Résumé

  • RFC4865 autorise un client à confier au serveur de soumission l’attente précédant la remise d’un message au circuit de livraison. Elle n’en fait ni une livraison à heure exacte ni une réservation des ressources de tout le trajet.
  • Une demande combinant remise différée et échéance DELIVERBY doit respecter des obligations distinctes côté client et côté serveur. Refuser une contradiction protège ces obligations ; accepter une demande cohérente laisse encore à gérer les horloges, les quotas et les suites de l’échéance.

Une instruction dit d’attendre. L’autre dit qu’il sera bientôt trop tard. Présentées dans deux champs séparés d’une interface, elles peuvent sembler parfaitement raisonnables. Il suffit pourtant que l’échéance de livraison précède la fin de l’attente pour qu’elles deviennent incompatibles.

Prenons un cas fictif : un utilisateur soumet le matin un message qui ne doit être libéré qu’à midi, avec une consigne d’arrêt des tentatives de livraison après onze heures. Il ne s’agit ni d’un incident observé ni d’un essai effectué pour cet article. L’exemple sert à isoler un problème que la capacité du réseau ne peut pas résoudre. Modifier l’une des deux heures change la demande ; ce n’est pas simplement mieux l’exécuter.

C’est une façon utile de lire RFC4865, publiée en mai2007. Son extension Future Message Release donne au client un stockage côté serveur pour les messages à libérer ultérieurement. Un terminal qui ne peut pas conserver une file locale ou rester disponible à l’heure prévue y gagne une faculté pratique. Le serveur reçoit en échange du contenu à garder, des ressources à consacrer à cette garde et une responsabilité temporelle.

La question de gouvernance commence au moment où cette facilité est vendue comme une promesse plus large. Qui peut annoncer une heure ? Qui paie l’attente ? Qui décide de sacrifier une contrainte lorsque deux demandes se contredisent ? Et quelles observations permettront ensuite de dire ce qui s’est réellement passé ?

Ce que le serveur promet en acceptant d’attendre

Future Message Release appartient à la soumission SMTP, pas au relais SMTP ordinaire. Le serveur annonce FUTURERELEASE dans sa réponse EHLO avec deux bornes : une durée maximale et une date-heure future maximale. Le client vérifie la présence de l’extension puis utilise exactement un paramètre d’attente dans MAIL.

HOLDFOR exprime une durée ; HOLDUNTIL, une date-heure. Chaque valeur doit respecter la limite correspondante annoncée par le serveur. L’absence de paramètre ne vaut pas demande d’une attente par défaut. On ne peut donc pas déduire une politique de programmation du seul fait qu’un serveur propose l’extension.

Les deux formes répondent à des capacités différentes des clients. Une machine peut disposer d’une heure locale sans information de fuseau suffisamment utile ; une autre peut mal connaître l’heure absolue. La coexistence des deux mécanismes est un compromis pratique décrit par le document. Elle n’abolit pas le problème de l’horloge.

Pour un message accepté avec cette demande, le serveur ne doit pas le libérer avant l’écoulement de la durée ou l’arrivée de l’instant indiqué. Cette obligation fixe une limite inférieure. Elle ne dit pas que la libération aura lieu exactement à la première seconde autorisée. Elle dit encore moins que le destinataire recevra ou lira le message à cet instant.

La distinction est essentielle pour un produit de programmation. Le calendrier peut montrer une heure précise alors que le contrat technique porte d’abord sur l’interdiction de partir plus tôt. Il faut encore observer la mise en circulation effective, l’acceptation par l’étape suivante et la livraison. Une seule date visible ne résume pas ces événements.

Le délai de livraison n’est pas une voie rapide

RFC2852 définit DELIVERBY avec une autre fonction. Le client indique une période de livraison et choisit le traitement applicable si le message ne peut être livré dans cette période. La spécification refuse explicitement d’en faire une demande de priorité. Le serveur peut décider d’accélérer le traitement ; l’extension ne l’y oblige pas.

Ce délai n’est pas non plus une date de départ différé, et il n’allonge pas la durée normale de conservation des messages impossibles à livrer. Il serait donc trompeur de présenter deux champs « départ » et « arrivée » comme les extrémités d’un créneau intégralement réservé.

