Résumé

  • 251 accepte l’ancien destinataire et confie au serveur la suite du transfert ; 551 refuse ce destinataire et laisse au client le choix d’essayer la nouvelle adresse ou d’échouer.
  • Les normes ultérieures autorisèrent le transfert silencieux avec 250 et le refus discret avec 550, car l’adresse finale pouvait être confidentielle ou inaccessible à l’expéditeur.
  • Une adresse corrigée n’authentifie ni une personne ni un renommage global. La réutiliser à l’avenir exige une preuve du serveur et une autorité distincte sur le carnet d’adresses.

Même connaissance, obligations contraires

Un logiciel envoie RCPT TO vers une ancienne boîte. Le serveur sait où le titulaire reçoit désormais son courrier. Avec 251, il répond positivement : le destinataire de cette transaction est accepté, et le serveur prend la charge de faire suivre. Avec 551, la classe 5xx ferme la tentative : l’ancien destinataire est refusé, même si le texte propose une autre voie.

Réduire les deux réponses à « adresse déplacée » produit deux fautes symétriques. Après 251, réémettre immédiatement vers la nouvelle adresse peut créer un doublon. Après 551, croire que le premier serveur s’en chargera peut perdre le message. Le premier chiffre est un registre de garde, pas une décoration.

La bifurcation dessinée en 1982

RFC 821 posa les deux réponses dès l’origine de SMTP. Le chemin fourni pouvait corriger l’hôte, la partie locale ou les deux. 251 User not local; will forward signifiait que le serveur recevait le message et assumait sa livraison. 551 User not local; please try signifiait qu’il refusait ; le client devait rediriger ou signaler une erreur à l’auteur.

Le protocole ne disait donc pas seulement où se trouvait une boîte. Il disait qui devait maintenant agir. La même chaîne de caractères n’avait pas la même autorité lorsqu’elle accompagnait une acceptation et lorsqu’elle accompagnait un refus.

Le présent et l’avenir restaient séparés. Pour le présent, le code numérique décidait de l’état du destinataire. Pour l’avenir, le client pouvait afficher la correction, la conserver pour une tentative, demander confirmation à l’utilisateur ou ne rien modifier.

Faire suivre sans montrer où

En 2001, RFC 2821 reconnut qu’un transfert silencieux était devenu courant. Les alias d’entreprise simplifiaient les adresses ; une ancienne boîte pouvait alimenter un compte privé. Révéler l’adresse finale risquait d’exposer une topologie interne ou une destination que l’expéditeur n’était pas autorisé à joindre.

RFC 5321 conserve quatre combinaisons. Un serveur peut accepter, transférer et annoncer la correction avec 251, ou accepter sans la révéler avec 250. Il peut refuser et suggérer avec 551, ou refuser sans information précise avec 550.

La confidentialité n’oblige donc pas à mentir sur la garde du message. Elle retire un renseignement tout en préservant le résultat de transaction. Les implémentations qui savent émettre 251 ou 551 devraient permettre aux sites d’en restreindre l’usage.

Le déplacement ne promet pas une destination publique

RFC 3463 ajouta le statut étendu X.1.6 : la boîte a déménagé, sans adresse de transfert. Le registre IANA des statuts SMTP étendus maintient aujourd’hui cette formulation pour un échec permanent.

L’absence peut correspondre à plusieurs réalités légitimes : aucune adresse ne remplace l’ancienne ; le serveur ne connaît pas la suivante ; la politique interdit de la publier ; elle n’est joignable que depuis le système qui transfère. Dans aucun cas le client ne reçoit le droit d’inventer une cible à partir d’un ancien en-tête ou d’un annuaire tiers.

RFC 3464 traite la même tension dans les notifications d’état. Les DSN peuvent être falsifiées, et un destinataire peut faire suivre ses messages sans vouloir divulguer l’adresse finale. Le standard encourage un mécanisme de confidentialité. Une livraison peut donc progresser tandis que la visibilité de l’expéditeur diminue.

La correction lisible par machine devint une cible

Le texte ordinaire d’une réponse SMTP est destiné à l’humain et varie selon les serveurs. Le chemin de 251 et 551 est une exception : une machine peut l’extraire pour décider d’une nouvelle action. Cette utilité agrandit le dommage d’une fausse réponse.

RFC 5321 avertit qu’un client ne devrait modifier automatiquement son comportement futur — par exemple son carnet — qu’après s’être assuré de l’authenticité du serveur. Un intermédiaire qui remplace l’adresse ne détourne pas seulement le message courant ; si la correction est mémorisée, il peut détourner les suivants.

Même authentifiée, la réponse ne prouve pas tout. Elle attribue la déclaration à un serveur ; elle ne certifie ni que la nouvelle boîte appartient à la même personne, ni que la mutation sera éternelle, ni que l’administrateur du serveur possède le carnet d’un utilisateur. La preuve de transport est une condition d’automatisation, non un mandat universel sur l’identité.

Un alias déplace la charge, pas le texte de l’auteur

RFC 5598 distingue le relais ordinaire de l’alias. Un MTA rapproche le message de son destinataire sans changer les adresses d’enveloppe. Un alias, choisi du côté du destinataire, réexpédie vers une ou plusieurs adresses en conservant le message et généralement le chemin de retour.

La modification mécanique paraît minuscule : seul RCPT TO change. Son effet sémantique est grand : le destinataire initial en choisit un autre. Une panne en aval peut pourtant produire un rapport vers l’auteur original, qui ignore l’existence de cet alias. Le transfert redistribue ainsi le risque sans réécrire forcément le champ visible To.

Une correction SMTP ne constitue donc pas un renommage Internet. C’est une déclaration locale sur un destinataire d’enveloppe : nous le prenons et faisons suivre, ou nous le refusons et vous indiquons éventuellement une piste. Le reste appartient à d’autres registres.

Une correction utile parce qu’elle demeurait bornée

L’histoire de 251 et 551 sépare quatre décisions que les interfaces modernes fusionnent facilement : accepter, transférer, révéler et mémoriser. Les trois premières appartiennent au serveur et à la transaction ; la dernière appartient au détenteur des données de contact.

SMTP savait aider un message à suivre un déménagement sans prétendre que le réseau avait renommé la personne. Quand la confidentialité exigea le silence, le protocole put retirer l’adresse sans perdre cette division des responsabilités.