Analyse approfondie des adresses e-mail

• Une adresse e-mail n’est pas une simple combinaison d’un nom d’utilisateur et d’un domaine, mais un système qui inclut une structure complexe, des règles définies par les RFC et des pièges de sécurité
• La partie locale (avant @) admet divers formats valides peu connus, comme les guillemets, les commentaires ou l’Unicode, mais la plupart ne sont pas pris en charge en environnement réel
• Tout e-mail comporte deux adresses d’expéditeur, l’Envelope Sender et l’en-tête From, et cette différence est à l’origine du spoofing et du phishing
• La politique d’ignorance des points de Gmail, l’adressage avec plus et les alias de domaine sont des comportements propres à chaque fournisseur qui ont un impact direct sur la sécurité et la validation
• Lorsqu’on construit un système de collecte ou de validation d’adresses e-mail, il est essentiel de comprendre précisément l’écart entre les RFC et le comportement réel

---

Structure de base

• Une adresse e-mail se compose de trois parties : la partie locale (avant @), le séparateur @ et le domaine (après @)
• En apparence simple, elle comporte dans chaque partie des règles et des cas limites qui influencent la sécurité, la confidentialité et la validation

Partie locale (Local Part)

• Caractères autorisés

  • Dans le format standard non entre guillemets (dot-atom), les caractères autorisés sont : lettres a-z, A-Z, chiffres 0-9, caractères spéciaux . _ - + ! # $ % & ' * / = ? ^ { | } ~
  • La longueur maximale est de 64 octets (octets) ; en ASCII standard cela équivaut à 64 caractères, mais il existe une différence avec une partie locale Unicode
    • Un octet désigne précisément un groupe de 8 bits, utilisé en réseau (IPv4) pour représenter une valeur de 0 à 255
    • 64 octets correspondent à un bloc de données de 512 bits

• Sensibilité à la casse

  • Selon la RFC 5321, la partie locale est techniquement sensible à la casse, et [e-mail] ainsi que [e-mail] peuvent désigner des boîtes mail distinctes
  • En pratique, tous les grands fournisseurs de messagerie ignorent la casse ; normaliser en minuscules avant stockage ou comparaison est donc la valeur par défaut la plus sûre
  • La partie domaine, elle, n’est jamais sensible à la casse

• Adressage avec points

  • Le point est autorisé dans la partie locale, mais avec trois restrictions : il ne peut pas être en début, ni en fin, et les points consécutifs sont interdits
  • Normalisation des points par Gmail : Gmail ignore complètement les points dans la partie locale, de sorte que [e-mail], [e-mail] et [e-mail] sont tous distribués dans la même boîte de réception
    • Il s’agit d’un comportement propre à Gmail, non défini par les RFC
    • C’est un vecteur d’attaque réel, exploitable par un attaquant qui crée un compte avec une variante à points pour contourner une limite d’unicité de compte ou obtenir plusieurs essais gratuits

• Sous-adressage (adressage avec plus)

  • Il est possible d’ajouter un tag à la partie locale à l’aide d’un séparateur, le serveur distribuant le message vers l’adresse de base tout en conservant le tag (RFC 5233)
  • Le séparateur le plus courant est +, pris en charge par Gmail, Outlook, ProtonMail, Fastmail, etc.
    • Certaines configurations Yahoo et certains réglages de Postfix utilisent -
    • qmail utilise = comme séparateur par défaut, ce qui explique pourquoi VERP encode @ en =
  • Principaux cas d’usage :
    • Traçage des fuites : s’inscrire à chaque service avec un tag unique (ex. [e-mail]) pour identifier l’origine d’une fuite en cas de spam
    • Filtrage de la boîte de réception : classer automatiquement les messages destinés à certaines adresses taguées via des règles de messagerie
    • Comptes multiples : créer plusieurs comptes avec une seule adresse sur des services qui ne normalisent pas le plus
  • De nombreux validateurs d’adresses e-mail sur le Web rejettent +, mais il s’agit d’un bug du code de validation, pas d’une limitation de l’e-mail

