Résumé

  • Le 8 mai 2026, l’IESG a approuvé draft-ietf-mailmaint-expires-06 comme Proposed Standard. Le champ indique la date après laquelle un message « perd sa validité », sans imposer une conséquence opérationnelle unique.
  • Un logiciel de messagerie ne doit ni rejeter ni écarter un message uniquement à cause de ce champ. Il ne devrait pas supprimer un message déjà expiré sans configuration délibérée du propriétaire de la boîte.

Le calendrier de l’émetteur

Le besoin est réel. Une promotion prend fin, une réunion est passée, une notification sociale a cessé d’être actuelle, un bulletin périodique a été remplacé. Un client de messagerie peut épargner l’attention du lecteur en reléguant ces éléments, sans nier qu’ils ont existé.

Le champ Expires contient une valeur date-time conforme à RFC 5322. Le créateur du message ne doit pas insérer plus d’un champ de ce nom. Après l’instant indiqué, le message est réputé perdre sa validité.

Cette formule paraît simple, mais elle ne signifie pas « effacer ». Elle ne signifie pas davantage « rappeler », « refuser », « masquer à toute recherche » ou « ignorer comme preuve ». Le groupe de travail n’a pas trouvé de sens normatif plus précis qui décrirait honnêtement les pratiques antérieures et le consensus actuel.

La prudence vient de la position de celui qui choisit la date. L’entreprise qui envoie une offre peut souhaiter qu’elle disparaisse après la vente. L’auteur d’une instruction contestée peut préférer qu’elle devienne difficile à retrouver. L’échéance reste donc une assertion du créateur, non une décision prise par le destinataire.

Une approbation encore dans la file éditoriale

L’IESG a annoncé son approbation le 8 mai 2026 à 22 h 11 UTC. Le texte, issu du groupe Mail Maintenance, vise le Standards Track au niveau Proposed Standard. Au moment où les éléments de cet article ont été figés, le Datatracker affichait la révision 06 dans la file du RFC Editor, en attente d’un premier éditeur, et l’action IANA au stade RFC-Ed-Ack.

Le registre Message Headers de l’IANA présente déjà Expires pour le courrier électronique comme standard et renvoie vers le projet. Une ligne distincte concerne Netnews. Le même nom n’abolit pas la frontière entre deux environnements dont les usages et les effets ne sont pas identiques.

Le champ a une histoire antérieure : on le retrouve dans des travaux de correspondance avec X.400 et dans d’anciens enregistrements de champs de courrier. Des logiciels lui ont donné des comportements variés. La nouvelle spécification ne transforme pas rétroactivement cette diversité en une commande universelle. Elle fixe un noyau interopérable et interdit qu’une interprétation destructrice devienne une conséquence implicite.

C’est un choix de coordination minimal. Le standard rend l’information transmissible et compréhensible. Il laisse les décisions futures à l’endroit où se trouvent la connaissance du contexte et la responsabilité de la perte.

Afficher, marquer et détruire sont trois décisions

L’architecture du courrier distingue le Message Creator du Message Reader. Ce dernier peut être un agent de stockage ou un agent utilisateur. Il peut atténuer la présentation d’un message expiré, l’omettre d’une vue ordinaire ou proposer des règles de nettoyage commandées par l’utilisateur.

Le texte impose cependant une limite nette : un message ne doit pas être rejeté ou écarté pour le seul motif que son échéance est passée. Il ne devrait pas être supprimé sur ce seul fondement, sauf si le propriétaire de la boîte a volontairement configuré ce résultat.

Cette distinction protège une chaîne de preuves. La lecture du champ est un événement. La modification de l’affichage en est un autre. Le passage à un état de suppression est une décision supplémentaire. La destruction permanente constitue enfin un résultat qui peut être irréversible.

IMAP4rev2 rend cette chaîne visible. Le drapeau \Deleted marque le message ; la commande EXPUNGE retire définitivement les messages marqués, et UID EXPUNGE permet de limiter l’opération à certains UID. Toutes les plateformes ne reposent pas sur IMAP, mais elles devraient pouvoir produire l’équivalent de ces étapes au lieu de les confondre sous le mot « expiration ».

Une interface réversible peut suivre l’indication de l’émetteur. Une opération destructive doit suivre une politique locale, identifiable et assumée par le propriétaire.

Une signature authentifie une provenance, pas un pouvoir

DKIM permet de vérifier qu’un domaine signataire a pris une certaine responsabilité pour les parties signées d’un message. Si Expires figure dans cet ensemble, une modification ultérieure peut être détectée dans les limites du mécanisme.

Cela ne rend pas la date exacte ou bienveillante. Cela ne prouve ni le souhait du destinataire, ni une règle de conservation, ni le droit du domaine signataire à effacer les données d’autrui. L’authenticité d’une déclaration et l’autorité nécessaire pour l’exécuter appartiennent à deux couches différentes.

Cette erreur de catégorie traverse les infrastructures numériques. Une valeur normalisée, une entrée de registre ou un objet signé établit un fait dans un périmètre donné. Le caractère lisible par machine n’ajoute pas un mandat opérationnel qui n’existait pas auparavant.

Le champ temporel invite naturellement à l’automatisation. La bonne réponse n’est pas de l’interdire, mais de rendre visible la règle qui convertit l’information en action. L’horodatage vient de l’émetteur ; le seuil d’affichage, le nettoyage et la conservation viennent du lecteur et du propriétaire.

Une date malveillante reste une date valide

Le modèle de menace autorise un créateur à choisir un instant très ancien, très proche ou très lointain. Sans autre contexte, le lecteur ne peut pas supposer que cette valeur est exacte ou utile.

Une date passée pourrait rendre un pourriel moins visible avant son signalement. Une échéance proche pourrait compliquer la recherche d’une plainte ou d’une instruction après qu’une personne a agi. Une échéance lointaine pourrait servir à réclamer une visibilité durable. Le champ est donc peu apte, à lui seul, à décider si un message est désiré ou frauduleux.

Il peut néanmoins enrichir une présentation lorsqu’il est associé à l’authentification, à l’historique de l’émetteur, au type de message et aux préférences du propriétaire. L’étiquette honnête serait « date de validité déclarée dépassée ». La formule « suppression sans risque » exige une autre décision et une autre source d’autorité.

Les mots choisis par l’interface déterminent si l’utilisateur voit une observation ou une conclusion. Une architecture responsable ne cache pas ce passage.

Sources