← RFC Reference

RFC 3030 – SMTP BINARYMIME et CHUNKING

Pourquoi cette RFC existe

SMTP traditionnel utilise la commande DATA pour transférer le contenu des messages. Le corps du message est envoyé sous forme de flux de texte, terminé par une ligne contenant uniquement un point (.\r\n). Cette conception présente deux problèmes :

• Surcharge du point d'échappement : Toute ligne du message commençant par un point doit être échappée en ajoutant un point supplémentaire. Le serveur doit analyser chaque ligne pour supprimer l'échappement. Cela ajoute une surcharge de traitement et peut introduire des bogues.
• Pas de support binaire : La commande DATA suppose un texte ASCII 7 bits avec des terminaisons de ligne CRLF. Le contenu binaire (comme les pièces jointes) doit être encodé en Base64, ce qui augmente la taille des données d'environ 33 %.

RFC 3030 définit deux extensions connexes qui résolvez ces problèmes. CHUNKING introduit la commande BDAT, qui transfère les données en blocs de taille explicite — aucun point d'échappement requis. BINARYMIME s'appuie sur CHUNKING pour permettre le contenu binaire brut sans aucun encodage.

Fonctionnement

CHUNKING (la commande BDAT)

1. Le serveur annonce CHUNKING dans sa réponse EHLO.
2. Au lieu de DATA, le client utilise BDAT <size> pour envoyer un bloc d'exactement <size> octets.
3. Le serveur lit exactement ce nombre d'octets, puis envoie une réponse.
4. Le client peut envoyer plusieurs blocs BDAT. Le dernier bloc inclut le mot-clé LAST : BDAT <size> LAST.
5. Aucun point d'échappement n'est nécessaire car la taille est explicite.

BINARYMIME

1. Le serveur annonce à la fois CHUNKING et BINARYMIME dans sa réponse EHLO.
2. Le client déclare BODY=BINARYMIME sur la commande MAIL FROM.
3. Les données du message sont envoyées via BDAT et peuvent contenir du contenu binaire brut — aucun encodage Base64, aucune exigence de terminaison de ligne CRLF.

Exemple SMTP

Envoi d'un message utilisant BDAT au lieu de DATA :

Avec BINARYMIME pour le contenu binaire brut :

Détails techniques clés

BDAT vs. DATA

Dimensionnement des blocs

Aucune taille de bloc n'est obligatoire. Les clients choisissent généralement les tailles de blocs en fonction de la mémoire disponible et des conditions du réseau. Les stratégies courantes incluent l'envoi du message entier sous la forme d'un seul BDAT ... LAST, ou la division en blocs de quelques centaines de kilooctets. Les blocs plus petits permettent la détection d'erreurs intermédiaires ; les blocs plus grands réduisent la surcharge du protocole.

Récupération d'erreurs

Si le serveur rejette un bloc BDAT (par exemple, le message est trop volumineux), le client peut émettre BDAT 0 LAST pour terminer la transaction correctement. Cela est plus propre que le modèle DATA, où le client doit envoyer le message entier et le terminateur par point même s'il sait que le serveur le rejettera.

Transfert BINARYMIME

Un serveur qui reçoit un message BINARYMIME ne doit pas le transférer à un serveur qui ne supporte pas BINARYMIME. Si le prochain saut n'annonce pas BINARYMIME, le serveur de transfert doit convertir les parties de contenu binaire en encodage Base64 avant de les relayer. Il s'agit d'une exigence critique d'interopérabilité.

Erreurs courantes

• Utilisation de BDAT sans vérifier CHUNKING. Tous les serveurs ne supportent pas CHUNKING. Vérifiez toujours la réponse EHLO avant d'utiliser BDAT. Si CHUNKING n'est pas annoncé, revenir à DATA.
• Envoi de BODY=BINARYMIME quand le prochain saut ne le supporte pas. Si vous êtes un serveur de relais et le MTA aval n'annonce pas BINARYMIME, vous devez ré-encoder les parties binaires en Base64 avant de les transférer. L'envoi de binaire brut à un serveur qui ne le comprend pas corrompt le message.
• Mauvais nombre d'octets. La taille dans BDAT doit correspondre exactement au nombre d'octets qui suivent. Envoyer trop peu ou trop d'octets désynchronise le protocole et corrompt la session.
• Oublier le mot-clé LAST. Le bloc BDAT final doit inclure LAST. Sans cela, le serveur attend d'autres blocs et la session s'arrête.
• Mélanger BDAT et DATA. Un client doit utiliser soit DATA soit BDAT pour un message donné, jamais les deux. Basculer en cours de transaction est une erreur de protocole.
• Ne pas gérer les erreurs de bloc intermédiaire. Si un bloc BDAT non final renvoie une erreur, le client doit envoyer BDAT 0 LAST pour réinitialiser la transaction plutôt que de continuer à envoyer des données.

Impact sur la délivrabilité

• Bande passante réduite pour les pièces jointes binaires. BINARYMIME élimine la surcharge de 33 % de l'encodage Base64. Pour une pièce jointe de 10 Mo, cela économise environ 3,3 Mo de données de transfert. Cela a de l'importance à l'échelle.
• Traitement plus rapide des messages volumineux. BDAT avec des tailles explicites permet au serveur d'allouer la mémoire à l'avance et de sauter l'analyse ligne par ligne. Cela réduit la surcharge CPU des deux côtés.
• Gestion d'erreurs plus propre. Les réponses de bloc intermédiaire permettent aux clients de détecter les défaillances rapidement sans transmettre le message entier. Cela économise la bande passante et le temps de connexion quand un message sera rejeté.
• Large support parmi les principaux fournisseurs. Google, Microsoft et la plupart des grandes plates-formes de messagerie supportent CHUNKING. L'utiliser quand disponible est une meilleure pratique pour une livraison efficace.
• Élimine les bogues d'échappement de points. BDAT supprime toute une classe de bogues potentiels liés à l'échappement de points et à la gestion des terminaisons de ligne. Les messages arrivent exactement comme envoyés, octet par octet.

Related RFCs