• Format en chaîne entre guillemets (Quoted String Form)

  • Lorsque la partie locale est entourée de guillemets doubles, la plupart des restrictions sur les caractères sont levées, ce qui autorise les espaces, @, les points consécutifs, ainsi que les points initiaux ou finaux
  • Exemples : "john doe"@example.com, "user@name"@example.com, " "@example.com
  • En pratique, presque tous les fournisseurs de messagerie refusent les parties locales entre guillemets ; valide au sens des RFC, mais inutilisable en pratique

• Commentaires (Comments)

  • Des commentaires entre parenthèses peuvent apparaître au début ou à la fin de la partie locale ; le serveur les supprime sans effet sur l’acheminement
  • C’est techniquement valide selon la RFC 5322, mais plus utilisé aujourd’hui
  • Un validateur qui rejette les parenthèses est plus strict que la RFC

• Partie locale Unicode (EAI)

  • L’internationalisation des adresses e-mail (EAI), définie par les RFC 6530, 6531 et 6532, autorise les caractères UTF-8 dans la partie locale
  • Elle nécessite l’extension SMTPUTF8 dans la session SMTP, et les serveurs d’envoi comme de réception doivent la prendre en charge
  • En 2026, l’adoption reste limitée, et comme les caractères Unicode occupent 2 à 4 octets, il est possible d’atteindre la limite de 64 octets avant d’atteindre 64 caractères visibles

• Formats historiques

  • Bang path (UUCP) : méthode de routage utilisée avant le DNS sur des réseaux de machines Unix reliées par modem, avec des chemins d’hôtes séparés par ! (machine1!machine2!user) ; c’est pourquoi ! figure dans la liste des caractères autorisés. Aujourd’hui totalement abandonné
  • Percent hack : astuce de routage par relais sous la forme [e-mail] ; le caractère % reste valide dans la partie locale même après l’abandon du mécanisme de routage dans la RFC 5321
  • Source routing : liste explicite de relais dans la commande SMTP RCPT TO (@relay1,@relay2:user@domain). Abandonné par la RFC 5321

• VERP (Variable Envelope Return Path)

  • Technique utilisée par les systèmes d’envoi massif pour identifier précisément le destinataire ayant provoqué un bounce
  • Elle encode l’adresse du destinataire dans l’expéditeur d’enveloppe (MAIL FROM), en remplaçant @ par = dans l’adresse du destinataire
    • Exemple : bounces+alice=[e-mail]
  • Mailchimp, SendGrid et Amazon SES utilisent VERP ou des variantes pour le traitement des bounces à grande échelle

• SRS (Sender Rewriting Scheme)

  • Format d’adresse apparaissant lorsqu’un serveur transfère un e-mail et réécrit l’expéditeur d’enveloppe pour faire passer les vérifications SPF
  • Sous la forme SRS0=HASH=TT=originaldomain.com=[e-mail]
  • En cas de transfert à plusieurs sauts, sous la forme SRS1=HASH=[e-mail]
  • Il s’agit d’une adresse e-mail structurellement valide, mais d’un artefact d’infrastructure, pas d’une adresse utilisée par une personne
  • Le composant HASH est un HMAC sur l’horodatage et l’adresse d’origine, utilisé pour empêcher la falsification et limiter la durée de validité du jeton

Partie domaine (Domain Part)

• Règles des labels

  • Un domaine est composé de labels séparés par des points, et chaque label peut contenir des lettres a-z, des chiffres 0-9 et le trait d’union -
  • Il ne peut pas commencer ni se terminer par un trait d’union, et il ne peut pas y avoir de doubles traits d’union en 3e et 4e position (sauf pour les labels Punycode commençant par xn--)
  • Un label peut faire au maximum 63 caractères, le domaine complet 253 caractères au maximum, et l’adresse e-mail entière (addr-spec) 254 caractères au maximum

• Sous-domaines

  • Un domaine peut avoir plusieurs niveaux, et en dehors de la longueur totale maximale de 253 caractères, il n’existe pas de limite stricte sur la profondeur des sous-domaines
  • Usages courants : infrastructure mail (mail., smtp., mx.), séparation organisationnelle (sales.company.com), envoi par un ESP (email.company.com)

• Littéraux d’adresse IP

  • Il est possible d’utiliser une adresse IP entre crochets à la place d’un nom de domaine : user@[192.168.1.1], user@[IPv6:2001:db8::1]
  • C’est valide selon la RFC 5321, mais presque jamais accepté par les serveurs mail publics ; c’est utilisé pour les systèmes de messagerie internes et les tests SMTP

