10    Mailserver

Dieses Kapitel zeigt Ihnen den sauberen Aufbau eines Mailrelays mit »Postfix« nebst grundlegendem Spam- und Virenschutz und erklärt wie Sie es vor einem Groupwareserver wie »Exchange« oder einem IMAP-Server wie »Dovecot« betreiben sollten. Außerdem zeigen wir Ihnen, wie Sie mit wenigen Schritten Dovecot als flexiblen und mächtigen IMAP-Server in Betrieb nehmen können.

E-Mail ist einer der ältesten Dienste im Internet überhaupt – und wird gleichzeitig von vielen Administratoren in seiner Komplexität unterschätzt. Mailserver sind mächtig und komplex, schließlich agieren sie nicht nur als Server, die auf eine konkrete Anfrage eines Clients reagieren, sondern arbeiten zugleich auch als autonom entscheidende Clients, die aufgrund eigener Logik andere Server kontaktieren und ihnen Mails zustellen. Es gibt extrem viele sinnvolle, vor allem aber auch sehr viele nicht sinnvolle Einstellungsmöglichkeiten.

Eigentlich sind Mailserver einfach. Zumindest, wenn man sich an die Regeln hält. Viele Administratoren arbeiten hier zu viel mit »Trial and Error«, glauben, es wäre egal, auf welchem Weg ein Ziel genau erreicht wird, und meinen, sie könnten an Schrauben so lange drehen, bis es dann irgendwie trickreich funktioniert. Doch genau hier werden die Komplexität der Zusammenhänge, die Auswirkungen vieler Kleinigkeiten unterschätzt. Konfigurieren Sie Mailserver immer recht penibel »im Sinne des Erfinders«, klar und stringent, und Sie werden feststellen, dass Mailserver auf einmal einfach, problemlos und pflegeleicht sein können.

10.1    Postfix

Postfix wurde 1997 von IBM zunächst unter den Namen VMailer und Secure Mailer entwickelt, um eine schnelle, sichere und bequem zu administrierende Alternative zum verbreiteten Sendmail zu bieten. Postfix-Autor Wietse Zweitze Venema hatte sich bereits viele Lorbeeren als Autor der TCP-Wrapper-Bibliothek (/etc/host.allow und /etc/host.deny) und als Autor des Netzwerkscanners Saint/Satan erworben.

Als Spezialist für sichere Programmierung nutzte er die Gelegenheit und gab Postfix von vornherein ein sicheres Design und klare Entwicklungsprinzipien mit auf den Weg. Durch die Aufteilung in verschiedene, möglichst kleine, überschaubare Module konnte eine klare Aufgaben- und Rechtetrennung durchgesetzt werden, um Fehler und Angriffsflächen zu minimieren. Wann immer es irgendwie geht, wird auf den Einsatz von root-Rechten verzichtet. Und das hat Erfolg: Im Gegensatz zu seinen Mitbewerbern ist für Postfix bis heute kein einziger root-Exploit bekannt geworden.[ 10 ]

Postfix wird bis heute sehr aktiv weiterentwickelt und bietet auch bei neuen Entwicklungen wie DANE stets als eines der ersten Programme eine funktionierende Implementierung in mustergültiger Qualität.

10.1.1    Grundlegende Konfiguration

Ein frisch installierter Postfix-Server ohne besondere Konfigurationsanpassungen ist an sich bereits ein lauffähiger, funktionierender Mailserver. Mails aus dem Internet nimmt er an, wenn sie an seinen Hostnamen adressiert sind und er die Empfänger in /etc/passwd vorfindet. Gleichzeitig akzeptiert er Mails seiner lokalen Nutzer und von Hosts in seinem eigenen Subnetz und sendet sie auch an externe Ziele ab, die er über DNS-MX-Records ermitteln kann.

Die Konfiguration von Postfix spielt sich in /etc/postfix ab, namentlich in den beiden Dateien main.cf und master.cf. Dazu gesellen sich je nach Konfiguration zahlreiche weitere Hilfsdateien mit Domainlisten, Weiterleitungen oder White- und Blacklists, auf die durch entsprechende Parameter aus der main.cf verwiesen wird.

Bevor Sie mit der Konfiguration ans Eingemachte gehen, müssen Sie in Ihrer main.cf einige grundlegende Einstellungen klären:

Je nach Version und Paketierung kennt Postfix derzeit gut und gerne 800 Parameter, weil so gut wie alles bei Postfix über einen Parameter einstellbar ist. Alle diese Werte haben einen sinnvollen Default-Wert und stehen auch längst nicht alle in der main.cf.

Dort finden Sie normalerweise nur diejenigen Parameter, die Sie abweichend vom DefaultWert tatsächlich anpassen wollen. In der Praxis werden das selbst in komplexeren Setups nur rund 20 bis 30 Optionen sein.

Über das Tool postconf können Sie jederzeit abfragen, welchen Wert ein Parameter aus Sicht von Postfix hat:

mail:~ # postconf myhostname
mail.example.com

mail:~ # postconf mynetworks
mynetworks = 127.0.0.0/8 192.168.200.0/24 10.0.40.6/32

Listing 10.2    »postconf« zeigt den Inhalt der Postfix-Parameter.

[+]  »systemd« versus »syslog«

In Sachen Logging verlassen sich viele Distributionen mittlerweile ganz auf systemd und dessen eigene Log-Funktionalitäten. Diese sind für den gelegentlichen Blick auf einzelne Prozesse auch durchaus praktisch und haben verschiedene Vorteile, auf einem Mailserver jedoch werden fortlaufend große Mengen Log-Meldungen zu jeder einzelnen E-Mail erzeugt, die gegebenenfalls auch archiviert und nach Tagen noch durchsucht werden müssen. Wir empfehlen Ihnen, dafür weiterhin auf den guten alten (r)syslog zu setzen. Wenn Ihr Logfile in /var/log/mail (SUSE) bzw. /var/log/mail.log (Debian/Ubuntu) leer bleibt bzw. gar nicht erst angelegt wird, so prüfen Sie, ob (r)syslog bei Ihnen überhaupt installiert wurde, und holen Sie diese Installation kurzerhand nach (siehe Kapitel 12, »Syslog«). Sobald (r)syslog läuft, wird sich auch Ihr Mailserver-Logfile wieder mit hilfreichen Meldungen füllen.

