Sendeprotokoll

Genau das ist DSN. Wie mailtrace, nur besser. Mit DSN kannst du die Zustellung nachweisen. Nur eben nicht als Protokoll für alle deine Mails, sondern individuell je Email. Besser insofern, als du eine Rückmeldung durch den annehmenden Server bekommst. Mailtrace wäre "nur" eine Info des Absenderserver, also von mailbox.org. Der Nachteil ist, dass nicht jeder Empfängerserver DSN unterstützt. Ich hatte das früher mal probiert, und war überrascht, doch recht viele Rückmeldungen zu bekommen.

Der Satz "Vor Gericht und auf hoher See bist du in Gottes Hand" gilt ganz besonders im Bereich IT. Da gibt es wenig höchstrichterliche Rechtsprechung, und über die Urteile wundert man sich daher bisweilen. Sofern du eine Zustellung unwiderlegbar beweisen möchtest, muss du durch Gerichtsvollzieher zustellen lassen. Das kann die Gegenseite nicht widerlegen. Für alltägliches, wie die Kündigung der Tageszeitung oder der Verbraucherwiderruf im Onlineshop, hast du gute Chancen, dass vom Gericht die DSN als Zustellnachweis anerkannt wird. Der Beweiswert wird vermutlich mindestens so groß sein, wie der von Mailtrace.

Ansonsten sehe ich das wie zapata: Mailtrace wurde mal auf die To-Do-Liste gesetzt, und dann aber wider eingestampft.

Zu DSN: Ich habe es gerade (nicht repräsentativ, sondern zufällig) mit 3 Providern getestet; einer war mailbox.org. Von zahlreichen Mails zwischen den 3 Providern hat mailbox.org 1 x eine Rückmeldung verschickt; bei 3 oder 4 weiteren Mails an mailbox.org kam nichts. Bei den beiden anderen Providern kam überhaupt nichts. Das deckt sich mit meiner Beobachtung aus der Vergangenheit, dass die meisten Provider die DSN-Anforderung ignorieren.

Und der Teil den, im Falle von Mailtrace, oder wie man es auch immer nennen mag, die Gegenstelle unterstützen muss ist Teil des SMTP Protokolls und somit eigentlich immer verfügbar.

