TwitterFacebookGoogleYouTubeEmailRSS

Ein eigener, vollständig abgesicherter, Mailserver mit Zarafa

Da es bereits einige Zeit her ist (Februar 2013), wollte ich gerne eine aktualisierte Fassung online bringen, wie man einen Mailserver mit Hilfe von Zarafa und Postfix unter Ubuntu / Debian richtig konfiguriert. Der alte Post wird außerdem in den nächsten Tagen offline gehen. Hier werden wir einen Zarafa-Server zusammen mit Postfix und einer SASL-Authentifizierung sowie Virenscanner und Spamfilter so installieren und einrichten, dass dieser anschließend gegen gängige Angriffe geschützt ist. Dabei wird die gesamte Kommunikation auf Basis von SSL/TLS aufgebaut sein und es wird neben den normalen Web-Zugriff auch die Möglichkeit geben die E-Mail Konten in entsprechende Desktop Clients mit Absicherung einzurichten. Im Rahmen dieses „Tutorials“ werden wir also einen vollständig gesicherten Zarafa-Mailserver in Version 7.1.11 unter Ubuntu 14.04 LTS installieren und einrichten. Da ich bei meinem alten Post bereits Anfragen bekommen habe, ob ich hierbei Unterstützung leisten kann, möchte ich an dieser Stelle direkt darauf hinweisen, dass ich in einer IT-Firma angestellt bin, die diese Dienstleistungen anbieten kann. Bei näheren Fragen hierzu, also bitte an die CVA GmbH wenden. Beginnen wir also nun mit der kleinen „HowTo“-Anleitung.

Um diesen Beitrag in Englisch zu sehen hier klicken: View this post in english

 

Share-Online

Die Vorbereitung

Nachdem wir uns auf unseren Server verbunden haben, sollten wir zunächst einmal in ein beliebiges Verzeichnes wechseln, in dem wir später die Dateien herunterladen. Ich verwende hierfür das Home-Verzeichnes meines aktuellen Benutzers, welches ich mittels „cd ~“ erreiche. Nun müssen wir die passende Zarafa-Version für uns finden und herunterladen. Unter folgender URL können wir uns die passende Version heraussuchen: http://download.zarafa.com/community/final/. Ich verwende hierbei die Version 7.1.11 für Ubuntu 14.04 LTS. Um dorthin zu gelangen, klicken wir auf 7.1 und anschließend auf 7.1.11-46050. Sollte die spätere Verwendung in Microsoft Outlook gewünscht sein, müssen wir uns auch noch für dies das entsprechende Plugin herunterladen. Dieses Plugin finden wir im „windows“-Ordner im Zarafa Download Archiv. Die dortige „*.msi“-Datei können wir auf Windows-Maschinen problemlos installieren. Für eine finale Absicherung zum Ende hin, benötigen wir auch noch ein SSL-Zertifikat, welches wir z.B. von StartSSL bekommen können.

Um nun das Archiv mit den Daten für die Zarafa-Mailserver-Installation herunterzuladen, verwenden wir folgenden Befehl:

wget http://download.zarafa.com/community/final/7.1/7.1.11-46050/zcp-7.1.11-46050-ubuntu-14.04-x86_64-free.tar.gz

Nach dem Download müssen wir dies noch entpacken. Dies kann mit folgendem TAR-Befehl getätigt werden:

tar xvfz zcp-7.1.11-46050-ubuntu-14.04-x86_64-free.tar.gz

Außerdem sollte für die Installation des Mailservers ein Apache2 oder Nginx sowie MySQL installiert sein. Hierfür eignet sich z.B. die Installation des LAMP-Servers. Eine detaillierte Anleitung dazu befindet sich hier: http://www.mypcsupport.de/net/linux/ubuntu-lamp-installation/. Die Installation der MySQL-Datenbanken ist hierbei für dieses Tutorial zwingend erforderlich, während Apache2 bzw. Nginx nur für den Webzugriff (Webaccess und Webapp) von Zarafa notwendig sind.

Weiterhin müssen wir bei unserem Domain-Hoster noch die nötigen Subdomains sowie Maindomain konfigurieren. Hierfür benötigen wir einen A-Record für die Subdomain „secure“, die „mail“ Subdomain, für die „www“ Domain sowie ein MX-Record mit der Priorität 10, welcher auf „mail.example.de“ (ersetzen mit Ihrer Domain!) zeigt. Bedenken Sie, dass es bis zu einer Stunde dauern kann, bevor diese verfügbar sind. Die A-Record sollten natürlich alle auf unsere Server-IP-Adresse zeigen.

Nun haben wir alles, was wir zur Installation benötigen. Im nächsten Schritt geht es zur Installation.

 

Die Installation

Postfix

Beginnen wir mit der Installation von Postfix – unserem Kern für den Mailversand unter Zarafa. Hierfür können wir, nachdem wir unsere Paketliste aktualisiert haben, folgenden Befehl verwenden:

apt-get install postfix

Nachdem wir dies getan haben, beginnt auch gleich das Initial-Setup für Postfix. Eigentlich ist es egal was wir in Postfix konfigurieren, da wir vieles davon später manuell ändern werden, um die Sicherheit zu maximieren. Dennoch hier kurz der Guide durch den Installations-Wizard: Im ersten Dialog wird „Internet mit Smarthost“ gewählt. Als System E-Mail registrieren wir hier nun servername.domain also z.B. ‚example.example.de‘. Für den SMTP-Relay-Server ist es irrelevant was wir wählen, da wir diesen später entfernen. Für den Fall, dass es dennoch benötigt wird, könnte man dies auf z.B. ’smtp.example.de‘ festlegen. Damit ist die grundlegende Installation von Postfix auch bereits abgeschlossen, die nähere Konfiguration folgt später.

 

Zarafa

Kommen wir also nun zur Installation von Zarafa, Postfix sowie SASL und fail2ban. Für die Zarafa-Installation müssen wir zunächst in den gerade entpackten Ordner navigieren. Hier können wir nun das Shell-Script zur Installation verwenden, um so alle Referenzen zu bekommen.

./install.sh

Das nun folgende Setup kann größtenteils durch simples Bestätigen durchgeführt werden. Sollten der Installation Pakete fehlen, so erfolgt eine Aufforderung zur Installation, hierfür reicht jedoch eine Bestätigung. Beginnend bei der Aufforderung eine gültige Seriennummer einzugeben, kann nun unter http://www.zarafaserver.de/ eine erworben werden. Andernfalls können wir die Seriennummer zunächst leer lassen. Auch eine spätere Ergänzung der Seriennummer ist möglich. Dies werde ich unter den Punkt „Weiteres“ am Ende auflisten.

Bei der MySQL-Server Konfiguration, die im Rahmen des Setups erfragt wird, sollte der Host (wenn auf gleichem Server ‚localhost‘), Port, Benutzer sowie Passwort korrekt eingegeben werden. Diese Eingaben orientieren sich an jenen Eingaben aus der Installation. Wurde kein spezieller Benutzername gewählt, müsste dieser ‚root‘ sein, für den Host ‚localhost‘ und für Port ‚3306‘. Die Datenbank sollte einen eindeutigen, noch nicht existierenden Namen, bekommen z.B. ‚zarafa‘. Als Log-Methode kann grundsätzlich ‚file‘ genutzt werden, als Log-File sollte stets eine definierte Datei gewählt werden. Ich werde diese unter ‚/var/log/zarafa/‘ ablegen, bei SQL heißt mein Logfile ’sql.log‘.

Als SMTP-Server kann hierbei ’smtp.example.de‘ (example.de ist durchgehend durch die eigene Domain zu ersetzen!) verwendet werden. Auch hier ist wieder das Loggen sinnvoll einzurichten. Bei dem Warning-Interval nutze ich persönlich immer einen Tag also ‚1‘ als Wert. Natürlich sollte auch hier die Log-Konfiguration sinnvoll eingerichtet werden. Weiter geht es mit der Abfrage für POP3 sowie IMAP. Ich würde hierfür empfehlen den Service zu nutzen, da es auch Clients gibt, die nicht anders genutzt werden können. In diesem Zuge können natürlich auch die dafür verwendeten Ports direkt angepasst werden. Ich verwende hier jedoch die Standardports (110 POP3, 143 IMAP). Im Weiteren Verlauf werden wir gefragt, ob wir auch den iCal-Service nutzen möchten. Auch dies werde ich mitnutzen, da ich die Kalender Integration sinnvoll finde (über iCal / CalDAV findet auch die Anbindung in Kalander Apps auf Android oder iOS statt). Auch hierfür nutze ich den Standardport 8080.

Der nächste Service wäre der „Search“-Service (dt. Such-Service). Auch diesen werde ich nutzen. Gegebenenfalls werden Sie nun nochmals aufgefordert fehlende Pakete zu installieren, dies können Sie erneut mit einer Bestätigung akzeptieren. Abschließend kommt die Frage, ob der Service starten soll. Dies wird bestätigt und der „Search“-Service wird ausgeführt. Im Regelfall, mal abgesehen von Passwörtern sowie ob die einzelnen Services genutzt werden, kann der in den [] stehenden Standardwert durch einfaches drücken von Enter akzeptiert werden.

Wenn alles korrekt eingerichtet wurde, sollte nun bereits unter http://SERVER_IP_ADRESSE/webapp/ der Zarafa Server erreichbar sein. Sollte dem nicht so sein, helfen die Logfiles sicherlich weiter wo der Fehler liegt. Diese können in der Standard-Konfiguration unter „/var/log/“ gefunden werden. Die hierbei interessanten Log-Dateien sind jene im Apache / Nginx Ordner, Zarafa Ordner sowie der Mail-Log. In den meisten Fällen sind dies hier aber nur Apache / Nginx Modul-Fehler, weil entsprechende Module fehlen. Im Falle des Apache-Webservers sollten hier die Module ssl, rewrite sowie php5 vorhanden und aktiv sein. Auch das Apache-Modul „mod security“ bietet sich hierbei an.

 

