8. Downgrading prima e dopo le transazioni SMTP
Un problema importante con queste estensioni è come gestire le interazioni tra sistemi che supportano indirizzi non-ASCII e sistemi legacy che si aspettano ASCII. Non vi è, naturalmente, alcun problema con i sistemi solo-ASCII che inviano a quelli in grado di gestire forme internazionalizzate, poiché le forme ASCII sono semplicemente un sottoinsieme proprio. Ma, quando i sistemi che supportano queste estensioni inviano posta, essi MAY includere indirizzi non-ASCII per i mittenti, i destinatari, o entrambi, e potrebbero anche fornire informazioni di intestazione non-ASCII diverse dagli indirizzi. Se l'estensione non è supportata dal sistema di first-hop (ossia il server SMTP a cui accede il server di sottomissione che agisce come client SMTP), i sistemi che originano i messaggi SHOULD essere preparati o a inviare buste e intestazioni di messaggio convenzionali, oppure a restituire il messaggio all'utente di origine, affinché il messaggio possa essere sottoposto manualmente a downgrading nella forma tradizionale, eventualmente utilizzando encoded word [RFC2047] nelle intestazioni del messaggio. Naturalmente, tali trasformazioni implicano che l'utente o il sistema di origine debba disporre di indirizzi solo-ASCII per tutti i mittenti e i destinatari. I meccanismi mediante i quali tali indirizzi possono essere trovati o identificati sono al di fuori dell'ambito di queste specifiche, come lo sono le decisioni sulla progettazione dei sistemi di origine, quale ad esempio se le eventuali trasformazioni richieste siano effettuate dall'utente, dal MUA di origine o dal server di sottomissione.
Una situazione un po' più complessa si presenta quando il sistema di first-hop supporta queste estensioni ma qualche server successivo nella catena di trasmissione SMTP no. È importante notare che la maggior parte dei casi di tale situazione con indirizzi forward-pointing sarà il risultato di errori di configurazione: in particolare, se ospita indirizzi non-ASCII, un final delivery MTA che accetta queste estensioni SHOULD NOT essere configurato con host MX a preferenza inferiore che non le accettano. Quando l'unico indirizzo non-ASCII trasmesso è backward-pointing (ad esempio, in un comando SMTP MAIL), la configurazione del destinatario non può in genere essere d'aiuto. D'altro canto, gli indirizzi alternativi solo-ASCII per i mittenti sono quelli che più probabilmente sono noti in modo autorevole all'ambiente di sottomissione o al mittente stesso. Di conseguenza, se un relay SMTP intermedio che richiede queste estensioni scopre poi che il sistema successivo nella catena non le supporta, avrà poca scelta se non quella di rifiutare o restituire il messaggio.
Come discusso sopra, il downgrading verso una forma solo-ASCII può avvenire prima o durante la sottomissione iniziale del messaggio. Può anche avvenire dopo la consegna al final delivery MTA, al fine di adattarsi ad archivi messaggi, server IMAP o POP, o client che hanno capacità diverse da quelle del MTA di consegna. Questi casi sono discussi nelle sottosezioni seguenti.
8.1. Downgrading prima o durante la sottomissione del messaggio
L'IETF ha tradizionalmente evitato di specificare il comportamento preciso dei MUA, per fornire la massima flessibilità nelle relative interfacce utente. Lo standard SMTP [RFC5321], Sezione 6.4, concede ampia libertà ai MUA e ai server di sottomissione riguardo a ciò che può essere fornito dall'utente, purché il risultato sia conforme agli standard "on the wire" una volta immesso nella Internet pubblica. In quella tradizione, la discussione nel resto della Sezione 8 è fornita come guida generale anziché come requisiti normativi.
I messaggi che richiedono queste estensioni saranno talvolta trasferiti a un sistema che non supporta queste estensioni; è probabile che i casi più comuni comportino la combinazione di indirizzi forward-pointing solo-ASCII con un indirizzo backward-pointing non-ASCII. Finché le estensioni qui descritte non saranno state implementate universalmente nell'ambiente della posta elettronica Internet, i mittenti che preferiscono usare indirizzi non-ASCII (o caratteri UTF-8 grezzi nei campi di intestazione), anche quando i destinatari previsti usano e si aspettano indirizzi all-ASCII, dovranno prestare particolare attenzione alle condizioni di errore che possono verificarsi. I rischi sono particolarmente elevati in ambienti in cui i messaggi di mancato recapito (o altre indicazioni provenienti dai server di sottomissione) vengono sistematicamente scartati o ignorati.
Come forse è ovvio, il momento più comodo per trovare un indirizzo ASCII corrispondente a un indirizzo internazionalizzato è presso il MUA di origine o sistemi strettamente associati. Ciò può avvenire sia prima dell'invio del messaggio sia dopo il rifiuto della forma internazionalizzata del messaggio. È anche il momento più comodo per convertire un messaggio dalla forma internazionalizzata alla forma ASCII convenzionale, oppure per generare un messaggio di mancato recapito al mittente, se necessario. A quel punto, l'utente ha a disposizione una gamma completa di scelte, tra cui cambiare gli indirizzi backward-pointing, contattare il destinatario previsto fuori banda per un indirizzo alternativo, consultare directory appropriate, organizzare la traduzione sia degli indirizzi sia del contenuto del messaggio in una lingua diversa, e così via. Sebbene sia naturale pensare al downgrading dei messaggi come a un processo ottimale completamente automatizzato, non dovremmo sottovalutare le capacità di un utente di almeno moderata intelligenza che desideri comunicare con un altro utente altrettanto capace.
In questo contesto, si possono facilmente immaginare modifiche ai server di sottomissione dei messaggi (come descritto nell'RFC 6409 [RFC6409]) affinché eseguano operazioni di downgrading o persino di upgrading. Tali operazioni consentirebbero di ricevere messaggi con una o più delle estensioni di internazionalizzazione qui discusse e di adattare il messaggio in uscita, secondo necessità, per rispondere all'ambiente di consegna o di next-hop che il server di sottomissione incontra.
8.2. Downgrading o altra elaborazione dopo la consegna SMTP finale
Quando un messaggio email viene ricevuto da un final delivery MTA, di solito viene memorizzato in qualche forma. Poi viene recuperato o da software che legge direttamente la forma memorizzata, oppure da software client tramite alcuni meccanismi di recupero della posta come POP o IMAP.
L'estensione SMTP descritta nella Sezione 7.1 fornisce protezione solo nel trasporto. Non impedisce ai MUA e ai meccanismi di recupero della posta che non sono stati aggiornati per comprendere gli indirizzi internazionalizzati e le intestazioni di messaggio UTF-8 di accedere alle email internazionalizzate memorizzate.
Poiché il final delivery MTA (o, per essere più precisi, il suo corrispondente agente di archiviazione della posta) non può assumere con sicurezza che gli agenti che accedono all'archivio email siano sempre in grado di gestire le estensioni qui proposte, esso MAY sottoporre a downgrading le email internazionalizzate, identificare in modo speciale i messaggi che utilizzano queste estensioni, o entrambe le cose. Se una o entrambe di queste azioni fossero intraprese, il final delivery MTA SHOULD includere un meccanismo per preservare o recuperare le forme internazionalizzate originali senza perdita di informazioni. La conservazione di tali informazioni è necessaria per supportare l'accesso da parte di agenti consapevoli di SMTPUTF8.