Quels caractères sont autorisés dans une adresse email?

Question

Je ne demande pas à propos de la validation complète du courrier électronique.

Je veux juste savoir quels sont les caractères autorisés dans user-name et server parties de l'adresse e-mail. Cela peut être simpliste à l'extrême, peut-être que les adresses électroniques peuvent prendre d'autres formes, mais je m'en fiche. Je ne parle que de ce simple formulaire: user-name@server (par exemple, wild.wezyr@best-server-ever.com) et des caractères autorisés dans les deux parties.

Anton Gogolev · Accepted Answer

Voir RFC 5322: Format du message Internet et, dans une moindre mesure, RFC 5321: Protocole de transfert de courrier simple .

RFC 822 couvre également les adresses e-mail, mais traite principalement de sa structure:

 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

Et comme d’habitude, Wikipedia a une bonne réputation article sur les adresses e-mail :

La partie locale de l'adresse e-mail peut utiliser n'importe lequel de ces caractères ASCII:

lettres latines majuscules et minuscules A à Z et a à z;

chiffres 0 à 9;

caractères spéciaux !#$%&'*+-/=?^_`{|}~;

point ., à condition que ce ne soit ni le premier ni le dernier caractère, sauf entre guillemets, et qu'il n'apparaisse pas consécutivement à moins qu'il ne soit entre guillemets (par exemple, John..Doe@example.com n'est pas autorisé mais "John..Doe"@example.com est autorisé) ;

les caractères espace et "(),:;<>@[\] sont autorisés avec des restrictions (ils ne sont autorisés qu'à l'intérieur d'une chaîne de caractères, comme décrit dans le paragraphe ci-dessous, et une barre oblique inversée ou une double guillemet doit en outre être précédée d'une barre oblique inversée);

les commentaires sont autorisés avec des parenthèses aux deux extrémités de la partie locale; par exemple. john.smith(comment)@example.com et (comment)john.smith@example.com sont équivalents à john.smith@example.com.

En plus de ASCII caractères, à partir de 2012 vous pouvez utiliser international caractères ci-dessus U+007F, codé en UTF-8 comme décrit dans le Spécification RFC 6532 et expliqué sur Wikipedia . Notez qu'à partir de 2019, ces normes sont toujours marquées comme étant proposées, mais leur déploiement est lent. Les modifications apportées à cette spécification ont essentiellement ajouté des caractères internationaux sous forme de caractères alphanumériques valides (atext) sans affecter les règles applicables aux caractères spéciaux autorisés et restreints tels que !# et @:.

Pour la validation, voir tilisation d'une expression régulière pour valider une adresse électronique .

La partie domain est définie comme suit :

Les normes Internet (demande de commentaires) pour les protocoles stipulent que les étiquettes de nom d’hôte de composant ne peuvent contenir que les lettres ASCII a à z (sans tenir compte de la casse), les chiffres 0 à 9 et au trait d'union (-). La spécification d'origine des noms d'hôte dans RFC 952 , stipulait que les étiquettes ne pouvaient pas commencer par un chiffre ni par un trait d'union et ne devaient pas se terminer par un trait d'union. Cependant, une spécification ultérieure ( RFC 112 ) permettait aux étiquettes de nom d'hôte de commencer par des chiffres. Aucun autre symbole, caractère de ponctuation ou espace n'est autorisé.

kenorb · Answer

Le format de l'adresse de messagerie est le suivant: _local-part@domain-part_ (max. 64 @ 255 caractères, pas plus de 256 au total).

Les _local-part_ et _domain-part_ peuvent avoir un ensemble différent de caractères autorisés, mais ce n'est pas tout, car il y a plus de règles.

En général, la partie locale peut avoir ces caractères ASCII:

lettres latines minuscules: abcdefghijklmnopqrstuvwxyz,
lettres latines majuscules: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
chiffres: _0123456789_,
caractères spéciaux: _!#$%&'*+-/=?^_`{|}~_,
point: _._ (pas le premier ni le dernier caractère ni répété sauf si cité),
des ponctuations d'espace telles que: "(),:;<>@[\] (avec certaines restrictions),
commentaires: _()_ (sont autorisés entre parenthèses, par exemple _(comment)john.smith@example.com_).