10.1.2    Postfix als Relay vor Exchange, Dovecot oder anderen Backends

Damit Postfix auch als Relay vor anderen Servern E-Mails annehmen kann, müssen Sie noch die Parameter relay_domains und transport_maps setzen. Der erste sorgt dafür, dass Postfix Mails an die gewünschten Domains annimmt, der zweite sorgt dafür, dass Postfix diese Mails auch wieder an das gewünschte Ziel weiterleiten kann.

Die Angabe von transport_maps ist hier ausnahmsweise notwendig, da Postfix sich in diesen Fällen nicht mehr auf die MX-Records im DNS verlassen kann, denn diese zeigen ja auf ihn selbst als das für das Internet zuständige Mailrelay.

Üblicherweise versenden Mailserver E-Mails über das SMTP-Protokoll auf Port 25. Auf der »letzten Meile« zwischen Mailrelay und Exchange- oder IMAP-Server kommt jedoch besser der kleine Bruder Local Mail Transfer Protocol (LMTP) auf Port 24 zum Einsatz. LMTP unterscheidet sich nur in kleinen Details von SMTP, es ist, wenn man so will, eine Art SMTP-Dialekt.

Mailserver können bei Mails an mehrere Empfänger gleichzeitig per LMTP einfacher feststellen, ob die Mail in den verschiedenen Postfächern gespeichert werden konnte oder ob Quotas, Blacklisting oder andere Fehler dies verhindert haben.

Legen Sie darum eine zweispaltige Datei /etc/postfix/relay_domains an, in der Sie sowohl die Domains als auch das jeweilige Routing-Ziel auf Basis des LMTP- oder SMTP-Protokolls eintragen:

# Diese Domain wird an einen lokalen Dovecot-/Cyrus-Server weitergegeben
example.com     lmtp:[127.0.0.1]

# Diese Domain wird an einen entfernt laufenden Exchange-Server geroutet
example.net     lmtp:[exchange.example.net]

# Diese Sub-Domain leiten wir per SMTP an den Mailinglistenserver weiter
listen.example.org      smtp:[listenserver.example.org]

Listing 10.3    Die Syntax der kombinierten Relay-Domains- und Routing-Tabelle

Setzen Sie Hostnamen dabei stets in eckige Klammern, wenn Sie exakt diesen Mailserver, also die IP-Adresse hinter diesem Servernamen, ansprechen wollen. Lassen Sie die eckigen Klammern weg, würde Postfix zuerst prüfen, ob für diesen Server ausdrücklich MX-Records im DNS hinterlegt sind, und dann dorthin zustellen. Nur hilfsweise würde er sonst auf die A-Records dieser Hostnamen zurückgreifen.

Nun können Sie aus der main.cf mit relay_domains auf diese Tabelle verweisen und gleichzeitig Postfix über transport_maps anweisen, für Routing-Einträge neben der normalen /etc/postfix/transport auch alle Tabellen von relay_domains zu verwenden.

relay_domains = hash:/etc/postfix/relay_domains
transport_maps = hash:/etc/postfix/transport, $relay_domains

Listing 10.4    Relay-Domains in Postfix einrichten

So haben Sie alle Routing-Fragen Ihrer zu relayenden Domains mit nur einem einzigen Eintrag in /etc/postfix/relay_domains geklärt. Die Datei /etc/postfix/transport benötigen Sie für Ihre eigenen Domains nicht – aber vielleicht möchten Sie hier in Ausnahmefällen einmal Routing-Einträge für Domains anderer Provider eintragen (deren E-Mails Sie deswegen ja nicht gleich als Relay aus dem Internet annehmen wollen).

Einige Distributionen haben /etc/postfix/transport noch nicht einmal als leere Datei vorbereitet. Wenn Sie über transport_maps auf eine nicht existente Datei verweisen, muss Postfix seine Arbeit einstellen. Legen Sie im Zweifelsfall /etc/postfix/transport als leere Datei an, und übersetzen Sie sie mit dem postmap-Kommando in eine Berkeley-Datenbank:

mail:~ # touch /etc/postfix/transport
mail:~ # ls -la /etc/postfix/transport*
-rw-r--r-- 1 root root     0 Mar 26 09:51 /etc/postfix/transport
mail:~ # postmap /etc/postfix/transport
mail:~ # ls -la /etc/postfix/transport*
-rw-r--r-- 1 root root     0 Mar 26 09:51 /etc/postfix/transport
-rw-r--r-- 1 root root 12288 Mar 26 09:52 /etc/postfix/transport.db

Listing 10.5    Relay-Domains in Postfix einrichten

Hash- und Btree-Tabellen erfordern ein »postmap«-Kommando

Sobald Postfix in seiner Konfiguration angewiesen wird, über hash: oder btree: auf seine Tabellen zuzugreifen, müssen Sie nach jeder Änderung in der Datei das Kommando postmap <filename> ausführen, also beispielsweise postmap relay_domains, postmap transport oder postmap access_recipient. Das postmap-Kommando wandelt die Dateien in eine kleine Berkeley-Datenbank mit der Endung .db um – und nur diese Datei wird von Postfix letzten Endes ausgewertet, auch wenn die .db-Endung nicht in der Konfiguration genannt ist.

10.1.3    Die Postfix-Restrictions: Der Schlüssel zu Postfix

Zu einem richtigen Mailserver gehört natürlich weit mehr als nur der Umstand, dass er Mails an bestimmte Domains von überall her annimmt bzw. Mails der eigenen IP-Bereiche an den Rest der Welt versenden kann. Spam-Schutzmaßnahmen, Empfängerprüfungen oder White-/Blacklists gehören zur elementaren Grundausstattung eines Mailservers und zur täglichen Arbeit eines Postmasters.

Ob eine Mail angenommen wird oder nicht, entscheidet sich dabei ganz wesentlich schon bevor der eigentliche E-Mail-Inhalt übertragen wird. Bereits aus den Daten des SMTP-Protokolls lässt sich in vielen Fällen erkennen, dass eine Mail unerwünscht ist, die absendende IP-Adresse als Spam-Versender aufgefallen ist oder dass die Verbindung aus anderen Gründen als verdächtig gelten muss.

