Zusammenfassung

  • RFC 2368 erweiterte mailto: um Empfänger, Header und einen kurzen Klartextkörper, ohne beim Auflösen der URL eine sofortige Netzverbindung zu verlangen.
  • Der Client durfte gefährliche Felder verwerfen und sollte das vollständig dekodierte Ergebnis vor einer Zustimmung zeigen; Link, Klick und ausgefüllter Entwurf belegten weder Versand noch Zustellung.

Bei einem gewöhnlichen Weblink folgt auf den Klick meist eine Anfrage an ein entferntes System. Bei mailto: konnte die gesamte Auflösung lokal enden. Ein Fenster war geöffnet, mehrere Felder waren ausgefüllt, doch noch war keine Mail unterwegs.

RFC 1738 kannte vor allem die Adresse. RFC 2368 ergänzte eine Mailbox-Liste sowie Name-Wert-Paare nach ?, getrennt durch &. Der besondere Name body lieferte den ersten text/plain-Teil. Eine Webseite konnte so eine Listenanmeldung, eine Anfrage an einen Informationsdienst, eine Archivantwort oder eine Nachricht mit Kopie vorbereiten.

Weniger Tipparbeit bedeutete nicht weniger Zuständigkeiten. Der Herausgeber kontrollierte die URL. Ein Parser wandelte Escapes in Adressen und Felder. Der Mailclient entschied über seine Sicherheitsregeln. Der Nutzer prüfte und entschied. Erst danach konnten Einlieferungsserver, Transportwege und Zielpostfach eigene Tatsachen erzeugen. Kein früher Zustand ersetzte den späteren Beleg.

Die Kodierung war Teil dieser Grenze. ?, = und & strukturierten das Format und mussten als Daten prozentkodiert werden. Leerzeichen wurden %20, Zeilenumbrüche im Körper %0D%0A, ein wörtliches Prozentzeichen %25. In HTML musste der Trenner & als & erscheinen. Quelltext, geparste URL und sichtbarer Entwurf waren verschiedene Darstellungen. Eine falsche oder doppelte Dekodierung konnte Empfänger oder Feldgrenzen verändern.

Auch die Internationalisierungsgrenze von 1998 blieb sichtbar. Nicht kodierte Acht-Bit-Zeichen waren verboten. MIME-encoded-words waren in Headerwerten möglich, nicht aber in body. Variablenersetzung fehlte; eine statische URL konnte weder die Adresse der klickenden Person zuverlässig einfügen noch eine kontextabhängige Signatur erzeugen. Das Format war bewusst eine Vorlage, kein allgemeines Programm.

Die Grammatik erlaubte mehr, als ein Client ausführen musste. Bei gefährlichen Headern durfte er die Nachricht ganz verweigern oder nur sichere Teile übernehmen. Subject, Keywords und Body galten als nützlich; From, Bcc, Routing- und manche MIME-Felder waren besonders verdächtig. Syntax verlieh dem fremden Dokument keine Autorität über Absenderidentität oder versteckte Ziele.

Vor dem Senden sollte der Client die vollständige dekodierte Nachricht samt aller URL-Header anzeigen, deutlich auf die bevorstehende E-Mail hinweisen und Zustimmung verlangen. Der Standard nannte konkrete Risiken: Identitätsabfluss an Dritte, Gebühren, rechtswidrige Aussagen oder schädliche Aktionen, die dem Nutzer zugerechnet würden.

Deshalb muss die Beweiskette gestuft bleiben. Die URL belegt ein Angebot. Der Klick belegt höchstens Aktivierung. Ein Entwurf zeigt, welche Felder der Client angenommen hat. Sendeentscheidung, Serverannahme, Zustellung, Lesen und ausgelöste Handlung brauchen jeweils eigene Protokolle.

RFC 6068 ersetzte den Text 2010, erlaubte UTF-8-basierte Prozentkodierung und präzisierte Duplikate sowie Sicherheitsfragen. Die Hauptgrenze blieb: Eine URI war eine Nachrichtenvorlage. Korrekte Zeichen waren keine Einwilligung, und Einwilligung war keine Zustellungsquittung.

RFC 2368 steht damit für zurückhaltende Automatisierung. Ein externes Dokument durfte Arbeit abnehmen, aber nicht die Entscheidung des lokalen Nutzers übernehmen.

Quellen