The changes required to the Postfix main.cf are extremely basic:

# Tell Postfix to use IPv6:
inet_protocols = ipv4,ipv6
# Add the equivalents to your existing IPv4 setup to mynetworks
mynetworks = 127.0.0.1/32 1.2.3.0/24 [::1]/128 [2001:db8:dead:beef::]/64
# This will be required if you need to override an autoconfed address
# (for outbound connections):
smtp_bind_address6=2001:db8:dead:beef::deca:fbad

After this, stop and start Postfix. A postfix reload alone will not bind to the new IPv6 interface.

After local testing, set up an additional AAAA record for your mailexchanger:

   MX 10 mx.example.com.
mx A 1.2.3.2
; The new record:
mx AAAA 2001:db8:dead:beef::deca:fbad

Don’t forget that you must, as always, set up proper forward and reverse DNS for your MX. Implement this at the same risk as if you were moving to a new IPv4 address.

Not long after the AAAA record is in place, you should see the spambots trying to deliver mail via IPv6, and Postfix will start to use IPv6 for outbound e-mail automatically if it can find a remote IPv6 MX. Which will be the case rather sooner than later.

See? You may still be an early adopter now, but you surely aren’t a pioneer living on the most remote corner of the net. I, for one, now have customers who use proper IPv6 e-mail without even knowing.

This was fixed by shutting down the VM, changing the SCSI adapter from Buslogic to LSI logic and booting up again. hdparm is at 63MB/s now. The machine, which will be an SMTP mail exchanger, now scans 8 mails per second (Postfix before-queue filter via amavisd-new+ClamAV) in 10 concurrent sessions. Not bad at all.

Debian is by far the simplest choice for an SMTP content filter because it’s not neccessary to bring in any dependencies by hand. Cool.

I replaced the stock rpm from CentOS 5 with the current released dovecot 1.0.10 rpm from atrpms.net, which instantly fixed the problem.

Packages of dovecot 1.0.10 for Debian are available from backports.org.

Aus dem Changelog:

TLS (SSL) support was streamlined further, and provides a new
security level based on certificate fingerprints instead of CA
signatures.

Wo man vorher bei der Mailauslieferung über Einträge in tls_policy_maps geprüft hat, ob das gegnerische Zertifikat von einer bekannten CA signiert ist und auf einen Common Name aus einer bestimmten Domain ausgestellt ist:

example.com secure match=example.net

kann man nun auch selbstsignierte Zertifikate verwenden (oder Zertifikate, die von einer CA ausgestellt sind, mit deren Zertifizierungspolicy man nicht einverstanden ist) und den Fingerprint prüfen:

example.com fingerprint
  match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1

Alle anderen Attribute des Zertifikats (insbesondere das Ablaufdatum) werden damit ignoriert.

Aus der Doku:

If certificate fingerprints are exchanged securely, this is the strongest, and least scalable security level. [...] This may be feasible for an SMTP “VPN” connecting a small number of branch offices over the Internet, or for secure connections to a central mail hub. It works poorly if the remote SMTP server is managed by a third party, and its public certificate changes periodically without prior coordination with the verifying site.

Ich finde es wirklich ulkig, daß hier von einem SMTP-VPN die Rede ist. Genau diesen treffenden Vergleich hat nämlich auch mal ein Kunde konstruiert, der im großen Maßstab Secure Channel TLS einsetzt, um den Internet-Mailtraffic mit seinen Partnern abzusichern.

Für die Verwendung im “Enterprise-Bereich” sollte die Prüfung von Fingerprints aber in der Tat trotz des objektiv zu gewinnenden Sicherheitsvorteils genau auf den Prüfstand gestellt werden. Schlampig arbeitende Gegenstellen mit Snake-Oil-Zertifikaten werden damit nämlich möglicherweise erst recht zu weiterhin schlampiger Arbeit angehalten.

Hier die Basiskonfiguration für TLS, ein Auszug aus der main.cf:
# TLS grundsätzlich deaktivieren, Aktivierung erfolgt dann fallweise.
smtp_tls_security_level = none
# Auch wenn wir selbst kein TLS machen, wollen wir loggen, wenn
# Gegenstellen TLS anbieten.
smtp_tls_note_starttls_offer = yes
# Apropos Log; standardmäßig loggt Postfix überhaupt keine Infos zu
# TLS-Transaktionen.
smtp_tls_loglevel = 1
# In dieser Map tragen wir die Gegenstellen ein, mit denen wir nur per
# TLS kommunizieren wollen.
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# Und in diesem Verzeichnis sind die Zertifikate enthalten, von denen
# die Zertifikate der Gegenstellen signiert sein müssen, um als akzeptabel
# zu gelten.
smtp_tls_CApath = /etc/postfix/tls/cacerts.d

Zu beachten ist, daß die im smtp_tls_CApath hinterlegten Zertifikate vor Verwendung gehasht werden müssen. Dafür wird das Perl-Script c_rehash aus der OpenSSL-Distribution verwendet.

c_rehash `postconf -h smtp_tls_CApath`

(Falls der smtp-Client im chroot läuft, müssen die Zertifikate und die Links mit den Hashwerten dort ebenfalls vorhanden sein. Man kann das z.B. erreichen, indem man die Zertifikate in /var/spool/postfix/etc/postfix/tls/cacerts.d/ ablegt und das Verzeichnis dann per Symlink aus /etc/postfix/tls/ erreichbar macht. Oder man legt einen entsprechenden Kopierjob an. Der Fantasie des Lesers sind keine Grenzen gesetzt.)

Wie intensiv die Zertifikate bei abgehenden Verbindungen geprüft werden sollen, wird mittels smtp_tls_security_level festgelegt. Darüberhinaus können in der über smtp_tls_policy_maps referenzierten Datei /etc/postfix/tls_policy pro Zieldomain abweichende Policies definiert werden. Es lassen sich eine ganze Menge “Sicherheitsstufen” einstellen:

• none: Es wird generell nicht verschlüsselt. Wenn der gegnerische Mailserver seine Verschlüsselungsbereitschaft anzeigt (STARTTLS im ESMTP-Greeting), wird dies ignoriert.

• may: Wenn der gegenerische Mailserver STARTTLS anbietet, wird verschlüsselt, wenn nicht, dann nicht.
• encrypt: Die Mail wird nur übertragen, wenn der gegnerische Mailserver STARTTLS anbietet und eine Verschlüsselung aufgebaut werden kann. Eine Prüfung des Server-Zertifikats findet nicht statt. Selbstsignierte Zertifikate werden akzeptiert.
• verify: Die Mail wird nur übertragen, wenn der gegnerische Server ein Zertifikat benutzt, das von einer CA ausgestellt wurde, deren Zertifikat im mit smtp_tls_CApath angegebenen Pfad enthalten ist.
• secure: Die Mail wird nur übertragen, wenn der gegnerische Server ein Zertifikat benutzt, das von einer CA ausgestellt wurde, deren Zertifikat im mit smtp_tls_CApath angegebenen Pfad enthalten ist und bei dem der im Zertifikat eingetragene Common Name mit der Zieldomain übereinstimmt.

Als Default-Policy (smtp_tls_security_level) eignen sich ausschließlich “none” und “may”, denn mit “encrypt” und aufwärts wird man ein Gateway, das Mail ins Internet senden soll, nicht betreiben können. Ich habe mich im vorliegenden Fall für “none” entschieden, da ich in der von “may” gebotenen opportunistischen Verschlüsselung keinen Nutzen erkenne. Im Gegenteil: Opportunistische Verschlüsselung kostet mich nicht nur Rechenzeit, sondern es besteht potentiell die Gefahr, daß Probleme bei der Kommunikation mit MTAs auftreten, bei denen TLS fehlerhaft konfiguriert und/oder implementiert ist.

Nun zu den Zielen, mit denen wir verschlüsselt kommunizieren wollen. Wenn man davon ausgeht, daß keine Verschlüsselung besser ist als schlechte Verschlüsselung, kann man die Optionen “may” und “encrypt” in diesem Zusammenhang direkt vergessen:

• Die opportunistische Verschlüsselung “may” bringt keinerlei Sicherheitsgewinn.

• Kaum etwas anderes gilt für “encrypt”: Für eine Gegenstelle Verschlüsselung zu erzwingen und dann jedes Zertifikat, egal ob abgelaufen oder selbstsigniert, zu akzeptieren, ist nur die Illusion von Sicherheit, gerade so, als würde man das routinemäßige Abklicken von SSL-Warnungen im WWW-Browser zum Standard erheben.

Übrig bleiben also “verify” und “secure”, von denen die letztere natürlich ganz besonders verlockend klingt und es auch ist:

• Mit “verify” wird erzwungen, daß Mail an eine Gegenstelle nur dann ausgeliefert wird, wenn deren Zertifikat von einer bekannten CA signiert wurde.

• Mit “secure” wird nicht nur, wie bei “verify”, das Zertifikat überprüft, sondern es wird auch noch verlangt, daß der Common Name des gegnerischen Zertifikats der Zieldomain entspricht. Alternativ kann auch eine Liste von Host- und Domainnamen angegeben werden, die als Common Names für die Zieldomain akzeptabel sind.

Hier also ein paar Beispiele für Einträge in der tls_policy.

• Für die Domain binblog.de soll uns eine einfache Überprüfung des Zertifikats reichen:
  binblog.de verify

• Die Mailexchanger der Domain example.com liegen alle in example.com (mx1.example.com und mx2.example.com), und wir wollen nur Zertifikate akzeptieren, die auf einen Hostnamen (Common Name) unter example.com ausgestellt sind:
  example.com secure

• Der Mailexchanger der Domain scsy.de hat den Namen vortex.f00.net. In diesem Fall müssen wir, wenn wir den Common Name überprüfen wollen, extra dazusagen, in welcher Domain er liegen bzw. welchen Namen er haben soll:
  scsy.de secure match=vortex.f00.net

Mit der in den letzten beiden Beispielen genannten “sicheren” Überprüfung von Zertifikaten stellen wir so weit wie möglich sicher, daß wir gegen DNS-Angriffe geschützt sind: Wird uns ein gefälschter MX-Record untergeschoben, weigert sich Postfix, Mail an diesen auszuliefern. Wechselt die Domain den Besitzer und bekommt neue Mailexchanger, weigert sich Postfix ebenfalls, Mail dorthin auszuliefern, solange nicht entsprechende Konfigurationsänderungen in der TLS Policy vorgenommen werden.

Wenn Postfix aufgrund einer Umstellung auf einer der Gegenseiten keine Mail ausliefern kann, werden die Mails übrigens nicht gebounced, sondern im Rahmen der normalen Timeouts in der Queue behalten. Es bleibt also genügend Gelegenheit, auf Überwachungen oder Useranrufe zu reagieren.

Diese gesamte Konfigurationsmethodik wurde von Postfix 2.2 zu Postfix 2.3 komplett ausgetauscht. Leider ist 2.3 bisher nur zu den wenigsten Distributionen durchgedrungen. Die Implementation in 2.3 ist aber so gelungen ausgefallen, daß ich jedem, der sich auf diese Ebene begeben will, nur zum Upgrade raten kann.

Wer das alles viel zu überkandidelt findet: Die übernächste Postfix-Version, 2.5, wird voraussichtlich sogar die Möglichkeit haben, gezielt die Fingerprints von Zertifikaten pro Zieldomain anzugeben. Damit dürfte dann wirklich das allerletzte DNS-Schlupfloch gestopft sein, und gleichzeitig können selbstsignierte Zertifikate verwendet werden.

Update am 21.3.: Hoffentlich werden hier jetzt keine Unwahrheiten mehr verbreitet.