All das entscheidet sich bei Postfix in den sogenannten Restrictions. Passend zu den fünf Stufen einer SMTP-Übertragung gibt es fünf Restrictions, die zu verschiedenen Zeitpunkten durchlaufen werden:

Viele Anleitungen erklären, dass an verschiedenen Stellen in den Restrictions nun umfangreiche Konfigurationsarbeiten notwendig seien: Sender-Blacklistings (smtpd_sender_ restrictions), RBL-(Real-time Black-list-)Abfragen (smtpd_client_restrictions) und vieles andere mehr. Doch dieser Aufwand und diese Komplexität sind nicht nur überflüssig, sie verhindern in den meisten Fällen sogar eine gute Konfiguration. Denn ob eine Mail wirklich angenommen werden soll oder nicht, kann in manchen Fällen erst nach Bekanntgabe des Empfängers, also nach dem RCPT TO:-Kommando entschieden werden. So soll ein gesperrter Absender beispielsweise noch beim Helpdesk oder Postmaster um Rat fragen können. Insofern müssen Sie wissen, wer der Empfänger ist, bevor Sie entscheiden, ob Sie den Absender ablehnen wollen. Hinzu kommt, dass Postfix vorhandenes Wissen sowieso nicht vergisst. Auch in den smtpd_recipient_restrictions können noch Absender-Sperrlisten oder RBL-Abfragen über die Client-IP-Adresse ausgeführt werden. Auch aus dieser Sicht gibt es keinen Grund, »zu früh« zu prüfen.

Aufgrund eines falschen Grundverständnisses und auch halbgar zusammengestellter Postfix-HowTos hatten sich in der Praxis viele gefährliche Konfigurationsfehler in die Restrictions eingeschlichen. Mit Postfix-Version 2.10 hat Postfix-Autor Wietse Zweitze Venema darum vor die smtpd_recipient_restrictions noch die smtpd_relay_restrictions gestellt. Beide werden direkt nacheinander durchgeprüft. Insofern sind die smtpd_relay_restrictions überflüssig, scheinen Einsteigern an verschiedenen Stellen aber zu helfen, den Überblick zu behalten und die Konfiguration für ausgehende bzw. für eingehende Mails besser auseinanderhalten zu können. Eine Hilfe, die man nutzen kann, aber nicht nutzen muss.

Wir ziehen es vor, alle gewünschten Prüfungen übersichtlich und logisch konsequent an einer einzigen Stelle zusammenfassen zu lassen: in den smtpd_recipient_restrictions. Hier kommt es entscheidend auf die richtige Reihenfolge an, damit sich keine Prüfungen widersprechen oder in der falschen Reihenfolge ausgeführt werden. Denn die Prüfungen werden der Reihe nach abgearbeitet: Sobald eine Prüfung ein eindeutiges positives Ergebnis (PERMIT – Mail wird angenommen) oder negatives Ergebnis (REJECT – Mail wird abgelehnt) liefert, wird die Entscheidung ausgeführt, und auf weitere Prüfungen in dieser Restriction kommt es dann nicht mehr an (First match wins). Aus unserer langjährigen Praxis empfehlen wir folgenden Aufbau:

#
# Musterlösung smtpd_recipient_restrictions
# Heinlein Support GmbH, http://www.heinlein-support.de
# Relay-Restrictions leer setzen (alles wird in Recipient-Restrictions abgebildet)
smtpd_relay_restrictions =

smtpd_recipient_restrictions =
# White-/Blacklistings für Empfänger, Sender, HELO und Client-IPs
        check_recipient_access hash:/etc/postfix/access_recipient
        check_sender_access hash:/etc/postfix/access_sender,
        check_helo_access hash:/etc/postfix/access_helo,
        check_client_access cidr:/etc/postfix/access_client,
# Keine Mails mit nicht-existenten Absendern/Empfängern annehmen!
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
# Mails unserer Nutzer/Server erlauben!
#       permit_sasl_authenticated,
        permit_mynetworks,
# Wichtig: Andere Mails an externe Ziele verbieten
        reject_unauth_destination,
# Bei eingehenden Mails die Client-IP gegen RBLs checken
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client ix.dnsbl.manitu.net,
# Greylisting checken!
        check_policy_service inet:127.0.0.1:10023
# Dynamisch prüfen, ob der Empfänger bei Dovecot/Exchange existiert
        reject_unverified_recipient,
# Was jetzt lebt, darf durch!
        permit

Listing 10.6    Die Best Practice der Restrictions

White- und Blacklists pflegen

Die vier access-Dateien haben jeweils einen zweispaltigen Aufbau: An erster Stelle steht der Lookup Key, also der Wert, nach dem gesucht wird. In der zweiten Spalte das Result, also das Ergebnis. Dabei handelt es sich um eine Aktion, die ausgeführt wird. Die wichtigsten Aktionen sind PERMIT, um eine E-Mail anzunehmen, und REJECT, um die jeweilige E-Mail abzulehnen. Über die Manpage man 5 access können Sie jedoch noch zahlreiche weitere Möglichkeiten der access-Map entdecken.

Um Mails einer bestimmten Client-IP zu sperren oder Mails einer bestimmten Client-IP immer anzunehmen, können Sie die IP-Adressen wie folgt in die Datei access_client eintragen:

# Diese einzelne IP ist komplett gesperrt
192.168.20.20/32        REJECT
# Und auch dieses ganze /24-Subnetz darf keine Mails einliefern
192.168.100.0/24        REJECT

Listing 10.7    Client-Blacklisting

Möchten Sie einen bestimmten Empfänger whitelisten, also Mails an ihn auch dann annehmen, wenn die Client-IP eigentlich durch RBL-Sperrlisten verboten ist, so reicht ein einfacher Eintrag in den access_recipients:

# Diese Empfängeradresse wird gewhitelistet, empfängt also "immer"
user@example.com        PERMIT

Listing 10.8    Empfänger-Whitelisting

Analog dazu können Sie Hostnamen und Absender über access_helo oder access_sender blocken. Vergessen Sie anschließend das postmap-Kommando nicht!