Partie de domaine:

lettres latines minuscules: abcdefghijklmnopqrstuvwxyz,
lettres latines majuscules: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
chiffres: _0123456789_,
trait d'union: _-_ (pas le premier ou le dernier caractère),
peut contenir une adresse IP entourée de crochets: _jsmith@[192.168.2.1]_ ou _jsmith@[IPv6:2001:db8::1]_.

Ces adresses électroniques sont valides:

_prettyandsimple@example.com_
_very.common@example.com_
_disposable.style.email.with+symbol@example.com_
_other.email-with-dash@example.com_
_x@example.com_ (partie locale d'une lettre)
_"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_ (nom de domaine local sans domaine de premier niveau)
_#!$%&'*+-/=?^_`{}|~@example.org_
"()<>[]:,;@\"!#$%&'-/=?^_`{}| ~.a"@example.org
_" "@example.org_ (espace entre les guillemets)
_example@localhost_ (envoyé de localhost)
_example@s.solutions_ (voir le Liste des domaines de premier niveau Internet )
_user@com_
_user@localserver_
_user@[IPv6:2001:db8::1]_

Et ces exemples d'invalide:

_Abc.example.com_ (pas de _@_ caractère)
_A@b@c@example.com_ (un seul _@_ est autorisé en dehors des guillemets)
a"b(c)d,e:f;gi[j\k]l@example.com (aucun des caractères spéciaux de cette partie locale n'est autorisé en dehors des guillemets)
_just"not"right@example.com_ (les chaînes entre guillemets doivent être séparées par des points ou le seul élément constituant la partie locale)
_this is"not\allowed@example.com_ (les espaces, les guillemets et les barres obliques inverses ne peuvent exister que dans les chaînes entre guillemets et précédées d'une barre oblique inversée)
_this\ still\"not\allowed@example.com_ (même en cas d'échappement (précédé d'une barre oblique inverse), les espaces, les guillemets et les barres obliques inverses doivent toujours être entre guillemets)
_john..doe@example.com_ (double point avant _@_); (avec mise en garde: Gmail laisse passer cela)
_john.doe@example..com_ (double point après _@_)
une adresse valide avec un espace de début
une adresse valide avec un espace de fin

Source: adresse électronique sur Wikipedia

regex RFC2822 de Perl pour valider les emails:

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

La regexp complète pour les adresses RFC2822 était un simple 3,7k.

Voir aussi: Analyseur d'adresses électroniques RFC 822 en PHP .

Les définitions officielles des adresses électroniques se trouvent dans:

RFC 5322 (sections 3.2.3 et 3.4.1, obsolètes RFC 2822), RFC 5321, RFC 3696,
RFC 6531 (caractères autorisés).

Apparenté, relié, connexe:

Le vrai pouvoir des expressions régulières

Mike Weller · Answer

Wikipedia a un bon article à ce sujet , et la spécification officielle est ici . De Wikipdia:

La partie locale de l'adresse de messagerie peut utiliser n'importe lequel de ces caractères ASCII:

Lettres anglais majuscules et minuscules (a-z, A-Z)

Chiffres 0 à 9

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

Personnage . (point, point, point final) à condition qu'il ne s'agisse pas du premier ou du dernier caractère, et à condition également qu'il n'apparaisse pas deux ou plusieurs fois de suite.

De plus, les guillemets (par exemple: "John Doe" @ example.com) sont autorisés, permettant ainsi des caractères qui seraient autrement interdits, mais ils n'apparaissent pas dans les pratiques courantes. La RFC 5321 avertit également qu '"un hôte qui s'attend à recevoir du courrier DEVRAIT éviter de définir des boîtes aux lettres lorsque la partie locale nécessite (ou utilise) la forme de chaîne entre guillemets".

Angel Koh · Answer

Google fait une chose intéressante avec leurs adresses gmail.com. Les adresses gmail.com autorisent uniquement les lettres (a-z), les chiffres et les points (qui sont ignorés).

par exemple, pikachu@gmail.com est identique à pi.kachu@gmail.com et les deux adresses e-mail seront envoyées à la même boîte aux lettres. PIKACHU@gmail.com est également livré à la même boîte aux lettres.

Donc, pour répondre à la question, cela dépend parfois de l'implémenteur de la quantité de normes RFC à suivre. Le style d'adresse gmail.com de Google est compatible avec les normes. Ils le font de cette manière pour éviter toute confusion lorsque différentes personnes prendraient des adresses électroniques similaires, par exemple.

*** 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)

