Postfix SMTP Server

Ein SMTP-Server nimmt Mails an und versendet diese. Er ist das eigentliche Herz des Email-Server-Komplex. Dabei heißt annehmen nur, die Mails ablegen. Sie dem Benutzer zugänglich machen, dafür ist ein anderer Server zuständig. Postfix basiert im wesentlichen nur auf 2 Konfig-Dateien. Das ist einmal die „master.cfg“ und einmal die „main.cfg“. Hier wird definiert wie viele Threads laufen, auf welchen Ports er lauscht und wie eingehende und ausgehende Mails geprüft werden.

master.cf

In der „master.cf“ kann man eigentlich das meiste so lassen wie es ist. Selten besteht bedarf hier etwas zu ändern. Definiert sind hier alle Subprozesse von Postfix und deren Optionen. Z.B. kann man hier einen weiteren SMTP-Port definieren um die Übergabe an Amavis zu regeln. Auch kann man hier schon Checks durchführen, bevor die Mail überhaupt richtig angenommen wurde. Dies sollte man in der Regel aber der „main.cf“ überlassen.

main.cf

Die „main.cf“ definiert wirklich alles weitere, was über die Helfershelfer und die Ports hinausgeht. Unter anderen z.B. Wie sich der Server nennt, auf welche Domains er achten soll, welche Annahmechecks durchgeführt werden, verschiedene Limits und wo die Mailboxen liegen. Mit zusätzlichen Modulen kann man die Mailboxen auch über MySQL definieren. dazu bedarf es dann noch einiger Helfer-Konfigurationen. Diese sind aber selbsterklärend, da in ihnen nur eine MySQL-Verbindung und ein SELECT steht. Neben den ganzen Laufzeit- und Domaineinstellungen sind hier aber die Annahmechecks am wichtigsten. Es gibt verschiedene Level von „restrictions“ in denen man filtern kann. Am meisten Sinn macht aber eigentlich nur „smtpd_recipient_restrictions“.

Hier ein Beispiel wie die „restriction“ aussehen könnte:

smtpd_recipient_restrictions =
# Keine unsauberen Mails annehmen
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
# eigene saeuberung der adresse
check_recipient_mx_access cidr:/etc/postfix/mx_access,
check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
check_helo_access hash:/etc/postfix/helo_blacklist,
# Eiegne Nutzer erlauben
permit_sasl_authenticated,
permit_mynetworks,
# SPAMSCHUTZ RBLs
reject_rbl_client zen.spamhaus.org,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.njabl.org,
# relay-empfaenger
reject_unverified_recipient,
# backup MX
permit_mx_backup,
reject_unauth_destination,
permit

Von oben nach unten erklärt:

Am Anfang wir geprüft ob der Absender eine Voll qualifizierte Domain-Adresse hat. Anschließend wird geprüft ob die Domain bekannt (erreichbar) ist. Mit MX-Access wird geprüft ob der Absender aus einen Gültigen IP-Netz kommt. Hierauf wird dann geprüft, ob die Mail vom Aufbau her stimmt, also z.B. ob genau ein „@“ darin enthalten ist. Mit der Regel „check_helo_access“ wird überprüft ob jemand versucht mit der IP des Servers aber einer anderen, nicht bekannte Domain, Mail einzuliefern. Anschließend erlaubt man das per SASL authentifizierte Benutzer Kontakt zum Server aufnehmen dürfen. Weiterhin werden auch die eigenen IPs erlaubt, sodass man sich nicht selbst aussperrt. Danach wird mit „reject_rbl_*“ verschiedenen „DNS Black Lists“ abgefragt, ob der einliefernde Mailserver nicht schon für Spam bekannt ist. Anschließend werden Mails abgewiesen, welche einen unbekannten Empfänger haben. Letztendlich wird noch erlaubt das ein Backup-MX erlaubt. Es wird dann noch verboten, das an Adressen versendet wird, welche nicht erlaubt sind oder nicht existieren. Abschließen wird noch alles erlaubt was bis jetzt nicht verboten ist.

RBL im Detail