Auch hier gilt immer: »First match wins.« Wenn Sie möchten, können Sie die Reihenfolge der access-Map-Prüfungen in den Restrictions anpassen – beispielsweise indem Sie doch zuerst check_client_access und dann erst check_recipient_access aufrufen. Das obliegt ganz Ihrer Entscheidung für den Fall, dass Sie so bestimmte Anforderungen wie beispielsweise »Ein gewhitelisteter Client darf trotzdem an gesperrte Empfänger versenden« abbilden möchten.

Nicht existente Domains ablehnen

Stößt Postfix auf einen der Parameter reject_non_fqdn_* oder reject_unknown_*_domain, prüft er, ob die jeweilige Absender-/Empfänger-Domain im DNS überhaupt existiert, das heißt, ob ein MX- oder ein A-Record für diese Domain hinterlegt ist. Ist das bei einem Empfänger nicht der Fall, kann man an diesen auch keine E-Mails senden: Wohin sollte Postfix die Mail auch routen? Und wenn man an einen Empfänger keine Mail senden kann – warum sollte Postfix sie dann überhaupt annehmen? Damit Postfix sie wenige Millisekunden später bouncen und mühsam versuchen müsste, die Mail wieder zurückzusenden?

Gleiches gilt für die inhaltsgleiche Prüfung der Absender-Domain: Wenn die Domain des Absenders gar nicht im DNS steht bzw. keinen MX- und A-Record hat, wird man auf die fragliche E-Mail nicht antworten können. Um eine normale erwünschte E-Mail wird es sich dabei also kaum handeln.

Es ist in aller Regel sinnvoll zu prüfen, ob die Absender- oder Empfänger-Domain auch für ausgehende E-Mails der eigenen Nutzer existiert. Schließlich wollen Sie weder, dass Ihre eigenen Nutzer mit nicht existenten Domains Mails versenden, geschweige denn macht es für Sie Sinn, Ihren Nutzern Mails an per Definition nicht zustellbare Domains abzunehmen.

In manchen Unternehmen hat es sich jedoch eingebürgert, für interne Hostnamen und Mailadressen example.local zu verwenden. Da diese .local-Domains nie im DNS auflösbar wären, würden die hier gezeigten Regeln auch den internen Mailverkehr blocken. Nutzen Sie lokal nicht valide Domains, so dürfen Sie diesen Domaincheck erst nach permit_mynetworks und/oder permit_sasl_authenticated durchführen:

smtpd_recipient_restrictions =
[…]
# Alle Mails unserer Nutzer/Server erlauben!
#       permit_sasl_authenticated,
        permit_mynetworks,
# Keine Mails mit nicht-existenten Absendern/Empfängern von extern annehmen!
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
[…]

Listing 10.9    Domainprüfungen nach »mynetworks«

Interne E-Mails der eigenen User werden so auch mit kaputten Domains akzeptiert, der DNS-Check greift nur noch für Mails von externen Absendern – und diese können und sollen sowieso keine Mails an die .local-Adressen schreiben.

RBLs/DNSBLs benutzen

DNS-Blacklists (DNSBLs) gibt es viele im Internet – genauer müsste man jedoch sagen: gab es viele im Internet. Die meisten wurden geschlossen oder werden nicht mehr aktiv gepflegt, weil die Betreiber sich anderweitig orientiert haben oder die Qualität nicht halten konnten. Das heißt nicht, dass RBL-Blacklists schlecht und nicht empfehlenswert seien. Ganz im Gegenteil: Dank RBLs können Sie mit extrem wenig Ressourceneinsatz bereits rund 60 bis 70 % aller eingehenden Spam-Mails blocken. Sie müssen lediglich aufpassen, wem Sie hier vertrauen. Wir empfehlen Ihnen, ausschließlich die unten genannten RBLs zu verwenden, da sie ein seriöses, ständiges Betreiberteam, eine klare Listing-Policy und eine extrem hohe Qualität haben. Erfahrungsgemäß sind Sie damit bestens bedient. Sollten Sie sich weitere RBLs aus anderen Quellen und Anleitungen zusammensuchen wollen, so sollten Sie immer darauf achten, ob die jeweiligen Listen überhaupt noch betrieben werden, und zudem prüfen, nach welchen Bedingungen dort IP-Adressen gelistet werden bzw. auch wieder von der Liste gestrichen werden.

Eine RBL-Abfrage (Realtime Blacklists) besteht aus einer speziellen DNS-Abfrage an die jeweilige RBL-Domain – in unserem Beispiel zen.spamhaus.org oder ix.dnsbl.manitu.org. Dabei wird die IP-Adresse des zu überprüfenden Clients (192.168.10.20) umgedreht und als Hostname unter der RBL-Domain abgefragt, also als 20.10.168.192.zen.spamhaus.org. Existiert ein Host mit diesem Namen, ist die IP-Adresse auf der Sperrliste enthalten. Liefert das DNS-System für diesen Hostnamen keinen Eintrag, ist die IP-Adresse nicht gelistet. Aus diesem Grund werden RBL-Listen etwas korrekter auch als DNS-Blacklist (DNSBL) bezeichnet.

DNSBLs sind sehr effektiv gegen Spam, bergen aber immer die Gefahr, auch erwünschte Mails abzulehnen. Seriöse RBL-Betreiber listen eine IP-Adresse nur dann, wenn von dieser IP aus nachweisbar aktuell Spam versandt wird, also »eine akute Gefahr« ausgeht.

Lizenzbedingungen der Spamhaus-RBL

Spamhaus agiert seit Jahren als weltweite Non-Profit-Organisation gegen Spam und kennt sich in der Szene ausgezeichnet aus. Bitte beachten Sie, dass die Verwendung der SpamhausRBL, insbesondere bei mehr als 100.000 eingehenden Mails pro Tag, gegebenenfalls kostenpflichtig sein kann, um die immensen Betriebskosten der über 50 DNSServer weltweit und des rund um die Uhr aktiven Administrations- und ResearcherTeams wieder refinanzieren zu können. Weitere Informationen finden Sie unter:

www.spamhaus.org/organization/dnsblusage/

Greylisting

