Une adresse peut être écrite sans la moindre faute et ne mener nulle part. Trois questions se cachent derrière le mot « valide » du langage courant, et elles ne se posent pas au même endroit. La première regarde la forme de l’adresse. La deuxième interroge le domaine placé après l’arobase. La troisième s’adresse au serveur qui héberge la boîte. Chacune s’arrête à une frontière nette, et savoir où elle passe évite de déclarer fausse une adresse qui fonctionne.
Valide veut dire bien écrite, et rien d’autre
Du côté de la forme, deux textes de l’IETF font autorité. La RFC 5322, publiée en octobre 2008, décrit la structure d’une adresse : une partie locale, une arobase, un domaine. La RFC 5321, qui décrit le protocole SMTP la même année, fixe les longueurs maximales dans sa section 4.5.3.1, soit 64 octets pour la partie locale et 255 octets pour le domaine.
Ce que ces normes autorisent surprend souvent. En dehors des lettres et des chiffres, la RFC 5322 admet dans une partie locale non protégée toute une série de caractères spéciaux : ! # $ % & ' * + - / = ? ^ _ ` { | } ~. Le point y est accepté à l’intérieur, jamais en tête ni en queue, et jamais deux fois de suite. Entourée de guillemets, elle accepte en plus des espaces et des caractères normalement réservés.
La RFC 3696, écrite par John Klensin en février 2004 pour guider les développeurs, donne des exemples d’adresses parfaitement légales : [email protected], customer/[email protected], !def!xyz%[email protected], [email protected], ou encore "Fred Bloggs"@example.com. Beaucoup de formulaires les refusent. Le cas le plus répandu reste le signe plus, que Gmail utilise pour étiqueter un abonnement et que des champs de saisie bloquent en le prenant pour une faute de frappe. Depuis la RFC 6531 de février 2012, l’extension SMTPUTF8 ajoute encore les caractères non-ASCII, dans la partie locale comme dans le domaine.
Une adresse qui franchit ces règles est bien formée, ce qui ne dit rien du domaine qui la suit.
Existante se joue dans le DNS, sur l’enregistrement MX
Le DNS répond à la deuxième question. Avant d’expédier quoi que ce soit, un serveur SMTP demande au DNS les enregistrements MX du domaine placé après l’arobase, et ces enregistrements désignent les machines chargées de recevoir le courrier pour ce domaine. La RFC 5321 prévoit le cas d’une réponse vide dans sa section 5.1 : le domaine est alors traité comme s’il portait un enregistrement MX implicite, de préférence 0, qui pointe vers lui-même. La livraison est tentée sur l’adresse du domaine, et un domaine sans MX déclaré peut donc héberger une boîte joignable.
Un mail tester gratuit interroge justement ces enregistrements MX puis le serveur lui-même, ce qui répond en quelques secondes à une question que la syntaxe seule ne tranche pas. La réponse porte sur le domaine et sur la boîte visée par cette adresse mail.
Active dépend de ce que répond le serveur d’en face
Une fois le domaine confirmé, reste la boîte elle-même. Le protocole SMTP décrit par la RFC 5321 fonctionne comme un dialogue court entre deux machines. Le client annonce l’expéditeur avec la commande MAIL FROM, puis présente le destinataire avec RCPT TO. Le serveur destinataire se prononce à ce moment précis. S’il accepte, la RFC prévoit qu’il renvoie une réponse 250 OK et mémorise le chemin de livraison. S’il refuse définitivement, il renvoie un code de la famille 5yz, dont le 550 qui signale un destinataire inconnu ou rejeté.
Ce dialogue peut se dérouler sans qu’aucun message ne parte. La connexion s’ouvre, la question RCPT TO est posée, la réponse est lue, la connexion se ferme. Rien n’a été écrit dans la boîte.
Une commande dédiée existe pourtant depuis les débuts du protocole, VRFY, qui sert à demander à un serveur si une adresse lui est connue avant même d’engager la moindre livraison. Sa fiabilité est faible, et la RFC 5321 l’écrit noir sur blanc. Un serveur qui répond 252 signale une adresse qui semble valide mais qu’il ne peut pas raisonnablement vérifier en temps réel, ce qui ne confirme rien du tout. La même section interdit de répondre 250 à un VRFY sans avoir réellement vérifié l’adresse. Sa section 7.3 autorise en plus les administrateurs à désactiver la commande par configuration, pour des raisons de sécurité, ce que beaucoup de serveurs publics ont fait. VRFY renvoie donc rarement une information exploitable aujourd’hui.
Les cas où la réponse reste suspendue
Il arrive que le serveur refuse de trancher, et deux mécanismes expliquent l’essentiel de ces réponses molles.
Le premier est la configuration dite catch-all, qui accepte n’importe quel destinataire pour un domaine, existant ou non. La RFC 5321 décrit ce comportement dans sa section 3.3 en reconnaissant qu’en pratique, certains serveurs ne vérifient pas le destinataire avant d’avoir reçu le corps du message. La norme leur demande alors de traiter l’échec comme une défaillance ultérieure et de renvoyer un avis de non-remise. Le RCPT TO répond 250, la boîte n’existe pas et le rebond arrive plus tard. Un domaine en catch-all rend l’ensemble de ses adresses indécidables d’un seul coup. La configuration se repère par comparaison, en présentant au serveur une adresse tirée au hasard sur le même domaine : s’il accepte aussi celle-là, ses réponses ne distinguent plus rien.
Le second est le greylisting, décrit par la RFC 6647 publiée en juin 2012. Le principe consiste à dégrader temporairement le service pour une source inconnue ou suspecte, sur une durée que le texte situe en minutes ou en quelques heures. Le serveur répond par un code temporaire, 421 s’il souhaite couper la connexion immédiatement et 450 sinon, puis attend le retour de l’expéditeur. La RFC recommande d’appliquer la décision au niveau du RCPT, sur un triplet composé de l’adresse IP, de l’expéditeur annoncé et du premier destinataire. Un serveur légitime réessaie, dans une fenêtre que le texte situe entre une minute et 24 heures. Une vérification ponctuelle, elle, ne réessaie pas et repart avec un refus temporaire qu’elle ne peut pas interpréter.
Ce que la technique ne dira jamais
Aucun de ces contrôles ne dit si quelqu’un lit encore cette boîte. Le protocole SMTP transporte du courrier et répond à des questions de routage ; il n’expose ni la date de la dernière connexion à la boîte, ni la moindre trace d’un être humain derrière l’adresse, et rien dans la norme ne prévoit de rendre ces informations accessibles à un tiers.
Une boîte professionnelle abandonnée après un départ continue souvent d’accepter le courrier pendant des mois. Elle répond 250 à chaque RCPT TO. Personne ne l’ouvre. Une redirection automatique produit le même effet depuis une adresse que son titulaire a quittée. Un service qui a fermé ses portes garde parfois son domaine et sa messagerie actifs le temps que l’enregistrement expire.
La vérification technique s’arrête à la porte. Elle confirme que le courrier sera accepté, et le reste lui échappe. Cette limite est structurelle : l’information n’existe nulle part dans le protocole, donc aucune méthode d’interrogation ne la fera apparaître. Seul le comportement observé sur des envois réels, ouvertures et réponses, apporte ce complément.
À quoi la distinction sert vraiment
Si vous expédiez du courrier en nombre, ces trois niveaux changent la façon de nettoyer une liste. Une adresse mal formée se corrige ou se supprime dès la saisie. Un domaine sans messagerie joignable se retire sans état d’âme, puisque plus rien n’y arrivera. Une boîte qui répond 550 se retire aussi. Les cas suspendus, catch-all et greylisting, se rangent à part et se traitent par un envoi prudent plutôt que par une vérification supplémentaire, qui rendra exactement la même réponse.
Côté formulaire, l’exigence s’inverse. Un champ trop restrictif refuse des clients réels. La RFC 3696 existe pour cette raison. Ses exemples d’adresses valides mais inhabituelles servent de banc d’essai à n’importe quel contrôle de saisie. Un filtre trop zélé rejette des adresses parfaitement légales, la personne repart sans insister, et le formulaire aura écarté un client au lieu d’une erreur de saisie.
Côté destinataire, enfin, ces trois niveaux aident à lire un message d’erreur. Un rebond qui cite un code 550 désigne un destinataire refusé par le serveur d’en face. Rien ne sert de retenter. Un code commençant par 4 annonce une attente temporaire, et le message repartira tout seul. Les deux appellent des réactions différentes, et les confondre fait supprimer des contacts qui recevaient parfaitement le courrier.
