Résumé
- Dans le SMTP initial, un échec de taille ou de stockage pouvait n’apparaître qu’après la transmission complète de DATA et son abandon par le destinataire.
- RFC 1870 autorisa le serveur à annoncer un plafond fixe dans EHLO et le client à estimer les octets dans MAIL FROM. Le refus définitif prit le code 552 ; le manque provisoire, 452.
- Le nombre resta un indice limité : il ne bornait pas DATA, ne réservait pas tous les stockages ultérieurs et ne faisait pas d’une réponse positive une garantie de remise.
Un refus placé après le coût
RFC 821 ordonnait la transaction : MAIL, un ou plusieurs RCPT, puis DATA. Après la réponse 354, l’expéditeur envoyait l’en-tête, le corps et la ligne de fin. Le serveur ne répondait à l’objet achevé qu’après l’avoir reçu.
Cette séquence était nette, mais certaines connaissances arrivaient trop tard. Un serveur pouvait déjà savoir qu’une limite administrative rendait l’objet impossible. Il pouvait aussi manquer momentanément d’espace. Sans extension, le client devait néanmoins transmettre chaque octet avant que le serveur jette le message. Avec l’essor du courrier multimédia, l’échec tardif consommait ligne, temps et tampon sans ouvrir de voie vers le succès.
Deux déclarations qui ne se confondent pas
L’idée parut dans RFC 1427 en 1993, fut révisée par RFC 1653, puis stabilisée dans RFC 1870 en 1995. Le serveur publie SIZE dans sa réponse EHLO. Un nombre facultatif indique le plus grand message qu’il acceptera toujours selon sa limite fixe.
Zéro signifie qu’aucun maximum fixe n’est en vigueur. L’absence de nombre signifie seulement qu’aucune information sur ce maximum n’est donnée. Elle ne veut pas dire capacité infinie. Le client peut ensuite ajouter SIZE à MAIL FROM pour annoncer son estimation du message particulier. Quand le calcul exact est difficile, l’estimation peut être heuristique et devrait plutôt surestimer.
Le protocole fait ainsi dialoguer deux autorités sans les fusionner. L’administrateur possède la règle du serveur ; l’expéditeur connaît la représentation qu’il veut envoyer. Aucun nombre ne commande à lui seul l’autre machine.
Compter sans encadrer
La taille comprend les octets transmis après 354 : en-tête, corps et paires CR-LF. Elle exclut le point terminal de DATA et les points supplémentaires introduits pour la transparence SMTP. Cette définition rend les observations comparables.
Mais RFC 1870 interdit au serveur d’employer SIZE pour trouver la fin du contenu. Une estimation erronée peut modifier la décision d’acceptation ; elle ne peut transformer les octets suivants en commandes. Le terminateur DATA conserve son rôle. SIZE traite donc des ressources, non de l’encadrement — frontière essentielle avec l’histoire de la transparence par points et de BDAT.
Le temps change la nature du refus
Si la valeur dépasse le plafond fixe, le serveur peut répondre 552. Réessayer plus tard le même objet contre la même règle ne changera rien. S’il manque seulement de ressources aujourd’hui, 452 demande au client de réinitialiser ou de quitter, puis de remettre le message en file.
La distinction distribue le travail futur. Prendre un refus permanent pour une panne temporaire fabrique des tentatives inutiles. Prendre une pénurie passagère pour une interdiction détruit une remise encore possible. Le serveur peut aussi appliquer la taille à chaque destinataire : accepter un RCPT, en différer un autre et en refuser définitivement un troisième. Une estimation commune ne supprime pas les politiques locales des boîtes et des canaux.
Une permission précoce n’est pas une réception
Une réponse 250 à MAIL ne garantit rien d’absolu. Les ressources peuvent varier, DATA peut dépasser la déclaration, un relais ultérieur peut refuser et la livraison finale reste à accomplir. Le serveur peut tolérer un message plus grand qu’annoncé, mais n’y est pas obligé.
RFC 1870 crée néanmoins une confiance bornée : après avoir accepté la taille déclarée, le serveur ne devrait pas invoquer son plafond ordinaire par un 552 post-DATA si la taille réelle n’a pas dépassé cette déclaration. Le mécanisme avance une décision sans aspirer toutes les décisions suivantes.
RFC 5321 imposa plus tard une capacité minimale de 64 Kio et recommanda SIZE aux systèmes contraints. Il ne fixa pas une taille mondiale des pièces jointes. Chaque relais gardait son disque, sa file et ses destinataires ; le standard rendait seulement une limite locale intelligible à temps.
Sources et limites
RFC 821 fournit la transaction originale. RFC 1427, RFC 1653 et RFC 1870 retracent l’extension ; RFC 1870 définit les comptes et réponses. RFC 5321 donne la règle ultérieure. Ces textes ne mesurent ni le déploiement actuel ni les plafonds des fournisseurs. SIZE n’authentifie pas un contenu, ne prouve pas un quota, ne réserve pas toute la route et ne vaut pas reçu. Il montre comment un chiffre faible, bien borné, peut éviter un travail condamné sans centraliser la décision.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