Der größte Teil des heutigen Spams wird über Botnetze versandt, also in aller Regel durch vireninfizierte Windows-PCs. Spam von Botnetzen lässt sich hervorragend durch Greylisting abwehren: Dabei werden Verbindungen bislang unbekannter IP-Adressen zunächst temporär mit einem 4xx-Fehler abgelehnt. Da es sich um einen temporären und nicht um einen fatalen Fehler handelt, geht die Mail dabei nicht an den Absender zurück, sondern verbleibt in der Mail-Queue des einliefernden Mailservers und wird wenige Minuten später erneut zugestellt.

Da sich der Mailserver beim ersten Versuch in einer kleinen Datenbank die IP-Adresse, die Absender- und die Empfänger-Mailadresse zusammen mit einem Zeitstempel gemerkt hat, wird er einen Wiederholungsversuch als bekannt identifizieren und wird – sofern die übliche Wartezeit von fünf Minuten erreicht wurde – die Mail annehmen und sich die Client-IP in seiner Datenbank für lange Zeit merken, damit zukünftige Mails dieser IP direkt ohne Verzögerung akzeptiert werden. Insofern ist Greylisting in seinen Auswirkungen sehr harmlos: Mailserver werden automatisch gelernt, und bereits bekannte Systeme erfahren gar kein Greylisting mehr. Oder anders ausgedrückt: Nur erste E-Mails bislang unbekannter Systeme werden kurzfristig verzögert.

Durch Greylisting können Sie sehr effektiv prüfen, ob das einliefernde System ein echter normaler Mailserver ist (der queuen kann) oder ob es sich dabei um ein Spam-Botnetz handelt. Denn: Aus technischen Gründen ist es für Spammer in aller Regel wenig sinnvoll, tatsächlich erneut wiederzukommen: Der Spammer verschwendet durch Wiederholungsversuche wertvolle Ressourcen, die er bei anderen Opfern (im wahrsten Sinne des Wortes) gewinnbringender einsetzen kann. Denn die Zeit arbeitet gegen den Spammer: Mit jeder Minute, die der Spammer länger am Werk ist, wird die Chance steigen, dass die Vireninfektion entdeckt und sein Bot abgeschaltet wird, die IP des Servers geblacklistet oder die von ihm versandte Spam-Mail durch andere Anti-Spam-Verfahren als bekanntermaßen unerwünscht klassifiziert und deswegen abgelehnt wird. Darum gilt für Spammer nach wie vor: »Fire and forget« – schnell rein, schnell raus. Spammer könnten Greylisting durch Wiederholungsversuche überleben, aber sie machen dies größtenteils nicht, weil es mehr Nachteile als Vorteile hat.

Auch unter Virenschutzaspekten ist Greylisting wünschenswert, werden durch Botnetze doch ebenso auch Viren verschickt, und je länger ein Virenausbruch bereits läuft, umso eher wird er von Ihrem Virenkiller erkannt werden können. Insofern ist Greylisting auch ein sehr effektiver und wichtiger Teil eines mehrstufigen Antivirenschutzes und deckt den heiklen Zeitraum zwischen dem ersten Auftreten eines Virus und dem Erscheinen entsprechender Signatur-Updates der Antivirenhersteller ab.

Die beste Greylisting-Implementierung im Zusammenspiel mit Postfix ist Postgrey, ein Programm von David Schweikert, der mit Pflogsumm ja auch bereits einen schönen LogfileReporter für Postfix geschrieben hat. Postgrey ist mit wenigen Handgriffen installiert und bedarf keiner weiteren Pflege. Es nutzt ein paar lokal gespeicherte Berkeley-Datenbanken, in denen es auch selbsttätig aufräumt.

Installieren Sie das Paket postgrey, und starten Sie den Dämon:

mail:~ # systemctl start postgrey

Listing 10.10    Der Start von »postgrey«

Ein kurzer Blick in die Prozessliste zeigt, ob Ihre Distribution den Dämon per Default auf einen UNIX-Socket lauschen lässt (so unter CentOS/openSUSE Leap):

mail:~ # ps ax | grep postgrey
 9331 ?        Ss     0:00 /usr/sbin/postgrey -d \
                          --unix=/var/spool/postfix/postgrey/socket \
                          --auto-whitelist-clients

Listing 10.11    Aufrufparameter definieren einen UNIX-Socket-Typ.

Falls Ihre Distribution per Default einen TCP/IP-Socket für den Dämon vorbereitet hat (Debian/Ubuntu), sieht der Befehl so aus:

mail:~ # ps ax | grep postgrey
23238 ?        Ss     0:00 /usr/sbin/postgrey -d --inet=127.0.0.1:10023 \
                      --auto-whitelist-clients

Listing 10.12    Aufrufparameter definieren einen TCP-Socket-Typ.

Sie könnten das Verhalten von Postgrey natürlich auch umkonfigurieren, aber am Ende ist es viel einfacher, in Postfix wahlweise einen UNIX- oder einen TCP-Socket zu konfigurieren, als sich mit einer individuellen Postgrey-Konfiguration abzumühen.

Postgrey ist ein Postfix Policy Daemon, er wird von Postfix über das Postfix-interne Postfix Policy Delegation Protocol angesprochen, sodass hier keine Konfigurationsarbeit nötig ist. Sie müssen Postfix in den smtpd_recipient_restrictions nur sagen, wo er den Policy-Dämon finden und um Rat fragen soll.

Unter openSUSE Leap bzw. bei Verwendung eines UNIX-Sockets lautet der Aufruf:

# Greylisting checken!
        check_policy_service unix:postgrey/socket

Listing 10.13    Aufruf von »postgrey« durch Postfix über einen UNIX-Socket

Alternativ lautet er unter Debian/Ubuntu bei Verwendung eines TCP-Ports:

# Greylisting checken!
        check_policy_service inet:127.0.0.1:10023

Listing 10.14    Aufruf von »postgrey« durch Postfix über einen TCP-Socket

Diesen Aufruf müssen Sie an passender Stelle in Ihre smtpd_recipient_restrictions integrieren: nach mynetworks (damit Ihre eigenen User nicht von Greylisting betroffen sind) und vor der endgültigen Annahme der E-Mail. Listing 10.6 zeigte, wo der beste Platz dafür ist.

