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 😉

 

Das Anastasia Botnetz

Spams gibt ja immer und meisten steckt heute ein Botnetz dahinter. Das Netzwerk, das unsere Mailserver derzeit am meisten nervt, ist das von mir so genannte Anastasia Botnetz.

Es ist allerdings leicht am Absender zu identifizieren, der immer das Wort Anastasia am Anfang hat:

2017-08-02 01:44:59 H=(ip-38-239.tricom.net) [186.150.38.239] rejected MAIL <Anastasiabj@tricom.net>: identified as Anatasia Botnet
2017-08-02 01:45:43 H=(ocit-41.189.55.239.aviso.ci) [41.207.201.171] rejected MAIL <Anastasiafab@aviso.ci>: identified as Anatasia Botnet
2017-08-02 01:45:46 H=([115.164.85.255]) [115.164.85.255] rejected MAIL <Anastasiabcbr@puretechnutrition.com>: identified as Anatasia Botnet
2017-08-02 01:47:05 H=([51.36.222.115]) [51.36.222.115] rejected MAIL <Anastasiacoe@incco.com.gt>: identified as Anatasia Botnet
2017-08-02 01:47:27 H=(131-108-125-254.infortek.net.br) [131.108.125.254] rejected MAIL <Anastasiarcae@infortek.net.br>: identified as Anatasia Botnet
2017-08-02 01:47:32 H=160.red-81-39-134.dynamicip.rima-tde.net [81.39.134.160] rejected MAIL <Anastasiaxte@woburnapartments.co.nz>: identified as Anatasia Botnet
2017-08-02 01:47:54 H=([161.132.100.51]) [161.132.100.51] rejected MAIL <Anastasiamm@rhinohandyman.com>: identified as Anatasia Botnet
2017-08-02 01:48:56 H=([186.235.188.234]) [186.235.188.234] rejected MAIL <Anastasiacljgf@pedicur.ru>: identified as Anatasia Botnet
2017-08-02 01:49:06 H=([202.90.136.58]) [202.90.136.58] rejected MAIL <Anastasiaxw@directiva.com.br>: identified as Anatasia Botnet
2017-08-02 01:49:44 H=([175.101.251.27]) [175.101.251.27] rejected MAIL <Anastasiadihu@it-is-it.com>: identified as Anatasia Botnet
2017-08-02 01:50:25 H=(host-177-232-80-119.static.metrored.net.mx) [177.232.80.119] rejected MAIL <Anastasiaazy@metrored.net.mx>: identified as Anatasia Botnet
2017-08-02 01:50:31 H=([27.123.171.127]) [27.123.171.127] rejected MAIL <Anastasiabviyu@hrcbmdfw.org>: identified as Anatasia Botnet
2017-08-02 01:50:32 H=85.233.11.37.dynamic.jazztel.es [37.11.233.85] rejected MAIL <Anastasiayurg@jazztel.es>: identified as Anatasia Botnet
2017-08-02 01:51:18 H=(static.vnpt.vn) [113.161.8.21] rejected MAIL <Anastasiafir@static.vnpt.vn>: identified as Anatasia Botnet
2017-08-02 01:52:20 H=fixed-187-189-92-55.totalplay.net [187.189.92.55] rejected MAIL <Anastasiahw@fixed-187-189-92-55.totalplay.net>: identified as Anatasia Botnet
2017-08-02 01:52:26 H=(static.vnpt.vn) [14.183.242.229] rejected MAIL <Anastasiaud@static.vnpt.vn>: identified as Anatasia Botnet
2017-08-02 01:52:34 H=(static-ip-cr18152012787.cable.net.co) [181.52.127.87] rejected MAIL <Anastasiaxcs@cable.net.co>: identified as Anatasia Botnet
2017-08-02 01:53:09 H=(host-177-232-87-110.static.metrored.net.mx) [177.232.87.110] rejected MAIL <Anastasiarclg@metrored.net.mx>: identified as Anatasia Botnet
2017-08-02 01:53:20 H=red.connectbd.com [202.79.16.10] rejected MAIL <Anastasiavpuup@red.connectbd.com>: identified as Anatasia Botnet
2017-08-02 01:53:42 H=([161.132.100.51]) [161.132.100.51] rejected MAIL <Anastasiaualik@grouptower.com>: identified as Anatasia Botnet
2017-08-02 01:54:30 H=([123.23.241.122]) [123.23.241.122] rejected MAIL <Anastasianwz@ubsystems.com>: identified as Anatasia Botnet
2017-08-02 01:55:05 H=(187.253.122.253.cable.dyn.cableonline.com.mx) [187.253.122.253] rejected MAIL <Anastasiadabgp@cableonline.com.mx>: identified as Anatasia Botnet
2017-08-02 01:57:59 H=(static.vdc.com.vn) [113.190.40.226] rejected MAIL <Anastasiailk@vdc.com.vn>: identified as Anatasia Botnet
2017-08-02 01:58:21 H=([191.99.126.26]) [191.99.126.26] rejected MAIL <Anastasiafsg@zarlock.com>: identified as Anatasia Botnet
2017-08-02 01:59:32 H=([41.216.32.42]) [41.216.32.42] rejected MAIL <Anastasiaecous@vertexconsultancy.co.in>: identified as Anatasia Botnet
2017-08-02 01:59:42 H=(181-174-59-224.telebucaramanga.net.co) [181.174.59.224] rejected MAIL <Anastasiajinv@simtecno.com.br>: identified as Anatasia Botnet
2017-08-02 02:00:19 H=([31.145.75.194]) [31.145.75.194] rejected MAIL <Anastasiaonl@juste.com.tw>: identified as Anatasia Botnet

