3. Protocollo a livello di trasporto della posta

3.1. Quadro dell'estensione di internazionalizzazione

È definita la seguente estensione del servizio:

1. Il nome dell'estensione del servizio SMTP è "Internationalized Email".

2. Il valore della parola chiave EHLO associato a questa estensione è "SMTPUTF8".

3. Non sono definiti valori di parametro per questo valore della parola chiave EHLO. Al fine di consentire estensioni future (sebbene non previste), la risposta EHLO NON DEVE contenere alcun parametro per questa parola chiave. Il client SMTP compatibile con SMTPUTF8 DEVE ignorare qualsiasi parametro se appare per questa parola chiave; cioè, il client SMTP compatibile con SMTPUTF8 DEVE comportarsi come se i parametri non apparissero. Se un server SMTP include SMTPUTF8 nella sua risposta EHLO, DEVE essere pienamente conforme a questa versione di questa specifica.

4. Un parametro OPZIONALE, SMTPUTF8, viene aggiunto al comando MAIL. Il parametro non accetta un valore. Se questo parametro è impostato nel comando MAIL, indica che il client SMTP è compatibile con SMTPUTF8. La sua presenza afferma anche che la busta include l'indirizzo non ASCII, il messaggio inviato è un messaggio internazionalizzato o il messaggio inviato necessita del supporto SMTPUTF8.

5. La lunghezza massima di una riga di comando MAIL è aumentata di 10 caratteri per accogliere la possibile aggiunta del parametro SMTPUTF8.

6. Un parametro OPZIONALE, SMTPUTF8, viene aggiunto ai comandi VERIFY (VRFY) ed EXPAND (EXPN). Il parametro SMTPUTF8 non accetta un valore. Il parametro indica che il client SMTP può accettare caratteri Unicode nella codifica UTF-8 nelle risposte dai comandi VRFY ed EXPN.

7. Nessun verbo SMTP aggiuntivo è definito da questa estensione.

8. I server che offrono questa estensione DEVONO fornire supporto e annunciare l'estensione 8BITMIME [RFC6152].

9. Il percorso inverso e il percorso diretto dei comandi SMTP MAIL e RCPT sono estesi per consentire caratteri Unicode codificati in UTF-8 nei nomi delle caselle di posta (indirizzi).

10. Il corpo del messaggio di posta è esteso come specificato nella RFC 6532 [RFC6532].

11. L'estensione SMTPUTF8 è valida sulla porta di sottomissione [RFC6409]. Può anche essere utilizzata con il Local Mail Transfer Protocol (LMTP) [RFC2033]. Quando questi protocolli vengono utilizzati, il loro utilizzo dovrebbe riflettersi nelle parole chiave WITH del campo di traccia come appropriato [RFC3848].

3.2. L'estensione SMTPUTF8

Un server SMTP che annuncia l'estensione SMTPUTF8 DEVE essere preparato ad accettare una stringa UTF-8 [RFC3629] in qualsiasi posizione in cui la RFC 5321 specifica che può apparire una <mailbox>. Sebbene i caratteri nella <local-part> possano contenere caratteri non ASCII, l'effettiva analisi della <local-part> e i delimitatori utilizzati rimangono invariati rispetto alla specifica di base della posta elettronica [RFC5321]. Qualsiasi nome di dominio da cercare nel DNS DEVE essere conforme e processato come specificato per l'Internationalizing Domain Names in Applications (IDNA) [RFC5890]. Quando si effettuano ricerche, il client o server SMTP compatibile con SMTPUTF8 DEVE utilizzare una libreria DNS compatibile con Unicode o trasformare il nome di dominio internazionalizzato in forma A-label (cioè, un nome di dominio completamente qualificato che contiene una o più A-label ma nessuna U-label) come specificato nella RFC 5890 [RFC5890].

Un client SMTP che riceve la parola chiave di estensione SMTPUTF8 in risposta al comando EHLO PUÒ trasmettere nomi di caselle di posta all'interno dei comandi SMTP come stringhe internazionalizzate in forma UTF-8. PUÒ inviare un'intestazione UTF-8 [RFC6532] (che può includere anche nomi di caselle di posta in UTF-8). PUÒ trasmettere le parti di dominio dei nomi delle caselle di posta all'interno dei comandi SMTP o dell'intestazione del messaggio come A-label o U-label [RFC5890]. La presenza dell'estensione SMTPUTF8 non modifica i comportamenti di inoltro del server descritti nella RFC 5321.

