11. Weitere Probleme
Dieser Abschnitt identifiziert Probleme, die als Teil dieser Spezifikationsgruppe nicht oder nicht umfassend behandelt werden, aber im Rahmen der Bereitstellung der Internationalisierung von E-Mail-Adressen und -Headern einer fortlaufenden Überprüfung bedürfen.
11.1. Auswirkungen auf URIs und IRIs
Das mailto:-Schema [RFC6068] und seine Erörterung in der Spezifikation für Internationalized Resource Identifiers (IRI) [RFC3987] müssen möglicherweise geändert werden, wenn diese Arbeit abgeschlossen und standardisiert ist.
11.2. Verwendung von E-Mail-Adressen als Identifikatoren
Es gibt eine Reihe von Stellen in der heutigen Internet-Nutzung, an denen E-Mail-Adressen als Identifikatoren für Personen verwendet werden, einschließlich als Identifikatoren für Webserver, die einige Electronic-Commerce-Sites unterstützen, und in einigen X.509-Zertifikaten [RFC5280]. Diese Dokumente befassen sich nicht mit diesen Verwendungen, aber es ist vernünftig zu erwarten, dass einige Schwierigkeiten auftreten werden, wenn internationalisierte Adressen erstmals in diesen Kontexten verwendet werden, von denen viele nicht einmal den gesamten Bereich der heute erlaubten Adressen verarbeiten können.
11.3. Kodierte Wörter, signierte Nachrichten und Downgrading
Eine besondere Eigenschaft des E-Mail-Formats ist seine Persistenz: MUAs wird erwartet, dass sie mit Nachrichten umgehen, die ursprünglich vor Jahrzehnten gesendet wurden, und nicht nur mit solchen, die vor Sekunden zugestellt wurden. Daher werden MUAs und Mail-Filter-Software, wie die in Sieve [RFC5228] spezifizierte, weiterhin Header-Felder akzeptieren und dekodieren müssen, die den Mechanismus des "encoded word" [RFC2047] verwenden, um non-ASCII-Zeichen in einigen Header-Feldern aufzunehmen. Während Erweiterungen sowohl für POP3 [RFC1939] als auch für IMAP [RFC3501] definiert wurden, die ein automatisches Upgrading von Nachrichten umfassen, die non-ASCII-Informationen in kodierter Form tragen -- einschließlich der RFC-2047-Dekodierung -- von Nachrichten durch den POP3- [RFC5721bis-POP3] oder IMAP- [RFC5738bis-IMAP] Server, gibt es Nachrichtenstrukturen und MIME-Inhaltstypen, für die dies nicht möglich ist oder bei denen die Änderung unannehmbare Nebenwirkungen hätte.
Beispielsweise können Nachrichtenteile, die kryptografisch signiert sind, z. B. mit S/MIME [RFC5751] oder Pretty Good Privacy (PGP) [RFC3156], nicht ohne Brechen der Signatur von der RFC-2047-Form in normale UTF-8-Zeichen aufgerüstet werden. Ebenso können verschlüsselte Nachrichtenteile beim Entschlüsseln Header-Felder enthalten, die die RFC-2047-Kodierung verwenden; solche Nachrichten können ohne Zugriff auf kryptografische Schlüssel nicht "vollständig" aufgerüstet werden.
Ähnliche Probleme können auftreten, wenn Nachrichten signiert und anschließend herabgestuft werden, z. B. wie in Abschnitt 8.1 diskutiert, und dann versucht wird, sie in die ursprüngliche Form aufzurüsten und dann die Signaturen zu verifizieren. Selbst die sehr subtilen Änderungen, die sich aus Algorithmen zum Herabstufen und dann erneuten Aufrüsten ergeben können, können ausreichen, um die Signaturen ungültig zu machen, wenn sie entweder die primären oder die MIME-Body-Part-Header betreffen. Wenn Signaturen vorhanden sind, muss ein Downgrading mit äußerster Sorgfalt durchgeführt werden, wenn überhaupt.
11.4. Andere Verwendungen von lokalen Teilen
Lokale Teile werden manchmal verwendet, um Domänenlabels zu konstruieren, z. B. könnte der lokale Teil "user" in der Adresse [email protected] in einen Hostnamen user.domain.example mit seinem Web-Bereich unter http://user.domain.example und die Catch-All-Adressen [email protected] umgewandelt werden.
Solche Schemata sind offensichtlich unter anderem durch die SMTP-Regeln für Domänennamen eingeschränkt und werden ohne weitere Einschränkungen für andere lokale Teile nicht funktionieren. Ob diese Einschränkungen für diese Spezifikationen relevant sind, ist eine offene Frage. Es mag einfach ein weiterer Fall der beträchtlichen Flexibilität sein, die Zustell-MTAs bei der Bestimmung der Postfachnamen, die sie akzeptieren, und deren Interpretation gewährt wird.
11.5. Nicht standardmäßige Kapselungsformate
Einige Anwendungen verwenden Formate ähnlich dem application/mbox-Format [RFC4155] anstelle der in RFC 2046, Abschnitt 5.1.5 [RFC2046] definierten message/digest-Form, um mehrere Nachrichten als einzelne Einheiten zu übertragen. Insofern solche Anwendungen davon ausgehen, dass alle gespeicherten Nachrichten das in RFC 2046, Abschnitt 5.2.1 [RFC2046] beschriebene message/rfc822-Format mit ASCII-Nachrichtenheadern verwenden, sind sie nicht bereit für die in dieser Dokumentenreihe spezifizierten Erweiterungen, und es können besondere Maßnahmen erforderlich sein, um sie ordnungsgemäß zu erkennen und zu verarbeiten.