Le lien wikipedia est une bonne référence sur ce que les adresses électroniques permettent généralement. http://en.wikipedia.org/wiki/Email_address

Vladimir · Answer

Vous pouvez commencer à partir de article de wikipedia :

Lettres anglais majuscules et minuscules (a-z, A-Z)
Chiffres 0 à 9
Personnages ! # $% & '* + -/=? ^ _ `{| } ~
Personnage . (point, point, point final) à condition qu'il ne s'agisse pas du premier ou du dernier caractère, et à condition également qu'il n'apparaisse pas deux ou plusieurs fois de suite.

ThinkingStiff · Answer

Nom:

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

Serveur:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

Richard Maxwell · Answer

Recherchez @ et., Puis envoyez un courrier électronique à vérifier.

Je ne peux toujours pas utiliser mon adresse électronique .name sur 20% des sites Internet car quelqu'un a foiré la validation de leur adresse électronique ou parce qu'elle est antérieure à la validité des nouvelles adresses.

Mac · Answer

La réponse acceptée fait référence à un article de Wikipedia lorsqu’on discute de la partie locale valide d’une adresse électronique, mais Wikipedia n’est pas une autorité en la matière.

IETF RFC 3696 est une autorité à ce sujet et doit être consulté à la section 3. Restrictions sur les adresses électroniques à la page 5:

Les adresses électroniques contemporaines consistent en une "partie locale" séparée d'une "partie de domaine" (un nom de domaine complet) par un at-sign ("@"). La syntaxe de la partie domaine correspond à celle de la section précédente. Les préoccupations identifiées dans cette section concernant le filtrage et les listes de noms s'appliquent également aux noms de domaine utilisés dans un contexte de courrier électronique. Le nom de domaine peut également être remplacé par une adresse IP entre crochets, mais cette forme est vivement déconseillée, sauf à des fins de test et de dépannage.

La partie locale peut apparaître en utilisant les conventions de citation décrites ci-dessous. Les formulaires cités sont rarement utilisés dans la pratique, mais sont nécessaires à des fins légitimes. Par conséquent, ils ne doivent pas être rejetés dans les routines de filtrage, mais doivent plutôt être transmis au système de messagerie pour évaluation par l'hôte de destination.

La règle exacte est que tout caractère ASCII, y compris les caractères de contrôle, peut apparaître entre guillemets ou entre guillemets. Lorsque la citation est nécessaire, la barre oblique inversée est utilisée pour citer le caractère suivant. Par exemple
 Abc\@def@example.com 
est une forme valide d'adresse email. Des espaces vides peuvent également apparaître, comme dans
 Fred\ Bloggs@example.com 
La barre oblique inversée peut également être utilisée pour se citer, par exemple,
 Joe.\Blow@example.com 
Outre les guillemets utilisant la barre oblique inversée, vous pouvez également utiliser des guillemets classiques pour entourer les chaînes. Par exemple
 "Abc@def"@example.com "Fred Bloggs"@example.com 
sont des formes alternatives des deux premiers exemples ci-dessus. Les formulaires cités sont rarement recommandés et sont rares dans la pratique, mais, comme indiqué ci-dessus, ils doivent être pris en charge par les applications qui traitent des adresses électroniques. En particulier, les formulaires cités apparaissent souvent dans le contexte d'adresses associées à des transitions à partir d'autres systèmes et contextes; ces exigences transitoires existent toujours et, puisqu'un système acceptant une adresse électronique fournie par l'utilisateur ne peut pas "savoir" si cette adresse est associée à un système hérité, les formulaires d'adresse doivent être acceptés et passés dans l'environnement de messagerie.

Sans guillemets, les parties locales peuvent être constituées de n’importe quelle combinaison de
caractères alphabétiques, chiffres ou l'un des caractères spéciaux
 ! # $ % & ' * + - / = ? ^ _ ` . { | } ~ 
