© Patrizia Tilly, Fotolia.com

Anfang Mai erschien die jährliche stabile Postfix-Release. Schon allein der vollautomatische Antistress-Modus liefert Gründe genug für einen genauen Blick auf die Details.

Einfacher, schneller, stabiler, sicherer, noch kompatibler und leichter administrierbar, so steht\’s in der Veröffentlichung. Hohe Ziele für die neue Version eines mächtigen Mailservers, der ohnehin schon ein hohes Ansehen genießt. Im Detail verbessert die Version 2.6.2 das Verhalten des MTA an vielen Ecken und bringt eine lange erwartete Veränderung der Architektur sowie ein vollautomatisches Stressmanagement für Zeiten mit hoher Last mit.

Einfache Konfiguration

Postfix [1] unterscheidet sich von Eric Allmans Sendmail besonders durch sein einfacheres Konfigurationsinterface. Der Grundsatz “So einfach wie möglich, aber ja nicht einfacher!” galt von Anfang an für die gesamte Entwicklung. Dieser Maxime folgend hat Chefentwickler Wietse Venema Postfix nun selbst einer ersten größeren Revision unterzogen. Denn auch sein MTA führt mit seinem mächtigen Funktionsangebot bei komplexeren Konfigurationen leicht zu Unübersichtlichkeit und Verwirrung.

Bisher schlugen sich Postfix-Anwender beispielsweise beim klassischen All-in-One-Mailserver mit »pre-filter smtpd«, »content_filter«, »post-filter smtpd« unter anderem mit folgenden Fragen herum:

• Wo und wann wendet Postfix Alias-Umschreibungen an? Vor dem
  Filter oder nach dem Filter? Oder gar an beiden Stellen?
• Welche Mails befinden sich noch vor dem Filter und warten auf
  Bearbeitung?
• Welche Mails befinden sich bereits hinter dem Filter?
• Wie kann ich nur die Mails hinter dem Filter flushen?

Auch die Anforderung, einen Multi-homed Server auf einem System umzusetzen, etwa um den MTA mit verschiedenen Identitäten (HELO-Name, TLS-Zertifikat) nach außen hin darzustellen, war in früheren Versionen nur über Umwege realisierbar. Verrenkungen dieser Art tritt der nun eingeführte Multi-Instanz Manager (MIM) entgegen. Er gestattet es, ein komplexes System in überschaubare Bestandteile zu zerlegen und auf mehrere Postfix-Instanzen zu verteilen.

Die Konfiguration wird übersichtlicher und als besonderes Schmankerl ist das Gesamtsystem besser steuerbar, denn jede Postfix-Instanz hat ihre eigene Queue und lässt sich damit unabhängig vom Gesamtsystem beeinflussen. In einem Multi-Instanz-Postfix ist es möglich, Mails auch hinter einem Filter in einer separaten Instanz zu flushen.

Postfix unter Druck

Einen Postfix unter Last erkennt der erfahrene Admin in der Regel an folgenden Symptomen:

• Neue Verbindungen nimmt er weiter an, aber es dauert
  ungewöhnlich lange bis das SMTP-Banner erscheint; alle
  »smtpd«-Prozesse sind aktiv und in einer SMTP-Session
  gebunden.
• Das Log weist viele »lost connection after
  CONNECT«-Meldungen auf.
• Viele SMTP-Verbindungen befinden sich unter der Netstat-Lupe im
  Zustand »FIN_WAIT1/2«. Die Verbindung ist noch offen.
  Einer der beiden Kommunikationspartner – Client oder Server
  – muss die Connection aktiv beenden.

Postfix eilt überlasteten Systemen ab sofort mit einem eigenen Betriebszustand zu Hilfe, dem Stress Mode. Ein gestresstes Postfix ändert sein Betriebsverhalten, es passt sich an die Situation an und sorgt selbstständig für Entspannung. Die Stress-Konfiguration erfordert die Anwendung erweiterter Konfigurationssyntax, wie sie bereits seit Postfix 2.2 dabei ist.

Der Parameter »$stress« bleibt dabei standardmäßig ohne Wertangabe, also ohne »no« oder »yes«. Der Postfix-»master«-Daemon setzt ihn selbstständig – genau dann, wenn alle für den Server (»smtpd«) vorgebenen Prozesse aktiv sind. Die Ausgabe des »ps«-Kommandos listet den »smtpd«-Server in diesem Betriebszustand mit dem zusätzlich aktivierten Parameter »stress=yes«.

Stresstherapie

Für einige Parameter sieht Postfix bereits in der Standardkonfiguration Stressverhalten vor. Das »smtpd_hard_error_limit« liegt dann bei 1 anstatt entspannten 20, das »smtpd_junk_command_limit« bei strikter 1 anstatt 100 und der »smtpd_timeout« fällt im Stressfall von 300 auf 10 Sekunden (Listing 1).

Ein gestresster Postfix-Server kennt keine Gnade mehr für potenziell fehlerträchtige Clients, er will Störenfriede abschütteln, damit so schnell wie möglich wieder Ruhe einkehrt. Das Ziel ist die Rückkehr in den Normalmodus, in dem nicht mehr alle Smtpd-Prozesse gebunden sind. Postfix prüft alle 1000 Sekunden, ob dieser Zustand erreicht ist.

01 # postconf -d | grep stress
02 smtpd_hard_error_limit = ${stress?1}${stress:20}
03 smtpd_junk_command_limit = ${stress?1}${stress:100}
04 smtpd_timeout = ${stress?10}${stress:300}s

Erweiterte Resistenz

Die Autoren des Linux-Magazins empfehlen, das Stress-Standardverhalten zusätzlich zu erweitern. Reaktionen auf Clients, die in DNS-Blacklisten geführt werden, sollten unter Stress deutlich schärfer ausfallen, um Postfix von unerwünschten Verbindungen zu entlasten. Statt wie üblich mit dem SMTP-Reply-Code »554 Transaction failed« auf eingehende Verbindungen gelisteter Clients zu reagieren, sollte ein gestresstes Postfix mit »521 <Servername> does not accept mail« antworten [2].

Auf den ersten Blick zeigt sich kein großer Unterschied. Beide Reply-Codes gehören in die 5er Gruppe, also zu den permanenten Fehlern. Im Detail offenbart sich dann der gewinnbringende Unterschied: Antwortet ein SMTP-Server mit »554« muss er warten, bis der Client mit einem »QUIT« die Verbindung abbaut. Sendet der Server »521«, muss er nicht auf den Client warten, sondern baut die Verbindung selbst ab. Die Ressource ist nicht mehr gebunden. Sie steht dem Gesamtsystem sofort wieder für eingehende Verbindungen zur Verfügung.

Die Stressanpassung bedient sich der erweiterten Konfigurationssyntax:

rbl_reply_maps = ${stress?$default_database_type:/etc/postfix/rbl_reply_maps} 

Ist der Server gestresst, setzt er zusätzlich die »rbl_reply_map« aus »/etc/postfix/rbl_reply_maps« ein. Im Normalfall findet sie keine Anwendung.

Die genannte Map modifiziert die Serverantwort wie folgt: Beide Antispam-Sublisten führen Bereiche auf, in denen keine MTAs betrieben werden sollen oder dürfen. Baut ein Client eine SMTP-Verbindung zu Postfix auf, beantwortet der Agent die Anfrage mit »521 4.7.1 Service unavailable;…« und terminiert sie umgehend. Der Smtpd-Prozess wird frei und kann den nächsten Client bedienen (siehe Listing 2).

01 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable; $rbl_class [$rbl_what] blocked using
02 $rbl_domain${rbl_reason?; $rbl_reason}
03 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable; $rbl_class [$rbl_what] blocked using
04 $rbl_domain${rbl_reason?; $rbl_reason}

Ohne SSL Version 2

Postfix bietet TLS seit Version 2.2 als Standardfeature an. Seither wächst der TLS-Funktionsumfang, vor allem dank des Engagements von Viktor Duchovni, mit jeder weiteren Release. Die Version 2.6 bringt eine Änderung des Standardverhaltens und eine Erweiterung des Funktionsumfangs.

Ab sofort verweigert der Postfix-SMTP-Client die Nutzung des SSLv2-Protokolls. Der dafür geschaffene Parameter »smtp_tls_protocols « (Standard: »!SSLv2«) steuert dieses Verhalten. Der SMTP-Server »smtpd« bleibt davon unberührt und unterhält sich weiterhin mit Clients per SSLv2, wenn diese es wünschen.

Dieser Schritt wurde notwendig, weil SSLv2 von Anfang an als “Broken by Design” gilt [3]. Im Mail-Alltag bringt der Wegfall von SSLv2 auch keine Probleme. Die Nachfolgeprotokolle SSLv3 und TLSv1 sind seit 1996 und 1999 spezifiziert und in Anwendung.

Mit ECC und DKIM

Ebenso begrüßenswert ist die Erweiterung des TLS-Funktionsumfangs um ECC-Zertifikate (Elliptic Curve Cryptography). Sie gelten in Fachkreisen als wünschenswerte Alternative zu RSA- und DSA-Zertifikaten, denn ECC erreicht mit wesentlich kürzeren Schlüssellängen von 224 Bit Länge die gleiche Sicherheit wie RSA-Zertifikate mit 2048 Bit. Smartphones mit ihren vergleichsweise schwachen CPUs profitieren von den kürzeren Schlüsseln. Die kryptographischen Berechnungen belasten die CPU weniger und die Mobiles bauen schneller sichere Verbindungen zu Postfix auf.

Diese Erleichterung war einer der Gründe für Viktor Duchovni, ECC-Support in Postfix zu integrieren. Ebenso wichtig war ihm auch, mit ECC-Zertifikaten die allgemeine Systemsicherheit zu erhöhen. Denn die bekannten besten Angriffe auf ECC benötigen mehr Zeit (exponentielle Zeit) als gegen RSA (Faktorisierung, sub-exponentielle Zeit) oder gegen DSA (Bestimmung des diskreten Logarithmus, sub-exponentielle Zeit). Details dazu finden sich unter [4]. Die ECC-Zertifikate setzen übrigens OpenSSL ab Version 0.9.9 voraus.

DKIM und Milter

DKIM-Signaturen (Domain Keys Identified Mail) beschreiben den inhaltlichen Zustand einer Nachricht zum Zeitpunkt des Signierens. Wird die Nachricht anschließend verändert, zerstört dies die Signatur und die Integrität der Nachricht ist dahin. Postfix ergänzt »Resent-From:«, »From:«, »Date:«, »Message-ID:« und »To:«-Header deshalb nur noch dann, wenn die Clients in »$local_header_rewrite_clients« gelistet sind. Das bisherige automatische Hinzufügen dieser Header zerstörte in bestimmten Situationen bestehende DKIM-Signaturen.

Darüber hinaus unterstützt der Mailserver nun auch Version 6 des Milter-Protokolls. Seit der Postfix-Version 2.2 arbeitet Wietse Venema daran, das Sendmail-Milter-Protokoll in Postfix zu integrieren. Das ist nicht immer einfach, denn beide MTAs arbeiten intern unterschiedlich und Postfix hat bestimmte Informationen nicht immer dann parat, wenn das Milter-Protokoll sie gerne hätte.

Die aktuelle Erweiterung erlaubt es jetzt, Milter-Filter einzusetzen, die beispielsweise den Envelope Sender verändern. Der leidgeplagte Postmaster kann damit Bounce Address Tag Validation (BATV, [5]) implementieren und seine Empfänger so effektiv vor Backscattern schützen. Der Filter verändert »p@state-of-mind.de« vor dem Versenden beispielsweise in »prvs=tag-value=p@state-of-mind.de«. Wird nun eine Nachricht an »p@state-of-mind.de« gebounced, kann der Filter vor ihrer Annahme prüfen, ob der zusätzliche String »prvs=tag-value=« enthalten ist, und die Nachricht abweisen, falls er fehlt oder fehlerhaft ist.

Ohne Richtung, aber auf dem richtigen Weg

Die neuen Features in Version 2.6.2 zeigen, wie reif Postfix mittlerweile geworden ist. Eine ausgeprägte Entwicklungsrichtung ist aktuell nicht zu erkennen. Das ist sicherlich auch ein Indiz dafür, dass Entwickler und Community Postfix im Wesentlichen für bereits komplett halten. Daher bringt diese Release viele kleinere, teilweise schon lange ersehnte Features mit und macht Postfix somit ein weiteres Mal noch praktischer und noch nützlicher. (mfe)