In einer früheren Version dieses Artikels bin ich umständlich auf die Konfiguration von Postfix und saslauthd eingegangen. Da ich damals erst mit dem Artikelschreiben begann und auch fachlich noch nicht sehr gereift war, ist die alte Version dieses Artikels heute nicht mehr vertretbar.
Da ich aber nach-wie-vor dieses Thema für spannend und erklärungs-intensiv halte, mache ich einen neuen Versuch, dieses Thema zu bearbeiten. Ich sehe in dieser Artikelüberarbeitung eher einen Diskussionsbeitrag zu verschiedenen Aspekten des SMTP Servers Postfix. Daher wünsche ich viel Spass beim schmökern in diesen Text!
Software Versionen
Folgende Versionen liegen dieser 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.
Auch wenn dies mittlerweile vergangene Versionen sind, beschreibt der Artikel auch grundsätzliche Aspekte der Konfiguration und ist damit auch unabhängig der installierten Versionen zu lesen.
Das Szenario
Ich gehe hier von einer Mail- Server Konfiguration aus, die mehrere Mail-Domänen bedienen soll und die Mail- Anwender aus der lokalen Benutzer-Verwaltung des Servers nimmt. Also keine Datenbank oder LDAP!
Dummerweise sind mir beim Umzug dieses Artikels in das neue CMS die Bilder abhanden gekommen. Aber gerade dieser Artikel hatte viel mit Bildern dokumentiert. Damit ist dieser Artikel nur eingeschränkt brauchbar. Ich lasse ihn trotzdem online - vielleicht kann ja jemand aus dem Text noch die eine oder andere Information gewinnen.
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. Eine einfache und mit diesem Artikel ausbaufähige SMTP Mailserver (Postfix) Konfiguration erhält man, wenn auf der Konsole dpkg-reconfigure postfix ausgeführt wird.
Wenn Du alle Bilder aus diesen Artikel ausdruckst und untereinander klebst, bekommst Du allerdings eine brauchbare Konfiguration. Ich würde auch empfehlen, die Kommentare in meinen config- Bildern zu lesen! Weitergehende Ergänzungen zu diesen Artikel hänge ich als Kommentar unten dran.
Ab jetzt folgende Bilder beziehen sich auf die main.cf in /etc/postfix – wenn nicht anders erwähnt.
Stolperstein 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 gesetzt.
Delimiter: feine Sache
Die Option delimiter finde ich sehr spaßig: Sie sagt uns, mit welchen Zeichen wir eine Mailadresse unterteilen können. Nützlich ist diese Funktion, wenn Emails mit einen Filter einsortieren werden. So kann eine Mail an benutzername+umfrage@meinedomain.org leichter in den Ordner „Umfrage“ einsortiert werden.
Mailordner oder Mailfile?
Die Option mail_spool_directory ist eine Grundlegende: Damit wird Postfix gesagt, wo die Benutzer Postfächer liegen und mit dem slash (also ein Schrägstrich /) am Ende des Ordnernamens legen wir Postfix auf das maildir Format fest.
Wenn der slash am Ordnerende fehlt, geht Postfix davon aus, dass die mbox Variante gewünscht ist. Im wesentlichen unterscheiden sich diese Varianten in der Art der Email- Haltung:
Das mbox Format speichert alle Emails in eine Datei (Mailfile). Das maildir Format sichert jede Email als eine Datei in einen Ordner.
Dann gibt es verschiedene Varianten: Dovecot nimmt maildir und erstellt einen Index, Cyrus IMAP benutzt mbox (ein Mailfile) und Courier benutzt maildir ohne Indizieung der Emails.
Jede Variante hat natürlich Vor- und Nachteile: Wenn ein Mailfile defekt ist, sind alle Mails in diesen File betroffen, separate Indexe können ebenfalls defekt oder Verlust gehen, Varianten ohne Index können bei Suchen im Postfach sehr langsam sein und maildir erzeugt pro Email eine Datei – entsprechend muss die Festplatte arbeiten.
Die perfekte Speichervariante gibt es technisch gesehen also nicht, praktisch hat sich aber über die Kombination Postfix/Docecot doch maildir als quasi-standard etabliert.
Die Option mailbox_command übergibt (deliver) die Emails an den verfügbaren IMAP Server, hier dovecot.
Die endgültige Festsetzung der Email- Haltung muss natürlich zwischen Postfix und dem IMAP Server gleich sein. Also Beide mbox oder maildir. Ich zeige hier das maildir Format (slash am Ende) und empfehle den Dovecot IMAP Server. Wobei DBMail mittlerweile auch sehr interessant ist …
mailbox_command und mailbox_transport
Was ist aber der Unterschied zwischen den Optionen mailbox_command und mailbox_transport? Das mailbox_command wird in Verbindung mit lokalen Benutzern und mailbox_transport in Verbindung mit virtuellen Benutzern genutzt. In unseren Fall benutzen wir weder eine Datenbank noch LDAP zur Mail- Abwender Verwaltung. Wir benutzen lokale Anwender und damit 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.
virtual_maps anlegen
Die virtuelle Mail- Domänen – also Domänen für die der Mailserver verantwortlich zeichnet – werden in einer zweispaltigen Tabelle aufgeführt. Es ist grundlegend wichtig, dass ein MX Eintrag im DNS für jede Maildomäne eingetragen wird, damit unser Mail- Servern von anderen Mail- Servern ernst genommen wird!
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 zu einem Datenbankfile umgewandelt wurde. Der Dateiname ist frei wählbar. Die zweite Spalte wird nicht ausgewertet, muss aber einen Wert (z.B.: OK) gesetzt haben!
Genauso verfahren wir hier mit der Datei virtual_users (Dateiname ist frei wählbar).
Wieder eine zwei-spaltige Tabelle, in der links der virtuelle Benutzer- Namen festgelegt und rechts auf den realen Benutzer in unserer Benutzer- Verwaltung gemappt wird. 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 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.
Nochmal deutlich: In der /etc/postfix/main.cf wird quasi nur die Hauptdomäne konfiguriert! Mit der virtual_alias_domains erweitert man den Mailserver dann um weitere Domänen für die der Mailserver zuständig ist.
Alle (nicht nur die Hauptdomäne!) sollten als MX Eintrag im DNS präsent sein.
Was RFC’s verlangen
Einige Emailkonten sind auf einen Mailserver mandatory (Pflicht). Genaueres ist in den entsprechenden RFC’s nachzulesen. So muss der Mailempfänger abuse (zur Annahme von Beschwerden) und postmaster (als administrativer Account für die Dienste) auf dem Mail- Server präsent sein. Allerdings kann man für diese Mailempfänger auch aliase anlegen … Folgendes Zitat ist aus der SMTP RFC:
Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox “postmaster” as a case-insensitive local name.
Generell finde ich 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.
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, da der Benutzername in der Benutzerverwaltung des Servers eindeutig ist und keine Domänen- Zuordnung ermöglicht. Eine sinnvolle Namensgebung für Anwender ist also vorher zu überlegen …
SASL Konfiguration
Einfach gesagt: SASL ermöglicht eine Authorisierung von Mailclients an unseren Postfix SMTP Server. SASL wird über den saslauthd zur Vergügung gestellt. Der saslauthd kann Authorisierungen von Email- Versendern an verschiedenen Authorisierungs- Diensten ermöglichen.
So kann saslauthd gegen eine Benutzerdatenbank auf SQL oder LDAP Basis authorisieren, eine eigene kleine Datenbank (sasldb2) oder die lokale Benutzerverwaltung vom Linux Server (/etc/shadow) nutzen.
Die Wahl der Benutzerdatenbank legt auch fest, ob Kennwörter der Mail- Anwender verschlüsselt gelagert und übertragen werden müssen.
saslauthd und sasldb2
- Der saslauthd (pwcheck_method=saslauthd in smtpd.conf) ermöglicht ausschließlich eine Klartext (PLAIN / LOGIN) Anmeldung mit den Passwörter in der /etc/shadow an Postfix (dem SMTP Dienst).
- Die sasldb2 ermöglicht (auch) eine Anmeldung mit verschlüsselten Passwort (z.B. DIGEST-MD5, CRAM-MD5). Siehe obigen Link zur SASL Webseite für weitere Infos!
- Die zwei Arten der Passwortverwaltung sind un-abhängig von der verschlüsselten Übertragung einer Anmeldung: Dafür ist TLS entscheidend.
- Der Saslauthd wird in /etc/postfix/sasl/smtpd.conf konfiguriert.
- Soll sasldb2 (also verschlüsselte Passwörter) benutzt werden, ist im Postfix- Konfigurationsfile main.cf die Option smtpd_sasl_security_option mit dem Wert noplaintext zu erweitern.
- Die sasldb2 – also die mit saslpasswd2 erstellte Datenbank in der die Passwörter für die Mail- User stehen – liegt normalerweise mit root:postfix und 640 in /etc.
- 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. Bei Anmeldeprobleme einfach mal die sasldb2 in den genannten Pfad kopieren.
- Der Benutzer ‚postfix‘ muss der Gruppe ’sasl‘ zugewiesen werden.
Letztlich sollten die sasl- Befehle und Eigenheiten bekannt sein:
- saslpasswd2 -c -f -u <domäne> 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. Beachte die Option -u <domäne>, weil wir hier mehrere Maildomänen bedienen.
- sasldblistusers2 zeigt, welche Users in der sasldb2 hinterlegt sind.
- Über saslpasswd2 müssen die Email- Users auch ihr Passwort ändern können. Das Linux- Passwort ist nicht gleich sasl- Passwort! Vielleicht ‘usermin’ einsetzen?
- Gängige Fehlermeldungen beachten: „no secret in database“.
- Bei mehreren Domänen und sasldb2 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, wenn der Postfix SMTP Server in einer ge-chroot-eten Umgebung läuft.
Die chroot Umgebung ist ein Sicherheitsmerkmal von Postfix und hebt diesen Serverdienst aus dem realen Dateisystem und versetzt Postfix in eine Art Sandkasten – also in eine Ordnerstruktur auf einer anderen Ebene. Wenn dann also Eindringlinge über Postfix einbrechen, landen sie nicht im produktiven Ordnersystem und bleiben isoliert.
Dazu schafft sich Postix unter /var/spool/postfix eine eigene Ordner Ebene und kopiert – bei jeden Neustart des Postfix’s – für ihn wichtige Dateien aus dem üblichen Dateisystem dorthin.
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.
Eine mögliche Vorgehensweise wäre diese: Öffne die Datei /etc/init.d/postfix und erweitere die Datei- Liste (wie auf dem Bild) mit etc/sasldb2. Nach einen service postfix restart sollte die sasldb2 in den chroot- 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 gehe ich weiter unten im Artikel ein.
SASL realm
Aufgeschnappt: Sollte der Domänen- Teil (Stichwort: SASL realm) in saslpasswd2 nerven, kann mit der Option -r in /etc/default/saslauth oder mit der Option smtpd_sasl_local_domain in der main.cf experimentiert werden.
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.
SASL – die smtpd.conf
Folgendes Bild zeigt den Inhalt der /etc/postfix/sasl/smtpd.conf:
Wie im Bild sichtbar, ist die Konfiguration, ob sasldb2 oder saslauthd (mit lokalen Benutzerpasswort) 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 Dienst natürlich gestartet sein – wenn sasdb2 benutzt wird, kann der saslauthd deaktiviert sein. Beachte die Ausgabe von ps -ax.
Nochmal deutlich: saslauthd geht standardmäßig nicht mit cram-md5 (digest-md5,also verschlüsselte Passwörter). Wenn in deiner smtpd.conf saslauthd und cram-md5 steht, sollte die Konfiguration nochmal überprüft werden.
Beachte auch, dass die Nutzung eines unverschlüsselten Passwortes ohne Absicherung gefährlich ist! Entschärfe diese Sicherheitslücke mit TLS.
TLS – verschlüsselte Übertragung
Standardmäßig spricht Postfix TLSv1 und SSLv3. Das ist auch sehr gut so. Mit der Option (siehe Bild) smtpd_tls_mandatory_protocols kann man also nichts mehr wesentlich verbessern. Wobei es mittlerweile wichtig wäre, SSLv3 zu deaktivieren! 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 garnicht erst beginnt oder 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 aktiviert hat, die Verschlüsselung des Übertragungsweg auch benutzt wird – wenn nicht aktiviert, 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. Dies ist auch die von mir favorisierte Variante der Konfiguration!
Die Option smtpd_tls_received_header ist ganz spaßig: Sie setzt dem Mailheader 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.
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!
Tipp: Bei Bastelaktionen mit TLS kann es manchmal hilfreich sein, die letzte Option im Bild (limit) zu aktivieren und den Wert anzuheben.
Restriktionen
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 sind schneller entsprechende Stellschrauben im Betrieb verfügbar.
Bei den Einstellungen im folgenden Bild, geht es uns um den Briefkopf einer Email. Damit wollen wir sicherstellen, dass die angenommene Email in der Form korrekt ist. Damit können verschiedene Probleme in der Weiterverarbeitung einer Email gleich ausgeschlossen werden. Die Post klebt für Dich auch keinen Briefumschlag zu.
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) kann von Spammer genutzt werden, um gültige Mailadressen abzuchecken. Dann sollte der Client mit einen korrekten helo beim Mailserver anklopfen 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 nach Vorschrift.
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 in willkürlicher Reihenfolge zusammen gestellt werden.
- dass permit_mynetworks und permit_sasl_authenticated eingetragen ist.
- dass die teuren restrictions in der Liste am Ende stehen.
- dass zum Abschluss der Liste ein end-gültiges Statement (reject oder permit) steht.
Deswegen erstmal mit einen schmalen set starten – ausgebaut werden kann immer!
Teure Restriktionen?
Du kannst z.B. per restrictions festlegen, dass alle Absender von einkommenden Emails auf 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 auf 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 dieser Eintrag ist für policyd_weight gesetzt. Einfach das Paket policyd_weight installieren und den Eintrag wie im Bild setzen und schon werden alle eingehenden Emails – also die Absender, bevor die Email 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 (policyd), 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?
Mit Queue ist die Warteschlange des Mailservers gemeint. Queue ist nur kürzer als ‘Warteschlange’. Ähnlich wie Druckserver muss ein Mailserver 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 Emails vor der Queue oder in der Queue verworfen werden (Spam, Formfehler, Schadprogramme).
Damit ist die Frage, ob man in Postfix Filter einbaut, 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 entsprechenden Einträge in master.cf und main.cf setzen und Postfix reloaden.
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 der proxy 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 fehlerhaft!
Zusätzlich sehen wir die Bestätigung der chroot Umgebung des Postfix Server’s am Bindestrich (-) in der chroot Spalte. Damit wird die Standard Einstellung (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) weniger Mail- Anfragen annehmen soll.
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 landen kann.
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.
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 Emails gleichzeitig – umgehen kann. Zusätzlich ist der Eintrag -o content_filter= zu beachten.
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.
In den gängigen Internet Howtos zu Postfix ist meistens der content_filter beschrieben.
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.
amavisd-new gegen Viren
Hier wird nur die Einbindung von amavisd-new in Postfix beschrieben. Beachte, dass amavisd-new auch eine Konfiguration verlangt!
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 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 ist in der Datei /etc/amavis/20-debian_defaults und der Option inet_socket_port definiert.
Der port 10024 für den amavisd-new 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 vorteilhaft 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 der „künstlichen“ chroot 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 der Bindestrich (-) zu einen n (für nein/no) zu ändern.
Aber weil wir ja auch noch den saslauthd nutzen wollen und der ein ganz enger Partner von 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 Abschluss
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.
Ergänzungen
Ich erlaube mir – weil es jetzt auf zehn 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 drinsind. 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 diesen Artikel viele Einstellungen an meiner Mailserver- 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 out-of-the-box.
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 das Passwort gewechselt wird, 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 scheiterte auf meinen Server 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 Dateien!
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.
Viel Spass beim basteln
Comments