Mailserver daheim: dovecot und fetchmail

Nach dem gestrigen Beitrag wie man Postfix installiert und E-Mails über einen Smarthost versenden kann, geht es heute mit dem eigenen IMAP-Server und dem Abrufen von bestehenden E-Mailkonten weiter.

Der IMAP-Server wird die auf dem System liegenden Mails für einen Client zur Verfügung stellen, ein anderes Programm (fetchmail) läd derweil die E-Mails von den Servern und sortiert sie über procmail dem Postfach zu. Damit alles schön automatisch abläuft gehört natürlich auch noch ein entsprechender Eintrag in der crontab dazu.

Nach dem Überblick was auf dieser Seite zu finden ist nun aber gleich weiter mit dovecot als IMAP-Server.

dovecot

Anstatt mich wieder mit Courier zu plagen bin ich den Tipps gefolgt, welche dovecot als IMAP-Server empfehlen. Leider sind viele Anleitungen nicht mehr ganz aktuell und das zur Installation benannte Paket »dovecot« führt nur zu einer Fehlermeldung:

Paket dovecot ist nicht verfügbar, wird aber von einem anderen Paket
referenziert. Das kann heißen, dass das Paket fehlt, dass es veraltet
ist oder nur aus einer anderen Quelle verfügbar ist.
Doch die folgenden Pakete ersetzen es:
  dovecot-common
E: Paket dovecot hat keinen Installationskandidaten

Immerhin wird man darauf hingewiesen, wie der korrekte Paketname für die Installation lautet. Da der Server IMAP zur Verfügung stellen soll, wird das dafür benötigte Paket gleich in einem Rutsch installiert:

apt-get install dovecot-common dovecot-imapd

Die folgenden Schritte basieren auf der englischsprachigen Anleitung Set Up a Debian or Ubuntu Machine as a Maildrop und sind nur im Detail abgewandelt.

Nach der Installation von dovecot muss die Konfiguration durch Änderung in der Konfigurationsdatei /etc/dovecot/dovecot.conf auf IMAP umgestellt werden. Der entsprechende Block sieht wie folgt aus:

# Protocols we want to be serving: imap imaps pop3 pop3s managesieve
# If you only want to use dovecot-auth, you can set this to "none".
#protocols = imap imaps

Da ich eine sichere Verbindung mittels IMAP über SSL installieren wollte, gab ich imaps als einzig gültiges Protokoll an:

protocols = imaps

Damit IMAP über SSL funktioniert, muss noch ein entsprechendes Zertifikat erstellt werden. Den Aufruf habe ich von der bereits verlinkten Anleitung übernommen:

openssl req -new -x509 -nodes -out /etc/ssl/certs/dovecot.pem 
-keyout /etc/ssl/private/dovecot.pem -days 5000

Der Aufruf ist natürlich in einer Zeile zu schreiben und wurde hier nur wegen der beschränkten Breite umbrochen.

Der Aufruf verlangt ein paar Angaben, welche für die Erstellung des Zertifikats notwendig sind. So muss beispielsweise der Name eingegeben werden. Bei »common name« sollte der Hostname (mitsamt Domain sofern existent) angegeben werden. Die geforderte E-Mailadresse sollte ebenfalls gültig sein.

Die Angabe das Zertifikat sei für 5'000 Tage gültig sorgt dafür, dass das Zertifikat erst nach über 13 Jahren ungültig wird. Bis dahin wird der Mailserver vermutlich schon einige Jahre lang nicht mehr laufen.

Sofern dovecot noch nicht läuft kann es durch die Eingabe dovecot gestartet werden.

Ob dovecot läuft und wie gewünscht auch per IMAPS über den Port 993 erreichbar ist, kann über eine Verbindung mittels openssl überprüft werden:

openssl s_client -connect localhost:993

Nach einigen Informationen zum Zertifikat meldet sich dovecot und wartet auf eine Eingabe:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN
] Dovecot ready.

Durch die Abfrage zu was dovecot in der installierten Version fähig ist meldet sich der Server entsprechend zurück:

1 CAPABILITY

Sollte eine ähnliche Rückgabe wie bei mir zur Folge haben:

* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISP
LAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE U
IDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHI
N CONTEXT=SEARCH AUTH=PLAIN
1 OK Capability completed.

Nachdem alles wie gewünscht funktioniert kann die Verbindung zum Server beendet werden:

2 LOGOUT

Sollte der Server nicht nur lokal sondern auch von anderen Rechnern im Netzwerk genutzt werden können, ist der Port 993 bei den Firewall-Regeln entsprechend freizugeben.

Bereits jetzt sollte der IMAP-Server über einen beliebigen Client mit einem gültigen Benutzernamen des Linuxsystems aufgerufen und sich mit den Zugangsdaten eingeloggt werden können.

fetchmail

Zunächst die Variante, bei welcher fetchmail einfach an der Kommandozeile aufgerufen wird. Weiter unten auf der Seite erläutere ich auch die Variante fetchmail als Daemon im Hintergrund laufen zu lassen.

Die E-Mails werden von Mailservern per POP3 heruntergeladen und sollen anschließend in Verzeichnisse sortiert werden. Auch die Überprüfung auf Viren und Spam ist möglich. fetchmail übergibt dabei die E-Mails an procmail, welche die Verteilung übernimmt. Zunächst jedoch nur wie fetchmail eingerichtet werden kann.

fetchmail -kv -m "/usr/bin/procmail -d %T"

Wenn alles läuft wie gewünscht kann die Option -k weggelassen werden:

fetchmail -v -m "/usr/bin/procmail -d %T"

Die Option -k steht für »keep« und wird in der Anleitung mit »Don’t delete seen messages from server« beschrieben. Erhalten bleibt -v, da die Ausgabe weiterhin »verbose« stattfinden soll.

Wird aus dem -kv ein -v, werden E-Mails auf dem Server gelöscht sobald sie heruntergeladen wurden.

In manchen Anleitungen ist die Option -K angegeben. Mit versalem »K« wird fetchmail dazu »gezwungen« bereits heruntergeladene E-Mails löschen. Da dies auch ohne diese Option der Fall ist, habe ich kein -K im Aufruf. Dies sei nur am Rande erwähnt. Der Vollständigkeit halber noch die Dokumentation der beiden Optionen:

-k | --keep
    (Keyword: keep) Keep retrieved messages on the remote mailserver. Normally, 
    messages are deleted from the folder on the mailserver after they have been 
    retrieved. Specifying the keep option causes retrieved messages to remain 
    in your folder on the mailserver. This option does not work with ETRN or ODMR.
-K | --nokeep
    (Keyword: nokeep) Delete retrieved messages from the remote mailserver. This 
    option forces retrieved mail to be deleted. It may be useful if you have 
    specified a default of keep in your .fetchmailrc. This option is forced on 
    with ETRN and ODMR.

Einige Anleitungen geben an, dass man den Abruf seiner Postfächer in der Datei /etc/fetchmailrc angeben soll. Dies macht meiner Meinung nach jedoch wenig Sinn, da ich als Benutzer die Angaben über meine E-Mailaccounts in meinem Verzeichnis haben sollte.

Daher ist bei mir die eben genannte leer beziehungsweise nicht vorhanden. Alle Angaben für fetchmail befinden sich bei mir in der ~/.fetchmailrc.

Die Zugangsdaten für den Abruf der E-Mails werden in dieser Datei samt Passwort im Klartext eingegeben. Daher sollten nach dem Erzeugen der Datei die Leserechte entsprechend angepasst werden.

Der Aufbau eines Aufrufs ist sehr simpel:

poll SERVER with protocol POP3 user "USERNAME" there with password "PASSWORD" options ssl

Dabei sind natürlich die Angaben entsprechend zu ersetzen: »SERVER« bezeichnet die Adresse des Mailservers, von welchem die E-Mails abgerufen werden sollen. »POP3« das Protokoll, über welches die Verbindung zum eben genannten Server aufgenommen werden soll. »USERNAME« und »PASSWORT« entsprechen den Zugangsdaten zum Account auf diesem Mailserver. Weiterhin können noch optionen angegeben werden, beispielsweise »ssl«.

