Passa al contenuto principale

7. Panoramica delle estensioni e modifiche di protocollo

7.1. Estensione SMTP per gli indirizzi email internazionalizzati​

Un'estensione SMTP, "SMTPUTF8", è specificata come segue:

  • Consente l'uso di stringhe UTF-8 negli indirizzi email, sia nelle parti locali sia nei nomi di dominio.

  • Consente l'uso selettivo di stringhe UTF-8 nelle intestazioni dei messaggi email (si veda la Sezione 7.2).

  • Richiede che il server annunci l'estensione 8BITMIME [RFC6152] e che il client supporti la trasmissione a 8 bit, affinché le informazioni di intestazione possano essere trasmesse senza utilizzare un content-transfer-encoding speciale.

Alcuni principi generali influenzano le decisioni di sviluppo alla base di questo lavoro.

  1. Gli indirizzi email entrano in sottosistemi (come un'interfaccia utente) che possono eseguire conversioni di set di caratteri o altre modifiche di codifica. Quando la parte locale dell'indirizzo include caratteri al di fuori del repertorio di caratteri ASCII, l'uso della codifica compatibile con ASCII (ACE) [RFC3492] [RFC5890] nella parte del dominio è sconsigliato, per promuovere un'elaborazione coerente dei caratteri in tutto l'indirizzo.

  2. Un relay SMTP MUST

    • O riconoscere esplicitamente il formato, accettando di farlo tramite un'opzione ESMTP, oppure
    • Rifiutare il messaggio o, se necessario, restituire un messaggio di notifica di mancato recapito, affinché il mittente possa predisporre un altro piano.

  3. Se il messaggio non può essere inoltrato perché il sistema di next-hop non può accettare l'estensione, esso MUST essere rifiutato oppure MUST essere generato e inviato un messaggio di mancato recapito.

  4. Nell'interesse dell'interoperabilità, i set di caratteri diversi da UTF-8 sono proibiti negli indirizzi di posta e nelle intestazioni dei messaggi trasmessi su Internet. Non esiste un modo pratico per identificare correttamente più set di caratteri con un'estensione simile a questa senza introdurre grande complessità.

La conformità al gruppo di standard qui specificato per il trasporto e la consegna dell'email richiede l'implementazione della specifica dell'estensione SMTP e della specifica delle intestazioni UTF-8. Se il sistema implementa IMAP o POP, esso MUST essere conforme rispettivamente alle specifiche IMAP [RFC5738bis-IMAP] o POP [RFC5721bis-POP3] internazionalizzate.

7.2. Trasmissione dei campi di intestazione email in codifica UTF-8​

Vi sono molti punti nei MUA o nella presentazione all'utente in cui compaiono indirizzi email o nomi di dominio. Esempi includono i campi di intestazione convenzionali "From:", "To:" o "Cc:"; i campi di intestazione "Message-ID:" e "In-Reply-To:" che normalmente contengono nomi di dominio (ma che possono costituire un caso speciale); e i corpi dei messaggi. Ciascuno di questi deve essere esaminato dal punto di vista dell'internazionalizzazione. L'utente si aspetterà di vedere nomi di caselle postali e di dominio in caratteri locali, e di vederli in modo coerente. Se vengono usate codifiche non ovvie, come varianti ACE specifiche di protocollo, l'utente inevitabilmente, anche se solo occasionalmente, le vedrà invece dei caratteri "nativi" e le troverà sconcertanti o sorprendenti. Analogamente, se per il trasporto della posta e per i corpi dei messaggi vengono usate codifiche diverse, l'utente è particolarmente probabile che rimanga sorpreso, fosse anche solo in conseguenza del principio, da lungo tempo consolidato, che "le cose trapelano". L'unico modo pratico per evitare queste fonti di disagio, sia nel medio sia nel lungo termine, è fare in modo che le codifiche usate nel trasporto siano il più possibile simili a quelle usate nelle intestazioni e nei corpi dei messaggi.

Quando le parti locali degli indirizzi email sono internazionalizzate, esse SHOULD essere accompagnate da disposizioni affinché le intestazioni dei messaggi siano nella forma completamente internazionalizzata. Tale forma SHOULD usare UTF-8 anziché ASCII come set di caratteri di base per il contenuto dei campi di intestazione (gli elementi di protocollo come i nomi stessi dei campi di intestazione sono invariati e rimangono interamente in ASCII). Ai fini della transizione e della compatibilità con i sistemi legacy, ciò può essere fatto estendendo i modelli tradizionali di codifica MIME per i caratteri non-ASCII nelle intestazioni [RFC2045] [RFC2231], ma anche questi dovrebbero essere basati su UTF-8, anziché su altre codifiche, se possibile [RFC6055]. Tuttavia, l'obiettivo sono intestazioni di messaggio completamente internazionalizzate, come discusso in [RFC6532], e non una transizione estesa e dolorosa.

7.3. Estensione del servizio SMTP per i DSN​

La specifica esistente delle Delivery Status Notification (DSN) [RFC3461], che è un Draft Standard, è limitata al testo ASCII nelle parti leggibili dalla macchina del protocollo. "International Delivery and Disposition Notifications" [RFC6533] aggiunge un nuovo tipo di indirizzo per gli indirizzi email internazionali, così che un indirizzo di destinatario originale con caratteri non-ASCII possa essere preservato correttamente anche dopo il downgrading. Se un server SMTP annuncia sia l'estensione SMTPUTF8 sia l'estensione DSN, quel server MUST implementare DSN internazionalizzati, incluso il supporto per il parametro ORCPT specificato nell'RFC 3461 [RFC3461].