RFC 4954 : Extension SMTP AUTH

Piste Standard Authentification des e-mails Published March 2026

ELI5: Imaginez un bureau de poste où n'importe qui peut entrer et déposer du courrier en prétendant être quelqu'un d'autre. Le chaos, non ? SMTP AUTH est le contrôle d'identité au comptoir. Avant de remettre votre courrier, vous prouvez qui vous êtes — nom d'utilisateur, mot de passe, tout. Ce n'est qu'après que le commis vérifie votre identité que vous pouvez soumettre votre message. Sans AUTH, SMTP est une porte grande ouverte aux abus.

Pourquoi cela existe

Le SMTP original (RFC 5321) n'avait aucun concept d'authentification de l'expéditeur. N'importe quel client pouvait se connecter à n'importe quel serveur et envoyer du courrier en tant que n'importe qui. Cette conception fonctionnait au début d'Internet où tous les participants étaient de confiance, mais elle est devenue le fondement du problème du spam.

La RFC 4954 définit l'extension AUTH du SMTP, fournissant une façon standardisée pour les clients de s'authentifier auprès d'un serveur de courrier avant de soumettre des messages. Elle utilise le framework SASL (Simple Authentication and Security Layer), permettant à plusieurs mécanismes d'authentification d'être connectés sans modifier le protocole SMTP lui-même.

Cette RFC a rendu obsolète la RFC 2554 (1999), corrigeant les problèmes de sécurité et clarifiant l'interaction entre AUTH et d'autres extensions SMTP comme STARTTLS.

Fonctionnement

La négociation AUTH

Le client se connecte et envoie EHLO.
Le serveur annonce 250-AUTH suivi d'une liste des mécanismes SASL pris en charge.
Le client choisit un mécanisme et envoie AUTH <mechanism>, optionnellement avec une réponse initiale.
Le serveur et le client échangent une ou plusieurs séries de défi/réponse (dépend du mécanisme).
Le serveur répond avec 235 (authentification réussie) ou 535 (authentification échouée).

Transcription SMTP : AUTH PLAIN

Le mécanisme PLAIN envoie les identifiants dans une seule chaîne codée en Base64 contenant l'identité d'autorisation, l'identité d'authentification et le mot de passe :

# Se connecter et découvrir les capacités S: 220 smtp.mailertogo.com ESMTP C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-STARTTLS S: 250-AUTH PLAIN LOGIN XOAUTH2 S: 250-SIZE 26214400 S: 250 ENHANCEDSTATUSCODES # Passer à TLS en premier (toujours avant AUTH) C: STARTTLS S: 220 2.0.0 Ready to start TLS # ... handshake TLS ... re-EHLO requis C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-AUTH PLAIN LOGIN XOAUTH2 S: 250 ENHANCEDSTATUSCODES # Authentifier avec AUTH PLAIN # Base64 de "\0alice@example.com\0secretpassword" C: AUTH PLAIN AGFsaWNlQGV4YW1wbGUuY29tAHNlY3JldHBhc3N3b3Jk S: 235 2.7.0 Authentication successful # Maintenant autorisé à soumettre des messages C: MAIL FROM:<alice@example.com> S: 250 2.1.0 OK

Transcription SMTP : AUTH LOGIN

Le mécanisme LOGIN utilise un défi/réponse séparé pour le nom d'utilisateur et le mot de passe :

C: AUTH LOGIN S: 334 VXNlcm5hbWU6 ← Base64 de « Username: » C: YWxpY2VAZXhhbXBsZS5jb20= ← Base64 de « alice@example.com » S: 334 UGFzc3dvcmQ6 ← Base64 de « Password: » C: c2VjcmV0cGFzc3dvcmQ= ← Base64 de « secretpassword » S: 235 2.7.0 Authentication successful

Transcription SMTP : AUTH échouée

C: AUTH PLAIN AGJhZEBleGFtcGxlLmNvbQB3cm9uZw== S: 535 5.7.8 Authentication credentials invalid # Le client NE DOIT PAS tenter d'envoyer du courrier après un 535

Détails techniques clés

Mécanismes SASL

La RFC 4954 ne définit pas directement les mécanismes d'authentification. Elle fournit le framework ; les mécanismes proviennent du registre SASL. Les plus couramment utilisés en SMTP :

Mécanisme	Fonctionnement	Notes de sécurité
`PLAIN`	Chaîne Base64 unique : `\0authzid\0password`	Simple, largement pris en charge. À utiliser uniquement sur TLS.
`LOGIN`	Défi/réponse en deux étapes pour le nom d'utilisateur et le mot de passe	Non-standard mais omniprésent. À utiliser uniquement sur TLS.
`XOAUTH2`	Jeton porteur OAuth 2.0 dans une chaîne formatée	Aucun mot de passe transmis. Basé sur jeton, utilisé par Gmail et Microsoft 365.
`SCRAM-SHA-256`	Défi/réponse avec salt et liaison de canal	Mot de passe jamais envoyé, même hashé. Authentification mutuelle. Meilleure sécurité mais adoption limitée en SMTP.
`CRAM-MD5`	Défi/réponse avec HMAC MD5	Déprécié. MD5 est considéré comme faible. Évite d'envoyer le mot de passe mais ne protège pas contre les attaques par rejeu.

Format des identifiants AUTH PLAIN

Le mécanisme PLAIN encode trois champs séparés par des octets nuls (\0), puis encode le résultat en Base64 :

