RFC 6409 – Soumission de messages pour le courrier

Norme Internet SMTP principal et format de message Obsoletes RFC 4409 Published March 2026

ELI5: Imaginez la différence entre déposer une lettre dans une boîte aux lettres publique dans la rue et la remettre au guichetier au comptoir de la poste. La boîte aux lettres de rue (port 25) est destinée aux facteurs qui transfèrent le courrier entre les bureaux de poste. Le comptoir (port 587) est l'endroit où vous, en tant que client, soumettez votre lettre — vous montrez d'abord votre pièce d'identité, et le guichetier vérifie que tout est en ordre. RFC 6409 définit ce comptoir de poste pour le courrier électronique.

Pourquoi cette RFC existe

Aux débuts de la messagerie électronique, il n'y avait aucune distinction entre un utilisateur envoyant un nouveau message et un serveur relayant un mail d'un autre serveur. Les deux utilisaient le port 25, et n'importe qui pouvait se connecter et envoyer. Cela a conduit au problème des relais ouverts — les spammeurs exploitaient tout serveur qui acceptait et transférait les messages sans authentification.

La RFC 6409 (originellement RFC 2476 en 1998, mise à jour en RFC 4409 en 2006, et finalisée en 6409 en 2011) sépare formellement la soumission de messages du relayage de messages :

Soumission (port 587) : Un utilisateur authentifié ou une application soumet un nouveau message à son service de messagerie pour la livraison. Le serveur agit comme un MSA (RFC 5598).
Relayage (port 25) : Un serveur de messagerie transfère un message à un autre serveur de messagerie en route vers la destination. Le serveur agit comme un MTA.

Cette séparation est fondamentale pour la sécurité moderne de la messagerie. Elle permet l'authentification des expéditeurs, l'application des politiques et la capacité de bloquer le relayage non authentifié tout en acceptant les soumissions légitimes.

Comment cela fonctionne

La soumission de messages utilise le même protocole SMTP défini dans la RFC 5321, mais avec des différences importantes dans le comportement, la politique et le numéro de port.

Le processus de soumission

Le client (MUA ou application) se connecte au MSA sur le port 587.
Le client envoie EHLO et découvre les extensions disponibles.
Le client passe à TLS en utilisant STARTTLS (ou se connecte via TLS implicite sur le port 465 selon la RFC 8314).
Le client s'authentifie en utilisant AUTH (RFC 4954) — généralement PLAIN ou LOGIN sur TLS.
Le client soumet le message avec MAIL FROM, RCPT TO et DATA.
Le MSA valide le message, ajoute potentiellement les en-têtes manquants (Date, Message-ID) et le met en queue pour la livraison via l'infrastructure MTA.

Soumission vs. Relayage : côte à côte

Aspect	Soumission (MSA, port 587)	Relayage (MTA, port 25)
Objectif	Accepter les nouveaux messages des utilisateurs/applications	Transférer les messages entre serveurs
Authentification	Requise (SMTP AUTH)	Non requise (confiance serveur à serveur)
Chiffrement	Requis (STARTTLS ou TLS implicite)	Opportuniste (STARTTLS si disponible)
Validation de l'expéditeur	Le MSA vérifie que l'utilisateur authentifié est autorisé à utiliser l'adresse From	Le MTA vérifie SPF, DKIM, DMARC
Correction d'en-tête	Le MSA peut ajouter les en-têtes Date, Message-ID et MIME manquants	Le MTA ajoute uniquement l'en-tête Received
Qui se connecte	Les utilisateurs finaux, les applications, les services de messagerie	Les autres serveurs de messagerie

Exemple SMTP

Une session de soumission typique sur le port 587 :

# Le client se connecte au port 587 S: 220 smtp.mailertogo.com ESMTP Submission C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-STARTTLS S: 250-AUTH PLAIN LOGIN S: 250-SIZE 26214400 S: 250-8BITMIME S: 250 ENHANCEDSTATUSCODES # Passer d'abord à TLS C: STARTTLS S: 220 2.0.0 Ready to start TLS # La négociation TLS se fait ici, puis re-EHLO C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-AUTH PLAIN LOGIN S: 250-SIZE 26214400 S: 250-8BITMIME S: 250 ENHANCEDSTATUSCODES # S'authentifier (identifiants codés en Base64) C: AUTH PLAIN AGFsaWNlQGV4YW1wbGUuY29tAHNlY3JldA== S: 235 2.7.0 Authentication successful # Soumettre maintenant le message C: MAIL FROM:<notifications@example.com> S: 250 2.1.0 OK C: RCPT TO:<user@recipient.com> S: 250 2.1.5 OK C: DATA S: 354 Start mail input C: From: Example App <notifications@example.com> C: To: user@recipient.com C: Subject: Your order has shipped C: Date: Wed, 11 Mar 2026 14:00:00 +0000 C: Message-ID: <order-12345@example.com> C: C: Your order #12345 has been shipped and is on its way. C: . S: 250 2.0.0 OK, queued as abc123 C: QUIT S: 221 2.0.0 Bye

