Reichis Blog

… beispielhaft erläutert am MTA Postfix.

Einleitende Anmerkungen und Beweggründe

Ergänzend zu meinem kleinen Howto für Zarafa + Courier + Postfix will ich mit diesem Blogeintrag erläutern wie man Postfix (ganz generell; ohne  abhängig von der Zarafa-Integration zu sein) um einen angenehm zu benutzenden Spam und Virenfilter ergänzen kann.
Obwohl ich eigentlich nur zwei aktive Mailaccounts habe um sprengt mein jährliches Volumen an Spammails mittlerweile die Grenze von ca. 100k Nachrichten. In Summe haben alle Regeln meines SpamAssassin bereits >1.000.0000 mal getroffen und mal Punkte verteilt.

Da die Lust Spammails aufwändig durch manuelles verschieben in einen speziellen Ordner dem Spamassassin zum Training “vorzuwerfen” äußerst gering war, habe ich auf die Suche nach einer praktikablen und gleichzeitig effizienten Möglichkeit zur Spamfilterung umgesehen und stieß dabei vor ca. 3 Jahren an meiner FachHochschule auf Maia Mailguard.

Kurz zusammengefasst bietet Maia Mailguard benutzerindividuelles Spam und Virusmanagement auf Webbasis mit Hilfe von bekannten Open-Source Anwendungen wie zum Beispiel Spamassassin (folgend mit SA abgekürzt) als Spamfilter und/oder clamav als Virenscanner.

Obwohl ich lange eigentlich kein direkter Freund von DNS-Blacklists wie beispielsweise spamhaus.org war (ich hatte mehrfach damit zu kämpfen ein NATtendes System welches >1000 Stundenten mit Internet versorgte wieder von selbigen runter zu bekommen) muss ich mittlerweile gestehen, dass sie sehr hilfreich dabei sind einen wirklich großen Teil der Spammails (bei mir nach bisherigen Erfahrungen geschätzte 30-50%) bereits beim ersten Aufschlagen am MTA abzulehnen und damit ein Mailsystem bedeutend zu entlasten, denn jede Spam/Virusmail die durch die komplette MTA->SA->Clamav->MTA->Postfach Quarantäne Queue läuft verschwendet letztenendes kostbare CPU-Zeit und Plattenplatz (mal mehr, mal weniger).

Somit ergibt sich folgender technischer Aufbau

• Postfix als MTA
• spamhaus.org, abuseat.org und sorbs.net als Blacklists
• Maia Mailguard als Spam und Virusmanagement

Ausgehend von der Postfixkonfiguration aus meinem vorletzten Blogeintrag sind für die Abfrage der Blacklists folgende Einträge in der main.cf zu ergänzen (die Ergänzungen sind unterstrichen)

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        reject_rbl_client sbl.spamhaus.org,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client dul.dnsbl.sorbs.net

Ich werde nicht auf die Konfiguration von Maia Mailguard eingehen. Eine ausführliche Installationsanleitung liegt Maia bei weshalb ich auf diesbezügliche Erläuterungen hier verzichte.

Erstmal sollte man Maia soweit fertig einrichten, dass alles bis auf die letztliche Filterung der eingehenden Mails einwandfrei funktioniert.

Dann noch folgende Configeinträge für Postfix - unter der Annahme, dass amavis auf Port 10024 lauscht und die Mails auf Port 10025 wieder zurück an dem MTA liefern will.

in der main.cf

content_filter = amavis:[127.0.0.1]:10024

in der master.cf

amavis    unix  -       -       -       -       2       smtp
        -o smtp_data_done_timeout=5000
        -o smtp_send_xforward_command=yes
        -o disable_dns_lookups=yes

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_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks=127.0.0.0/8
        -o strict_rfc821_envelopes=yes

Das war’s schon!
Zusätzlich habe ich noch einen Mailaccount welcher in Maia als Spamtrap definiert wurde. Dadurch erhöht sich die Lernrate des SA um ein Vielfaches.

Ich musste leider feststellen, dass sich Nokias Mail for Exchange und lighttpd mit z-push als ActiveSync-Replacement wenig bis garnicht vertragen.

Nachdem ich kürzlich - wie einen Artikel vor diesem zu erlesen - Zarafa installiert habe, hat z-push zwar problemlos mit Windows Mobile, nicht aber mit Nokias Mail for Exchange (MfE) funktioniert.

Nach Analyse des lighttpd access.log fiel folgende Zeile auf

77.24.143.4 - - [29/Sep/2008:18:00:38 +0200] “POST /Microsoft-Server-ActiveSync?User=stephan&DeviceId=IMEI12345678901234&DeviceType=IMEI12345678901234&Cmd=FolderSync HTTP/1.1″ 417 0 “-” “-”

wenn man nun mal Google die Suchmaschine seiner Wahl dazu befragt stellt sich folgendes heraus:
Lighttpd lehnt HTTP-POST Anfragen grundsätzlich mit Fehler 417 ab wenn deren Header den Parameter “Expect” enthält - genau diese Konstellation schickt MfE…
Ich mag ja meinen lighty wirklich gerne, vor allem weil ich mit dem Stil der Config richtig gut zurecht komme… aber dieses Problem lässt mich doch stark darüber nachdenken wieder zurück zum Apachen zu wechseln.

