Formato indirizzo email: regole di sintassi e limiti reali

Il formato indirizzo email è una delle poche cose che ogni sviluppatore crede di conoscere già, e una delle poche in cui la convinzione è di solito più stretta dello standard e più ampia di ciò che i servizi accettano. Le regole sono brevi: un indirizzo si divide in due attorno alla chiocciola, e ciascuna metà ha un limite di lunghezza espresso in byte. Le complicazioni arrivano da ogni altra parte — dalle parti locali tra virgolette, dai caratteri internazionali e dal divario tra ciò che una specifica permette e ciò che un servizio reale accetta.

Le due metà attorno alla chiocciola

Un indirizzo ha una parte locale a sinistra della chiocciola e un dominio a destra. La parte locale è affare del sistema ricevente: dentro il suo dominio, può interpretare quell’etichetta come preferisce, ed è per questo che due servizi possono trattare la stessa etichetta in modi completamente diversi.

Il dominio è la parte che il sistema di posta più ampio deve poter trovare, ed è per questo che è governato dalle regole dei domini anziché da quelle della posta. Quando un messaggio viene inviato, il lato mittente cerca il dominio per trovare il server che accetta posta per esso, e il messaggio viene poi offerto a quel server. Senza un record di dominio che nomini un server ricevente, non c’è un posto dove il messaggio possa andare.

Questa divisione è anche il punto da cui parte il consiglio pratico: valida il dominio in modo severo, perché sbagliarlo significa posta che non potrà mai essere consegnata, e sii indulgente con la parte locale, perché essere severi lì rifiuta solo indirizzi che avrebbero funzionato.

Quanto può essere lungo un indirizzo?

Lo standard pubblico pone limiti su entrambe le metà e sul totale. Questi sono conteggi di byte, non di caratteri, il che conta nel momento in cui sono coinvolti caratteri non ASCII.

Una convenzione ingegneristica ben nota è persino più stretta: molti servizi limitano l’indirizzo intero a circa 254 caratteri, perché quella cifra torna bene quando si tiene conto della sintassi attorno a un indirizzo. Quella convenzione non è lo standard, e trattarla come tale è il modo in cui una colonna di database finisce un carattere troppo corta per un indirizzo legittimo.

La lezione per chi progetta un modulo o una tabella è dimensionare i campi secondo lo standard e memorizzare i byte che hai effettivamente ricevuto. Troncare un indirizzo in silenzio è peggio che rifiutarlo, perché l’account che viene creato non potrà mai ricevere nulla.

Ciò che lo standard permette ma la maggior parte dei servizi rifiuta

La sintassi è molto più permissiva della posta che la maggior parte delle persone riceve. Tra le forme che lo standard consente ci sono una parte locale scritta tra virgolette, commenti tra parentesi, un dominio scritto come indirizzo tra parentesi quadre anziché come nome e — in base alle estensioni di internazionalizzazione — caratteri non ASCII in entrambe le metà.

Molto pochi servizi accettano tutto ciò. Molti rifiutano senz’altro le parti locali tra virgolette, quasi tutti ignorano i commenti, e il supporto per un dominio tra parentesi quadre è raro. Gli indirizzi non ASCII esistono e funzionano in alcuni ambienti, ma quasi ogni servizio consumer si comporta come se la forma ASCII fosse l’unica.

La conclusione da portare nel tuo codice è precisa: un controllo di sintassi non è un’affermazione sul mondo. Superarlo significa che l’indirizzo è ben formato. Non significa che un servizio qualsiasi lo accetterà, e non significa che l’account dietro di esso esista.

Perché un indirizzo valido viene comunque rifiutato?

Tre ragioni, nessuna delle quali riguarda la sintassi.

La prima è che il dominio potrebbe non accettare affatto posta. Un indirizzo sintatticamente perfetto su un dominio senza server ricevente, o che rifiuta tutta la posta, è non recapitabile. Questo è esattamente il caso che una casella usa e getta è costruita per aggirare: lo strumento di posta temporanea ti dà un indirizzo su un dominio che sta accettando posta proprio ora, quindi il percorso di consegna è la parte che non devi predisporre.

