← RFC Reference

RFC 5321 – Protocole simple de transfert de courrier

Pourquoi cette RFC existe

SMTP est le protocole le plus ancien et le plus fondamental alimentant le courrier électronique. Son origine remonte à la RFC 821, publiée en 1982 par Jon Postel. La RFC 5321, publiée en 2008, est la spécification définitive actuelle. Elle a consolidé des décennies d'extensions, de clarifications et d'expérience opérationnelle dans un seul document faisant autorité.

L'évolution clé de la RFC 821 à la 5321 comprend : la formalisation d'ESMTP (Extended SMTP), la clarification du comportement de relais par rapport à l'envoi, des exigences plus strictes concernant les recherches MX DNS, des règles mises à jour pour les littéraux d'adresses et IPv6, et des exigences pour la gestion des retours. Cette RFC est la base sur laquelle toutes les autres RFC de courrier électronique s'appuient.

Comment cela fonctionne

Une transaction SMTP est une conversation structurée entre deux serveurs sur une connexion TCP (traditionnellement le port 25). Le protocole est basé sur du texte et orienté ligne — chaque commande et réponse est un ASCII lisible.

Le modèle SMTP

SMTP définit trois rôles :

• Client SMTP (Sender-SMTP) : Le système qui initie la connexion pour transférer un message.
• Serveur SMTP (Receiver-SMTP) : Le système qui accepte la connexion et reçoit le message.
• Relais SMTP : Un serveur qui reçoit un message et le transfère vers sa destination finale, agissant à la fois comme client et serveur.

Le client se connecte, s'identifie avec EHLO, spécifie l'expéditeur de l'enveloppe (MAIL FROM), un ou plusieurs destinataires (RCPT TO), puis transmet les données du message (DATA). Le serveur répond à chaque commande par un code d'état à trois chiffres.

Les commandes SMTP

Codes de réponse

Chaque réponse du serveur commence par un code à trois chiffres. Le premier chiffre indique au client ce qui s'est passé :

• 2xx — Succès. L'action demandée a été complétée.
• 3xx — Intermédiaire. Le serveur a besoin de plus d'entrées (utilisé après DATA).
• 4xx — Échec temporaire. Le client doit réessayer plus tard. Exemples : boîte aux lettres pleine (452), serveur occupé (421).
• 5xx — Échec permanent. Ne pas réessayer. Exemples : utilisateur inconnu (550), erreur de syntaxe (500), relais refusé (553).

Le deuxième chiffre affine la catégorie : x0x = syntaxe, x1x = information, x2x = connexion, x5x = système de messagerie. La RFC 3463 étend davantage ces codes avec des codes d'état améliorés comme 5.1.1 (mauvaise boîte aux lettres de destination).

Détails techniques clés

Enveloppe par rapport aux en-têtes

Une distinction critique dans SMTP est celle entre l'enveloppe et les en-têtes du message. L'enveloppe (MAIL FROM et RCPT TO) contrôle l'acheminement — elle indique aux serveurs où livrer le message. Les en-têtes du message (From:, To:, Subject:) font partie du corps du message transmis pendant DATA et sont ce que le destinataire voit. Ceux-ci peuvent différer, et ils le font légitimement dans des cas comme les listes de diffusion, BCC et la redirection.

Processus de recherche MX

Quand un client doit livrer à user@example.com, il interroge le DNS pour les enregistrements MX de example.com. Le processus défini par la RFC 5321 :

1. Rechercher les enregistrements MX du domaine. Trier par préférence (numéro inférieur = priorité supérieure).
2. S'il n'existe pas d'enregistrements MX, revenir à un enregistrement A ou AAAA du domaine lui-même.
3. Si un enregistrement MX pointe vers . (un « MX nul » selon la RFC 7505), le domaine n'accepte pas de courrier.
4. Essayer chaque hôte MX dans l'ordre de priorité. Si un serveur retourne une erreur 4xx, essayer l'hôte suivant.

Longueur de ligne et transparence des données

