Mac als Mail-Server und Spamfilter

Inhaltsverzeichnis

Der Reiz eines hauseigenen Mail-Servers, der etwa WG-Mitbewohner oder Mitarbeiter kleiner Unternehmen versorgt, liegt in der ungehinderten Erweiterbarkeit und in höherem Komfort. Bei geschickter Auswahl und Konfiguration der Komponenten legt man sich zusätzlich eine sehr wirksame Waffe gegen Spam zu. Dies verringert die Datenmenge beim Mail-Abruf, was besonders mobilen Geräten wie dem iPhone zugutekommt. Und man verwandelt mit geringem Aufwand spartanische POP3-Freemail-Angebote in komfortable IMAP-Konten.

Ist der Server komplett, eignet er sich für den Abruf, die Spam-Filterung und Lagerung aller Mails von Freemail-Konten wie GMX, aber auch von Mails an eine DynDNS-Domain. Wenn sichergestellt ist, dass der Server dauerhaft läuft, kann man darauf auch eine eigene Domain wie macosx.homeunix.net inklusive zugehöriger Mail-Konten wie joe.user@macosx.homeunix.net einrichten – ohne die Freemailer-Beschränkungen hinsichtlich der Mailanzahl oder des Mail-Volumens. Die Umsetzung der Anleitung erfordert diverse Arbeiten auf der Kommandozeile; vor der Bedienung des C++-Compilers sollte man ebenfalls keine Scheu haben.

Für alle genannten Funktionen muss man zunächst den Inhalt von zum Beispiel einem GMX-Postfach in ein Postfach auf dem heimischen Mac laden – dafür bringt der Mac wie viele andere Unix-Systeme das Programm Fetchmail mit. Auf dem Mac kann man anschließend das Mail-Server-übliche Arsenal an Funktionen und Filtern auf den hereingeholten Inhalt anwenden. So lässt sich auch der Funktionsumfang kostenpflichtiger Mail-Angebote übertreffen – allein schon, weil man als eigener Chef auf dem Mac private Mail-Konten ohne Speicherplatzbeschränkungen einrichten kann.

Wenn man den Mail-Server via SSL-Verschlüsselung gegen unerwünschte Mithörer absichert und sowohl den Mail-Abruf als auch den Versand nur nach Authentifizierung erlaubt, kann man ihn gefahrlos auch so einrichten, dass man ihn unterwegs übers Internet erreichen kann. So werden auch kommerziell angebotene Mail-Konten unterwegs nützlich, auf die man wegen Einschränkungen mancher Provider nur aus deren eigenen Netzen zugreifen kann – zum Beispiel Standard-Mailkonten von T-Online oder Stadtnetzbetreibern wie htp.

Nutzen

Normalerweise sind Rechner, die über dynamisch zugewiesene IP-Adressen ins Internet gelangen, nicht für den Betrieb als Mail-Server geeignet, denn mangels DNS-Eintrag und MX-Record sind sie für potenzielle Mail-Absender unsichtbar. Unter anderem deshalb sind Freemail-Dienste als Ersatzlösung verbreitet, wenn man die hohen monatlichen Kosten für die Profi-Lösung mit fester IP-Adresse sparen will.

Hat man seinem Mac etwa über dyndns.org einen DNS-Namen wie macosx.homeunix.net verschafft, genügen aber zwei weitere Tricks, damit sowohl der Mail-Empfang als auch der -Versand an einem Anschluss mit dynamisch zugewiesener IP-Adresse zuverlässig klappen. Damit an die Domain macosx.homeunix.net adressierte Mails zum eigenen Mac zugestellt werden, muss man im betreffenden DynDNS-Eintrag einen MX-Record anlegen (Mail eXchanger) – also auf der Seite "Modify Hostname" unten das Feld "Yes, let me configure Email routing" anklicken und den betreffenden DynDNS-Namen noch einmal eintragen. Damit der Mail-Versand ebenfalls zuverlässig funktioniert, setzt man einen öffentlichen Mail-Server als Vermittler ein, der sie in seinem Namen zum Ziel durchstellt (Relay). So passieren sie übereifrige Spam-Filter, die Mails tilgen, wenn sie von einem Mail-Server stammen, der nur eine dynamisch zugewiesene IP-Adresse hat.

Allerdings ist ein privater Mail-Service nicht viel wert, wenn der Heim-Mac nur unregelmäßig online ist: Denn wenn er abwesend ist, bekommt seine IP-Adresse umgehend ein anderer Rechner. Für eine Weile ist aber der DynDNS-Name immer noch mit seiner eben noch benutzten IP-Adresse verknüpft, sodass währenddessen zuzustellende E-Mails an den neuen Eigner "seiner" IP-Adresse geraten und dort mangels passendem Empfänger zurückgewiesen werden (bounce) – ein solches Mail-Konto ist damit unzuverlässig und irritiert die Absender.

Mail-Server

Mail-Server

Der Begriff Mail-Server wird häufig unscharf gebraucht; er ist als Oberbegriff für alle Bausteine eines Mail-Systems gebräuchlich und auch als Synonym für einzelne Bestandteile wie Message Delivery Agent, Message Transfer Agent, POP3-Server oder auch IMAP-Server. Wir verwenden den Begriff im Weiteren als Synonym für IMAP-Server.

Mail-Systeme für Client-Betriebssysteme sind nicht neu. Jedoch gibt es für den Mac bisher nur Beispiele für ältere Betriebssystemversionen oder nicht mehr moderne IMAP-Server wie UW-IMAP; selbst Apples rund 500 Euro teure Server-Version des Mac OS X bringt nur den betagten Cyrus mit. Wir zeigen deshalb, wie man auf der Client-Version den beliebten Dovecot einrichtet (Mac OS X 10.5.2 alias Leopard).

Dafür sind etliche Klippen zu umschiffen, beispielsweise schon für den systemkonformen Start verschiedener Dienste oder für die Authentifizierung über Mac-eigene Nutzerkonten. Am Ende steht jedoch ein elegantes System, das alle auf dem Mac eingetragenen User mit nur wenigen Handgriffen nutzen können – eine separate User-Datenbank ist nicht erforderlich. Wir setzen dabei nur das moderne IMAP ein, POP3-Konten lassen sich aber ebenfalls anlegen.

Auf Linux ist Dovecot längst etabliert; es gibt auch zahlreiche Konfigurationsbeispiele dafür. Doch die Umsetzung auf dem Mac bedarf zahlreicher Detail-Anpassungen, etwa weil Pfadangaben nicht übereinstimmen, aber auch weil der automatische Start von Diensten nicht über Init-Skripte, sondern über LaunchDaemon-Skripte eingefädelt wird, weil die eine oder andere Datei nachgerüstet werden muss oder auch weil für den reibungslosen Lauf und die Journalverwaltung der installierten Programme angepasste Zugriffsrechte erforderlich sind.

Damit die Einrichtung möglichst schnell abläuft, haben wir alle entwickelten Skripte und LaunchDaemons in einem Download-Archiv bereitgestellt; die einzelnen Elemente sind dann nur noch in die verschiedenen Zielverzeichnisse zu kopieren und in Details anzupassen. Übrig bleibt ein Rest an Handarbeit, die zugleich eine gute Übersicht über das Zusammenwirken der einzelnen Elemente verschafft und so die spätere Wartung erleichtert.