Das dies nur ein kleiner Ausschnitt von nur einer einzigen Maschine ist, deutet das Ausmaß des Botnetzes an.

Für alle die einen EXIM Mailserver betreiben, hier die Regel um die Spams gezielt auszufiltern:

acl_check_mail:

# Hosts are required to say HELO (or EHLO) before sending mail.
...
drop message = identified as Anastasia Botnet
     condition = ${if match{$sender_address}{\N^Anastasia.*\N}{1}{0}}

Natürlich ist die Regel sehr grob, auch eine echte Anastasia.Kulikovwa@mail.ru würde ausgefiltert werden, aber im Gegensatz zu zum Botnetz, könnte die Dame zum Telefon greifen und einfach anrufen, daß die Mails nicht ankommen. Davon abgesehen sind 0.01% falsche Treffer eine echt gute Quote, mit der ich persönlich leben kann 🙂

Selbstverständlich könnte man die Regeln entsprechend verfeinern:

 condition = ${if match{$sender_address}{\N^Anastasia.{2,5}@.*\N}{1}{0}}

Diese Anpassung entspricht dem Muster, daß nach Anastasia noch bis zu 5 zufällige Zeichen kommen vor dem @.

Da es ähnliche Regelsätze für andere Mailserver gibt, könnt Ihr da natürlich jetzt Eure eigenen Anpassungen machen.

Lets Encrypt: Zertifikatsprobleme auf iOS Geräten

Seit Dezember 2015 stellt Lets Encrypt kostenlose Zertifikate zur Verfügung. Damit kann man Webseiten und Mailserver schützen, wenn da nicht die liebe Realität in Form von iOS wäre.

Bei unserem hausinternen Versuch, die Mailserver von einem kommerziellen Comodozertifikat auf Lets Encrypt umzustellen, was für Webseiten überhaupt kein Problem war, stellte sich raus, das sofort alle iOS Endgeräte, egal ob iPhone 5,6,7 oder iOS 9,10 keine Emails mehr empfangen konnten. Entäuschenderweise war auch Thunderbird betroffen 🙁

Daraufhin haben wir auf ein Comodozertifikat umgestellt und die Lage beruhigte sich, bis einige iOS Geräte anfinden, nur noch Emails zu senden, aber keine mehr zu empfangen. Wohlgemerkt, mit dem gleichen SSL-Zertifikat 😉

Nach derzeitigen Erkenntnissen seitens Comodo und unseren Technikern, liegt das Problem beim iOS Gerät selbst. Mal sehen was Apple dazu meint.

Auflösung: Mail.APP ist buggy, denn jedes andere installierte Emailprogramm auf einem betroffenen IPhone hat das Zertifikat einwandfrei akzeptiert. Aber der Witz kommt jetzt, dem Kunden hat das neue Mailprogramm „My Mail“  viel besser gefallen als die original App 😀