Laß Dich nicht verwirren: Ich habe den Titel extra so gewählt, weil ich den Eindruck hatte, dass in vielen Foren saslauthd und sasldb2 durcheinander geworfen wird. In diesen Artikel gehe ich punktuell (!) auf die Konfiguration von Postfix, saslauthd/sasldb2 und policyd-weight ein. Ich schreibe hier nur am Rande über die Konfiguration von Dovecot. Ich sehe diesen Artikel eher als einen Diskussionsbeitrag zu verschiedenen Konfigurations- Möglichkeiten des SMTP Servers Postfix an. Außerdem werde ich in meinen Text mit Bildern arbeiten. Wer also code zum kopieren sucht, muss leider auf eine andere Quelle wechseln. Außerdem neigen meine Artikel leider immer zur Länge :)

Software Versionen

Folgende Versionen liegen meiner Ausführung zugrunde: Ubuntu 10.04 LTS, Postfix 2.7.0, saslauthd 2.1.23, sasl2-bin 2.1.23, amavisd-new 2.6.4, clamav 0.96.5, policyd-weight 0.1.14.17.

Das Szenario

… basiert auf einen Server, der 4 Mail- Domänen bedienen soll – allerdings ohne Datenbank oder LDAP. Die Benutzer sind lokale Benutzer im Systems.

LDAP oder SQL?

Nur mal kurz: Ich habe in den Foren häufig Diskussionen über den Vor- und Nachteil einer Benutzerverwaltung in Datenbank oder LDAP gelesen. Aus meinen Erfahrungsbereich würde ich sagen, dass im Unternehmens- Umfeld ein LDAP vor zu ziehen ist, weil Enterprise Software häufig einen Konnektor zu LDAP mitbringt. Sind also viele System verknüpft: LDAP. Auf standalone Servern – wie z.B. einen gebuchten root Server – würde ich eine Datenbank als Benutzerverwaltung vorziehen.

Grundlegende Konfiguration

Auf die grundlegende Konfiguration gehe ich nicht ausführlich ein – in anderen blogs gibt es dazu wirklich hervorragende Artikel. Am Ende dieses Artikels habe ich eine kleine Linksammlung zum Thema abgelegt. Wenn Du aber alle Bilder aus diesen Artikel ausdruckst und untereinander klebst, bekommst Du eine brauchbare Konfiguration. Ich würde auch empfehlen, die Kommentare in meinen config- Bildern zu lesen! Ab jetzt folgende Bilder beziehen sich auf die main.cf in /etc/postfix – wenn nicht anders erwähnt. Im ersten Bild gibt es nichts wirklich Spannendes:

Server mit dyndns

Allerdings ist bei Einsatz von dyndns zu beachten, dass ein $mydomain natürlich dann nicht dyndns.org sein kann! Ich habe für so einen Fall (home Server über dyndns) mydomain = $myhostname und myorigin = $mydomain eingefügt.

Die delimiter- Option finde ich sehr spaßig: Sie sagt uns, mit welchen Zeichen wir eine Mailadresse unterteilen können.

Nützlich ist diese Funktion, wenn man Emails mit einen Filter einsortieren möchte. So kann eine Mail an benutzername+umfrage@meinedomain.org leichter in den Ordner “Umfrage” einsortiert werden.

maildir oder mbox?

Die mail_spool_directory Option ist Grundlegend: Mit dem slash am Ende des Ordnernamens legst Du Postfix auf das maildir Format fest und sagst Postfix, wo die Benutzer Postfächer sind. Das andere Format (also ohne slash am Ende) wäre mbox.

Wichtig ist diese Festlegung in Verbindung mit dem IMAP Server. Im wesentlichen unterscheiden sich diese Formate in der Art der Email- Haltung. Das mbox Format speichert alles in eine Datei. Das maildir Format sichert alle Emails als einzelne Datei in einen Ordner. Dann gibt es verschiedene Varianten: Dovecot nimmt maildir und erstellt einen Index, Cyrus IMAP benutzt mbox und Courier benutzt maildir ohne Index. Die verschiedenen Vor- und Nachteile sind für einen Techniker offensichtlich. Die Option mailbox_command übergibt (deliver) die Emails an den verfügbaren IMAP Server, hier dovecot.

mailbox_command und mailbox_transport

Was ist aber der Unterschied zwischen mailbox_command und mailbox_transport? Die erstere Option wird in Verbindung mit lokalen Benutzern und die zweite Option in Verbindung mit virtuellen Benutzern gesetzt. In unseren Fall benutzen wir weder  eine Datenbank noch LDAP, wir benutzen lokale User und setzen also mailbox_command.

