Zusammenfassung

  • RFC 3503 führte das gemeinsame, groß-/kleinschreibungsunabhängige Schlüsselwort $MDNSent ein, damit mehrere Mail User Agents an demselben IMAP-Postfach keine doppelten Message Disposition Notifications erzeugen.
  • Das Flag belegte keinen früheren Versand: Ablehnung durch den Nutzer, Kopien gesendeter oder unfertiger Nachrichten und automatische Entscheidungen ohne versandte MDN konnten denselben Sperrzustand erzeugen.

Mehrere Mailprogramme vor demselben Postfach sehen nicht automatisch dieselbe Vergangenheit. Das erste Programm kann lokal festhalten, dass es eine angeforderte Dispositionsbenachrichtigung behandelt hat. Öffnet ein zweites Programm dieselbe Nachricht auf einem anderen Rechner, fehlt ihm diese lokale Information. Ohne ein gemeinsames Merkmal könnte jeder Client die Anfrage neu auswerten und erneut antworten.

RFC 3503 erschien im März 2003 und behandelte genau diese Koordinationslücke. Das Dokument erfand weder einen neuen IMAP-Befehl noch eine neue Antwort. Es definierte das besondere Postfach-Schlüsselwort $MDNSent und beschrieb eine interoperable Verhaltensregel. Der gemeinsam gespeicherte Nachrichtenbestand wurde zum Träger einer schmalen, aber dauerhaften Entscheidung.

Der Name klingt wie eine abgeschlossene Tatsachenfeststellung: MDN gesendet. Die Schreibregeln waren absichtlich breiter. Nach automatischer Verarbeitung setzte der Client das Flag unabhängig davon, ob die MDN tatsächlich abgesandt wurde. Verweigerte ein Nutzer die Benachrichtigung, durfte derselbe Zustand verhindern, dass ein anderer Client später fragte oder sendete. Auch beim Speichern einer gesendeten Kopie und einer unfertigen Nachricht war das Schlüsselwort erforderlich.

Aus dem Bit folgen daher nicht die Ereignisse, die sein Name nahelegt. Es besagt zuverlässig nur, dass konforme Clients für dieses gespeicherte Objekt keine weitere MDN erzeugen sollen. Es nennt weder handelnden Client noch Einwilligung, Erzeugung, Einlieferung, Transport oder Zustellung. Über menschliches Lesen sagt es erst recht nichts.

Zunächst musste der Client prüfen, ob der Server die gemeinsame Erinnerung dauerhaft halten konnte. Bei Auswahl des Postfachs untersuchte er PERMANENTFLAGS. Der Server musste entweder $MDNSent selbst oder beliebige Schlüsselwörter unterstützen. Eine angekündigte Fähigkeit blieb jedoch von der einzelnen Ausführung getrennt. Trotz allgemeiner Unterstützung konnte STORE mit NO scheitern, etwa wenn das Postfach sein Schlüsselwortlimit erreicht hatte.

Die empfohlene Reaktion war, die MDN dann nicht zu senden. Ein sofortiger Versand ohne gespeichertes Sperrzeichen ließe den nächsten Client im Unklaren und öffnete die Wiederholung. RFC 3503 nahm eine fehlende Nachricht eher in Kauf als einen nicht koordinierten Doppelversand. Das ist keine allumfassende Exactly-once-Zusage, sondern ein sicherer Abbruch an der Stelle, an der der gemeinsame Beleg nicht geschrieben werden kann.

Vorhandene IMAP-Flags durften den Zweck nicht übernehmen. \Recent war als Auslöser untersagt, weil bei mehreren gleichzeitigen Verbindungen nicht festgelegt war, welche Verbindung eine neue Nachricht als recent sah. Ein uneinheitlich sichtbares Signal kann keine gemeinsame Zuständigkeit verteilen. \Seen durfte ein zusätzlicher Grund gegen den Versand sein; \Draft schützte eine unfertige Nachricht. Beide besaßen eigene Bedeutungen. War $MDNSent vorhanden, musste der Client die anderen Flags für diese Entscheidung ignorieren.

Das Schlüsselwort war außerdem monoton. Ein Client durfte es nach dem Setzen nicht wieder entfernen. So ließ sich eine alte Anfrage nicht leicht versehentlich reaktivieren. Zugleich wurde sichtbar, was der Zustand nicht war: kein Auditprotokoll. Er speicherte keinen Zeitpunkt, keinen Akteur, keine Begründung und kein externes Ergebnis. Er regelte die Zukunft, ohne die Vergangenheit vollständig zu erzählen.