Je nach Anleitung und persönlichem Geschmack wird der Aufruf mal in einer Zeile geschrieben, mal in Blöcken oder auch jeder einzelne Punkt in einer Zeile. fetchmail arbeitet alle »Schreibweisen« gleich ab, es ist eher als »Freiheit des Administrators« zu sehen wie die Aufrufe geschrieben werden. Dies sei am Rande erwähnt, da die diversen Anleitungen für fetchmail häufig unterschiedlichste Schreibweisen verwenden.

Wenn fetchmail als Daemon im Hintergrund ausgeführt werden soll, unterscheidet sich die Konfiguration ein wenig. Ich gehe weiter unten auf dieser Seite darauf ein.

Wenn alle Einträge vorgenommen wurden, müssen noch die Zugriffsrechte der Datei geändert werden. Ansonsten quittiert fetchmail den Versuch gestartet zu werden mit einer Fehlermeldung:

Datei /home/amy/.fetchmailrc darf nicht mehr Zugriffrechte haben als -rwx--x-- (0710).

Die entsprechenden Rechte sind schnell gesetzt:

chmod 710 ~/.fetchmailrc

Theoretisch könne bereits jetzt ein Testaufruf erfolgen. Jedoch sollte zunächst auch ein Blick auf die Konfiguration von procmail geworfen werden.

procmail

Bei procmail werden zwei Konfigurationsdateien berücksichtigt. Zunächst die globale Konfigurationsdatei /etc/procmailrc, weiterhin die jeweilige ~/.procmailrc in den Verzeichnissen der Benutzer.

Die globale Konfigurationsdatei kann wie folgt übernommen werden:

# file: /etc/procmailrc
# system-wide settings for procmail
SHELL="/bin/bash"
SENDMAIL="/usr/sbin/sendmail -oi -t"
LOGFILE="/var/log/procmail.log"
DEFAULT="$HOME/Maildir/"
MAILDIR="$HOME/Maildir/"

Manche Anleitungen setzen bereits in diese globale Konfigurationdatei die Zustellung der einzelnen Benutzer.

Wie schon bei fetchmail liegt bei mir die Konfigurationsdatei für procmail im Benutzerverzeichnis und ist nicht mit der globalen Konfigurationsdatei »vermischt«. Die Datei ~/.procmailrc kann beispielsweise wie folgt aussehen:

DEFAULT="$HOME/Maildir/"
MAILDIR="$HOME/Maildir/"            # Dieses Verzeichnis muss als Maildir existieren
LOGFILE="$HOME/.procmaillog"        # Ort der Protokolldatei für procmail
#DELIVER="/usr/lib/dovecot/deliver" # Auskommentierte Definition für deliver (obsolet)
LOGABSTRACT=no
VERBOSE=off

:0                                  # Alles was an *gaskutsche.de geschickt wird, landet
* ^TO.*gaskutsche.de                # in ~/Maildir/.gaskutsche/ (ebenfalls ein Maildir)
.gaskutsche/

:0                                  # Alles was von *@ebay.de geschickt wurde, landet   
* ^From.*@ebay.de                   # in ~/Maildir/.gaskutsche/ (ebenfalls ein Maildir)
.ebay/

procmail ist so konfiguriert, dass alle eingehenden E-Mails mit den beiden Regeln überprüft werden. Wird die E-Mail an »irgendwas«gaskutsche.de geschickt, so wird sie in das entsprechende Verzeichnis verschoben und landet nicht im globalen Posteingang. Gleiches trifft auf E-Mails zu, welche »irgendwas«@ebay.de als Absender haben. Diese werden in den angegebenen Ordner verschoben.

Da sonst keine weiteren Definitionen vorhanden sind, landen alle übrigen Mails im globalen Posteingang.

Diese beiden Beispiele für Mailfilterung sollen nur einen kleinen Eindruck vermitteln, was procmail außer der Zustellung in den globalen Posteingang vermag. Filterung nach Spam, Viren sowie umfangreichere Sortierung von eingehenden Mails sind durch den großen Funktionsumfang realisierbar.

Wichtig ist, dass die jeweiligen Verzeichnisse bereits bestehen, ansonsten gibt es ein Problem bei der Zustellung. procmail legt keine Verzeichnisse an wenn sie nicht existieren sollten. E-Mails werden in diesem Fall nicht zugestellt.

