Zusammenfassung

  • RFC 9873 ergänzt den Basis-Kontakt um genau eine ASCII- oder SMTPUTF8-Adresse und kann diese bevorzugen, ohne die vorhandene E-Mail zu entfernen.
  • Syntax, Unicode-Roundtrip, SMTP-Zustellung, Empfängerhandlung, Offenlegung und RDAP-Ausgabe bleiben eigenständige Beweisfragen.

Bei internationalisierten Adressen reicht „gespeichert“ nicht als Qualitätsurteil. RFC 9873 empfiehlt kontrollierte Zeichenrepertoires, IDNA2008-konforme Domains und Tests mit schwierigen kombinierenden Sequenzen. Die IANA-IDNA-Tabellen geben den registrierten Status von Codepunkten an; RFC 5895 betrifft Abbildungen an der Benutzerschnittstelle. Visuelle Ähnlichkeit bleibt trotzdem eine unsichere Identitätsgrundlage.

Die Erweiterung baut auf dem Kontakt-Mapping aus RFC 5733 auf. Dessen E-Mail bleibt erhalten. Hinzu kommt eine ASCII- oder SMTPUTF8-Adresse mit optionalem primary. Dieses Attribut setzt eine Verarbeitungspräferenz, löscht aber den Basiswert nicht und löst keinen Test der Mailbox aus.

Auch die Zustandsgrenze ist sauber: Ein leeres Element entfernt die Zusatzadresse bei einem Update oder meldet ihre Abwesenheit bei einer Abfrage. Es darf nicht als primär markiert werden. Ein nichtleerer Wert belegt demnach Konfiguration, nicht Erreichbarkeit.

Zuvor müssen Client und Server die Erweiterung nach RFC 5730 in Greeting und Login aushandeln. Bei erfolgreicher Aushandlung müssen sie den Wert annehmen, validieren, speichern und zurückgeben sowie SMTPUTF8 beim Versand oder Empfang beherrschen. Ohne Aushandlung dürfen sie die erweiterten Kontaktdaten nicht liefern. Das ist ein belastbarer Nachweis über die beiden EPP-Endpunkte.

Danach beginnt eine andere Kette. RFC 6530 beschreibt den Rahmen für internationalisierte E-Mail, RFC 6531 die SMTP-Erweiterung. DNS-Route, Mailbox, Weiterleitung, SMTP-Annahme, endgültige Zustellung, Lesen und Antwort sind dennoch getrennte Ereignisse. Eine Nachricht kann zwischen beiden Adressen weitergeleitet werden, und die Antwort kann aus einer anderen Schrift zurückkommen.

Für die Offenlegung gilt dagegen eine gemeinsame Regel. Die disclose-Entscheidung der Basis-E-Mail muss jede Zusatzadresse einschließen. Die öffentliche Darstellung ist trotzdem eine eigene Projektion. Verarbeitung über RDAP nach STD 95 verlangt nicht, jeden EPP-Wert wortgetreu zu zeigen. Der ICANN-Hinweis von 2026 ordnet pseudonymisierte Adressen und Webformulare politisch ein; er belegt keine Einführung von RFC 9873.

Heng Lus Lehre von den Realitätsebenen trennt ausgehandelte Fähigkeit, konfigurierten Wert, Normalisierung, Speicherung, Offenlegung, SMTP-Versuch, Transportergebnis, Empfängerhandlung und öffentliche Projektion. Seine minimale Anfangsspezifikation passt zum engen gemeinsamen Kern der Erweiterung. Der Vorrang laufenden Codes fordert für jeden Übergang reproduzierbare Spuren.

Die Führungsgefahr liegt in der Abkürzung: Ein stabil zurückgegebener Unicode-Wert wird als verifizierte Identität dargestellt, primary als Zustellgarantie oder ein RDAP-Formular als Veröffentlichung derselben gespeicherten Adresse. Keine dieser Folgerungen steht im Protokoll.

Quellen