Mon blog

Ce RFC normalise le champ Expires: dans l'en-tête d'un message. Il existait déjà mais n'avait apparemment jamais été spécifié officiellement. Il indique quand un message cesse d'être utile et n'a plus besoin d'être montré.

L'utilisation envisagée est que le MUA peut déclasser un message expiré, voire le masquer complètement (le détruire n'est pas recommandé, un message expiré n'est plus valide mais peut garder, par exemple, un intérêt historique). Notre RFC n'essaie pas de donner une signification trop précise à ce champ, encore moins de requérir des actions spécifiques par le logiciel.

Donc, le champ garde sa syntaxe (section 3), la forme de la date-et-heure étant tirée du RFC 5322, section 3.3 :

Expires: Thu, 16 Jul 2026 11:28:03 +0000
  

(Si vous utilisez le logiciel GNU date, l'option --rfc-email permet d'afficher une date-et-heure au bon format.)

On l'a dit, ce RFC n'est pas trop normatif, mais il donne quand même des avis. La section 4 conseille aux logiciels de création de messages de mettre un Expires: quand on sait que le message perdra son intérêt après un certain moment. C'est par exemple le cas d'une promotion commerciale qui a une date de fin, d'un message qui annonce un évènement ou d'un message périodique, qui n'est valable que jusqu'à l'émission du suivant.

La section 5, elle, consacrée aux logiciels de lecture, leur suggère de diminuer la priorité d'affichage des messages expirés, voire de ne pas les montrer du tout. Elle estime qu'il ne faut pas refuser un message uniquement sur la base du champ Expires:, et ne pas, par défaut, détruire les messages expirés (mais on peut avoir une option du logiciel pour activer cette destruction).

On notera qu'il existe un projet Email Expiration Date pour développer l'utilisation du champ Expires:. Ce projet, porté par plusieurs acteurs spécialisés dans l'envoi massif de messages, a développé un greffon Thunderbird mettant en œuvre l'expiration des messages. Jusqu'à présent, je n'ai vu ce champ dans des vrais messages que dans les spams de la SNCF, par exemple un message expédié en juin qui indiquait Expires: Monday, 21 December 2026 14:38:28 +0000 (cette date était sans rapport avec le contenu de la publicité, mais était à six mois dans le futur donc je suppose qu'un Expires: d'une demi-année est mis automatiquement).

Ce champ Expires: a une histoire. Le RFC 1327 décrit déjà, dans le contexte de l'interopérabilité avec X.400, un champ Expiry-date:. Le RFC 2156 le renomme Expires:, en indiquant juste sa syntaxe (une date-et-heure, au format du - à l'époque - RFC 822) et peu de sémantique à part qu'on ne pouvait pas compter que ce champ soit appliqué automatiquement. Puis le RFC 4021 l'a placé dans le registre de l'en-tête du courrier. Notez qu'un autre format, celui des News, a un champ Expires: (RFC 5536, section 3.2.5), avec une syntaxe et une sémantique proche. Comme, dans le contexte du courrier électronique, ce champ existe depuis longtemps, mais avec peu ou pas de spécification, il aurait été difficile de définir une spécification stricte, cela aurait cassé certains usages existants (cf. section 6).