Ich verwende für meinen Posteingang das sogenannte Maildir-Format. E-Mails werden in einem Verzeichnis als einzelne Dateien abgelegt. Alternativ könnte auch das Mbox-Format verwendet werden. Dort werden E-Mails in einer großen Datei zusammengefasst.

Um ein Verzeichnis für die Zustellung im Maildir-Format zu erstellen ist folgender Aufruf notwendig:

maildirmake ~/Maildir/.ebay/

Sollte maildirmake noch nicht auf dem System installiert sein muss es noch installiert werden. maildirmake ist in unterschiedlichen Paketen vorhanden. Ich habe es aus dem Paket von maildrop verwendet:

sudo apt-get install maildrop

fetchmail und procmail sind konfiguriert, nun kann der erste Test mittels einem Aufruf erfolgen:

fetchmail -kv -m "/usr/bin/procmail -d %T"

Dies ist der oben bereits genannte Aufruf bei welchem heruntergeladene E-Mails auf dem Server belassen werden. Sollte etwas bei der Konfiguration von fetchmail und/oder procmail nicht passen, gehen so keine E-Mails verloren.

Wenn alles funktioniert wäre es natürlich vorteilhaft, wenn die E-Mails automatisch alle fünf Minuten abgefragt werden. Man möchte ja nicht wie früher im Mailclient auf den »E-Mails abrufen«-Knopf drücken beziehungsweise die Zeile wieder und wieder eingeben. Um dies zu bewerkstelligen kommen zwei Wege in Frage: entweder man lässt fetchmail als Daemon laufen oder man greift auf cron zurück.

fetchmail als Daemon

In der Konfigurationsdatei /etc/default/fetchmail wird angegeben ob fetchmail im Hintergrund als Daemon laufen soll oder nicht. Standardmäßig ist fetchmail so eingerichtet, dass es nicht im Hintergrund läuft. Um dies zu ändern muss folgende Zeile entsprechend auf den Wert yes gesetzt werden:

# Declare here if we want to start fetchmail. 'yes' or 'no'
START_DAEMON=yes

Die weiteren Angaben welche Server von fetchmail abgefragt werden sollen und in welchem Intervall dies geschehen soll wird in der Datei /etc/fetchmailrc angegeben:

# /etc/fetchmailrc for system-wide daemon mode
# This file must be chmod 0600, owner fetchmail

set daemon      300                # alle 5 Minutes Mails abrufen
set syslog                         # log über syslog 
set postmaster  root               # postmaster auf root setzen 

Neben den allgemeinen Angaben muss jener Bereich, welchen ich weiter oben in der Anleitung in die ~/home/.fetchmailrc geschrieben habe, in die /etc/fetchmailrc übernommen werden. Dabei müssen jedoch die Aufrufe um den Zusatz is USERNAME here ergänzt werden. Ansonsten kann fetchmail die abgerufenen E-Mails keinem anderen Benutzer korrekt zuweisen.

Der oben bereits erklärte Aufruf, diesmal in mehreren Zeilen umbrochen, würde dann wie folgt aussehen:

poll SERVER 
with protocol POP3 
user "USERNAME" there 
with password "PASSWORD" 
is USERNAME here
options ssl

Nachdem die Konfiguration soweit fertiggestellt wurde müssen noch die Schreibrechte angepasst und die Konfigurationsdatei dem Benutzer fetchmail gehören:

chmod 600 /etc/fetchmailrc
chown fetchmail /etc/fetchmailrc

Anschließend kann fetchmail gestartet werden. Das Programm wird nun im Hintergrund als Daemon laufen.

/etc/init.d/fetchmail start

fetchmail über crontab

Die Datei /etc/crontab beinhaltet Befehle, welche zu bestimmten Zeitpunkten von cron automatisch ausgeführt werden sollen. Ein Eintrag für das Abrufen der E-Mails alle fünf Minuten würde dafür sorgen, dass der Mailserver stets relativ aktuell ist.

Mein Beispiel ruft eine Datei auf, in welcher der Aufruf von fetchmail zuvor gespeichert wurde. In ~/.fetchmail-aufruf befindet sich der oben bereits genannte Aufruf (welcher die E-Mails nach dem Herunterladen vom Server dort löscht):