Auszug aus der Wikipedia (http://de.wikipedia.org/wiki/Realtime_Blackhole_List, 13.10.2009):

Als Realtime Blackhole List (RBL) oder DNS-based Blackhole List (DNSBL) werden in Echtzeit (realtime) abfragbare Schwarze Listen bezeichnet, die verwendet werden, um E-Mail zweifelhafter Herkunft als Spam zu klassifizieren. In den meisten RBLs werden IP-Adressen von Rechnern gelistet, von denen in der Vergangenheit Spam versendet wurde – einige Listen enthalten auch Quellen von Computerviren und anderer Malware. Heute handelt es sich bei diesen Rechnern meist um trojanisierte PCs oder seltener offene Mail-Relays, die von Spammern missbraucht wurden. Diese Listen können Mailserver oder Spam-Erkennungssoftware (z. B. Spamassassin) beim Eingang einer Mail nahezu in Echtzeit über das DNS-Protokoll auswerten und bei positivem Ergebnis die Annahme der Mail verweigern, die Annahme der Mail verzögern (Teergrube, Greylisting) oder die Mail so markieren, dass sie ohne großen Aufwand vom Empfänger gefiltert werden kann.

Es werden die Listen von Spamhaus.org, NiXSpam (Liste der iX), SpamCop.net und NJABL.org empfohlen. Diese haben sich in der Vergangenheit als sehr zuverlässig erwiesen und einen geringen Anteil an False-Positives.

postconf

Will man sich die Konfig welche gerade geladen ist noch einmal ansehen, kann man dazu das Kommando „postconf“ nehmen. Mit „postconf -d“ kann man sich alle Defaulteinstellungen anzeigen lassen. Dies gibt sehr viel Output, da wirklich fast jede Variable ausgegeben wird. Übersichtlicher wird das ganze wenn man „postconf -n“, welche Variablen anzeigt, welche nicht defaultmäßig belegt sind. Also verändert wurden. Neben dem Anzeigen der Konfigs, kann man mit postconf auch Variablen setzen. Dazu gibt man „postconf -e ‚PARAMETER=WERT‘ “.

postqueue

Mit dem Kommando „postqueue“ kann man sich die Warteschlange des Servers ansehen. Hier liegen Mails die noch nicht versendet wurden, oder zurück kamen und auf einen erneuten Zustellversuch warten. Dabei kann man sich die Queue ansehen und auch einen erneuten Zustellversuchen veranlassen. Anzeigen kann man sich die Queue mit „postqueue -p“. Dabei wird dann angezeigt, welche ID die Mail hat. Dies ist wichtig wenn man in Logdateien danach sucht. Weiterhin wird auch angezeigt, welche Größe die Mail hat, wann sie ursprünglich eintraf und von wem an wen sie gesendet wurde. Hängt man den noch ein „-v“ an, bekommt man noch einige Debug-Meldungen ausgegeben. Gibt man mehr V’s an, werden noch mehr Ausgaben produziert. Mit „postconf -f“ veranlasst man Postfix dazu, alle Mails in der Queue noch mal versuchen zu versenden. Mit „postqueue -i ID“ veranlasst man Postfix genau die Mail mit der übergebenen ID nochmals zuzustellen. Weiterhin kann man dann auch noch mit „postqueue -s Domain“ den erneuten Versandt aller Mails dieser Domain zu veranlassen. Was postqueue nicht kann, ist das löschen einer Mail aus der Queue.

postsuper

Da postqueue keine Mails löschen kann, nimmt man „postsuper“. Dieses ist zur Queue-Steuerung da. Man kann Queue-Mails löschen, in eine Queue stecken oder sie auch wieder herausholen. Will man also eine Mail aus der Queue entfernen gibt man „postsuper -d ID“ an. Will man die gesamte Queue löschen nimmt man „postsuper -d ALL“. Wobei darauf zu achten ist, das das „ALL“ auch wirklich groß geschrieben wird, da es sonst nicht klappt. Hinter dem ALL kann man auch noch eine Queue angeben. Muss man aber nicht. Man kann auch eine Mail auf „on Hold“ setzten. das heißt sie temporär stoppen. Das tut man indem man „postsuper -h ID“ eingibt. Auch hier trifft wieder das mit ALL und der optionalen Queue Angabe zu. Um die Mail wieder weiterzubearbeiten holt man sie mit „postsuper -H ID“ wieder ins aktive System.

Das Postfix-Log

Postfix schreibt im normal Fall unter „/var/log/“ seine Log-Dateien. Hierbei schreibt es immer 4 Logs parallel. Einmal all-umfassend „mail.log“. Hier steht alles drin was Postfix und seine Helfershelfer so von sich geben. Dann gibt es noch die drei Dateien „mail.info“ , „mail.warn“ und „mail.err“. Hier stehen dann entsprechend der Namen jeweils nur die Logs vom Level Info, Warning und Error drin. Die Logs werden dabei immer ungefähr 10-14 Tage in 8 Versionen vorgehalten.

pflogsum

pflogsum“ erstellt aus dem Logfile von Postfix eine Zusammenfassung. Wie viele Mails prozesst wurden, wie viele abgelehnt und geblockt. Welche SMTP-Fehler auftraten. Top-Senden und Top-Empfänger. Wie die Verteilung der Mails über den Tag hinweg waren und noch andere statistische Werte. Damit kann man den Mailserver ein wenig im blick behalten und frühzeitig Fehler erkennen. Ein aufruf von „pflogsum“ für normaler Weise zur Ausgabe in der CLI. Man kann das Ganze aber auch in eine Mail umleiten und dann per Cronjob einmal am Tag versenden lassen.

pflogsumm --rej_add_from --problems_first --smtpd_stats -h 15 -u 15 --no_reject_detail --no_smtpd_warnings -d today /var/log/mail.log | mail -s "Mailserver Report - `date`" monitoring@domain.de