period (".") peut également apparaître, mais ne peut pas être utilisé pour commencer ou terminer la partie locale, pas plus que deux périodes consécutives. Autrement dit, tout caractère graphique ASCII graphique autre que le signe @, la barre oblique inverse, les guillemets doubles, les virgules ou les crochets peut apparaître sans guillemets. Si l'un de ces caractères exclus doit apparaître, vous devez le citer. Des formes telles que
 user+mailbox@example.com customer/department=shipping@example.com $A12345@example.com !def!xyz%abc@example.com _somename@example.com 
sont valides et sont vus assez régulièrement, mais n’importe lequel des caractères énumérés ci-dessus est autorisé.

Comme d'autres l'ont fait, je soumets une expression régulière qui fonctionne à la fois pour PHP et JavaScript afin de valider les adresses électroniques:

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

Luke Madhanga · Answer

Une bonne lecture sur le matière .

Extrait:

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

Michael JAMES · Answer

La réponse courte est qu'il y a 2 réponses. Il existe une norme pour ce que vous devez faire. c.-à-d. un comportement sage qui vous évitera des ennuis. Il existe une autre norme (beaucoup plus large) pour le comportement que vous devez accepter sans créer de problèmes. Cette dualité fonctionne pour l'envoi et l'acceptation de courrier électronique, mais a une large application dans la vie.

Pour un bon guide pour les adresses que vous créez; voir: http://www.remote.org/jochen/mail/info/chars.html

Pour filtrer les courriels valides, transmettez simplement tout ce qui est suffisamment compréhensible pour passer à l’étape suivante. Ou commencez à lire un tas de RFC, attention, soyez des dragons.

Yash Patel · Answer

Comme on peut le trouver dans ce lien Wikipedia

La partie locale de l'adresse e-mail peut utiliser n'importe lequel de ces caractères ASCII:

lettres latines majuscules et minuscules A à Z et a à z;

chiffres 0 à 9;

caractères spéciaux !#$%&'*+-/=?^_`{|}~;

point ., à condition que ce ne soit ni le premier ni le dernier caractère, sauf entre guillemets, et qu'il n'apparaisse pas consécutivement à moins qu'il ne soit entre guillemets (par exemple, John..Doe@example.com n'est pas autorisé mais "John..Doe"@example.com est autorisé) ;

les caractères espace et "(),:;<>@[\] sont autorisés avec des restrictions (ils ne sont autorisés qu'à l'intérieur d'une chaîne de caractères, comme décrit dans le paragraphe ci-dessous, et une barre oblique inversée ou une double guillemet doit en outre être précédée d'une barre oblique inversée);

les commentaires sont autorisés avec des parenthèses aux deux extrémités de la partie locale; par exemple. john.smith(comment)@example.com et (comment)john.smith@example.com sont équivalents à john.smith@example.com.

En plus des ASCII ci-dessus, les caractères internationaux au-dessus de U + 007F, codés en UTF-8, sont autorisés par RFC 6531 , bien que les systèmes de messagerie puissent limiter les caractères à utiliser lorsque assigner des parties locales.

Une chaîne entre guillemets peut exister en tant qu'entité séparée par des points dans la partie locale, ou peut exister lorsque les guillemets les plus externes sont les caractères les plus externes de la partie locale (par exemple, abc."defghi".xyz@example.com ou "abcdefghixyz"@example.com sont autorisés. Inversement, abc"defghi"xyz@example.com n'est pas, ni abc\"def\"ghi@example.com). Les chaînes et les caractères cités ne sont cependant pas couramment utilisés. RFC 5321 prévient également qu '"un hôte qui s'attend à recevoir du courrier DEVRAIT éviter de définir des boîtes aux lettres lorsque la partie locale nécessite (ou utilise) la forme de chaîne entre guillemets".

La partie locale postmaster est traitée de manière spéciale: elle est sensible à la casse et doit être transmise à l'administrateur de messagerie du domaine. Techniquement, toutes les autres parties locales sont sensibles à la casse. Par conséquent, jsmith@example.com et JSmith@example.com spécifient des boîtes aux lettres différentes. Cependant, de nombreuses organisations considèrent les lettres majuscules et minuscules comme équivalentes.

