risposta-alla-domanda-sullo-sviluppo-web-bd.com

Quali caratteri sono ammessi in un indirizzo email?

Non sto chiedendo di convalidare la posta elettronica completa.

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

535
WildWezyr

Vedi RFC 5322: Formato messaggio Internet e, in misura minore, RFC 5321: Simple Mail Transfer Protocol .

RFC 822 copre anche gli indirizzi email, 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 discreto articolo sugli indirizzi email :

La parte locale dell'indirizzo email può utilizzare uno qualsiasi di questi caratteri ASCII:

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

Oltre a ASCII caratteri, a partire dal 2012 puoi usare international caratteri sopraU+007F, codificati come UTF-8 come descritto nella specifica RFC 6532 e spiegato su Wikipedia . Si noti che a partire dal 2019, questi standard sono ancora contrassegnati come Proposed, ma vengono lanciati lentamente. I cambiamenti in questa specifica hanno essenzialmente aggiunto caratteri internazionali come caratteri alfanumerici validi (atext) senza influenzare le regole sui caratteri speciali consentiti e ristretti come !# e @:.

Per la convalida, vedi Utilizzo di un'espressione regolare per convalidare un indirizzo email .

La parte domain è definita come segue :

Gli standard Internet (Request for Comments) per i protocolli impongono che le etichette hostname dei componenti possano contenere solo ASCII letters a attraverso z (in modo maiuscole/minuscole), le cifre 0 attraverso 9 e il trattino (- ). La specifica originale dei nomi host in RFC 952 , imposto che le etichette non possano iniziare con una cifra o con un trattino e non deve terminare con un trattino. Tuttavia, una specifica successiva ( RFC 1123 ) ha permesso alle etichette del nome host di iniziare con le cifre. Non sono consentiti altri simboli, caratteri di punteggiatura o spazi vuoti.

701
Anton Gogolev

Attento! C'è una marea di conoscenze in questo thread (cose che prima erano vere e che ora non lo sono).

Per evitare falsi positivi di indirizzi email 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 gente negli Stati Uniti e A spesso non sono all'altezza, ma è già in uso diffuso e in rapido aumento in tutto il mondo (principalmente le parti dominate dall'inglese).

Il Gist è che ora puoi usare indirizzi come mason @ 日本 .com e [email protected]ügen.net. No, questo non è ancora compatibile con tutto ciò che c'è fuori (come molti hanno lamentato in precedenza, anche gli indirizzi in stile qmail-style + sono spesso erroneamente rifiutati). Ma c'è una RFC, c'è una specifica, ora è supportata da IETF e ICANN, e - cosa più importante - c'è un numero crescente e crescente di implementazioni che supportano questo miglioramento attualmente in servizio.

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

http://www.Amazon.co.jp/ エ レ ク ト ロ ポ ニ ス ス デ デ ジ b b b/b/ref = topnav_storetab_e? ie = UTF8 e nodo = 3210981

So che non vuoi link a specifiche, ma se ti affidi esclusivamente alle conoscenze obsolete degli hacker sui forum di Internet, il tuo validatore di e-mail finirà per rifiutare gli indirizzi email che gli utenti non-Enlish si aspettano sempre di lavorare. Per quegli utenti, tale convalida sarà altrettanto fastidiosa di quella forma di cervello comune che tutti noi odiamo, quella che non può gestire un dominio + o un nome di dominio in tre parti o altro.

Quindi non sto dicendo che non è una seccatura, ma l'elenco completo di caratteri "permesso in alcune/nessuna/nessuna condizione" è (quasi) tutti i caratteri in tutte le lingue. Se vuoi "accettare tutti gli indirizzi e-mail validi (e molti anche non validi)" allora devi prendere in considerazione IDN, il che rende praticamente un approccio basato sui personaggi inutile (mi dispiace), a meno che tu non abbia prima convertito gli indirizzi email internazionalizzati a Punycode .

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

291
Mason

Il formato dell'indirizzo e-mail è: [email protected] (massimo 64 caratteri a 255 caratteri, non più 256 in totale).

