Adresse e-mail - Email address

Une adresse e-mail identifie une boîte e - mail à laquelle les messages sont livrés. Alors que les premiers systèmes de messagerie utilisaient une variété de formats pour l'adressage, aujourd'hui, les adresses e-mail suivent un ensemble de règles spécifiques normalisées à l'origine par l' Internet Engineering Task Force (IETF) dans les années 1980, et mises à jour par les RFC 5322 et 6854 . Le terme adresse e-mail dans cet article fait référence à addr-spec dans la RFC 5322, pas à l' adresse ou à la boîte aux lettres ; c'est-à-dire une adresse brute sans nom d'affichage .

Une adresse e-mail, telle que john.smith@example.com , est composée d'une partie locale , du symbole @, et d'un domaine , qui peut être un nom de domaine ou une adresse IP entre crochets. Bien que la norme exige que la partie locale soit sensible à la casse, elle demande également que les hôtes de réception remettent les messages indépendamment de la casse, par exemple, que le système de messagerie du domaine example.com traite John.Smith comme l'équivalent de john.smith ; certains systèmes de messagerie les traitent même comme équivalents à johnsmith . Les systèmes de messagerie limitent souvent le choix du nom des utilisateurs à un sous-ensemble des caractères techniquement autorisés.

Avec l'introduction des noms de domaine internationalisés , les efforts progressent pour autoriser les caractères non ASCII dans les adresses e-mail.

Transport de messages

Une adresse e-mail se compose de deux parties, une partie locale et un domaine ; si le domaine est un nom de domaine plutôt qu'une adresse IP, le client SMTP utilise le nom de domaine pour rechercher l'adresse IP de l'échange de courrier. Le format général d'une adresse e-mail est local-part @ domain , par exemple , jsmith@[192.168.1.2], jsmith@example.com . Le client SMTP transmet le message à l'échange de messagerie, qui peut le transmettre à un autre échange de messagerie jusqu'à ce qu'il arrive finalement à l'hôte du système de messagerie du destinataire.

La transmission de courrier électronique depuis l'ordinateur de l'auteur et entre les hôtes de messagerie sur Internet utilise le protocole SMTP ( Simple Mail Transfer Protocol ), défini dans les RFC 5321 et 5322 , et des extensions telles que RFC 6531. Les boîtes aux lettres sont accessibles et gérées par des applications sur des ordinateurs personnels, des appareils mobiles ou des sites de messagerie Web, en utilisant le protocole SMTP et soit le protocole de bureau de poste (POP) soit le protocole d'accès aux messages Internet (IMAP).

Lors de la transmission d'e-mails , les agents d'utilisateur de messagerie (MUA) et les agents de transfert de messagerie (MTA) utilisent le système de nom de domaine (DNS) pour rechercher un enregistrement de ressource (RR) pour le domaine du destinataire. Un enregistrement de ressource d'échangeur de messagerie ( enregistrement MX ) contient le nom du serveur de messagerie du destinataire. En l'absence d'enregistrement MX, un enregistrement d'adresse ( A ou AAAA ) spécifie directement l'hôte de messagerie.

La partie locale d'une adresse e-mail n'a aucune importance pour les systèmes de relais de messagerie intermédiaires autres que l'hôte de boîte aux lettres final. Les expéditeurs de courrier électronique et les systèmes de relais intermédiaires ne doivent pas supposer qu'il est insensible à la casse, car l'hôte de la boîte aux lettres finale peut ou non le traiter comme tel. Une seule boîte aux lettres peut recevoir des e-mails pour plusieurs adresses e-mail, si elle est configurée par l'administrateur. À l'inverse, une seule adresse e-mail peut être l'alias d'une liste de distribution vers de nombreuses boîtes aux lettres. Les alias de messagerie , les listes de diffusion électronique , les sous-adresses et les adresses fourre-tout , ces dernières étant des boîtes aux lettres qui reçoivent des messages quelle que soit la partie locale, sont des modèles courants pour atteindre divers objectifs de livraison.

