Résumé

  • Le SMTP d’origine offrait VRFY et EXPN comme outils de diagnostic. Une réponse positive pouvait révéler une boîte aux lettres, voire tous les membres d’une liste de diffusion.
  • Le code 252 introduisit une troisième réponse honnête : le serveur ne vérifie pas l’utilisateur, mais peut accepter le message et tenter sa livraison. Divulgation d’annuaire, prise en charge du transport et livraison finale cessent alors d’être confondues.

Quand le serveur de courrier répondait comme un annuaire

La RFC 821 proposait un échange d’une limpidité rare. À VRFY Smith, le serveur pouvait répondre 250 avec le nom complet de Fred Smith et sa boîte. Il pouvait indiquer une adresse de réexpédition, signaler qu’aucun nom ne correspondait ou, si plusieurs Smith existaient, imposer la réponse 553 User ambiguous.

La commande jumelle EXPN allait plus loin. Un client donnait le nom d’une liste ; une réponse positive sur plusieurs lignes énumérait ses boîtes aux lettres, une par ligne. Le contrat était strict : un succès de VRFY devait contenir la boîte de l’utilisateur, et un succès d’EXPN devait livrer les adresses de la liste. Le serveur transformait ainsi une connaissance locale en preuve protocolaire exploitable à distance.

Cette franchise résolvait de vrais problèmes. Une faute dans un nom pouvait être détectée avant l’envoi. Une réexpédition devenait visible. L’expansion de listes imbriquées pouvait être suivie jusqu’à la boucle. Puisque l’annuaire et la remise s’appuyaient sur la même connaissance, placer le diagnostic dans SMTP semblait naturel.

Mais la fenêtre de dépannage était aussi ouverte sur l’Internet public.

L’utilité changea de bénéficiaire

En 1989, la RFC 1123 exigea la mise en œuvre de VRFY côté réception et recommanda EXPN, tout en autorisant chaque installation à désactiver les commandes, éventuellement pour certaines listes seulement. Son commentaire conservait les deux vérités : les administrateurs s’en servaient régulièrement pour comprendre les incidents de livraison, et l’expansion des listes constituait une exposition potentielle de la vie privée et de la sécurité.

Avec le courrier indésirable de masse, le même dialogue trouva un autre public. VRFY permettait de tester un dictionnaire de noms ; EXPN convertissait un identifiant de liste en une collection d’adresses. La RFC 2505 recommanda donc de contrôler les demandeurs par un interrupteur ou des listes d’accès. Pour un VRFY fermé ou interdit, 252 devait devenir la réponse par défaut ; EXPN, lui, devait être désactivé par défaut.

La commande n’avait pas cessé d’être utile. Son autorité devait dépendre du demandeur. L’administrateur qui audite une réexpédition interne et l’inconnu qui récolte des adresses peuvent envoyer les mêmes octets. Leur droit à connaître ne réside pas dans la syntaxe, mais dans l’identité, la relation administrative et la portée autorisée.

Une troisième réponse, plutôt qu’un mensonge binaire

Deux choix seulement auraient forcé le serveur à inventer un fait. Retourner 250 après avoir vérifié la seule syntaxe revient à certifier une adresse qui ne l’a pas été. Retourner systématiquement 550 revient à affirmer l’inexistence, même lorsque le serveur refuse simplement de parler. La RFC 5321 déclare les deux comportements non conformes.

252 ouvre une issue : « impossible de VRFY l’utilisateur, mais le message sera accepté et sa livraison tentée ». Ce code ne prouve pas l’existence de la boîte. Il ne garantit pas que chaque futur RCPT TO sera accepté, et encore moins qu’un humain recevra le message. Il dit seulement que le serveur ne peut ou ne veut pas formuler l’assertion d’annuaire demandée, sans fermer le chemin normal du courrier.

Un relais MX peut parfaitement connaître les domaines qu’il dessert et valider une syntaxe sans disposer en temps réel de la base finale des boîtes. Dans ce cas, répondre oui ou non dépasserait son savoir. 252 préserve l’incertitude au lieu de la maquiller.

La politique de sécurité utilise la même sémantique. Selon la RFC 5321, un site qui désactive les commandes pour se protéger doit répondre 252, et non un code interprétable comme une vérification positive ou négative. Ne pas divulguer n’est pas démontrer l’absence.

Vérifier, accepter et livrer produisent trois faits

Les systèmes de messagerie ont tendance à écraser des états voisins. Une syntaxe valide devient « adresse vérifiée ». Un 250 reçu sur un relais devient « livré ». Une consultation bloquée devient « boîte inexistante ». À chaque raccourci, une observation partielle reçoit une autorité qu’elle ne possède pas.

Trois registres doivent rester distincts. La vérification d’annuaire affirme que le serveur a réellement établi une adresse ou une expansion. L’acceptation de transaction indique qu’une machine a pris une responsabilité à une étape donnée. La livraison finale ne peut être connue qu’après routage, files, transferts et traitement du destinataire. 252 se tient volontairement en amont de ces résultats.

Un tableau de supervision ne devrait donc classer ce code ni parmi les vérifications réussies, ni parmi les adresses invalides. Le bon état est une incertitude explicite accompagnée d’un chemin de transport possible. Une transaction ultérieure pourra produire davantage de preuves ; la requête d’annuaire ne peut les anticiper.

Fermer VRFY ne ferme pas toutes les fuites

La RFC 5321 avertit que les réponses à RCPT peuvent parfois révéler la même validité. Ailleurs, le contrôle du destinataire est reporté après DATA, de sorte que RCPT ne dit presque rien. Le gain marginal de la fermeture de VRFY dépend donc de toute la chaîne d’acceptation.

Il serait faux d’annoncer une victoire parce qu’un verbe renvoie 252. La politique peut supprimer la requête la moins chère et la plus directe ; elle ne garantit pas que les différences de délai, les domaines attrape-tout, les rebonds ou les rapports ultérieurs ne livrent aucun indice. La surface composite doit être testée.

L’existence d’autres méthodes ne justifie pas non plus un EXPN public. Retirer la voie d’énumération la plus autoritative augmente le coût et réduit la confiance du collecteur. La sécurité consiste souvent à gouverner le prix et la qualité de la preuve plutôt qu’à promettre un secret parfait.

Le diagnostic survécut derrière une frontière

La RFC 5321 maintient l’intérêt de VRFY et d’EXPN pour les utilisateurs authentifiés et dans un même domaine administratif. Ils permettent d’auditer le routage, de repérer une réexpédition automatique de courrier sensible ou d’examiner une liste. Un site peut les réserver aux demandeurs authentifiés. La fonction subsiste ; le droit anonyme disparaît.

Le registre SMTP actuel de l’IANA marque encore cette séparation. La prise en charge de VRFY est requise dans les serveurs, tandis que son annonce dans EHLO reste facultative. VRFY et EXPN sont tous deux marqués MUST NOT pour le service Message Submission. Être authentifié pour soumettre son propre courrier ne confère pas un droit sur l’annuaire du système receveur.

SMTP n’apprit donc pas à esquiver la question par le mensonge ou le silence. Il apprit à répondre exactement à une question plus petite. Le serveur pouvait refuser de certifier une personne, conserver la possibilité de transporter le message et réserver le diagnostic détaillé à une relation légitime. Dans un protocole fait de réponses, 252 limita ce qu’une réponse avait le droit de prétendre savoir.

Sources