• Domaines à label unique

  • Un domaine sans point (par ex. user@localhost) est techniquement valide dans certains contextes, mais les serveurs mail publics le rejettent
  • postmaster@localhost est un cas particulier conventionnel du mail système local sur les systèmes de type Unix

• Noms de domaine internationalisés (IDN) et Punycode

  • Le DNS ne prend en charge que l’ASCII ; les caractères non ASCII sont donc encodés en Punycode (RFC 3492), et tous les labels encodés commencent par le préfixe xn--
  • Les clients e-mail les affichent dans l’écriture native et SMTP les transmet sous forme Punycode
  • Attaque par homographe : il est possible d’enregistrer un domaine ressemblant à un domaine connu en utilisant des caractères visuellement identiques issus d’autres écritures Unicode. Les navigateurs disposent de mécanismes de défense qui affichent le Punycode pour les IDN suspects, mais les clients e-mail n’ont généralement pas ces protections, ce qui rend l’attaque plus efficace par e-mail

• Point final (Trailing Dot)

  • En DNS, tous les domaines se terminent techniquement par un point final représentant la zone racine, mais dans les adresses e-mail il est toujours implicite et donc omis
  • La plupart des validateurs rejettent la forme [e-mail].

• Enregistrements MX

  • Le domaine d’une adresse e-mail n’est pas forcément l’endroit où se trouve le serveur mail ; le serveur émetteur interroge les enregistrements DNS MX (Mail Exchanger) pour déterminer le vrai nom d’hôte du serveur mail
  • Un nombre de priorité plus faible signifie une priorité plus élevée, et s’il n’existe aucun enregistrement MX, il y a repli sur l’enregistrement A du domaine
  • Si un domaine ne doit jamais recevoir d’e-mails, on peut publier un enregistrement null MX (MX 0 .) pour indiquer explicitement aux serveurs émetteurs de ne pas tenter la livraison (RFC 7505)

Domaine de premier niveau (TLD)

• TLD génériques d’origine

  • Les 7 gTLD de l’Internet des débuts : .com (commercial, aujourd’hui sans restriction, exploité par Verisign), .net (réseaux, sans restriction), .org (organisations, sans restriction), .edu (établissements d’enseignement accrédités aux États-Unis, restreint), .gov (gouvernement américain, restreint), .mil (armée américaine, restreint), .int (organisations internationales fondées sur un traité, très restreint)
  • .arpa est un TLD d’infrastructure géré par l’IANA, utilisé pour les recherches DNS inversées

• TLD de code pays (ccTLD)

  • Il s’agit de codes à 2 lettres fondés sur la norme ISO 3166-1 alpha-2 ; il en existe environ 250
  • Certains ccTLD ont été réaffectés dans l’usage à d’autres secteurs :
    • .io (Territoire britannique de l’océan Indien → entreprises tech), .tv (Tuvalu → médias et streaming), .ai (Anguilla → entreprises IA), .co (Colombie → alternative à .com), .me (Monténégro → sites personnels), .ly (Libye → raccourcisseurs d’URL), .sh (Sainte-Hélène → projets logiciels)
  • Utiliser un ccTLD réaffecté signifie techniquement relever de la juridiction du registre du pays concerné ; le domaine est contrôlé par le registre du pays d’origine, et non par l’ICANN

• TLD sponsorisés (sTLD)

  • TLD avec organisme sponsor et critères d’éligibilité : .aero (transport aérien, sponsorisé par SITA), .coop (coopératives), .museum (musées), .jobs (emploi), .xxx (contenu adulte), .post (poste), .cat (langue et culture catalanes)

• Nouveaux TLD génériques (depuis 2012)

  • En 2012, l’ICANN a ouvert les candidatures pour de nouveaux gTLD, ce qui a conduit à la délégation de plus de 1 200 nouveaux TLD
  • Impact important pour la validation des e-mails : les validateurs qui limitent la longueur des TLD à 4 à 6 caractères cassent avec des extensions comme .photography, .international ou .construction
  • Côté développeurs : .app, .dev, .web, .code / commerce : .shop, .store, .online / contenu : .blog, .news, .media / business : .tech, .agency, .cloud
  • Les nouveaux gTLD sont surreprésentés dans le spam et le phishing en raison de coûts d’enregistrement faibles et de politiques anti-abus parfois insuffisantes chez certains registres

