Résumé

  • SMTP AUTH plaça un échange SASL avant la transaction de courrier. Le serveur de soumission pouvait ainsi autoriser un compte mobile sans assimiler son adresse IP à son identité.
  • Le succès restait local à la session : l’identité authentifiée, l’identité autorisée, l’expéditeur d’enveloppe, l’auteur visible et le contenu formaient des affirmations différentes.

Sortir l’autorisation de l’adresse IP

Le SMTP historique savait accepter du courrier destiné au domaine local et transmettre des messages entre machines coopérantes. Lorsqu’un serveur public relayait aussi vers n’importe quelle destination, la simple capacité de se connecter devenait une autorisation trop large. À l’inverse, limiter le relais aux adresses d’un réseau d’accès empêchait un abonné légitime de voyager.

L’extension publiée en 1999, puis remplacée par la [RFC 4954], déplaça la preuve dans la session SMTP. Après EHLO, le serveur annonce AUTH et une liste de mécanismes SASL. Le client en choisit un, répond aux défis et obtient un résultat avant MAIL FROM. Une réussite permet d’appliquer une politique de relais à cette session ; elle ne transforme ni l’adresse réseau ni le mot de passe en identité universelle.

SASL distingue l’identité portée par les justificatifs de l’identité au nom de laquelle le client demande à agir. Le serveur vérifie les justificatifs, puis décide si la première peut exercer la seconde. Un compte de service peut déposer pour plusieurs boîtes ; un assistant peut recevoir une délégation limitée ; une file d’attente peut s’authentifier comme serveur tout en transportant les soumissions de nombreux utilisateurs.

La différence protège donc les deux côtés. Une authentification correcte ne suffit pas lorsque l’action demandée dépasse la délégation. Une adresse d’enveloppe plausible ne prouve pas quel compte a ouvert la session. Le champ From visible ne prouve pas qui a composé le texte.

Le MSA n’était pas l’Internet entier

La RFC 6409 donna une frontière à cette relation. Le port 587 désigne la soumission d’un agent utilisateur vers un Message Submission Agent. Le MSA reçoit un nouveau message d’un client auquel l’opérateur fournit un service ; le MTA reçoit ou transmet ensuite le courrier dans le réseau public.

Par défaut, le MSA doit refuser MAIL avec le statut 530 lorsque la session n’a ni SMTP AUTH ni autre autorisation établie indépendamment, par exemple un sous-réseau protégé. Cette exigence ne signifie pas que tous les MTA d’Internet doivent connaître un compte utilisateur à chaque saut. Elle place le contrôle fort au point où client et fournisseur possèdent une relation explicite.

Le gain économique et opérationnel fut concret : un abonné pouvait soumettre depuis un réseau étranger sans demander un relais ouvert. L’opérateur pouvait limiter les domaines, volumes ou rôles attachés au compte, révoquer une délégation et distinguer l’admission d’un utilisateur de l’acceptation du courrier entrant pour ses propres domaines.

Une identité de session, une identité par message

La RFC 4954 emploie aussi AUTH= comme paramètre facultatif de MAIL FROM. Le verbe AUTH établit l’état de la session ; le paramètre associe un message à l’identité déclarée comme soumissionnaire original. Les deux peuvent légitimement différer.

Un serveur qui traite une file s’authentifie une seule fois, puis relaie des messages associés à des utilisateurs différents. S’il fait confiance à l’assertion reçue et coopère dans un environnement contrôlé, le prochain serveur peut conserver cette boîte. La chaîne transporte alors une provenance bornée, non une preuve d’auteur.

Le protocole sait aussi dire qu’il ne sait pas. AUTH=<> signifie que le soumissionnaire est inconnu ou insuffisamment authentifié. Le relais ne doit pas combler le vide avec sa propre identité de session. Une connexion réussie ne lui donne pas le droit de réécrire l’histoire du message.

La syntaxe seule n’accorde aucune confiance. Le serveur récepteur choisit quels pairs peuvent affirmer une identité de soumission et dans quel périmètre. Hors de cette relation, la valeur peut être enregistrée comme donnée, pas promue automatiquement en verdict.

TLS protégeait le secret, pas l’auteur

Certains mécanismes exposent un mot de passe à un observateur si le canal n’est pas protégé. La RFC 4954 exige une configuration qui n’annonce pas ces mécanismes sans TLS ou couche équivalente. La liste après STARTTLS peut donc être différente : une possibilité dangereuse en clair devient acceptable dans un canal validé.

La RFC 8314 recommande TLS pour tout échange entre client et serveur de soumission. Le port 587 utilise couramment STARTTLS ; le port 465 commence par TLS implicite. Validation du certificat et chiffrement réduisent le risque de remettre le secret à un faux serveur ou à un observateur du réseau.

Mais ce canal se termine. Il ne signe pas le contenu, n’authentifie pas les sauts suivants et ne prouve pas qu’une personne approuve le champ From. SMTP AUTH traite la soumission, non la paternité du message. Une signature de bout en bout répond à une autre question.

Une trace d’une seule frontière

Après un succès, un serveur peut inscrire ESMTPA ou ESMTPSA dans son champ Received. Ces valeurs enregistrées par la RFC 3848 signalent respectivement SMTP AUTH, ou SMTP AUTH avec TLS, sur ce saut. Elles aident à diagnostiquer l’abus et à distinguer la soumission authentifiée du transfert entrant.

Le consommateur doit néanmoins connaître le producteur. Une ligne externe peut imiter une forme correcte ; une ligne interne n’atteste que ce qu’un serveur dit avoir vu. Le code 235 prouve le succès de l’échange, 530 l’exigence d’authentification et 535 l’échec des justificatifs. Aucun ne valide le contenu ou la politique de livraison du destinataire.

Les registres nommaient les choix

IANA maintient un registre des extensions SMTP et un autre des mécanismes SASL. Le premier rend AUTH intelligible ; le second permet de remplacer un mécanisme sans redessiner SMTP. Un nom peut devenir limité ou obsolète tandis que l’interface demeure.

Cette coordination est mince. IANA ne gère pas les comptes, n’accorde pas le relais et ne relie pas un identifiant à une boîte. Le serveur choisit ses mécanismes et ses délégations ; le client choisit ce qu’il accepte ; chaque opérateur répond d’une configuration ancienne ou excessive.

SMTP AUTH réussit ainsi en refusant une conclusion séduisante. L’identifiant ouvre un service précis, sous une politique précise. Il peut laisser une preuve de saut et une provenance transmise avec prudence. Il ne signe jamais la lettre.

Sources