Zusammenfassung

  • RFC 2298 vom März 1998 führte Disposition-Notification-To als Bitte um eine Meldung über die Behandlung einer Nachricht ein. Der User Agent des Empfängers konnte sie ignorieren oder im ursprünglichen Format denied zurückgeben.
  • Eine MDN meldete Vorgänge wie Anzeigen, Weitergeben, Verarbeiten oder Löschen. Der RFC empfahl die Zustimmung des Nutzers nachdrücklich und begrenzte die Antwort auf eine MDN pro Empfänger und Nachricht. RFC 3798 strich 2004 die kaum genutzten Zustände denied und failed.

Eine Frage reist mit der Post

Ein Büro im Jahr 1998: Die E-Mail ist geschrieben, der Absender klickt auf Senden. Mitgeschickt wird ein zusätzlicher Header. Er nennt eine Adresse, an die eine Nachricht über die spätere Behandlung zurückgehen soll. Disposition-Notification-To klingt amtlich, ist aber zunächst eine Frage. Sobald die Nachricht im fremden Postfach landet, arbeiten andere Einstellungen und ein anderer Mensch an der Antwort.

Der RFC 2298 gab Message Disposition Notifications, kurz MDNs, ein Format. Seine zweite Sektion nennt den Header ausdrücklich eine Anfrage. Das empfangende Programm darf ihn still übergehen. Die erste Fassung hatte außerdem denied, einen förmlichen Bescheid, dass der Empfänger über den Verbleib der Nachricht keine Auskunft geben will. Vor dem Versand einer MDN sollte der User Agent nachdrücklich die Zustimmung des Nutzers einholen. Das konnte eine Frage zu jeder Nachricht sein oder eine gespeicherte Voreinstellung. Der Absender bekam ein Formular, keinen Schlüssel zum Postfach.

Die Zustandswörter waren sorgfältiger als das populäre Etikett „gelesen“. Displayed bedeutete, dass das Programm die Nachricht jemandem beim Zugriff auf das Postfach angezeigt hatte. Dispatched konnte Drucken oder Weiterleiten meinen. Processed erfasste eine Regel oder einen Servervorgang. Deleted meldete das Löschen. Die Definitionen im RFC betreffen solche Handlungen. Ein Mensch kann auf den Bildschirm sehen, ohne einen schwierigen Satz schon begriffen zu haben. Das Feld beschreibt die Anzeige.

Auch der Weg zur Meldung war aufgeschlüsselt. Ein Modus unterschied eine manuelle Handlung von einer automatischen. Ein zweiter unterschied die eigens erlaubte Rückmeldung von einer Rückmeldung, die eine frühere Einstellung auslöste. Zwei MDNs mit dem Zustand displayed konnten so verschiedene lokale Entscheidungen enthalten. Der Absender erfuhr mehr, wenn er beide Modi las, statt das Wort als Urteil über Aufmerksamkeit zu behandeln.

Die Verfasser begrenzten den Eifer der Programme. Für einen Empfänger durfte dessen User Agent zu einer Nachricht höchstens eine MDN ausstellen. Eine MDN durfte selbst keine neue MDN verlangen; ihr Eingang durfte ebenfalls keine erzeugen. Zwei Programme, die sich endlos den Empfang ihrer jeweiligen Quittung quittieren, sind ein brauchbarer Witz. Im Mailverkehr wären sie ein Fehler gewesen. Die Regel beendete ihn vor der ersten Zugabe.

Ein Rückmeldeziel konnte zudem missbraucht werden. Ein Absender hätte zahlreiche Empfänger um Bestätigungen an die Adresse eines unbeteiligten Dritten bitten können. Deshalb empfahl RFC 2298 einen Vergleich von Disposition-Notification-To und Return-Path. Unstimmige oder fehlende Rückwege sowie mehrere Zieladressen sollten eine Bestätigung durch den Nutzer auslösen oder die automatische MDN verhindern. Der Text nennt Mailschleifen und Mailbomben als Gründe. Eine höfliche Bitte durfte nicht zum Multiplikator für Belästigung werden.

Hier sind die Zuständigkeiten sauber verteilt. Der Absender schreibt seine Bitte. Das Empfängerprogramm prüft Adresse und Voreinstellungen. Der Nutzer kann zustimmen oder die Antwort unterlassen. Eine tatsächlich versandte MDN berichtet einen abgegrenzten Vorgang auf der Empfängerseite. Die Zustellung der E-Mail schuf keinen Anspruch auf eine tägliche Inventur fremder Aufmerksamkeit.

Sechs Jahre später verschwand die förmliche Ablehnung aus dem Wortschatz. RFC 3798 ersetzte 2004 RFC 2298 und entfernte denied und failed wegen fehlender Nutzung oder Implementierung. Stilles Nichtantworten blieb möglich. Das große Formular für „Nein“ ging verloren; die Tür blieb beim Empfänger.

Die historische Lesebestätigung war damit ein kleines Stück Verhandlungstechnik. Sie verband die Neugier des Absenders mit einem Bericht über Softwarehandlungen und einem lokalen Recht auf Auswahl. Wer eine MDN bekam, erhielt ein Stück Protokollgeschichte aus dem fremden Mailprogramm — keinen Blick in fremde Gedanken.