local-part e domain-part potrebbero avere set diversi di caratteri consentiti, ma non è tutto, poiché ci sono più regole ad esso.

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

  • lettere latine minuscole: abcdefghijklmnopqrstuvwxyz,
  • lettere maiuscole latine: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • cifre: 0123456789,
  • caratteri speciali: !#$%&'*+-/=?^_`{|}~,
  • punto: . (non il primo o l'ultimo carattere o ripetuto se non citato),
  • punteggiature spaziali come: "(),:;<>@[\] (con alcune restrizioni),
  • commenti: () (sono consentiti tra parentesi, ad esempio (comment)[email protected]).

Parte del dominio:

  • lettere latine minuscole: abcdefghijklmnopqrstuvwxyz,
  • lettere maiuscole latine: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • cifre: 0123456789,
  • trattino: - (non primo o ultimo carattere),
  • può contenere un indirizzo IP circondato da parentesi quadre: [email protected][192.168.2.1] o [email protected][IPv6:2001:db8::1].

Questi indirizzi e-mail sono validi:

E questi esempi di non validi:

  • Abc.example.com (nessun carattere @)
  • [email protected]@[email protected] (solo un @ è consentito al di fuori delle virgolette)
  • a"b(c)d,e:f;gi[j\k][email protected] (nessuno dei caratteri speciali in questa parte locale è consentito al di fuori delle virgolette)
  • just"not"[email protected] (le stringhe tra virgolette devono essere separate da punti o l'unico elemento che compone la parte locale)
  • this is"not\[email protected] (spazi, virgolette e backslash possono esistere solo all'interno di stringhe tra virgolette e preceduti da una barra rovesciata)
  • this\ still\"not\[email protected] (anche se con caratteri di escape (preceduti da una barra rovesciata), spazi, virgolette e barre retroverse devono essere ancora contenute tra virgolette)
  • [email protected] (double dot before @); (con avvertenza: Gmail lascia passare questo)
  • [email protected] (doppio punto dopo @)
  • un indirizzo valido con uno spazio leader
  • un indirizzo valido con uno spazio finale

Fonte: Indirizzo email su Wikipedia


RFC2822 di Perl regex per la convalida della posta elettronica:

(?:(?:\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*)

L'espressione regolare per gli indirizzi RFC2822 era di soli 3,7 k.

Vedi anche: Parser indirizzo email RFC 822 in PHP .


Le definizioni formali degli indirizzi e-mail sono in:

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

Relazionato:

37
kenorb

Wikipedia ha un buon articolo su questo , e la specifica ufficiale è qui . Da Wikipdia:

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

  • Lettere maiuscole e minuscole in inglese (a-z, A-Z)
  • Cifre da 0 a 9
  • Personaggi ! # $% & '* + -/=? ^ _ `{| } ~
  • Personaggio . (punto, punto, punto) a condizione che non sia il primo o l'ultimo carattere, e che anche questo non compaia due o più volte consecutivamente.

Inoltre, sono consentite le stringhe quotate (ad es. "John Doe" @ esempio.com), consentendo quindi caratteri altrimenti vietati, tuttavia non appaiono nella pratica comune. RFC 5321 avverte anche che "un host che si aspetta di ricevere mail DOVREBBE evitare di definire caselle di posta in cui la parte locale richiede (o utilizza) il modulo di stringa quotata".

21
Mike Weller

Puoi iniziare da wikipedia article :

  • Lettere maiuscole e minuscole in inglese (a-z, A-Z)
  • Cifre da 0 a 9
  • Personaggi ! # $% & '* + -/=? ^ _ `{| } ~
  • Personaggio . (punto, punto, punto) a condizione che non sia il primo o l'ultimo carattere, e che anche questo non compaia due o più volte consecutivamente.
12
Vladimir

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

ad esempio, [email protected] è uguale a [email protected] e entrambi gli indirizzi di posta elettronica verranno inviati alla stessa casella di posta. [email protected] viene anche consegnato alla stessa casella di posta.

Quindi, per rispondere alla domanda, a volte dipende dall'implementatore su quanta parte degli standard RFC vogliono seguire. Lo stile di indirizzo di 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 ***
[email protected]   (accepted)
[email protected]   (bounce and account can never be created)
[email protected]     (accepted)
D.Oy'[email protected]   (bounce and account can never be created)

Il link wikipedia è un buon riferimento su ciò che gli indirizzi email generalmente consentono. http://en.wikipedia.org/wiki/Indirizzo email

12
Angel Koh

Nome:

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

Server:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.
11
ThinkingStiff

Controlla @ e. e quindi inviare una email per loro per verificare.

Non riesco ancora a utilizzare il mio indirizzo email .name sul 20% dei siti su Internet perché qualcuno ha rovinato la convalida dell'email o perché è anteriore ai nuovi indirizzi che sono validi.

9
Richard Maxwell

La risposta accettata si riferisce ad un articolo di Wikipedia quando si discute della parte locale valida di un indirizzo email, ma Wikipedia non è un'autorità in merito.

IETF RFC 3696è un'autorità su questo argomento, e dovrebbe essere consultato nella sezione 3. Limitazioni sugli indirizzi email a pagina 5:

Gli indirizzi email contemporanei consistono in una "parte locale" separata da una "parte del dominio" (un nome di dominio completo) da un at-sign ("@"). La sintassi della parte del dominio corrisponde a quella della sezione precedente. Le preoccupazioni identificate in quella sezione sul filtraggio e gli 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 forma è fortemente sconsigliata tranne che per scopi di test e risoluzione dei problemi.

La parte locale può apparire utilizzando le convenzioni di citazione descritte di seguito. I moduli citati sono usati raramente nella pratica, ma sono richiesti per alcuni scopi legittimi. Quindi, non dovrebbero essere rifiutati nelle routine di filtraggio ma, dovrebbero 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 quotare, il carattere backslash viene utilizzato per citare il seguente carattere. Per esempio

  Abc\@[email protected]

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

  Fred\ [email protected]

Il carattere backslash può anche essere usato per quotare se stesso, ad es.

  Joe.\\[email protected]

Oltre a citare usando il carattere barra rovesciata, i caratteri convenzionali a virgoletta possono essere usati per circondare le stringhe. Per esempio

  "[email protected]"@example.com

  "Fred Bloggs"@example.com

sono forme alternative dei primi due esempi sopra. Questi moduli citati sono raramente raccomandati e sono rari nella pratica, ma, come discusso sopra, devono essere supportati dalle applicazioni che stanno elaborando gli 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 continuano a sorgere e, dal momento che un sistema che accetta un indirizzo email fornito dall'utente non può "sapere" se quell'indirizzo è associato a un sistema legacy, i moduli di indirizzo devono essere accettati e inoltrati nell'ambiente di posta elettronica.

Senza virgolette, le parti locali possono essere costituite da qualsiasi combinazione di
caratteri alfabetici, cifre o uno qualsiasi dei caratteri speciali

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

periodo (".") può anche apparire, ma non può essere usato per iniziare o terminare la parte locale, né possono apparire due o più periodi consecutivi. Detto in modo diverso, qualsiasi carattere ASCII grafico (stampa) diverso dal segno-at ("@"), dal backslash, dal doppio virgolette, dalla virgola o dalle parentesi quadre può apparire senza virgolette. Se qualcuno di quella lista di personaggi esclusi deve apparire, devono essere citati. Forme come

  [email protected]

  customer/[email protected]

  [email protected]

  !def!xyz%[email protected]

  [email protected]

sono validi e sono visti abbastanza regolarmente, ma uno qualsiasi dei caratteri sopra elencati è permesso.

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

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

Una buona lettura sul argomento .

Estratto:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"[email protected]"@example.com
customer/[email protected]
\[email protected]
!def!xyz%[email protected]
[email protected]
5
Luke Madhanga

La risposta breve è che ci sono 2 risposte. C'è uno standard per ciò che dovresti fare. cioè un comportamento che è saggio e ti terrà lontano dai guai. C'è un altro (molto più ampio) standard 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 le e-mail valide, basta trasmettere qualcosa di abbastanza comprensibile per vedere il prossimo passo. O inizia a leggere un mucchio di RFC, attenzione, qui ci sono i draghi.

5
Michael JAMES

Come si può trovare in questo link di Wikipedia

La parte locale dell'indirizzo email può utilizzare uno qualsiasi di questi caratteri ASCII:

  • lettere maiuscole e minuscole latine Aa Ze aa zname__;

  • cifre 0 a 9;

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

  • punto ., a condizione che non sia il primo o l'ultimo carattere se non quotato e purché non appaia consecutivamente a meno di quotato (ad esempio [email protected] non è consentito ma "John..Doe"@example.com è consentito);

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

  • i commenti sono consentiti con parentesi alle estremità della parte locale; per esempio. john.smith(comment)@example.com e (comment)[email protected] sono entrambi equivalenti a [email protected].

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

Una stringa quotata può esistere come entità separata da punto 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"[email protected] o "abcdefghixyz"@example.com sono consentiti.Al contrario, abc"defghi"[email protected] non lo è; abc\"def\"[email protected]). Tuttavia, le stringhe e i caratteri citati non sono comunemente usati. RFC 5321 avverte anche che "un host che si aspetta di ricevere mail DOVREBBE evitare di definire caselle di posta in cui la parte locale richiede (o utilizza) il modulo di stringa quotata".

La parte locale postmasterè trattata in modo speciale, non fa distinzione tra maiuscole e minuscole e deve essere inoltrata all'amministratore dell'amministratore del dominio. Tecnicamente tutte le altre parti locali sono sensibili al maiuscolo/minuscolo, pertanto [email protected] e [email protected] specificano caselle di posta diverse; tuttavia, molte organizzazioni trattano lettere maiuscole e minuscole come equivalenti.

Nonostante la vasta gamma di caratteri speciali che sono tecnicamente validi; organizzazioni, servizi di posta, server di posta e 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 (.), underscore (_) e trattino (-). Un consiglio comune è di evitare l'uso di alcuni caratteri speciali per evitare il rischio di e-mail rifiutate.

3
Yash Patel

Per motivi di semplicità, sanitizzo l'invio rimuovendo tutto il testo tra virgolette e quelle associate alle virgolette circostanti prima della convalida, inserendo il kibosh nelle comunicazioni di posta elettronica in base a ciò che non è consentito. Solo perché qualcuno può avere il John .. "The * $ hizzle * Bizzle" .. L'indirizzo [email protected] non significa che devo permetterlo nel mio sistema. Viviamo nel futuro, dove forse ci vuole meno tempo per ottenere un indirizzo email gratuito piuttosto che fare un buon lavoro pulendo il sedere. E non è come se i criteri di posta elettronica non sono intonacati proprio accanto all'input dicendo ciò che è e non è permesso.

Sanitizzo anche ciò che non è specificamente consentito da vari RFC dopo la rimozione del materiale quotato. L'elenco di personaggi e pattern specificamente non consentiti sembra essere un elenco molto più breve da testare.

Non consentito:

    local part starts with a period ( [email protected] )
    local part ends with a period   ( [email protected] )
    two or more periods in series   ( [email protected] )
    &’`*|/                          ( some&thing`[email protected] )
    more than one @                 ( [email protected]@Host.com )
    :%                              ( mo:characters%mo:[email protected] )

Nell'esempio riportato:

John.."The*$hizzle*Bizzle"[email protected] --> [email protected]

[email protected] --> [email protected]

L'invio di un messaggio e-mail di conferma al risultato rimanente al tentativo di aggiungere o modificare l'indirizzo e-mail è un buon modo per vedere se il codice può gestire l'indirizzo e-mail inviato. Se l'e-mail supera la convalida dopo il numero di cicli di disinfezione necessari, quindi attivare la conferma. Se una richiesta ritorna dal link di conferma, la nuova email può essere spostata dallo stato || temporaneo || stato di purgatorio o archiviazione per diventare una vera e-mail memorizzata di prima classe.

Se si desidera essere premurosi, è possibile inviare una notifica di errore di modifica dell'indirizzo e-mail o di successo al vecchio indirizzo e-mail. Le configurazioni di account non confermate potrebbero cadere fuori dal sistema come tentativi falliti interamente dopo un ragionevole lasso di tempo.

Non permetto l'e-mail stinkhole sul mio sistema, forse questo è solo buttare via soldi. Ma, il 99,9% delle volte le persone fanno la cosa giusta e hanno una e-mail che non spinge i limiti di conformità al limite utilizzando gli scenari di compatibilità caso Edge. Fai attenzione alle espressioni regolari DDoS, questo è un posto dove puoi metterti nei guai. E questo è legato alla terza cosa che faccio, metto un limite su quanto a lungo sono disposto a elaborare una qualsiasi email. Se ha bisogno di rallentare la mia macchina per essere convalidata - non sta superando la mia logica dell'endpoint API in entrata.

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

0
BradChesney79

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

Solo osservando una delle diverse possibili regole di inclusione per il testo consentito nella parte "testo del 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 utilizzati in [] letterale di dominio, per formare una coppia quotata \ e il carattere di spazio bianco (% d32). Con questo viene utilizzato l'intero intervallo 32-126 (decimale). Un requisito simile appare come "qtext" e "ctext". Sono ammessi/utilizzati anche molti caratteri di controllo. Una lista di tali caratteri di controllo appare nella pagina 31 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 i caratteri di controllo sono ammessi 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 una tale regola di inclusione è quindi "semplicemente troppo ampia". Oppure, in un altro senso, la regola prevista è "troppo semplicistica".

0
user2350426