Werbehinweise

Startseite » Blog » Mailserver daheim: dovecot und fetchmail 

Blog

Mai 2024 April 2024 Februar 2024 Januar 2024 Dezember 2023 November 2023 Oktober 2023 September 2023 August 2023 März 2023 Dezember 2022 November 2022 Oktober 2022 September 2022 August 2022 Juli 2022 Juni 2022 Mai 2022 März 2022 Januar 2022 Dezember 2021 November 2021 Oktober 2021 August 2021 Juli 2021 Juni 2021 Mai 2021 April 2021 März 2021 Februar 2021 Januar 2021 Dezember 2020 November 2020 Oktober 2020 August 2020 Juli 2020 Juni 2020 Mai 2020 April 2020 März 2020 August 2019 Juni 2019 April 2019 Dezember 2018 September 2018 Februar 2018 Oktober 2017 August 2017 April 2017 März 2017 Februar 2017 Januar 2017 Dezember 2016 Juli 2016 Februar 2016 Januar 2016 Oktober 2015 Juli 2015 Juni 2015 März 2015 Januar 2015 Dezember 2014 November 2014 Oktober 2014 September 2014 Juli 2014 Juni 2014 April 2014 März 2014 Februar 2014 Januar 2014 Dezember 2013 November 2013 Oktober 2013 August 2013 Juli 2013 März 2013 Februar 2013 Januar 2013 Dezember 2012 November 2012 Oktober 2012 September 2012 August 2012 Juli 2012 Juni 2012 Mai 2012 April 2012 März 2012 Februar 2012 Januar 2012 Dezember 2011 November 2011 Oktober 2011 September 2011 August 2011 Juli 2011 Juni 2011 Mai 2011 April 2011 März 2011 Februar 2011 Januar 2011 Dezember 2010 November 2010 Oktober 2010 September 2010 August 2010 Hardware per Kommandozeilenbefehl lshw auslesen Lily on exploration Windows Product Key ändern Partitionsgröße mit GParted ändern Gehäuseidee: Schlachtaktion WLAN mit Ralink RT2561ST @epost.de – ein Déjà-vu Mit Metallschere und -säge Mailserver daheim: Postfix Mailserver daheim: dovecot und fetchmail Juli 2010 Juni 2010 Mai 2010 April 2010 März 2010 Februar 2010 Januar 2010 Dezember 2009 November 2009 Oktober 2009 September 2009 Januar 2009 Dezember 2008 November 2008 Oktober 2008 September 2008 Juni 2008 Mai 2008 April 2008 März 2008 Februar 2008 Januar 2008 Dezember 2007 November 2007 Oktober 2007 Mai 2007 Februar 2007 Januar 2007 September 2006 August 2006 Juni 2006 Mai 2006 April 2006 März 2006 Februar 2006 November 2005 Oktober 2005 September 2005 Juli 2005 Juni 2005 Mai 2005 Mai 2004 Oktober 2003 September 2003 Juli 2003 Juni 2002 Mai 2002 März 2002 Februar 2002 Januar 2002 November 2001 Oktober 2001 Juli 2001 Juni 2001 Mai 2001 März 2001 Februar 2001 Januar 2001
get Bluefish Editor
Geany – The Flyweight IDE
get Mozilla Firefox
get Opera
get Konqueror
get Mozilla Thunderbird
get Linux Mint
get Ubuntu Linux

Anzeige
ALL-INKL.COM - Webhosting Server Hosting Domain Provider

Werbung

31.

August

2010

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

Datenschutzerklärung
Durch die Nutzung der Website stimmen Sie der Verwendung von Cookies zur Durch­führung von Analysen und zum Erstellen von Inhalten und Werbung, welche an Ihre Interessen angepasst ist, zu.