• TLD de marque

  • Lors de l’extension ICANN de 2012, de grands groupes ont demandé leur propre TLD : .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
  • La plupart ne sont pas utilisés pour des adresses e-mail publiques ; ils servent surtout à des usages internes ou ne sont pas utilisés du tout

• TLD géographiques et de villes

  • Des villes et régions ont leur propre TLD : .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
  • L’enregistrement exige généralement de prouver un lien avec la zone concernée

• TLD internationalisés

  • De nombreux pays disposent de TLD dans des écritures non ASCII, encodés en Punycode dans le DNS
    • .xn--p1ai (Russie, alphabet cyrillique), .xn--fiqz9s (Chine, caractères simplifiés), .xn--mgberp4a5d4ar (Arabie saoudite, alphabet arabe), .xn--h2brj9c (Inde, alphabet devanagari)

• TLD réservés et de documentation

  • Les RFC 2606 et RFC 6761 réservent certains TLD pour les tests et la documentation :
    • .test (n’existe jamais dans le DNS public, donc sûr pour les tests logiciels), .example (pour les exemples dans la documentation), .invalid (quand on a besoin d’un domaine garanti comme non résoluble), .localhost (pour le loopback)
  • L’IANA a enregistré example.com, example.net et example.org pour la documentation et les exemples, ce qui permet de les utiliser librement dans du code sans risquer d’atteindre une vraie boîte mail

• TLD retirés

  • Des ccTLD ont été supprimés à la disparition de leur pays : .yu (Yougoslavie, supprimé en 2010), .cs (Tchécoslovaquie, supprimé en 1995), .dd (Allemagne de l’Est, supprimé en 1990), .tp (Timor oriental, remplacé par .tl puis définitivement supprimé en 2015)
  • Exception : .su (Union soviétique) comporte toujours des domaines actifs malgré la dissolution de 1991 ; l’IANA discute depuis des années de sa transition, mais il reste actif

Domaines de second niveau des ccTLD

• De nombreux ccTLD ajoutent une catégorie fonctionnelle de second niveau entre le nom enregistrable et le TLD
  • Royaume-Uni : .co.uk, .org.uk, .gov.uk / Australie : .com.au, .edu.au / Japon : .co.jp, .ac.jp / Inde : .co.in, .gov.in / Brésil : .com.br, .gov.br
• Cela a un impact sur la validation et la détection du domaine organisationnel dans les systèmes de vérification d’e-mail lorsqu’il faut identifier le domaine organisationnel

• Public Suffix List (PSL)

  • Liste maintenue par la communauté sur publicsuffix.org, recensant tous les suffixes de domaine que les internautes peuvent enregistrer directement
  • Inclut à la fois les délégations officielles (.co.uk, .com.au) et les registres privés (github.io, wordpress.com, herokuapp.com)
  • Utilise une notation avec joker (ex. *.ck), les exceptions étant indiquées par ! (ex. !www.ck)
  • Utilisée par les validateurs d’e-mail et les filtres antispam pour identifier le domaine organisationnel dans la chaîne complète du domaine
  • Ce n’est pas un standard IETF, mais un standard de facto pour ce problème

Formats d’adresse e-mail

• Adresse de base (Bare Address)

  • Une addr-spec de la forme local@domain, utilisée dans les commandes SMTP et les contextes simples

• Format entre chevrons

  • En SMTP, les commandes MAIL FROM et RCPT TO encadrent l’adresse de chevrons : MAIL FROM:<[e-mail]>
  • Les chevrons font partie de la syntaxe de la commande SMTP, pas de l’adresse elle-même

• Format avec nom d’affichage (Display Name Format)

  • Dans les en-têtes de message (From, To, Cc), un nom lisible par un humain peut précéder l’adresse entre chevrons : "John Doe" <[e-mail]>
  • Si le nom d’affichage contient des caractères spéciaux, les guillemets sont obligatoires
  • Usurpation du nom d’affichage : l’expéditeur peut définir librement le nom affiché, ce qui permet des attaques du type "PayPal Security <[e-mail]>" <[e-mail]>
    • Comme de nombreux clients e-mail n’affichent que le nom d’affichage dans la liste de réception, c’est l’une des techniques de phishing les plus courantes