Grundlegend finde ich eine klare Aufteilung einer Konfigurationsdatei: So würde ich die alias Datei nur für system-eigene administrative Accounts nutzen – im wesentlichen für den root und verschiedene System- User. Mailbenutzer und Maildomänen, die zusätzlich angelegt werden, landen alle in den virtual maps.

Die virtual_maps erstellen

Die virtual_alias_domains sehen in der zu erstellenden Datei folgendermaßen aus:

Also eine einfache zweispaltige Tabelle in der alle virtuellen Domänen aufgeführt werden, die der Mailserver bedienen soll. Allerdings würde ich einen MX Eintrag im DNS für jede Maildomäne empfehlen, um von anderen Email- Servern ernst genommen zu werden! Nach dem erstellen dieser Datei, wird sie über die gezeigte Funktion im vorherigen Bild in Postfix eingebunden. Sie kann aber nur von Postfix genutzt werden, wenn sie mit dem Befehl postmap <dateiname> zu einem Datenbankfile umgewandelt wurde. Der Dateiname ist frei wählbar. Die zweite Spalte wird nicht ausgewertet, muss aber einen Wert (hier: OK) gesetzt haben.

Genauso verfahren wir hier mit der Datei virtual_users (Dateiname kann frei gewählt werden). Wieder eine zwei-spaltige Tabelle, in der links der virtuelle Namen festgelegt und rechts auf dem Benutzer gemappt wird, der auf unseren Email- Server angelegt wurde. In dieser Datei wird also die zweite Spalte ausgewertet! Also nochmal: in der linken Spalte die gewünschten User mit der gewünschten Domäne, die in virtual_domains angelegt wurden. Die einkommende Mail wird also einfach nur dem lokalen Benutzer (in der rechten Spalte) in das Postfach geschoben. Die Benutzer für die originäre Domäne – also aus main.cf – werden auch in diese Datei eingetragen. Das postmap nicht vergessen. simpel.

Was RFC’s verlangen

Übrigens: Einige Emailkonten sind auf einen Mailserver mandatory (Pflicht). Genaueres ist in den entsprechenden RFC’s nachzulesen. Wenn ich mich recht erinnere, waren das der abuse (zur Annahme von Beschwerden) und der postmaster (als administrativer Account für die Dienste). Generell finde ich aber ein professionelles Auftreten und entsprechende Verwaltung von Servern (auch im privaten Rahmen) für wichtig, und empfehle auch Konten für den webmaster, blogmaster, usw. zu erstellen. Service bringt Mehrwert.

Also nochmal: In der main.cf steht ja schon die physikalische Domäne (siehe erstes Bild) und mit den virtual Dateien wird der Mailserver um virtuelle Domänen und Benutzer erweitert! Also nicht kompliziert denken und klar strukturieren. Letztlich findet einfach nur ein Mapping von virtuellen Emailadressen auf Postfächer der angelegten Usern statt.

Entscheidend ist dann natürlich das Namens-Schema für angelegte User: Zweimal mustermann – für diese und für eine andere virtuelle Domäne – anlegen ist nicht! Zumindest nicht, mit der hier gezeigten Konfiguration.

SASL

Einfach gesagt: SASL ermöglicht eine Authorisierung von Mailclients an unseren Postfix SMTP Server. Im wesentlichen gibt es zwei Konstrukte – saslauthd und sasldb2:

• Der saslauthd – als service gestartet – ermöglicht eine Klartext (plaintext) Anmeldung mit den Passwörter in der /etc/shadow an Postfix – also dem smtp service.
• Die sasldb2 erfordert keinen gestarteten Service und ermöglicht zusätzlich eine verschlüsselte Anmeldung mit der Passwortverwaltung in der sasldb2.
• Die 2 Arten der Passwortverwaltung sind un-abhängig von der verschlüsselten Übertragung der Anmeldung: Dafür ist TLS entscheidend.
• Saslauthd und sasldb2 werden über die Datei smtpd.conf konfiguriert, liegt bei Ubuntu 10.04 in /etc/postfix/sasl und gehört mit 644 root:root.
• Soll sasldb2 (also verschlüsselte Passwörter) benutzt werden, ist die Option smtpd_sasl_security_option mit dem Wert noplaintext zu erweitern.
• Die sasldb2 – also die mit saslpasswd2 erstellte Datenbank in der alle verschlüsselten Passwörter für die Mail- User stehen – liegt normalerweise mit root:postfix und 640 in /etc.
• Bei Einsatz von verschlüsselten Passwörter sind also pro User zwei (2) Passwörter zu pflegen und für die User der Zugriff einzurichten, da Dovecot die /etc/shadow nutzt.
• Sollte keine Anmeldung möglich sein, kann es daran liegen, dass Postfix ge-chrootet läuft, d.h. Postfix erwartet die sasldb2 mit 640 und root:postfix in /var/spool/postfix/etc.