La seconda è una regola specifica del servizio. Un prodotto può limitare quali domini accetta, o quali caratteri consente in un nome utente, per ragioni che non hanno nulla a che fare con lo standard. Quelle restrizioni sono politica, e dovrebbero essere descritte come politica anziché camuffate da validazione.

La terza è la gestione di maiuscole e spazi. La metà del dominio è insensibile alle maiuscole; la parte locale è tecnicamente sensibile, anche se in pratica quasi nulla distingue le maiuscole lì. Uno spazio iniziale o finale incollato da un documento è una causa comune di un rifiuto che sembra un errore di sintassi, e vale la pena eliminarlo prima di validare anziché dopo.

Creare indirizzi che i servizi accettano

Quando ti serve un indirizzo che un prodotto qualsiasi accetterà senza obiezioni, la forma più sicura è quella noiosa: lettere e cifre ordinarie prima della chiocciola, un dominio convenzionale dopo di essa, nessuna virgoletta, nessun commento, nessun dominio tra parentesi quadre, nessuna punteggiatura esotica. Quella forma supera essenzialmente ogni validatore in uso.

La pagina della posta temporanea produce indirizzi esattamente di quel tipo, e puoi scegliere tu stesso un prefisso quando un modulo rifiuta etichette troppo corte o che sembrano generate automaticamente. Poiché l’indirizzo viene creato per te anziché registrato, la posta che arriva appartiene alla commissione che hai avviato, e la casella può essere abbandonata dopo. Se stai scegliendo tra questo e una disposizione più longeva, posta temporanea o alias espone la differenza.

Tutto ciò che è discusso qui descrive la forma di un indirizzo, non una persona. Nessun indirizzo di alcun tipo dovrebbe essere trattato come identità reale, e uno sintatticamente corretto non ti dice nulla su chi, se qualcuno, ci sia dietro.

Per gli sviluppatori: validazione, larghezza dei campi e maiuscole

Tre abitudini prevengono la maggior parte dei difetti nella gestione degli indirizzi.

Rendi la validazione permissiva e a strati. Controlla che ci sia esattamente una chiocciola fuori dalle virgolette, che entrambe le metà non siano vuote e che il dominio abbia la struttura che un dominio deve avere. Resisti alla tentazione di rifiutare qualsiasi altra cosa, perché le forme esotiche che rifiuti potrebbero essere esattamente gli indirizzi che ti è stato chiesto di accettare. Se un servizio con cui ti stai integrando ha regole più strette, applica quelle regole al confine dell’integrazione e dillo nel messaggio di errore.

Dimensiona l’archiviazione secondo lo standard. Dai alla parte locale spazio sufficiente per 64 byte, al dominio abbastanza per 255 e all’intero campo abbastanza per 256, punteggiatura inclusa. Testa il confine di proposito con una parte locale lunga, perché l’input troppo lungo è il caso che tronca in silenzio.

Normalizza di proposito, e documenta ciò che normalizzi. Eliminare gli spazi e convertire il dominio in minuscolo sono operazioni sicure e attese. Convertire la parte locale in minuscolo è comune ma tecnicamente una modifica all’indirizzo, quindi rendila una decisione che puoi indicare anziché un incidente di una funzione di supporto.

Poi separa le due domande nei tuoi test: questo indirizzo è ben formato, ed è recapitabile? Una singola asserzione che copre entrambe finirà prima o poi per sbagliare su una delle due. L’articolo sul test dei flussi di verifica copre cosa fare una volta che un indirizzo supera il primo controllo e la posta deve davvero arrivare.

Prossimi passi

Prendi la colonna degli indirizzi nel tuo prodotto e misurala rispetto alla tabella qui sopra; se è dimensionata per convenzione anziché secondo lo standard, allargala prima che l’indirizzo di qualcuno venga troncato alla registrazione. Poi apri la pagina della posta temporanea e genera un indirizzo nella forma noiosa, così che tu possa vedere cosa fa il tuo validatore con un input inequivocabilmente accettabile.