• Syntaxe de groupe (Group Syntax)

  • Format de groupe nommé pour plusieurs destinataires défini dans la RFC 5322 : Marketing Team: [e-mail], "Bob Smith" <[e-mail]>;
  • Motif des destinataires masqués : To: undisclosed-recipients:; — syntaxe de groupe vide, où les véritables destinataires se trouvent dans l’enveloppe SMTP (RCPT TO) et ne sont pas visibles dans les en-têtes du message

• Noms d’affichage encodés

  • Dans les anciens systèmes e-mail, les caractères non ASCII du nom d’affichage étaient traités comme des encoded words RFC 2047 : =?charset?encoding?encoded_text?=
  • Les encodages sont B (base64) ou Q (quoted-printable)
  • Avec la prise en charge moderne de SMTPUTF8, il est possible d’utiliser directement UTF-8 dans les en-têtes sans cette enveloppe d’encodage

Les deux expéditeurs de tout e-mail

• Expéditeur de l’enveloppe (Envelope Sender / MAIL FROM)

  • Défini dans la commande SMTP MAIL FROM: et ne fait pas partie du contenu du message lui-même
  • Utilisé pour le routage des bounces, c’est la cible de la vérification SPF, et le serveur destinataire final le stocke dans l’en-tête Return-Path:
  • Aussi appelé envelope from, reverse path ou RFC5321.MailFrom

• En-tête From

  • Adresse présente dans l’en-tête From: du message, c’est ce que le client e-mail affiche comme expéditeur
  • Élément protégé par DMARC, avec alignement SPF ou DKIM
  • Peut être défini librement par l’expéditeur et, sur la plupart des serveurs de messagerie, ne fait l’objet d’aucune vérification intrinsèque
  • Ces deux adresses peuvent être totalement différentes, et c’est un scénario normal et attendu :
    • Lors d’envois de masse via un ESP, le MAIL FROM peut être [e-mail] et l’en-tête From [e-mail]
    • Sur une mailing list, le MAIL FROM est l’adresse de bounce de la liste, tandis que l’en-tête From reste celui du publieur d’origine
    • En cas de transfert d’e-mail, le serveur relais peut réécrire le MAIL FROM avec SRS tout en conservant l’en-tête From d’origine
  • Si un domaine n’applique pas DMARC, n’importe qui peut envoyer un message en utilisant un MAIL FROM sans rapport tout en plaçant ce domaine dans l’en-tête From

• En-tête Sender

  • Identifie l’émetteur réel du message lorsque l’adresse From est différente : Sender: [e-mail]

• En-tête Reply-To

  • Indique où les réponses doivent être envoyées, et peut différer de l’adresse From
  • Peut aussi être exploité comme vecteur de phishing : l’attaquant donne au From une apparence légitime et définit Reply-To sur sa propre adresse

• Null Sender

  • MAIL FROM:<> est une structure SMTP valide et importante ; un expéditeur d’enveloppe vide est utilisé pour les messages de bounce, les réponses automatiques et les messages qui ne doivent pas eux-mêmes générer de bounce
  • Empêche les boucles infinies de bounce où deux systèmes continuent à s’échanger des notifications d’échec

Adresses basées sur des rôles (Role-Based Addresses)

• Obligation RFC 5321

  • postmaster@domain : selon la RFC 5321, tout domaine qui accepte du courrier doit accepter les messages à cette adresse, sans exception

• Recommandation RFC 2142

  • abuse@domain (signalement de spam et d’abus), hostmaster@domain (gestion de zone DNS), security@domain (divulgation de vulnérabilités et rapports de sécurité), webmaster@domain (problèmes de serveur web), noc@domain (exploitation réseau)

• Adresses de rôle d’usage courant

  • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@, etc. : ce ne sont pas des standards officiels, mais elles sont largement utilisées
  • Les adresses de rôle sont généralement partagées par plusieurs personnes, donc plusieurs membres de l’équipe peuvent consulter les informations sensibles qui y sont envoyées
  • abuse@ et postmaster@ reçoivent des messages de réclamation, ce qui en fait des cibles de social engineering

