4. Sicherheitsüberlegungen

Da UTF-8 häufig mehrere Oktette benötigt, um ein einzelnes Zeichen zu kodieren, kann die Internationalisierung dazu führen, dass Header-Feldwerte (im Allgemeinen) und E-Mail-Adressen (im Besonderen) länger werden. Wie in [RFC5322] spezifiziert, darf (MUST NOT) jede Zeile Zeichen, ohne CRLF, nicht mehr als 998 Oktette umfassen. Andererseits müssen MDA-Prozesse (Mail Delivery Agent), die E-Mail-Adressen oder lokale Teile parsen, speichern oder verarbeiten, besonders darauf achten, keine Puffer zu überlaufen, Adressen abzuschneiden oder Speicherkontingente zu überschreiten. Außerdem müssen sie beim Vergleichen darauf achten, die vollständigen Längen der Adressen zu verwenden.

Es gibt viele Möglichkeiten, UTF-8 zu verwenden, um etwas darzustellen, das einem bestimmten angezeigten Zeichen oder einer Zeichengruppe gleichwertig oder ähnlich ist; Einzelheiten zu den Problemen, die dies verursachen kann, finden Sie in den Sicherheitsüberlegungen in [RFC3629]. Der in Abschnitt 3.1 beschriebene Normalisierungsprozess wird empfohlen, um diese Probleme zu minimieren.

Die Sicherheitsauswirkungen von UTF-8-Headern auf E-Mail-Signatursysteme wie Domain Keys Identified Mail (DKIM), S/MIME und OpenPGP werden in Abschnitt 14 von [RFC6530] erörtert.

Wenn ein Benutzer sowohl eine Nicht-ASCII-Mailbox-Adresse als auch eine ASCII-Mailbox-Adresse hat, kann ein digitales Zertifikat, das diesen Benutzer identifiziert, beide Adressen in der Identität enthalten. Mehrere E-Mail-Adressen als Identitäten in einem einzigen Zertifikat werden bereits in PKIX (Public Key Infrastructure using X.509) [RFC5280] und OpenPGP [RFC3156] unterstützt, doch es kann in diesem Zusammenhang Benutzeroberflächenprobleme im Zusammenhang mit der Einführung von UTF-8 in Adressen geben.