Quello che segue è un messaggio chiarificatore della corretta sintassi di un indirizzo di posta elettronica secondo le specifiche RFC-2822, che definiscono il formato standard per la composizione dei messaggi Internet, che ho voluto un giorno scrivere per motivi di lavoro.

  Siccome la lettura e la comprensione dello standard RFC-2822 si sono rivelati più ostici di quanto previsto (grazie anche alla scarsa familiarità con la sintassi Augmented Backus-Naur Form [ABNF] ivi utilizzata), ho voluto conservare e condividere questo documento per il beneficio di quanti volessero chiarire un loro dubbio espresso con la domanda: Un indirizzo email scritto in questo modo, è corretto oppure no?

  Nel rispetto dei criteri di condivisione delle definizioni degli standard Internet, libera e senza restrizioni di alcuna natura, con i quali sono divulgati i documenti RFC, anche il presente documento è disponibile "così com'è per qualsiasi scopo".  L'autore non è da ritenersi responsabile per eventuali errori od omissioni, ma non limita in alcun modo l'uso che chiunque ne vorrà fare.
Prima versione: gennaio 2008
Ultima revisione: 28 luglio 2010
< Torna al livello superiore <
<< Torna alla prima pagina <<
  Scusate, approfitto delle recenti comunicazione sugli indirizzi di posta elettronica validi o non validi per allegare uno studio quasi esaustivo sugli indirizzi di posta elettronica formalmente corretti e quelli che non lo sono.

  L'esposizione si basa sullo standard ufficiale che regola il formato di composizione dei messaggi di posta elettronica, lo RFC-2822.  È un testo molto strutturato e tecnico, per cui ne ho tentato un'estrazione delle sole parti d'interesse (il formato del solo indirizzo di destinazione) riscrivendolo in un linguaggio quanto più possibile chiaro e diretto e saltandone certe parti che non ci interessano.

  Questo nel solo caso si volesse optare per un software che effettui un controllo analitico esaustivo della corretta sintassi di un indirizzo di posta elettronica sintatticamente valido presente (o in via d'immissione) nel database EBILL. Oppure per verificare se un errore sia forse dovuto ad un indirizzo non valido finito nel DB.


Per gl'impazienti, potete andare in fondo alla sezione "Nel minor numero possibile di parole".


  Le specifiche ufficiali per la sintassi regolare degli indirizzi di posta elettronica è il documento RFC-2822, "Internet Message Format", pubblicato su:



  Specifica che un indirizzo di posta elettronica valido è costituito da (sezione: "3.4.1. Addr-spec specification"):

addr-spec = local-part "@" domain

local-part = dot-atom / quoted-string / obs-local-part

domain = dot-atom / domain-literal / obs-domain

domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]

dcontent = dtext / quoted-pair

dtext = NO-WS-CTL / ; Non white space controls

        %d33-90 /   ; The rest of the US-ASCII
        %d94-126    ; characters not including "[",
                    ; "]", or "\"


  La prima riga della lista di elementi riportata sopra vuol dire che un indirizzo di posta elettronica regolare è composto da una stringa "locale", il carattere "@" (ASCII decimale 64) e una parte finale che è il dominio.

Ad esempio: in trappola@route-add.net la parte locale è "trappola", mentre il dominio è "route-add.net".


Inizio sezione riguardante la parte locale dell'indirizzo di posta elettronica.


  La seconda riga della lista di elementi riportata sopra specifica che la parte locale di un indirizzo di posta elettronica regolare è composto da un elemento "dot-atom" oppure da una "quoted-string".

  Le stringhe definenti elementi di sintassi che iniziano con "obs-" indicano elementi obsoleti che sono da mantenersi per compatibilità con i vecchi sistemi di trasporto, consegna o di gestione da parte dell'utente dei messaggi, ma non saranno presi in considerazione nel testo presente per brevità.

  La forma dot-atom è descritta nella sezione "3.2.4. Atom" e consiste in una stringa definita dalla sintassi seguente:

dot-atom-text   =       1*atext *("." 1*atext)
ossia una stringa consistente in almeno un carattere atext, seguito da zero o più elementi costituiti da un punto "." (carattere ASCII decimale 46) cui segue, se presente, almeno un carattere atext, elemento quest'ultimo definito dalla sintassi seguente:
atext = ALPHA / DIGIT / ; Any character except controls,
        "!" / "#" /     ;  SP, and specials.
        "$" / "%" /     ;  Used for atoms
        "&" / "'" /
        "*" / "+" /
        "-" / "/" /
        "=" / "?" /
        "^" / "_" /
        "`" / "{" /
        "|" / "}" /
        "~"

  Ossia, lo atext è una stringa che può contenere tutti i caratteri ASCII alfabetici e numerici ma esclusi: i caratteri di controllo (da 0 a 31 decimale), il carattere spazio (32 decimale) e alcuni caratteri speciali (quale il carattere di cancellazione,  127 decimale).  Sono esplicitamente ammessi i caratteri elencati, ossia quelli contenuti nella stringa che segue:

!#$%&'*+-/=?^_`{|}~

  NON ne fanno parte, ad esempio, i caratteri contenuti nella stringa che segue:

[]()\,."@<>:;


  La forma quoted-string è descritta nella sezione "3.2.5. Quoted strings" e consiste in una stringa definita dalla sintassi seguente:

quoted-string = [CFWS]
                DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                [CFWS]

