Wenn der beste MX eine Map sein soll
Heute flog mal wieder eine seltsame Fehlermeldung durchs Log bei der auch normales Googlen keine sinnvollen Ergebnisse brachte. Deswegen möchte ich sie hier dokumentieren.
bestmx_map_lookup: MX host 2001:4420:f501:0400::2. includes map delimiter character 0x3A
Der Übeltäter war schnell gefunden: Eine E-Mail an eine taiwanische Adresse.
550 5.1.2 <xxx@ems.shiyeu.gov.tw>... Invalid MX record for recipient host ems.shiyeu.gov.tw
Also schauen wir uns mal den MX genauer an:
$ host ems.shiyeu.gov.tw ems.shiyeu.gov.tw has address 117.56.237.218 ems.shiyeu.gov.tw has address 192.168.5.252 ems.shiyeu.gov.tw has address 192.168.56.1 ems.shiyeu.gov.tw has IPv6 address 2001:4420:f501:400::2 ems.shiyeu.gov.tw mail is handled by 10 117.56.237.218. ems.shiyeu.gov.tw mail is handled by 10 2001:4420:f501:0400::2.
Autsch! Da ist wohl jemanden aufgefallen, dass man keine IP-Adressen in den MX schreiben darf, weil dann Namen wie 117.56.237.218.ems.shiyeu.gov.tw. entstehen. Aber anstatt den Fehler zu verstehen und den Namen eines Servers hin zuschreiben, hat man einfach einen Punkt an die IP-Adresse angehängt und so den DNS-Namen verkürzt.
Der MTA interpretiert aber den Doppelpunkt (0x3A) als Trennzeichen in Maps (Hilfetabellen) und beschwert sich dann darüber.
Würde nur legacy IP(v4) benutzt, käme nicht mal eine so deutliche Fehlermeldung. Denn grundsätzlich könnte eine IP(v4)-Adresse auch ein gültiger DNS Name sein: Er hat alphanumerische Texte, die durch Punkte getrennt sind. Das zu der IP als Name interpretiert dann keine IP existiert, macht die Fehlersuche allerdings nicht einfacher.
Spielereien
Also spielen wir mal:
$ORIGIN donnerhacke.de. broken-mx MX 0 1.2.3.4 broken-mx2 MX 0 1.2.3.4.
Das ergibt dann bei der Abfrage im DNS:
$ host broken-mx.donnerhacke.de broken-mx.donnerhacke.de mail is handled by 0 1.2.3.4.donnerhacke.de. $ host broken-mx2.donnerhacke.de broken-mx2.donnerhacke.de mail is handled by 0 1.2.3.4.
Und damit versuche ich jetzt mal E-Mails zu verschicken.
from=<test@broken-mx.donnerhacke.de>, size=40, nrcpts=1, proto=ESMTP, daemon=MTA, relay=...
Das geht? Ja, natürlich. Ich habe ja einen Wildcard Eintrag. Der passt auch auf 1.2.3.4.donnerhacke.de. Und damit sieht das aus wie ein korrekter Absender.
550 5.1.2 <test@broken-mx2.donnerhacke.de>... Illegal MX record for recipient host broken-mx2.donnerhacke.de
Der andere Eintrag funktioniert aber nicht. Wie erwartet gibt es keine schwerwiegende Fehler-Meldung über irgendwelche Map-Zeichen, sondern nur eine blanke Ablehnung. Der Grund ist einfach, dass es für 1.2.3.4. keine IP Adresse im DNS gibt.
Beim Versenden der E-Mail an diesen Empfänger schaut es noch anders aus:
rcpt to: <test@broken-mx.donnerhacke.de> 250 2.1.5 <test@broken-mx.donnerhacke.de>... Recipient ok rcpt to: <test@broken-mx2.donnerhacke.de> 250 2.1.5 <test@broken-mx2.donnerhacke.de>... Recipient ok DATA ... 250 2.0.0 u4I8Kv6c010237 Message accepted for delivery
Und was passiert genau?
to=<test@broken-mx.donnerhacke.de>, relay=1.2.3.4.donnerhacke.de. [217.17.193.188], stat=User unknown to=<test@broken-mx2.donnerhacke.de>, relay=1.2.3.4., stat=Deferred: 1.2.3.4.: No route to host
In einem Fall greift der Wildcard-Eintrag, aber der Server nimmt keine E-Mail für solch einen Nutzer an.
In dem anderen Fall kann keine Adresse ermittelt und deswegen kann auch der Zielserver erreicht werden. Da eine solche Situation von externen Diensten abhängig ist und diese auch mal fehlerhaft sein können (die Namensauflösung kann schlicht auch mal scheitern), wir die E-Mail zurück gelegt und später nochmal versucht.
May 18 10:22:49 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host May 18 10:23:49 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host May 18 10:24:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host May 18 10:25:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host May 18 10:26:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host May 18 10:27:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host May 18 10:28:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host ...
Für den Admin ist die Meldung allerdings fehlerträchtig. Es ist leicht zu übersehen, das es sich um einen DNS-Namen und nicht um eine IP-Adresse handelt. Man kann Stunden damit zubringen, den Fehler überhaupt zu erkennen.
named: db.donnerhacke.de:48: warning: '1.2.3.4': MX is an address
named: db.donnerhacke.de:49: warning: '1.2.3.4.': MX is an address
Das sollte eigentlich auffallen. Schlimmer ist aber, dass die Entwickler der Software den Fehler so häufig sehen, dass sie die Warnung für notwendig gehalten haben. Ganz offensichtlich ist das aber witzlos. weil die Admins, die solchen Schrott eintragen, auch keine Logfiles lesen.
Total 1 comments