Als temporäre Lösung lauscht nun erstmal der Apache auf einem anderen Port und versorgt mein Handy per z-push und MfE mit Mails, Terminen und Kontakdaten.

Nachdem kürzlich die Meldung durch die Presse ging, dass der Zarafa Groupware-Server unter der Affero GPLv3 als Open Source Projekt veröffentlicht wurde habe ich mich kurzerhand dazu entschieden das doch direkt mal ausprobieren zu wollen.

Für alle die mit der Marke Zarafa garnichts anfangen können will kurz erläutern was das eigentlich ist.
Zarafa ist eine Groupware welche viele vom Exchange-Server bekannte Features bietet. Dazu gehören neben den üblichen Dingen wie E-Mail (zarafa ist KEIN MTA!), Kontakten, Kalendern und Aufgaben auch Dinge wie z.B. öffentliche Ordner oder auch eine sehr gut funktionierende MAPI-Implementierung. Auch Microsoft-ActiveSync PUSH ist mit Hilfe der schon seit längerem aus dem Zarafa-Projekt heraus enstandenen und unter einer Open-Source Lizenz veröffentlichten freien Implementierung z-push schnell und (je nach Client) recht problemlos möglich!
Am Wichtigsten war für mich persönlich jedoch, dass Zafara Webaccess - wie der Name schon ahnen lässt - in seiner Funktionalität und Bedienbarkeit doch sehr stark an Outlook WebAcces aka OWA erinnert.
Man kann ja gegen Microsoft wettern soviel man will aber an OWA kam bisher keine mir bekannte Open-Source Lösung auch nur ansatzweise heran.
Mal im Ernst: Gibt es irgendeinen Menschen auf der Erde der freiwillig und dauerhaft horde einsetzen will? Zumindest mein Drang zur Perversion ist da nicht groß genug!

Nach einer “Previewinstallation” in einem CoLinux mit Debian Etch habe ich mich dann recht schnell entschieden, dass ich diese Groupware in Zukunft gerne für meine Privaten Mails, Termine und Kontakte nutzen will.

Bisher setzte ich beim Mailserver auf Postfix + Postfixadmin mit Maia Mailguard als Spam und Virus Management System und Courier als imap/pop3 Server .

Die Migration auf zarafa gestaltete sich dabei denkbar einfach.
Erstmal alle bisherigen Serverdienste beendet um während der Änderungen keine Mails in ein nach der Installation totes Postfach zu kriegen.

Dann auf der Zarafa Community Seite die Debian Etch zarafa*.debs heruntergeladen und installiert.
Einige Abfragen (mysql user/pw etc) später ist Zarafa dann auch schon vollständig installiert. Kurz noch einen ersten User mit zarafa-admin anlegen und schon kann man sich via webinterface (welches standardmäßig nach /var/www/webaccess installiert kopiert wird) einloggen.
Damit auch die Mails dort landen wo man sie haben will - in der mysql-Datenbank von zarafa und nicht in den bisherigen mailboxen auf dem Filesystem - muss Postfix noch eine neue Config verpasst werden.

Folgende Konfigurationseinträge sind zu machen:

main.cf

mydomain = reichholf.net
myhostname = host
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf
myorigin = /etc/mailname
mydestination = $myhostname, $myhostname.local, localhost, $mydomain
mynetworks = 127.0.0.0/8
mailbox_transport = zarafa:
zarafa_recipient_limit = 1
inet_interfaces = all

mysql-aliases.cf

# The user name and password to log into the mysql server.
user = root
password = zarafa
hosts = 127.0.0.1
dbname = zarafa
# For Postfix 2.2 and later The SQL query template.
# See mysql_table(5) for details.
query = select value from objectproperty where objectid=(select objectid from objectproperty where value='%s' limit 1) and propname='loginname';

und dann noch der Mailbox Transport zarafa in der master.cf

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

Das war’s schon!

Postfix neustarten, testmail senden - DAD GEEEEEEEEEEEEEEEEEEEEEEEEHT!
Da ich bereits eine Integration für Maia Mailguard in meiner bisherigen Postfix-Installation hatte habe ich diese auch für Zarafa übernommen - nach mittlerweile ca. 125000 trainierten Mails ist die Trefferquote meines Mailguards mittlerweile wirklich gut (~96% Total - Tendenz steigend!)

Die Installation von z-push gestaltet sich ähnlich simpel. Konfigurieren muss man mit Zarafa als Backend auf Seiten von z-push garnichts, lediglich ein Redirect muss auf dem Webserver eingerichtet werden (/Microsoft-Server-ActiveSync => $webroot/z-push/index.php). PDA anwerfen, testen - geht auch!

Das Einzige was jetzt noch zu tun war war die Erstellung diverser self-signed SSL-Certs und schon war der Groupware-Server vollständig installiert.

Gesamtdauer der Installation: ca. 2h

PS:
Da die Übergabe der Mails an Zarafa über den zarafa-dagent erfolgt kann man auch jederzeit völlig problemlos mit fetchmail arbeiten um eventuell Mails aus externen Mailaccounts zu sammeln - ich persönlich bevorzuge es jedoch meinen eigenen MX zu betreiben.