dove CFWS sta per "Comments and/or FWS" e FWS indica una "Folding White Space".

  Ossia:
  • una quoted-string può essere composta da uno o più commenti opzionali (definiti nella sezione "3.2.3. Folding white space and comments" come stringhe tra parentesi tonde, che qui si tralascia di trattare in dettaglio), magari contenenti una sequenza di 'ritorno-a-capo_con_spazio_iniziale' (sequenza che permette di continuare una stessa intestazione su più righe, caratteristica dello standard che qui si ometterà di trattare in ulteriore dettaglio rimandando alla sezione "2.2.3. Long Header Fields");
  • un carattere DQUOTE (doppio-apice) """ (carattere ASCII decimale 34);
  • zero o più elementi qcontent su un qualsiasi numero di righe di testo secondo il criterio FWS;
  • opzionalmente un'ultima riga vuota;
  • un carattere finale DQUOTE (doppio-apice) """ (carattere ASCII decimale 34);
  • altre righe di commento opzionali.

  L'elemento qcontent è definito nella stessa sezione "3.2.5. Quoted strings" come segue:

qcontent        =       qtext / quoted-pair

ossia o da un elemento qtext oppure da uno quoted-pair, dove l'elemento qtext è definito come:

qtext = NO-WS-CTL / ; Non white space controls
        %d33 /      ; The rest of the US-ASCII
        %d35-91 /   ;  characters not including "\"
        %d93-126    ;  or the quote character


(i caratteri ASCII tranne quelli di controllo, il carattere "\" e il carattere doppi-apici """) e dove l'elemento quoted-pair è definito nella sezione "3.2.2. Quoted characters" come:

quoted-pair = ("\" text) / obs-qp

ossia da un carattere " \" seguito da una stringa definita da (sezione "3.2.1. Primitive Tokens"):

text = %d1-9 / ; Characters excluding CR and LF
       %d11 /
       %d12 /
       %d14-127 /
       obs-text

qualsiasi carattere ASCII (anche di controllo) tranne i caratteri di ritorno-a-capo (ASCII decimale 13) e di nuova-linea (ASCII decimale 10).

Fine sezione riguardante la parte locale dell'indirizzo di posta elettronica.

  La sintassi corretta per i domini Internet è descritta nel documento RFC-1034, "DOMAIN NAMES - CONCEPTS AND FACILITIES".

  Qui si specifica che i nomi di dominio devono essere composti di un carattere ASCII alfabetico A-Z, a-z, seguito da altri caratteri  ASCII alfabetici e numerici 0-9, che possono contenere anche caratteri "-" ma solo se circondati da caratteri alfa-numerici.  Il tutto senza discriminazione di maiuscole/minuscole, anche se queste dovrebbero essere mantenute inalterate, e raggruppati in elementi separati da caratteri "." se si tratta di nomi di dominio assoluti (che è il caso di nostro interesse), per una lunghezza massima totale di 255 caratteri.


Considerazioni finali

Possibili semplificazioni:
  • tutte le considerazioni sulle intestazioni (inclusa quella "To: " contenente l'indirizzo email di destinazione) distribuite su più linee possono essere ignorate richiedendo che tutte le stringhe immesse nel database contenenti indirizzi email validi siano scritti sulla stessa riga e che omettano tutti i commenti, come ad esempio il nome e il cognome dell'utente (cosa che già si fa) e facendo tesoro dell'indicazione contenuta nella sezione "2.2.3. Long Header Fields" che i ritorni a capo siano confinati tra elementi di strutture sintattiche di più alto livello (ad esempio, quelle che separano più indirizzi email tra di loro oppure un commento dal relativo indirizzo email, ma non all'interno dello stesso indirizzo).
  • Nella sezione "3.4.1. Addr-spec specification" è specificato che: se una stringa può essere rappresentata da una dot-atom (cioè non contiene altri caratteri oltre a caratteri atext [vedasi sopra] o un punto "." circondato da caratteri atext), allora la forma dot-atom DOVREBBE essere usata e la forma quoted-string NON DOVREBBE essere usata.  I commenti e il FWS [ritorno a capo con spazi bianchi] NON DOVREBBERO essere usati intorno al carattere "@" dello addr-spec [stringa che specifica l'indirizzo].

  La dicitura DOVREBBE/NON DOVREBBE (SHOULD/SHOULD NOT) è la seconda più forte usata nei documenti RFC dopo DEVE/NON DEVE (MUST/MUST NOT), quindi imporre tale vincolo non è una limitazione esagerata dello standard.


  Nel minor numero possibile di parole:

Un indirizzo valido e conforme alle specifiche tecniche definite negli standard pubblicati nella RFC-2822 e RFC-1034, può essere costituito da una prima stringa contenente qualsiasi numero di questi caratteri (dove  ALFANUM=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 ):

ALFANUM!#$%&'*+-/=?^_`{|}~.

con il carattere "-" (meno) mai doppio; in seguito deve comparire il carattere "@" e il nome di dominio contenente esclusivamente i caratteri:

ALFANUM.-

con i caratteri "-" (meno) e "." mai doppi.

  Ad esempio, gl'indirizzi a sinistra sono validi, ma quelli a destra non lo sono.

giulio+d'arrigo@giulio-darrigo.it            giulio@d'arrigo.it
antonio&carrieri_lab.a2@gc45.info            antonio(carrieri)@gc45.info
sandro+lori=due-fratelli@famiglia.net        noi\due@famiglia--casa.net
giulio.valori@incipit.com                    giulio"valori@incipit.com


  Saluti,

< Torna al livello superiore <
<< Torna alla prima pagina <<