Komponenten des Mac-Mail-Servers
Funktion	Umsetzung	Anwendung für
Mail einsammeln	fetchmail	Freemail-Konten, gehostete Domains
Spam filtern	SpamAssassin	Filterung aller eingehenden Mails
Mail-Lagerung	Dovecot	alle Mails auf einem IMAP-Server
privater Mailhost	DynDNS	DynDNS-Domain
Empfang	Postfix, DynDNS, MX-Record	privater Mailhost
Versand	Postfix/Relay	Passieren fremder Spam-Filter
Verbindungsverschlüsselung	OpenSSL	Fernzugriff übers Internet
Client-Authentifizierung	PAM via Dovecot	Mac-Userkonten benutzen

Voraussetzungen

Wir setzen einen Mac mit Mac OS X 10.5.2 voraus, der über einen Router mit einer dynamischen öffentlichen IP-Adresse ins Internet gelangt. Der Router ist aus dem Internet über einen individuellen DynDNS-Namen erreichbar; mittelbar über Port-Forwarding lässt sich auch der Mac aus dem Internet über den DynDNS-Namen erreichen. Der Anschluss sollte über einen Flatrate-Tarif abgerechnet werden, damit der Mail-Server-Betrieb keine Verbindungskosten verursacht. Um Missbrauch und unbefugten Zugriff auf SMTP- und IMAP-Server zu verhindern, sollten die Passwörter der User möglichst aus mehr als sechs Zeichen bestehen und Groß- wie auch Kleinbuchstaben und Ziffern enthalten.

Mehrere der benötigten Programme sind auf Rechnern mit Mac OS X 10.5.2 bereits an Bord. Die übrigen Elemente müssen aus dem Internet geladen und kompiliert werden. Dazu dienen die XCode-Tools von der Leopard-DVD. Wir haben das System mit Fetchmail 6.3.8, Postfix 2.4.3, SpamAssassin 3.2.4, RazorAgents 2.8.4, RazorAgents SDK 2.0.7, Dovecot 1.0.13, Dovecot Sieve 1.0.2 und OpenSSL 0.9.8g aufgesetzt. Als Beispiele für Domain, Mail-User und Administrator benutzen wir leoclient.bermuda.endofinternet.net, Joe User sowie dz – setzen Sie statt der Beispiele Ihre individuellen Daten ein.

Postfix

Postfix

Das Postfix-Paket gehört beim Mac zum Lieferumfang, es muss nur aus dem Dornröschenschlaf geweckt werden. Kopieren Sie dafür den LaunchDeamon in den Ordner /System/Library/LaunchDaemons und die Postfix-Konfigurationsdateien in den Ordner /etc. Wenn Sie das Mail-Server-Archiv auf dem Desktop Ihres Macs entpackt haben, geht das über das Terminal mit Administrator-Rechten beispielsweise so:

cd Desktop/ct-Mac-Mail-Server/Postfix 
sudo cp org.postfix.master.plist \ /System/Library/LaunchDaemons 
sudo cp access aliases main.cf master.cf sasl_passwd \ /etc/postfix/

In den Abschnitten für Fetchmail, Dovecot und SpamAssassin verfahren Sie dann entsprechend mit den übrigen LaunchDaemons und Konfigurationsdateien. Die LaunchDaemons sollten grundsätzlich dem User root und der Gruppe wheel gehören, sonst weigert sich der Prozess launchd, die darin enthaltenen Anweisungen auszuführen.

Um nun Ihre individuellen Postfix-Einstellungen einzutragen, öffnen Sie die neu einkopierte Konfigurationsdatei für Postfix, main.cf:

sudo pico /etc/postfix/main.cf

