SMTP-DSN: Warum einfach …

… wenn es auch kompliziert geht.

Hintergrund ist folgender: Ich habe für eine Plattform ein Mailinglisten-System implementiert. Das war notwendig, weil es dort sehr spezielle Regeln zur Generierung der Empfänger gibt, die jedes Mal dynamisch angewendet werden müssen. Bestandteil dieses System ist natürlich auch die Erzeugung von Bounces, um Fehler und Ausnahmezustände mitzuteilen.

Dabei ist mir etwas aufgefallen: Es gibt drei nette RFCs, die sich mit dem Format dieser Delivery Status Notifications (DSN oder kurz Bounce) beschäftigen:

Diese Konventionen regeln, wie eine Bounce-Message aufgebaut ist, wie die Informationen abgelegt werden, welche Fehlercodes es gibt und so fort.

Und nun kommt unser kompliziertes Leben: Kein Mail User Agent, den ich kenne, wertet die Bounces anhand dieser RFCs aus! Statt dessen bekommt der – mittlerweile oft laienhafte – E-Mail-Nutzer eine kryptische Fehlermeldung zu sehen, die häufig so interpretiert wird, dass die Adresse nicht existiert. Das ist ein beliebter Grund für Bounces, aber oft auch falsch.

Liebe MUA-Programmierer: Warum gibt es keine Ansicht fuer Bounces, in der die Informationen aufgeschlüsselt sind und auch den Nutzern, die E-Mails nicht per telnet lesen können, verständlich gemacht werden? Das würde einen weißen (nein, eigentlich schwarzen) Fleck auf der Landkarte der E-Mail-Kommunikation beseitigen.

Leave a Reply

Your email address will not be published. Required fields are marked *