Ich erzähl euch mal eine kurze Geschichte: Heute am späten Nachmittag ereilte mich der Hilferuf eines befreundeten Emailadmins. Einer seiner Mailserver, zugegen einer auf dem recht wenig los ist, nimmt keine Emails mehr an. „Relay Access Denied“ steht da im syslog drin. Ok, etwas genauer darauf geschaut: Das trifft nur auf die Emails zu die von Gmail kommen. Alles andere, wenn mal was vorbei kommt, läuft „richtig“ durch. Eine Besonderheit der Empfangsdomain: IDN, Punycode, SMTPUTF8 und kein ASCII. Oder, ganz anders ausgedrückt „German umlaut in the domain name“. Seit RFC-6530…6533 soll das ja kein Thema mehr sein. Siehe z.B. hier: https://tools.ietf.org/html/rfc6531 – das ist wohl das RFC wo der interessanteste Teil zu den Grundlagen von SMTPUTF8 drin steht.

 

In der Postfix-Doku ist ganz gut erklärt warum Postfix sich schwer damit tut zu erahnen ob eine Domain jetzt UTF8 oder ASCII ist und was das für Seiteneffekte mit sich ziehen kann. Siehe hierzu http://www.postfix.org/SMTPUTF8_README.html#detecting sowie die darauf folgenden Abschnitte. Unterm Strich sollte das aber keine große Hürde darstellen – mag man meinen.

 

Per telnet fix nachgeschaut:

telnet <bla.blubb> 25
Trying 253.254.255.256..
Connected to <bla.blubb>.
Escape character is '^]'.
220 <bla.blubb> ESMTP Try me, beat me!
ehlo duda
250-<bla.blubb>
250-PIPELINING
250-SIZE 31457280
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8
quit
221 2.0.0 Bye

 

Alles gut, SMTPUTF8 steht mit drin. Und ja, im Postfix Log steht die Emailadresse je nach Modul mal als UTF8 oder als ASCII drin – siehe oben, der Link zum Readme. Aber irgendwie, Relay Access Denied. Trotz allem. Hm… Während die Gedanken sich so winden: Kleiner Online-Konverter gefällig mit dem der Titel dieses Textes zurück nach ASCII übersetzt werden kann? Bitte schön, gibt es hier: http://unicode.org/cldr/utility/idna.jsp. Aber zurück zum eigentlichen Thema, wir waren beim Hm… stehen geblieben. Dort läuft noch ein amavisd-new-milter. Ob der was damit zu tun haben kann? Laut https://www.ijs.si/software/amavisd/release-notes.txt nein, der soll alles richtg können (Achtung, bei dem Link hab ich gerade ein SSL-Zertifkatsfehler ignorieren müssen). Fix via telnet nachgeprüft – lief hier auf dem üblichem Amaivs-Port 10024: SMTPUTF8 taucht in der Liste erwartungsgemäß auf.

 

Bleibt noch der letzte Beteiligte in der Kette: Dovecot LTMP. Kann der mit SMTPUTF8 umgehen? Eine eindeutige Aussage dazu habe ich nicht gefunden. Also falls Ihr was finden solltet wo eindeutig drin steht „ja, das geht“ oder „nein, das geht (noch?) nicht“: Nur her damit!

 

Jetzt mal ernsthaft und das ganze Bild nochmals komplett betrachtet: Andere Emails kommen an. Und die haben kein Problem mit dem Umlaut in der Domain. Nur die von Gmail nicht. Ggf. auch noch von ein paar weiteren, da ist bloß bisher noch nichts aufgefallen. So muss Gmail hier als stellvertretendes Beispiel dienen. Was macht in diesem Falle hier Gmail anders als der Rest? Das Internet schweigt sich aus. Nur wenig lässt sich finden wo das exakt gleiche Problem beschrieben wird. Lösungen fehlen aber. Gefühlte tausende Logzeilen von Postfix im Debug Modus später und zwar das Problem immer weiter eingekreist auf das oben beschriebene aber keine Lösung gefunden. Doch Moment mal: Das Problem ist doch wohl der Natur, dass die Ursache im Umlaut, also SMTPUTF8 liegen muss. Es ist ja nun mal so, dass einige Emails ankommen obwohl die Domain einen Umlaut hat. Was ist wohl bei denen anders als bei denen die nicht ankommen? So langsam wird es zwingend logisch was bei denen anders sein muss. Na, schon die passende Idee dazu? Ich hab es einfach gleich mal ausprobiert und in die main.cf von Postfix folgendes eingetragen: „smtputf8_enable = no“. Per telnet geprüft: SMTPUTF8 fehlt. Und siehe da: Die Emails von Gmail kommen an. Da jetzt kein SMTPUTF8 mehr angeboten wird übergibt Google die Mails in ASCII-Darstellung. Und schon klappt alles wie erwartet. Google scheint, wenn es die Gegenseite anbietet, doch tatsächlich SMTPUTF8 zu nutzen. Und ist damit wohl noch einer der wenigen die das so tun.

 

Freundlicherweise hab ich ja noch ein paar Appliances von namhaften Herstellern im Angebot wo man via telnet auf den SMTP-Port mal rasch prüfen kann was die so tun: Kein SMTPUTF8. Ok, die werden wohl wissen warum. Das weiß ich jetzt ebenfalls.

 

Aber irgendwie bleibt ein ungutes Gefühl bei der ganzen Sache. Die Durchdringung von Umlautdomains ist wohl doch noch nicht so weit wie man denken mag. Wirklich toll ist das nicht. Ich freue mich schon, oder auch nicht, wenn der erste Kunde kommt der bei diesem Mailhoster aus Redmond liegt. Wo dem Namen nach die Kunden das ganze Jahr lang jeden Tag im Büro verbringen. Und wenn dann dieser Kunde sagt er hat eine Umlaut-Domain: An dem Tag hab ich vermutlich Urlaub…