Détails techniques clés

L'authentification est requise

La RFC 6409 indique qu'un MSA DEVRAIT exiger l'authentification et NE DOIT PAS accepter les messages destinés au relayage de clients non authentifiés sauf s'il existe une politique organisationnelle spécifique le permettant. En pratique, chaque serveur de soumission moderne exige l'authentification. Le mécanisme standard est SMTP AUTH (RFC 4954) utilisant les mécanismes PLAIN ou LOGIN, toujours sur TLS.

Correction d'en-tête par le MSA

Contrairement à un MTA (qui ne doit pas modifier le contenu des messages), un MSA est censé examiner et corriger le message soumis :

Ajouter l'en-tête Date manquant si le client ne l'a pas inclus.
Ajouter Message-ID manquant pour s'assurer que chaque message a un identifiant unique.
Vérifier l'adresse From correspond à l'identité authentifiée, ou ajouter un en-tête Sender: pour indiquer l'entité réellement transmettrice.
Ajouter les en-têtes de traçage — le MSA ajoute son propre en-tête Received: comme première entrée.

Port 465 : TLS implicite

Historiquement, le port 465 a été brièvement assigné pour « SMTPS » (SMTP sur TLS implicite), puis réassigné, puis re-standardisé par la RFC 8314 en 2018. Aujourd'hui, le port 465 avec TLS implicite est l'approche recommandée pour la soumission — la négociation TLS se fait immédiatement à la connexion, avant toute commande SMTP. Le port 587 avec STARTTLS reste largement pris en charge et valide.

Limites de taille et de débit

Les MSA appliquent généralement des limites plus strictes que les MTA :

Limites de taille de message (généralement 10-25 MB)
Limites de débit par utilisateur authentifié (pour empêcher les comptes compromis de spammer)
Limites du nombre de destinataires par message et par période de temps
Restrictions d'adresse d'expéditeur (vous ne pouvez envoyer que depuis les adresses que vous êtes autorisé à utiliser)

Erreurs courantes

Envoyer sur le port 25 depuis une application. Les applications doivent toujours soumettre via le port 587 (ou 465) avec authentification. L'envoi direct au MX d'un destinataire sur le port 25 contourne l'authentification, la signature DKIM et la gestion de la réputation de votre service de messagerie. La plupart des plateformes cloud (AWS, GCP, Azure) bloquent le port 25 sortant par défaut.
Ne pas utiliser TLS avant AUTH. Envoyer les identifiants sur une connexion non chiffrée expose votre nom d'utilisateur et votre mot de passe SMTP. Toujours STARTTLS avant AUTH, ou utiliser TLS implicite sur le port 465.
Confondre les identifiants de soumission avec les identifiants de boîte aux lettres. Certains services utilisent des identifiants séparés pour la soumission SMTP par rapport à l'accès IMAP/POP. Vérifiez la documentation de votre fournisseur.
Ignorer les réponses de rejet du MSA. Si le MSA rejette votre message (par ex. adresse d'expéditeur non autorisée, message trop volumineux), votre application doit gérer cela correctement, et non ignorer silencieusement l'erreur.
Coder en dur le port 25 dans le code d'application. Les applications héritées qui se connectent au port 25 pour la soumission causent des problèmes de livrabilité et peuvent cesser de fonctionner entièrement à mesure que les FAI et les fournisseurs cloud bloquent de plus en plus ce port pour une utilisation non-serveur.
Ne pas réémettre EHLO après STARTTLS. Après la négociation TLS, vous devez envoyer un nouveau EHLO. La liste des capacités du serveur peut changer (AUTH est généralement annoncé uniquement après que le chiffrement soit établi).

Impact sur la livrabilité

L'authentification active la signature DKIM. Lorsque vous soumettez via un MSA, le service peut appliquer des signatures DKIM à vos messages. L'envoi direct à des MTA distants contourne cela, ce qui signifie que vos messages arrivent non signés et sont plus susceptibles d'être signalés comme spam.
Vérification de l'identité de l'expéditeur. Le MSA vérifie que vous êtes autorisé à envoyer depuis l'adresse que vous prétendez. Cela empêche votre compte d'être utilisé pour usurper l'identité d'autres domaines et maintient votre réputation d'envoi.
Gestion de la réputation. Votre service de messagerie (MSA) maintient une réputation d'adresse IP partagée. En routant via la soumission, vos messages bénéficient de la réputation établie du service auprès des principaux fournisseurs de boîtes aux lettres.
Traitement de la boucle de rétroaction. Un MSA qui traite vos messages peut suivre les rebonds, les plaintes et l'état de la livraison, fournissant les données dont vous avez besoin pour maintenir l'hygiène des listes et protéger votre réputation d'expéditeur.
TLS partout. La soumission sur TLS (obligatoire pour la soumission) assure que votre message est chiffré de votre application au service de messagerie. Le service gère ensuite le chiffrement pour le prochain saut, vous donnant une protection bout en bout en transit.