Dynamische Empfängervalidierung

Damit Postfix als Relay vor einer anderen Mailserver-Software richtig arbeiten kann, muss Postfix in der Lage sein, unbekannte Empfänger von vornherein ablehnen zu können. Da so gut wie alle Spam- und Virenmails mit gefälschten Absendern unbeteiligter Dritter versendet werden, darf Postfix keinesfalls erst nach der Annahme feststellen, dass eine Mail unzustellbar ist. Würden Mailserver angenommene, aber unzustellbare Spam-Mail verspätet bouncen (Late Bounce), würde der unbeteiligte Dritte dermaßen viele Mailrückläufer aus aller Welt erhalten, dass es für ihn einem DDoS (Distributed Denial of Service) gleichkäme. Mailserver, die verspätet bouncen, nennt man Backscatter-Systeme (to backscatter – »zurückwerfen, zurückstreuen«). Backscatter-Systeme werden völlig zu Recht selbst auf RBL-Sperrlisten geführt, da von ihnen eine Gefahr für andere Systeme ausgeht.

Klassischerweise hat man in vorgeschalteten Mailrelays früher statische Empfängerlisten gepflegt oder eine Abfrage eines LDAP- oder AD-Servers eingerichtet. Doch das geht mit Postfix seit vielen Jahren deutlich eleganter, denn Postfix kann über SMTP/LMTP-Verbindungen zum Zielserver bequem und vom Nutzer unbemerkt testen, ob dieser eine bestimmte Empfängeradresse akzeptieren würde. Dabei wird keine wirkliche E-Mail abgeschickt, denn nachdem das Zielsystem seine Antwort auf das RCPT TO:-Kommando offenbart hat, sendet Postfix ein QUIT und beendet die Verbindung, ohne eine E-Mail abgesandt zu haben. Das Ergebnis wird für einige Stunden (unbekannter Empfänger) bis hin zu vielen Tagen (bekannter Empfänger) von Postfix gecacht.

Alles in allem ist dies ein ressourcenschonender, verblüffend trivialer und gut funktionierender Mechanismus, der noch nicht einmal besondere Freigaben in der Firewall benötigt. Die sowieso schon vorhandene SMTP/LMTP-Verbindung zum Zielserver genügt. Selbstverständlich berücksichtigt Postfix dabei für seine Testmails Routing-Tabellen wie die transport_maps oder die Umschreibung von E-Mail-Adressen durch die canonical- oder virtual-Maps. Eine Verify-E-Mail wird darum stets genauso behandelt wie eine echte E-Mail auch. Sie wird halt nur nie abgeschickt.

Per Default ist bei heutigen Postfix-Versionen alles vorbereitet. address_verify_database zeigt auf ein Daten-Directory von Postfix, in dem es in einer kleinen Berkeley-Datenbank seinen lokalen Cache der existierenden und nicht existierenden Adressen aufbauen kann:

mail:~ # postconf address_verify_map
address_verify_map = btree:$data_directory/verify_cache

Listing 10.15    Die »address_verify_map« cacht alle Einträge.

Dieser Cache ist für den Administrator vollständig pflegefrei, denn Postfix räumt seinen verify_cache automatisch auf und löscht veraltete Einträge.

# Nach 3 Stunden prüft Postfix erneut und erkennt,
# dass Adressen plötzlich existieren
address_verify_negative_refresh_time = 3h
address_verify_negative_expire_time = 3d

# Nach 7 Tagen prüft Postfix existierende Adressen erneut
address_verify_positive_refresh_time = 7d
address_verify_positive_expire_time = 31d

Listing 10.16    Die Caching-Zeiten der »verify«-Datenbank

Existierende Adressen erfahren relativ spät nach sieben Tagen eine erneute Überprüfung. Existiert diese Adresse nicht mehr, wechselt sie nun auf »negativ«, also nicht existent. Ist ein Refresh der Adresse jedoch nicht möglich, zum Beispiel weil das nachgeschaltete System derzeit nicht erreichbar ist, darf Postfix die Adresse bis zu 31 Tage lang als gültig betrachten und Mails annehmen. Auch Mailadressen, von denen Sie nur selten etwas empfangen, sind so mit hoher Wahrscheinlichkeit im Cache und werden von Ihrem Postfix-Relay auch dann noch zuverlässig angenommen, wenn Ihr eigentlich dahintergeschaltetes Mailsystem einige Tage lang nicht erreichbar ist.

Nicht existente Adressen erfahren bereits nach drei Stunden eine erneute Überprüfung, schließlich wollen Sie nicht unnötig lange Mails an frisch eingerichtete Accounts ablehnen. Bereits nach drei Tagen würden nicht existente Adressen jedoch endgültig gelöscht werden, damit Spammer, die viele Adressen ausprobieren, nicht unnötig Ihren Cache verstopfen können.

Die Default-Werte von Postfix haben sich hier als sehr praktikabel erwiesen; wir raten Ihnen, diese Werte beizubehalten.

Um die dynamische Empfängervalidierung nutzen zu können, müssen Sie an passender Stelle den Aufruf reject_unverified_recipient in Ihre smtpd_recipient_restrictions einfügen: nach mynetworks und permit_sasl_authenticated, damit Sie keinesfalls ausgehende E-Mails bei anderen Providern überprüfen, und auch nach Spam-Schutzmaßnahmen wie RBL- und Greylisting, damit Sie nicht unnötig Verify-Abfragen starten, obwohl Sie die E-Mail des Spammers sowieso nicht annehmen werden. Listing 10.6 zeigte, wo Sie reject_unverified_recipient am besten in die Restrictions einbauen.

10.1.4    Weiterleitungen und Aliasse für Mailadressen

Auf einem Mailserver gibt es häufig auch virtuelle Mailadressen, also Mailadressen, die selbst keinen eigenen Account besitzen, sondern als Weiterleitung auf andere Accounts ausgestaltet sind. Postfix regelt diese Weiterleitungen über die virtual_alias_maps-Abfrage, über die Sie beliebige Mailadressen umschreiben, also weiterleiten lassen können. Am einfachsten verwalten Sie Weiterleitungen in der Textdatei /etc/postfix/virtual.