# Format : [authzid] \0 authcid \0 password # authzid = identité d'autorisation (généralement vide ou identique à authcid) # authcid = identité d'authentification (le nom d'utilisateur) # password = le mot de passe en texte clair # Exemple : authzid vide, authcid "alice@example.com", password "s3cret" \0alice@example.com\0s3cret # Encodé en Base64 : AGFsaWNlQGV4YW1wbGUuY29tAHMzY3JldA==

Optimisation de la réponse initiale

La RFC 4954 permet au client d'envoyer la réponse SASL initiale sur la même ligne que la commande AUTH (comme montré dans l'exemple PLAIN ci-dessus). Cela économise un aller-retour par rapport à l'approche ancienne en deux étapes où le serveur envoie d'abord un défi vide. Pour les mécanismes comme PLAIN où le client parle en premier, cette optimisation est standard.

Interaction avec STARTTLS

La RFC 4954 recommande fortement aux serveurs de ne pas annoncer AUTH jusqu'après l'établissement de TLS. Cela empêche les clients d'envoyer accidentellement les identifiants en texte clair. Le flux typique est :

Se connecter → EHLO → le serveur annonce STARTTLS mais pas AUTH
STARTTLS → handshake TLS
EHLO à nouveau → le serveur annonce maintenant AUTH (STARTTLS n'est plus listé)
AUTH → soumettre les messages

Codes de réponse

Code	Signification
`235`	Authentification réussie
`334`	Défi du serveur (continuation de l'échange SASL)
`432`	Changement de mot de passe nécessaire (le serveur nécessite un changement de mot de passe)
`454`	Défaut d'authentification temporaire (réessayez plus tard)
`500`	Commande AUTH non reconnue (le serveur ne prend pas en charge AUTH)
`534`	Mécanisme d'authentification trop faible (le serveur nécessite un mécanisme plus fort)
`535`	Identifiants d'authentification invalides

AUTH et identité MAIL FROM

Après une authentification réussie, le serveur associe la connexion à l'identité authentifiée. Le MSA peut ensuite appliquer que les adresses MAIL FROM et From: d'en-tête correspondent (ou soient autorisées pour) l'utilisateur authentifié. Cela empêche les utilisateurs authentifiés d'usurper l'identité d'adresses d'expéditeur arbitraires.

Erreurs courantes

Envoyer AUTH avant STARTTLS. Si le serveur annonce AUTH sur une connexion en texte clair (certains serveurs mal configurés le font), vos identifiants voyagent quand même en clair. Établissez toujours TLS avant de vous authentifier. Avec TLS implicite sur le port 465, c'est automatique.
Confondre l'encodage Base64 avec le chiffrement. Base64 est un encodage, pas un chiffrement. AUTH PLAIN envoie les identifiants dans un format trivial à décoder. La protection vient de la couche TLS, pas de Base64.
Ne pas gérer les erreurs 535. Une AUTH échouée signifie que le serveur a rejeté vos identifiants. Réessayer les mêmes identifiants en boucle vous fera mettre sur liste noire ou bloquer votre IP. Vérifiez les identifiants et échouez gracieusement.
Coder en dur AUTH LOGIN quand PLAIN est disponible. LOGIN est un mécanisme non-standard avec des implémentations incohérentes. Si le serveur prend en charge PLAIN, préférez-le. S'il prend en charge XOAUTH2 ou SCRAM, préférez ceux-ci.
Ne pas réémettre EHLO après STARTTLS. La liste des capacités change après l'établissement de TLS. AUTH ne peut apparaître que dans la réponse EHLO après TLS. Ignorer le second EHLO signifie que votre client ne découvre jamais la prise en charge d'AUTH.
Ignorer l'optimisation de la réponse initiale. Envoyer AUTH PLAIN sans les identifiants en ligne force un aller-retour supplémentaire inutile. La plupart des serveurs modernes prennent en charge la réponse initiale.
Utiliser CRAM-MD5 pour la « sécurité ». CRAM-MD5 évite d'envoyer le mot de passe en texte clair, mais il utilise MD5 (cassé), ne protège pas contre les attaques par rejeu et nécessite que le serveur stocke le mot de passe sous une forme récupérable. PLAIN sur TLS est strictement supérieur.

Impact sur la délivrabilité

Requis pour la soumission de messages. Tous les services de courrier modernes nécessitent SMTP AUTH pour la soumission (RFC 6409). Sans authentification, le serveur rejettera vos messages avec une réponse 530 (authentification requise).
Permet la liaison de l'identité de l'expéditeur. L'authentification lie chaque message à un compte connu. Cela permet au service de courrier d'appliquer les politiques d'envoi, d'appliquer les signatures DKIM et de suivre la réputation par expéditeur authentifié.
Empêche l'abus de relais ouvert. En nécessitant l'authentification avant d'accepter les messages pour la livraison, les serveurs évitent d'être exploités en tant que relais ouverts — ce qui entraînerait rapidement le blacklistage d'IP et l'échec de la livraison pour tous les utilisateurs sur le serveur.
OAuth2 pour les intégrations modernes. Des services comme Gmail et Microsoft 365 suppriment progressivement AUTH basé sur mot de passe au profit de XOAUTH2. La migration vers l'authentification basée sur jeton évite les perturbations de service lorsque l'authentification basique est désactivée.
Limitation de débit et prévention des abus. Les sessions authentifiées permettent une limitation de débit par utilisateur. Si un compte est compromis, le service peut réduire ou désactiver ce compte sans affecter les autres expéditeurs sur la même infrastructure.