Die Zeilen mit den individuellen Einstellungen haben wir in den Konfigurationsdateien kommentiert (#), sodass leicht zu erkennen ist, wo Ihre lokalen Einstellungen einzutragen sind, etwa der Host- und Domain-Name. Während der Erprobungsphase empfiehlt es sich, die Postfix-Eingangskontrolle für Mails etwas zu lockern, damit lokal versandte Testmails, die keine kompletten Header haben, durchgelassen werden; wenn das System zuverlässig läuft, sollte man diese Einstellung abschalten.

soft_bounce = yes

In unserem Beispiel ist Postfix so eingerichtet, dass es eingehende Nachrichten annimmt, die für lokale, am Mac eingetragene User bestimmt sind; er leitet sie an diese mittelbar über SpamAssassin weiter. Der Mail-Versand ist lokal über Port 25 für alle Teilnehmer im selben Subnetz zugelassen. Außerhalb des Subnetzes ist für den Mail-Versand nur über Port 587 verfügbar. Wir gehen dabei von einem NAT-Router aus, der den Zugang zum Internet herstellt und Anfragen von dort an den Port 587 via Port-Forwarding zum Mac durchstellt. Der Server akzeptiert nur am Mac eingetragene User nach Authentifizierung mit ihrem Mac-Passwort (smtpd_sasl_auth_enable). Die Kommunikation wird via TLS verschlüsselt (Transport Layer Security). Das Port-Forwarding für den Port 25 darf nicht eingeschaltet werden, weil dieser nicht via TLS abgesichert ist und deshalb die im Klartext übermittelten Passwörter abhörbar wären.

Ein Ziel bei der Konzeption des Mail-Servers war, für die Authentifizierung die Mac-OS-X-eigene User-Datenbank über Pluggable Authentication Modules zu nutzen (PAM), um die Erstellung und den Entwurf einer separaten User-Datenbank zu vermeiden. Das klappte auf dem Mac zunächst nicht, weil eine PAM-Einstellungsdatei fehlt und weil Apple den Daemon saslauthd, der die PAM-Authentifizierung normalerweise vermittelt, ohne PAM-Unterstützung kompiliert hat. Glücklicherweise kann Postfix für die PAM-Authentifizierung den SASL-Dienst des Dovecot-Mail-Servers nutzen (smtpd_sasl_type = dovecot). Das erspart es auch, für die TLS-Verschlüsselung zusätzliche SSL-Zertifikate zu erzeugen: Stattdessen bereiten wir Postfix dafür vor, die später für Dovecot erzeugten Zertifikate zusätzlich für die TLS-Kommunikation über Port 587 zu nutzen (smtpd_tls_key und smtpd_tls_cert).

Der Mail-Versand erfolgt nicht direkt vom Mac-Server zum Ziel, sondern mittelbar über einen öffentlichen Mail-Server, der als Relay dient (relayhost). Bei diesem vermittelten Versand werden die vom privaten Mail-Server abgeschickten Mails mit dem Header eines öffentlich akzeptierten SMTP-Servers versehen und erst von diesem zugestellt. Deshalb bestehen sie die ersten Spam-Analysen und werden bis zum Ziel-SMTP weitergereicht.

Der Relay-Service ist Bestandteil vieler kostenpflichtiger Mail-Dienste (Liste von SMTP-Relays), aber auch separat erhältlich, zum Beispiel von www.smtp.com für rund 2 US-Dollar pro Monat. Der Versand via Relay ist in der Regel nur nach einer Authentifizierung möglich; man muss dafür also ein registrierter Kunde beim Betreiber des öffentlichen Mail-Servers sein, der als Relay fungiert. In unserem Beispiel wird ein Relayhost über Port 587 angesprochen und der lokale Postfix-SMTP authentifiziert sich bei ihm per SASL-Verfahren (Simple Authentication and Security Layer, smtp_sasl_auth_enable) mit der Kennung, die für den Relay-Dienst erforderlich ist. Das kann auch die reguläre Kennung für den Postabruf und -versand von diesem öffentlichen Mail-Server sein; sie wird später in der Datei /etc/postfix/sasl_passwd eingetragen.

Mit den Parametern mailbox_size_limit und message_size_limit lassen sich die Volumina der Postfächer sowie einzelner Nachrichten beschränken. Wir schalten keine Grenzen ein, weil wir davon ausgehen, dass Nachrichten, die bereits die Beschränkungen der Mail-Betreiber passiert haben, nicht zu groß sein dürften. Für die Variablen mydomain und myhostname geben Sie die Namen an, die auf Ihr Netz und Ihren Mail-Server zutreffen. Bei relayhost tragen Sie den öffentlichen Mail-Server ein, der Ihre per Postfix abgeschickten Mails ins Internet weiterleiten soll, also etwa mail.gmx.de, wenn Sie Zugriff auf diesen SMTP-Relay haben.

Sind alle individuellen Parameter gesetzt, speichern Sie main.cf mit Ctrl-X und Y und editieren nacheinander /etc/postfix/access, /etc/postfix/aliases und /etc/postfix/sasl_passwd gemäß den Kurzanleitungen, die wir diesen Dateien vorangestellt haben. So werden die für Postfix essenziellen Aliasnamen, Senderechte für SMTP-Nutzer und das Relay-Passwort festgelegt.

Anschließend legt man die Alias-, Access- und SASL-Passwort-Datenbanken an. Der jeweilige Schritt ist auch später erforderlich, wenn Sie den Inhalt einer der Textdateien ändern:

sudo newaliases 
sudo postmap /etc/postfix/access 
sudo postmap /etc/postfix/sasl_passwd

Anschließend schränkt man den Zugriff auf die beiden Passwortdateien auf die Postfix-Gruppe und den Root ein, schließt Dritte also aus:

sudo chown root:postfix sasl_passwd* 
sudo chmod 640 sasl_passwd*

Stellen Sie sicher, dass die erforderlichen Spool-Verzeichnisse vorhanden sind – falls der Ordner /private/var/spool/postfix nicht existiert, legen Sie ihn so an:

sudo mkdir /private/var/spool/postfix 
sudo postfix check

Mit dem Kommando postfix check legt man alle Spool-Verzeichnisse auf einen Schlag an. Nun entfernt man den ursprünglichen LaunchDaemon …

sudo launchctl unload /System/Library/LaunchDaemons/org.postfix.master.plist

… und startet den neu eingerichteten:

sudo launchctl load -w /System/Library/LaunchDaemons/org.postfix.master.plist

Ob der Service gestartet ist, kann man mit dem Programm "Konsole" aus dem Ordner "Dienstprogramme" prüfen; die Ausgaben landen in mail.log. Einen erfolgreichen Start vermeldet Postfix so:

Apr 30 15:50:01 LeoClient1 postfix/master[365]: daemon 
started -- version 2.4.3, configuration /etc/postfix

Der Postfix-LaunchDaemon enthält den KeepAlive-Parameter, mit dem man festlegt, dass Postfix dauerhaft laufen soll. Falls die Konfiguration fehlerhaft ist, quittiert Postfix umgehend den Dienst, aber der LaunchDaemon startet es erneut – das führt zu einer Unzahl von Fehlermeldungen im Log, weshalb man den Teufelskreis mit der obigen Zeile launchctl unload … durchbricht.

Falls das Problem länger besteht und Postfix deshalb auch nach Neustarts nicht mehr geladen werden soll, fügt man hinter "unload" den Schalter "-w" ein. Korrekturen der Konfigurationsdateien oder auch Änderungen an access, alias oder sasl_passwd übernimmt Postfix so:

sudo postfix reload

Die Änderungen übernimmt dann gleich das ganze Mail-Transportsystem.

Dovecot

Dovecot

Spätestens an dieser Stelle sollten die XCode-Tools von der Leopard-DVD installiert sein. Wenn das der Fall ist, laden Sie das Dovecot-Archiv und extrahieren es in einen Pfad ohne Sonder- oder Leerzeichen, weil sonst spätere Schritte scheitern. Wechseln Sie dann auf der Kommandozeile in dieses Verzeichnis, um die Software zu kompilieren und zu installieren:

cd ~/dovecot-1.0.13 
./configure 
make

Weil die Software im Pfad /usr/local/ installiert werden soll, dort aber nur der User root Schreibrechte hat, meldet man sich als root an. Der root-Account ist auf dem Mac von Haus aus nicht aktiv. Um ihn zu aktivieren, genügt es, als Administrator sudo passwd root einzugeben und nach Aufforderung das root-Passwort festzulegen. Ist der root-Account aktiv, fährt man mit der Dovecot-Installation fort:

su 
make install 
exit

Anschließend kopiert man aus dem Mac-Mail-Server-Archiv den Dovecot-LaunchDaemon, die pam.d-Konfiguration dovecot sowie die Dovecot-Konfiguration dovecot.conf in die jeweiligen Verzeichnisse:

cd ct-Mac-Mail-Server/Dovecot 
sudo cp dovecot.plist /Library/LaunchDaemons/ 
sudo cp pam.d/dovecot /etc/pam.d/ 
sudo cp dovecot.conf /usr/local/etc/

Damit Dovecot und zu seinem Paket gehörige Programme starten können und Log-Files im Pfad /var/log/ schreiben dürfen, braucht die Software ein eigenes User-Konto. Der Dovecot-Prozess soll aber aus Sicherheitsgründen keine Shell öffnen können und auch kein Passwort erhalten. Bis Mac OS X 10.4 alias Tiger ließen sich User mit dem grafischen Frontend NetInfo Manager anlegen. Dieses Programm hat Apple mit Leopard aber stillschweigend aufgegeben, ohne konkret darauf hinzuweisen, dass auf Leopard diese Aufgaben nunmehr das Kommandozeilenprogramm dscl übernimmt (Directory Service Command Line Utility). Wir haben im Skript AddUserDovecot.sh alle erforderlichen dscl-Befehle zusammengefasst, um den Dovecot-User anzulegen. Stellen Sie sicher, dass es ausführbar ist:

cd ct-Mac-Mail-Server/Dovecot 
chmod +x AddUserDovecot.sh
sudo ./AddUserDovecot.sh

Der Befehl dscl . read Users/dovecot zeigt, mit welchen Parametern der User dovecot angelegt worden ist.

Öffnen Sie nun /usr/local/etc/dovecot.conf und tragen Sie an den markierten Stellen Ihre individuellen Einstellungen ein. Das sind die Postmaster-Adresse und der Hostname. Weitere Änderungen sind nicht erforderlich. Außerdem definiert die Datei die Klartext-Authentifizierung via PAM (sowohl für den eigenen Bedarf als auch als Service für Postfix) und die SSL-Verschlüsselung.

SSL für Dovecot

In diesem Beispiel setzen wir für die SSL-Verschlüsselung ein selbstsigniertes Zertifikat ein. Das geht am schnellsten und hat nur den Nachteil, dass Mail-Clients den Aussteller des Zertifikats nicht kennen und deshalb die SSL-Verbindung nur nach Rückfrage aufbauen. Um die Rückfragen zu vermeiden, muss man entweder jedem Mail-Client beibringen, das Zertifikat dauerhaft zu akzeptieren oder ein Zertifikat von einem Unternehmen wie VeriSign kaufen. Dovecot erwartet die OpenSSL-Dateien, die eine SSL-Verschlüsselung des POP3- und IMAP-Verkehrs ermöglichen, nicht in /usr/local/etc/, also dort, wo seine eigenen Konfigurationsdateien liegen, sondern in /etc/, wo zunächst zwei Ordner dafür angelegt werden müssen:

sudo mkdir /etc/ssl 
sudo mkdir /etc/ssl/certs 
sudo mkdir /etc/ssl/private

Danach wechselt man in das Dovecot-Source-Verzeichnis und editiert dort im doc-Verzeichnis die Datei dovecot-openssl.cnf – im einfachsten Fall genügt es, die lokalen Parameter für die Variablen OU, CN und E-Mail-Kontakt einzutragen, also etwa so:

# Organizational Unit Name (eg. section) 
OU=LeoClient IMAP server 
# Common Name (*.example.com is also possible)
CN=leoclient.bermuda.endofinternet.net 
# E-mail contact emailAddress=dz@leoclient.bermuda.endofinternet.net

Sind die Anpassungen für Ihren Dovecot-Server gespeichert, schalten Sie die im gleichen Ordner befindliche Datei mkcert.sh ausführbar und führen es als root aus:

chmod +x mkcert.sh
su 
./mkcert.sh 
exit

Wenn es fehlerfrei durchläuft, findet man am Ende der Statusmeldungen den MD5-Fingerprint. Wenn SSL korrekt eingerichtet ist, kann Dovecot die Konfigurationsdatei fehlerfrei abarbeiten und starten:

sudo launchctl load -w /Library/LaunchDaemons/dovecot.plist

Ob das Programm läuft, zeigt das Kommando ps auxw | grep -i dovecot. Falls nicht, ist mit hoher Wahrscheinlichkeit etwas bei der SSL-Einrichtung schiefgegangen, sodass das Programm gleich beim Start die Grätsche macht – Einträge im Log-File schreibt es in diesen Fällen nicht, sodass man bei der Fehlersuche ein wenig auf Intuition angewiesen ist.

Hat man die Mac-Firewall auf "Zugriff für bestimmte Dienste und Programme festlegen" eingestellt, bemerkt man den ersten erfolgreichen Dovecot-Start zusätzlich daran, dass die Firewall fragt, ob das Programm eingehende Verbindungen annehmen darf – ja, man gestattet das. Diese Frage stellt die Firewall nur beim ersten Start und wenn man sie abgenickt hat, bleibt sie fortan stumm. Mit welchen Einstellungen Dovecot aktuell läuft, zeigt dieses Kommando an:

/usr/local/sbin/dovecot -n

Zunächst wird die Grundfunktion des Servers per Telnet geprüft und anschließend SSL-verschlüsselt:

telnet localhost imap

Wenn er antwortet, prüft man die PAM-Authentifizierung (den vorangestellten Punkt nicht vergessen):

. login username passwort 
. status INBOX (messages)

Wenn das geklappt hat, kann man für den angemeldeten User die Ordner anlegen, in die Fetchmail die per POP3 abgerufenen Mails ablegen soll. Ersetzen Sie die in den Beispielen "POP3-Account-n" genannten Verzeichnisse mit sinnvollen Namen, etwa T-Online oder Web.de.

. create POP3-Account-1 
. create POP3-Account-2 
. create POP3-Account-3

Der Server antwortet jeweils mit

. OK Create completed.

Nun kann man die Verbindung schließen:

. logout

Für die SSL-Prüfung eignet sich der Befehl openssl, weil er tiefere Einblicke in die SSL-Kommunikation gewährt als übliche Mail-Clients:

openssl s_client -connect localhost:993

Beim Verbindungsaufbau wird dann zwar das selbstsignierte Zertifikat moniert (verify error:num=18:self signed certificate), aber nach Übermittlung des Server-Zertifikats sollte die Verbindung aufgebaut werden (SSL handshake, Server public key, SSL-Session) und der Dovecot-Prompt erscheinen:

* OK Dovecot ready.

Nun kann man sich wie bei unverschlüsselten Telnet-IMAP-Verbindungen authentifizieren – mit dem Unterschied, dass das unverschlüsselte PAM-Passwort über einen SSL-gesicherten Kanal übermittelt wird.

Neu startende Mail-Clients sollten nun SSL-verschlüsselt über Port 993 mit dem Server kommunizieren können, wenn man diese Option in den Einstellungen einschaltet. Um zu vermeiden, dass die Mail-Clients das selbstsignierte SSL-Zertifikat bei jedem Neustart monieren, importiert man es in die jeweilige Zertifikatsverwaltung. Bei Apple Mail unter Leopard genügt es dafür, das Kästchen "Always trust …" anzuklicken. Das Zertifikat wird dann nicht nur vom Client-Mac übernommen, sondern auch als dauerhaft vertrauenswürdig eingestuft. Details des Zertifikats kann man im Programm Keychain Access einsehen (im Ordner Dienstprogramme).

Erst an dieser Stelle, also wenn gesichert ist, dass der Server über Port 993 via SSL-verschlüsselt kommuniziert, sollte man den IMAP-Server für Zugriffe aus dem Internet zugänglich machen, also im Router den Port 993 zur privaten IP-Adresse des Dovecot-Servers im LAN weiterleiten. Wie das geht, beschreiben die Router-Hersteller in den jeweiligen Handbüchern.

Wenn die PAM-Authentifizierung via Dovecot klappt, sollte auch der Postfix-SMTP ansprechbar sein; über den Befehl telnet localhost smtp kann man sich lokal mit ihm verbinden. Wenn er korrekt eingerichtet ist, meldet er sich mit seinem smtpd_banner:

220 .bermuda.endofinternet.net ESMTP

Das genügt als Beleg; man kann die Sitzung gleich wieder schließen, indem man quit eingibt. Falls der smtpd Zicken macht, lässt sich Telnet auf diese Weise nicht beenden, aber immerhin per Control-] (Alt-Ctrl-6).