SASL Authentication

Weiter geht es mit der SASL Installation. Aber was ist SASL eigentlich? SASL sorgt im Grunde für eine gesicherte Authentifizierung, damit wir SMTP nur mit Login verwenden können. Somit ist dies eine Erweiterung, die wir unbedingt nutzen sollten. Die Installation hiervon geschieht über eine simple Kommandozeile.

apt-get install sasl2-bin

Das ist erstmal auch schon alles, was wir mit SASL zur Installation machen müssen.

 

fail2ban

Ähnlich wie SASL muss auch fail2ban lediglich mit einem Befehl installiert werden. Dieses nützliche Programm schützt uns vor Brute-Force sowie DDOS Attacken.

apt-get install fail2ban iptables-persistent

 

Amavis

Genauso anspruchsvoll ist die als letztes verbleibende Installation von Amavis – unserem Viren und Spamschutz. Auch hierfür genügt ein einzelner Befehl und zwar folgender:

apt-get install amavisd-new clamav-daemon spamassassin razor pyzor

Nun sind wir mit unseren Installationen soweit fertig und können mit der Konfiguration beginnen.

 

Die Konfiguration

Beginnen wir mit der Konfiguration unserer einzelnen Teile. Da wir zuvor kein Zertifikat beantragen können, werden wir hier nun zunächst das ganze ohne SSL einrichten müssen und können erst im zweiten Schritt zur SSL Absicherung voranschreiten.

 

Die Grundeinrichtung

Als Grundlage für unseren Server sollten wir zunächst unsere SASL Authentifizierung konfigurieren. Dies tun wir indem wir folgende Datei bearbeiten (im Beispiel mit dem Nano-Editor):

nano /etc/postfix/sasl/smtpd.conf

Hier müssen wir Folgendes einfügen und anschließend abspeichern:

pwcheck_method: saslauthd
mech_list: plain login

Wenn dies erledigt ist, müssen wir den „Postfix“-Benutzer noch der „SASL“-Gruppe zuordnen. Hierfür steht uns folgender Befehl zur Verfügung:

gpasswd -a postfix sasl

Weiter geht es mit unserer Hauptkonfiguration von Postfix. Gehen wir also zunächst zu unserer Konfigurationsdatei:

nano /etc/postfix/main.cf

Hier müssen wir die ‚relayhost‘-Zeile durch Löschen oder Auskommentieren entfernen. Diese sollte sich relativ weit unten befinden und in etwa so aussehen (abhängig von der Angabe bei der Postfix Installation): „relayhost = smtp.example.de„. Wenn dies erledigt ist, fügen wir am Ende unserer Datei Folgendes ein (bitte die ‚example.de‘-Domain entsprechend ersetzen!):

# SASL Auth
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,check_relay_domains,reject_unauth_destination 

# Amavis
content_filter=smtp-amavis:[127.0.0.1]:10024 

# Zarafa Mailbox mapping
virtual_mailbox_domains = example.de
virtual_alias_maps = hash:/etc/aliases
mailbox_command = /usr/bin/zarafa-dagent "$USER"
virtual_transport = zarafa: zarafa_destination_recipient_limit = 1

Auch hier natürlich abspeichern und weiter geht es nochmal mit unserer SASL-Konfiguration. Dafür müssen wir folgende Datei bearbeiten:

nano /etc/default/saslauthd

Hier ist es am einfachsten, zunächst alles zu löschen und anschließend das Ganze in einem Stück einzufügen. Der Inhalt der Datei sollte anschließend wie folgt aussehen:

START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="rimap"
MECH_OPTIONS="127.0.0.1"
THREADS=0
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"

Nun geht es weiter, indem wir unseren Virtual-Mail Benutzer anlegen und einbinden. Außerdem benötigen wir noch einen Benutzer für Amavis.

adduser --system --no-create-home vmail
adduser clamav amavis

Somit haben wir also auch noch die Benutzer angelegt, die unser Setup benötigen wird. Außerdem müssen wir unseren Virutal-Mail-Benutzer noch für Zarafa bekannt machen. Dafür nutzen wir folgende Datei:

nano /etc/zarafa/server.cfg

Dazu suchen wir nach der Variable „local_admin_users“ und fügen, wie bereits in der Kommentarzeile abgebildet, den vmail-Benutzer hinzu. Weiter geht es mit Amavis und dessen Einbindung. Hierfür müssen wir folgende Datei bearbeiten:

nano /etc/amavis/conf.d/15-content_filter_mode

Hier müssen wir jeweils die ‚#‘-Zeichen vor den Zeilen, die mit einem ‚@‘ starten und deren jeweiliger Folgezeile entfernen. Abschließend sollte die Konfiguraiton in etwa so aussehen:

use strict;

@bypass_virus_checks_maps = (
 \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);

