Quali caratteri sono ammessi in un indirizzo email?

Non sto chiedendo la convalida e-mail completa.

Voglio solo sapere quali sono i caratteri consentiti user-namee le serverparti dell'indirizzo e-mail. Questo può essere semplificato, forse gli indirizzi e-mail possono assumere altre forme, ma non mi interessa. Sto chiedendo solo questo semplice modulo: user-name@server(ad esempio wild.wezyr@best-server-ever.com) e caratteri consentiti in entrambe le parti.

Vedere RFC 5322: Formato dei messaggi Internet e, in misura minore, RFC 5321: Simple Mail Transfer Protocol .

RFC 822 copre anche indirizzi e-mail, ma si occupa principalmente della sua struttura:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

E come al solito, Wikipedia ha un articolo decente sugli indirizzi e-mail :

La parte locale dell'indirizzo e-mail può utilizzare uno di questi caratteri ASCII:

• lettere latine maiuscole e minuscole Ada Ze averso z;
• cifre 0a 9;
• personaggi speciali !#$%&'*+-/=?^_`{|}~;
• punto ., a condizione che non sia il primo o l'ultimo carattere a meno che non sia citato, e purché non appaia consecutivamente a meno che non sia citato (ad es. John..Doe@example.comnon è consentito ma "John..Doe"@example.comè consentito);
• lo spazio e i "(),:;<>@[\]caratteri sono consentiti con restrizioni (sono consentiti solo all'interno di una stringa tra virgolette, come descritto nel paragrafo seguente, e inoltre, una barra rovesciata o una virgoletta doppia devono essere precedute da una barra rovesciata);
• sono consentiti commenti tra parentesi alle estremità della parte locale; ad esempio john.smith(comment)@example.come (comment)john.smith@example.comsono entrambi equivalenti a john.smith@example.com.

Oltre ai caratteri ASCII, a partire dal 2012 è possibile utilizzare i caratteri internazionali sopraU+007F , codificati come UTF-8 come descritto nelle specifiche RFC 6532 e spiegato su Wikipedia . Si noti che a partire dal 2019, questi standard sono ancora contrassegnati come proposti, ma vengono implementati lentamente. Le modifiche apportate a questa specifica hanno essenzialmente aggiunto caratteri internazionali come caratteri alfanumerici validi (atext) senza influire sulle regole sui caratteri speciali consentiti e limitati come !#e @:.

Per la convalida, vedere Utilizzo di un'espressione regolare per convalidare un indirizzo e-mail .

La domainparte è definita come segue :

Gli standard Internet (Request for Comments) per i protocolli mandato che le etichette hostname componenti possono contenere solo i caratteri ASCII aattraverso z(in maniera case-insensitive), le cifre 0attraverso 9, e il trattino ( -). La specifica originale dei nomi host in RFC 952 , prevedeva che le etichette non potevano iniziare con una cifra o con un trattino e non devono terminare con un trattino. Tuttavia, una specifica successiva ( RFC 1123 ) ha permesso alle etichette dei nomi host di iniziare con le cifre. Non sono consentiti altri simboli, caratteri di punteggiatura o spazi vuoti.

Attento! C'è un sacco di conoscenza marcire in questo thread (cose che prima erano vere e ora non lo sono).

Per evitare il rifiuto di falsi positivi di indirizzi di posta elettronica effettivi nel mondo attuale e futuro e da qualsiasi parte del mondo, è necessario conoscere almeno il concetto di alto livello di RFC 3490 , "Internazionalizzazione dei nomi di dominio nelle applicazioni (IDNA)". So che la gente negli Stati Uniti e A spesso non sono d'accordo, ma è già in uso diffuso e in rapido aumento in tutto il mondo (principalmente le parti non inglesi).

L'essenza è che ora puoi usare indirizzi come mason @ 日本 .com e wildwezyr@fahrvergnügen.net. No, questo non è ancora compatibile con tutto ciò che c'è là fuori (come molti hanno lamentato sopra, anche i semplici indirizzi in stile qmail + ident sono spesso erroneamente respinti). Ma c'è un RFC, c'è una specifica, ora è supportato da IETF e ICANN e, cosa ancora più importante, c'è un numero crescente e crescente di implementazioni a supporto di questo miglioramento che sono attualmente in servizio.

Non sapevo molto di questo sviluppo da solo fino a quando non sono tornato in Giappone e ho iniziato a vedere indirizzi email come hei @ や る .ca e URL Amazon come questo:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ク ス - デ ジ タ ル カ メ ラ -? ポ ー タ ブ ル オ ー デ ィ オ / b / ref = topnav_storetab_e ie = UTF-8 & node = 3.210.981