Les adresses trouvées dans les champs d'en-tête d'un message électronique ne sont pas directement utilisées par les échanges de courrier pour délivrer le message. Un message électronique contient également une enveloppe de message qui contient les informations pour le routage du courrier. Alors que les adresses d'enveloppe et d'en-tête peuvent être identiques, les adresses e-mail falsifiées - également appelées adresses e-mail falsifiées - sont souvent détectées dans le spam , le phishing et de nombreuses autres escroqueries sur Internet. Cela a conduit à plusieurs initiatives qui visent à rendre ces falsifications d'e-mails frauduleux plus faciles à repérer.

Syntaxe

Le format d'une adresse e-mail est local-part@domain , où la partie locale peut faire jusqu'à 64 octets de long et le domaine peut avoir un maximum de 255 octets. Les définitions formelles se trouvent dans la RFC 5322 (sections 3.2.3 et 3.4.1) et la RFC 5321—avec une forme plus lisible donnée dans la RFC 3696 informative et les errata associés.

Une adresse e-mail peut également avoir un nom d'affichage associé pour le destinataire, qui précède la spécification de l'adresse, maintenant entouré de crochets angulaires, par exemple : John Smith <john.smith@example.org> .

Les formes antérieures d' adresses e - mail pour d'autres réseaux qu'Internet comprenaient d'autres notations, telles que celle requise par X.400 et la notation UUCP bang path , dans laquelle l'adresse était donnée sous la forme d'une séquence d'ordinateurs à travers lesquels le message devait être relayé. Cela a été largement utilisé pendant plusieurs années, mais a été remplacé par les normes Internet promulguées par l' Internet Engineering Task Force (IETF).

Local-partie

La partie locale de l'adresse e-mail peut être sans guillemets ou peut être placée entre guillemets.

S'il n'est pas entre guillemets, il peut utiliser n'importe lequel de ces caractères ASCII :

