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

Service-Liste:

• Postfix SMTP-Server
• AmaVis
  • Spamassasin
    • pyszor
    • dcc
    • bayes
  • ClamAV

• Courier
  • IMAP-Server
  • POP3-Server

Schematischer Aufbau:

Annahme Von E-Mails

Kommen E-Mails vom Internet aus am Mail-Server an, werden diese zunächst angenommen und dann geprüft. Zu erst wird der Aufbau der E-Mail geprüft. Ist dieser nicht FQDN-Konform wird die E-Mail abgewiesen, da FQDN-Unkonforme (FQDN = Full Qualified Domain Name = Standardmäßiger Domainname) E-Mails nicht im Internet vorkommen, außer sie werden von Spammern verwendet. Danach wird geprüft ob der einliefernde Mailserver per Reserve DNS und EHLO-Check legitim ist. Darauf wird dann noch geprüft ob der Empfänger FQDN-konform ist. Ist dies der Fall wird die IP des einliefernden Servers gegen verschiedene Spam-Listen getestet. Sollte dies positiv sein, wird die E-Mail abgewiesen. Ist das Ergebnis negativ wird die E-Mail an AMaViS übergeben. Dieser durch-scannt mit Hilfe von Spamassassin die E-Mail nach Spam-Merkmalen. Auch wird durch AMaViS die E-Mail auf Viren geprüft. Dies geschieht mit Hilfe von ClamAV. Wenn die E-Mail dann letztendlich auch diese Prüfungen bestanden hat, wird sie auf die Festplatte ins MailDir des betreffenden Empfängers gespeichert. Dort liegt sie dann als simple Textdatei vor.

Nun kann sie durch ein Mailprogramm abgerufen werden. Dies geschieht indem das Mailprogramm zu Courier eine Verbindung aufbaut und nach neuen Mails fragt. Courier biete dazu die Protokolle POP3 und IMAP an. Darüber werden dann die als Textdateien gespeicherten E-Mail aus dem Maildir ausgelesen und an das Mailprogramm gesendet.

Versenden von E-Mails

Vor dem Versenden durch den SMTP-Server wird die E-Mail wieder auf Viren und Spam geprüft. Ein Greylisting findet in diese Richtung nicht statt. Die Anti-Spam-Listen werden in diese Richtung auch nicht abgefragt. Im Anschluss wird die Mail wieder darauf geprüft ob Sender- und Empfänger-Adresse FQDN-konform sind. Auch wird noch geprüft ob der empfangende Mailserver legitim ist. Passiert die Mail die Tests wird sie vom SMTP versendet.

Gestern haben wir uns dann mal einen VServer erstellt, also ne VM die ich bereit stellte und darauf eine Domain geschalten. Dann alles nach und nach installiert. Eigentlich sollten wir ja nicht soviel eingreifen müssen, da wir ja viele scripte vorbereitet hatten. Dies war aber ein Irrtum. Das meiste lief ganz gut durch, also Apache, MySQL und PHP. Postfix ging auch ganz gut durch. Doch dann die Konfiguration davon. Da gab es dann doch das ein oder andere Problem, was isch dann aber auch lösen lies. Meist waren es kleine Fehler mit grossen Auswirkungen wie eben falsche Dateiberechtigungen oder Datenbankberechtigungen. Eines der Grösseren Probleme war, das die ClamAV Version von Debian wohl einen Tick hat und in der Konfiguration, so wie ich sie hier hatte, nicht richtig funktionierte. Nach ein wenig Recherche im Netz fand ich dann aber einen passenden Workaround.
So gegen 23 Uhr war dann alles soweit erstmal bereit das es lief. Also ein Webserver mit PHP und MySQL support, MySQL an sich und eine Mailserverkonstrukt, was Emails empfangen und verenden kann. Wir hatten um 12:00 Uhr Mittags angefangen. Naja, mal ne grössere Pause zum einkaufen und noch eine weitere zum essen. Was jetzt dann noch fehlte waren so Kleinigkeiten wie die Richtige Verschlüsselung der Mails und Statistik tools wie AwStats und Cacti. Auch sollte noch ein Jabber-Server hinzukommen. Dies haben wir dann noch bis 4 Uhr morgens implementiert. Als Jabber Server hatten wir uns dann für OpenFire entschieden, aufgrund der GUI. Is ja für Mausschubser, aber falls eben mal kein Admin zu Hand ist, das die auch mal ein wenig was regeln können. Dann noch als Test für den Webserver und PHP sowie MySQL noch eben ein kleines WordPress aufgesetzt um zu sehen ob das läuft.

Ich werde dann mal Demnächst die Final Version der Script-Sammlung hier noch veröffentlichen.

hier dann noch ein paar quellen:

HowtoForge Tutorial für einen Mail Server

Workaround Tutorial für einen Mail Server