SMTP exige que les lignes du message ne dépassent pas 998 caractères (excluant CRLF), avec une limite recommandée de 78 caractères. Le marqueur de fin de données est une ligne contenant uniquement un point (.). Si une ligne du corps du message commence par un point, le client doit « doubler le point » en ajoutant un point supplémentaire, et le serveur doit le supprimer.

Délais d'expiration

La RFC 5321 spécifie les délais d'expiration minimums que les clients DOIVENT respecter :

• Message d'accueil initial : 5 minutes
• Commande MAIL : 5 minutes
• Commande RCPT : 5 minutes
• Initiation DATA : 2 minutes
• Bloc de données : 3 minutes
• Terminaison DATA (point final) : 10 minutes

Ces délais généreux existent parce que les serveurs de réception peuvent effectuer des vérifications coûteuses (filtrage des spam, analyse antivirus) avant de répondre au point final.

Exemple SMTP

Une transaction SMTP complète livrant un message :

Erreurs courantes

• Confondre les adresses d'enveloppe et d'en-tête. L'adresse d'enveloppe MAIL FROM n'est pas la même que l'en-tête From:. Les vérifications SPF contrôlent l'expéditeur de l'enveloppe ; DKIM signe l'en-tête. Faire cette erreur cause des échecs d'authentification.
• Ignorer la distinction 4xx par rapport à 5xx. Un 450 signifie « réessayer plus tard » — vous devez mettre en file d'attente et réessayer avec une réduction exponentielle. Un 550 signifie « ne va jamais fonctionner » — continuer à réessayer génère du trafic inutile et peut nuire à votre réputation d'expéditeur.
• Ne pas gérer les réponses multi-lignes. Une réponse comme 250- (avec un tiret) signifie que d'autres lignes suivent. Seul 250 (avec un espace) signale la ligne finale.
• Envoyer sans EHLO. Utiliser l'ancienne commande HELO à la place d'EHLO signifie que vous ne découvrirez pas les extensions du serveur comme STARTTLS, SIZE ou PIPELINING. Utilisez toujours EHLO.
• Dépasser les limites de longueur de ligne. Les lignes de plus de 998 caractères violent la spécification et peuvent causer une corruption du message. Utilisez l'encodage MIME pour le contenu long.
• Ignorer l'expéditeur nul. Les messages de retour (DSN) utilisent un MAIL FROM:<> vide. Rejeter l'expéditeur nul casse le mécanisme de prévention de boucle de retour.
• Ne pas implémenter le doublement du point. Si le corps de votre message a une ligne commençant par ., le serveur l'interprétera comme fin de données à moins que vous doubliez le point.

Impact sur la délivrabilité

La conformité à la RFC 5321 affecte directement si votre courrier électronique atteint la boîte de réception :

• Nom d'hôte EHLO approprié. Votre nom d'hôte EHLO doit être résolvable dans le DNS (forward et reverse). De nombreux serveurs de réception vérifient que le nom EHLO a un enregistrement A/AAAA valide et que le DNS inverse pour votre IP correspond. Les non-concordances sont un signal de spam.
• Gestion des retours. La RFC 5321 exige que les expéditeurs traitent les retours. Si vous ignorez les DSN, vous continuerez à envoyer aux adresses invalides, ce qui détruit votre réputation d'expéditeur. Les fournisseurs de boîtes aux lettres suivent votre taux de retour de près.
• Comportement de nouvelle tentative. La logique de nouvelle tentative appropriée avec réduction exponentielle pour les erreurs 4xx montre que vous êtes un expéditeur bien comporté. Le comportement de nouvelle tentative agressif peut déclencher une limitation de débit ou une mise en liste noire.
• Comportement de connexion. Ouvrir trop de connexions simultanées à un seul MX, ou se reconnecter trop rapidement après avoir été rejeté, sont des modèles associés au spam. Respectez les limites de connexion et limitez le débit de manière appropriée.
• Alignement de l'enveloppe. SPF et DMARC s'appuient sur le domaine MAIL FROM. S'assurer que votre domaine d'expéditeur de l'enveloppe s'aligne avec votre domaine d'en-tête From: est essentiel pour réussir les vérifications d'authentification.

Related RFCs