Résumé

  • La RFC 5230 a défini une action Sieve qui crée un nouveau message vers l’expéditeur d’enveloppe du courrier reçu et suit, dans le temps, si cette adresse a déjà reçu la même réponse.
  • Le réglage essentiel n’est pas seulement le texte : qualification du destinataire, identité de la réponse, en-têtes anti-boucle et délai limité déterminent qui recevra le message et à quel moment.

L’absence ne concernait pas que la personne absente

Une réponse automatique paraît anodine parce qu’elle tient souvent en deux lignes. Mais elle sort du compte au nom de son propriétaire, sans validation de chaque destinataire. Elle peut révéler une absence, répondre à une liste de diffusion ou rebondir entre deux systèmes laissés seuls. Le protocole devait donc définir quand se taire autant que quoi dire.

En 2008, la RFC 5230 a ajouté « vacation » à Sieve, langage de filtrage du courrier volontairement limité. Un script peut signaler qu’une personne ne répondra pas rapidement, puis produire un message distinct. C’était la première extension Sieve capable de créer un message entièrement nouveau. L’effet dépasse le tri d’un dossier : la règle déclenche une communication externe, qui peut susciter une réponse à son tour.

La réponse vise l’expéditeur SMTP de l’enveloppe — la valeur MAIL FROM, conservée dans Return-Path si le traitement Sieve vient après la livraison finale — et non le seul champ From lisible par une personne. Le nouvel envoi devrait lui-même employer une enveloppe vide ; si l’extension de notification de remise est disponible, l’implémentation devrait demander qu’aucune notification ne soit générée en cas d’échec. L’en-tête Auto-Submitted indique que le message a été produit automatiquement. Date, expéditeur, destinataire et références décrivent une réponse réellement générée, plutôt qu’un message maquillé en courrier de l’expéditeur initial.

Une adresse, une réponse précise, un intervalle

La fonction la plus discrète est la mémoire : l’extension retient les réponses envoyées à chaque adresse pendant un certain temps. Un correspondant peut écrire une seconde fois pendant l’absence, mais il ne reçoit pas nécessairement le même texte à chaque message. Le paramètre :days borne cet intervalle. En son absence, la valeur est le plus grand de sept jours et du minimum local. Le site peut fixer un minimum strictement positif et une limite supérieure ; les valeurs hors de cette plage sont ramenées aux bornes. Le nombre inscrit dans le script n’est donc pas toujours le délai réellement appliqué.

Il ne s’agit pas d’un indicateur global « absent » : le système distingue la réponse que cette personne a déjà reçue. Un :handle explicite donne une identité commune aux déclarations de vacances qui partagent le même handle. Sans cela, l’identité est synthétisée à partir de :subject, :from, :mime et du texte de réponse. Deux branches peuvent ainsi envoyer des explications différentes au même correspondant. À l’inverse, deux commandes aux mêmes arguments partagent l’historique de suppression. Lorsque l’extension de variables est utilisée, les arguments ne doivent pas être développés avant cette comparaison : l’identité repose sur les arguments définis, pas sur une valeur volatile calculée à chaque exécution.

Le délai est donc une petite base de politique. Sa clé associe l’adresse du correspondant à l’identité de la réponse. Cette précision évite les répétitions sans empêcher un message distinct, adapté à un fait nouveau. Elle répartit aussi le contrôle : le script déclare quelles réponses sont équivalentes, tandis que le site borne leur fréquence effective.

Répondre à la bonne personne

La RFC 5230 exige que l’adresse du destinataire figure parmi To, Cc, Bcc ou leurs variantes Resent avant qu’une réponse de vacances soit envoyée. Le serveur peut reconnaître l’adresse via son compte, l’enveloppe finale, ou une liste :addresses fournie par le script pour des alias. Cette liste aide les personnes possédant plusieurs adresses, mais devient incomplète quand le transfert et le sous-adressage compliquent l’identité du destinataire.

D’autres garde-fous visent les machines et les listes. L’implémentation doit maintenir une liste d’adresses qui ne recevront jamais de réponse ; le texte suggère les noms de démons et d’outils de gestion de listes. Elle devrait éviter les messages portant des en-têtes de gestion de liste, ainsi que ceux dont Auto-Submitted indique autre chose que no. Elle peut aussi écarter des messages dont les en-têtes ou le contenu rendent une réponse inappropriée. Ce cadre ne garantit pas que chaque déploiement reconnaisse chaque automatisme : certaines identités restent définies localement et dépendent des traces accessibles au serveur.

La RFC 3834 avait publié en 2004 des recommandations plus générales pour les réponses automatiques. La RFC 5230 dit que son extension de réponse personnelle vise à les respecter. Les travaux ultérieurs en ont prolongé les limites : RFC 6131 ajoute :seconds, y compris zéro pour répondre à chaque message ; RFC 6133 compose vacation avec présence et carnet d’adresses ; RFC 8580 permet de déposer une copie locale de la réponse. Ces textes montrent une évolution de conception, pas la fréquence de déploiement de ces fonctions.

Le message ne se réduit pas à son texte

La RFC prévoit UTF-8 et MIME, notamment les alternatives multilingues. Un script peut choisir une langue en fonction des en-têtes, mais le document avertit qu’une lecture trop simple peut être trompée. Il souligne aussi que le degré de formalité peut dépendre du lien avec le correspondant — collègue ou personne inconnue — pas seulement de sa langue. Le choix de la réponse est déjà une décision sur son audience.

L’action reste limitée : une fois par script, incompatible avec reject ou refuse, et sans annuler le keep implicite de Sieve. Ces détails la situent dans le langage, mais ne reprennent pas l’analyse générale de RFC 3028 sur les actions et leurs effets. L’apport propre de RFC 5230 est la politique entourant un message sortant : adresse visée, identité du texte, en-têtes et délai.

Les sources établissent le mécanisme, pas sa sécurité universelle. Un serveur ne peut pas toujours savoir si un message était personnel, si un alias transféré appartient au même compte ou si un en-tête de liste dit tout. La norme empile plutôt des tests observables et une mémoire bornée autour d’un automatisme tentant. Le message d’absence n’était pas qu’une phrase enregistrée : c’était une autorisation, adressée à quelqu’un, sous contrainte de temps.

Sources