10. Problemi di interfaccia utente e configurazione

L'internazionalizzazione degli indirizzi e delle intestazioni dei messaggi, specialmente in combinazione con le variazioni di codifica dei caratteri inerenti a Unicode, può rendere la scelta accurata degli indirizzi e la configurazione accurata dei server e dei record DNS ancora più importante di quanto non lo sia per la posta elettronica Internet tradizionale. È probabile che, man mano che si sviluppa l'esperienza con l'uso di questi protocolli, sarà opportuno produrre uno o più documenti aggiuntivi che offrano indicazioni per la configurazione e le interfacce. È prevista la realizzazione di un documento che discuta i problemi con i MUA, specialmente per quanto riguarda il downgrading. Le sottosezioni seguenti affrontano alcuni altri problemi.

10.1. Scelta dei nomi delle caselle postali e normalizzazione Unicode

Da lungo tempo la sintassi dell'email consente scelte sui nomi delle caselle postali che sono poco sagge nella pratica, se si intende realmente che le caselle postali siano accessibili a un'ampia gamma di mittenti. Gli esempi più spesso citati riguardano l'uso della distinzione tra maiuscole e minuscole e la quotatura insidiosa dei caratteri incorporati nelle parti locali delle caselle postali. Queste costruzioni deliberatamente inusuali sono consentite dai protocolli, e ci si aspetta che i server le supportino. Sebbene possano fornire valore in casi speciali, trarne vantaggio è quasi sempre una cattiva pratica, a meno che l'intento non sia creare una qualche forma di sicurezza tramite oscuramento.

In assenza di queste estensioni, i client e i server SMTP sono vincolati a usare solo gli indirizzi consentiti dall'RFC 5321. Le parti locali di tali indirizzi MAY essere composte da qualsiasi carattere ASCII eccetto i caratteri di controllo proibiti dall'RFC 5321, sebbene alcuni di essi MUST essere quotati come ivi specificato. È degno di nota, in un contesto di internazionalizzazione, che su alcuni sistemi esiste una lunga storia di uso di caratteri ASCII sovrapposti (un carattere, un backspace e un altro carattere) all'interno di una stringa quotata per approssimare caratteri non-ASCII. Questa forma di internazionalizzazione era consentita dall'RFC 821 [RFC0821] ma è proibita dall'RFC 5321, perché richiede un carattere di backspace (un controllo C0 proibito). Poiché l'RFC 5321 (e il suo predecessore, l'RFC 2821) proibiscono l'uso di questo carattere nei nomi di casella postale ASCII ed esso è ancora più problematico (per ragioni di canonicalizzazione e normalizzazione) nelle stringhe non-ASCII, il backspace MUST NOT apparire nei nomi di casella postale SMTPUTF8.

Per il caso particolare dei nomi di casella postale che contengono caratteri non-ASCII nella parte locale, nella parte del dominio, o in entrambe, MUST essere prestata particolare attenzione alla normalizzazione Unicode [Unicode-UAX15], in parte perché le stringhe Unicode possono essere normalizzate da altri processi indipendentemente da quanto specificato da un protocollo di posta (ciò è esattamente analogo a quanto può accadere con la quotatura e la dequotatura negli indirizzi tradizionali). Di conseguenza, i seguenti principi sono offerti come consigli a coloro che selezionano i nomi per le caselle postali:

• In generale, è saggio supportare gli indirizzi in forma normalizzata, usando almeno la Normalization Form NFC. Salvo nei casi in cui NFKC mapperebbe insieme caratteri che le parti responsabili del server di posta di destinazione preferirebbero mantenere distinguibili, supportare la forma conforme a NFKC produrrebbe un comportamento ancora più prevedibile per l'utente tipico.

• Di solito sarà saggio supportare altre forme della stessa stringa di parte locale, sia come alias sia mediante normalizzazione delle stringhe che giungono al server di consegna: non ci si dovrebbe affidare al mittente per l'invio delle stringhe in forma normalizzata.

• Detto in modo diverso e in termini più specifici, le regole del protocollo per le stringhe di parte locale stabiliscono essenzialmente che:

  • Le stringhe non normalizzate sono valide, ma costituiscono una pratica sufficientemente cattiva da poter non funzionare in modo affidabile su scala globale. I server non dovrebbero dipendere dai client per l'invio di forme normalizzate, ma dovrebbero essere consapevoli che procedure su macchine client al di fuori del controllo del MUA possono causare l'invio di stringhe normalizzate indipendentemente dall'intento dell'utente.

  • I controlli C0 (e presumibilmente C1) (si veda The Unicode Standard [Unicode]) sono proibiti, i primi nell'RFC 5321 e i secondi per ovvia estensione da esso [RFC5198].

  • Altre forme di punteggiatura, spazi, ecc. costituiscono una pratica rischiosa. Forse funzioneranno, e il codice del ricevitore SMTP è tenuto a gestirle senza errori gravi (anche se tali stringhe non sono accettate negli indirizzi da consegnare su quel server), ma creare dipendenze da esse nei nomi delle caselle postali scelti è di solito una cattiva pratica e può portare a problemi di interoperabilità.