• Adresses catch-all (Catch-All Addresses)

  • Ce n’est pas un format d’adresse e-mail précis, mais une configuration du serveur de messagerie qui accepte la remise même pour des local parts sans boîte spécifique
  • Cas d’usage : récupérer les fautes de frappe, tests de développeurs, création d’adresses uniques par service sans système formel d’alias
  • Inconvénients : comme n’importe quel local part peut être remis, cela entraîne un afflux massif de spam et empêche la vérification de validité des adresses par probing SMTP (toutes les sondes reçoivent une réponse positive)

Comportements spécifiques selon le fournisseur

• Gmail

  • Normalisation des points : tous les points de la partie locale sont ignorés
  • Adressage plus : prise en charge du séparateur +
  • @googlemail.com : alias historique de @gmail.com dû à un litige sur la marque en Allemagne et au Royaume-Uni ; les deux domaines sont remis vers la même boîte de réception
  • Restrictions de caractères : seules les lettres latines, les chiffres et les points sont autorisés dans la partie locale (avec + pour l’adressage plus). Le jeu de caractères complet des RFC n’est pas pris en charge
  • Limite de longueur de la partie locale : 30 caractères, bien en dessous du maximum RFC de 64

• Microsoft (Outlook, Hotmail, Live)

  • Aucune normalisation des points : [e-mail] et [e-mail] sont des boîtes distinctes
  • Alias de domaine : @hotmail.com, @live.com et @outlook.com peuvent référencer le même compte lors de la configuration d’alias
  • Prise en charge de l’adressage plus

• Apple (iCloud)

  • Alias de domaine : @icloud.com, @me.com et @mac.com pointent vers la même boîte de réception (historique de changement de nom du service : .mac → .me → .icloud)
  • Prise en charge de l’adressage plus
  • Hide My Email : création d’alias aléatoires sous la forme [e-mail], avec un alias unique par service ou application afin de garder l’adresse réelle privée

• ProtonMail / Proton

  • Alias de domaine : @proton.me, @protonmail.com et @pm.me pointent vers la même boîte de réception
  • Prise en charge de l’adressage plus

• Services d’alias e-mail

  • Indépendamment des e-mails jetables, il existe des services qui génèrent des adresses de redirection permanentes et contrôlables :
    • SimpleLogin (groupe Proton) : redirection vers n’importe quelle boîte de réception via des alias personnalisés ou aléatoires
    • Addy.io (anciennement AnonAddy) : similaire à SimpleLogin, avec possibilité d’auto-hébergement
    • Firefox Relay (Mozilla) : alias aléatoires limités dans l’offre gratuite
    • DuckDuckGo Email Protection : alias en @duck.com
  • Ils génèrent pour l’expéditeur des adresses structurellement indiscernables d’une vraie boîte de réception
  • Différence essentielle avec l’e-mail jetable : les alias sont permanents et contrôlables ; on peut désactiver un alias précis, vérifier quel service l’a utilisé pour envoyer, et rediriger vers la boîte de réception souhaitée

E-mails jetables et temporaires

• Ils fournissent des boîtes de réception sans inscription, qui expirent généralement après une courte période ; Mailinator, Guerrilla Mail, 10 Minute Mail et TempMail sont parmi les plus connus
• La plupart utilisent un routage catch-all, donc n’importe quelle partie locale sur ce domaine est remise à une boîte de réception
• Beaucoup de boîtes sont publiques, de sorte que toute personne connaissant l’adresse peut lire les messages
• Il existe des listes de blocage de domaines jetables connus (le dépôt GitHub disposable-email-domains étant le plus cité), mais elles restent toujours incomplètes, les services changeant continuellement de domaine pour contourner les blocages

Validation

• Validité technique vs validité pratique

  • Valides selon les RFC mais presque jamais acceptées par les serveurs en pratique : espace entre guillemets (" "@example.com), @ entre guillemets ("user@name"@example.com), domaine littéral IP (user@[192.168.1.1]), caractère unique / label unique (a@b)
  • Valides selon les RFC et acceptées en pratique : [e-mail], [e-mail], [e-mail], [e-mail]
  • Dans la plupart des applications, un validateur pragmatique est préférable à un validateur de conformité RFC complet : vérification de la structure de base, validation d’un jeu de caractères raisonnable, et éventuellement requête DNS MX sur le domaine