Se l'estensione SMTP SMTPUTF8 non è offerta dal server SMTP, il client SMTP compatibile con SMTPUTF8 NON DEVE trasmettere un indirizzo email internazionalizzato e NON DEVE trasmettere un messaggio di posta contenente intestazioni di posta internazionalizzate come descritto nella RFC 6532 [RFC6532] a qualsiasi livello all'interno della sua struttura MIME [RFC2045]. (Per questo paragrafo, il nome di dominio internazionalizzato in forma A-label come specificato nelle definizioni IDNA [RFC5890] non è considerato "internazionalizzato".) Invece, se un client SMTP compatibile con SMTPUTF8 (mittente) tenta di trasferire un messaggio internazionalizzato e incontra un server SMTP che non supporta l'estensione, la migliore azione da intraprendere dipende da altre condizioni. In particolare:

• Se si tratta di un Message Submission Agent (MSA) [RFC6409] [RFC5598], PUÒ scegliere il proprio modo di affrontare questo scenario utilizzando l'ampia discrezione per modificare gli indirizzi o altrimenti sistemare e trasformare i messaggi consentita dalla RFC 6409. Finché il messaggio risultante è conforme ai requisiti della RFC 5321 (cioè, senza l'estensione SMTPUTF8), i dettagli di tale trasformazione esulano dallo scopo di questo documento.

• Se non è un MSA o è un MSA e non sceglie di trasformare il messaggio in uno che non richiede l'estensione SMTPUTF8, DOVREBBE rifiutare il messaggio. Come al solito, ciò può essere fatto generando una risposta appropriata durante la transazione SMTP o accettando il messaggio e quindi generando e trasmettendo una notifica di mancata consegna. Se viene fatta quest'ultima scelta, il processo di notifica DEVE essere conforme ai requisiti della RFC 5321, RFC 3464 [RFC3464] e RFC 6533 [RFC6533].

• Come specificato nella Sezione 2.2.3 della RFC 5321, un client SMTP con informazioni aggiuntive e/o conoscenza di circostanze speciali PUÒ scegliere di rimettere in coda il messaggio e riprovare più tardi e/o provare un host MX alternativo come specificato in quella sezione.

Questo documento si applica quando un client o server SMTP compatibile con SMTPUTF8 supporta l'estensione SMTPUTF8. Per tutti gli altri casi, e per indirizzi e messaggi che non richiedono un'estensione SMTPUTF8, i client e server SMTP compatibili con SMTPUTF8 non modificano il comportamento specificato nella RFC 5321 [RFC5321].

Se un server SMTP compatibile con SMTPUTF8 pubblicizza l'estensione Delivery Status Notification (DSN) [RFC3461], DEVE implementare la RFC 6533 [RFC6533].

3.3. Sintassi estesa degli indirizzi delle caselle di posta

La RFC 5321, Sezione 4.1.2, definisce la sintassi di una <Mailbox> interamente in termini di caratteri ASCII. Questo documento estende <Mailbox> per aggiungere il supporto di caratteri non ASCII.

Le principali modifiche apportate da questa specifica includono:

• La regola ABNF <Mailbox> è importata dalla RFC 5321 e aggiornata per supportare l'indirizzo email internazionalizzato. Altre regole correlate sono importate dalla RFC 5321, RFC 5234, RFC 5890 e RFC 6532 o sono estese in questo documento.

• La definizione di <sub-domain> è estesa per consentire sia la definizione della RFC 5321 che una stringa UTF-8 in un'etichetta DNS conforme alle definizioni IDNA [RFC5890].

• La definizione di <atext> è estesa per consentire sia la definizione della RFC 5321 che una stringa UTF-8. Tale stringa NON DEVE contenere alcuno dei caratteri grafici o di controllo ASCII.

Le seguenti regole ABNF importate dalla RFC 5321, Sezione 4.1.2, sono aggiornate direttamente o indirettamente da questo documento:

• <Mailbox>
• <Local-part>
• <Dot-string>
• <Quoted-string>
• <QcontentSMTP>
• <Domain>
• <Atom>

La seguente regola ABNF sarà importata direttamente dalla RFC 6532, Sezione 3.1:

• <UTF8-non-ascii>

La seguente regola ABNF sarà importata direttamente dalla RFC 5234, Appendice B.1:

• <DQUOTE>

La seguente regola ABNF sarà importata direttamente dalla RFC 5890, Sezione 2.3.2.1:

• <U-label>

Le seguenti regole sono estese in ABNF [RFC5234] come segue.

sub-domain   =/  U-label
 ; extend the definition of sub-domain in RFC 5321, Section 4.1.2