@bypass_spam_checks_maps = (
 \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

 1;

Weiter geht es damit, Amavis zu aktivieren. Dies geschieht in folgender Datei:

nano /etc/default/spamassassin

Hier muss lediglich die Variable ‚ENABLED‘ auf ‚1‘ anstatt auf ‚0‘ gesetzt werden. Danach folgt die Einrichtung von fail2ban. Hier müssen wir noch die zu schützenden Schnittstellen aktivieren. Dies können natürlich mehr sein als nur die für unseren Mail-Verkehr . Ich werde hier aber nur jene erläutern. Dafür benötigen wir folgende Datei:

nano /etc/fail2ban/jail.conf

Hier können wir zunächst nach „postfix“ suchen und die ‚enabled‚ Variable auf ‚true‚ setzen. Selbiges machen wir nun noch mit „sasl„. Sinn machen würde es auch noch für apache sowie ssh. Abschließend für unsere Grundkonfiguration folgt die Anpassung in der Postfix Master-Datei. Diese finden Sie hier:

nano /etc/postfix/master.cf

Hier muss auch gleich einiges ergänzt werden. Unter der Zeile „pickup    unix  n       –       –       60      1       pickup“ können wir folgendes für Amavis einfügen:

# Amavis
 -o content_filter=
 -o receive_override_options=no_header_body_checks
# Amavis end

Unter der Zeile „smtp      unix  –       –       –       –       –       smtp“ wird dies eingefügt:

smtps inet n - n - - smtpd
 -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes

Weiterhin wird Submission Support + SASL aktiviert. Der komplette „submission”-Block inkl -o Parameter wird gelöscht (Zeile löschen in nano mit STRG+K) und durch folgenden Block ersetzt:

submission inet n       -       -       -       -       smtpd -v
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Und abschließend muss am Ende der Datei dieser Block eingefügt werden:

zarafa unix - n n - 10 pipe
 flags=DRhu user=vmail argv=/usr/bin/zarafa-dagent -R ${recipient}
# Amavis
smtp-amavis unix - - - - 2 smtp
 -o smtp_data_done_timeout=1200
 -o smtp_send_xforward_command=yes
 -o disable_dns_lookups=yes
 -o max_use=20

127.0.0.1:10025 inet n - - - - smtpd
 -o content_filter=
 -o local_recipient_maps=
 -o relay_recipient_maps=
 -o smtpd_restriction_classes=
 -o smtpd_delay_reject=no
 -o smtpd_client_restrictions=permit_mynetworks,reject
 -o smtpd_helo_restrictions=
 -o smtpd_sender_restrictions=
 -o smtpd_recipient_restrictions=permit_mynetworks,reject
 -o smtpd_data_restrictions=reject_unauth_pipelining
 -o smtpd_end_of_data_restrictions=
 -o mynetworks=127.0.0.0/8
 -o smtpd_error_sleep_time=0
 -o smtpd_soft_error_limit=1001
 -o smtpd_hard_error_limit=1000
 -o smtpd_client_connection_count_limit=0
 -o smtpd_client_connection_rate_limit=0
 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

Damit ist die Konfiguration an sich abgeschlossen. Allerdings benötigen wir noch einen E-Mail Account sowie die Weiterleitung von ‚webmaster‘, ‚postmaster‘ und ‚hostmaster‘ auf unseren Mail-Account. Legen wir uns also zunächst einmal unseren Mail-Account an. Dies geschieht über folgende Befehle (Zeilen einzeln ausführen und Bildschirmausgabe beachten!):

adduser mailuser --no-create-home
zarafa-admin -c mailuser -p mailpassword -f "Mailuser Example" -e "mailuser@example.de" 
zarafa-admin -u mailuser --enable-feature imap 
zarafa-admin --create-store mailuser

Ok, was geschieht hier nun? Zunächst erzeugen wir einen lokalen Benutzer ohne sonderlich viele Rechte und ohne Home-Verzeichnis. Hierfür müssen wir noch ein Passwort auf unserem System festlegen, das dasselbe sein sollte wie das spätere Mail-Passwort. Anschließend machen wir Zarafa mit unserem Benutzer bekannt. Der Parameter ‚-c‘ gibt hierbei den Loginnamen an, ‚-p‘ das Passwort, ‚-f‘ den Anzeigenamen und da ein Leerzeichen vorkommt in „“ (dies ist im Regelfall Vor- und Nachname) und zum Schluss ‚-e‘ welches die Mail angibt. In der nächsten Zeile erlauben wir unserem neuen Benutzer noch die IMAP-Kommunikation zu benutzen und fügen anschließend noch ein Storage für die Mails hinzu. Bitte beachten Sie hierbei, dass der Benutzer- / Loginname sowie das Passwort durchgehend identisch sein sollte.

Bearbeiten wir nun die Weiterleitung der Postfächer. Dazu müssen wir folgende Datei bearbeiten:

nano /etc/aliases

Am einfachsten ist es hier, die folgende Zeile einzufügen:

root: mailuser

Denn so werden alle, die auf root geleitet werden auf unseren Mail-Benutzer (natürlich anpassen!) weitergeleitet. Ansonsten muss diese Anpassung mindesten für die drei oben genannten erfolgen, damit wir dessen Mails auch bekommen. Nun benötigen wir noch folgenden Befehl um die Datenbank zu aktualisieren:

newaliases

Für nähere Informationen zu den Aliases, kann folgendes Tutorial herangezogen werden: http://townx.org/blog/elliot/adding_aliases_to_postfix_on_ubuntu

Damit amavis razor und pyzor verwenden kann, ist folgendes noch zusätzlich notwendig (Zeile für Zeile eingeben):

su - amavis -s /bin/bash
razor-admin -create
razor-admin -register
pyzor discover
exit

Außerdem empfehle ich in der Datei „/etc/amavis/conf.d/20-debian_defaults“ folgende Änderungen durchzuführen (entsprechende Stellen suchen und ändern):

$sa_tag_level_deflt  = undef;
$sa_tag2_level_deflt = 5;
$sa_kill_level_deflt = 20;

Abschließend, damit die Konfigurationen auch wirksam werden, müssen nochmals sämtliche verwendeten Services neugestartet werden (bitte Zeilen nur einzeln eingeben!).

service saslauthd restart
service spamassassin restart
service clamav-daemon restart
service amavis restart
service postfix restart
service zarafa-dagent restart
service zarafa-server restart
service apache2 restart
service fail2ban restart

Etwaige Warnungen von Amavis bezüglich der Aktualität können hierbei ignoriert werden – die Aktualisierung geschieht automatisch. Nun sollten wir uns auch mit unserem Mail-Benutzer sowie dessen Passwort im Zarafa-Webinterface einloggen können. Dafür stehen uns folgende zwei Webinterfaces standardmäßig zur Verfügung:

WebApp: http://SERVER_IP_ADRESSE/webapp/
Webaccess: http://SERVER_IP_ADRESSE/webaccess/

 

Anlernen des Spam-Filters

Da ein Spam-Filter, in unseren Fall spamassassin, immer erst angelernt werden muss, um Spam korrekt zu erkennen und Filtern zu können, müssen wir dies nun auch noch tun. Wechseln wir zunächst einmal in ein dafür geeignetes Verzeichnis. Ich nutze hier für „/var/mail/spam/„. Sollte das Verzeichnis nicht vorhanden sein, kann dies mittels „mkdir“ angelegt werden. Geeignete Spam-Archive können z.B. von folgender Seite heruntergeladen werden (wieder mit wget): http://untroubled.org/spam/. Wenn die entsprechenden Archive heruntergeladen worden (es empfiehlt sich immer mindestens die drei letzten zu nehmen) und entpackt worden sind, führen wir einfach folgenden Befehl aus:

sa-learn --no-sync --spam /var/mail/spam/

Dieser Befehl kann nur einige Minuten dauern, also erstmal ein fröhliches Warten. Zusätzlich können wir ein automatisches Anlernen aktivierern. Hierfür müssen wir folgende Datei bearbeiten

nano /etc/spamassassin/local.cf

Hier müssen zwei Zeilen wieder rein genommen werden, welche derzeit durch ein ‚#‘ deaktiviert sind.

use_bayes 1
bayes_auto_learn 1

Auch wenn dies sehr performancehungrig ist, so lernt Spamassassin nun zukünftig durch von uns in Spam / Junk verschobene E-Mail dazu. Natürlich empfiehlt es sich weiterhin auch das direkte anlernen über „sa-learn“ zu nutzen. Hier sollte wenigstens alle 2-3 Monate ein Anlernen stattfinden, um einen sauberen Spam-Filter nutzen zu können. Auch wenn es nicht zwingend notwendig ist, empfiehlt sich ein Neustart von Spamassassin nach erfolgreichen Anlernen durch „sa-learn„.

 

Die SSL Konfiguration

Nun haben wir eine schon einigermaßen gesicherte Konfiguration. Aber was noch fehlt ist die Verschlüsselung durch SSL. Hierfür benötigen wir nun ein Zertifikat, eine erneute Anpassung unserer Konfigurationen und zum Schluss wieder einen Neustart unserer Systeme. Ein kostenloses Zertifikat können wir z.B. von hier bekommen: https://www.startssl.com/ (Hinweis: Diese Zertifikate müssen jährlich erneuert werden). Die einzige Bedingung ist eine Registrierung (das Registrierungszertifikat sollte man sich Speichern, da es später zum Login dient). Mit Hilfe des „Validation Wizard“ können wir unsere Domain validieren lassen. Hierfür müssen wir bei Type „Domain Name Validation“ wählen und dem Wizard folgen. Am Ende sollten wir eine E-Mail mit unserem Freischaltcode bekommen. Sollte diese nicht ankommen, müssen wir uns die Logdatei von unserem Mailserver näher ansehen. Dies finden Sie hier:

tail -f --lines=30 /var/log/mail.log

Meist findet man hier alle benötigen Informationen, wenn etwas schief geht. Wenn die Validierung geschafft ist, geht es weiter zum „Certificates Wizard“. Hier wählen wir als Certificate Target „Web Server SSL/TLS Certificate“. Anschließend müssen wir ein Passwort für unser Zertifikat wählen, dies sollte möglichst komplex und lang sein, jedoch ist es erforderlich, dass dies noch in ein paar Minuten zur Verfügung steht. Als „Keysize“ muss hier „2048“ gewählt werden und als Hash-Algorithm „SHA2“. Nun haben wir unseren privaten Schlüssel. Anschließend gehen wir auf dem Server zu folgender Datei:

nano /etc/keys/mail.ssl.key

Dort fügen wir den Text 1:1 ein. Im nächsten Schritt führen wir folgenden Befehl aus und geben unser Passwort ein, welches wir zur Zertifikatserstellung gewählt haben und hier eigtl. zum letzten Mal benötigen.

openssl rsa -in /etc/keys/mail.ssl.key -out /etc/keys/mail.ssl.key

Danach geht es weiter im Wizard. Nun wählen wir unsere Domain aus und geben die Subdomain an, welche wir bei unserem Domain-Hoster registriert haben. Ich nutze hierfür z.B. „secure.example.de„. Nun bekommen wir noch eine Zertifikatsdatei, die wir hier ablegen:

nano /etc/keys/mail.ssl.crt

Erneut den Inhalt 1:1 einfügen, den wir im Wizard bekommen. Nun benötigen wir noch das CA-Zertifikat sowie das Class1-CA-Zertifikat. Beginnen wir mit dem Class1 Zertifikat:

nano /etc/keys/sub.class1.server.ca.pem

Hier fügen wir Folgendes ein (nur wenn StartSSL verwendet wird, ansonsten bitte das passende Class1-CA-Zertifikat anfordern):

-----BEGIN CERTIFICATE-----
MIIGNDCCBBygAwIBAgIBGDANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjA1NDE3WhcNMTcxMDI0MjA1NDE3WjCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtonGrO8JUngHrJJj0PREGBiE
gFYfka7hh/oyULTTRwbw5gdfcA4Q9x3AzhA2NIVaD5Ksg8asWFI/ujjo/OenJOJA
pgh2wJJuniptTT9uYSAK21ne0n1jsz5G/vohURjXzTCm7QduO3CHtPn66+6CPAVv
kvek3AowHpNz/gfK11+AnSJYUq4G2ouHI2mw5CrY6oPSvfNx23BaKA+vWjhwRRI/
ME3NO68X5Q/LoKldSKqxYVDLNM08XMML6BDAjJvwAwNi/rJsPnIO7hxDKslIDlc5
xDEhyBDBLIf+VJVSH1I8MRKbf+fAoKVZ1eKPPvDVqOHXcDGpxLPPr21TLwb0pwID
AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYD
VR0OBBYEFOtCNNCYsKuf9BtrCPfMZC7vDixFMB8GA1UdIwQYMBaAFE4L7xqkQFul
F2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDov
L29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0
c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0
BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl
LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEAIQlJPqWIbuALi0jaMU2P91ZXouHTYlfp
tVbzhUV1O+VQHwSL5qBaPucAroXQ+/8gA2TLrQLhxpFy+KNN1t7ozD+hiqLjfDen
xk+PNdb01m4Ge90h2c9W/8swIkn+iQTzheWq8ecf6HWQTd35RvdCNPdFWAwRDYSw
xtpdPvkBnufh2lWVvnQce/xNFE+sflVHfXv0pQ1JHpXo9xLBzP92piVH0PN1Nb6X
t1gW66pceG/sUzCv6gRNzKkC4/C2BBL2MLERPZBOVmTX3DxDX3M570uvh+v2/miI
RHLq0gfGabDBoYvvF0nXYbFFSF87ICHpW7LM9NfpMfULFWE7epTj69m8f5SuauNi
YpaoZHy4h/OZMn6SolK+u/hlz8nyMPyLwcKmltdfieFcNID1j0cHL7SRv7Gifl9L
WtBbnySGBVFaaQNlQ0lxxeBvlDRr9hvYqbBMflPrj0jfyjO1SPo2ShpTpjMM0InN
SRXNiTE8kMBy12VLUjWKRhFEuT2OKGWmPnmeXAhEKa2wNREuIU640ucQPl2Eg7PD
wuTSxv0JS3QJ3fGz0xk+gA2iCxnwOOfFwq/iI9th4p1cbiCJSS4jarJiwUW0n6+L
p/EiO/h94pDQehn7Skzj0n1fSoMD7SfWI55rjbRZotnvbIIp3XUZPD9MEI3vu3Un
0q6Dp6jOW6c=
-----END CERTIFICATE-----

Weiter geht es mit dem CA-Zertifkat, welches hier liegt:

nano /etc/keys/ca.pem

Mit folgendem Inhalt (nur wenn StartSSL verwendet wird, ansonsten bitte das passende CA-Zertifikat anfordern):

-----BEGIN CERTIFICATE-----
MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh
cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk
pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf
OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C
Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT
Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi
HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM
Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w
+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+
Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3
Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B
26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID
AQABo4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYE
FE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3Js
LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFM
BgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy
dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3Rh
cnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlh
YmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg
dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFp
bGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJ
YIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNT
TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ
9GYMNPXQhV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8
jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUW
FjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENNZEXO3SipXPJz
ewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1
ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5L
EUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYu
L6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq
yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuC
O3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6V
um0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkySh
NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14=
-----END CERTIFICATE-----

Nun müssen wir noch ein zusammengefügtes Zertifikat erzeugen. Dieses legen wir einfach mit folgenden Befehl an:

cd /etc/keys/ && cat mail.ssl.crt mail.ssl.key ca.pem sub.class1.server.ca.pem sub.class1.server.ca.pem > example.de-ssl.pem

Und ja, es ist korrekt, dass das letzte Zertifikat hier zwei mal hinein gehört. Nun haben wir auch unser zusammengefügtes Zertifikat. Abschließend müssen wir nochmals die Main-Konfiguration von Postfix anpassen. Diese finden wir erneut hier: 

nano /etc/postfix/main.cf

Hier ist nun der Teil unter „# TLS parameters“ bis hin zu „# See /usr/share/doc…“ durch Folgenden zu ersetzen:

smtpd_tls_auth_only = no
smtp_use_tls = yes
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes

smtpd_tls_cert_file = /etc/keys/example.de-ssl.pem
maildrop_destination_recipient_limit = 1

smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

Sollte Ihre zusammengefügte Zertifikatsdatei anders heißen, korrigieren Sie diese bitte! Anschließend müssen wir noch in der Zarafa-Gateway-Konfiguration IMAPS und/oder POP3S aktivieren. Dies wird in folgender Datei gemacht:

nano /etc/zarafa/gateway.cfg

Hier werden die folgenden eigenschaften mit „yes“ aktiviert (auch die Ports könnten hier geändert werden, falls gewünscht):

pop3s_enable    =       yes
imaps_enable    =       yes

Natürlich müssen nicht beide aktiviert sein. Jedoch verwenden wir in unserer SASL-Konfiguration Reverse-IMAP, dies sollte nicht vergessen werden. Die hier nun genutzten Ports müssen anschließend nur noch in der Firewall frei gegeben werden. Allgemein empfiehlt es sich eine White-List-Firewall zu führen und nur Erlaubtes freizugeben. Erneut können wir einfach den oben bereits genutzten Restart-Block nutzen, um das Ganze zu aktivieren (theoretisch würde ein postfix, apache und zarafa reload genügen).

service saslauthd restart
service spamassassin restart
service clamav-daemon restart
service amavis restart
service postfix restart
service zarafa-dagent restart
service zarafa-server restart
service apache2 restart
service fail2ban restart

Somit können wir nun mit Hilfe eines E-Mail Programms die gesicherte Verbindung testen. Sollte es erforderlich sein, dass die Weboberflächen ebenfalls mit SSL, also HTTPS aufgerufen werden können, ist noch eine Anpassung bei apache nötig. Hierfür kann folgendes Tutorial genutzt werden: http://wiki.ubuntuusers.de/Apache/SSL

 

Weiteres

Greylisting

Greylisting ist eine Form der SPAM-Bekämpfung. Hierbei wird sich zunutze gemacht, dass normale Mailserver einen gescheiterten Zustellversuch später wiederholen, während Spammer sich im Allgemeinen nicht diese Mühe machen. Der Greylisting-Dienst identifiziert dabei jeden Client über eine Kombination aus IP-Adresse, Absenderadresse und Empfängeradresse. Taucht eine derartige Kombination das erste Mal auf, so wird der Zustellversuch mit einer Fehlermeldung bzgl. eines temporären Problems abgelehnt und diese ID in einer Liste eingetragen. Wird die Kombination erneut zugestellt, wird diese dann vom Mailer akzeptiert.

Nachteil dieser Methode ist, dass die jeweils ersten Emails von neuen Kontakten ein wenig verzögert eintreffen. Vorteil gegenüber herkömmlichen, analyse-gestützten Spamerkennungsverfahren ist, dass die Mail gar nicht erst angenommen und unter Aufwendung von Rechenzeit untersucht werden muss, sondern direkt abgelehnt wird. Gerade auf ausgelasteten Servern stellt dies eine vorteilhafte Möglichkeit dar, einen Großteil des Mülls gar nicht erst auf das System zu lassen.

Installieren lässt sich das Greylisting ganz simpel über folgenden Befehl:

apt-get install postgrey

Nun muss dies noch in der Datei „/etc/postfix/main.cf“ eingebunden werden. Hier wird die Zeile für die Eigenschaft „smtpd_recipient_restrictions“ um den Wert „check_policy_service inet:127.0.0.1:10023“ erweitert (Achtung: Port könnte abweichen!! Sollte der Port falsch sein, bekommt man einen Verbindungsfehler im Mail-Log mit). Die Zeile sollte nun in etwa so aussehen:

smtpd_recipient_restrictions =  permit_mynetworks,
				permit_sasl_authenticated,
				reject_unauth_destination,
				check_policy_service inet:127.0.0.1:10023

Nun noch Postfix mittels „service postfix restart“ neustarten und schon ist das Greylisting aktiv und sollte im Mail-Log einsehbar sein.

 

Zarafa Bayesian Learning

Um Spam-Mails direkt aus Zarafa zu erlernen, kann folgendes Tutorial verwendet werden:
Zarafa Bayesian Learning (zur Installation des Perl-IMAP Plugins wird unter Ubuntu / Debian folgender Befehl benötigt: „apt-get install libmail-imapclient-perl„)

 

Nachträgliche Installation einer Zarafa-Lizenz

Um nachträglich die Zarafa-Lizenz zu Installieren, muss folgende Datei bearbeitet werden:

nano /etc/zarafa/license/base

Hier wird die Lizenz einfach im Klartext hineingeschrieben und gespeichert. Anschließend müssen die Zarafa Dienste neugestartet werden.

service zarafa-dagent restart
service zarafa-gateway restart
service zarafa-ical restart
service zarafa-licensed restart
service zarafa-monitor restart
service zarafa-search restart
service zarafa-server restart
service zarafa-spooler restart

 

Zarafa-Mailserver Administration

Da das ZAdmin (Zarafa-Admin) Webinterface noch nicht für Ubuntu 14.04 freigegeben worden ist, müssen die administrativen Zugriffe (anlegen, ändern, löschen und anzeigen) der Dienste über eine SSH-Sitzung durchgeführt werden. Nachfolgend eine Auflistung der wichtigsten Zarafa-Administrationsbefehlen. Eine detaillierte Erklärung sämtlicher Zarafa-Administrationsbefehle kann hier nachgeschlagen und gefunden werden:
http://doc.zarafa.com/7.1/Administrator_Manual/en-US/html/_UserManagement.html (DB plugin)

Befehl Auswirkung
zarafa-admin -l Zeigt alle existierenden Benutzer an. Hier wird der Benutzername (Loginname), der vollständige Name sowie der „Homeserver“ ausgegeben.
zarafa-admin -c MAILUSER -p MAILPASSWORD -f „FULL MAILUSER NAME“ -e „MAILUSER@example.de“ Legt einen neuen Benutzer an. Der Parameter „-c“ wird hierbei mit den Loginnamen versehen, „-p“ mit dem dazugehörigen Passwort, „-f“ mit den vollständen Namen des Benutzers und „-e“ mit der entsprechenden E-Mail Adresse (diese muss zu den Zertifikatsinformationen passen).
zarafa-admin -u MAILUSER –enable-feature imap Aktiviert die IMAP-Funktionalität für den entsprechenden Benutzer. Wenn dies nicht ausgeführt wird, ist nur POP3 verfügbar.
zarafa-admin –create-store mailuser Erstellt das Mail-Storage für den Benutzer. Wenn das Anlegen des neuen Benutzers mit „sudo“ ausgeführt worden ist, ist dieser Befehl nicht notwendig.
zarafa-admin –d MAILUSER Löscht den entsprechenden Benutzer.
zarafa-admin –details MAILUSER Gibt die Details des jeweiligen Benutzers aus.

Eine Ausführliche Erklärung des zarafa-admin-Tools kann unter anderem auch unter diesem Link gefunden werden:
http://rpm.pbone.net/index.php3/stat/45/idpl/15454311/numer/1/nazwa/zarafa-admin

 

Bei Änderung des MySQL-Passwortes

Wenn die Passwörter  zur Sicherheit geändert werden (auch wenn der Zarafa-Benutzer nur lokalen Zugriff haben sollte), muss dies in folgender Datei angepasst werden:

nano /etc/zarafa/server.cfg

 

Weitere Informationen zur Mailserver Funktionsweise

MTA: http://de.wikipedia.org/wiki/Mail_Transfer_Agent
MDA: http://de.wikipedia.org/wiki/Mail_Delivery_Agent
Zarafa: http://www.zarafa.com/wiki/index.php/Main_Page
Anti-Spam (spamassassin): http://de.wikipedia.org/wiki/SpamAssassin
Anti-Virus (Amavis): http://de.wikipedia.org/wiki/Amavis

 

Hilfreiches Wissen / Weitere Konfigurationen

Zarafa: http://wiki.ubuntuusers.de/Zarafa
Postfix: http://wiki.ubuntuusers.de/Postfix
Postfix Erweiterte Konfiguration: http://wiki.ubuntuusers.de/Postfix/Erweiterte_Konfiguration
Amavis-Spam-Virenfilter: http://wiki.ubuntuusers.de/Amavis-Spam-Virenfilter

 

Fazit

Abschließend möchte ich noch hinzufügen, dass das Aufsetzen eines eigenen Mailservers mithilfe von Zarafa und Postfix wirklich ein Kinderspiel ist. Selbst die Absicherung des Servers ist in kürzester Zeit zu realisieren. Jedem der einen eigenen Mailserver aufsetzten will, dem kann ich Zarafa nur empfehlen. Aktuell ist dies aus meiner Sicht das Beste. Auch für Firmen lohnt es sich hier eine entsprechend lizensierte Fassung aufzusetzen und zu verwenden, da auch die Lizenzkosten akzeptabel sind. Die Unterschiede zwischen der kostenlosen und der kostenpflichten Version können der Zarafa Homepage problemlos entnommen werden.

Ich hoffe ich konnte Ihnen mit diesem Tutorial helfen und würde mich über Feedback freuen.

 

Der Beitrag hat euch gefallen, geholfen und Ihr wollt mich unterstützen? Den macht dies doch einfach direkt hier. Teilt die Seite über Socialmedia Netzwerke, nutzt die Amazon Links oder spendet einfach einen kleinen Betrag via PayPal. Jede Art der Unterstützung ist eine Hilfe für Blogs wie diesen.

33 Gedanke zu “Ein eigener, vollständig abgesicherter, Mailserver mit Zarafa

  1. Hallo Sebastian, schon meinen ersten Zarafa Server habe ich nach deiner Anleitung gemacht, super klasse Arbeit dies auf deutsch ins Netz zu stellen!
    Laut Zarafa Forum gibt es für Ubuntu 14.04 aber einer erste Z-Admin Version, und dies schon seit September, ich hatte selbst im August einen Thread im forum aufgemacht, denn meiner meinung nach ist Z-Admin unerlässlich, es sei denn ich arbeite nur mit 1-2 Accounts, dann reicht das sicherlich. Ich hatte da nur drübergeflogen, aber soll wohl bei einem fresh install funktionieren.

  2. Hallo, vielen Dank für den interessanten Artikel.

    Im letzten Abschnitt zu Spamassassin steht, dass Spamassassin im Spam/Junk-Folder abgelegte eMails bei der Bewertung berücksichtigt. Was mir noch nicht ganz klar ist: Wie greift Spamassassin auf den Spam/Junk-Folder des Users zu? Bisher habe ich den Eindruck, dass die dort abgelegten Mails von Spamassassin auf dem Server nicht beachtet werden da sie ja in der Datenbank gespeichert sind. Im Netz gibt es auch nur Anleitungen für einen Public-Folder, in dem die Benutzer die Mails ablegen müssen.

    • Ich glaube hier war der Satz ein wenig unglücklich von mir gewählt worden. Die Ordner müssen für Spamassassin natürlich zugänglich sein. Hier gibt es die Möglichkeit über einen entsprechenden Public-Spam-Ordner dies zu implementieren oder alternativ kann man auch ein Script erstellen welche die Mails dieser Ordner anschließend für Spamassassin ausliest und im Dateisystem des Servers ablegt.

      • Hallo Sebastian,

        vielleicht passt Du deine Anleitung nochmal an betreff Spamassassin, ich müsste mich jetzt auch erst durch google wälzen um nach einer Lösung zu suchen, wie das dann geht.

        By the Way, mal offtopic:

        ich schleppe aus historischen Gründen ein 3GB postfach mit mir rum, ich greife ständig von mind 3 Quellen auf mein Postfach zu, Laptop/Smartphone/Office PC, Dieses Archiv hat mir schon oft den Ar*** gerettet, daher will ich das gerne immer vorhalten.

        Durch die 3GB ist es natürlich „langsam“ hat keiner eine interessante Alternative um ein „Archiv“ online vorhalten zu können, es aber so vom aktuellen Postfach zu trennen, bestenfalls das so mit regeln zu spicken, das es automatisch nachts vorgefertigte Regeln abarbeitet um Mails ins Archiv zu packen…

        Ich meine ich hätte bei Zarafa da mal was drüber gelesen, aber durch mein schlechtes Englisch nicht wirklich verstanden

        • Sobald ich die Zeit finde mich dort noch mal richtig rein zu arbeiten (Thema: Spamassassin Automatisches anlernen) kann ich dies gern noch im Beitrag einfügen. Ich würde ungern einfach etwas aus irgendwelchen Google Quellen übersetzen sondern auch wirklich vorher verstehen. Aktuell nutze ich selber auch kein automatisches Anlernen da mir dies die Performance auf einen vServer zerlegen würde.

          Bzgl. des Archivs meine ich, auch schon einmal etwas gelesen zu haben. Aber auch hier gilt das Gleiche wie für Spamassassin und dem automatischen anlernen.

  3. Vielen Dank für deinen hilfreichen Artikel! Mein Zarafa funktioniert wunderbar!
    Einen Hinweis hätte ich noch: man muss noch die Webaccess-Seite im Apache einrichten, da ansonsten nicht auf das Webinterface zugegriffen werden kann.
    Weiterhin könntest du noch den Artikel: http://www.maffert.net/debian-z-push-activesync-fuer-zarafa-installieren-smartphone/ in deine Seite integrieren. Activesync ist einfach ein super cooles Feature, dass den Zarafa noch wertvoller macht 🙂

    Viele Grüße,

    Jonas

  4. Hallo,

    du verwendest folgenden Befehl, um ein SSL-bundle zu erstellen:

    „cd /etc/keys/ && cat mail.ssl.crt mail.ssl.key ca.pem sub.class1.server.ca.pem sub.class1.server.ca.pem > example.de-ssl.pem“

    das ist in meinen Augen jedoch fatal. Du hast damit deinen privaten key mit in das Bundle eingefügt, wozu? Außerdem hast du zwei mal das Intermediate Class 1 Zertifikat von StartCom eingefügt und die Reihenfolge sollte auch anders aussehen. So sollte das richtigerweise lauten:

    „cd /etc/keys/ && cat mail.ssl.crt sub.class1.server.ca.pem ca.pem > example.de-ssl-bundle.pem“

    Oder nicht?

    • Den musst du in der Konfiguration jedoch den Private-Key separat angeben. Ich habe dies so gelöst, da das Zertifikat so eh nicht an den Client gesendet wird (es ist nur für Postfix so). Ob man die Reihenfolge ändern kann, weiß ich nicht, ich kenne es nur so – spontan würde ich aber sagen, dass man weder Reihenfolge ändern kann, noch was auslassen kann, da dieses zusammengefügte Zertifikat von Postfix in die einzelnen Bausteine wieder geteilt wird, ist also nur eine Konfigurationssache.

  5. Hallo Sebastian,

    zunächst besten Dank für diese tolle Anleitung. Habe vor Jahren schon mal mühsam Zarafa installiert und es hat Tage gedauert bis es lief. Mit Deiner Anleitung ging es dieses mal ruck zuck.
    Leider habe ich das genaue Zusammenspiel der einzelnen Komponenten noch nicht ganz verstanden. Das rächt sich immer, wenn man dann von der Anleitung in einzelnen Punkten abweichen muss.
    Nun habe ich das Gefühl, dass spamassasin nicht funktioniert. (Es werden jedenfalls keine Spams ausgefiltert)

    Da ich meinen Zarafa server auf einer eigenen Domain betreibe mit eigenem SMTP habe ich den SASL Teil weggelassen. Ich hoffe, das ist in Ordnung so.
    Ich kann problemlos Mails in Zarafa empfangen und auch raussenden.
    Das ganze funktioniert mit webaccess und mit zpush.

    spamd, clamd und amavis scheinen im Hintergrund zu laufen, wie ps aux ergibt.
    rroot@vserver:/var/log# ps aux | grep ’spamd \|amavis \|clam‘
    root 1896 0.0 0.2 146956 2512 ? Ss Nov29 0:12 /usr/sbin/spamd –create-prefs –max-children 5 –helper-home-dir -d –pidfile=/var/run/spamd.pid
    root 1901 0.0 0.1 146956 1596 ? S Nov29 0:00 spamd child
    root 1902 0.0 0.1 146956 1604 ? S Nov29 0:00 spamd child
    amavis 2098 0.0 0.1 217188 1208 ? Ss Nov24 0:10 /usr/sbin/amavisd-new (master)
    clamav 2510 0.0 31.1 441064 319604 ? Ssl Nov24 7:40 /usr/sbin/clamd -c /etc/clamav/clamd.conf
    clamav 2641 0.1 0.1 73956 1396 ? Ss Nov24 10:28 /usr/bin/freshclam -d –quiet –config-file=/etc/clamav/freshclam.conf
    root 4506 0.0 0.0 2556 160 pts/0 D+ 09:34 0:00 grep spamd \|amavis \|clam
    amavis 26751 0.0 6.6 230600 68180 ? S Nov28 0:21 /usr/sbin/amavisd-new (ch13-avail)
    amavis 26777 0.0 6.7 227752 68968 ? S Nov28 0:17 /usr/sbin/amavisd-new (ch12-avail)

    hast Du eine Idee, wo ich den Fehler suchen kann? Ich finde für spamassassin auch keine logs.
    Kann gerne noch ein paar configs senden, wenn ich weiß, wo ich suchen soll

    Bin dankbar für jeden Tip
    Mario

    Ich vermute, dass die Mails bei mir an spamd vorbei gehen.

    • Hallo Herr Cremer,

      den SASL Teil würde ich nicht weglassen, auch wenn der Server unter einer eigenen Domaine betrieben wird. Der SASL Teil ist quasi die letzte Barrikade gegen Bots und Hacker. Siehe: https://de.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer. Damit Spamassassin korrekt funktioniert ist ein „Anlernen“ des Filters erforderlich. Dazu gibt es bereits einige gute Anleitungen bei Google zum Thema Public-Folder Antispam und zusätzlich gibt es noch die manuelle Methode aus der Anleitung oben, siehe „Anlernen des Spam-Filters“. Ich verwende zum „Anlernen“ die manuelle Methode und das Script von DMZS, so als Beispiel. Wenn ansonsten die Anleitung befolgt wurde, sollte Spamassassin, nachdem es weiß, was Spam ist, diesen Filtern können. Das einzige, was mir AdHoc auffällt ist, dass der spamd bei mir mit anderen Parametern läuft siehe:

      root@Ubuntu1404:/# ps ax | grep 'spam\|amavis\|clam'
       1589 ?        Ssl   23:24 /usr/sbin/clamd
       1708 ?        Ss    60:23 /usr/bin/freshclam -d --quiet
      23949 ?        Ss     0:06 /usr/sbin/spamd --create-prefs --max-children 2 --username spamd -H -s spamd.log -d --pidfile=/var/run/spamd.pid
      23962 ?        Ss     0:01 /usr/sbin/amavisd-new (master)
      23970 ?        S      0:00 spamd child
      23971 ?        S      0:00 spamd child
      23977 ?        S      0:00 /usr/sbin/amavisd-new (ch1-avail)
      23978 ?        S      0:00 /usr/sbin/amavisd-new (virgin child)
      24486 pts/0    S+     0:00 grep --color=auto spam\|amavis\|clam

      Die Relevanz von SASL lässt sich im übrigen hiermit ganz gut testen: http://www.mailradar.com/openrelay

      • Hallo zurück,
        danke für die superschnelle Antwort. Habe nun den SASL-Teil nachgeholt und bin zur Sicherheit noch mal alle Schritte durchgegangen.
        Spamassasin wurde mit 4 der auf der Seite untroubled.org gelisteten Spamarchiven angelernt. Darüber hinaus packe ich immer meine aktuellen Spams in eine mbox Datei und lerne diese manuell an. Das quittiert er auch ordentlich, so dass ich glaube dass das funktioniert.
        Nur, dass anscheinend die Mails nicht gecheckt werden.
        Seit der SASL Integration werden leider keine Mails mehr zugestellt.

        mail.log zeigt folgende Einträge:

        Nov 30 16:08:03 vserver postgrey[3211]: action=greylist, reason=early-retry (52s missing), client_name=Mail.wieland-antriebstechnik.de, client_$
        Nov 30 16:08:03 vserver postfix/smtpd[7647]: NOQUEUE: reject: RCPT from Mail.wieland-antriebstechnik.de[195.145.21.122]: 450 4.2.0 <cremerma@su$
        Nov 30 16:08:03 vserver postfix/smtpd[7647]: disconnect from Mail.wieland-antriebstechnik.de[195.145.21.122]
        Nov 30 16:09:03 vserver postfix/smtpd[7647]: connect from Mail.wieland-antriebstechnik.de[195.145.21.122]
        Nov 30 16:09:04 vserver postgrey[3211]: action=pass, reason=triplet found, delay=309, client_name=Mail.wieland-antriebstechnik.de, client_addre$

        das sieht ja erst mal so aus, als würde greylist funktionieren und erst bei mehrmaligem Versuch die Verbindung zulassen.

        Danach hängt es aber:

        Nov 30 16:09:04 vserver postfix/qmgr[7268]: 3B3974AD6F: from=, size=19518, nrcpt=1 (queue active)
        Nov 30 16:09:04 vserver postfix/qmgr[7268]: warning: connect to transport private/smtp-amavis: Connection refused

        Beste Grüße
        M. Cremer

        • Läuft der Amavis Dienst den und ist dieser so Konfiguriert, dass er Verbindungen entgegen nehmen kann?

          Bei mir verhält sich der Mailserver wie folgt beim erhalt einer E-Mail von einem bis dato unbekannten Absender:

          Dec  2 09:34:35 lvps92-51-151-150 postfix/smtpd[21137]: connect from h2306620.stratoserver.net[81.169.166.247]
          Dec  2 09:34:35 lvps92-51-151-150 postgrey[960]: action=greylist, reason=new, client_name=h2306620.stratoserver.net, client_address=81.169.166.247, sender=www-data@h2306620.stratoserver.net, recipient=sebastian@kruse-familie.eu
          Dec  2 09:34:35 lvps92-51-151-150 postfix/smtpd[21137]: NOQUEUE: reject: RCPT from h2306620.stratoserver.net[81.169.166.247]: 450 4.2.0 : Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/kruse-familie.eu.html; from= to= proto=ESMTP helo=
          Dec  2 09:34:35 lvps92-51-151-150 postfix/smtpd[21137]: disconnect from h2306620.stratoserver.net[81.169.166.247]
          
          Dec  2 09:37:55 lvps92-51-151-150 postfix/anvil[21139]: statistics: max connection rate 1/60s for (smtp:81.169.166.247) at Dec  2 09:34:35
          Dec  2 09:37:55 lvps92-51-151-150 postfix/anvil[21139]: statistics: max connection count 1 for (smtp:81.169.166.247) at Dec  2 09:34:35
          Dec  2 09:37:55 lvps92-51-151-150 postfix/anvil[21139]: statistics: max cache size 1 at Dec  2 09:34:35
          
          Dec  2 09:44:25 lvps92-51-151-150 postfix/smtpd[22262]: connect from h2306620.stratoserver.net[81.169.166.247]
          Dec  2 09:44:25 lvps92-51-151-150 postgrey[960]: action=pass, reason=triplet found, delay=590, client_name=h2306620.stratoserver.net, client_address=81.169.166.247, sender=www-data@h2306620.stratoserver.net, recipient=sebastian@kruse-familie.eu
          Dec  2 09:44:25 lvps92-51-151-150 postfix/smtpd[22262]: 466BD203B1: client=h2306620.stratoserver.net[81.169.166.247]
          Dec  2 09:44:25 lvps92-51-151-150 postfix/cleanup[22266]: 466BD203B1: message-id=<20151202083433.C41A4542363@h2306620.stratoserver.net>
          Dec  2 09:44:25 lvps92-51-151-150 postfix/qmgr[2444]: 466BD203B1: from=, size=1283, nrcpt=1 (queue active)
          Dec  2 09:44:25 lvps92-51-151-150 postfix/smtpd[22262]: disconnect from h2306620.stratoserver.net[81.169.166.247]
          Dec  2 09:44:26 lvps92-51-151-150 postfix/smtpd[22271]: connect from localhost[127.0.0.1]
          Dec  2 09:44:26 lvps92-51-151-150 postfix/smtpd[22271]: 86B4B206A0: client=localhost[127.0.0.1]
          Dec  2 09:44:26 lvps92-51-151-150 postfix/cleanup[22266]: 86B4B206A0: message-id=<20151202083433.C41A4542363@h2306620.stratoserver.net>
          Dec  2 09:44:26 lvps92-51-151-150 postfix/qmgr[2444]: 86B4B206A0: from=, size=2042, nrcpt=1 (queue active)
          Dec  2 09:44:26 lvps92-51-151-150 amavis[30754]: (30754-01) Passed CLEAN {RelayedInbound}, [81.169.166.247]:48791 [81.169.166.247]  -> , Queue-ID: 466BD203B1, Message-ID: <20151202083433.C41A4542363@h2306620.stratoserver.net>, mail_id: BB38JUV3ZJhx, Hits: -0.008, size: 1283, queued_as: 86B4B206A0, 1220 ms
          Dec  2 09:44:26 lvps92-51-151-150 postfix/smtp[22267]: 466BD203B1: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.3, delays=0.08/0.02/0.01/1.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 86B4B206A0)
          Dec  2 09:44:26 lvps92-51-151-150 postfix/qmgr[2444]: 466BD203B1: removed
          Dec  2 09:44:26 lvps92-51-151-150 postfix/pipe[22272]: 86B4B206A0: to=, relay=zarafa, delay=0.25, delays=0/0/0/0.24, dsn=2.0.0, status=sent (delivered via zarafa service)
          Dec  2 09:44:26 lvps92-51-151-150 postfix/qmgr[2444]: 86B4B206A0: removed
          
          Dec  2 09:47:45 lvps92-51-151-150 postfix/anvil[22264]: statistics: max connection rate 1/60s for (smtp:81.169.166.247) at Dec  2 09:44:25
          Dec  2 09:47:45 lvps92-51-151-150 postfix/anvil[22264]: statistics: max connection count 1 for (smtp:81.169.166.247) at Dec  2 09:44:25
          Dec  2 09:47:45 lvps92-51-151-150 postfix/anvil[22264]: statistics: max cache size 1 at Dec  2 09:44:25
          
          Dec  2 09:49:26 lvps92-51-151-150 postfix/smtpd[22271]: timeout after END-OF-MESSAGE from localhost[127.0.0.1]
          Dec  2 09:49:26 lvps92-51-151-150 postfix/smtpd[22271]: disconnect from localhost[127.0.0.1]

          Und der Mail-Header dazu sieht anschließend wie folgt aus:

          Return-Path: 
          Delivered-To: sebastian@kruse-familie.eu
          Received: from localhost (localhost [127.0.0.1])
          	by lvps92-51-151-150.dedicated.hosteurope.de (Postfix) with ESMTP id 86B4B206A0
          	for ; Wed,  2 Dec 2015 09:44:26 +0100 (CET)
          X-Virus-Scanned: Debian amavisd-new at kruse-familie.eu
          X-Spam-Flag: NO
          X-Spam-Score: -0.008
          X-Spam-Level:
          X-Spam-Status: No, score=-0.008 required=5
          	tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001,
          	T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
          Received: from lvps92-51-151-150.dedicated.hosteurope.de ([127.0.0.1])
          	by localhost (lvps92-51-151-150.dedicated.hosteurope.de [127.0.0.1]) (amavisd-new, port 10024)
          	with ESMTP id BB38JUV3ZJhx for ;
          	Wed,  2 Dec 2015 09:44:25 +0100 (CET)
          X-Greylist: delayed 590 seconds by postgrey-1.34 at lvps92-51-151-150.dedicated.hosteurope.de; Wed, 02 Dec 2015 09:44:25 CET
          Received: from h2306620.stratoserver.net (h2306620.stratoserver.net [81.169.166.247])
          	by lvps92-51-151-150.dedicated.hosteurope.de (Postfix) with ESMTP id 466BD203B1
          	for ; Wed,  2 Dec 2015 09:44:25 +0100 (CET)
          Received: by h2306620.stratoserver.net (Postfix, from userid 33)
          	id C41A4542363; Wed,  2 Dec 2015 09:34:33 +0100 (CET)
          To: sebastian@kruse-familie.eu
          Subject: Test-E-Mail
          X-PHP-Originating-Script: 33:Sendmail.php
          X-Originating-IP: 46.21.15.2
          From: something@trash-mail.com
          Reply-To: something@trash-mail.com
          Date: Wed, 02 Dec 2015 09:34:33 +0100
          Content-Type: multipart/alternative;
           boundary="=_33e1055f96f42ef0916301d3b7fa9866"
          MIME-Version: 1.0
          Message-Id: <20151202083433.C41A4542363@h2306620.stratoserver.net>

          Warum es nun aber zu dem „Connection refused“-Fehler kommt, kann ich AdHoc nicht genau sagen.

          • Hallo Sebastian,

            erneut besten Dank für die schnelle und tolle Unterstützung.
            Manchmal muss man einfach mal einen Schritt zurück gehen, um vorwärts zu kommen.
            Wahrscheinlich habe ich mir mit der ganzen Rumprobiererei in irgend einer config einen Fehler eingebaut. (vermutlich master.cf)
            habe heute postfix deinstalliert, /etc/postfix/ gelöscht und dann neu installiert.
            Dann bin ich Deine Anleitung noch mal durchgegangen. und schon kommen meine Mails wieder an.
            Nun habe ich auch in den logs jeweils eine Zeile für amavis:……Passed CLEAN {RelayedInbound},……..
            Dein Tip mit dem Mailheader war sehr hilfreich.
            Hier finde ich z.B. folgenden Text:

            -Virus-Scanned: Debian amavisd-new at susanneundmario.de
            X-Spam-Flag: NO
            X-Spam-Score: 0.104
            X-Spam-Level:
            X-Spam-Status: No, score=0.104 required=5 tests=[DC_PNG_UNO_LARGO=0.001,
            DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, TVD_RCVD_SPACE_BRACKET=0.001,
            T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001]
            autolearn=no

            Sieht also aus, als würden die Mails gecheckt. Müsste dann ja bald einige ******* SPAM ****** in meinem Junk finden

            Finde auch jede menge SASL Meldungen über unauthorisierte Loginversuche. War anscheinend wirklich eine gute Idee, das nachzuinstallieren.

            Ich hatte noch eine Warnung, weil ich in der /etc/postfix/main.cf meinen server sowohl in mydestination als auch in den zarafa virtual_mailbox_domains definiert hatte.

            Darüber hinaus meckert postfix noch folgendes

            warning: support for restriction „check_relay_domains“ will be removed from Postfix; use „reject_unauth_destination“ instead

            Da scheint etwas doppelt gemoppelt in der main.cf zu sein.
            Habe den check_relay_domains Eintrag mal entfernt. Hoffe das hilft.

            Schöne Grüße
            Mario

  6. Hallo Sebastian,

    vielen Dank für die Anleitung. Ich habe bereits eine bestehende Zarafa-Installation (6.x) auf Debian Squeeze.
    Da ich einen neuen Rootserver miete werde ich das ganze dort mit Zarafa 7.x unter Debian Jessie neu aufsetzen, nach Deiner Anleitung.
    Nun meine Frage: hast Du einen Tipp wie ich die alten Postfächer auf die neue Installation übertragen kann?

    Vielen Dank im Voraus und Grüße

    Daniel

  7. Hi Sebastian, Hi Community!

    Danke erstmal für die hilfreiche Anleitung. Hab meinen neuen Mail-Server nach deinem Tutorial aufgesetzt, lief eigentlich alles schnell und problemlos. Allerdings hab ich ein kleines Problem gefunden, dass ich trotz Google-Recherche und herumprobieren nicht lösen konnte. Sende ich eine Mail an ein existierendes Mail-Postfach, dann klappt alles wie geschmiert. Habe dann spaßeshalber und testweise eine Mail an ein nichtexistierendes Postfach geschickt und dadurch zufällig rausgefunden dass es anscheinend noch ein Rechteproblem in meinem Setup gibt. Ich bekam folgende Fehlermeldung, gleichlautend sowohl als Return-E-Mail als auch in der mail.log:

    ————————————

    internal software error. Command output: Unable to open logfile ‚/var/log/zarafa/dagent.log‘ as user ‚vmail‘ Not enough permissions to append logfile ‚/var/log/zarafa/dagent.log‘. Reverting to
    stderr.

    ————————————

    Habe wie gesagt gegoogelt und nur eine Lösung gefunden, nämlich in der Datei /etc/zarafa/server.cfg in der zeile „local_admin_users“ den User vmail hinzuzufügen. Das habe ich versucht, den Zarafa-Server natürlich auch neu gestartet, leider ohne Ergebnis.
    Hab dann noch alles mögliche versucht, nichts hat geholfen, nichtmal die Permissions von dagent.log auf 777 zu stellen.

    Braucht der User vmail noch erweiterte Rechte um was ins Logfile schreiben zu können?

    Falls irgendjemand einen Tipp für mich hat wär ich sehr dankbar.

    Liebe Grüße von Daniel!

    • Das Problem bei dir ist nicht die File-Permission, sondern dass das File einen höheren User als vmail gehört. Die Rechte sollten im übrigen niemals auf 777 gestellt werden. Es gibt so gut wie nie einen Fall der dieses Erfordert / Gerechtfertigt. Für dein Problem gibt es zwei Lösungen. 1. Dafür sorgen, dass die Datei mit den richtigen User geschrieben wird und kein anderer dort schreibt (das wäre die wohl beste alternative). 2. Den Benutzer vmail in den Rechten erhöhen, evtl. sogar zum Sudo’er machen ohne Login Erlaubnis (nicht so optimal da dadurch dein Mail-User Administrator wird).

      Leider sorgt die hervorragende Kabel DE 200.000er Leitung gerade dafür das ich mal wieder mich nicht per SSH verbinden kann, sonst hätte ich dir sagen können womit der Log-File bei mir bearbeitet wird (welcher User, etc.).

    • Hi,

      ich habe das Problem auch gehabt und wie folgt gelöst. Mein System ist Debian 8 und Zarafa 7.2 Comunity.
      Mein Problem war das beschriebene, allerding mit dem User zarafa (warum auch immer)

      temporary failure. Command output: Unable to open logfile ‚/var/log/zarafa/dagent.log‘ as user ‚zarafa‘ Not enough permissions to append logfile ‚/var/log/zarafa/dagent.log‘. Reverting to stderr.

      Da ich Probleme mit der Installation hatte, habe ich /etc/zarafa/dagent.cfg die Zeile „#log_file = /var/log/zarafa/dagent.log“ einkommentiert, also „log_file = /var/log/zarafa/dagent.log“. Nachdem ich die wieder auskommentiert habe ist die Fehlermeldung mit der Permission weg. Alle vorherigen Versuche mit chmod 777 und was sonst so im Web und hier zu finden ist, sind auch bei mir fehlgeschlagen.

      ERGÄNZUNG:

      Da das Problem oft zusammen mit einem Zustellungsproblem von postmaster@domain.xy (oder webmaster etc.) erwähnt wird, hier noch die Erweiterung dazu.
      In der Anleitung hier steht für die main.cf

      virtual_alias_maps = hash:/etc/aliases

      Das ging bei mir so aber nicht, obwohl ich in der /etc/aliases die Zuordnung „postmaster: zarafa-user“ drin hatte.
      Ich habe nun nach folgender Anleitung umgestellt: http://www.berkes.ca/guides/postfix_virtual.html

      /etc/postfix/virtual:
      postmaster@domain.xy zarafa-user

      Dann „postmap /etc/postfix/virtual“ und „services postfix restart“

      So funktioniert bei mir auch postmaster@domain.xy.
      Über /etc/postfix/virtual wird diese Mail Adresse so in den zarafa-user übersetzte und an zarafa übergeben.

      Die /etc/aliases ist nun weitestgehend überflüssig.
      Lediglich, wenn man Mails nur an „postmaster“, oder „root“ (also ohne @domain.xy) sendet (z.B. auf der lokalen Commandline), wird /etc/aliases dann noch verwendet.

      Warum?: http://serverfault.com/questions/644306/confused-about-alias-maps-and-virtual-alias-maps

      • Hallo Mike, wie hast du die Zarafa 7.2 Version installiert. Bzw. welche Pakete hast du benutzt?

        Ich würde gerne auch die neuste Zarafa Version einsetzen habe aber in der Vergangenheit immer nur mit dem install.sh script welches bei lag die Installation vorgenommen. Vielleicht kannst du mir dabei helfen?

        Gruß Daniel

  8. Hallo Sebastian!

    Bin beeindruckt wie schnell du auf meinen Kommentar reagiert hast. Danke dafür.

    Dass man ein File nicht auf 777 stellen sollte weiß ich, hab das ja nur aus debugging-Gründen gemacht um zu testen ob das Logfile dann beschrieben werden kann. Nutzte aber wie gesagt eh nix.

    Du meintest:

    1. Dafür sorgen, dass die Datei mit den richtigen User geschrieben wird und kein anderer dort
    schreibt (das wäre die wohl beste alternative).

    Das versteh ich grade nicht ganz. Könntest du mir das vielleicht nochmal genauer erklären, sobald dein Internet wieder funktioniert? ^^

    Außerdem: Ist es nicht eigentlich so dass die Logfiles vom syslog bzw heutzutage eher von systemd geschrieben werden? Der müßte ja anundfürsich genug rechte haben um im /var/log alles zu bearbeiten. Hab übrigens vorhin vergessen zu erwähnen dass ich das Ganze auf Debian 8 laufen habe.

    LG!

    • Entschuldige die verspätete Antwort, war gestern Abend schon im Bett und habe jetzt erst Mittagspause. Normal sollte das Logging über das System gehandhabt werden. Laut deiner Fehlermeldung versucht jedoch der Benutzer „vmail“ das Log zu modifizieren. Ich hatte das ganze gerade mal auf meinen Server nachgestellt (der exakt nach der Anleitung konfiguriert worden ist) und dort wird sämtliches logging über das System bzw. root getätigt. Hast du schon einmal versucht in der main.cf und master.cf nach den Text „vmail“ zu suchen? Die Anzahl der Einträge müsste überschaubar sein und auch ob diese so sein sollten.

      • Hi!

        Das hab ich jetzt gecheckt. In der main.cf kommt vmail gar nicht vor, ist ja auch in deinem Tutorial nirgens so angegeben. In der master.cf kommt vmail seltsamerweise in 2 Zeilen vor, einmal natürlich in der Zeile, die in deinem Tutorial angegeben ist:

        —————————–

        zarafa unix – n n – 10 pipe
        flags=DRhu user=vmail argv=/usr/bin/zarafa-dagent -R ${recipient}

        —————–

        Vmail kommt noch ein zweites mal vor, und zwar weiter oben in der master.cf.

        ——————–
        # maildrop unix – n n – – pipe
        # flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}

        —————————

        Das ist allerdings Standard in Debian, hab das mit der original-Master.cf gegengecheckt. Wundert mich eigentlich, denn ein User vmail existiert doch in einem Standard-Debian-System gar nicht. Glaube jedenfalls dass man die Zeile auskommentieren kann, da der MDA Maildrop eh nicht gebraucht wird, wir benutzen ja zarafa-dagent. Hab das jetzt getan und es scheint immernoch alles zu funktionieren.

        Wie dem auch sei, das Problem mit den Vmail-Permissions besteht weiterhin. Hast du schonmal probiert was bei dir passiert wenn du eine Mail an einen Mailbox schickst die es auf deinem Server gar nicht gibt?

        LG!

        • Das dort zwei Einträge sind ist schon richtig. Und wenn du die Zeile mal genau liest siehst du auch dein Problem. Bei „maildrop“ (sprich unzustellbar) soll mit den Benutzer „vmail“ die Ablehnung und das logging erfolgen. Ich dachte eigtl. ich hätte das hier im Beitrag schon angepasst aber anscheinend bin ich da drüber hinweg gekommen (nach der Anpassung hier oder der Benutzer Zuordnung vom dagent.log zu vmail kommen noch ein paar andere Fehler). Ich werde morgen mal meine Notizen raus suchen (oder falls ich die nicht finde unseren Linux Experten fragen, was wir da damals gemacht hatten) und anschließend den Beitrag anpassen.

  9. Hi Sebastian!

    Jetzt schreib ich gleich nochmal wegen ner anderen Sache die mich noch interessieren würde: So wie ich dein Setup verstehe ist es wohl nicht nötig für jeden Zarafa-Nutzer zusätzlich auch noch einen Unix-Nutzer anzulegen, so wie du das in deinem Tutorial machst. Zarafa ist in deinem Setup doch so konfiguriert dass er das Datenbank-Plugin zur User-authentifizierung verwendet und nicht PAM. Hab grad einen neuen Zarafa-User angelegt, der empfängt problemlos E-Mails ohne dass es einen entsprechenden Linux-User gibt. Auch das einloggen über die Webapp klappt problemlos. Drum meine Frage: Wozu die Linux-User? Haben die einen Sinn den ich noch nicht durchschaut habe?

    LG!

    • Solange du kein LDAP Verwendest, verwaltet Postfix die Benutzer über das System (unabhängig ob dort eine Zarafa Oberfläche ist). Probleme werden auftreten, wenn du mit einen externen Client wie z.B. Outlook oder Thunderbird ohne ein Zarafa-Plugin dich ganz normal zum Mailserver verbinden möchtest. Hier wird dich Postfix zurückweisen weil er den User nicht kennt (zumindest würde ich dies so erwarten).

      • Hi!

        Nein, ich habs jetzt extra nochmal getestet, obwohl ich mir eigentlich schon vorher sicher war. Die Linux-User brauchst du in deinem Setup nicht. Standardmäßig nutzt Zarafa das Plugin DB, was du in deinem Setup auch nicht veränderst. Siehe die Zeile „User_plugin“ in der /etc/zarafa/server.cfg. Wenn der Eintrag darin auf DB steht dann macht Zarafa das gesamte User-Management intern über die eigene Mysql-Datenbank. Auch das einloggen z.B. per Thunderbird hat damit nichts zu tun. Habs grad ausprobiert, den User einfach über zarafa-admin anzulegen genügt vollkommen, er kann sowohl per pop3/imap Mails empfangen als auch per smtp wellche versenden. Du kannst das ganze auch auf Linux auslagern, wenn du willst. Dazu müßtest du den o.g. Eintrag von „db“ auf „linux“ setzen, dann holt er sich die Daten vom Pam. Mit Ldap is es das gleiche, dafür wär das Plugin „ldap“ da.

        LG!

        • Bedingt das ich primär als C# Entwickler tätig bin, weiß ich das ich mich mit dem .NET MailClient nicht verbinden kann ohne LDAP oder die lokalen Benutzer. Eigentlich müsstest du bei der Verwendung eines lokalen Mail-Programms (nicht die Weboberfläche) die gleichen Probleme haben beim Versenden (außer du verwendest die vorgesehenen Zarafa-Plugins für z.B. Outlook).

  10. Hallo Sebastin,

    ich wollte einfach nur mal Danke sagen! Ohne die Anleitung hätte ich das nicht hinbekommen!
    Hier noch meine Egänzungen für Debian 8 mit Zarafa 7.2 Community:

    1. Ich hatte große Probleme mit der Installation von avavis/spamasassin. Das lag wohl daran, dass ich in /etc/hostname und etc/mailname ncht den FQDN des Servers drin hatte. Also das am besten driekt am Anfang durchführen. Dann ging es.

    2. gleiches gilt für myhostname in postfix->main.cf nach postfix install.

    3. bei Zarafa 7.2 ging die Installation nicht über install.sh sondern:
    dpkg -i *.deb
    apt-get install -f

    4. nano /etc/zarafa/server.cfg und dort MYSQL-PW eintragen nicht vergessen (Hast du ja auch schon erwähnt).

    5. fail2ban hat bei mir einen Fehler geschmissen: nano /etc/fail2ban/filter.d/postfix-sasl.conf -> einfügen: ignoreregex =

    Vielleicht hilft es ja jemandem…

    Gruß

  11. Bei mir lief die Installation zwar reibungslos durch, aber zarafa startet nicht nach einem reboot des Servers, obwohl alle scripte in rc2.d vorhanden sind …
    Es sind auch nirgends Fehlermeldungen zu erkennen, die erkennen lassen würden, warum die scripte nicht starten.

    Jemand eine Idee?

  12. Hallo schönes Howto, hat eigentlich alles gut geklappt, nur wenn ich mich auf dem zarafa server einloggen will mit http://localhost/webapp dann kommt da eine Ausschrift von wegen irgendeinem Problem mit XML, wahrscheinlich kann der Browser kein Stylesheet finden … hab ich da was übersehen??

    Mit dieser XML-Datei sind anscheinend keine Style-Informationen verknüpft. Nachfolgend wird die Baum-Ansicht des Dokuments angezeigt.



    SOAP-ENV:Client
    HTTP GET method not implemented

  13. Hallo,

    super Anleitung! Vielen Dank dafür. Allerding habe ich noch ein kleines Problem und mir gehen die Ideen aus. Vielleicht habt ihr noch eine.
    Ich brauche für die smtp Authentifizierung nicht nur „PLAIN LOGIN“ sondern auch CRAM-MD5. Das alte SQL-Statement für die „smtpd.conf“ funtioniert leider nicht mehr:

    sql_select: SELECT DISTINCT `objectid` FROM `objectproperty` WHERE objectid = (SELECT `objectid` FROM `objectproperty` WHERE `propname` = ‚loginname‘ AND `value` = ‚%u‘) AND `propname` = ‚password‘ AND `value` = CONCAT(SUBSTR(`value`, 1, 8), MD5(CONCAT(SUBSTR(`value`, 1, 8), ‚%p‘)))

    Es kommt dann der Fehler:

    sql plugin create statement from userPassword xxxxxx xxxx
    Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin doing query SELECT DISTINCT `objectid` FROM `objectproperty` WHERE objectid = (SELECT `objectid` FROM `objectproperty` WHERE `propname` = ‚loginname‘ AND `value` = ‚xxxxxx‘) AND `propname` = ‚password‘ AND `value` = CONCAT(SUBSTR(`value`, 1, 8), MD5(CONCAT(SUBSTR(`value`, 1, 8), ‚userPassword‘)));
    Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin: no result found
    Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin create statement from cmusaslsecretCRAM-MD5 xxxxxx xxxx
    Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin doing query SELECT DISTINCT `objectid` FROM `objectproperty` WHERE objectid = (SELECT `objectid` FROM `objectproperty` WHERE `propname` = ‚loginname‘ AND `value` = ‚xxxxxx‘) AND `propname` = ‚password‘ AND `value` = CONCAT(SUBSTR(`value`, 1, 8), MD5(CONCAT(SUBSTR(`value`, 1, 8), ‚cmusaslsecretCRAM-MD5‘)));
    Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin: no result found
    Jan 4 12:30:41 mx01 postfix/smtpd[6505]: commit transaction
    Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin Parse the username xxxxxx
    Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin try and connect to a host
    Jan 4 12:30:41 mx01 postfix/smtpd[6505]: sql plugin trying to open db ‚xxxxx‘ on host ‚127.0.0.1‘

    Da scheind an der Datenbankabfrage etwas nicht zu passen. Gibt es noch einen anderen Weg eine „CRAM-MD5“ Authentifizierung für smtp (Postfix) hin zu bekommen?

    VG. Sven

Hinterlasse ein Kommentar.

CyberChimps

Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir Cookies verwenden. Informationen zum Datenschutz

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen