Exim – Wie man TLS erzwingt

Exim ist einer der vielseitigsten Mailserver die man auf einem Server haben kann, fast Nichts ist unmöglich. In einer Zeit, in der immer mehr abgehört wird und die Kommunikation von Personen, Firmen und Behörden geschützt werden muß, finden sich immer noch Mailserver, die kein TLS sprechen.

Mailtransportverschlüsselung

TLS wurde vor fast 19 Jahren per RFC als Nachfolger von SSL geboren und hat dies erfolgreich abgelöst. Sollte man jedenfalls meinen. Tatsächlich habe ich erst heute eine Rechnung von 1und1 bekommen, ja, Name & Shame in progress, die mit einem gebrochenen TLS 1.0 aka. „SSLv3 modified“ übertragen wurde :

H=mbulk.1and1.com [212.227.126.220] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256

Da unser Server TLS1.2 spricht und anbietet, kann man von einem Konfigurationsfehler ausgehen. Wenigsten wurde hier TLS gesprochen. Andere Mailserver können nicht mal SSL, die senden und empfangen unverschlüsselt, nicht wahr liebe Admins von faller.de 😉

Wie man TLS erzwingt

Im letzteren Fall kann man Exim dazu bewegen, daß er keine Emails ohne TLS sendet. Damit kann verhindert werden, daß Geheimnisse abgehört werden können. Exim ist von Haus aus mit den nötigen Funktionen ausgestattet und daher extrem leicht dafür zu begeistern 🙂

Der in praktisch jeder Eximconfig vorkommende Transporttreiber „remote_smtp“ muß nur um zwei Befehle erweitert werden:

remote_smtp:
 driver = smtp
 hosts_require_tls = *
 tls_tempfail_tryclear = false

Das zwingt Exim dazu, ohne TLS Verbindung abzubrechen und auf keinen Fall auf Klartext zurückzufallen. Das wäre ja auch selten dämlich, oder ? Tja, wie sich herausstellte, ist sich immer einer in der Welt nicht zu blöd, genau das zu machen 😀 Mein Name & Shame Beispiel für diesen Fail, hat sich allerdings bekehren lassen und sendet jetzt vorbildlich in TLSv1.2 \o/

Der ewige Optimist Exim

Exim sieht einen Fail beim TLS leider als temporären Fehler an. Er geht also davon aus, daß der empfangende Mailserver irgendwann in der Retryzeit seine Meinung ändert 😀 Aus Erfahrung kann ich sagen, nein, tun die empfangenden Mailserver nicht 🙂

Daher müssen wir die Retryzeit für diesen Fall auf 0 setzen, so daß sofort eine Delivery Message erzeugt wird.  Das erledigen wir so :

begin retry

*          refused
*           quota
*        tls_required
*             *         F,2h,15m; G,16h,1h,1.5; F,4d,6h

Das war es bis auf einen kleinen Schönheitsfehler schon: die Delivery Message macht für den Leser derselben keinen Sinn, da ein falscher Fehlergrund ausgegeben wird, aber das ist Euer Problem 😉