Definieren Sie dazu in Ihrer main.cf den Verweis auf die Datei wie folgt:

virtual_alias_maps = hash:/etc/postfix/virtual

Listing 10.17    Verweis auf die Virtual-Map von Postfix

Legen Sie dann in /etc/postfix/virtual wie folgt Weiterleitungen an:

# Alle Mails von Klaus an Susi weiterleiten:
klaus@example.com           susi@example.com

# Den Role-Account "support" an mehrere Admins verteilen lassen
support@example.com         micha@example.com, beate@example.com, joerg@example.com

# Alle anderen Empfänger als catch-all an info@ weiterleiten
@example.com                info@example.com

Listing 10.18    Definition von Weiterleitungen in der Virtual-Map

Vergessen Sie nicht, anschließend das Kommando postmap /etc/postfix/virtual auszuführen! Ansonsten bekommt Postifx davon nichts mit.

Übrigens: Haben Sie neben Ihren Domains aus $relay_domains noch alternative Domainschreibweisen, die jedoch allesamt eine identische Userschaft aufweisen, können Sie mit wenigen Handgriffen diese »Marketing-Domains« annehmen und auf Ihre HauptDomain mappen lassen.

# Die virtuelle Domain bei postfix anmelden, damit er Mails an diese Domain annimmt.
# Diese Domains dürfen dann nicht mehr in relay_domains gelistet werden!
example.net             anything

# Alle Mails von example.net auf example.com umschreiben lassen:
@example.net            @example.com

Listing 10.19    Definition von virtuellen Domains

Der Userpart der Mailadressen wird dabei stets beibehalten. Aus klaus@example.net wird also klaus@example.com.

[+]  In Abschnitt 17.16, »Verwaltung von Weiterleitungen für den Mailserver Postfix«, zeigen wir Ihnen übrigens, wie Sie die »virtual_alias_maps«-Abfrage an LDAP anbinden können.

10.1.5    SASL/SMTP-Auth

Ein Mailserver darf keinesfalls als Open Relay Mails für beliebige Nutzer an externe Adressen annehmen und weiterleiten. Spammer würden das mit Handkuss sofort ausnutzen. Lediglich Client-IPs, die aus $mynetworks stammen, oder User, die sich mit Usernamen und Passwort authentifizieren (SMTP-Auth), dürfen über einen Mailserver an externe Ziele relayen.

Doch: Sendet ein Nutzer Username und Passwort, ist Postfix gar nicht in der Lage, diese Angaben selbst zu überprüfen. Stattdessen delegiert er diese Aufgabe über das SASL-Verfahren an IMAP-Server wie Cyrus oder Dovecot, die ja bereits eine funktionierende Userauthentifizierung besitzen müssen.

Während das Zusammenspiel von Postfix und Cyrus traditionell immer recht heikel war, finden Postfix und Dovecot mit wenigen Handgriffen nahtlos zusammen. Im auth-Modul von Dovecot wird mit wenigen Zeilen ein eigener Authentifizierungs-Socket geöffnet, mit dem sich Postfix verbinden kann und mit dem er von Haus aus umzugehen weiß. Um SASL mit Dovecot in Postfix zu aktivieren, ergänzen Sie die main.cf von Postfix wie folgt:

smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot

Listing 10.20    Die SASL-Parameter in Postfix

Dies aktiviert nur die SMTP-Auth-Unterstützung in Postfix generell, zieht aber noch keine Konsequenzen in der Mailannahme nach sich. Dazu müssen Sie an passender Stelle in den smtpd_recipient_restrictions den Parameter permit_sasl_authenticated anführen. Postfix wird dann an dieser Stelle die Mails der Nutzer akzeptieren, die sich zu Beginn des SMTP-Dialogs bereits erfolgreich authentifiziert hatten. Unsere Musterlösung der smtpd_recipient_restrictions in Abschnitt 10.1.3, »Die Postfix-Restrictions: Der Schlüssel zu Postfix«, hatte permit_sasl_authenticated bereits an passender Stelle vorgesehen. Dort war der Parameter durch eine Raute noch deaktiviert. Aktivieren Sie nun diesen Eintrag:

# Mails unserer Nutzer/Server erlauben!
        permit_sasl_authenticated,
        permit_mynetworks,

Listing 10.21    Die Prüfung der Authentifizierung in den Restrictions

Heutzutage ist es sinnvoll, den eigenen Usern eine Authentifizierung nur geschützt durch SSL/TLS anzubieten. Ergänzen Sie dazu Ihre main.cf ggf. noch wie folgt:

smtpd_tls_auth_only = yes

Listing 10.22    Die TLS-Parameter in Postfix

Mit den Anpassungen für Postfix sind Sie damit fertig, allerdings müssen Sie noch den Authentifizierungs-Socket in Dovecot bereitstellen, also quasi unsere Gegenstelle, die Postfix hier anrufen und um Rat fragen kann. Wenn Dovecot bereits installiert ist, können Sie diese Anpassung schon jetzt vornehmen, ansonsten kehren Sie nach der Installation von Dovecot in diesen Abschnitt zurück. In Dovecot ist bei neuen Versionen in der Datei /etc/dovecot/conf.d/10-master.cf bereits ein Authentifizierungs-Socket für Postfix vorbereitet. Suchen Sie die passende Stelle in der 10-master.cf, prüfen Sie, ob der folgende Eintrag vorbereitet ist, und aktivieren Sie ihn:

service auth {
[…]
  # Postfix smtp-auth
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
  }
[…]
}

Listing 10.23    Der Authentifizierungs-Socket in Dovecot

Nach einem Neustart von Postfix und Dovecot sollte einer Authentifizierung nichts mehr im Wege stehen. Eine erfolgreiche Authentifizierung loggt Postfix eindeutig im Logfile:

Jun 29 11:45:49 plasma postfix/smtpd[19664]: 59A19A6BE2: client=unknown[10.0.40.6]:\
56828, sasl_method=CRAM-MD5, sasl_username=p.heinlein@heinlein-support.de

Listing 10.24    Eine erfolgreiche Authentifizierung im Postfix-Logfile