Falls aus dem LAN oder dem Internet keine Verbindung zustande kommt, liegt es vermutlich an der Mac-Firewall, die restriktiv eingestellt ist (Systemeinstellungen, Sicherheit, Zugriff für bestimmte Dienste und Programme festlegen). Nehmen Sie in diesem Fall smtpd in die Ausnahmeliste der Firewall auf (auf "+" klicken, dann Apfel-Shift-G drücken, den Pfad /usr/libexec/postfix/ eintragen, Eingabetaste drücken und im Dateidialog den Eintrag smtpd doppelklicken). In unseren Tests hat die Firewall die Ausnahmeliste aber nicht immer beachtet; smtpd- oder auch IMAP-Verbindungen ließ die Software nur dann zuverlässig durch, wenn sie auf "Alle eingehenden Verbindungen erlauben" eingestellt war.

SpamAssassin

SpamAssassin

SpamAssassin haben wir im Beispiel so eingerichtet, dass es eingehende Mails zentral für alle Nutzer analysiert und markiert. Anschließend entscheidet jeder User individuell, was mit den Mails passiert. So kann man als Spam markierte Nachrichten abhängig vom Spam-Score automatisch löschen lassen. Die Filterung erfolgt per Sieve. Man könnte die Spam-Nachrichten auch in spezielle Ordner verschieben und nur manuell löschen.