atext   =/  UTF8-non-ascii
 ; extend the implicit definition of atext in
 ; RFC 5321, Section 4.1.2, which ultimately points to
 ; the actual definition in RFC 5322, Section 3.2.3

qtextSMTP  =/ UTF8-non-ascii
 ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2

esmtp-value  =/ UTF8-non-ascii
 ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2

3.4. Uso dei parametri del comando MAIL

Se la busta o il messaggio inviato richiede le funzionalità dell'estensione SMTPUTF8, il client SMTP compatibile con SMTPUTF8 DEVE fornire il parametro SMTPUTF8 con il comando MAIL. Se questo parametro viene fornito, NON DEVE accettare un valore. Se il client SMTP compatibile con SMTPUTF8 è consapevole che né la busta né il messaggio inviato richiedono alcuna delle funzionalità dell'estensione SMTPUTF8, NON DOVREBBE fornire il parametro SMTPUTF8 con il comando MAIL.

Poiché non vi è alcuna garanzia che un server SMTP del salto successivo supporti l'estensione SMTPUTF8, l'uso dell'estensione SMTPUTF8 comporta sempre un rischio di fallimento della trasmissione. Infatti, durante le prime fasi di implementazione dell'estensione SMTPUTF8, il rischio sarà piuttosto elevato. Pertanto, vi è un netto vantaggio a breve termine per i messaggi solo ASCII nell'essere inviati senza utilizzare questa estensione. Il vantaggio a lungo termine della conversione dei caratteri ASCII [ASCII] (0x7f e inferiori) in forma UTF-8 è che consente ambienti puramente Unicode.

3.5. Indirizzi non ASCII e codici di risposta

Un client SMTP compatibile con SMTPUTF8 NON DEVE inviare un messaggio internazionalizzato a un server SMTP che non supporta SMTPUTF8. Se il server SMTP non supporta questa opzione, il client SMTP compatibile con SMTPUTF8 ha tre scelte secondo la Sezione 3.2 di questa specifica.

I codici di risposta a tre cifre utilizzati in questa sezione si basano sui loro significati come definiti nella RFC 5321.

Quando i messaggi vengono rifiutati perché il comando RCPT richiede un indirizzo ASCII, viene restituito il codice di risposta 553 con il significato "nome casella di posta non consentito". Quando i messaggi vengono rifiutati perché il comando MAIL richiede un indirizzo ASCII, viene restituito il codice di risposta 550 con il significato "casella di posta non disponibile". Quando il server SMTP compatibile con SMTPUTF8 supporta i codici di stato avanzati del sistema di posta [RFC3463], viene utilizzato il codice di risposta "X.6.7" [RFC5248] (vedere Sezione 4), che significa "Indirizzi non ASCII non consentiti per quel mittente/destinatario".

Quando i messaggi vengono rifiutati per altri motivi, il server segue il modello della specifica di base della posta elettronica nella RFC 5321; questa estensione non modifica tali circostanze o messaggi di risposta.

Se un messaggio viene rifiutato dopo il "." finale del comando DATA perché uno o più destinatari non sono in grado di accettare ed elaborare un messaggio con intestazioni email internazionalizzate, viene utilizzato il codice di risposta "554" con il significato "Transazione fallita". Se il server SMTP compatibile con SMTPUTF8 supporta i codici di stato avanzati del sistema di posta [RFC3463], viene utilizzato il codice di risposta "X.6.9" [RFC5248] (vedere Sezione 4) per indicare questa condizione, che significa "Il messaggio con intestazione UTF-8 non può essere trasmesso a uno o più destinatari, quindi il messaggio deve essere rifiutato".

I server SMTP compatibili con SMTPUTF8 sono incoraggiati a rilevare che i destinatari non possono accettare messaggi internazionalizzati e generare un errore dopo il comando RCPT piuttosto che attendere fino a dopo il comando DATA per emettere un errore.

3.6. Parti del corpo ed estensioni SMTP

Il parametro del comando MAIL SMTPUTF8 afferma che un messaggio è un messaggio internazionalizzato o che il messaggio inviato necessita del supporto SMTPUTF8. C'è ancora una possibilità che un messaggio inviato tramite il comando MAIL con il parametro SMTPUTF8 non sia un messaggio internazionalizzato. Un client o server SMTP compatibile con SMTPUTF8 che richiede una conoscenza accurata del fatto che un messaggio sia internazionalizzato deve analizzare tutti i campi dell'intestazione del messaggio e i campi dell'intestazione MIME [RFC2045] nel corpo del messaggio. Tuttavia, questa specifica non richiede che il client o server SMTP compatibile con SMTPUTF8 ispezioni il messaggio.

Sebbene questa specifica richieda che i server SMTP compatibili con SMTPUTF8 supportino l'estensione 8BITMIME [RFC6152] per garantire che i server abbiano un'adeguata capacità di gestione per i dati a 8 bit, non richiede parti del corpo non ASCII nel messaggio MIME come specificato nella RFC 2045. L'estensione SMTPUTF8 PUÒ essere utilizzata come segue (assumendo che sia appropriato dato il contenuto del corpo):

• con il parametro BODY=8BITMIME [RFC6152], o

• con il parametro BODY=BINARYMIME, se il server SMTP pubblicizza BINARYMIME [RFC3030].

3.7. Ulteriori modifiche e chiarimenti ESMTP

Le informazioni trasportate nel processo di trasporto della posta coinvolgono indirizzi ("caselle di posta") e nomi di dominio in vari contesti oltre ai comandi MAIL e RCPT e alle loro alternative estese. In generale, la regola è che, quando la RFC 5321 specifica una casella di posta, questa estensione SMTP richiede che venga utilizzata la forma UTF-8 per l'intera stringa. Quando la RFC 5321 specifica un nome di dominio, il nome di dominio internazionalizzato DOVREBBE essere in forma U-label se l'estensione SMTPUTF8 è supportata; altrimenti, DOVREBBE essere in forma A-label.

Le seguenti sottosezioni elencano e discutono tutti i casi rilevanti.

3.7.1. Lo scambio SMTP iniziale

Quando viene aperta una connessione SMTP, il server SMTP invia una risposta di "saluto" composta dal codice di risposta 220 e alcune informazioni. Il client SMTP invia quindi il comando EHLO. Poiché il client SMTP non può sapere se il server SMTP supporta SMTPUTF8 fino a dopo aver ricevuto la risposta all'EHLO, il client SMTP compatibile con SMTPUTF8 DEVE inviare solo domini ASCII (etichetta LDH o A-label [RFC5890]) nel comando EHLO. Se il server SMTP compatibile con SMTPUTF8 fornisce nomi di dominio nella risposta EHLO, DEVONO essere sotto forma di etichette LDH o A-label.

3.7.2. Mail eXchanger (MX)

Se vengono utilizzati più record MX DNS per specificare più server per un dominio (come descritto nella Sezione 5 della RFC 5321 [RFC5321]), si consiglia vivamente che tutti o nessuno di essi SUPPORTI l'estensione SMTPUTF8. Altrimenti, possono verificarsi rifiuti imprevisti durante guasti temporanei o permanenti, che gli utenti potrebbero percepire come seri problemi di affidabilità.

3.7.3. Informazioni di traccia

Le informazioni di traccia <Return-path-line>, <Time-stamp-line> e le relative regole sono definite nella Sezione 4.4 della RFC 5321 [RFC5321]. Questo documento aggiorna <Mailbox> e <Domain> per supportare i caratteri non ASCII. Quando viene utilizzata l'estensione SMTPUTF8, la clausola 'Reverse-path' della Return-path-line può includere un nome di dominio internazionalizzato che utilizza la forma U-label. Inoltre, la clausola 'Stamp' della Time-stamp-line può includere un nome di dominio internazionalizzato che utilizza la forma U-label.

Se i messaggi che includono campi di traccia vengono inviati da un client o server di inoltro SMTP compatibile con SMTPUTF8 senza il parametro SMTPUTF8 incluso nei comandi MAIL, i valori dei campi di traccia devono essere conformi alla RFC 5321 indipendentemente dalla capacità del server SMTP.

Quando un server SMTP compatibile con SMTPUTF8 aggiunge un campo di traccia a un messaggio che è stato o sarà trasmesso con il parametro SMTPUTF8 incluso nei comandi MAIL, quel server DOVREBBE utilizzare la forma U-label per i nomi di dominio internazionalizzati nel nuovo campo di traccia.

Il valore del protocollo della clausola 'WITH' quando viene utilizzata questa estensione è uno dei valori SMTPUTF8 specificati nella sezione "Considerazioni IANA" di questo documento.

3.7.4. Stringhe UTF-8 nelle risposte

3.7.4.1. Comando MAIL

Se un client SMTP segue questa specifica e invia comandi MAIL contenenti il parametro SMTPUTF8, il server SMTP compatibile con SMTPUTF8 è autorizzato a utilizzare caratteri UTF-8 nell'indirizzo email associato ai codici di risposta 251 e 551, e il client SMTP DEVE essere in grado di accettarli ed elaborarli. Se un determinato comando MAIL non include il parametro SMTPUTF8, il server SMTP compatibile con SMTPUTF8 NON DEVE restituire una risposta 251 o 551 contenente una casella di posta non ASCII. Invece, DEVE trasformare tali risposte in risposte 250 o 550 che non contengono indirizzi non ASCII.