Le mode Return impose une limite aux tentatives ultérieures lorsque le message n’a pas été livré ou relayé avant l’échéance, avec une notification d’échec pour les destinataires concernés par les conditions de notification. Le mode Notify permet, lui, de poursuivre les tentatives selon la politique locale et prévoit la notification de retard correspondante. Le dépassement de l’heure n’a pas le même effet dans les deux cas.

Une interface peut appeler les deux situations « délai dépassé ». L’automatisation ne devrait pas les confondre. Continuer un travail en mode Return ou l’abandonner automatiquement en mode Notify reviendrait à appliquer à une demande les conséquences prévues pour l’autre.

La continuité du trajet est elle aussi conditionnelle. Un message en mode Return ne doit pas être relayé vers un serveur dépourvu de DELIVERBY, ni vers un serveur dont le minimum fixe dépasse le temps restant. Notify peut traverser une étape non compatible, moyennant les conséquences de notification prévues. L’obligation ne voyage pas indépendamment des capacités des acteurs qui la reprennent.

Enfin, le compte rendu d’échec n’est pas assuré de revenir aussi vite que le délai a expiré. RFC2852 précise que les notifications ne bénéficient pas nécessairement d’un traitement accéléré. Borner les tentatives n’est pas borner le temps nécessaire pour apprendre qu’elles ont cessé.

Une asymétrie à ne pas effacer

Lorsque les deux extensions sont utilisées ensemble, RFC4865 demande au client de placer le délai de livraison strictement après l’heure de libération, qu’elle soit explicite ou déduite d’une durée. C’est l’obligation du client, formulée à la section5.2.1.

La règle du serveur à la section5.2.2 est rédigée différemment : s’il prend en charge les deux extensions et détermine que la libération est plus tardive que la limite de livraison, il doit rejeter MAIL. Le document recommande alors la réponse501 et le code d’état amélioré5.5.4.

Cette formulation ne doit pas être remplacée sans le dire par une comparaison « supérieure ou égale ». Mais elle ne permet pas davantage au client d’envoyer légalement deux instants égaux. La demande du client resterait contraire à son obligation d’assurer un délai strictement postérieur.

Un test sérieux sépare donc les deux questions. A-t-on vérifié l’ordre strict exigé du client ? Qu’a fait le serveur face à chaque valeur limite ? Si le comportement à égalité a une importance opérationnelle, il faut le mesurer sur l’implémentation concernée, sans attribuer à la norme une décision supplémentaire.

Le cas franchement contradictoire est moins subtil : retenir jusqu’après le terme de livraison ne constitue pas un travail que le serveur doit sauver en choisissant une préférence à la place de l’utilisateur. Refuser à l’entrée peut préserver à la fois la confidentialité temporelle et la règle d’arrêt, en obligeant leur propriétaire à les rendre compatibles.

Cela impose aussi de conserver le stade exact de l’échange. Une réponse favorable à MAIL ne signifie pas que l’ensemble du message a finalement été accepté, encore moins livré. RFC2852 rappelle qu’une impossibilité peut devenir apparente lors du traitement des destinataires ou à l’achèvement des données. Un tableau de bord qui agrège toutes les réponses positives fabrique un succès sans préciser son objet.

La file future consomme des ressources présentes

La valeur économique du service est de déplacer l’attente. Au lieu de peser sur le terminal, elle occupe le serveur. Celui-ci doit conserver le contenu alors même qu’il n’a pas encore le droit de le remettre au circuit de livraison.

L’authentification protège contre certains usages non autorisés ; elle ne suffit pas contre la consommation excessive d’un utilisateur autorisé. RFC4865 recommande une limite de stockage par utilisateur pour les messages en attente de libération. Si le serveur applique cette limite et constate que le nouveau message la dépasserait, il doit rejeter MAIL.

Il faut garder la condition entière. La recommandation de mettre en place un quota n’est pas une affirmation selon laquelle chaque serveur possède le même mécanisme de réservation. Et l’obligation de refuser un dépassement détecté dans un quota effectivement appliqué n’est pas une simple suggestion de confort.

Le vocabulaire d’état distingue le quota individuel, X.7.16, du quota système, X.7.17. Dans un cas, la marge manque pour l’utilisateur ; dans l’autre, elle manque à l’ensemble partagé. Attendre qu’une file particulière se vide et attendre le rétablissement du service commun sont deux diagnostics, pas une seule erreur assortie d’un délai de nouvelle tentative universel.

