Postfix, weitere Konfiguration
Mehrere Domains
Wie ich bereits im ersten Teil des HowTos gezeigt habe, kann man sehr einfach mehrere Maildomains mit Postfix hosten indem man den mydestination Parameter entsprechend ergänzt. Aber dabei kommen immer alle Benutzernamen als der selbe Account in allen Domains vor. Dies ist oft nicht gewünscht.
Natürlich bietet Postfix auch Lösungen an um mehrere Domains mit jeweils verschiedenen Accounts zu haben. Dazu läßt sich vor allem der Parameter virtual_alias_domains zusammen mit virtual_alias_maps einsetzen. Virtuelle Aliase unterscheiden sich von normalen Aliasen vor allem dadurch das diese vollständige Adressen inklusive Domainteil sind. Virtuelle Aliase können dann genauso wie normale Aliase auf lokale Benutzeraccounts oder auch auf externe Mailadressen zeigen.
Möchte man also mehrere Domains mit jeweils getrennten Benutzern anlegen, dann erstellt man für alle Benutzer Benutzeraccounts. Dazu kann man der Einfachheit halber den Domainnamen als Teil des Benutzernamens verwenden. Dies ist nicht nötig, ermöglicht aber besser die Übersicht zu behalten. Möchte man z. B. die Domains example.com und example.net mit jeweils getrennten Nutzern verwalten und hat den User Klaus in example.net und den User Hans in example.com, könnte man die Benutzeraccounts examplenetklaus und examplecomhans anlegen. Dann trägt man die Domains example.net und example.com nicht in mydestination, sondern in virtual_alias_domains ein. Danach trägt man die Emailadressen von Klaus und Hans in eine eigene Datei die als Lookup-Tabelle benutzt wird ein, z. B. in die Datei /etc/postfix/virtual. In die main.cf wird dann folgendes eingetragen:
virtual_alias_domains = example.net, example.com
virtual_alias_maps = hash:/etc/postfix/virtual
Die Datei /etc/postfix/virtual könnte dann z. B. so aussehen:
klaus@example.net examplenetklaus
hans@example.com examplecomhans
Bei dieser Datei fällt auf, das sie ein etwas anderes Format als die normale Alias Datei hat, da kein Doppelpunkt als Trennzeichen zwischen Aliasadresse und Benutzername verwendet wird. Tatsächlich ist die normale Alias-Datei die einzigste Lookup-Tabelle die den Doppelpunkt als Trennzeichen enthält und daher wird auch nur diese mit dem Befehl postalias in eine Datenbankdatei konvertiert. Alle anderen Lookup-Tabellen benutzen beliebige Whitespace-Zeichen (also Leerzeichen oder Tabzeichen) als Trenner zwischen linker und rechter Seite und werden mit dem Befehl postmap in eine Datenbankdatei konvertiert:
postmap virtual
Dies wird aus der Datei virtual die benötigte Datenbankdatei virtual.db erzeugen.
Mail-Gateways
2 relativ spezielle Einsatzgebiete von Postfix sind Mailgateways und Backup-MX-Server. Beiden gemeinsam ist, das sie zwar Mails für bestimmte Domänen annehmen sollen, aber diese nicht in einen lokalen Nachrichtenspeicher ablegen sollen, sondern stattdessen an einen weiteren Mailserver durchreichen. Mailgateways werden z. B. in größeren Firmen in einer DMZ als vorgeschaltete Mailserver verwendet, welche z. B. auch zusätzlich der Viren- und/oder Spamfilterung dienen können. Außerdem ist solch ein vorgeschalteter Mailserver auch in der Lage z. B. Mails für mehrere Subdomains anzunehmen und diese z. B. auf Abteilungsmailserver je nach Subdomain weiterzuleiten, falls in einer Firma jede Abteilung ihren eigenen Mailserver betreibt.
Ein Backup-MX dient der Ausfallsicherheit und wird im DNS als niedriger priorisierter Mailserver für die Domäne eingetragen. Falls der Hauptmailserver ausfällt, nimmt der Backup-MX die Mails an und behält sie solange in seiner Queue, bis der Hauptmailserver diese wieder annehmen kann.
Sollen Mails für eine Domäne nur zwecks weiteren relaying angenommen werden, ist diese Domäne weder in mydestination noch in virtual_alias_domains anzugeben, sondern stattdessen in relay_domains. Außerdem muß der Server auch noch wissen wohin er solche Mails weiter zustellen soll. Dazu gibt es die Transport Lookup-Tabelle. In diese Lookup-Tabelle wird für jede Zieladresse (vollständige Emailadresse oder Domain) der sogenannte Next Hop eingetragen. Die Tabelle kann z. B. so aussehen:
verkauf.example.net smtp:[mail.verkauf.example.net]
support.example.net smtp:[mail.support.example.net]
Die Tabelle hat das Format: Adresse Transporttyp:Next Hop. Adresse kann sowohl eine vollständige Emailadresse als auch nur der Domainteil sein. Der Transporttyp ist beim Weitertransport an einen anderen Mailserver immer smtp. Ein anderer möglicher Transporttyp wäre z. B. LMTP. Der Next Hop ist der neue Zielhost. Für den Zielhost kann eine IP-Adresse, ein Hostname oder eine Domain eingetragen werden. Wird ein Host- oder Domainname eingetragen, dann wird auf diesen Namen eine MX-Abfrage durchgeführt. Soll keine MX-Abfrage durchgeführt werden, muß der Name in eckige Klammern gestellt werden. Generell bedeutet ein Eintrag in der Transport Lookup-Tabelle immer eine Art Ausnahme von dem normalen Zustellweg den Postfix sonst versuchen würde.
Aber Halt! Das Problem Mailgateway ist noch nicht ganz gelöst: Man stelle sich jetzt vor der Server nimmt Mails an Domains die in relay_domains konfiguriert sind an, z. B. an ingrid@support.example.net. Nun versucht der Mailserver die Mail an den eigentlichen Zielhost weiterzuleiten. Dieser nimmt die Mail aber nicht an, weil er zurück meldet, das die Mailadresse ingrid@support.example.net gar nicht existiert. Bislang weiß das Mailgateway nur welche Domains es durch relayen darf, aber nicht welche Benutzer es in den Domains gibt.
Dieses Problem läßt sich lösen indem man dem Relayserver ebenfalls alle Benutzeraccounts bekannt gibt. Dazu läßt sich im großen Stil entweder eine Lösung über LDAP (oder auch über NIS) erreichen, wer aber nicht ganz so viel User hat und keine zentrale Verwaltung über eine LDAP-Datenbank möchte, kann auch eine separate Lookup-Tabelle für die User anlegen. In diesem Fall müßte man natürlich alle User 2-fach pflegen: Einmal auf dem eigentlichen Mailserver und einmal auf dem Gateway.
Die neue Lookup-Tabelle könnte z. B. /etc/postfix/relay_recipients mit folgenden Inhalt sein:
barbara@support.example.net OK
heinrich@support.example.net OK
martin@verkauf.example.net OK
Es ist jeweils eine gültige Adresse in einer Zeile anzugeben. Rechts muß auch ein Wert stehen, aber was dort steht ist egal.
Nun müssen noch die beiden neuen Lookup-Tabellen in Datenbanken umgewandelt werden:
postmap transport
postmap relay_recipients
Danach muß die main.cf noch geändert werden:
relay_domains = support.example.net, verkauf.example.net
transport_maps = hash:/etc/postfix/transport
relay_recipient_maps = hash:/etc/postfix/relay_recipients
SASL
Häufig hat man das Problem, das man auch Benutzern das Relaying von Mails gestatten muß, diese aber nicht im gleichen Netzwerk, wie der Mailserver sind, sondern in sehr unterschiedlichen Netzwerken sein können. Außendienstmitarbeiter mit ihrem Notebook wollen ebenfalls den Mailserver benutzen oder man betreibt einen gemieteten sogenannten "Rootserver" in einem fremden Rechenzentrum, der als Mailserver von unterschiedlichen IPs aus benutzt werden soll. In diesen Fällen benötigt man eine Benutzerauthentifizierung. Postfix selbst hat keine Benutzerauthentifizierung, was jedoch für diesen Zweck benutzt wird ist SASL.
SASL steht für Simple Authentication and Security Layer. Es ist eine Bibliotheksfunktion die von beliebigen anderen Serverprogrammen genutzt werden kann um Authentifizierungen durchzuführen. Die bekannteste SASL Implementierung sind die Cyrus SASL Bibliotheken. Daneben gibt es auch noch Dovecot SASL. Postfix kann sowohl Cyrus SASL, als auch Dovecot SASL benutzen. Falls sie ohnehin Dovecot als POP/IMAP-Server verwenden, ist es sinnvoll auch die Dovecot SASL Authentifizierung für Postfix zu verwenden. Dann können Postfix und der POP/IMAP-Server auf die gleichen Authentifizierungsquellen zugreifen. Ansonsten wird meist Cyrus SASL verwendet zumal es schon erheblich länger als Dovecot SASL von Postfix unterstützt wird.
Die Unterstützung für die jeweilige SASL Implementierung muß in Postfix einkompiliert sein um sie benutzen zu können. Falls sie also ein vorgefertigtes Paket benutzen, achten sie auf die SASL Unterstützung. Welche SASL-Implementierungen Postfix unterstützt können sie mit dem Befehl postconf -a feststellen. Falls sie Postfix aus den Quellen selbst kompilieren, müssen sie darauf achten die SASL Bibliotheken ebenfalls installiert zu haben und die entsprechenden Parameter für make verwenden (Postfix verwendet kein configure-Script).
SASL unterstützt verschiedene Authentifizierungsmethoden, wie etwa Plain, Login, Digest-MD5, CRAM-MD5, Kerberos und Anonymous.
Plain benutzt Klartextpasswörter. Sie können zusätzlich TLS verwenden um die Übertragung zu sichern. Der Vorteil von Plain ist das sie die normale Unix-Passwortdatenbank benutzen können, ohne eine eigene Passwortdatenbank aubauen zu müssen.
Login benutzt ebenfalls Klartextpasswörter. Manche ältere Clients ziehen Login gegenüber Plain vor, weshalb es auch unterstützt wird. Ansonsten gilt für Login auch alles für Plain gesagte.
Digest-MD5 und CRAM-MD5 sind Verfahren bei dem nie das eigentliche Passwort über die Leitung gesendet wird. Stattdessen sendet der Server eine "Challenge". Der Client kombiniert die Challenge mit dem Passwort und bildet daraus einen MD5-Hash. Dieser Hash wird dann dem Server gesendet. Der Server ermittelt dann ob er auf das gleiche Ergebnis kommt, womit der Client das richtige Passwort kennen muß.
Kerberos ist ein Netzwerkauthentifizierungsdienst der vor allem für Single-Sign-On benutzt wird. Falls sie bereits Kerberos in ihrem Netzwerk einsetzen, kann SASL ebenfalls auf Kerberos zurückgreifen um Single-Sign-On zu unterstützen. Die Nutzung von Kerberos für SASL macht nur Sinn, wenn sie ohnehin bereits Kerberos einsetzen.
Anonymous ist eigentlich kein Authentifizierungsverfahren, sondern läßt anonyme Anmeldungen zu. Dies mag für andere Anwendungen sinnvoll sein, aber der Zweck von SASL für einen SMTP-Server ist eine Authentifizierung. Anonyme Anmeldungen wären ohnehin auch schon ohne SASL möglich.
Möchten sie die normalen Unix-Passwortinformationen verwenden (also z. B. /etc/shadow oder PAM) sind sie zwangsläufig auf Plain und Login beschränkt, da die Passwortdatenbank selber verschlüsselt ist und für die verschlüsselten Verfahren CRAM-MD5 und Digest-MD5 muß das Passwort im Klartext auf dem Server vorhanden sein.
Möchten Sie Digest-MD5 oder CRAM-MD5 einsetzen, dann müssen sie eine eigene SASL-spezifische Passwortdatei aufbauen und verwenden. Sie müssen sich daher vorab für ein bestimmtes Verfahren entscheiden, da die Konfiguration je nach verwendeten Verfahren unterschiedlich aussieht.
Plain und Login mit saslauthd
Der Postfix smtpd kann auf die Passwortinformationen des Systems nicht zugreifen, da er nicht mit Root-Rechten arbeitet. Aus diesem Grund kommt Cyrus SASL mit einem eigenen Dienst für die Überprüfung der lokalen Passwortdatenbank, bzw. für die Nutzung von PAM. Dieser Dienst ist der saslauthd, welcher bei Cyrus SASL mit dabei ist. Zusätzlich benötigt SASL noch für jeden Serverdienst der SASL benutzt, eine Datei die festlegt welches Authentifizierungsframework (also z. B. saslauthd) dieser Server benutzt. Für einen Postfix SMTP-Server heißt diese Datei smtpd.conf. Bei vorkompilierten Paketen findet sich die Datei oft unter /etc/postfix/sasl, ansonsten auch unter /usr/local/lib/sasl2. Es reicht in diese Datei folgende 2 Zeilen zu schreiben:
pwcheck_method: saslauthd
mech_list: plain login
Dies bietet nur die Klartextmethoden Plain und Login an und läßt den Postfix-Server Authentifizierungen an den saslauthd weiterleiten. Der saslauthd muß dazu mit Root-Rechten als Systemdienst gestartet werden. Das der saslauthd Root-Rechte benötigt ist ein kalkulierbares Risiko, da er nicht auf Netzwerkanfragen lauscht, sondern nur lokale Anfragen entgegennimmt. Nähere Informationen zum saslauthd finden sie auch in dessen Manpage.
Sollte der smtpd in einem Chroot laufen (dies wird in der master.cf festgelegt), muß die Socketdatei, die Postfix verwendet um den saslauthd zu kontaktieren, innerhalb des Chroots zugänglich sein. Der Pfad des Sockets, den saslauthd erstellt läßt sich über den Startparameter -m für saslauthd einstellen.
Digest-MD5 und CRAM-MD5 mit SASL-Datenbank
Falls Sie Digest-MD5 oder CRAM-MD5 zur Authentifizierung verwenden wollen, muß eine eigene Datenbank mit Authentifizierungsinformationen aufgebaut werden. Zuvor erstellen sie die Datei smtpd.conf, die meistens entweder in /etc/postfix/sasl oder in /usr/local/lib/sasl2 liegt, mit folgender Zeile:
pwcheck_method: auxprop
auxprop steht für Auxiliary Proprietary Plugin und kann verschiedene Backends zur Authentifizierung einbinden, darunter auch eine von Cyrus SASL mitgelieferte eigene Benutzerdatenbank. Einen Benutzer in der SASL eigenen Benutzerdatenbank können sie mit dem Befehl saslpasswd2 erstellen:
saslpasswd2 -c -u mail.example.net user
Dies wird sie nach einem Passwort fragen und die Benutzerdatenbank unter /etc/sasl2.db erstellen. Der Parameter -c steht dabei für das erstellen eines neuen Users, mit -d kann man User löschen. Der Parameter -u steht für den Hostnamen. Der Wert für diesen Parameter muß mit dem Hostnamen der in der Postfix Konfiguration angegeben wurde übereinstimmen (Dies ist in der main.cf der Parameter myhostname). Der in Postfix eingegebene Hostname läßt sich auch mit postconf myhostname überprüfen.
Achten sie bei der SASL Datenbankdatei auf die Zugriffsrechte. Die Datenbank enthält die Passwörter im Klartext. Die Datei muß natürlich für den Postfix-User lesbar sein. Denkbar ist es also root Lese- und Schreibrecht auf die Datei zu geben (für Änderungen) und der Gruppe von Postfix nur Leserechte, während alle anderen keine Rechte haben:
chown root:postfix /etc/sasl2.db
chmod 640 /etc/sasl2.db
Mit dem Kommando sasldblistusers2 lassen sich alle Benutzer der Datenbank abfragen. Dabei werden jedoch die Passwörter nicht gezeigt.
Falls der smtpd bei ihnen in einem Chroot läuft, kann dieser allerdings nicht auf die Datenbank die ja unter /etc liegt zugreifen. Daher ist es in diesem Fäll nötig nach jeder Änderung die Datenbank in den entsprechenden Pfad im Chroot zu kopieren, z. B. so:
cp -p /etc/sasl2.db /var/spool/postfix/etc
Die Option -p für cp erhält dabei die Zugriffsrechte. Da nun zum anlegen von Mailusern mehrere Schritte nötig sind, ist es sinnvoll diese z. B. in einem Shellscript zusammenzufassen, das dann jedesmal bei Änderungen vom Administrator aufgerufen werden kann.
Änderungen an der main.cf
Um SASL nun nutzen zu können muß noch die main.cf geändert werden:
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable schaltet die SASL Authentifizierung ein. smtpd_recipient_restrictions ist ein Parameter der Client-Beschränkungen definiert. Dies wird dazu benutzt festzulegen, wer Mails durch den Server relayen darf. Der Standardwert von smtpd_recipient_restrictions ist permit_mynetworks, reject_unauth_destination, was Clients aus mynetworks das Relaying erlaubt, allen anderen nicht. Um auch SASL Clients das relaying zu erlauben muß permit_sasl_authenticated noch ergänzt werden. Danach muß wie immer bei Änderungen an der main.cf Postfix neu geladen werden:
postfix reload
Es ist auch möglich die Authentifizierungsarten die SASL verwenden kann, aus Sicherheitsgründen einzuschränken. Haben sie SASL z. B. für die Verwendung mit Digest-MD5/CRAM-MD5 konfiguriert, möchten sie womöglich nicht das überhaupt jemand die Plain Methode benutzt. Dies kann so erreicht werden:
smtpd_sasl_security_options = noanonymous, noplaintext
Dies verhindert Anmeldemethoden die Klartextpasswörter übertragen, wie Plain und Login. Der Standardwert von smtpd_sasl_security_options ist noanonymous, was lediglich die Anonymous Methode abschaltet.
SMTP-Auth als Client
Es gibt Situationen in denen Postfix sich wie ein normaler SMTP-Client benehmen muß und sich mit Benutzername und Passwort bei einem anderen Mailserver anmeldet um Mails durch diesen relayen zu können. Dies ist z. B. dann nötig wenn ein Laninterner Postfix-Server für eine Arbeitsgruppe eingerichtet wurde und dieses Lan nach außen dynamisch wechselnde IP-Adressen verwendet. Was ist das Problem mit dynamischen IP-Adressen beim Versand? Beim Empfang ist klar, das der Server Schwierigkeiten haben wird Mails zu empfangen, da seine IP-Adresse sich immer wieder ändert. Der Versand sollte aber doch normal möglich sein oder? Der Punkt beim Versand ist das viele Mailserver beim heutigen Spamaufkommen, so konfiguriert sind, daß sie nur Mails von Hosts mit fester IP-Adresse annehmen. Alle anderen Mails werden als Spam abgewiesen, da Spamversender häufig von Botnetzen aus senden deren Mitglieder meist dynamische IP-Adressen haben.
Um also zu verhindern das die Mail dieses Mailserver als Spam abgelehnt wird, muß ein Smarthost eingerichtet werden. Ein Smarthost ist ein anderer Mailserver, durch den unser Mailserver alle Mails zu ihrem eigentlichen Ziel hindurch relayt. Der Smarthost sollte also ein Mailserver mit fester IP-Adresse sein, den wir zum relaying benutzen dürfen, z. B. der Mailserver unseres Providers. Solch ein Smarthost wird in der main.cf so definiert:
relayhost = mail.myisp.net
Dies wird alle Mails nicht an ihr eigentliches Ziel sondern an den Server mail.myisp.net weiterleiten. Ausnahmen davon können über eine Transport Lookup-Tabelle definiert werden (siehe bei Mailgateways).
Da aber praktisch alle Mailserver von Providern eine Authentifizierung verlangen, muß auch für diese Clientkonfiguration von Postfix SASL verwendet werden. Dazu sind 2 Parameter in der main.cf erforderlich:
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_auth_enable = yes schaltet die Clientseitige Unterstützung für SASL ein. smtp_sasl_password_maps verweist auf eine Lookup Tabelle, in der für jeden Relayserver ein Benutzername/Passwortpaar angegeben ist. Die Datei könnte zum Beispiel so aussehen:
mail.myisp.net user:geheim
Auf der linken Seite steht der Hostname des Servers, auf der rechten Seite getrennt durch einen Doppelpunkt ein Benutzername/Passwortpaar. Da in dieser Datei ein SMTP-Passwort im Klartext angegeben ist, achten sie auf die Rechte die diese Datei hat. Sie sollte nur für Root zugänglich sein:
chown root /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd
Danach muß noch die Datenbankdatei erstellt werden:
postmap sasl_passwd
Spambekämpfung
Spam wird zum immer größeren Problem. Bereits weit über 90 % des gesamten Emailverkehrs im Internet besteht aus Spam. Daher nehmen Spamabwehrmassnahmen einen immer breiteren Raum in der Arbeit von Mailadmins ein. Postfix besitzt einige einfache Maßnahmen gegen Spam, die durch weitere externe Filter wie etwa Spamassassin ergänzt werden können.
Der Vorteil einiger postfixinterner Spamabwehrmaßnahmen ist, daß die betreffenden Spammails bereits beim Einlieferungsversuch abgewiesen werden. Externe Filter wie etwa Spamassassin, sind darauf angewiesen, das die Mail bereits durch den Mailserver angenommen wurde, um mit Ihrer Arbeit zu beginnen. Bei den postfixinternen Maßnahmen wird dadurch im Vergleich zu externen Filtern Kapazität gespart. Außerdem erzeugt eine direkte Ablehnung der Mail eine Fehlermeldung, die der Mailserver seinem ursprünglichen Kunden weitergeben kann. Sollte eine Mail also versehentlich als Spam deklariert worden sein (false positive) bekommt der Mailversender direkt eine Fehlermeldung (sogenannter "Mailer-Daemon"). Zwar könnte auch ein externer Filter nach der Annahme eine Rückantwort schicken, falls eine Mail verworfen wird, aber Spammer fälschen Absenderadressen. In so einem Fall würde also jemand völlig ahnungsloses eine Fehlermeldung per Mail erhalten, dessen Adresse einfach als Absenderadresse von Spammern mißbraucht wurde. Solche Bounces sind oft genauso ärgerlich wie der Spam selber.
Die Postfixinternen Spamabwehrmaßnahmen gliedere ich hier in 3 Kategorien: Korrektheitsprüfungen, DNS-Blacklists und Inhaltsfilter.
Korrektheitsprüfungen
Als Korrektheitsprüfungen fasse ich hier Maßnahmen zusammen, die überprüfen ob bestimmte Angaben des einliefernden Mailservers, bzw. der Versandadresse überhaupt korrekt sein können. Sind sie nicht korrekt wird davon ausgegangen das es sich um Spam handelt. Als Beispiel dafür: Manchmal setzen Spammer Absenderadressen ein, deren Domain gar nicht existiert. Da man schlecht auf Mail antworten kann, deren Absenderdomain noch nicht mal im DNS bekannt ist, kann man in so einem Fall davon ausgehen das es sich um Spammails handelt und solche Mails einfach abweisen. Dazu muß Postfix nur prüfen ob die Absenderdomain existiert. Dies läßt sich durch folgenden Parameter in der main.cf erreichen:
smtpd_sender_restrictions = reject_unknown_sender_domain
Versucht nun jemand eine Mail einzuliefern deren Absenderdomain unbekannt ist, wird er mit einer Fehlermeldung abgewiesen. Diese Fehlermeldung hat hier als Standard einen 4xx Fehlercode. Das SMTP-Protokoll kennt Fehlermeldungen mit 4xx Statuscodes und mit 5xx Statuscodes. 4xx Statuscodes stehen für temporäre Fehler. In diesem Fall sollen einliefernde Clients es später noch mal versuchen. 5xx Statuscodes stehen für dauerhafte Fehler, der Client soll es nicht noch mal versuchen. Wer solche Clients daher mit einer 5xx Stausmeldung abweisen will kann folgenden Parameter benutzen:
unknown_address_reject_code = 554
Eine noch etwas strengere Prüfung stellt die Überprüfung dar, ob der einliefernde Host im DNS einen gültigen A- und PTR-Eintrag besitzt. Dies sollte eigentlich bei einem Mailserver stets der Fall sein (wovon man allerdings auch nicht unbedingt immer ausgehen kann), so das man Mails von Hosts auf die dies nicht zutrifft als Spam ablehnen kann:
smtpd_client_restrictions = reject_unknown_client
unknown_client_reject_code = 554
Auch hier wird durch den zweiten Parameter der Fehlercode von 4xx in einen 5xx Statuscode gewandelt.
DNS-Blacklists
DNS-Blacklists, manchmal auch als Realtime Blacklists (RBL) bezeichnet, sind Listen von Anbietern die bekannte Spamquellen einfach in eine DNS-Zone eintragen. Solche Blacklists sind praktisch da man zu deren Nutzung nicht viel machen muß und einen recht großen Teil des Spamaufkommens einfach los wird. DNS-Blacklists haben aber auch Nachteile: Sie sollten sich mit der Policy des Anbieters vertraut machen, da sie bei Anwendung der Blacklists einem anderen Anbieter vertrauen, wer ihnen noch Mail zusenden darf und wer nicht. Sollte der Anbieter zu scharf dabei sein, Spamquellen in die Blacklist aufzunehmen, könnte dies zu false positives führen.
DNS-Blacklists existieren von verschiedenen Anbietern, manche sind kostenlos, manche verlangen für die Nutzung etwas. Ein Beispiel für eine kostenlose DNS-Blacklist ist die Nixspam Blacklist des heise-Verlages in der Zone ix.dnsbl.manitu.net (siehe: http://www.heise.de/ix/nixspam/dnsbl/). Wenn sie solch eine Liste verwenden wollen, müssen sie nur die smtpd_recipient_restrictions entsprechend ergänzen:
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_rbl_client ix.dnsbl.manitu.net,
reject_unauth_destination
Der Wert reject_rbl_client, sowie die entsprechende DNS-Zone sind alles was sie in smtpd_recipient_restrictions ergänzen müssen.
Inhaltsfilter
Postfix kennt darüber hinaus Inhaltsfilter, die Mails nach Suchmustern absuchen und anhand von Treffern Mails abweisen oder annehmen können. Postfix unterstützt dazu als zusätzlichen Lookup-Tabellentyp, Lookup Tabellen mit regulären Ausdrücken. Reguläre Ausdrücke sind spezielle Suchmuster, die über einfache Wildcardzeichen deutlich hinausgehen. Postfix kann jeweils getrennt Mailheader und Mailbody nach Suchmustern durchsuchen. Für beide läßt sich eine Lookup-Tabelle angeben:
header_checks = regexp:/etc/postfix/headercheck
body_checks = regexp:/etc/postfix/bodycheck
Bitte beachten sie: Als Tabellentyp ist regexp angegeben, das bedeutet es handelt sich nicht um eine Datenbankdatei (die mit postmap erzeugt werden würde), sondern um eine einfache Klartextdatei die Perlkompatible reguläre Ausdrücke enthalten darf.
Die Datei headercheck könnte z. B. so aussehen:
/^Subject: [a-zA-Z]+ wartet auf dich im Live-Chat/ REJECT
/^Subject: Rolex extrabillig kauu?fen/ REJECT
Der jeweilige reguläre Ausdruck steht links, während rechts die Aktion steht, was mit einem Suchtreffer passieren soll. Als Aktion kann REJECT oder DISCARD angegeben werden. REJECT weist alle Mails mit einem 5xx Statuscode ab. DISCARD hingegen tut so als würde es die Mail annehmen verwirft sie aber sofort.
Was im Header meistens als Kriterium verwendet wird, ist der Betreff einer Email. Dieser beginnt immer am Zeilenanfang mit Subject: und einem Leerzeichen gefolgt vom Betreff. Die regulären Ausdrücke stehen immer zwischen 2 begrenzenden Schrägstrichen. Das Zeichen ^ steht für den Anfang der Zeile. /^Subject: / trifft also genau auf die Betreffzeile zu (und würde bei allen Mails die überhaupt einen Betreff enthalten treffen).
Die eckigen Klammern stehen für Zeichenklassen, das heißt, daß Zeichen das an dieser Stelle steht, kann eines der in der Zeichenklasse erwähnten Zeichen sein. Die Zeichenklasse [a-zA-Z] trifft auf einen beliebigen Groß- oder Kleinbuchstaben zu. Die Zeichen *, + und ? sind Quantifier. Quantifier machen eine Aussage darüber, wie oft das vor ihnen stehende Zeichen (oder die Zeichenklasse) wiederholt sein kann. * steht für beliebige Wiederholungen (inklusive keiner), + steht für mindestens ein vorkommen und ? steht für ein oder kein vorkommen. [a-zA-Z]+ bedeutet also das mindestens ein, aber beliebig viele Groß- und Kleinbuchstaben an dieser Stelle stehen können, was auf beliebige Wörter (aber nicht z. B. Zahlen) zutrifft und damit z. B. auch auf Namen.
Der Ausdruck kauu?fen, trifft sowohl auf kaufen, als auch auf kauufen zu, da das zweite u durch den ?-Quantifier optional ist. Dies zielt auf einen oft verwendeten Trick von Spammern ab, Inhaltsfilter durch falsche Schreibweise von Wörtern zu täuschen.
Möchten sie Zeichen, die in regulären Ausdrücken als Sonderzeichen verwendet werden, als Teil des gesuchten Zeichens verwenden, müssen sie dieses Zeichen mit einem Backslash entwerten. Möchten sie also nach "Frage?" suchen müßten sie /Frage\?/ verwenden. Der Punkt (.) ist übrigens auch ein Zeichen mit Sonderbedeutung für reguläre Ausdrücke, er steht für ein beliebiges Zeichen.
Bei der Verwendung von Inhaltsfiltern sollten sie generell darauf achten wirklich nur das zu filtern was eindeutig aussortiert werden soll um zu viele false positives zu vermeiden. Wenn sie z. B. alle Mails mit "geil" im Betreff verwerfen wollen, würde dies auch eine Mail treffen mit dem Betreff: "In Geilenkirchen scheint die Sonne".
TLS
TLS steht für Transport Layer Security (im Prinzip die modernere Variante von SSL). Postfix kann Verbindungen mit TLS verschlüsseln (sowohl als Client, wie auch als Server). Verschlüsselung macht zum Beispiel Sinn wenn Klartextpasswörter per SASL verwendet werden. Um diese Klartextpasswörter bei der Übertragung abzusichern, kann man TLS verwenden. Denken sie aber daran, daß damit nur der eine Transportweg abgesichert wird. Wenn die Mail mehrere Mailserver durchläuft kann nicht garantiert werden, das jede Verbindung bis zum Client des Empfängers verschlüsselt wird. TLS ist daher kein Ersatz zu per PGP/GnuPG verschlüsselten Mails.
Um TLS nutzen zu können benötigen sie zuerst ein Zertifikat. Außerdem müssen sie sich entscheiden, ob sie dieses Zertifikat durch eine externe CA signieren lassen, oder eine eigene CA verwenden. Für interne Zwecke ist eine eigene CA praktisch, aber wenn sie einen öffentlichen Mailserver für verschiedene Kunden betreiben, ist es besser ein von einer anerkannten CA signiertes Zertifikat zu verwenden, damit die Clients keine unnötigen Warnmeldungen bekommen.
Der private Schlüssel zum Zertifikat muß für Postfix in unverschlüsselter Form vorliegen. Mit folgenden Befehl kann man einen privaten Schlüssel, sowie einen Certificate Signing Request erzeugen, der durch eine CA signiert werden kann:
openssl req -new -nodes -keyout privkey.pem -out keyreq.req -days 730
Dies erzeugt die beiden Dateien privkey.pem, welches der private Schlüssel in unverschlüsselter Form im PEM-Format ist und die Datei keyreq.req, welche durch die CA unterschrieben werden muß. Der Parameter -nodes sorgt dafür das der private Schlüssel unverschlüsselt bleibt und mit -days 730 wird eine Gültigkeit von 2 Jahren festgelegt. Details können sie auch in der (sehr umfangreichen) Manpage von openssl nachlesen.
Nachdem sie ihr Zertifikat durch eine CA (eine eigene oder eine externe) signiert haben, müssen sie Postfix zum einen sagen, das er TLS verwenden soll, außerdem müssen sie Postfix 3 Dateien bekannt geben: Der Private Schlüssel, das signierte Zertifikat und der öffentliche Schlüssel der CA die das Zertifikat signiert hat:
smtpd_use_tls = yes
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_key_file = /etc/postfix/privkey.pem
smtpd_tls_cert_file = /etc/postfix/cert.pem
smtpd_use_tls sagt Postfix das er generell TLS für SMTP Clients anbieten soll (es gibt auch smtp_use_tls, falls Postfix selber Client ist). smtpd_tls_CAfile gibt die Datei mit dem öffentlichen Schlüssel der CA an. smtpd_tls_key_file gibt den privaten Schlüssel des Zertifikats an. Dieser private Schlüssel ist unbedingt zu schützen und sollte daher root gehören und keine Leserechte für andere Benutzer oder Gruppen haben:
chown root /etc/postfix/privkey.pem
chmod 600 /etc/postfix/privkey.pem
smtpd_tls_cert_file gibt schließlich die Zertifikatsdatei an.
Falls ihnen die hier verwendeten Begrifflichkeiten wie "privater Schlüssel" oder "CA" völlig fremd sind, ist es sinnvoll sich zunächst mit den Grundlagen der Public Key Infrastructure zu beschäftigen.
Literatur
Kyle D. Dent: Postfix, Ein sicherer und leicht zu verwaltender MTA für Unix, O'Reilly Verlag 2004.
Tobias Wassermann: Postfix ge-packt, MITP Verlag, 2006.
René Maroufi
