Résumé

  • Avec DELIVERBY, le client SMTP inscrivait un nombre de secondes dans l’enveloppe et choisissait entre deux conséquences : arrêter et retourner le message à l’échéance, ou signaler le retard tout en poursuivant les tentatives.
  • Chaque relais compatible devait transmettre le temps restant, jamais l’allocation initiale. L’extension ne garantissait ni priorité, ni livraison à temps, ni conservation prolongée, ni retour rapide de la notification.

La confusion paraît naturelle : si un message porte une échéance, le serveur devrait le traiter plus vite. RFC 2852 refusa pourtant cette conclusion. Un MTA pouvait accepter une demande Deliver By sans modifier la moindre priorité. Il pouvait conserver sa politique de file, sa répartition de ressources et ses intervalles de reprise.

Ce refus n’était pas une faiblesse. Il protégeait la différence entre le sens que l’expéditeur donne au temps et le coût que l’opérateur supporte pour transporter le message. L’un sait qu’une alerte ne doit plus déclencher un pager après 17 heures. L’autre sait quelle charge sa file peut absorber. Un protocole honnête devait permettre la rencontre de ces deux informations sans transformer la déclaration d’urgence en droit de commandement.

Publié en juin 2000, le Deliver By SMTP Service Extension fit de l’échéance une condition d’admission et de garde. Le serveur pouvait la refuser. S’il l’acceptait, il devait respecter le résultat choisi au terme du délai et transmettre aux relais compatibles un budget diminué.

L’admission précédait l’obligation

Le serveur annonce DELIVERBY dans sa réponse EHLO. Il peut ajouter un minimum fixe : l’intervalle le plus court qu’il accepte en mode Return. Le client place ensuite BY sur MAIL FROM. Aucun nouveau verbe n’est créé.

Le minimum donne au refus une forme publique. Un relais qui exige au moins 240 secondes ne doit pas accepter en mode Return un message dont il ne reste que 98 secondes. Il n’a pas besoin de prétendre qu’il fera de son mieux, puis d’effacer la contrainte. Sa capacité déclarée suffit à montrer que ce chemin ne peut pas reprendre l’obligation.

L’acceptation reste progressive. Le serveur peut répondre positivement à MAIL FROM, puis découvrir avec RCPT TO, DATA ou la fin des données que la demande ne peut être honorée. L’information sur les destinataires et le contenu n’arrive pas d’un bloc. Le premier succès atteste seulement que la condition était recevable à cette étape, non que chaque destinataire sera servi avant l’échéance.

Le temps voyageait comme différence

La valeur BY contient un nombre décimal signé de secondes, le mode R ou N, et éventuellement T pour la trace. La plage va de moins à plus 999 999 999 secondes.

Ce nombre est relatif. Le MTA récepteur l’ajoute à son heure locale pour former un deliver-by-time. Lorsqu’il relaie, il recalcule le nombre de secondes restantes au plus près de l’émission du nouveau MAIL FROM.

Cette architecture évite d’exiger deux horloges parfaitement alignées. Elle ne supprime pas le temps de transmission. RFC 2852 reconnaît que la latence entre commandes allonge légèrement le délai effectif et que l’erreur s’accumule à travers plusieurs sauts. Le protocole garantit une soustraction cohérente, pas une horloge universelle.

Le nombre ne signifie pas non plus « livrer après ». Il impose une borne supérieure, sans retarder volontairement une livraison possible. Il n’allonge jamais la durée normale de conservation : une politique locale plus courte peut conclure à l’échec avant l’heure demandée.

Deux modes, deux droits après l’échéance

Le mode R retire le droit de continuer. Zéro et les valeurs négatives y sont invalides. Si le message n’a été ni livré ni relayé au terme du temps, le MTA ne peut plus essayer. Il produit pour les destinataires concernés une DSN failed avec le code 5.4.7, delivery time expired.

Le mode N ne retire rien à la file. Elle poursuit les tentatives selon la politique du site et émet une DSN delayed avec le code 4.4.7 lorsque la notification s’applique. Zéro et les valeurs négatives sont admis : le retard passé reste une information utile même lorsque la livraison continue.