La forme de la charge future compte autant que le nombre d’octets déjà présents. Plusieurs utilisateurs peuvent programmer leurs messages pour des heures voisines sans dépasser chacun leur limite. Le problème peut alors se déplacer du stockage vers le débit de libération ou le transport sortant. C’est un scénario à tester, non un incident que les documents démontrent.

L’horizon maximal annoncé ne suffit donc pas à prouver la capacité future. Il expose une limite du service ; il ne montre ni la répartition des engagements déjà pris ni la faculté du réseau distant de les absorber. Une fonction qui permet de promettre longtemps à l’avance peut créer un stock d’obligations dont le coût opérationnel est peu visible au moment du clic.

Lu Heng analyse, dans sa Note32, les effets d’une séparation entre pouvoir et conséquences économiques. Appliquée ici, cette grille conduit à rapprocher le choix des limites commerciales de la responsabilité de garder puis de libérer les messages. Elle ne permet pas d’attribuer de mauvaises intentions à une entreprise ou à ses ingénieurs. Sa Note36 sur BTW.Media rappelle justement que le produit éditorial doit être la description de la structure, non la promotion d’un camp.

L’horloge et la preuve ne se remplacent pas

On pourrait croire qu’une durée HOLDFOR protège le service d’une mauvaise heure absolue. RFC4865 avertit pourtant que les horloges inexactes ou changeantes du serveur peuvent provoquer une libération prématurée ou tardive avec les deux mécanismes. Un choix de syntaxe côté client ne certifie pas la base temporelle du serveur.

Il faut dès lors conserver l’instruction d’origine à côté des observations. Si le serveur produit une DSN au sujet d’un message programmé, la spécification exige les champs Arrival-Date et Future-Release-Request dans la partie lisible par machine. Ils maintiennent le contexte d’arrivée et la demande de maintien en attente. Ils ne constituent pas, à eux seuls, une mesure de l’instant réel de sortie.

Cette séparation permet de ne pas appeler « retard réseau » toute durée écoulée depuis la soumission. Une partie de l’attente pouvait être voulue. Inversement, une demande connue ne suffit pas à expliquer une libération longtemps après l’instant autorisé. Le contexte du contrat et l’exécution observée doivent pouvoir être rapprochés.

Le client n’a pas le droit de demander Future Message Release lorsqu’il soumet une DSN ou une notification de disposition MDN. La notification sur le traitement ne doit pas devenir, par ce mécanisme, une nouvelle notification volontairement différée. Cela ne garantit pas que le réseau ne retardera jamais ces messages ; la restriction porte sur la demande faite au service.

Le champ Date du message n’est pas un journal de la file. RFC4865 indique qu’il reste inchangé après soumission ; le client peut choisir d’y placer la date future, sans que le transport soit censé modifier les traces pour masquer le délai. Il faut distinguer cette règle du droit limité de compléter une date manquante ou d’en corriger la syntaxe au stade de la soumission, décrit par RFC6409.

Ce dernier document remplace RFC4409 et explicite la séparation entre soumission et relais. La soumission utilise normalement le port587 ; la possibilité générale de désigner certains services sur25 comme services de soumission n’autorise pas à annoncer FUTURERELEASE sur un service de relais ordinaire. La frontière fonctionnelle de l’extension reste déterminante.

Une base documentaire, pas un banc d’essai

L’erratum2040 de RFC4865, vérifié et de nature éditoriale, remplace une référence grammaticale sans définition par la production date-time de RFC3339. La remarque du rapporteur en2010 sur son propre serveur constitue un témoignage historique attribué, pas un inventaire des déploiements actuels.

L’erratum éditorial2300 de RFC2852 est conservé pour une mise à jour du document ; il concerne les espaces manquants dans la grammaire. Il ne modifie pas les modes de dépassement ni leur effet. Ces statuts doivent être respectés au même titre que les obligations du texte principal.

Aucun essai SMTP, changement d’horloge ou accès à une file de production n’a été effectué pour cette analyse. Les textes permettent de déterminer ce qu’il faut demander et vérifier. Ils ne prouvent pas comment un fournisseur concret gère une égalité, une pointe de charge ou une reprise après incident.

Le bon résultat n’est donc pas toujours un message de plus accepté. C’est parfois une contradiction renvoyée à son auteur avant qu’elle ne devienne un engagement opaque. Un service fiable doit savoir attendre ; il doit aussi savoir dire qu’aucun instant ne permet d’honorer les deux instructions reçues.

Sources