lettres latines majuscules et minuscules Aà Zet aàz
chiffres 0à9
caractères imprimables !#$%&'*+-/=?^_`{|}~
point ., à condition qu'il ne s'agisse pas du premier ou du dernier caractère et à condition également qu'il n'apparaisse pas consécutivement (par exemple, John..Doe@example.comn'est pas autorisé).

S'il est cité, il peut contenir un espace, une tabulation horizontale (HT), tout graphique ASCII à l'exception d'une barre oblique inverse et d'un guillemet et une paire de guillemets composée d'une barre oblique inverse suivie de HT, d'un espace ou de tout graphique ASCII ; il peut également être divisé entre les lignes partout où HT ou Espace apparaît. Contrairement aux parties locales sans guillemets, les adresses ".John.Doe"@example.com, "John.Doe."@example.comet "John..Doe"@example.comsont autorisées.

La longueur totale maximale de la partie locale d'une adresse e-mail est de 64 octets.

Notez que certains serveurs de messagerie prennent en charge la reconnaissance générique des parties locales, généralement les caractères suivant un plus et moins souvent les caractères suivant un moins, donc fred+bah@domain et fred+foo@domain peuvent se retrouver dans la même boîte de réception que fred+@domain ou même comme fred@domain. Cela peut être utile pour marquer les e-mails pour le tri (voir ci-dessous) et pour le contrôle du spam. Les accolades {et }sont également utilisées de cette manière, bien que moins souvent.

l'espace et les caractères spéciaux "(),:;<>@[\]sont autorisés avec des restrictions (ils ne sont autorisés qu'à l'intérieur d'une chaîne entre guillemets, comme décrit dans le paragraphe ci-dessous, et dans cette chaîne entre guillemets, toute barre oblique inverse ou guillemet double doit être précédée d'une barre oblique inverse) ;
les commentaires sont autorisés avec des parenthèses à chaque extrémité de la partie locale ; par exemple, john.smith(comment)@example.comet (comment)john.smith@example.comsont tous deux équivalents à john.smith@example.com.

En plus des caractères ASCII ci-dessus, les caractères internationaux supérieurs à U+007F, codés en UTF-8 , sont autorisés par la RFC 6531, bien que même les systèmes de messagerie qui prennent en charge SMTPUTF8 et 8BITMIME puissent restreindre les caractères à utiliser lors de l'attribution de parties locales.

Une partie locale est soit une chaîne Dot, soit une chaîne Quoted ; ce ne peut pas être une combinaison. Les chaînes et les caractères entre guillemets, cependant, ne sont pas couramment utilisés. 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 où la partie locale requiert (ou utilise) la forme de chaîne entre guillemets".

La partie locale postmasterest traitée spécialement, elle est insensible à la casse et doit être transmise à l'administrateur de messagerie du domaine. Techniquement, toutes les autres parties locales sont donc sensibles à la casse jsmith@example.comet JSmith@example.comspécifient des boîtes aux lettres différentes ; cependant, de nombreuses organisations traitent les lettres majuscules et minuscules comme équivalentes. En effet, la RFC 5321 avertit qu'"un hôte qui s'attend à recevoir du courrier DEVRAIT éviter de définir des boîtes aux lettres où ... la partie locale est sensible à la casse".

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 dans la pratique. Par exemple, Windows Live Hotmail permet uniquement la création d'adresses e-mail utilisant des caractères alphanumériques, des points ( .), des traits de soulignement ( _) et des tirets ( -). Le conseil commun est d'éviter d'utiliser certains caractères spéciaux pour éviter le risque de rejets d'e-mails.

Domaine

La partie nom de domaine d'une adresse e-mail doit être conforme à des directives strictes : elle doit correspondre aux exigences d'un nom d'hôte , une liste d' étiquettes DNS séparées par des points , chaque étiquette étant limitée à une longueur de 63 caractères et composée de :

lettres latines majuscules et minuscules Aà Zet aà z;
chiffres 0à 9, à condition que les noms de domaine de premier niveau ne soient pas entièrement numériques ;
trait d'union -, à condition qu'il ne s'agisse pas du premier ou du dernier caractère.

Cette règle est connue sous le nom de règle LDH (lettres, chiffres, tiret). De plus, le domaine peut être un littéral d' adresse IP , entouré de crochets [], comme jsmith@[192.168.2.1]ou jsmith@[IPv6:2001:db8::1], bien que cela soit rarement vu, sauf dans le spam par courrier électronique . Les noms de domaine internationalisés (qui sont codés pour se conformer aux exigences d'un nom d'hôte ) permettent la présentation de domaines non ASCII. Dans les systèmes de messagerie conformes aux RFC 6531 et RFC 6532, une adresse e-mail peut être codée en UTF-8 , à la fois une partie locale et un nom de domaine.

Les commentaires sont autorisés dans le domaine ainsi que dans la partie locale ; par exemple, john.smith@(comment)example.comet john.smith@example.com(comment)sont équivalents à john.smith@example.com.

Domaines réservés

La RFC 2606 spécifie que certains domaines, par exemple ceux destinés à la documentation et aux tests, ne devraient pas être résolus et qu'en conséquence le courrier adressé aux boîtes aux lettres qu'ils contiennent et leurs sous-domaines devraient être non livrables. Il est à noter pour les e-mails : example , invalid , example.com , example.net et example.org .

Exemples

Adresses e-mail valides: simple@example.com; very.common@example.com; disposable.style.email.with+symbol@example.com; other.email-with-hyphen@example.com; fully-qualified-domain@example.com; user.name+tag+sorting@example.com(peut aller dans la user.name@example.comboîte de réception en fonction du serveur de messagerie); x@example.com (partie locale d'une lettre); example-indeed@strange-example.com; test/test@test.com (les barres obliques sont un caractère imprimable et autorisé); admin@mailserver1(nom de domaine local sans TLD , bien que l'ICANN décourage fortement les adresses e-mail sans point); example@s.example(voir la Liste des domaines Internet de premier niveau ); " "@example.org (espace entre les guillemets); "john..doe"@example.org (double point cité); mailhost!username@example.org (route hôte bangifiée utilisée pour les e-mails uucp); user%example.com@example.org (% d'itinéraire de courrier échappé vers user@example.com via example.org); user-@example.org (partie locale se terminant par un caractère non alphanumérique de la liste des caractères imprimables autorisés)

Adresses e-mail invalides: 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;g<h>i[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 des chaînes entre guillemets et précédés d'une barre oblique inverse); this\ still\"not\\allowed@example.com (même s'ils sont échappés (précédés d'une barre oblique inverse), les espaces, les guillemets et les barres obliques inverses doivent toujours être contenus par des guillemets); 1234567890123456789012345678901234567890123456789012345678901234+x@example.com (la partie locale fait plus de 64 caractères); i_like_underscore@but_its_not_allowed_in_this_part.example.com (Le soulignement n'est pas autorisé dans la partie domaine); QA[icon]CHOCOLATE[icon]@test.com (caractères icônes)

Sémantique commune des parties locales

Selon la RFC 5321 2.3.11 Mailbox and Address, "... la partie locale DOIT être interprétée et assignée sémantiquement uniquement par l'hôte spécifié dans le domaine de l'adresse." Cela signifie qu'aucune hypothèse ne peut être faite sur la signification de la partie locale d'un autre serveur de messagerie. Cela dépend entièrement de la configuration du serveur de messagerie.

Normalisation de la partie locale

L'interprétation de la partie locale d'une adresse e-mail dépend des conventions et des politiques mises en œuvre dans le serveur de messagerie. Par exemple, la sensibilité à la casse peut distinguer les boîtes aux lettres ne différant que par la capitalisation des caractères de la partie locale, bien que ce ne soit pas très courant. Gmail ignore tous les points de la partie locale d'une adresse @gmail.com afin de déterminer l'identité du compte.

Sous-adressage

Certains services de messagerie prennent en charge une balise incluse dans la partie locale, de sorte que l'adresse est un alias vers un préfixe de la partie locale. Par exemple, l'adresse joeuser+tag@example.com désigne la même adresse de livraison que joeuser@example.com . RFC 5233, fait référence à cette convention comme sous-adressage , mais il est également connu comme en plus d' adressage , marqué d' adressage ou extensions de courrier .

Les adresses de ce formulaire, utilisant divers séparateurs entre le nom de base et la balise, sont prises en charge par plusieurs services de messagerie, notamment Andrew Project (plus), Runbox (plus), Gmail (plus), Rackspace (plus), Yahoo! Mail Plus (trait d'union), iCloud d'Apple (plus), Outlook.com (plus), ProtonMail (plus), Fastmail (plus et adressage de sous-domaine), postale.io (plus), Pobox (plus), MeMail (plus), MMDF (égal), Qmail et Courier Mail Server (trait d'union). Postfix et Exim permettent de configurer un séparateur arbitraire à partir du jeu de caractères légal.

Le texte de la balise peut être utilisée pour appliquer le filtrage, ou pour créer une seule utilisation , ou adresses e - mail jetables .

En pratique, la validation de formulaire de certains sites Web peut rejeter des caractères tels que "+" dans une adresse e-mail - les traitant, à tort, comme des caractères invalides. Cela peut conduire à ce qu'un utilisateur incorrect reçoive un e-mail si le "+" est supprimé silencieusement par un site Web sans aucun message d'avertissement ou d'erreur. Par exemple, un e-mail destiné à l'adresse e-mail saisie par l'utilisateur foo+bar@example.com peut être incorrectement envoyé à foobar@example.com. Dans d'autres cas, une mauvaise expérience utilisateur peut se produire si certaines parties d'un site, comme une page d'inscription d'utilisateur, autorisent le caractère "+" tandis que d'autres parties, comme une page de désabonnement de la liste de diffusion d'un site, ne le font pas.

Validation et vérification

Les adresses e-mail sont souvent demandées en entrée du site Web pour valider l'existence de l'utilisateur. D'autres méthodes de validation sont disponibles, telles que la validation du numéro de téléphone portable, la validation du courrier postal et la validation de la télécopie.

Une adresse e-mail est généralement reconnue comme ayant deux parties jointes par un signe at ( @ ), bien que les spécifications techniques détaillées dans la RFC 822 et les RFC suivantes soient plus étendues.

Les adresses e-mail vérifiées et syntaxiquement correctes ne garantissent pas l'existence d'une boîte e-mail . Ainsi, de nombreux serveurs de messagerie utilisent à tort d'autres techniques et vérifient l'existence de la boîte aux lettres par rapport aux systèmes pertinents tels que le système de noms de domaine pour le domaine ou utilisent la vérification de rappel pour vérifier si la boîte aux lettres existe. La vérification par rappel est une solution imparfaite, car elle peut être désactivée pour éviter une attaque de récupération de répertoire .

Plusieurs techniques de validation peuvent être utilisées pour valider une adresse e-mail d'utilisateur. Par exemple,

Liens de vérification : la validation de l'adresse e-mail est souvent effectuée pour la création de compte sur des sites Web en envoyant un e-mail à l'adresse e-mail fournie par l'utilisateur avec un lien hypertexte temporaire spécial. Dès réception, l'utilisateur ouvre le lien, activant immédiatement le compte. Les adresses e-mail sont également utiles pour envoyer des messages à partir d'un site Web, par exemple, des messages d'utilisateurs, des actions d'utilisateurs, vers la boîte de réception des e-mails.

Normes formelles et informelles : RFC 3696 fournit des conseils spécifiques pour la validation des identifiants Internet, y compris les adresses e-mail. Certains sites Web tentent plutôt d'évaluer la validité des adresses e-mail à l'aide de normes arbitraires, par exemple en rejetant les adresses contenant des caractères valides, tels que + et / , ou en appliquant des limitations de longueur arbitraires. L'internationalisation des adresses e-mail fournit une gamme de caractères beaucoup plus large que celle autorisée par de nombreux algorithmes de validation actuels, tels que tous les caractères Unicode supérieurs à U+0080, codés en UTF-8 .

Outils algorithmiques : les grands sites Web, les expéditeurs de courrier en masse et les spammeurs nécessitent des outils efficaces pour valider les adresses e-mail. De tels outils dépendent d' algorithmes heuristiques et de modèles statistiques .

Réputation de l'expéditeur : la réputation d'un expéditeur de courrier électronique peut être utilisée pour tenter de vérifier si l'expéditeur est digne de confiance ou s'il s'agit d'un spammeur potentiel. Les facteurs qui peuvent être incorporés dans une évaluation de la réputation de l'expéditeur incluent la qualité du contact passé ou du contenu fourni par, et les niveaux d'engagement de l'adresse IP ou de l'adresse e-mail de l'expéditeur.

Vérification basée sur le navigateur : les formulaires HTML5 implémentés dans de nombreux navigateurs permettent de gérer la validation de l'adresse e-mail par le navigateur.

Certaines entreprises proposent des services pour valider une adresse e-mail, souvent à l'aide d'une interface de programmation d'applications , mais rien ne garantit qu'elle fournira des résultats précis.

Internationalisation

L' IETF dirige un groupe de travail technique et normatif consacré aux problèmes d'internationalisation des adresses électroniques, intitulé Internationalized Mail Address (EAI, également connu sous le nom d'IMA, Internationalized Mail Address). Ce groupe a produit les RFC 6530 , 6531 , 6532 et 6533 , et continue de travailler sur d'autres RFC liées à l'EAI.

Le groupe de travail EAI de l'IETF a publié la RFC 6530 « Overview and Framework for Internationalized Email », qui permettait d'utiliser des caractères non ASCII dans les parties locales et le domaine d'une adresse e-mail. La RFC 6530 fournit un e-mail basé sur l' encodage UTF-8 , qui permet le répertoire complet d' Unicode . La RFC 6531 fournit un mécanisme permettant aux serveurs SMTP de négocier la transmission du contenu SMTPUTF8 .

Les concepts EAI de base impliquent l'échange de courrier en UTF-8. Bien que la proposition initiale incluait un mécanisme de déclassement pour les systèmes hérités, celui-ci a maintenant été abandonné. Les serveurs locaux sont responsables de la partie locale de l'adresse, alors que le domaine serait restreint par les règles des noms de domaine internationalisés , bien que toujours transmis en UTF-8. Le serveur de messagerie est également responsable de tout mécanisme de mappage entre le formulaire IMA et tout alias ASCII.

EAI permet aux utilisateurs d'avoir une adresse localisée dans un script ou un jeu de caractères en langue native, ainsi qu'un formulaire ASCII pour communiquer avec les systèmes existants ou pour une utilisation indépendante du script. Les applications qui reconnaissent les noms de domaine et les adresses e-mail internationalisés doivent disposer d'installations pour convertir ces représentations.

Une demande importante pour de telles adresses est attendue en Chine, au Japon, en Russie et sur d'autres marchés qui ont de grandes bases d'utilisateurs dans un système d'écriture non latin.

Par exemple, en plus du domaine de premier niveau .in , le gouvernement indien a obtenu en 2011 l'approbation de ".bharat", (de Bhārat Gaṇarājya ), écrit en sept scripts différents à utiliser par Gujrati, Marathi, Bangali, Tamil, Orateurs télougou, pendjabi et ourdou. La société indienne XgenPlus.com prétend être le premier fournisseur de messagerie EAI au monde, et le gouvernement du Rajasthan fournit désormais un compte de messagerie gratuit sur le domaine राजस्थान.भारत pour chaque citoyen de l'État. Une maison de presse de premier plan, le Rajasthan Patrika, a lancé son domaine IDN पत्रिका.भारत avec une adresse e-mail joignable.

Exemples d'internationalisation

Les exemples d'adresses ci-dessous ne seraient pas gérés par les serveurs basés sur la RFC 5322, mais sont autorisés par la RFC 6530. Les serveurs compatibles avec cela pourront les gérer :

Alphabet latin avec signes diacritiques : Pelé@example.com
Alphabet grec : δοκιμή@παράδειγμα.δοκιμή
Caractères chinois traditionnels : 我買@屋企.香港
Caractères japonais : 二ノ宮@黒川.日本
Caractères cyrilliques : медведь@с-балалайкой.рф
Caractères Devanagari : संपर्क@डाटामेल.भारत

Accompagnement à l'internationalisation

Postfix mailer prend en charge le courrier internationalisé depuis 2015-02-08 avec une version stable 3.0.0.
Google prend en charge l'envoi d'e-mails vers et depuis des domaines internationalisés, mais n'autorise pas l'enregistrement d'adresses e-mail non ASCII.
Microsoft a ajouté des fonctionnalités similaires dans Outlook 2016
DataMail lance un support de messagerie internationalisé pour 8 langues indiennes à l'aide de la plate-forme de messagerie XgenPlus en Inde.

Documents de normes

RFC 821 - Simple Mail Transfer Protocol (obsolète par RFC 2821)
RFC 822 - Norme pour le format des messages texte Internet ARPA (obsolète par la RFC 2822) (Errata)
RFC 1035 – Noms de domaine, Implémentation et spécification (Errata)
RFC 1123 - Exigences pour les hôtes Internet, les applications et le support (mis à jour par RFC 2821, RFC 5321) (Errata)
RFC 2142 - Noms de boîtes aux lettres pour les services, rôles et fonctions communs (errata)
RFC 2821 - Simple Mail Transfer Protocol (obsolète RFC 821, mises à jour RFC 1123, obsolète par RFC 5321) (Errata)
RFC 2822 - Format de message Internet (obsolète RFC 822, obsolète par RFC 5322) (errata)
RFC 3696 - Techniques d'application pour la vérification et la transformation des noms (errata)
RFC 4291 - Architecture d'adressage IP version 6 (mis à jour par RFC 5952) (Errata)
RFC 5321 - Protocole de transfert de courrier simple (RFC 2821 obsolète, mises à jour RFC 1123) (Errata)
RFC 5322 - Format des messages Internet (RFC 2822 obsolète, mis à jour par RFC 6854) (Errata)
RFC 5952 - Une recommandation pour la représentation de texte d'adresse IPv6 (Mises à jour RFC 4291) (Errata)
RFC 6530 - Vue d'ensemble et cadre pour le courrier électronique internationalisé (obsolètes RFC 4952, 5504, 5825)
RFC 6531 - Extension SMTP pour le courrier électronique internationalisé (obsolète RFC 5336)
RFC 6854 – Mise à jour du format de message Internet pour autoriser la syntaxe de groupe dans les champs d'en-tête « De : » et « Expéditeur : » (Mises à jour RFC 5322)

Languages

In other projects