Mailserver - Umsetzung #
Auf dieser Seite möchte ich die Umsetzung der Ideen und Überlegungen auf der Seite MailServer beschreiben. Beides in eine Seite zu schreiben, dürfte schnell unübersichtlich werden. Deshalb soll die Seite MailServer als Übersicht über die gewünschten Funktionen dienen und die Seite MailServerUmsetzung für Diskussionen hierüber und die konkrete Umsetzung.
(Ob ich zuviel Java programmiert habe, wenn ich jetzt meine Wiki-Seiten schon in Interface und Implementation aufteile, mag der geneigte Leser selbst entscheiden... ;-) --ThomasBayen)
Die Reihenfolge in diesem Dokument entspricht der logischen Reihenfolge bei der Installation (nicht der thematischen Reihenfolge auf der Seite MailServer).
Exim-Konfiguration #
In diesem Abschnitt ist die eigentliche Mailserver-Software als Kern unseres Mailsystems sowie deren Konfiguration beschrieben.
Auswahl der Mailserver-Software #
Grundsätzlich habe ich die bekanntesten Mailsysteme überflogen. Das Hauptkriterium ist erstmal Sicherheit und Stabilität. Das versprechen jedoch eh alle Mailserver. :-) Nun wollte ich einen Server haben, der alles kann (also nicht zu einfach), der halbwegs gut verbreitet ist und deshalb nicht so schnell stirbt und der gut genug dokumentiert ist, um alle Anforderungen umsetzen zu können. Nach einigen Erfahrungen der Vergangenheit rate ich von Sendmail dringend ab, weil dessen Konfiguration die Hölle ist.
Ich habe mich einstweilen für Exim
enschieden. Der Hauptgrund ist, daß Exim standardmäßig von Debian installiert wird und ich mich daher bereits etwas an ihn gewöhnt habe. Exim ist sehr leistungsfähig. Leider geht damit einher, daß er für die Konfiguration im Grunde eine eigene Programmiersprache geschaffen hat. Die Dokumantation hierzu ist sehr lang und knochentrocken. Es sind zwar alle Befehle und Optionen erklärt, aber mir fehlt noch die Stelle, an der praktische Beispiele stehen. Ich musste mir die Debian-Standardkonfiguration Stück für Stück ansehen und daraus lernen, was man wie am besten macht. Wenn man die Konfiguration einmal hat, ist Exim ein solides Arbeitstier.
Von den anderen Alternativen erschien mir Postfix noch als am ehesten geeignet, ich hatte aber keine Lust, ich da auch noch in die Doku einzuarbeiten. Wie gesagt ist hier alles mit Exim beschrieben, bis jemand mit Postfix-Erfahrung seine Tips dazugibt.
Übrigens ist bei Exim die Version 4 aktuell. In älteren Systemen geistert auch noch Exim 3 herum. Grundsätzlich sollte alles hier beschriebene auch aus einem Exim 3 herauszukitzeln sein. Die Konfiguration hat sich jedoch stark geändert, weshalb ich mich hier ausschließlich auf Exim 4 beziehe. Eine ältere Seite zum Thema, die auf Exim 3 basiert, findet sich unter EximMailServer.
Die Standard-Konfiguration unter Debian weicht übrigens von der Standard-Konfiguration von Exim ab. Es kann also sein, daß unten genannte Beispiele für andere Distributionen angepasst werden müssen.
Exim installiert man unter Debian ganz einfach (dabei habe ich die heavy-Variante ausgewählt, da (scheinbar?) nur diese die Authentifizierung per sasl unterstützt):
aptitude install exim4 exim4-daemon-heavy dpkg-reconfigure exim4-config
Debconf setzt vor allem Werte in /etc/exim4/update-exim4.conf.conf. Diese habe ich hier als Beispiel angegeben:
dc_eximconfig_configtype='smarthost' dc_other_hostnames='meinedomain.de' dc_local_interfaces='' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='smtp.meinedomain.de' CFILEMODE='644' dc_use_split_config='true' dc_hide_mailname='false' dc_mailname_in_oh='true' dc_localdelivery='mail_spool'
Die beste Doku für den Start ist /usr/share/doc/exim4-base/README.Debian.gz. Dort sind z.B. auch alle Debconf-Fragen genau erklärt.
Hat man wirklich nur ein nacktes Mailserver-System, muss man ggf. die Perl-Installation um einige Module erweitern - da ist bisher ein Fehler in den Paketabhängigkeiten in Debian Etch. (Symptom ist, daß man nach 14 Tagen eine Mail wg. "outdated gnutls-params" von Exim bekommt.) Dies geht am besten mit:
aptitude install libpod-parser-perl
In Debian Wheezy ist das allerdings nicht mehr nötig.
Für die von uns gewünschten Manipulationen benötigt man in erster Linie die sog. Router, die in /etc/exim4/config.d/routers/ konfiguriert werden. Die dort liegenden Dateien sollte man mal überfliegen und versuchen herauszufinden, was sie tun. Dabei sollte man eine erste Vorstellung bekommen, wie Exim-Konfigurationen funktionieren.
Links:
- http://wiki.debian.org/PkgExim4 - Debian-Paket-Seite
Versand von Mails #
Grundsätzlich kann unser Exim sich zum Versand per DNS den sogenannten "MX-Record" der Zieldomain suchen. Dort steht der zuständige Mailserver, an den man dann die Mail senden kann. Praktisch ist es jedoch so, daß die allermeisten Mailserver unsere Mail gar nicht so einfach annehmen. Aus Gründen des Spamschutz werden dynamische IPs und überhaupt IPs, hinter denen sich Normaluser-Anschlüsse verbergen sollten, oftmals ausgefiltert. Deshalb ist es (wenn unser Mailserver nicht für einen "echten Provider" arbeiten soll) sinnvoll, daß wir unsere Mail an unseren Provider weiterreichen. Das kann der sein, dessen Internetzugang ich benutze oder der, der mir meine Domain zur Verfügung stellt.
Alle vernünftigen Provider verlangen nun, daß wir uns authentifizieren. (Die Unvernünftigen können von jedem Spammer zur Weiterleitung benutzt werden und landen daher auch bald auf Blacklists. Nimmt Dein Provider alsoo Mail ohne Authentifizierung an, ist es Zeit, sich einen neuen Provider zu suchen.)
Langer Rede kurzer Sinn: In der Datei /etc/exim4/passwd.client muss der SMTP-Server meines Providers, mein Benutzername und mein Passwort angegeben werden, da mein Provider nur authentifizierte Verbindungen annimmt. Der remote_smtp_smarthost-Transport bemerkt diese Datei und benutzt eine authentifizierte Verbindung zum Provider-Server, wenn nötig. In diese Datei muss übrigens der DNS-Name, den die IP-Adresse des SMTP-Servers bei einem Reverse-Lookup ergibt. Bei vielen Providern ist das ein Sammelname, da für alle Kunden eines Providers nur ein zentraler Mailserver existiert. Man kann dann nicht "smtp.meinedomain.de" oder sowas benutzen.
Kontrolle: Hat man diesen Schritt beendet, sollte man als Benutzer auf dem Mailserver mit mail test@gmx.de eine Mail ins Internet versenden können. Wenn man den Eingang dieser Mail kontrollieren kann, sollte deren Absender aus dem Benutzernamen verbunden mit der richtigen Internet-Domain bestehen.
gesicherter Zugriff #
Gute Informationen zum Einstieg ins Thema gibt es in /usr/share/doc/exim4-base/README.Debian.gz.
Als Basis brauchen wir das ssl-Paket:
aptitude install openssl
(In Debian Wheezy bereits vorinstalliert)
Mit dem folgendem Befehl erzeugt man ein selbstsigniertes Zertifikat, das dann im Verzeichnis /etc/exim4 abgelegt wird. Bei den abgefragten Daten ist eigentlich nur wichtig, daß man als Server Name den Namen angibt, unter dem der Nameserver im lokalen Netz bekannt ist (z.B. mail.intranet).
/usr/share/doc/exim4-base/examples/exim-gencert
Dazu muss man noch ein Macro in der Konfiguration setzen. Hierzu kann man z.B. eine Datei /etc/exim4/conf.d/main/00_localmacros mit folgendem Inhalt erzeugen:
MAIN_TLS_ENABLE = 1
Nun ist Exim in der Lage, verschlüsselte Verbindungen per SSL aufzubauen. Über diese Verbindungen macht nun auch eine Authentifizierung Sinn. Diese konfiguriert man in /etc/exim4/conf.d/auth/30_exim4-config_examples.
Man kann einerseits den plain_saslauthd_server benutzen. Dieser benutzt die normalen Linux-Benutzerpasswörter. Natürlich werden diese dadurch auch leichter kompromittiert. Wer den Mailserver zu nichts anderem benutzt, hat dadurch eine einheitliche Stelle, an der die Passwörter liegen. Allerdings kann ein kompromittiertes Passwort einen Login-Zugang auf dem Mailserver öffnen. Über dieses Einfallstor kann ein guter Hacker dann weiterkommen. Natürlich kann man die Login-Shell in /etc/passwd deaktivieren. Allerdings fragt man sich dann, warum man nicht gleich eine eigene Passwort-Datei benutzt.
Auf jeden Fall muss man dazu das Debian-Paket sasl2-bin, dann in /etc/default/saslauthd START=yes einstellen, dann die Befehle mkdir /var/run/saslauthd und adduser Debian-exim sasl ausführen. Nach einem Neustart von sasl und Exim kann man sich dann mit seinem normalen Passwort einloggen.
Besser kann man sich eine Plain- oder (besser) CRAM-MD5-Authentifizierung einrichten, indem man den entsprechenden Bereich in /etc/exim4/conf.d/auth/30_exim4-config_examples entkommentiert und die dort beschriebene Passwort-Datei anlegt.
Um die Verschlüsselung per TLS und die Authentifizierung einzurichten, war die Dokumentation von exim auch hilfreich.
Übrigens kann man von außen immer ohne Authentifizierung Mail an die eigene Domain und die mit debconf angegebenen relay-Domains sowie aus dem gesamten relay_net abgeben. Deshalb sollten die Relay-Einstellungen möglichst leer bleiben (wie oben im Beispiel). Eine Anlieferung von Mails an die lokale Domain ohne Authentifizierung ist immer möglich. Wollte man dies ändern, müsste man ggf. ACLs benutzen, aber das ist ein Thema für ein anderes Mal!
Kontrolle: An dieser Stelle kann man mit einem Mailclient (zum Beispiel dem Thunderbird) von einem anderen Rechner aus Mails verschicken. Im Thunderbird muss man dazu in den Einstellungen des Postausgangs-Servers die Option "TLS" aktivieren. Übrigens gibt es ggf. immer noch ein Fehlerfenster, weil der Thunderbird danach die Mail in den IMAP-Ordner "Sent" kopieren will (und IMAP installieren wir erst weiter unten...)
extended Adressen #
Extended Adressen werden wohl von fast jedem Mailserver irgendwie unterstützt, sind aber schlecht dokumentiert. Insbesondere Exim glänzt mal wieder dadurch, daß in der Doku alle Puzzleteile genau erklärt sind, aber einem keiner sagt, wie das dann zusammen funktioniert. Zum Glück gibt es das TMDA-Wiki. In die Dateien
/etc/exim4/config.d/router/400_exim4-config_system_aliases /etc/exim4/config.d/router/600_exim4-config_userforward /etc/exim4/config.d/router/700_exim4-config_procmail /etc/exim4/config.d/router/900_exim4-config_local_user
habe ich folgende Zeilen am Ende der Router-Definition eingefügt:
# -TB- local_part_suffix = -* local_part_suffix_optional
Diese Dateien enthalten Definitionen für Router wie den, der "~/.forward"-Files abarbeitet (mit deren Hilfe vom Benutzer z.B. procmail, TMDA, etc. aufgerufen werden können.) sowie den Router zur eigentlichen Zustellung in das lokale Postfach eines Linux-Benutzers. Diesen wird nun beigebracht, daß der email-Name ein Suffix enthalten kann ,das mit "-" beginnt. Dieses wird dann bei der Suche nach den richtigen Benutzer weggelassen. (Der letzte Router (local_user) wird eigentlich praktisch gar nicht gebraucht, wenn man procmail nutzen will. Bei meinen Tests habe ich jedoch festgestellt, daß man doch öfters die anderen Router mal fehlkonfiguriert. Dann ist man froh, wenn local_user als "fallback" auch konfiguriert ist und die Mail nicht weggeworfen wird.)
Alias-Adressen #
Es gibt in so gut wie allen Mailservern eine Datei /etc/aliases. Hier trage ich ganz einfach meine Alias-Adressen ein. Wenn mein Account also normalerweise thomasbayen heißt, ich aber z.B. auch als superman angesprochen werden will, füge ich folgendes ans Ende dieser Datei:
superman: thomasbayen
Catch-All-Adresse #
Eine Catch-All-Adresse kann recht nervig sein, weil Spammer oftmals erfundene Adressen bekannter Domains benutzen. Insbesondere benutzen sie diese gerne als Absende-Adresse. Die Spam sieht so etwas weniger nach Spam aus (weil sie ja von einer echten Domain, nämlich meiner, kommt). Daraufhin erhalte ich nun also alle Antworten auf die Spam. An guten Tagen trudeln bei mir Tausende(!) solcher "bounces" ein, in denen die Leute mir mitteilen, daß sie nicht mehr existieren, daß sie meine Mail nicht annehhmen, weil sie wie Spam aussieht, daß sie in Urlaub sind oder sonstwas...
Dennoch kann es Gründe geben, Mails an unbekannte Adressen abzufangen und wenn es nur aus Neugierde ist. Auf jeden Fall lege ich die Mails in einem eigenen User-Account ab. Dort stören Sie meinen normalen Mailverkehr nicht, ich kann Sie abrufen, wenn es mich interessiert und ich kann sie vor allem im Block löschen, wenn ich sie nicht mehr haben will.
Ich erzeuge einen Spam-Account mit
adduser spam
Der erste Gedanke war, die Datei /etc/exim4/config.d/routers/400_exim4-config_system_aliases durch setzen eines "*" hinter "lsearch" anzupassen. Dann nimmt der Alias-Router einen "*"-Eintrag in /etc/aliases als Default-Eintrag. Dabei ergibt sich allerdings das Problem, daß so alles, was nicht in aliases steht - und damit auch alle normalen User - umgeleitet wird. Man könnte natürlich die User hier einzeln eintragen, würde dann aber Probleme mit extended Adressen bekommen. Kurzum - der Weg ist der falsche.
Richtiger ist, später im Routing-Ablauf einzusetzen. Dafür brauchen wir einen ganz eigenen Router, der dann aufgerufen wird, wenn alle anderen Zustellungen versagt haben. Also habe ich folgenden Router geschrieben:
### router/950_exim4-config_default_user ######################################## # erstellt von Thomas Bayen # Weiterleitung von Mails, die bisher nicht lokal # zugestellt werden konnten, an den User "defaultuser", # der dann in "/etc/aliases" einem wirklichen Benutzer # zugeordnet werden kann. default_user: debug_print = "R: default_user for $local_part@$domain" driver = redirect domains = +local_domains local_parts = ! root data = defaultuser
Dazu setze ich noch einen Eintrag in /etc/aliases:
defaultuser: spam
globale Kopien #
Bei der Erstellung und dem Lesen von Kopien immer an die Privatsphäre der Nutzer sowie das Arbeitsrecht denken! Jeder Benutzer muss mindestens über das Kopieren seiner Post informiert werden.
Ich möchte gerne im Backup-Account unterscheiden können, welche Mails ausgehend sind. Das erhöht etwas den Überblick und ermöglicht mit einem schnellen Blick, Viren innerhalb des LANs zu erkennen, die SPAM versenden. Bei der Gelegenheit sende ich ausgehende Mails wieder an den Absender zurück. So hat dieser alle seine Mails zusammen in seinem Postfach (und braucht keinen "gesendet"-Ordner - Ich weiß, ist Geschmackssache).
Nach einigem Überlegen und langem Studium der Exim-Dokumentation habe ich beschlossen, daß dieses Problem ein Problem für einen Router ist (und nicht für einen Systemfilter, der das auch könnte). Also habe ich folgende Router in /etc/exim4/conf.d/router/180_exim4-config_backup erstellt:
### router/180_exim4-config_backup
##################################
# erstellt von Thomas Bayen
# - Backup aller Mails an den Backup-User
# - automatisches bcc an den Absender bei ausgehenden Mails
#
# Ich unterscheide ausgehende Mails anhand der IP-Adresse des Absenders -
# dadurch gelten lokale Mails vom Mailserver-Rechner als eingehend. Dies
# stimmt bei mir, da fetchmail dort lokal laeuft und ich von dort keine
# Mails lokal versende.
backup_outgoing:
debug_print = "R: backup_outgoing of mail for $local_part@$domain"
driver = redirect
condition = ${if match_ip{$sender_host_address}{192.168.0.0/16} {yes}{no}}
# Diesen Router immer nur einmal ausfuehren:
repeat_use = false
# Markierung, damit z.B. procmail besser sortieren kann:
headers_add = X-bayen-outgoing: true
# Hier wird ausser dem Backup ein bcc an den Absender produziert:
data = backupuser@bayen.de, $sender_address
unseen
backup_incoming:
debug_print = "R: backup_incoming of mail for $local_part@$domain"
driver = redirect
condition = ${if !match_ip{$sender_host_address}{192.168.0.0/16} {yes}{no}}
# Diesen Router immer nur einmal ausfuehren:
repeat_use = false
# Markierung, damit z.B. procmail besser sortieren kann:
headers_add = X-bayen-incoming: true
data = backupuser@bayen.de
unseen
Da diese Router mich einiges Grübeln gekostet haben hier etwas mehr Erklärungen:
Vorab noch die Bemerkung, daß man in /etc/defaults/exim4 die Option "-d" für Exim setzen kann, um Debugausgaben zu bekommen. Das kann sehr hilfreich sein. Ein "grep R:" über diese Ausgabe zeigt einen Überblick über die durchlaufenen Router.
Zuerst einmal ist es eine gute Frage, was eingehende und ausgehende Mails sind (siehe Exim-FAQ). Ich definiere ausgehende Mails dadurch, daß sie per SMTP aus meinem internen LAN eingereicht werden. Dies macht SMTP-Verbindungen aus dem Internet (so ich diese überhaupt zulasse) zu externen, aber auch Mails, die lokal von dem Mailserver versendet wurden. Da ich meine Mails per fetchmail aus dem Internet hole, trifft dies genau dort zu. Wer diese Definition anders fassen will, muss die condition-Zeile anders fassen. Übrigens ist mir aufgefallen, daß man zur Erzeugung des Ausdrucks die Syntax der Exim Strng Expansion sehr genau beachten muss. Man hat ganz schnell ein Paar Klammern vergessen und der Ausdruck ist immer wahr (statt einer Fehlermeldung).
Damit dieser Router eine Kopie erzeugt und das normale Routing weitergeht, als wäre nichts geschehen, benutzt man unseen.
Alle vom redirect-Router erzeugten Zustelladressen werden im Grunde wieder ganz oben in die Router-Pipeline hereingeschoben. In jedem Durchlauf wird dann zuerstmal eine Kopie gemacht. Benutzt man einen Aliasnamen oder eine Extended Adresse, so werden erstmal mehrere Kopien erzeugt. Dazu kommt, daß natürlich auch von der Kopie eine Kopie gemacht wird. Nun gibt es die Regel, daß Exim dieselbe Mail an eine Adresse nicht mehrfach zustellt. Eigentlich also kein Problem... Dies führt in Kombination mit der Eigenschaft, daß "headers_add" in Wirklichkeit erst beim Transport und nicht beim Router ausgeführt wird und der Tatsache, daß "unseen" diese Headers für die Ursprungsmail löscht, dazu, daß eine Version ohne "headers_add" an den backupuser zugestellt wird. Wer das nicht verstanden hat - auch egal. Wichtig ist, daß man also repeat_use setzt, damit der Copy-Router auch wirklich nur ein einziges Mal pro Mail benutzt wird.
Im outgoing Router kann man aus der data-Zeile die $sender_Address weglassen, um kein automatisches bcc an den Absender zu machen. Wer will, kann hierfür auch einen eigenen Router einsetzen. Der Markierungs-Header X-bayen-outgoing landet auch in der bcc-Mail, wodurch der Benutzer diese evtl. gesondert behandeln kann.
Ach so - die Exim-Hacks zum Thema lokale Kopien sollen wohl Systemfilter darstellen und sind nicht so gut, der dritte sogar völlig falsch.
Sortieren beim Backupuser #
Den backupuser kann man übrigens auch in /etc/aliases auf einen anderen Account umleiten (Achtung! Der Name backup ist bei Debian Linux bereits vergeben). Er hat bei mir eine dem folgenden ähnliche .procmailrc (zu procmail siehe unten):
# .procmailrc von Thomas Bayen # fuer Backupuser MAILDIR=$HOME/mail # vorher anlegen # ausgehende Mails nochmal extra kopieren :0c * ^X-bayen-outgoing: true$ outgoing :0 Backup
sonstige Programme #
Einige Dinge wie z.B. das Abholen von Mails geschieht nicht durch Exim. Dafür ist dieser Abschnitt gedacht:
IMAP-Server #
Als IMAP-Server empfehle ich den Dovecot-Server, der wie auf IMAPMailServer beschrieben Ruck-Zuck installiert ist. Übrigens gibt es auch ein Dovecot POP3-Paket. Dieses habe ich jedoch noch nicht getestet.
aptitude install dovecot-imapd
Dann in der Konfigurationsdatei /etc/dovecot/dovecot.conf folgendes einstellen:
protocols = imaps mail_location = mbox:~/mail:INBOX=/var/mail/%u
Im Dovecot-Paket aus Debian Wheezy sind diese Einstellungen bereits vorgenommen. Außerdem ist die Konfiguration in mehrere Dateien zerlegt. Ich habe hier Anpassungen in ssl.conf und mail.conf vorgenommen:
ssl = required
mail_privileged_group = mail
(Letzteres führt sonst zu Fehlermeldungen bei der Erzeugung von Lockdateien im Debian Inbox-Mailverzeichnis. Das ist IMO ein Bug im Debian-PAket, der bestimmt irgendwann behoben sein wird.)
Nun sollte man spätestens für jeden Benutzer ein Verzeichnis "mail" innerhalb des Homeverzeichnisses anlegen. Dort erwartet IMAP die Mailordner.
Grundsätzlich ist es nun so, daß Exim die Dateien in der Inbox ablegt. Das ist traditionell /var/mail/<username>. Sobald ein Benutzer per IMAP auf sein Postfach zugreift, kann er nun diese Inbox lesen. Alle anderen Ordner legt er allerdings im Verzeichnis ~/mail an. Wir werden weiter unten bei der automatischen Sortierung per procmail auf diese Verzeichnisse zurückkommen. Dennoch ist es auch möglich, jetzt z.B. mit Mozilla Thunderbird Verzeichnisse anzulegen und Mails von Hand umzusortieren.
Das vom Dovecot-Paket automatisch erzeugte Zertifikat lautet übrigens manchmal nur auf den Hostnamen, dann gibt man im Client besser mailserver an als mailserver.intranet.loc (oder man erzeugt ein neues, eigenes Zertifikat). In meiner neuen Lenny-Installation hatte ich im Gegensatz dazu ein Zertifikat mit einem voll qualifizierten Namen.
Kontrolle: Nun sollte man z.B. per Thunderbird auf die Postfächer zugreifen können. Dort muss man bei obigem Setup, bei dem die Mails nicht ins Home-Verzeichnis, sondern nach "~/mail/..." sollen, noch das IMAP-Server-Verzeichnis auf "mail" stellen. Ausserdem muss natürlich die Einstellung für "Sicherheit und Authentifizierung" auf SSL gestellt werden.
eigenes Zertifikat: Das vom Debian-Paket stqandardmäßig angelegte Zertifikat ist ein Jahr gültig und selbstsigniert. Wer ein eigenes anlegen möchte, kann das mit openssl ganz einfach machen und findet unter http://kefk.org/blog/2008/07/06/ausgelaufenes.dovecot.imappop3.ssl.zertifikat.erneuern eine schöne Anleitung.
Kopien per User #
Oft möchte der eine oder andere User mit seiner Mail bestimmte Dinge anstellen, bevor sie so ungefiltert seine Inbox überflutet. Jetzt ist die Gelegenheit, eine eigene Kopie zu machen, nach einer Extended Adresse zu sortieren, einen userabhängigen Spamfilter einzuschieben, Mailinglisten in Ordnern zu sammeln, etc. Hierzu benutzt man am besten procmail:
aptitude install procmail
Ist procmail installiert, brauche ich nur in meinem Homeverzeichnis eine Datei .procmailrc anzulegen. Exim merkt dies (in einem speziellen procmail-Router) und stellt die Mails nicht mehr in die normale Inbox zu, sondern übergibt sie procmail. Dieses arbeitet dann Regeln ab. Findet es keine passende Regel, kommt die Mail doch wieder ins Postfach. Zwischendurch kann sie jedoch beliebig kopiert, umgeleitet oder manipuliert worden sein.
Meine Start-~/.procmailrc ist diese:
# procmailrc von Thomas Bayen # MAILDIR=$HOME/mail # you'd better make sure it exists LOGFILE=$HOME/procmail.log # recommended # Zum staerkeren Debugging diese beiden Zeilen einbinden: #VERBOSE=yes #LOGABSTRACT=all # lokales Backup aller Mails :0c Backup
Diese Konfiguration erstellt ein Backup von jeder eingehenden Mail im Ordner "Backup". Zur genauen Syntax und Vorgehensweise bei procmail-Befehlen sage ich hier nicht so viel, weil das eine Artikelserie für sich wäre. Am besten folgt man den folgenden Links und sieht sich Beispiele an.
Setzt man ein System mit vielen Usern auf, ist es sinnvoll, diese Datei zentral, z.B. unter /etc/procmailrc abzuspeichern. Der einzelne User bekommt dann eine Datei ~/.procmailrc, die nur eine Zeile Inhalt zu haben braucht:
INCLUDERC=/etc/procmailrc
Dahinter kann der Benutzer natürlich beliebige weitere Regeln anfügen. Auf der anderen Seite können die zentralen Regeln zentral gewartet werden. Damit das richtig klappt, sollte man in conf.d/transport/30_exim4-config_procmail_pipe hinter dem Befehl /bin/procmail die Option -p einfügen. Sonst wird die Basisdatei in /etc/procmailrc immer eingelesen, was dann zwei Backups ergibt (natürlich kann man diese Datei auch anders benennen - Geschmackssache).
Links zu procmail:
- Artikel im Linux-Magazin (deutsch)
- procmail-Beispiele (deutsch)
- http://partmaps.org/era/procmail/quickref.html - Quick Reference
- http://pm-doc.sourceforge.net/pm-tips.html - umfangreiche procmail-Tips
automatische Sortierung #
Eine einfache Möglichkeit, Mailinglisten auszusortieren, ist, für diese "extended" Mailadressen zu benutzen. So kann ich die Adresse thomas-lugliste@meinedomain.de in der LUG Mailingliste eintragen und automatisch werden alle Mails der Liste in einen eigenen Unterordner von "Listen" sortiert. Dazu benutze ich folgenden Eintrag in .procmailrc:
# Extensions sind Mailadressen, an die ein "-" und eine # Erweiterung angehaengt ist (thomas-lugliste@meinedomain.de). # Kopie in Ordner, der nach der Extension benannt ist: :0c * ^TO_[^-]+-[^-@]+@meinedomain.de Listen/`formail -zxTo:|perl -pe 's/^[^-]+-([^-@]+)@.*$/$1/'`
Diese Regel ist besonders interessant, weil der Zielordner durch einen Shell-Befehl ermittelt wird.
Leider hat sie einen grossen Nachteil, denn in der To-Zeile können z.B. auch mehrere Adressen stehen. Hat eine davon ein "-" z.B. in der Domain, bricht das Chaos aus... Gerade bei Mailinglisten steht dort oft auch der Name der Liste, die eigentliche Zustellung geschieht dann an eine andere (BCC-)Adresse. Richtiger wäre also, den Header "Envelope-to:" zu benutzen. Leider habe ich festgestellt, daß der auch nicht immer stimmt. So behalten z.B. meine eigenen globalen Kopien, die ich mit obiger Exim-Konfiguration erstelle, den Envelope-to-Header des ursprünglichen Ziels. Warum das so ist, ist mir ein Rätsel!?!
Auf jeden Fall habe ich eine andere Lösung gefunden: Exim übergibt beim Start von procmail durch einige Umgebungsvariablen Informationen. Nun löscht procmail dieses Environment beim Start sicherheitshalber, was man jedoch durch die "-p"-Option verhindern kann. Also ändere ich in /etc/exim4/conf.d/transport/30_exim4-config_procmail_pipe eine Zeile:
command = "/usr/bin/procmail -p"
Nun kann ich folgendes Rezept statt dem obigen benutzen:
# Damit das funktioniert, muss procmail aus exim mit "-p" aufgerufen werden: :0 * ? test -d Listen * $LOCAL_PART_SUFFIX ?? -\/.+$ Listen/$MATCH
Das \/ in der Regex sorgt dafür, daß der Rest des Ausdrucks in die Variable $MATCH gepackt wird (Extraktion durch Klammern - wie in Perl-Regexen üblich - kann procmail nicht).
sonstige, individuelle Sortierung #
Andere Mails sortiert man einfach nach dem Betreff oder dem Absender:
:0: * ^FROM(mailings@gmx.net|@gmx-gmbh.de|newsletters@ebay.de|service@freenet.de|newsletter.*@freenet-ag.de) ^ Spam
Ansonsten gehe ich normalerweise so vor, daß ich alle Mails erstmal in meine Inbox kommen lasse. Finde ich nun eine Sorte Mails, die einen eigenen Ordner verdient, so schreibe ich mir dazu eine passende procmail-Regel.
Übrigens kann man in den meisten MUAs (wie z.B. in Mozilla Thunderbird) angeben, welche IMAP-Ordner einem angezeigt ("abonniert") werden und welche bei jedem Abholen aktualisiert werden (über "Einstellungen"). So erfährt man sofort, wenn sich auf einer wichtigen Mailingliste was getan hat, während andere einen nur belästigen, wenn man sie explizit anklickt.
Abholung von Mails #
So, nachdem wir jetzt alles wunderbar eingerichtet haben, können wir nun endlich das Internet auf unseren Server loslassen. Dazu brauchen wir ein Programm, das Mails bei unserem Provider abholt. Dazu benutzen wir fetchmail. Dessen Konfiguration kann man ganz einfach mit der grafischen Oberfläche fetchmailconf erstellen. Aber auch ohne ist es nicht sehr kompliziert. Als Beispiel hier eine /etc/fetchmailrc, mit der ich meine Mails aus einem Catch-All-Postfach bei meinem Provider abhole:
set postmaster "postmaster" set nobouncemail set properties "" poll mail.meinedomain.de with proto POP3 envelope "X-Envelope-To" localdomains meinedomain.de: user "186535" there with password "pAsSwOrD" to * here options fetchall warnings 3600 fetchlimit 50
Auch hier sollte bei der Angabe des Mailservers der richtige Name des Providerservers und nicht der eigene Alias angegeben werden, da fetchmail da pingelig ist.
neue Benutzer anlegen #
Bei jedem neu angelegten Benutzer muss man nun folgendes machen:
adduser neueruser # ...dann Passwort etc. eingeben su - neueruser mkdir mail cp -a ../alteruser/.procmailrc . mkdir mail/Listen # falls man obige .procmailrc benutzt
weitere Gedanken - noch zu lösende Probleme #
Kombinationen von verschiedenen Eigenschaften können noch Probleme geben. Was passiert z.B., wenn ich eine extended Adresse umleite?
Das meiste auf dieser Seite ist von ThomasBayen geschrieben worden, der bei Rückfragen (am besten auf die LugMailingListe) gerne antwortet.