Cette bifurcation empêche le mot « urgent » de décider à la place du propriétaire du message. Certains contenus deviennent dangereux ou absurdes lorsqu’ils arrivent tard ; d’autres gardent leur valeur et exigent seulement une alerte. Return modifie la garde. Notify modifie la preuve.

Les autres causes de fin ne disparaissent pas. Une erreur permanente peut clore la tentative avant l’échéance. Une erreur temporaire permet encore les reprises. Une rétention locale plus courte reste valable. DELIVERBY ajoute une limite ; il ne remplace pas le modèle de défaillance de SMTP.

Le relais recevait un solde

Entre deux serveurs compatibles, le relais doit conserver le mode et envoyer un nouveau BY calculé sur le temps restant. Le délai consommé dans la première file ne réapparaît pas dans la deuxième. Sans cette règle, chaque domaine pourrait repartir de la valeur initiale et l’échéance ne finirait jamais par gouverner la chaîne.

Return exige une continuité complète. Un message R ne peut pas passer vers un serveur qui n’annonce pas DELIVERBY, ni vers un serveur dont le minimum dépasse le solde. Le relais peut examiner une autre route légitime ; s’il n’en existe aucune, il doit conclure à la non-remise au lieu de faire disparaître silencieusement le délai.

Notify tolère une rupture de capacité, car l’échéance n’interdit pas de continuer. Le message peut entrer dans un système non compatible. Le relais doit cependant générer une DSN relayed pour les destinataires concernés et préserver la demande de retard lorsque le système suivant comprend DSN. Le transport survit ; la continuité sémantique perdue devient visible.

Le protocole coordonne donc le strict minimum. Il ne centralise ni les files ni les décisions d’exploitation. Il exige seulement qu’une obligation acceptée ne soit pas réinitialisée et que sa disparition à une frontière ne soit pas présentée comme une continuité.

La notification ne refermait pas la boucle temporelle

DELIVERBY s’appuie sur DSN pour nommer failed, delayed et relayed. Il ajoute Deliver-By-Date au rapport et recommande d’y conserver la date d’arrivée. Le drapeau T peut demander un rapport à chaque relais ; ces rapports ne sont pas terminaux.

DSN et DELIVERBY ne racontent donc pas la même histoire. DSN structure la preuve d’une action. DELIVERBY détermine quelle action l’expiration commande. Avec R, la file perd l’autorisation de poursuivre. Avec N, elle la conserve mais doit signaler le dépassement.

Le rapport de retour suit pourtant sa propre route. Un message envoyé avec BY=60;R peut expirer à soixante secondes sans que la DSN d’échec revienne dans le même délai. La spécification avertit que le rapport ne reçoit pas nécessairement un traitement accéléré. Borner la décision sur le trajet aller ne crée pas un pouvoir sur toutes ses conséquences.

Une échéance pouvait aussi sonder la file

Le drapeau de trace révèle des passages de relais. Même sans lui, une série de messages portant des délais progressivement différents peut produire une cartographie grossière des seuils ou latences. RFC 2852 traite cette possibilité comme une exposition de sécurité.

Les résultats ne désignent pas automatiquement un responsable. Une valeur négative en mode Notify dit qu’une échéance locale est dépassée, pas où le retard est né. Le code 5.4.7 dit que l’obligation Return ne pouvait plus être tenue, pas qu’un opérateur fut négligent. relayed prouve un passage, pas la livraison finale.

Le registre SMTP actuel de l’IANA conserve DELIVERBY, renvoie à RFC 2852 et lui donne le niveau MAY. Cette inscription constate une capacité standardisée ; elle ne mesure aucun déploiement présent.

L’apport durable de DELIVERBY tient à la forme de l’autorité. L’expéditeur pouvait déclarer quand la continuation devenait la mauvaise action. L’opérateur pouvait refuser un délai irréaliste et conserver la maîtrise de la priorité. Le relais compatible devait transmettre moins de temps qu’il n’en avait reçu. Une frontière incapable devait devenir un résultat, non un oubli.

Le temps accompagnait le message parce qu’il était transmissible. Il restait crédible parce qu’aucun relais n’avait le droit de remettre à zéro ce qu’un autre avait déjà consommé.

Sources