Und so gibt es noch viele Punkte, die ich hier aufführen könnte. Letztlich sollte man die zuständigen sasl- Befehle und Eigenheiten studieren:

• saslpasswd2 -c -f <pfad zur sasldb2> -u <domäne> <emailbenutzer> Damit werden die Emailbenutzer in die sasldb2 eingepflegt. Das -c ist nur für create, also für das erstmalige anlegen des Users in der sasldb2 notwendig.
• sasldblistusers2 zeigt, welche Users in der sasldb2 hinterlegt sind.
• Beachte die Option -u <domäne>, weil wir hier mehrere Maildomänen bedienen.
• Über saslpasswd2 müssen die Email- Users auch ihr Passwort ändern können. Linux- Passwort nicht gleich sasl- Passwort! Vielleicht usermin?
• Gängige Fehlermeldungen beachten: “no secret in database”.
• Bei mehreren Domänen und sasldb2 (also verschlüsselte Passwörter) ist mit dem Mailclient die Anmeldung am Mailserver mit der Emailadresse durchzuführen.

sasldb2 nach chroot

Ich habe selbst lange auf dem Server gesucht und geflucht, warum die sasldb2 nicht nach /var/spool/postfix/etc kopiert wird. Immerhin soll der Postfix in einer sicheren Ebene im Dateisystem des Servers laufen. Dazu schafft er sich unter /var/spool/postfix eine eigene Ordner Ebene und kopiert dort – bei jeden Neustart des Postfix’s – für ihn wichtige Dateien aus der üblichen root Umgebung in diese eigene künstliche ch(ange)-root Umgebung. Der Effekt dabei soll sein, das Schadpropramme, die über den Mail service Zugriff auf den Server erlangen, sich eben nur in einer chroot Umgebung bewegen. Verarscht.

Allerdings funktioniert Postfix eben auch nur, wenn alle Dateien, die Postfix für den Betrieb braucht, auch in die chroot Umgebung gelangen. Und da klappt das mit der sasldb2 nicht so wirklich.

Lösung? Öffne die Datei /etc/init.d/postfix und erweitere die Datei- Liste (wie auf dem Bild) mit etc/sasldb2. Nach einen service postfix restart müßte die sasldb2 in den Ordner  /var/spool/postfix/etc kopiert worden sein. Maßgeblich für die sasl- Befehle ist nur noch die sasldb2 in /etc. Also sollte nach Aufnahme eines neuen Users in die sasldb2 oder einen Passwort- Wechsel mit saslpasswd2 ein ‘service postfix restart’ erfolgen. Ein reload hat bei meinen Tests keinen Transfer der sasldb2 in die chroot bewirkt. Einen symbolischen link von /etc/sasldb2 nach /var/spool/postfix/etc setzen funktioniert zwar, scheitert aber im Zugriff mit einer Fehlermeldung. Jedesmal Postfix neu starten?

Auf die Abschaltung der chroot Umgebung – als eine weniger gute Lösung! – gehe ich weiter unten im Artikel ein.

SASL realm

Aufgeschnappt: Sollte der Domänen- Teil (Stichwort: SASL realm) in  saslpasswd2 nerven, kann man mit der Option -r in /etc/default/saslauth oder mit der Option smtpd_sasl_local_domain in der main.cf experimentieren. In der hier gezeigten Konfiguration sind keine weiteren Anpassungen notwendig.

Beachte die man-page, deine sasl Version und teste, ob es mit mehreren virtuellen Domänen funktioniert (Ausgabe sasldblistusers2)! Zur Hilfe sollte ein tail -f /var/log/mail.log auf der console mitlaufen und die loglevel auf 2 stehen. Eventuell kann die Ausgabe von saslfinger -s hilfreich sein.

Man sieht, dass der Konfigurationsaufwand für verschlüsselte Email- Passwörter um einiges höher ist: Es müssen zwei Passwörter gepflegt (sasldb2 und /etc/shadow) und es muss ein sicherer Server-Zugriff für den Passwortwechsel eingerichtet werden. Vorteil: Der Server braucht nicht unbedingt TLS sprechen und es kann ein service  im Hintergrund (saslauthd) eingespart werden.

SASL – die smtpd.conf

Folgendes Bild zeigt den Inhalt der /etc/postfix/sasl/smtpd.conf:

Wie man im Bild sieht ist die Konfiguration, ob sasldb2 oder saslauthd genutzt wird, easy. Alles was im Bild weiß ist, ist für saslauthd. Setze eine # (Raute) vor jeder weißen Zeile und nehme die Raute vor den blauen Optionen weg und es ist für sasldb2 konfiguriert.   Beachte aber die Option noplaintext in der main.cf wie im Text erwähnt. Den log_level kann man natürlich für beide Arten aktiv lassen. Wenn wir saslauthd nutzen, sollte der service natürlich gestartet sein – wenn sasdb2 benutzt wird, sollte der saslauthd deaktiviert sein. Beachte die Ausgabe von ps -ax.

Nochmal deutlich: saslauthd geht nicht mit cram-md5 (digest-md5, also verschlüsselte Passwörter). Wenn also in deiner smtpd.conf saslauthd und cram-md5 als aktivierte Werte drinstehen, hast Du die Lösung eines Problems gefunden.

Beachte auch, dass die Nutzung eines unverschlüsselten Passwortes – also saslauthd – nicht gerade ungefährlich ist. Entschärfe diese Sicherheitslücke mit TLS.

TLS – verschlüsselte Übertragung

Standardmäßig spricht Postfix TLSv1 und SSLv3. Das ist auch so in Ordnung. Mit der Option (siehe Bild) smtpd_tls_mandatory_protocols kann man also nichts mehr wesentlich verbessern – man könnte den Server noch auf TLSv1 einschränken. Es muss aber auch klar sein, dass sich andere Mailserver mit deinen Mailserver unterhalten und wenn die Vorgaben zu restriktiv sind (egal bei welchen Optionen!) besteht immer die Gefahr, dass der andere Mailserver nicht bedienen kann – also die Übertragung der Email abbricht.

Die Option smtpd_tls_security_level = may sagt im Prinzip dem Mailclient: “Wir könnten TLS sprechen.”

Daher ist es eine Möglichkeit, die Option smtpd_tls_auth_only zu deaktivieren und läuft in Verbindung mit sasldb2 darauf hinaus, dass, wenn der Mailclient TLS kann, die Verschlüsselung des Übertragungsweg auch benutzt wird – wenn er es nicht kann, ABER verschlüsselte Passwörter hat, dann geht es auch ohne TLS. Kurz: Man ist immer auf einer verschlüsselten Option.

Die andere Möglichkeit ergibt sich, wenn die Optionen wie im Bild gesetzt sind. Dann würde TLS verpflichtend  vom Mailclient – also z.B. mit plaintext Passwörter und saslauthd aber TLS (nochmal: unverschlüsselte Passwörter aber mit verschlüsselter Übertragung)  -verlangt werden. Klarer gehts nicht.

Die Option smtpd_tls_received_header ist ganz spaßig: Sie setzt dem Quelltext einer Mail noch zusätzliche Informationen hinzu, die den TLS Dialog der Mailserver betrifft. Schaue Dir mal den Quelltext einer Email an: Thunderbird -> eine Email auswählen -> andere Aktionen -> Quelltext anzeigen.

Übrigens: Wenn dein Mailclient bei aktivierten TLS meckert, dass keine Anmeldung möglich ist, hat dass nicht automatisch was mit der “Anmeldung” (sasldb2, usw.) zutun, sondern kann auch an einen fehlerhaft konfigurierten TLS liegen: Die Anmeldung wird nämlich erst begonnen, wenn TLS – also die verschlüsselte Übertragung – steht! Macht ja auch Sinn …

Ich habe Dir ja zu Beginn schon geschrieben, dass meine Artikel etwas länger ausfallen.

TLS Zertifikate

Wenn Du Emails von einen Mailserver bekommst, kann es sein, dass es Fehlermeldungen gibt, weil beim TLS Zertifikats Abgleich (wenn Dein Mailserver TLS spricht!), deinem Mailserver die notwendigen öffentlichen Zertifikate fehlen und er also nicht erkennt, ob die Zertifikate vom anderen Mailserver koscher sind. (Zum testen würde ich in der main.cf mal smtpd_tls_loglevel = 2 setzen.)

Dafür gibt es die Option smtpd_tls_CAfile. Mit dieser Option wird der Pfad zu deinen Zertifikatspool angegeben. Unter Ubuntu 10.04 ist der pool unter /etc/ssl/certs wenn ein bestimmtes Paket installiert ist, verdammt, wie heißt das noch? Ich vermute, es war ssl-cert. Und in diesen Zert-pool liegt eine Datei, die alle Zerts in diesen Ordner beinhaltet, ca-certificates.crt, diese Datei nennst Du deinen Mailserver (wie im vorherigen Bild gezeigt) und schon spricht er fließend zertisch mit anderen Mailservern.

Nochmal: Das hat nichts mit verschlüsselten Passwörtern zutun, bei TLS geht es nur um eine verschlüsselte Übertragung (!) von Daten! Und nochmal deutlich: Nicht nur Mailclients wie Outlook oder Thunderbird sprechen mit deinen Mailserver TLS sondern eben auch andere Mailserver, die Dir Mails anliefern …

Tipp: Bei Bastelaktionen mit TLS kann es manchmal hilfreich sein, die letzte Option im Bild (limit) zu aktivieren und den Wert anzuheben.

restrictions sind Einschränkungen

Bei den restrictions (Einschränkungen) scheinen sich die Kollegen immer übertreffen zu wollen! Das ist auch verständlich, weil jede Admina Angst davor hat, mit ihren Mailserver auf einer Schwarzen Liste  als Spam-Server zu landen oder der Admin einen Anschiss von seinen Anwendern erwartet, wenn zu viel oder zuwenig an Mails durchkommt. Wie dem auch sei …

Ich empfehle, es mit den restrictions nicht zu übertreiben – Wichtiger halte ich eine brauchbare Gliederung der restrictions. Auf welchen Ebenen des Mailverkehrs greifen welche Überprüfungen? Damit hat man schneller entsprechende Stellschrauben …

Bei den Einstellungen im folgenden Bild, geht es uns um den Briefkopf der Mail. Damit wollen  wir sicherstellen, dass die – vom Mailserver – angenommene Mail in der Form korrekt ist (Die Post klebt für Dich auch keinen Briefumschlag zu :) und können damit verschiedene Probleme in der Weiterverarbeitung der Mail ausschließen.

Es wird empfohlen, das vrfy Kommando zu deaktivieren. Das vrfy (kurz für verifizieren, bestätigen lassen, dass es einen Mailempfänger auf diesen Mailserver gibt) wird angeblich von Spammer genutzt, um gültige Mailadressen abzufischen. Dann sollte sich der Client mit einen korrekten helo beim Mailserver anmelden und der envelopes (Anschrift auf dem Briefumschlag)  muss ebenfalls korrekt sein: mit strict_rfc821_envelopes erwarten wir vom Absender eine spitze Klammer um die Mailadresse. Eben senden mit Stil.

Gültiger Mailserver?

Das folgende Bild geht auf die Netzwerkanbindung des Senders ein:

Damit checken wir einen gültigen – sprich: im Internet vollwertig bekannten – Mailservernamen und eine gültige Sender- Domäne ab. Wenn der sendende Mailserver einen unbekannten Namen hat, wird seine Mail nicht angenommen. Warum auch? Wohin sollten wir denn die Antworten auf seine Mail schicken?

Im folgenden Bild sehen wir im wesentlichen Empfänger-bezogene , bzw. den eigenen Mailserver betreffende Einschränkungen.

Bei der Option smtpd_recipient_restrictions, sind folgende Eigenheiten bei der Konfiguration zu beachten:

• dass die restrictions nicht willkürlich zusammen gestellt werden.
• dass (immer) permit_mynetworks und permit_sasl_authenticated eingetragen ist.
• dass die teuren restrictions in der Liste am Ende kommen.
• dass zum Abschluss der Liste ein end-gültiges Statement (reject oder permit) steht.

Deswegen erstmal mit einen schmalen set starten  - ausbauen kann man immer!

Was sind teure Restriktionen?

Du kannst z.B. per restrictions festlegen lassen, dass alle Absender von einkommenden Mails mit Schwarzen Listen abgeglichen werden. Es ist bestimmt verständlich, dass so eine Überprüfung Zeit dauert und damit eine “teure” Angelegenheit ist. Damit würde die restrictions “überprüfe Absender in der schwarzen Liste” in unserer Liste ganz unten – aber noch vor dem endgültigen Statement – stehen.

policy_weight gegen Spam

Übrigens: Im letzten Bild sieht man den Eintrag check_policy_service und der ist für policyd_weight gesetzt. Einfach das Paket policyd_weight installieren und den Eintrag wie im Bild setzen und schon werden alle eingehenden Mails – also die Absender, bevor die Mail in der Warteschlange des eigenen Servers aufgenommen wird, anhand verschiedener Schwarzer Listen – überprüft. Das Ergebnis ist in /var/log/mail.log zu sehen. Die Standard- Einstellungen und welche blacklists von policyd-weight genutzt werden ist unter /usr/share/doc/policyd-weight/README.Debian nachzulesen.

Sicherheitsfilter auf mehreren Ebenen

Damit haben wir auf auf mehreren Ebenen Sicherheitsfilter eingebaut: im Vorfeld fliegt spam raus, die grundsätzliche korrekte Form einer Mail wird abverlangt, die Netzwerk- Daten des sendenden Mailserver werden überprüft und die haus-internen restrictions für den Umgang mit angenommenen Emails sind definiert. Ein solides Fundament …

Vor oder nach dem queuen?

Um das nochmal klar zu sagen: Mit Queue ist die Warteschlange des Mailservers gemeint. Queue ist nur kürzer als Warteschlange. Ähnlich wie ein Druckserver muss der Mailserver auch mal verschiedene Aufträge bis zur Weiterverarbeitung ablegen können. Entscheidend ist dann, wie viel Hardware will ich für eine flotte Queue investieren, müssen manche Mails überhaupt ge-queuet werden und wer redet mit dem Absender, wenn eine Mail vor der Queue oder in der Queue verworfen wird (Spam, Formfehler, Schadprogramme).

Damit ist die Frage, ob man in Postfix Filter einbaut (z.B. für amavisd-new, siehe unten im Text), die vor oder nach dem queuen wirksam werden, eine relativ spannende Frage. Wir sollten aber auch keinen Glaubenskrieg daraus machen: Es kann ohne Probleme im laufenden Betrieb von content_filter auf proxy_filter (und umgedreht) umgestellt werden. Einfach alle Einträge in master.cf und main.cf setzen und entsprechend aktivieren.

proxy_filter – filter vor queue

Im ersten Schritt deaktivieren wir den content_filter Eintrag in der main.cf – wenn einer vorhanden ist! Generell muss für den proxy_filter kein Eintrag in der main.cf gesetzt werden, weil er mit den Postfix Optionen in der master.cf konfiguriert wird. Dazu kommen wir im nächsten Schritt.

Im zweiten Schritt erweitern wir den smtp Eintrag in der master.cf mit 3 Options- Zeilen. Beachte bitte den Einzug (mehrere Leerzeichen) vor den Options- Zeilen. Ohne diesen Einzug ist die Konfiguration unbrauchbar! Zusätzlich sehen wir die Aktivierung der  chroot Umgebung des Postfix Server’s am Minuszeichen (-) in der chroot Spalte. Damit wird die Standard Einstellungen (yes) bestätigt. Und die 20 steht für die verminderte Anzahl der smtp Dienste, die im Hintergrund Anfragen annehmen, weil der proxy_filter keine queue hat und daher (vorsorglich) mit weniger auskommen muss.

Im dritten Schritt bauen wir – ebenfalls in der master.cf – den Eintritt der Mail in die queue ein. An der IP-Adresse erkennen wir, dass der smtp Server nur mit sich selbst spricht: er gibt quasi das Fax für das nächste Büro durch die Zwischentür weiter. Fertig.

Alternativ können wir – wie im folgenden Abschnitt beschrieben – den content_filter einrichten:

content_filter – filter nach queue

Im ersten Schritt aktivieren wir den content_filter in der main.cf. Die 2 Zeilen aus dem folgenden Bild sind dabei vollkommen ausreichend. Mit der zweiten Option (mapping) wird das umschreiben der Empfänger- Adresse abgeschaltet, weil der smtp sonst zu falschen Annahmen kommt und die Mail im falschen Postfach landet.

Im zweiten Schritt überprüfen wir den smtp Eintrag in der master.cf – dieser steht normalerweise in einer der ersten Zeilen! Zusätzlich beachten wir das Minuszeichen für die aktivierte chroot Umgebung als Standard- Einstellung des Postfix Servers und die 100 für die volle Anzahl der smtpd Dienste, die im Hintergrund anfragen annehmen, weil der content_filter die queue von Postfix zur Verfügung hat. Diese Einträge sind normalerweise im un-konfigurierten Zustand dieser Datei zu erwarten.

Im dritten Schritt bauen wir – ebenfalls in die master.cf – den Eintritt der Mail in die queue ein. Hier ist nur zu beobachten, dass wir den lmtp statt den smtp als Schnittstelle bevorzugen, weil er besser mit gleichzeitigen Vorgängen – also mit mehreren Mails auf einmal – umgehen kann. Außerdem ist der Eintrag -o content_filter= sehr wichtig. Ebenfalls gilt es zu beachten, dass es vor und nach dem Gleichheitszeichen keine Leerzeichen geben darf!