fetchmail -v -m "/usr/bin/procmail -d %T"

Die Datei muss natürlich ausführbar sein, also die entsprechenden Rechte besitzen.

In /etc/crontab befindet sich demnach nur noch der Aufruf zu dieser ausführbaren Datei:

# m h dom mon dow user        command
0-59/5 * * * *    USERNAME   /home/USERNAME/.fetchmail-aufruf > /dev/null 2>&1

Natürlich werden in /etc/crontab bereits einige andere Zeilen stehen. Damit es verständlicher wird, sind die Spalten benannt.

Die erste Position gibt die Minuten an wann der Aufruf erfolgen soll. Die Angabe 0-59/5 besagt, dass alle fünf Minuten der Aufruf erfolgen soll.

Die folgenden Positionen (Stunde, Tag, Monat und Wochentag) sind mit einem * versehen. Dies hat zur Folge, dass der Befehl unabhängig von diesen Werten ausgeführt wird. Somit ist einzig und allein die Bedingung »alle fünf Minuten« ausschlaggebend.

Der Aufruf soll nicht als root stattfinden, sondern als jener Benutzer, welcher die E-Mails auch zugestellt bekommt.

In diesem Beispiel sind somit »USERNAME« bei Aufruf und im Pfad zur ausführbaren Datei identisch.

Damit cron nicht alle fünf Minuten eine E-Mail abschickt das der Aufruf erfolgreich war, muss noch die Weiterleitung > /dev/null 2>&1 hinzugefügt werden. Diese bewirkt, dass Ausgaben des Aufrufs in das »Datennirvana« nach /dev/null umgeleitet werden.

Das war es nun auch schon. Das Abrufen von E-Mails ist mittels fetchmail und procmail geregelt und wird dank dem Eintrag in /etc/crontab alle fünf Minuten vollzogen. Über den bereits eingerichteten IMAP-Server dovecot können die E-Mails nun mit einem beliebigen IMAP-fähigen Client abgerufen werden.

Weiterführende Literatur

dovecot

wiki.ubuntuusers.de/dovecot – ausführliche deutschsprachige Installationsanleitung für dovecot.

www.webmonkey.com/2010/02/set_up_a_debian_or_ubuntu_machine_as_a_maildrop/ – englischsprachige Installations- und Konfigurationsanleitung für dovecot und fetchmail als lokalen MDA (Mail Delivery Agent) mit IMAP.

fetchmail

www.tuxhausen.de/fetchmail.html – deutschsprachige Anleitung für fetchmail mit einfachen Beispielen für die Konfiguration.

wiki.ubuntuusers.de/Fetchmail – deutschsprachige Anleitung für fetchmail, welche etwas mehr in die Tiefe geht und auch auch eine GUI zur Konfiguration behandelt.

www.howtoforge.de/howto/linux/abrufen-von-e-mails-auf-entfernten-servern-mit-fetchmail-debian-etch – deutschsprachige Anleitung wie fetchmail entweder als Daemon oder über cron E-Mails abrufen kann.

www.webmonkey.com/2010/02/set_up_a_debian_or_ubuntu_machine_as_a_maildrop/ – englischsprachige Installations- und Konfigurationsanleitung für dovecot und fetchmail als lokalen MDA (Mail Delivery Agent) mit IMAP.

procmail

wiki.ubuntuusers.de/mutt – Informationen zum textbasierten MUA mutt mit einem kurzen Teilbereich über procmail.

wiki.dovecot.org/procmail – Grundlegende Konfiguration von procmail über die Datei /etc/procmailrc.

www.freebsd.org/doc/de/books/handbook/mail-procmail.html – deutschsprachige Anleitung welche sich mit dem Filtern von E-Mails mittels procmail auseinandersetzt.

www.uibk.ac.at/zid/systeme/mail/procmail/extend_procmail.html – umfangreiche englischsprachige Anleitung mit vielen Beispielen zur Filterung mittels procmail.

crontab

wiki.ubuntuusers.de/cron – umfangreiche deutschsprachige Anleitung mit vielen Beispielen wie cron beziehungsweise /etc/crontab für die regelmäßige Ausführung von Programmen und Skripten verwendet werden kann.

X_FISH