Mailtrace existiert seit Jahren für zwei/drei spezielle Kunden. Wir hatten den Wunsch, aber nie die Zeit das als generelle Lösung für andere Provider und Alltags-Massentauglivchkeit hochzuziehen. Wir haben keine Ressourcen, dieses Projekt weiter zu verfolgen, auch wenn ich persönluch Mailtrace liebe und für sehr wichtig und genial empfinde. Ist leider so. :-(

@thgeiges und @all:

DSN funktioniert wie folgt. Ein den Meta-Daten einer E-Mail wird eine DSN-Information transportiert. Diese sagt aus, Bei welchem Zustellergebnis, also WANN, der Absender informiert werden möchte. Bei einem

* BOUNCE (Nichtzustellbarkeit)

* SUCCESS (also Zustellung)

* DELAY (also Verzögerung mehr als <n> Stunden)

* NONE (ganz egal, wie die Mail ausgeht, bsp. bei Massenversand).

BOUNCE gibt es quasi (schon) immer. Ist die Mail nicht zustellbar, geht sie zurück.

DELAY gibt es quasi auch schon immer, war vor > 20 Jahren mal Mode als Mails auch mal stundenlang irgendwo rumlagen. Heute wird das kaum noch verwendet, weil die Verfügbarkeit heute anders gelebt wird und weil in der Praxis viele Nutzer die Delay-Warnings trotz explizitern Worten nicht verstanden und als fatales Bounce interpretriert haben. Unpraktisch.

Mittels DSN könnte man jetzt auch das Flag SUCCESS für die Mail setzen. Das ist optional, das machen Mailserver nicht automatisch (wer will das schon für jede Mail), aber mittels DSN kann man das setzen - wenn der Mailclient (!) DSN unterstützt. Open-Xchange tut das leider NICHT, wir wünschen uns das seit Gründung von mailbox.org, da ich seit ~15 Jahren ein großer DNS-Verfechter bin. Aber wir haben das leider nie durchsetzen können, da die in Open-Xchange verwendete Java-SMTP-Bibliothek das bis heute nicht kann und eine Implementierung alles andere als einfach wäre. DSN ist SMTP-Standard, wird aber von vielen Programmen/Programmierern aus Unkenntnis kaum unterstützt.

DSN-Informationen sind wie ein "Staffelstab". Mit jeder Mailübertragung wird die DSN-Information, also beispielsweise "DSN=SUCCESS" an den nächsten Mailserver weitergegeben. Der letzte Mailserver würde dann beim Abspeichern der Nachricht dieses DSN-Flag auflösen und die entsprechende SUCCESS-Meldung an den Absender zurücksenden.

Wenn es in der Kette der Mailserver irgendwo einen Mailserver gibt, der kein DSN unterstützt, so macht das nichts. Denn das letzte System mit DSN merkt dann, dass es das DSN-Flag nicht mehr übermitteln kann und löst dann die DSN-Information auf/aus. Sprich: Wenn mailbox.org die Mail an einen Proivder zusenden, der kein DSN nach außen anbietet, so sendet UNSER Mailrelay eine SUCCESS-Meldung an (unseren) Absender, dass die Mail an Provider XY übersandt wurde. Das ist auch völlig ausreichend, denn genau darum geht es ja: Die Beteiligten Systeme quittieren, dass die Mail bei XY "eingeworfen" wurde. Quasi ein Einwurf-Einschreiben mit Rückschein. Ironie: Das ist die einzige Variante, die es im klassischen Postwesen nicht gibt...

Insofern kann mailbox.org mit *jedem* Provider und *immer* auch DSN. Also wie, unsere Mailserver, leider aber nicht der Webmailer. Aber wenn man einen Mailclient nutzt, der das unterstützt. Es gibt dann *immer* auch eine DSN-Rückmeldung, egal ob der Zielprovider DSN kann, oder nicht.

Was sein kann, wenn es KEINE Rückmeldung gibt: Dann muss (!) das Zielsystem nach außen DSN angeboten haben, muss das also aktiv konfiguriert habe und dann aber, warum auch immer, die eigentliche Success-Meldung unterdrückt und weggeworfen haben. Das macht man aber nicht und ich habe ehrlich gesagt in der Praxis auch keine Systeme gesehen, die das gemacht haben. Das ist auch nicht einfach fehlerhaft so zu konfigurieren. Insofern kann ich mir das ehrlich gesagt so kaum vorstellen und schon gar nicht massenhaft. So oder so aber hat das dann was mit einem absolut falsch und auch völlig sinnfrei konfigurierten Zielsystem zu tun (sinnfrei, weil: wenn man es nicht will annonciert man DSN nicht nach außen und dann kann das letzte externe System eben den Einwurf quittieren und alle sind happy und works-as-expected).

@Peer Heinlein:

Danke für die ausführliche Erklärung.

Noch ein besinnliches Fest!

Noch eine kurze Ergänzung meinerseits. Bei weiteren Versuchen hat sich die Kombination mailbox.org und Thunderbird sowohl als Absender wie auch als Empfänger immer so verhalten, wie es Peer Heinlein oben beschrieben hat.

Fehler lagen bei mir entweder am anderen Provider oder am (von mir bevorzugten) Mail-Client „Postbox“ - einem Thunderbird-Abkömmling -, der zwar die Option DSN anbietet, sie aber offensichtlich nicht regelmäßig korrekt umsetzt.

@Peer Heinlein:

Könnten die DSN-Nachrichten der mailbox.org-Server mit einer DKIM-Signatur versehen werden? Dann könnte bewiesen werden, dass die Nachricht tatsächlich von mailbox.org stammt und die Bestätigung über die Zustellung einer E-Mail nicht gefälscht worden ist.

Vielen Dank für die ausführliche Antwort, jetzt bin ich schon wieder schlauer geworden.

Das scheint mir ideal für Kündigungen von Verträgen zu sein.

Auf die Schnelle schien aber kein von mir verwendeter Maildienst DSN zu unterstützen.

Wenn ich die "Successful Mail Delivery Report" Mails richtig interpretiere, scheinen die Mails immer die Bestätigung zu sein, dass Mailbox.org die Mail ordnungsgemäß abgegeben hat. Das müsste ja dann der Fall sein, wenn mailbox.org in der ganzen Server-Kette das letzte System war, das DSN unterstützt.

Kennt ihr Maildienste, die DSN vollständig unterstützen, sodass ich das einmal ausprobieren kann?

Die DSN-Bestätigung (SUCCESS) besagt entweder, die Mail wurde korrekt vom Empfänger-Server angenommen, wenn die Bestätigung von ihm ausgelöst wird (auf dem gleichen Weg zurück, wie die Mail hin). Oder sie kommt von mailbox.org, wenn mailbox.org die Mail erfolgreich ausgeliefert hat, der Empfänger-Server selbst aber keine Bestätigung schickt.

Bei meinen weiter oben erwähnten Tests, erhielt ich von GMX eine erfolgreiche Bestätigung, ebenso vom Webhosting-Provider "manitu". Von T-Online kam nichts; da kam die Bestätigung von mailbox.org selbst. Andere konnte ich auf die Schnelle nicht testen.