Beim Kopieren musste die Sperre mitwandern. Der Client sollte prüfen, dass COPY $MDNSent erhielt. Wurde zwischen Servern mit APPEND kopiert, musste das Schlüsselwort korrekt mitgegeben werden. Andernfalls kam der Inhalt am Ziel an, während die Koordinationsentscheidung verloren ging; ein Ziel-Client könnte fehlende Metadaten als neue Erlaubnis lesen.

Die ACL-Regel trennte zwei Befugnisse. Der Server prüfte weiterhin, ob der Client die Nachricht kopieren durfte. War die Kopie erlaubt, sollte $MDNSent auch dann erhalten bleiben, wenn dem Client das allgemeine Recht zum Schreiben von Flags fehlte. Kopierberechtigung war nicht freie Attributbearbeitung, und die Erhaltung einer Objekteigenschaft war keine zusätzliche Vollmacht.

Auch die Schreibweise durfte den Zustand nicht spalten. $MdnSENt, $MdnSENT und $mdnsent galten als dasselbe Schlüsselwort. Die Beispiele suchten mit anderer Großschreibung als zuvor angezeigt. Ohne diese Regel könnten zwei Clients nebeneinander an derselben vermeintlich gemeinsamen Erinnerung vorbeiarbeiten.

Eine wirkliche MDN gehört auf eine andere Beweiskette. RFC 2298 beschrieb das frühe Format, RFC 3798 überarbeitete es, und RFC 8098 wurde als STD 85 Internet Standard. Seine Dispositionen sind begrenzt. displayed bedeutet, dass ein MUA die Nachricht jemandem zeigte, der das Postfach betrachtete; Lesen oder Verstehen sind nicht garantiert. processed kann eine Regel ohne Menschen bezeichnen. deleted beweist weder, dass die Nachricht nie gesehen wurde, noch dass sie nicht wiederherstellbar ist.

Datenschutz begrenzt die Erzeugung zusätzlich. Die Voreinstellung sollte gegen den Versand stehen; bei bestimmten Adressunterschieden ist Zustimmung nötig. Eine MDN kann gefälscht werden, verloren gehen, Mailbombing verstärken oder Clientdetails preisgeben. RFC 8098 weist ausdrücklich zurück, dass MDNs Nichtabstreitbarkeit der Zustellung liefern oder garantieren, ob eine Nachricht gesehen wurde.

RFC 5788 formulierte die Registrierung später präziser als der Name: $MDNSent ist ein gemeinsames Schlüsselwort, das festlegt, dass für die markierte Nachricht keine MDN gesendet werden darf. Das ist eine Anweisung an den nächsten Akteur, keine Bescheinigung über den vorigen.

In JMAP verband RFC 9007 Handlung und Zustand enger. Ein Aufruf von MDN/send muss die Aktualisierung von $mdnsent veranlassen; der Server lehnt einen Aufruf ab, der diese Aktualisierung nicht ergibt, und kann bei vorhandenem Zustand mdnAlreadySent melden. Diese Kopplung verkleinert eine Lücke innerhalb der JMAP-Methode. Sie beweist weder menschliches Lesen noch endgültige Zustellung und schreibt älteren IMAP-Systemen nichts rückwirkend vor.

Für eine saubere Auswertung braucht es mehrere Quittungen. PERMANENTFLAGS belegt eine angekündigte Speichermöglichkeit. STORE OK belegt eine akzeptierte Zustandsänderung. $MDNSent belegt die gemeinsame Unterdrückungsregel. Erzeugung, Einlieferung, Übertragung und Empfang der Benachrichtigung haben eigene Nachweise. Eine Disposition ist eine typisierte Behauptung. Aufmerksamkeit und Verständnis liegen dahinter.

Die historische Leistung von RFC 3503 besteht in der Begrenzung. Gemeinsam sein musste lediglich das Verbot, dieselbe Handlung für dasselbe gespeicherte Objekt zu wiederholen. Der Server musste nicht zum Richter über Wahrnehmung oder Zustimmung werden. Ein dünner gemeinsamer Zustand koordinierte Programme, ohne die Wirklichkeit zu ersetzen.

Wer den Feldnamen später als Ereignisbeweis liest, erweitert seine Autorität. Aus Sperre wird Versand, aus Versand wird Zustellung, aus Anzeige wird Verstehen. Die Norm selbst hält dagegen: $MDNSent konnte gerade deshalb korrekt gesetzt sein, weil keine MDN gesendet werden sollte.

Quellen