SpamAssassin gibt es für den Mac unter anderem als vorgefertigtes Macport-Installationsarchiv, aber damit scheiterte der Einrichtungsversuch und hinterließ eine defekte Perl-Installation, sodass wir davon abraten. Zuverlässig klappte die Installation über das Comprehensive Perl Archive Network, CPAN. Damit die Perl-Skripte auf dem Mac reibungslos laufen, richtet man zuerst eine Umgebungsvariable ein (sonst meckert Perl "Setting locale failed …"). Dafür legt der Mac-Administrator zunächst einen Ordner in seinem Home-Verzeichnis an (~/)

mkdir ~/.MacOSX

und kopiert anschließend aus dem Archiv die Datei environment.plist dort hinein.

cd ct-Mac-Mail-Server/User/dot-MacOSX 
cp environment.plist ~/.MacOSX

Anschließend meldet man sich ab (logout) und erneut an, damit die Umgebungsvariable übernommen wird und startet dann den cpan-Client via cpanp. Er verlangt bei der ersten Inbetriebnahme eine Reihe von Einstellungen, aber im Test klappte das ganz einfach durch Übernehmen aller Voreinstellungen (Kontinent Europa, Land Germany, ftp-Auswahl: Germany). Wenn die Application Firewall so eingestellt ist, dass sie nur bestimmte eingehende Verbindungen erlaubt (Zugriff für bestimmte Dienste und Programme festlegen), fragt sie zwischendrin, ob Perl eingehende Verbindungen annehmen darf – ja, man gestattet das und setzt die Konfiguration fort. Hat alles geklappt, erscheint im Terminal der cpan-Prompt. Daraufhin schließt man den Client (exit) und startet die SpamAssassin-Installation (Schreibweise befolgen):

sudo cpan Mail::SpamAssassin

Nach den ersten Download-Schritten fragt das Skript die Adresse des Postmasters ab, also der Person, die im LAN für SpamAssassin-Fragen zuständig ist. Anschließend kompiliert sich das System den Wolf, also suchen Sie für die Zeit eine andere Beschäftigung (zwischendrin gibts immer mal Warnungen wie "skipped, all skipped: no reason given", aber denen muss man keine Beachtung schenken). Auf einem MacBook Core Duo mit 2 GHz Takt dauerte der Vorgang rund zehn Minuten. Schließlich tut das Skript das Ende der Installation mit dieser Meldung kund:

/usr/bin/make install -- OK

Um die Erkennungsrate zu steigern, nutzt SpamAssassin den Razor-Agents-Dienst. Dabei melden Razor-Nutzer erkannte Spam-Mails automatisch an eine Datenbank im Internet und stützen sich bei der eigenen Spam-Analyse auf die dort gesammelten Daten.

Laden und entpacken Sie zunächst das Razor-Agents-SDK, beispielsweise in einen Ordner auf dem Desktop. Öffnen Sie dort eine Shell und kompilieren Sie das Paket:

cd Desktop/razor-agents-sdk-2.07 
perl Makefile.PL 
make 
make test 
sudo make install

Mit dem Archiv Razor-agents-2.84 verfahren Sie ebenso. Richten Sie anschließend die Software im Home-Verzeichnis des Administrators ein (in diesem Beispiel hat er den Namen dz):

cd /Users/dz 
razor-admin -create

Nachdem so die Voreinstellungen unter .razor angelegt wurden, registriert man den Administrator für den Razor-Dienst:

razor-admin -register -user=dz@leoclient.bermuda.endofinternet.net

Im Erfolgsfall erhält man diese Rückmeldung:

Register successful. Identity stored in
/Users/dz/.razor/identity-dz@leoclient.bermuda.endofinternet.net

Weitere Details zu den Razor-Programmen wie razor-check oder razor-report finden Sie in der Bedienungsanleitung der Software.

Nun binden Sie den Razor-Dienst als Plug-in in SpamAssassin ein. Kopieren Sie dafür die Datei init.pre aus dem Mac-Mail-Archiv in den Ordner /etc/mail/spamassassin/. Dafür sind Administrator-Rechte erforderlich. Die entsprechende Definition finden Sie in der letzten Zeile (loadplugin Mail::SpamAssassin::Plugin::Razor2). Jeder User, also etwa auch Root, kann einen Voreinstellungsordner (/var/root/.razor) für den Razor-Dienst führen; dort findet sich nicht nur die Konfiguration für den Zugriff auf die Datenbankserver, sondern auch die Datei razor-agent.log, die über die Aktivität des razor-Dienstes informiert, also etwa über Spam-Mails, die dem System neu sind (mail n is not known spam).

Im Download-Archiv finden Sie für SpamAssassin ein auf das Wesentliche beschränktes Konfigurationsbeispiel, das Bayes-Optionen und Auto-Learning einschaltet und die Mail-Subjects unverändert lässt. Die minimale Trefferzahl, ab der SpamAssassin eine Nachricht als Spam klassifiziert, haben wir auf einen moderaten Wert von 5,4 gesetzt.

Wer Tipparbeit scheut, kann über grafische Web-Formulare weitere Voreinstellungen für SpamAssassin zusammenklicken, etwa Blacklists, Sprachanalyse oder auch Verpacken von Spams in Attachments. Weil solche Einstellungen sehr von der gegebenen Infrastruktur und auch vom persönlichen Geschmack abhängen, überlassen wir die Entscheidung dem Administrator.

Kopieren Sie nun die Dateien local.cf und spamd.plist in die Ordner (/etc/mail/spamassassin/ respektive /Library/LaunchDaemons/). Der spamd-LaunchDaemon ruft SpamAssassin mit zwei Parametern auf: -allow-tell öffnet einen Port für die nachträgliche Kommunikation mit spamc (erforderlich etwa für nachträgliche Lern-Vorgänge) und -siteconfigpath legt fest, aus welchem Verzeichnis spamd die systemweiten Einstellungen einlesen soll. Um nun spamd ohne Neustart zu aktivieren, gibt man diese zwei Zeilen ein:

sudo launchctl load -w \ /Library/LaunchDaemons/spamd.plist 
sudo launchctl start spamd

Nun gilt es, den Spamfilter über das Kommando sa-learn zu trainieren. Das kann unter einem beliebigen User-Kontext geschehen, hier sei als Beispiel dz verwendet. Sa-learn akzeptiert Mails in diversen Formaten, darunter mbox, aber es kann auch die von Apple Mail angelegten Mailordner durchforsten:

cd /Users/dz 
sa-learn --showdots --spam Library/Mail/SPAM-Ordner

Man kann den Pfad zu den Spam-Mails einfach aus einem Finder-Fenster in die Shell hineinkopieren (~/Library/Mail/Mailbox-Name/…/Name des Spam-Ordners). Anschließend füttert man die Software mit erwünschten Mails (ham), beispielsweise aus der Inbox des gleichen Postfachs:

sa-learn --showdots --ham /Library/Mail/HAM-Ordner 

Über die Effektivität der Lernautomatik gibt es unterschiedliche Ansichten. Während die Entwickler angeben, dass der Filter schon nach 200 Spam-Nachrichten ausreichend scharf ist, geben manche Anwenderberichte mehrere Tausend Spam-Mails an. Die Treffsicherheit lässt sich einfach anhand einzelner Spam-Mails prüfen.

spamassassin -tD < <Dateiname einer Spam-Mail>.eml

Nach der Analyse gibt SpamAssassin die Punktzahl und einen kurzen Befund aus:

Content analysis details: (17.7 points, 5.4 required)

Umgekehrt sollte das Programm eine erwünschte Mail ebenfalls zuverlässig erkennen, also eine Punktzahl unter 5,4 angeben:

Content analysis details: (0.1 points, 5.4 required)

Ist das erledigt, richtet man SpamAssassin so ein, dass es eingehende Nachrichten von Postfix übernimmt und analysiert. Dafür wurden bereits Voreinstellungen in /etc/postfix/master.cf angelegt, sodass das Transportsystem smtp die Nachrichten über eine Pipe zum Spamfilter weiterreichen möchte. Damit das klappt, muss das Ziel für die Pipe-Übergabe erzeugt werden:

sudo mkdir /Users/spamfilter

Kopieren Sie dort das Skript spamfilter.sh hinein, sodass es vom smtp aufgerufen werden kann:

cd Desktop/ct-Mac-Mail-Server/spamfilter 
cp spamfilter.sh /Users/spamfilter/

So wie Dovecot muss auch der SpamAssassin-Prozess mit spezifischen User-Rechten ausgestattet werden:

sudo ./AddUserSpamfilter.sh

Erst wenn das getan ist, kann man die Zugriffsrechte für den Spamfilter-Ordner und das Skript korrekt einstellen:

cd /Users/ 
sudo chown _spamfilter spamfilter 
sudo chown _spamfilter spamfilter/spamfilter.sh

Weil der SpamAssassin-Daemon spamd im Konfigurationsbeispiel die Nachrichten im _spamfilter-Kontext entgegennimmt, braucht er in seinem Heimatverzeichnis einen .spamassassin- und einen .razor-Unterordner, in die er seine Ergebnisse hineinschreiben darf:

cd /Users/spamfilter 
sudo mkdir .spamassassin 
sudo mkdir .razor 
sudo chown _spamfilter .spamassassin 
sudo chown _spamfilter .razor

Der User _spamfilter kann ebenso wenig wie _dovecot eine Shell öffnen. Deshalb lassen sich unter diesem Kontext keine Kommandos ausführen (zumindest sa-learn und razor-admin wären nötig), sodass SpamAssassin weder im Spamfilter-Ordner eine Datenbank hat noch im .razor-Ordner. Bereits gelernte SpamAssassin-Daten kann man aber aus einem beliebigen User-Verzeichnis – in diesem Beispiel "dz" – dorthin kopieren:

cd /Users/dz/.spamassassin/ 
sudo cp *.* /Users/spamfilter/.spamassassin/ 
cd /Users/dz/.razor/ 
sudo cp *.* /Users/spamfilter/.razor/

Anschließend passt man die Zugriffsrechte für alle drei Dateien (auto-whitelist, bayes_seen, bayes_toks) in einem Rutsch an:

cd /Users/spamfilter/.spamassassin 
sudo chown _spamfilter:wheel * 
cd /Users/spamfilter/.razor 
sudo chown _spamfilter:wheel *

Lokale Auslieferung

Lokale Auslieferung (deliver und SIEVE)

Nun gilt es, einen Local Delivery Agent einzurichten (LDA), der die von SpamAssassin wieder an Postfix zurückgereichten Nachrichten an den IMAP-Server durchstellt. Dafür war zunächst das vielseitige procmail ein Kandidat, aber mit Dovecot spielte die Software nur zum Teil mit – es sortierte POP3-Mails trotz korrekter Filtersyntax nicht anhand der Empfängeradresse in einen dafür eingerichteten IMAP-Unterordner ein. Auch vermag procmail den Nachrichten-Index von Dovecot nicht zu aktualisieren. Aber Dovecot bringt mit deliver nicht nur einen eigenen LDA mit, der geänderte IMAP-Ordner indiziert, sondern in Gestalt von Dovecot Sieve auch ein mächtiges Filtersystem.

Damit deliver im erwünschten User-Kontext startet, deponiert man in jedem User-Ordner die Datei .forward aus dem Download-Archiv.

cd ct-Mac-Mail-Server/User 
cp dot-forward /Users/JoeUser/.forward

Darin ist eine Pipe definiert, über die das Postfix-System die Nachrichten mitsamt der Ziel-Inboxadresse an deliver übergibt (| `/usr/local/libexec/dovecot/deliver`). Achten Sie darauf, dass jede .forward-Datei die User-Rechte erhält, die dem User-Ordner entsprechen. Liegt .forward im Ordner dz, sollte es also dem User dz gehören (ggf. also per sudo chown dz .forward einrichten). Falls die Zugriffsrechte nicht stimmen oder .forward überhaupt fehlt, gehen die Mails nicht verloren. Vielmehr legt Postfix die Mails dann selbst in die Inbox des Empfängers, aber der Sieve-Filter wird dann nicht aufgerufen. Weil deliver unter dem Dovecot-Benutzerkontext läuft, muss das Log-File, das es in den System-Ordner /var/log schreiben soll, angelegt und mit User-Schreibrechten versehen werden:

su 
echo > /var/log/dovecot-deliver.log 
chmod o+w /var/log/dovecot-deliver.log 
exit

Was nun noch fehlt, ist Dovecot Sieve: die Sieve-Routinen ruft deliver bei der Zustellung der Nachrichten auf. Nach dem Herunterladen und Entpacken des Dovecot-Sieve-Archivs wechselt man in das Dovecot-Sieve-Verzeichnis und ruft das dortige Configure-Skript mit dem Pfad auf, in welchem der Dovecot-Quellcode kompiliert worden ist. Wenn also die Dovecot-Quellen im Ordner /Users/dz/Desktop/dovecot-1.0.13/ liegen, sieht der Configure-Aufruf so aus:

./configure --with-dovecot=/Users/dz/Desktop/dovecot-1.0.13

Hat das fehlerfrei geklappt, startet man die Kompilierung und Installation

make; sudo make install

… und kopiert die als Beispiel beigefügte Filter-Definition .dovecot.sieve in die User-Ordner.

cd ct-Mac-Mail-Server/User 
cp dot-dovecot.sieve /Users/JoeUser/.dovecot.sieve

Die User müssen den Filter anschließend an ihre Bedürfnisse anpassen, sonst funktioniert die Sortierung von POP3-Mails in die Unterordner nicht. Im mitgelieferten Beispiel werden Mails einiger bevorzugter Absender umgehend in die Inbox einsortiert und übrige Nachrichten entsprechend dem ursprünglichen Empfänger in zugehörige IMAP-Ordner einsortiert, die beim Test des IMAP-Zugangs angelegt wurden.

Damit deliver die Sieve-Filterung anstößt, muss der Filter kompiliert sein. Wenn deliver Schreibrechte für das jeweilige Verzeichnis hat, stößt es die Skript-Kompilierung zwar selbst an, aber wenn man das Skript per Hand kompiliert, kommt man möglichen Fehlern umgehend auf die Spur:

/usr/local/libexec/dovecot/sievec .dovecot.sieve .dovecot.sievec

Falls sievec im Skript Fehler diagnostiziert, scheitert die Kompilierung und die Fehlermeldung wird in der Datei ~/.dovecot.sieve.err gespeichert.

