8. Downgrading vor und nach SMTP-Transaktionen
Ein wichtiges Problem bei diesen Erweiterungen ist der Umgang mit Wechselwirkungen zwischen Systemen, die non-ASCII-Adressen unterstützen, und Legacy-Systemen, die ASCII erwarten. Es gibt natürlich kein Problem damit, dass reine ASCII-Systeme an solche senden, die internationalisierte Formen verarbeiten können, da die ASCII-Formen nur eine echte Teilmenge sind. Wenn jedoch Systeme, die diese Erweiterungen unterstützen, Mail senden, können (MAY) sie non-ASCII-Adressen für Absender, Empfänger oder beide enthalten und möglicherweise auch andere non-ASCII-Header-Informationen als Adressen bereitstellen. Wenn die Erweiterung vom First-Hop-System nicht unterstützt wird (d. h. dem SMTP-Server, auf den der Submission-Server zugreift, der als SMTP-Client fungiert), sollten (SHOULD) nachrichtenursprüngliche Systeme darauf vorbereitet sein, entweder konventionelle Umschläge und Nachrichtenheader zu senden oder die Nachricht an den ursprünglichen Benutzer zurückzugeben, damit die Nachricht möglicherweise unter Verwendung kodierter Wörter (encoded words) [RFC2047] in den Nachrichtenheadern manuell in die traditionelle Form herabgestuft werden kann. Natürlich implizieren solche Transformationen, dass der ursprüngliche Benutzer oder das ursprüngliche System für alle Absender und Empfänger reine ASCII-Adressen zur Verfügung haben muss. Mechanismen, mit denen solche Adressen gefunden oder identifiziert werden können, liegen außerhalb des Geltungsbereichs dieser Spezifikationen, ebenso wie Entscheidungen über den Entwurf ursprünglicher Systeme, etwa ob erforderliche Transformationen vom Benutzer, vom ursprünglichen MUA oder vom Submission-Server vorgenommen werden.
Eine etwas komplexere Situation ergibt sich, wenn das First-Hop-System diese Erweiterungen unterstützt, aber ein nachfolgender Server in der SMTP-Übertragungskette nicht. Es ist wichtig zu beachten, dass die meisten Fälle dieser Situation bei vorwärts gerichteten Adressen (forward-pointing addresses) das Ergebnis von Konfigurationsfehlern sein werden: Insbesondere wenn er non-ASCII-Adressen hostet, sollte ein final delivery MTA, der diese Erweiterungen akzeptiert, nicht (SHOULD NOT) mit MX-Hosts niedrigerer Präferenz konfiguriert werden, die dies nicht tun. Wenn die einzige übertragene non-ASCII-Adresse rückwärts gerichtet ist (z. B. in einem SMTP-MAIL-Befehl), kann die Empfängerkonfiguration im Allgemeinen nicht helfen. Andererseits sind alternative reine ASCII-Adressen für Absender diejenigen, die am wahrscheinlichsten von der Submission-Umgebung oder dem Absender selbst autoritativ bekannt sind. Folglich wird ein intermediäres SMTP-Relay, das diese Erweiterungen benötigt und dann feststellt, dass das nächste System in der Kette sie nicht unterstützt, kaum eine andere Wahl haben, als die Nachricht abzulehnen oder zurückzugeben.
Wie oben diskutiert, kann ein Downgrading auf eine reine ASCII-Form vor oder während der initialen Nachrichtenübermittlung (message submission) erfolgen. Es kann auch nach der Zustellung an den final delivery MTA auftreten, um Nachrichtenspeicher, IMAP- oder POP-Server oder Clients mit anderen Fähigkeiten als der Zustell-MTA zu bedienen. Diese Fälle werden in den folgenden Unterabschnitten diskutiert.
8.1. Downgrading vor oder während der Nachrichtenübermittlung
Die IETF hat traditionell vermieden, das genaue Verhalten von MUAs festzulegen, um maximale Flexibilität in den zugehörigen Benutzeroberflächen zu ermöglichen. Der SMTP-Standard [RFC5321], Abschnitt 6.4, räumt MUAs und Submission-Servern großen Spielraum ein, was vom Benutzer bereitgestellt werden kann, solange das Ergebnis den "on the wire"-Standards entspricht, sobald es in das öffentliche Internet eingespeist wird. In dieser Tradition werden die Erörterungen im Rest von Abschnitt 8 als allgemeine Leitlinie und nicht als normative Anforderungen bereitgestellt.
Nachrichten, die diese Erweiterungen erfordern, werden manchmal an ein System übertragen, das diese Erweiterungen nicht unterstützt; es ist wahrscheinlich, dass die häufigsten Fälle die Kombination von reinen ASCII-vorwärts gerichteten Adressen mit einer non-ASCII-rückwärts gerichteten Adresse betreffen. Bis die hier beschriebenen Erweiterungen in der Internet-E-Mail-Umgebung universell implementiert sind, müssen Absender, die non-ASCII-Adressen (oder rohe UTF-8-Zeichen in Header-Feldern) bevorzugen, selbst wenn ihre beabsichtigten Empfänger reine ASCII-Adressen verwenden und erwarten, besonders sorgfältig auf die Fehlerbedingungen achten, die auftreten können. Die Risiken sind besonders groß in Umgebungen, in denen Unzustellbarkeitsnachrichten (oder andere Hinweise von Submission-Servern) routinemäßig verworfen oder ignoriert werden.
Vielleicht offensichtlich ist der günstigste Zeitpunkt, um eine einer internationalisierten Adresse entsprechende ASCII-Adresse zu finden, beim ursprünglichen MUA oder eng damit verbundenen Systemen. Dies kann entweder vor dem Senden der Nachricht oder nach der Ablehnung der internationalisierten Form der Nachricht geschehen. Es ist auch der günstigste Zeitpunkt, um eine Nachricht von der internationalisierten Form in die konventionelle ASCII-Form umzuwandeln oder, falls eines von beidem erforderlich ist, eine Unzustellbarkeitsnachricht an den Absender zu generieren. Zu diesem Zeitpunkt hat der Benutzer eine vollständige Auswahl an Möglichkeiten, einschließlich der Änderung rückwärts gerichteter Adressen, der Out-of-Band-Kontaktaufnahme mit dem beabsichtigten Empfänger für eine alternative Adresse, der Konsultation geeigneter Verzeichnisse, der Veranlassung der Übersetzung sowohl von Adressen als auch von Nachrichteninhalten in eine andere Sprache und so weiter. Während es natürlich ist, sich das Nachrichten-Downgrading idealerweise als vollständig automatisierten Prozess vorzustellen, sollten wir die Fähigkeiten eines Benutzers von mindestens mäßiger Intelligenz, der mit einem anderen solchen Benutzer kommunizieren möchte, nicht unterschätzen.
In diesem Kontext kann man sich leicht Modifikationen an Nachrichten-Submission-Servern vorstellen (wie in RFC 6409 [RFC6409] beschrieben), sodass sie Downgrading-Operationen oder vielleicht sogar Upgrading-Operationen durchführen würden. Solche Operationen würden es ermöglichen, Nachrichten mit einer oder mehreren der hier diskutierten Internationalisierungserweiterungen zu empfangen und die ausgehende Nachricht nach Bedarf anzupassen, um auf die Zustell- oder Next-Hop-Umgebung zu reagieren, auf die der Submission-Server trifft.
8.2. Downgrading oder andere Verarbeitung nach der endgültigen SMTP-Zustellung
Wenn eine E-Mail-Nachricht von einem final delivery MTA empfangen wird, wird sie normalerweise in irgendeiner Form gespeichert. Dann wird sie entweder von Software abgerufen, die die gespeicherte Form direkt liest, oder von Client-Software über einige E-Mail-Abrufmechanismen wie POP oder IMAP.
Die in Abschnitt 7.1 beschriebene SMTP-Erweiterung bietet nur Schutz beim Transport. Sie verhindert nicht, dass MUAs und E-Mail-Abrufmechanismen, die nicht aufgerüstet wurden, um internationalisierte Adressen und UTF-8-Nachrichtenheader zu verstehen, auf gespeicherte internationalisierte E-Mails zugreifen.
Da der final delivery MTA (oder genauer gesagt sein entsprechender Mail-Storage-Agent) nicht sicher davon ausgehen kann, dass Agenten, die auf den E-Mail-Speicher zugreifen, immer in der Lage sein werden, die hier vorgeschlagenen Erweiterungen zu verarbeiten, kann er (MAY) internationalisierte E-Mails herabstufen, Nachrichten, die diese Erweiterungen nutzen, speziell kennzeichnen oder beides. Wenn eine oder beide dieser Aktionen ergriffen werden, sollte (SHOULD) der final delivery MTA einen Mechanismus enthalten, um die ursprünglichen internationalisierten Formen ohne Informationsverlust zu bewahren oder wiederherzustellen. Die Bewahrung dieser Informationen ist notwendig, um den Zugriff durch SMTPUTF8-fähige Agenten zu unterstützen.