Le courriel avait expiré. La preuve, elle, devait rester.

Résumé

• Dans draft-ietf-mailmaint-expires-06, « perdre sa validité » reste volontairement imprécis : la date exprime le point de vue du créateur, non un fait certifié.
• Un logiciel de messagerie ne doit ni rejeter ni abandonner un message sur ce seul fondement, et ne devrait le supprimer qu’après une configuration délibérée du propriétaire de la boîte.
• La présentation, le stockage, la conservation probatoire et la purge finale sont des états différents. Les confondre transforme une aide au tri en commande distante.

Une promotion périmée n’est pas un document inexistant

La réduction de cinquante pour cent est terminée. Le message n’a plus de valeur commerciale immédiate. Pourtant, il peut encore expliquer le prix présenté au client, la date d’une commande ou l’origine d’une réclamation. Sa pertinence pour l’action et sa valeur comme trace ne suivent pas la même horloge.

La révision 06 du groupe Mail Maintenance élargit l’usage Internet du champ Expires, hérité des passerelles X.400. Sa forme est simple : une date et une heure, dans un seul champ. Après cette date, le créateur considère que le message a « perdu sa validité ». Faute de consensus, le texte refuse d’en donner une définition normative plus précise.

Cette retenue est essentielle. L’échéance peut concerner une offre, un événement, une notification périodique ou un code à usage unique. Elle ne dit pas si le destinataire a reçu, lu ou utilisé le message. Elle ne qualifie ni la fraude, ni le spam, ni l’obligation de conservation.

Le document se trouve dans la file du RFC Editor avec l’objectif de devenir une Proposed Standard. Il reste un Internet-Draft actif : ni RFC publié, ni mesure de déploiement.

Le même mot masque plusieurs opérations

Une interface peut griser le message. Un client peut le retirer de la vue principale. Une règle peut le déplacer vers un dossier temporaire. Le magasin peut effacer la copie courante, alors qu’un journal ou une sauvegarde subsiste. Une purge peut enfin rendre la récupération impossible.

Dire seulement « expiré » cache toute cette chaîne. Or le projet impose une limite nette : le logiciel ne doit pas rejeter ou abandonner un message en se fondant uniquement sur le champ. Il ne devrait pas supprimer un message déjà périmé sans configuration délibérée du propriétaire de la boîte.

L’expéditeur fournit donc un indice. Le destinataire décide de son effet. Ce partage est plus qu’une précaution d’interface : il empêche la partie qui écrit le message de contrôler la durée de vie de la trace chez l’autre partie.

Une signature authentifie des octets, pas une conséquence

DKIM peut relier des champs signés à un domaine qui en assume la responsabilité. Cela ne rend pas la date exacte, raisonnable ou obligatoire. Une origine authentifiée reste capable de se tromper, d’utiliser une autre horloge ou de poursuivre son propre intérêt.

Le projet énumère précisément ces intérêts. Un spammeur peut antidater le message pour qu’il soit moins visible et moins signalé, puis profiter d’un apprentissage adaptatif faussé. Une échéance très proche peut fabriquer l’urgence et compliquer une plainte ultérieure. Une date très lointaine peut chercher à maintenir le message en évidence.

Faire de Expires un verdict antifraude serait donc doublement dangereux : le champ n’est pas prévu pour cela, et son auteur choisit lui-même sa valeur.

Quatre couches à ne jamais compacter en une seule

La première couche est la déclaration : valeur brute, résultat d’analyse, identité et signature disponibles. La deuxième est la présentation : visible, atténué, regroupé ou masqué. La troisième est la conservation : boîte active, zone réversible, archive, sauvegarde ou purge. La quatrième est l’usage probatoire : incident, contrat, transaction, abus ou obligation légale.

Une transition dans une couche ne prouve rien dans les autres. Masqué ne veut pas dire supprimé. Supprimé de la boîte ne veut pas dire absent du journal. Périmé pour l’offre ne veut pas dire sans valeur pour un litige.

Un reçu local minimal devrait conserver l’identifiant ou l’empreinte du message, l’heure de réception, la valeur brute et la date analysée, l’identité disponible, la version de la règle locale, le consentement du propriétaire, l’action d’affichage, l’action de stockage, le délai de récupération et le résultat de purge. C’est une proposition d’exploitation, pas un nouveau champ de protocole.

Une petite règle commune, des choix futurs locaux

La filiation technique commence avec Expiry-Date dans le RFC 1327, passe par le mappage Expires du RFC 2156 et par l’enregistrement « not for general use » du RFC 4021. La révision 06 rendrait l’usage général possible. Elle ne convertit pas cette histoire en mandat permanent sur les boîtes des autres.

Une spécification initiale minimale suffit : nom stable, syntaxe stable, signification limitée. Les produits peuvent ensuite choisir de trier, d’atténuer ou d’offrir un nettoyage, sans déclarer invalides les produits qui n’adoptent pas le même comportement.

La preuve décisive vient du code en fonctionnement : le transport a-t-il accepté le message ? l’interface l’a-t-elle caché ? les octets sont-ils encore dans l’archive ? la restauration fonctionne-t-elle ? La date, la publication du standard et la signature du domaine se situent au-dessus de ces résultats.

Sources

1. Projet Expires 06, texte
2. Projet Expires 06, HTML
3. Datatracker, révision 06
4. Historique Datatracker
5. RFC 1327
6. RFC 2156
7. RFC 4021
8. RFC 5322
9. RFC 5536
10. RFC 5598
11. RFC 6376, DKIM
12. RFC 7942
13. Registre IANA des en-têtes
14. Lu Heng, Minimum Initial Specification
15. Lu Heng, On Reality Layers
16. Lu Heng, Running Code Primary