Übrigens: Wenn Sie Ihren SMTP-Auth-Server und Ihren IMAP-Server getrennt betreiben wollen, müssen Sie trotzdem kurzerhand Dovecot auf dem Postfix-Relay installieren. Sie können Ihre funktionierende Dovecot-Konfiguration von Ihrem IMAP-Server 1:1 kopieren, damit sichergestellt ist, dass die Abfrage der Authentifizierung funktioniert. Um jetzt jedoch nicht unnötig die eigentlichen Dovecot-Dienste POP3 oder IMAP zu starten, installieren Sie auf Ubuntu lediglich das Paket dovecot-core, nicht aber dovecot-pop3 oder dovecot-imap. Unter openSUSE Leap, wo alle Module zusammen paketiert sind, passen Sie in /etc/dovecot/dovecot.conf den Eintrag protocols wie folgt an, um POP3 und IMAP zu deaktivieren:

protocols = none

Listing 10.25    Dovecot als reiner Authentifizierungsserver

Dovecot wird nun nur seinen innersten (Authentifizierungs-)Kern starten und klein und harmlos als Partner von Postfix im Hintergrund seinen Dienst verrichten.

10.1.6    SSL/TLS für Postfix einrichten

Nicht nur angesichts des letzen NSA-Skandals ist die SSL/TLS-Verschlüsselung des E-Mail-Verkehrs eine gute Idee. Schon seit über 15 Jahren ist ein konsequenter Schutz von E-Mails und auch Zugangsdaten per SSL/TLS bei guten Mailprovidern eine Selbstverständlichkeit, auch wenn einige Anbieter (bzw. deren Marketing-Abteilung) ihre plötzliche Liebe zu SSL erst in der jüngsten Zeit entdeckt haben.

In Kapitel 30, »Verschlüsselung und Zertifikate«, wird ausführlich auf die Einrichtung einer CA und die Erzeugung eigener Zertifikate eingegangen. Echte Zertifikate mit CA-Unterschrift sind sinnvoll, wenn User mit Desktop-Software auf Ihre Mailserver zugreifen und Sie die Mailübertragung und die Passwortübertragung absichern wollen.

Sobald jedoch Mailserver untereinander Mails im Internet übertragen, ist eine SSL-Verschlüsselung sowieso nur optional; manche Provider unterstützen auf Ihren Mailrelays SSL, andere nicht.

Da Mailserver eine E-Mail im Zweifelsfall auch unverschlüsselt an die Gegenseite übertragen würden, kommt es auf die Gültigkeit des verwendeten Zertifikats für sie nicht an. Auch die Verschlüsselung mit nur selbst signierten und nicht überprüften Zertifikaten ist immer noch besser als eine vollständige Klartextübertragung.

Für Mailrelays können Sie darum problemlos auf selbst signierte Zertifikate zurückgreifen, und mit diesem charmanten Einzeiler können Sie Key und Zertifikat in einem einzigen Durchgang erzeugen lassen:

mail:~ # openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj
         /CN=mail.example.com  -keyout /etc/ssl/private/mail.example.com.key \
         -out /etc/ssl/certs/mail.example.com.crt
mail:~ # chmod 400 /etc/ssl/private/mail.example.com.key

Listing 10.26    Selbst signierte Zertifikate mit nur einem Kommando erzeugen

Nun müssen Sie nur noch die Pfade zu Key und Cert in der main.cf von Postfix ergänzen. Wenn Sie Zertifikate einer »echten« CA verwenden und diese ein Zwischenzertifikat verwendet, sollten Sie auch dieses über smtpd_tls_CAfile zur Verfügung stellen.

# Ausgehend SSL/TLS aktivieren
smtp_tls_security_level = may

# Eingehend SSL/TLS aktivieren
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.com.crt
smtpd_tls_key_file = /etc/ssl/private/mail.example.com.key

# Optional, falls benötigt:
# smtpd_tls_CAfile = /etc/ssl/certs/ca-zwischenzertifikat.crt

Listing 10.27    SSL/TLS in Postfix aktivieren

In der jüngeren Vergangenheit ist Perfect Forward Secrecy (PFS) in den Mittelpunkt der Aufmerksamkeit geraten. Mittels spezieller DHE-Ciphers kann die SSL-Kommunikation besonders gegen eine nachträgliche Entschlüsselung abgesichert werden. Optimieren Sie Ihr SSL-Setup, indem Sie über das OpenSSL-Kommando besondere DiffieHellmanFiles erzeugen:

mail:~ # openssl gendh -out /etc/postfix/dh_512.pem -2 512
mail:~ # openssl gendh -out /etc/postfix/dh_2048.pem -2 2048

Listing 10.28    Erzeugung der notwendigen Diffie-Hellman-Files

Für das Diffie-Hellman-Verfahren existieren Verfahren, die die Schlüssellänge schwächen. Aus diesem Grund sollten keine DH-Schlüssel mehr mit 1024 Bit Länge, sondern gleich mit 2048 Bit Länge erzeugt werden. Diese werden durch die Angriffsmöglichkeit zwar auch etwas geschwächt, sind damit aber immer noch dermaßen stark, dass sie als sicher gelten.

Postfix kennt keinen eigenen DH-Parameter für 2048 Bit Schlüssellänge. Stattdessen können Sie über den vorhandenen Parameter smtpd_tls_dh1024_param_file direkt auf ein File mit 2048 Bit verweisen, und Postfix wird dann 2048er-Schlüssel verwenden. Lassen Sie sich in diesem Fall also von dem Parameternamen nicht verwirren.[ 11 ]

Tragen Sie in der main.cf von Postfix also Folgende ein:

# 2048-Bit-DH-Schluessel zuweisen
smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
smtpd_tls_eecdh_grade = strong
tls_preempt_cipherlist = yes

Listing 10.29    »Perfect Forward Secrecy« in Postfix aktivieren

Übrigens: Auf starttls.info können Sie Ihren eigenen Mailserver bequem durchchecken lassen Abbildung 10.1 zeigt das Ergebnis einer solchen Prüfung.

»https://starttls.info/« checkt die SSL-Konfiguration Ihres Mailservers.

Abbildung 10.1    »https://starttls.info/« checkt die SSL-Konfiguration Ihres Mailservers.