← RFC Reference

RFC 2920 – Traitement par pipeline SMTP

Pourquoi cette RFC existe

SMTP standard est un protocole strict requête-réponse. Le client envoie une commande, attend la réponse du serveur, puis envoie la suivante. Chaque aller-retour ajoute de la latence, particulièrement sur les liaisons réseau à haute latence. Pour un message avec 50 destinataires, le client aurait besoin de 50 allers-retours distincts simplement pour les commandes RCPT TO.

RFC 2920 définit l'extension SMTP PIPELINING, qui permet au client d'envoyer plusieurs commandes par lot sans attendre les réponses individuelles. Le serveur met en buffer et traite les commandes dans l'ordre, puis renvoie toutes les réponses. Cela réduit dramatiquement le temps total d'une session SMTP.

Le pipelining est l'une des extensions SMTP les plus largement supportées. Presque chaque serveur mail moderne l'annonce, et la plupart des bibliothèques clientes SMTP l'utilisent par défaut.

Comment ça marche

1. Le client envoie EHLO et confirme que le serveur annonce PIPELINING dans sa liste de capacités.
2. Le client groupe ensemble les commandes qu'il est sûr de pipeline — typiquement MAIL FROM, un ou plusieurs RCPT TO, et DATA.
3. Le client envoie toutes ces commandes en rapide succession sans attendre les réponses individuelles.
4. Le serveur traite chaque commande dans l'ordre et envoie une réponse par commande, dans l'ordre.
5. Le client lit toutes les réponses et gère les erreurs (ex. un destinataire rejeté).

Exemple SMTP

Sans pipelining (5 allers-retours pour l'enveloppe) :

Avec pipelining (1 aller-retour pour l'enveloppe entière) :

Détails techniques clés

Quelles commandes peuvent être pipelinées

Pas toutes les commandes SMTP sont sûres à pipeliner. RFC 2920 divise les commandes en deux catégories :

Les commandes qui changent l'état de la connexion (EHLO, STARTTLS, AUTH) sont des points de synchronisation — le client doit attendre la réponse avant d'envoyer quoi que ce soit d'autre.

Gestion des erreurs

Lors du pipelining, certaines commandes dans un lot peuvent réussir tandis que d'autres échouent. Le client doit faire correspondre les réponses aux commandes dans l'ordre. Une RCPT TO rejetée n'invalide pas la transaction entière — le message est toujours livré aux destinataires acceptés. Cependant, si MAIL FROM est rejeté, les commandes RCPT TO suivantes échoueront aussi.

Considérations du buffering TCP

Le pipelining repose sur le buffering TCP. Le client écrit plusieurs commandes sur le socket sans lire, en se fiant au fait que le tampon d'envoi TCP peut les contenir. Pour de très grands lots de commandes RCPT TO (centaines ou milliers), le client peut avoir besoin de pipeliner par groupes pour éviter de remplir le tampon TCP et de se bloquer mutuellement.

Interaction avec STARTTLS

Après une réponse EHLO qui inclut STARTTLS, le client ne doit pas pipeliner STARTTLS avec d'autres commandes. La négociation TLS change l'état de toute la connexion, donc c'est un point de synchronisation strict. Après que TLS soit établi et qu'un nouvel EHLO soit envoyé, le pipelining peut reprendre.

Erreurs courantes

• Pipeliner EHLO ou STARTTLS avec d'autres commandes. Ce sont des points de synchronisation. Les pipeliner cause des erreurs de protocole parce que la réponse du serveur change l'état de session dont les commandes suivantes dépendent.
• Ne pas lire toutes les réponses avant d'agir sur les erreurs. Si vous pipelinéz 5 commandes, vous devez lire les 5 réponses, même si la première est une erreur. Abandonner le flux de réponse corrompt l'état du protocole.
• Supposer que tous les serveurs supportent le pipelining. Bien qu'à peu près universel, le pipelining est une extension. Vérifiez toujours la réponse EHLO pour PIPELINING avant de l'utiliser. Retombez à un mode un-à-la-fois s'il est absent.
• Pipeliner après que MAIL FROM soit rejeté. Si MAIL FROM est rejeté et que vous avez déjà pipeliné des commandes RCPT TO, elles échoueront toutes. Lisez la réponse MAIL FROM avant de pipeliner les destinataires, ou soyez prêt à gérer les défaillances en cascade.
• Envoyer le contenu de DATA dans le pipeline. La commande DATA elle-même peut être pipelinée, mais le corps du message qui suit ne peut pas. Vous devez attendre la réponse 354 à DATA avant d'envoyer le contenu du message.

Impact sur la délivrabilité

• Livraison plus rapide pour les messages multi-destinataires. Le pipelining réduit un message à N destinataires de N+2 allers-retours à environ 2 allers-retours pour la phase d'enveloppe. Sur les connexions à haute latence, cela économise des secondes par message.
• Débit plus élevé pour l'envoi en masse. Lors de l'envoi de nombreux messages via la même connexion, le pipelining vous permet de chevaucher l'enveloppe du message suivant avec le transfert de données du message actuel, maximisant l'utilisation de la connexion.
• Temps de connexion réduit. Les sessions plus courtes signifient moins de temps à maintenir les connexions ouvertes. C'est important pour les serveurs qui appliquent des limites de temps par connexion ou des limites de débit basées sur la durée de connexion.
• Meilleur comportement sous charge. Le pipelining réduit le nombre d'allers-retours réseau, ce qui réduit la charge sur les serveurs d'envoi et de réception. Cela rend votre infrastructure d'envoi plus efficace.
• Le rejet par destinataire fonctionne toujours. Le pipelining ne réduit pas la capacité du serveur à rejeter des destinataires individuels. Chaque RCPT TO obtient toujours son propre code de réponse, donc la gestion des rebonds fonctionne exactement de la même manière.

Related RFCs