3.7.4.2. Comandi VRFY ed EXPN e parametro SMTPUTF8

Se il parametro SMTPUTF8 viene trasmesso con i comandi VRFY ed EXPN, indica che il client SMTP può accettare stringhe UTF-8 nelle risposte a tali comandi. Il parametro con i comandi VRFY ed EXPN DOVREBBE essere utilizzato solo dopo che il client SMTP ha visto la risposta EHLO con la parola chiave SMTPUTF8. Ciò consente a un server SMTP compatibile con SMTPUTF8 di utilizzare stringhe UTF-8 nei nomi delle caselle di posta e nei nomi completi che appaiono nelle risposte, senza preoccuparsi che il client SMTP possa essere confuso da esse. Un client SMTP conforme a questa specifica DEVE accettare ed elaborare correttamente le risposte ai comandi VRFY ed EXPN che contengono stringhe UTF-8. Tuttavia, un server SMTP compatibile con SMTPUTF8 NON DEVE utilizzare stringhe UTF-8 nelle risposte se il client SMTP non consente specificamente tali risposte trasmettendo questo parametro con i comandi VRFY ed EXPN.

La maggior parte delle risposte non richiede che un nome di casella di posta sia incluso nel testo restituito e pertanto non è necessaria una stringa UTF-8 in esse. Alcune risposte, in particolare quelle risultanti dall'esecuzione riuscita dei comandi VRFY ed EXPN, includono la casella di posta.

Le sintassi dei comandi VERIFY (VRFY) ed EXPAND (EXPN) sono modificate in:

vrfy = "VRFY" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

expn = "EXPN" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

Il parametro SMTPUTF8 non accetta un valore. Se la risposta a un comando VRFY o EXPN richiede una stringa UTF-8, ma il client SMTP non ha utilizzato il parametro SMTPUTF8, il server SMTP compatibile con SMTPUTF8 DEVE utilizzare il codice di risposta 252 o 550. Il codice di risposta 252, definito nella RFC 5321 [RFC5321], significa "Impossibile verificare l'utente, ma accetterà il messaggio e tenterà la consegna". Il codice di risposta 550, anch'esso definito nella RFC 5321 [RFC5321], significa "Azione richiesta non intrapresa: casella di posta non disponibile". Quando il server SMTP compatibile con SMTPUTF8 supporta i codici di stato avanzati del sistema di posta [RFC3463], viene utilizzato il codice di risposta avanzato come specificato di seguito. L'utilizzo del parametro SMTPUTF8 con un comando VRFY o EXPN abilita le risposte UTF-8 solo per quel comando.

Se viene restituita una normale risposta di successo (cioè 250), la risposta PUÒ includere il nome completo dell'utente e DEVE includere la casella di posta dell'utente. DEVE essere in una delle seguenti forme:

User Name <Mailbox>
 ; Mailbox is defined in Section 3.3 of this document.
 ; User Name can contain non-ASCII characters.

Mailbox
 ; Mailbox is defined in Section 3.3 of this document.

Se la risposta SMTP richiede stringhe UTF-8, ma una stringa UTF-8 non è consentita nella risposta e il server SMTP compatibile con SMTPUTF8 supporta i codici di stato avanzati del sistema di posta [RFC3463], il codice di risposta avanzato è "X.6.8" [RFC5248] (vedere Sezione 4), che significa "È richiesta una risposta contenente una stringa UTF-8 per mostrare il nome della casella di posta, ma quella forma di risposta non è consentita dal client SMTP".

Se il client SMTP non supporta l'estensione SMTPUTF8, ma riceve una stringa UTF-8 in una risposta, potrebbe non essere in grado di segnalare correttamente la risposta all'utente e alcuni client potrebbero gestire in modo errato tale risposta. I messaggi internazionalizzati nelle risposte sono consentiti nei comandi solo nelle situazioni descritte sopra.

Sebbene le stringhe UTF-8 siano necessarie per rappresentare gli indirizzi email nelle risposte secondo le regole specificate in questa sezione, questa estensione non consente l'uso di stringhe UTF-8 per altri scopi. I server SMTP compatibili con SMTPUTF8 NON DEVONO includere caratteri non ASCII nelle risposte, tranne nei casi limitati specificamente consentiti in questa sezione.