Malgré le large éventail de caractères spéciaux techniquement valables; Les organisations, les services de messagerie, les serveurs de messagerie et les clients de messagerie ne les acceptent souvent pas tous en pratique. Par exemple, Windows Live Hotmail autorise uniquement la création d’adresses de messagerie utilisant des caractères alphanumériques, des points (.), un trait de soulignement (_) et un trait d’union (-). Il est généralement conseillé d'éviter d'utiliser certains caractères spéciaux pour éviter le risque de rejet des courriels.

BradChesney79 · Answer

Par souci de simplicité, je désinfecte la soumission en supprimant tout le texte entre guillemets doubles et ceux associés entourant les guillemets avant validation, en plaçant le kibosh sur les soumissions d'adresses électroniques en fonction de ce qui est interdit. Ce n'est pas parce que quelqu'un peut avoir le nom de John ... "L'adresse * $ hizzle * Bizzle" .. Doe@w Whatever.com que je dois le permettre dans mon système. Nous vivons dans le futur où il faut peut-être moins de temps pour obtenir une adresse e-mail gratuite que pour bien essuyer ses fesses. Et ce n'est pas comme si les critères de courrier électronique n'étaient pas affichés juste à côté de l'entrée pour indiquer ce qui est autorisé ou non.

Je désinfecte également ce qui est spécifiquement interdit par diverses RFC après que le contenu cité ait été retiré. La liste des caractères et des motifs spécifiquement interdits semble être une liste beaucoup plus courte à tester.

Interdit:

 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 )

Dans l'exemple donné:

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

L'envoi d'un e-mail de confirmation au résultat restant lors d'une tentative d'ajout ou de modification d'adresse e-mail est un bon moyen de voir si votre code peut gérer l'adresse e-mail soumise. Si le courrier électronique réussit la validation après autant de cycles de désinfection que nécessaire, déclenchez cette confirmation. Si une demande revient du lien de confirmation, le nouvel e-mail peut alors être déplacé du statut de conservation || temporaire || au purgatoire ou devenir un véritable e-mail stocké de première classe.

Une notification d'échec ou de succès de changement d'adresse e-mail peut être envoyée à l'ancienne adresse e-mail si vous souhaitez être prévenant. Les configurations de compte non confirmées peuvent tomber en dehors du système car les tentatives ont échoué après un laps de temps raisonnable.

Je n'autorise pas les courriels stinkhole sur mon système, c'est peut-être simplement jeter de l'argent. Cependant, 99,9% des personnes font ce qui est bien et ont un courrier électronique qui ne dépasse pas les limites de conformité à l'aide de scénarios de compatibilité avec les cas Edge. Faites attention aux DDoS regex, c'est un endroit où vous pouvez avoir des ennuis. Et ceci est lié à la troisième chose que je fais, je mets une limite à combien de temps je suis prêt à traiter n'importe quel email. S'il faut ralentir ma machine pour qu'elle soit validée, cela ne va pas au-delà de la logique de point de terminaison de mon API de données entrantes.

Edit: Cette réponse a continué à être critiqué pour être "mauvais", et peut-être le méritait-il. Peut-être que c'est toujours mauvais, peut-être pas.

user2350426 · Answer

La réponse est (presque) ALL (ASCII 7 bits).
Si les règles d'inclusion sont "... autorisées sous certaines conditions/aucune/aucune ..."

En regardant simplement l’une des règles d’inclusion possibles pour le texte autorisé dans la partie "texte du domaine" dans RFC 5322 , en haut de la page 17, on trouve:

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

les trois seuls caractères manquants dans cette description sont utilisés dans le domaine littéral [], pour former une paire entre guillemets \, et le caractère d'espace blanc (% d32). Avec cela, la plage entière 32-126 (décimale) est utilisée. Une exigence similaire apparaît comme "qtext" et "ctext". De nombreux caractères de contrôle sont également autorisés/utilisés. Une liste de tels caractères de contrôle apparaît à la page 31 section 4.1 de la RFC 5322 sous la forme 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

Tous ces caractères de contrôle sont autorisés comme indiqué au début de la section 3.5:

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

Et une telle règle d'inclusion est donc "tout simplement trop large". Ou, dans un autre sens, la règle attendue est "trop simpliste".