• Bugs courants des validateurs

  • Rejet de + dans la partie locale : [e-mail] est parfaitement valide, et c’est un bug très fréquent
  • Rejet de _ dans la partie locale : c’est également valide
  • Rejet de % dans la partie locale : c’est un caractère valide ; ce qui est obsolète, c’est seulement l’usage du routage percent-hack
  • Limitation de la longueur du TLD à 4–6 caractères : cela bloque des centaines de nouveaux gTLD comme .photography, .international, .construction
  • Validation avec une liste de TLD codée en dur : comme la liste évolue en permanence, le validateur devient obsolète
  • Mauvaise limite de longueur totale : utilisation de 255 ou 256 au lieu de 254. La valeur erronée 320, souvent citée, a été corrigée à 254 dans l’erratum n° 1690 de la RFC 3696
  • Rejet des majuscules dans la partie locale : valide selon les RFC
  • Rejet de [e-mail] : valide ; les domaines multi-points suivant le schéma ccTLD de second niveau sont normaux
  • Rejet de .dev, .app, .io comme TLD : ce sont tous des TLD délégués valides

• Limites de longueur

  Partie	Limite
  Partie locale	64 octets
  Label de domaine	63 octets
  Domaine complet	253 octets
  Adresse complète (addr-spec)	254 octets

• La limite de la partie locale est exprimée en octets, pas en caractères ; une adresse EAI contenant des caractères Unicode multioctets peut donc afficher moins de 64 caractères tout en atteignant la limite en octets

• Validation basée sur le DNS

  • Vérification des enregistrements MX : valide la présence d’un enregistrement MX sur le domaine ; c’est rapide et peu risqué. Les domaines qui utilisent un repli sur un enregistrement A (sans MX configuré) peuvent échouer à ce test
  • Vérification Null MX : si le domaine a MX 0 ., il n’accepte explicitement pas d’e-mails
  • Sondage SMTP RCPT TO : il consiste à se connecter au serveur mail et à émettre une commande RCPT TO pour voir si l’adresse est acceptée ; mais beaucoup de serveurs renvoient 250 pour toutes les adresses afin d’empêcher la collecte d’adresses, donc ce n’est pas fiable. Les domaines catch-all répondent toujours positivement. Il existe aussi un risque que l’IP de la sonde soit mise sur liste noire
  • La seule manière de valider une adresse e-mail de façon totalement fiable est d’envoyer un vrai message et de vérifier sa réception ; tout le reste relève de l’heuristique

Implications de sécurité

• Usurpation du nom affiché

  • N’importe qui peut définir le nom affiché d’un e-mail comme il le souhaite, et dans les vues de boîte de réception qui n’affichent que ce nom, l’utilisateur ne peut pas distinguer un expéditeur légitime d’une usurpation sans vérifier explicitement l’adresse réelle

• Attaques par homographes via le punycode

  • Il est possible d’enregistrer des domaines visuellement identiques à des domaines connus en utilisant des caractères issus d’autres écritures Unicode
  • Contrairement aux navigateurs, les clients e-mail n’affichent généralement pas d’avertissement à ce sujet

• Contournement de compte via l’astuce des points Gmail

  • Comme Gmail ignore les points, un attaquant peut s’inscrire à un service avec une variante pointée d’une adresse Gmail existante afin de contourner les limites à un seul compte, obtenir plusieurs essais gratuits, et recevoir des e-mails destinés au propriétaire du compte d’origine

• Réutilisation des adresses e-mail

  • Les fournisseurs e-mail peuvent réattribuer des adresses abandonnées à de nouveaux utilisateurs ; le nouveau titulaire peut alors recevoir les e-mails de récupération de compte de services où l’ancien titulaire s’était inscrit, et prendre le contrôle du compte via une réinitialisation de mot de passe
  • Gmail affirme ne pas réattribuer les adresses, mais certains autres fournisseurs l’ont historiquement fait

• Exposition des tags de sous-adressage

  • Si vous vous inscrivez avec [e-mail], le service destinataire peut voir l’adresse complète, tag inclus
  • Un service qui supprime le tag plus avant stockage expose l’adresse de base ; un service qui conserve l’adresse complète telle quelle peut révéler votre stratégie de traçage dans les paramètres du compte ou lors d’un export de données