So che non vuoi collegamenti a specifiche, ma se fai affidamento esclusivamente sulla conoscenza obsoleta degli hacker nei forum di Internet, il tuo validatore e-mail finirà per rifiutare gli indirizzi e-mail che gli utenti non di lingua inglese si aspettano sempre più di lavorare. Per quegli utenti, tale convalida sarà fastidiosa tanto quanto la comune forma morta di cervello che tutti odiamo, quella che non è in grado di gestire un + o un nome di dominio in tre parti o altro.

Quindi non sto dicendo che non è una seccatura, ma l'elenco completo dei caratteri "ammessi in alcune / nessuna / nessuna" è (quasi) tutti i caratteri in tutte le lingue. Se si desidera "accettare tutti gli indirizzi e-mail validi (e anche molti non validi)", è necessario prendere in considerazione IDN, il che in pratica rende inutile (scusate) un approccio basato sui caratteri, a meno che non si convertano prima gli indirizzi e-mail internazionalizzati in Punycode .

Dopo averlo fatto puoi seguire (la maggior parte) dei consigli sopra.

Il formato dell'indirizzo e-mail è: local-part@domain-part(max. 64 a 255 caratteri, non più di 256 in totale).

Il local-parte domain-partpotrebbe avere diversi set di caratteri consentiti, ma non è tutto, in quanto vi sono più regole.

In generale, la parte locale può avere questi caratteri ASCII:

• minuscole lettere latine: abcdefghijklmnopqrstuvwxyz,
• maiuscole lettere latine: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• cifre: 0123456789,
• caratteri speciali: !#$%&'*+-/=?^_`{|}~,
• punto: .(non primo o ultimo carattere o ripetuto se non citato),
• punteggiatura dello spazio come: "(),:;<>@[\](con alcune restrizioni),
• commenti: ()(sono ammessi tra parentesi, ad es (comment)john.smith@example.com.).

Parte del dominio:

• minuscole lettere latine: abcdefghijklmnopqrstuvwxyz,
• maiuscole lettere latine: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• cifre: 0123456789,
• trattino: -(non il primo o l'ultimo carattere),
• può contenere un indirizzo IP racchiuso tra parentesi quadre: jsmith@[192.168.2.1]o jsmith@[IPv6:2001:db8::1].

Questi indirizzi e-mail sono validi:

• prettyandsimple@example.com
• very.common@example.com
• disposable.style.email.with+symbol@example.com
• other.email-with-dash@example.com
• x@example.com (parte locale di una lettera)
• "much.more unusual"@example.com
• "very.unusual.@.unusual.com"@example.com
• "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
• example-indeed@strange-example.com
• admin@mailserver1 (nome di dominio locale senza dominio di primo livello)
• #!$%&'*+-/=?^_`{}|~@example.org
• "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
• " "@example.org (spazio tra le virgolette)
• example@localhost (inviato da localhost)
• example@s.solutions(vedi l' elenco dei domini di primo livello Internet )
• user@com
• user@localserver
• user@[IPv6:2001:db8::1]

E questi esempi di invalidi:

• Abc.example.com(nessun @personaggio)
• A@b@c@example.com( @è consentito solo uno tra virgolette)
• a"b(c)d,e:f;gi[j\k]l@example.com (nessuno dei caratteri speciali in questa parte locale è consentito al di fuori delle virgolette)
• just"not"right@example.com (le stringhe tra virgolette devono essere separate da punti o l'unico elemento che costituisce la parte locale)
• this is"not\allowed@example.com (spazi, virgolette e barre rovesciate possono esistere solo all'interno di stringhe tra virgolette e precedute da una barra rovesciata)
• this\ still\"not\allowed@example.com (anche se con escape (preceduto da una barra rovesciata), gli spazi, le virgolette e le barre rovesciate devono ancora essere racchiusi tra virgolette)
• john..doe@example.com(punto doppio prima @); (con un avvertimento: Gmail lo fa passare)
• john.doe@example..com(doppio punto dopo @)
• un indirizzo valido con uno spazio iniziale
• un indirizzo valido con uno spazio finale

Fonte: indirizzo e-mail su Wikipedia

RFC2822 di Perl regex per la convalida delle e-mail:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

Il regexp completo per gli indirizzi RFC2822 era di soli 3,7k.

Vedi anche: Analizzatore di indirizzi e-mail RFC 822 in PHP .

Le definizioni formali degli indirizzi e-mail sono in:

• RFC 5322 (sezioni 3.2.3 e 3.4.1, obsoletes RFC 2822), RFC 5321, RFC 3696,
• RFC 6531 (caratteri consentiti).

Relazionato:

• Il vero potere delle espressioni regolari

Wikipedia ha un buon articolo su questo e le specifiche ufficiali sono qui . Da Wikipdia:

La parte locale dell'indirizzo e-mail può utilizzare uno di questi caratteri ASCII:

• Lettere inglesi maiuscole e minuscole (az, AZ)
• Cifre da 0 a 9
• Personaggi ! # $% & '* + - / =? ^ _ `{| } ~
• Carattere . (punto, punto, punto e virgola) a condizione che non sia il primo o l'ultimo carattere e anche che non compaia due o più volte consecutive.

Inoltre, le stringhe tra virgolette (es .: "John Doe" @ example.com) sono consentite, consentendo così caratteri che sarebbero altrimenti proibiti, tuttavia non compaiono nella pratica comune. RFC 5321 avverte inoltre che "un host che prevede di ricevere posta DOVREBBE evitare di definire le cassette postali in cui la parte locale richiede (o utilizza) il modulo stringa di virgolette".

Google fa una cosa interessante con i suoi indirizzi gmail.com. Gli indirizzi gmail.com consentono solo lettere (az), numeri e punti (che vengono ignorati).

ad esempio, pikachu@gmail.com è uguale a pi.kachu@gmail.com e entrambi gli indirizzi e-mail verranno inviati alla stessa casella di posta. Anche PIKACHU@gmail.com viene recapitato nella stessa casella di posta.

Quindi, per rispondere alla domanda, a volte dipende dall'implementatore da quanto degli standard RFC vogliono seguire. Lo stile dell'indirizzo gmail.com di Google è compatibile con gli standard. Lo fanno in questo modo per evitare confusione laddove persone diverse prenderebbero indirizzi email simili, ad es

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

Il link di Wikipedia è un buon riferimento a ciò che gli indirizzi email generalmente consentono. http://en.wikipedia.org/wiki/Email_address

Puoi iniziare dall'articolo di Wikipedia :

• Lettere inglesi maiuscole e minuscole (az, AZ)
• Cifre da 0 a 9
• Personaggi ! # $% & '* + - / =? ^ _ `{| } ~
• Carattere . (punto, punto, punto e virgola) a condizione che non sia il primo o l'ultimo carattere e anche che non compaia due o più volte consecutive.

Nome:

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

Server:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

Controlla @ e. e quindi inviare un'e-mail per la verifica.

Non riesco ancora a utilizzare il mio indirizzo email .name sul 20% dei siti su Internet perché qualcuno ha rovinato la convalida della posta elettronica o perché è precedente alla validità dei nuovi indirizzi.

La risposta breve è che ci sono 2 risposte. C'è uno standard per quello che dovresti fare. cioè un comportamento che è saggio e ti terrà fuori dai guai. C'è un altro standard (molto più ampio) per il comportamento che dovresti accettare senza creare problemi. Questa dualità funziona per l'invio e l'accettazione di e-mail ma ha un'ampia applicazione nella vita.

Per una buona guida agli indirizzi che crei; vedi: http://www.remote.org/jochen/mail/info/chars.html

Per filtrare e-mail valide, basta trasmettere qualsiasi cosa sufficientemente comprensibile per vedere il passaggio successivo. O inizia a leggere un mucchio di RFC, attenzione, ecco i draghi.

Una buona lettura in merito .

Estratto:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

La risposta accettata si riferisce a un articolo di Wikipedia quando si discute la parte locale valida di un indirizzo e-mail, ma Wikipedia non è un'autorità al riguardo.

IETF RFC 3696 è un'autorità in materia e dovrebbe essere consultato nella sezione 3. Restrizioni per gli indirizzi e-mail a pagina 5:

Gli indirizzi e-mail contemporanei sono costituiti da una "parte locale" separata da una "parte di dominio" (un nome di dominio completo) da un segno ("@"). La sintassi della parte del dominio corrisponde a quella della sezione precedente. Le preoccupazioni identificate in quella sezione sul filtraggio e sugli elenchi di nomi si applicano anche ai nomi di dominio utilizzati in un contesto di posta elettronica. Il nome di dominio può anche essere sostituito da un indirizzo IP tra parentesi quadre, ma tale modulo è fortemente sconsigliato, tranne per scopi di test e risoluzione dei problemi.

La parte locale può apparire utilizzando le convenzioni di quotazione descritte di seguito. I moduli citati sono usati raramente nella pratica, ma sono necessari per alcuni scopi legittimi. Pertanto, non devono essere rifiutati nelle routine di filtro, ma devono invece essere passati al sistema di posta elettronica per la valutazione da parte dell'host di destinazione.

La regola esatta è che qualsiasi carattere ASCII, inclusi i caratteri di controllo, può apparire tra virgolette o in una stringa tra virgolette. Quando è necessario un preventivo, il carattere barra rovesciata viene utilizzato per citare il seguente carattere. Per esempio

  Abc\@def@example.com

è una forma valida di un indirizzo email. Potrebbero anche apparire spazi vuoti, come in

  Fred\ Bloggs@example.com

Il carattere barra rovesciata può anche essere usato per citare se stesso, ad es.

  Joe.\\Blow@example.com

Oltre a quotare usando il carattere barra rovesciata, è possibile utilizzare caratteri convenzionali a virgoletta doppia per circondare le stringhe. Per esempio

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

sono forme alternative dei primi due esempi sopra. Questi moduli citati sono raramente raccomandati e sono poco comuni nella pratica, ma, come discusso in precedenza, devono essere supportati da applicazioni che elaborano indirizzi e-mail. In particolare, le forme citate appaiono spesso nel contesto di indirizzi associati a transizioni da altri sistemi e contesti; tali requisiti transitori persistono e, poiché un sistema che accetta un indirizzo e-mail fornito dall'utente non può "sapere" se tale indirizzo è associato a un sistema legacy, i moduli dell'indirizzo devono essere accettati e passati nell'ambiente e-mail.

Senza virgolette, le parti locali possono consistere in qualsiasi combinazione di
caratteri alfabetici, cifre o uno qualsiasi dei caratteri speciali

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

può anche apparire il punto ("."), ma non può essere usato per iniziare o terminare la parte locale, né possono apparire due o più periodi consecutivi. Detto diversamente, qualsiasi carattere grafico ASCII (in stampa) diverso dal segno at ("@"), barra rovesciata, virgoletta doppia, virgola o parentesi quadre può apparire senza virgolette. Se deve apparire uno di questi elenchi di caratteri esclusi, questi devono essere citati. Forme come

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

sono validi e vengono visualizzati abbastanza regolarmente, ma è consentito uno qualsiasi dei personaggi sopra elencati.

Come altri hanno fatto, invio una regex che funziona sia per PHP che JavaScript per convalidare gli indirizzi e-mail:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

Come puoi trovare in questo link di Wikipedia

La parte locale dell'indirizzo e-mail può utilizzare uno di questi caratteri ASCII:

• lettere latine maiuscole e minuscole Ada Ze averso z;

• cifre 0a 9;

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

• punto ., a condizione che non sia il primo o l'ultimo carattere a meno che non sia citato, e purché non appaia consecutivamente a meno che non sia citato (ad es. John..Doe@example.comnon è consentito ma "John..Doe"@example.comè consentito);

• lo spazio e i "(),:;<>@[\]caratteri sono consentiti con restrizioni (sono consentiti solo all'interno di una stringa tra virgolette, come descritto nel paragrafo seguente, e inoltre, una barra rovesciata o una virgoletta doppia devono essere precedute da una barra rovesciata);

• sono consentiti commenti tra parentesi alle estremità della parte locale; ad esempio john.smith(comment)@example.come (comment)john.smith@example.comsono entrambi equivalenti a john.smith@example.com.

Oltre ai precedenti caratteri ASCII, i caratteri internazionali sopra U + 007F, codificati come UTF-8, sono consentiti da RFC 6531 , sebbene i sistemi di posta elettronica possano limitare quali caratteri utilizzare quando si assegnano parti locali.

Una stringa tra virgolette può esistere come entità separata da punti all'interno della parte locale, oppure può esistere quando le virgolette più esterne sono i caratteri più esterni della parte locale (ad esempio, abc."defghi".xyz@example.como "abcdefghixyz"@example.comsono consentite. Al contrario, abc"defghi"xyz@example.comnon lo è; né lo è abc\"def\"ghi@example.com). Stringhe e caratteri tra virgolette tuttavia, non sono comunemente usati. RFC 5321 avverte inoltre che "un host che prevede di ricevere posta DOVREBBE evitare di definire le cassette postali in cui la parte locale richiede (o utilizza) il modulo stringa di virgolette".

La parte locale postmasterviene trattata in modo speciale: non fa distinzione tra maiuscole e minuscole e deve essere inoltrata all'amministratore della posta elettronica del dominio. Tecnicamente tutti gli altri locali-parti sono case-sensitive, quindi jsmith@example.come JSmith@example.comspecificano cassette postali differenti; tuttavia, molte organizzazioni trattano le lettere maiuscole e minuscole come equivalenti.

Nonostante l'ampia gamma di caratteri speciali tecnicamente validi; le organizzazioni, i servizi di posta, i server di posta e i client di posta in pratica spesso non li accettano tutti. Ad esempio, Windows Live Hotmail consente solo la creazione di indirizzi e-mail utilizzando alfanumerici, punto ( .), trattino basso ( _) e trattino ( -). Un consiglio comune è di evitare l'uso di alcuni caratteri speciali per evitare il rischio di e-mail rifiutate.

La risposta è (quasi) ALL(ASCII a 7 bit).
Se le regole di inclusione sono "... consentite in alcune / nessuna / nessuna condizione ..."

Solo osservando una delle diverse possibili regole di inclusione per il testo consentito nella parte "testo di dominio" in RFC 5322 nella parte superiore della pagina 17 troviamo:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

gli unici tre caratteri mancanti in questa descrizione sono usati in domain-letteral [], per formare una coppia tra virgolette \e il carattere dello spazio bianco (% d32). Con ciò viene utilizzato l'intero intervallo 32-126 (decimale). Un requisito simile appare come "qtext" e "ctext". Sono ammessi / utilizzati anche molti caratteri di controllo. Un elenco di tali caratteri di controllo appare nella sezione 31 della sezione 4.1 di RFC 5322 come obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

Tutti questi caratteri di controllo sono consentiti come indicato all'inizio della sezione 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

E tale regola di inclusione è quindi "troppo ampia". O, in altri sensi, la regola attesa è "troppo semplicistica".

Per semplicità, disinfetto l'invio rimuovendo tutto il testo tra virgolette doppie e quelle associate che racchiudono le virgolette prima della convalida, inserendo il kibosh negli invii di indirizzi e-mail in base a ciò che non è consentito. Solo perché qualcuno può avere John. "L'indirizzo * $ hizzle * Bizzle". L'indirizzo Doe@whatever.com non significa che devo permetterlo nel mio sistema. Viviamo in futuro dove forse ci vorrà meno tempo per ottenere un indirizzo e-mail gratuito che per fare un buon lavoro pulendo il culo. E non è come se i criteri e-mail non fossero intonacati proprio accanto all'ingresso dicendo ciò che è e non è permesso.

Inoltre, disinfetto ciò che non è specificamente consentito da vari RFC dopo la rimozione del materiale citato. L'elenco di caratteri e motivi specificamente vietati sembra essere un elenco molto più breve da provare.

Non consentito:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

Nell'esempio fornito:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

L'invio di un messaggio e-mail di conferma al risultato rimanente nel tentativo di aggiungere o modificare l'indirizzo e-mail è un buon modo per vedere se il codice è in grado di gestire l'indirizzo e-mail inviato. Se l'e-mail supera la convalida dopo tutti i cicli di sanificazione necessari, disattiva tale conferma. Se una richiesta ritorna dal link di conferma, la nuova e-mail può essere spostata dallo stato purgatorio o temporaneo di archiviazione || temporanea || per diventare una vera e-mail archiviata di prima classe autentica.

Una notifica di errore o successo nella modifica dell'indirizzo e-mail può essere inviata al vecchio indirizzo e-mail se si desidera essere premurosi. Le configurazioni degli account non confermate potrebbero cadere dal sistema poiché tentativi falliti del tutto dopo un ragionevole lasso di tempo.

Non consento e-mail puzzolenti sul mio sistema, forse questo è solo buttare via i soldi. Tuttavia, il 99,9% delle volte le persone fanno semplicemente la cosa giusta e dispongono di un'e-mail che non supera i limiti di conformità fino al limite utilizzando scenari di compatibilità dei casi limite. Fai attenzione a regex DDoS, questo è un posto dove puoi metterti nei guai. E questo è legato alla terza cosa che faccio, ho messo un limite a quanto tempo sono disposto a elaborare una e-mail. Se è necessario rallentare la macchina per essere convalidato, non sta superando la logica dell'endpoint dell'API dei dati in entrata.

Modifica: questa risposta continuava a essere macchiata per essere "cattiva", e forse se lo meritava. Forse è ancora male, forse no.

Nel mio PHP utilizzo questo controllo

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

provalo tu stesso http://phpfiddle.org/main/code/9av6-d10r

Ho creato questo regex secondo le linee guida RFC:

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

Gmail consentirà solo + segno come carattere speciale e in alcuni casi (.) Ma qualsiasi altro carattere speciale non è consentito su Gmail. RFC afferma che puoi usare caratteri speciali ma dovresti evitare di inviare posta a Gmail con caratteri speciali.