Wie der User die als Spam markierten Nachrichten behandelt, bleibt ihm überlassen. Testuser haben mit unserer Konfiguration so gute Erfahrungen gemacht, dass sie Nachrichten mit Spam-Flag=YES ohne Weiteres löschen lassen. Diese Funktion ist im Beispielskript aus Sicherheitsgründen auskommentiert. Wenn Sie die Kommentarzeichen entfernen (#), werden aufgrund des Spam-Flags gelöschte Nachrichten im Journal dovecot-deliver.log als "discarded" verzeichnet.

Um nun zu prüfen, ob Mails über den lokalen smtp bis zu Dovecot durchgereicht werden, muss der Empfänger-User seinen Mail-Account lokal auf dem Mac eingerichtetet haben (beispielsweise mit Apple Mail für den Abruf von Nachrichten vom lokalen IMAP-Server). Anschließend gibt man unter dem Kontext des eingerichteten Mailkontos dieses Kommando ein (localhost unbedingt anhängen, sonst verwirft Postfix die Mail):

echo "Alles wird gut." | mail -s "Ich an mich" $USER@localhost

Diese Textmail sollte dem Filter entsprechend in der Inbox des Users landen, der sie abgeschickt hat. Nachrichten, die nicht als Spam klassifiziert wurden, landen in der Inbox – es sei denn, im Sieve-Filter haben Sie anderes vorgesehen.

Wenn Spam unerkannt durchrutscht oder erwünschte Mail nicht durch den Filter kommt, muss man SpamAssassin die korrekte Klassifizierung der betreffenden Dateien per Hand beibringen (sa-learn --spam oder --ham). Es gibt auch Verfahren, die das Nachsitzen automatisieren. Dabei wird sa-learn turnusmäßig per Bash- oder Perl-Skript mit Mails aus dedizierten Spam- und Ham-Ordnern gefüttert. Wir raten jedoch davon ab, weil sich Benutzerfehler nie ganz ausschließen lassen. Sicher fährt man, wenn man den Lernvorgang nach Durchsicht der Spam-Ordner per Hand anstößt.

fetchmail

Fetchmail

Wenn die Mails wie erwünscht in den IMAP-Ordnern landen, kann man den letzten Teil des Mail-Servers einrichten, nämlich das Abholen von E-Mails aus externen POP3-Postfächern; der Rest des Zustellmechanismus ist fertig.

POP3-Postfächer lassen sich mit verschiedenen Programmen leeren. Wir setzen Fetchmail ein, weil Mac OS X dieses Programm bereits mitbringt. Die Abholeinstellungen legt man in der User-Datei .fetchmailrc fest.

cd ct-Mac-Mail-Server/Fetchmail 
cp dot-fetchmailrc /Users/JoeUser/.fetchmailrc

Im mitgelieferten Beispiel werden die Nachrichten von den POP3-Postfächern zwar abgeholt, aber anschließend nicht gelöscht (Parameter keep). Es empfiehlt sich, diese Einstellung zumindest so lange beizubehalten, bis man Gewissheit hat, dass SpamAssassin keine erwünschten Mails löscht. Fetchmail erfasst in der Datei ~/.fetchids, welche Nachrichten es bereits abgeholt hat, sodass es diese bei der nächsten Verbindung nicht erneut abholt.

Wenn auf dem Server des Providers der Platz während der Erprobungsphase knapp wird, kann man per Mail-Client auf das Postfach zugreifen und überflüssige Nachrichten entfernen. Wenn sich der Abholmechanismus bewährt hat, kann man Fetchmail die Nachrichten direkt beim Abholen löschen lassen – oder eben doch behalten, wenn man auf ein externes Nachrichten-Backup auf dem Server des Providers Wert legt. Eine Beispielkonfiguration sieht so aus (alle Angaben erwartet Fetchmail in einer Zeile):

poll "mail.netbeat.de" protocol POP3 uidl user "Joe.User@amanadiseas.de"
password "geheim" is "dz" here keep

Dabei stellt Fetchmail Nachrichten, die beim Provider Netbeat an das POP3-Beispielkonto Joe.User@amanadiseas.de geschickt wurden, dem lokalen User dz zu. Weitere Fetchmail-Optionen, etwa Eingrenzen der Verbindungen auf ein bestimmtes Netzwerk-Interface, um Modem- oder Mobilfunkverbindungen zu vermeiden oder auch Beschränkungen hinsichtlich des Zeitpunkts Abrufe, kann man den Fetchmail-Man-Pages entnehmen.

Bei der Implementierung des Fetchmail-Dienstes gab es ein kleines Problem zu lösen: Die Software holt nicht von sich aus Nachrichten für jeden User nach einem Neustart des Rechners ab – Fetchmail ist nur als einfaches Kommandozeilenprogramm ausgelegt und nicht als Dienst. Mittels zweier Dateien – einem Shell-Skript und einem LaunchDaemon – lässt sich diese Funktion aber nachrüsten. Das Skript fetchmail_runner startet Fetchmail, und dieses klappert die in den .fetchmailrc-Dateien definierten Postfächer ab. Der Parameter -t legt fest, wie lange es auf die Antwort des Servers wartet, bevor es aufgibt (im Beispiel 45 Sekunden).

Auch ist dort festgelegt, welche weiteren Startparameter es nutzt und wo es sein Protokoll ablegt (/var/log/fetchmail.log). Darüber hinaus erschlägt das Skript ein Problem: Fetchmail ist so ausgelegt, dass es nur in dem User-Kontext läuft, von dem aus es gerade aufgerufen wurde – von Haus aus kann es also nicht als einzelner Service laufen, der unter verschiedenen Kontexten die Post für alle User abholt.

Genau das ermöglichten bereits einige für Linux entwickelte Shell-Skripte. Anhand der separaten User-Datenbank /etc/fetchmail.users starten sie Fetchmail mehrfach unter den angegebenen User-Kontexten. Für den Mac haben wir ein solches Skript geringfügig angepasst; die wichtigsten Funktionen stecken in den beiden Zeilen for username in `cat $USERDB`; do und su - $username -c `/usr/bin/fetchmail …. Mithin bezieht jede Fetchmail-Instanz ihre Einstellungen aus der .fetchmailrc-Datei des jeweiligen Users.

Weil so jeder User den Inhalt seiner .fetchmailrc selbst anpassen kann (etwa mit dem grafischen Frontend fetchmailconf), erspart das dem Administrator die Kleinarbeit. Auch setzen die User die Kennungen für den Mail-Abruf selbst in ihre .fetchmailrc ein und müssen sie nicht dem Administrator anvertrauen. Das wäre aber nötig, wenn Fetchmail für alle User eine gemeinsame .fetchmailrc nutzen und mit Root-Rechten laufen würde.

Den fetchmail_runner startet der fetchmail-LaunchDaemon alle 360 Sekunden. Die Datenbank fetchmail.users ist eine einfache Textdatei, in die der Root die User-Kürzel einträgt, die den POP3-Dienst nutzen wollen.

Kopieren Sie also den fetchmail_runner-LaunchDaemon, fetchmail.users und das Skript fetchmail_runner mit Root-Rechten in die jeweiligen Ordner (/Library/LaunchDaemons, /etc und /usr/local/sbin). Stellen Sie sicher, dass /usr/local/sbin/fetchmail_runner ausführbar ist (chmod +x). Die Zugriffsrechte für /etc/fetchmail.users sollten auf root:wheel eingestellt sein.

Damit alle fetchmail-Instanzen in /var/log/fetchmail.log schreiben können, muss die Datei eigens angelegt und mit Rechten versehen werden, die auch Schreibzugriffe für die niedrig privilegierten User-Kontexte aus /etc/fetchmail.users erlauben. Dafür sind explizit Root-Rechte erforderlich, weil im Verzeichnis /var/log von Haus aus nur Root schreiben darf:

su 
touch /var/log/fetchmail.log 
chmod o+w /var/log/fetchmail.log 
exit

Nun kann man den fetchmail_runner-Dienst starten:

sudo launchctl load -w \ /Library/LaunchDaemons/fetchmail_runner.plist 
sudo launchctl start fetchmail_runner

Um zu prüfen, ob fetchmail läuft, sollte man nicht das Kommando ps verwenden, weil das Programm nur kurz alle fünf Minuten aufgerufen wird. Ob es gelaufen ist, verrät aber die Protokolldatei /var/log/fetchmail.log. Falls die konstant leer bleibt, empfiehlt es sich, im console.log nach Fehlerhinweisen zu suchen. Beispielsweise weigert sich fetchmail zu laufen, wenn in /etc/fetchmail.users fehlerhafte Einträge vorhanden sind (Username nicht vorhanden oder falsch geschrieben) oder die Datei riskante Zugriffsrechte aufweist (in diesem Fall mit chmod 0710 .fetchmailrc herabsetzen).

Abschließende Arbeiten

Log-Rotation

Weil das Mac OS X die neuen Log-Files zunächst nicht kennt, werden sie auch nicht rotiert, sodass sie im Laufe der Zeit immer mehr anwachsen. Dadurch verlangsamen sich Suchvorgänge in den Logs und veraltete Daten belegen sinnlos Platz auf der Platte.

Das Rotieren lässt sich auf dem aktuellen Mac OS X 10.5.x mit dem aus der Linux-Welt importieren Kommando newsyslog einschalten. Die Einstellungen bezieht das Kommando aus der Datei /etc/newsyslog.conf. Dieser Datei fügt man drei Zeilen für Dovecot-Deliver, Fetchmail und Razor hinzu

/var/log/dovecot-deliver.log dovecot:wheel 646 10 100 * J 
/var/log/fetchmail.log 666 10 500 * J 
/Users/spamfilter/.razor/razor-agent.log spamfilter:wheel 640 5 100 * J

Mit User-Rechten kann Dovecot-Deliver nicht in /var/log/ schreiben, daher stellt man den Zugriffsmodus auf 646 ein. Newsyslog archiviert zehn dovecot-deliver.logs, rotiert das Log, wenn es 100 kByte erreicht hat und komprimiert die Archive. Details zu weiteren Optionen sind in den man-Pages sowie in newsyslog.conf beschrieben.

Für Fetchmail-Logs empfiehlt es sich zunächst, größere Logs zuzulassen, weil die repetitiven Abrufe einzelner Mails viel Platz belegen, aber nur wenig Informationen enthalten. Wenn es die Probezeit besteht, kann man das Logging bei Fetchmail auf den silent-Modus schalten.

Newsyslog rotiert auch Log-Files in anderen Pfaden, wenn es dort Schreibrechte hat – siehe razor-agent.log. Das Programm Konsole kennt den Pfad dorthin aber nicht, und deshalb führt es solche Dateien auch nicht in der Spalte "Log-Files" auf. Um solche Logs dennoch mit dem Programm Konsole anzeigen zu lassen, muss man sie also etwas umständlicher über den Dateidialog öffnen.

Hat man die Newsyslog-Konfiguration geändert, genügt es, newsyslog aufzurufen, um die Einstellungen zu übernehmen (sudo newsyslog). Log-Files, die größer sind als das in /etc/newsyslog.conf definierte Maximum, werden nun rotiert (logfile turned over due to size>1000K).

Wenn alle Elemente des Servers zur Zufriedenheit laufen, sollte man auch den Postfix-Eingangsfilter scharf stellen (soft_bounce = no in der Datei /etc/main.cf).

Wartungsheft

Wenn sich im Laufe des Betriebs Ungereimtheiten einstellten, kamen wir den Fehlerchen in der Regel leicht durch die Auswertung der Logs auf die Spur. Der größte Teil der Aktivitäten wird in /var/log/mail.log aufgezeichnet. Wenn man dieses Journal mit dem Programm Konsole öffnet und nach "Failure" oder "Error" filtert, hat man die kritischen Meldungen schnell isoliert, sodass man die Fehlersuche eingrenzen kann.

Grundsätzliche Probleme wie Abstürze oder Start-Schwierigkeiten dokumentiert das Betriebssystem in den System Messages. Welches Schicksal einzelnen Nachrichten widerfuhr, die vom Postfix zu Dovecot-Deliver weitergereicht wurden, steht in Dovecot-deliver.log. Wenn Postfix wegen Fehlersituationen Nachrichten zurückhält, kann man sich mit dem Shareware-Tool Postfix q Monitor behelfen – dieses AppleScript-Programm zeigt Inhalte von Warteschlangen an und kann auch die Verarbeitung von zürückgestellten Nachrichten erneut anstoßen. (dz/c't) ()