Das die meisten Optionszeilen keine Werte haben, ist in diesen Zusammenhang richtig, weil die Werte an dieser Stelle (Postfix spricht ja hier mit sich selbst) nicht wirksam werden sollen, an anderer Stelle schon definiert sind oder eben doch mit diesen speziellen Werten wirksam werden müssen.

Unterschiede der Filter?

Die Funktionalität ist die gleiche, aber was unterscheidet diese filter? Es ist simpel: der content_filter gibt die Mails zur Filterung, wenn die Mails schon in der Warteschlange aufgenommen sind. Unser Mail- Server muß also (nach RFC’s) bei z.B. Fehler oder Ablehnung den Verwaltungskram mit dem Sender abwickeln.

Der proxy_filter ist aber der Queue (Warteschlange) vorgeschaltet – vergleichbar dem policyd_weight – und muss bei Ablehnung der Mail dem Sender keine Status- Mail schicken. Die Mail stirbt. Ist alles in den RFC’s geregelt.

Die Debatte zu pros und cons der beiden Filter ist im Internet sehr umfangreich – sollte diese Frage für den eigenen Server kriegsentscheidend sein, dann würde ich dazu ausführliche Recherchen empfehlen: einfach mal die Suchwörter “postfix pros cons content_filter” in google eingeben. Im “normalen” Betrieb ist üblicherweise der content_filter in Anwendung.

Was jetzt?

Ich bevorzuge den proxy_filter, denn: Was ich nicht annehme – darum muß ich mich auch nicht kümmern! Allerdings hat der proxy_filter auch Nachteile: So soll er bei einer großen Anzahl paralleler Verbindungen zum Mailserver in’s Schwitzen geraden. Das liegt daran, das dieser proxy_filter ein ganz normales Programm ist und keine eigene Warteschlange besitzt. Damit kann es passieren, dass der Client – also der Absender einer Mail – in einen timeout läuft, wenn die Server- Ressourcen mal knapp wären. Entscheide selbst.

amavisd-new gegen Viren

In der Beschreibung des amavisd-new Pakets steht sinngemäß “eine Schnittstelle zwischen MTA (hier: postfix) und Viren- oder Inhalts- Filter”. Wenn Admina also das (Anti-Viren-) Paket clamav und clamav-freshclam installiert hat, den (im Bild) gezeigten Zugang zur Schnittstelle amavisd-new in main.cf und den content_filter  konfiguriert hat, ist Postfix über den amavis mit dem Virenscanner clamav connectet. Die Mails werden durch den Virenscanner gejagt.

In diesen Bild sehen wir also die entscheidende Einbindung des amavisd-new mit der Benutzung des content_filter unter Nutzung des ports 10024 in der main.cf. Der Standard port 10024 für amavisd-new ergibt sich aus der Datei /etc/amavis/20-debian_defaults der mit der Option inet_socket_port definiert ist.

Der port 10024 für den proxy_filter ist als Options- Zeile unter dem smtp Eintrag in der master.cf zu finden – wenn alternativ der proxy_filter konfiguriert ist!

chroot abschalten

Manchmal kann es notwendig sein, die chroot Umgebung des Postfix Server’s abzuschalten. Das ist eigentlich keine große Sache, erfordert aber ein Umdenken, weil die Dateien wieder an ihren “Original”- Plätzen – also nicht in einer “künstlichen” Umgebung – für den Postfix im Zugriff sein müssen. Im Prinzip ist schon aus den vorhergehenden Bilder zu sehen was gemacht werden muss: in der master.cf ist beim smtp service, in der Spalte chroot das Minuszeichen (-) zu einen n (für nein/no) zu ändern.

Aber weil wir ja auch noch (eventuell) den saslauthd nutzen und der ja ein ganz enger homie vom Postfix ist, muss bei diesen Service auch nachgebessert werden. Immerhin hat saslauthd nach Abschalten der Postfix chroot einen anderen Rendezvouse Ordner mit Postfix. Dafür das folgende Bild (beachte auch den Kommentar im Bild):

Im Bild wird der Text in /etc/default/saslauthd gezeigt, der die Umstellung von saslauthd auf Nicht-chroot (und umgekehrt) konfiguriert. Grundsätzlich sollte man aber die Empfehlung annehmen, dass Sicherheits- Konfigurationen ihren Sinn haben und nur als letzte Lösung abzuschalten sind.

Zum Schluss (endlich!)

Nur kein Durcheinander. Wenn Admina sich das ganze als Fließband vorstellt, und sich vorstellt, wer, wann, was drauflegen darf und wie es abgehandelt wird, wenn es draufgelegt wird, oder eben auch nicht, dann bekommt man leicht ein Bild von der Wanderung einer Email in postfix. Unter dem Artikel habe ich links abgelegt, unter denen man auch gute Schema Zeichnungen zum Ablauf findet.

Jetzt fange ich nicht mehr mit bäsixs an: Wer nicht weiß, wo seine logs liegen, wie Admina die logs lesen muss, was der Befehl tail -f ermöglicht, welche Aussage er mit ps findet, init 6, verschiedene Mailclients, quelltext einer Mail, DNS und MX, service Verwaltung unter Linux, mindestens 3 terminals geöffnet, Versionen herausbekommt, show und search mit aptitude, vi, wer das alles nicht kennt, sollte das Thema Mailserver beenden. Mailserver ist die Königs- Disziplin und eine solche Konfiguration kopiert man nicht eben mal von einer anderen Webseite ab. Wer weniger als 4 Wochen an seinen Mailserver gebastelt hat, hat nicht gebastelt sondern gespielt.

Wenn ich noch mehr schreibe, werde ich gesteinigt. Have fun …

Ergänzung

Ich erlaube mir – weil es jetzt auf 10 Sätze mehr auch nicht ankommt – hier noch zwei Bilder abzulegen.

Bild mit proxy_filter

Dieses Bild zeigt den Empfang einer Email mit einen proxy_filter. Die roten Kreise markieren die verschiedenen Konfigurationspunkte, die wir hier im Text ausgeführt haben.

Von oben nach unter beschrieben, sieht man, dass der Mailserver von dem sendenden Google Mailserver ein TLS verlangt und bekommt. Danach checkt erstmal policyd-weight, ab – vor der queue – ob es sich bei der Mail um spam handelt. Dann übernimmt der proxy_filter, typischerweise mit einen NOQUEUE, gibt die Mail an den Amavis – der nickt ab, dass keine Viren drin sind. Damit ist der proxy_filter (END-OF-MESSAGE: 250, die Zahl besagt OK) fertig und der Postfix service local übernimmt die Mail, stellt sie über dovecot-deliver dem Anwender zu, wie mit mailbox_command in der main.cf festgelegt.

Bild mit content_filter

Im Gegensatz dazu, sehen wir in dem Bild, das den Mailempfang mit den content_filter beschreibt, etwas weniger rote Kreise :)

Von oben nach unten, erfahren wir, dass die TLS Anforderung unseres Mailserver von Google bestätigt wird, dann sofort policyd-weight an vorderster Front – also vor der queue – gegen Spam kämpft, danach die Mail beim Postfix smtp bleibt, der aber dann mit einen connect an sich selbst (127.0.0.1) die Mail an den content_filter übergibt, Amavis seine Aufgabe erledigt und dann über lmtp,127.0.0.1 und port 10025 die Mail an den local Dienst von Postfix weiterleitet, der die Einsortierung über dovecot-deliver managt.

Passwort- Verwaltung

Nachdem ich für das Schreiben dieses Artikels viele Einstellungen an meiner Konfiguration überprüft, viel im Internet recherchiert habe und mir auch nochmal einiges inhaltlich klarer wurde, bin ich auch etwas ernüchtert. Die totale Sicherheit auf dem Mailserver gibt es nicht ohne workarounds oder zusätzlichen Umstand!

Alleine die Tatsache, dass die Nutzung von verschlüsselten Passwörter (sasldb2) mit Postfix in der chroot Umgebung ein Neustart des Postfix Service erfordert, wenn man das Passwort wechselt, ist schon ein Unding. Denn erst dann wird die sasldb2 aus /etc mit dem neuen Passwort nach /var/spool/postfix/etc kopiert – wenn der Eintrag in der /etc/init.d/postfix wie oben beschrieben gemacht wurde. Eine Verlinkung scheitert mit einer Fehlermeldung.

Außerdem muss einem Admin klar sein, dass Dovecot – also der IMAP Server – die Passwörter aus der /etc/shadow nutzt. So hat man zwei Passwörter an zwei Stellen im System zu pflegen. Schlimmer noch: Der Anwender braucht für einen Passwort- Wechsel Zugriff auf beide Stellen!

Wie durchschlägt man diesen Gordischen Knoten? Wenn wir bei dieser Konfiguration weitestgehend bleiben wollen, würde ich folgendes empfehlen: Aktiviere den saslauthd, setze also auf unverschlüsselte Passwörter, aktiviere TLS verpflichtend und lasse den Postfix in der chroot Umgebung. Damit ist nach meiner Meinung, dass optimale an Sicherheit im Rahmen der vorgestellten Konfiguration rausgeholt.

Alles ohne Garantie.