Résumé

  • Le nom d’un dossier par défaut sert lorsque la recherche d’une boîte à usage spécial ne donne pas de destination. Il ne permet pas de contourner ensuite une erreur de stockage dans la boîte trouvée.
  • Modifier l’attribution d’un usage peut déplacer les prochains messages sans modifier le filtre. La cohérence du classement dépend donc aussi d’un état extérieur au script.
  • Un test d’existence et de droits ne réserve pas de capacité. Préserver le bon emplacement peut laisser un échec visible, dont la résolution doit avoir un responsable.

Le script n’avait pas changé

Pour comprendre pourquoi des messages arrivent dans un nouveau dossier, le premier réflexe est souvent de comparer deux versions du filtre. Aucun changement : l’explication semble devoir se trouver ailleurs.

Avec la sélection par usage spécial, elle peut effectivement se trouver ailleurs, sans que le filtre ait mal fonctionné. La règle ne désigne plus nécessairement une boîte par son nom actuel. Elle peut demander celle qui remplit la fonction d’archive. Si cette fonction est attribuée autrement, la prochaine exécution peut suivre cette nouvelle attribution.

Ce déplacement voulu et un déplacement provoqué par une panne ne sont pourtant pas équivalents. RFC 8579 permet au langage de filtrage Sieve de rechercher une boîte à usage spécial et de conserver un nom par défaut. Mais le texte refuse de faire de ce dernier une destination de secours universelle.

Imaginons une archive dont le quota ne permet plus de recevoir le prochain message. Un autre dossier, nommé dans le filtre, dispose encore de place. Le déposer là améliorerait immédiatement le compteur des opérations réussies. Dans ce cas construit pour expliquer la règle, ce serait néanmoins franchir la limite : une erreur de dépôt sans rapport avec l’existence de la boîte sélectionnée ne doit pas déclencher une nouvelle tentative dans le dossier par défaut.

L’enjeu n’est pas de préférer la panne au service. Il est de savoir ce que le service a été autorisé à changer pour surmonter la panne.

Deux références, une priorité

L’extension IMAP décrite dans RFC 6154 identifie certains usages par des attributs tels que \Archive, \Junk ou \Sent. Elle évite qu’un client soit obligé de deviner, à partir du nom ou de sa langue, quel dossier contient les archives ou les messages indésirables.

Sieve accède à cette logique avec l’argument :specialuse de son action de classement. Il cherche d’abord une boîte portant l’attribut demandé dans l’espace de noms personnel de l’utilisateur. Une correspondance prend la place du nom fourni comme destination par défaut.

En l’absence de boîte correspondante, ou si l’implémentation ne connaît pas cet attribut, l’action reprend son comportement ordinaire fondé sur le nom. Le dossier par défaut peut alors être utilisé selon les règles habituelles. Le protocole prévoit ainsi une compatibilité avec un compte dont les usages ne sont pas configurés comme attendu.

Ce n’est pas un dispositif qui essaye successivement toutes les destinations jusqu’à obtenir un résultat positif. La condition donnant accès au repli est l’absence de résultat pertinent à la recherche, non l’échec de toute opération ultérieure.

Il est donc possible qu’un dossier par défaut soit parfaitement utilisable sans que l’action ait le droit de l’essayer. L’existence de ressources disponibles ne suffit pas à autoriser leur emploi pour une autre destination.

Le coût du courrier dispersé

Pourquoi fermer cette issue ? RFC 8579 donne une raison concrète : éviter que des erreurs transitoires ou intermittentes répartissent les messages de manière inattendue entre deux boîtes.

Sur une série de correspondances, la panne deviendrait sinon une règle de classement invisible. Les messages reçus pendant les périodes normales iraient dans l’archive désignée ; ceux reçus au mauvais moment, dans le dossier de repli. La localisation dépendrait de la santé du stockage, alors que l’utilisateur avait choisi une fonction.

Une recherche globale pourrait parfois retrouver l’ensemble. Cela ne rétablirait pas pour autant les habitudes de consultation, les vues des autres clients ou les traitements qui surveillent seulement le bon dossier. Le succès du dépôt et la continuité du classement ne mesurent pas la même propriété.

L’argument contraire mérite d’être conservé. Un utilisateur peut préférer un autre emplacement à une interruption. Un exploitant peut devoir prévoir un mode dégradé explicite. Mais il faut alors décider ce qui change, comment les lecteurs le sauront et qui remettra ensuite les messages en ordre. L’argument par défaut de cette extension ne constitue pas, à lui seul, cette décision.

Après l’échec du dépôt dans la boîte spéciale, les règles ordinaires d’échec de l’action s’appliquent. RFC 8579 n’impose pas ici un résultat universel de mise en attente, de retour à l’expéditeur ou de suppression. Il interdit une substitution précise, sans faire disparaître la nécessité de traiter l’incident.

Ce que vérifie réellement l’existence

Un contrôle préalable peut rassurer à tort. Le test specialuse_exists ne répond pas à la question « ce message sera-t-il stocké ? ». Il combine l’existence d’une boîte, ses usages et la possibilité d’y déposer du courrier dans le contexte de l’utilisateur exécutant le script.

Sans nom de boîte explicite, chaque attribut demandé doit correspondre à au moins une boîte personnelle permettant le dépôt. Des attributs différents peuvent être satisfaits par des boîtes différentes. Avec un nom explicite, c’est cette boîte précise qui doit exister, permettre le dépôt et posséder tous les attributs énumérés.

La définition de cette possibilité vient de RFC 5490. Le texte précise qu’un test d’existence positif ne garantit pas le succès d’un classement ultérieur : le message peut notamment entraîner un dépassement de quota.

Ce n’est pas une incohérence. Le contrôle établit une condition d’existence et de droits, pas une réservation d’espace pour le message à venir. Une autorisation d’essayer n’est pas la preuve que le stockage est achevé.

Le suivi utile doit donc rapprocher le contexte utilisateur, les correspondances trouvées, la boîte finalement choisie et le résultat réel du dépôt. Enregistrer seulement le test positif efface justement la différence nécessaire pour comprendre une erreur de capacité.

Une fonction peut avoir plusieurs titulaires

Le mot « spécial » ne signifie pas « unique ». Plusieurs boîtes personnelles peuvent porter le même attribut. RFC 8579 précise alors le rôle du nom par défaut : s’il désigne l’une des boîtes correspondantes, celle-ci doit être choisie.

Si ce nom ne départage pas les candidates, le choix relève de l’implémentation. Le texte recommande de le maintenir cohérent tant que les attributions pertinentes restent inchangées. Il permet en revanche de changer de destination lorsque ces attributions changent.

Deux systèmes peuvent donc reconnaître le même usage sans sélectionner la même boîte dans un ensemble ambigu. Copier les attributs lors d’une migration ne suffit pas à prouver la continuité du résultat. Il faut examiner les candidates et la règle effectivement appliquée.

Le sens de l’usage reste lui aussi limité. RFC 6154 laisse au serveur la signification précise de l’archivage. Un attribut Archive n’établit ni durée de conservation, ni immutabilité, ni obligation réglementaire particulière. Il facilite la localisation d’une fonction ; il ne remplace pas le contrat que l’organisation associe à cette fonction.

Cette distinction évite de transformer un mécanisme de configuration en certificat de bonne gestion documentaire.

Le travail que chaque côté attendait de l’autre

Encore faut-il que les attributs aient été attribués. Les usages sont optionnels. La création d’une boîte avec une désignation spéciale dépend d’une capacité distincte, CREATE-SPECIAL-USE. La modification par métadonnées dépend également des possibilités du serveur et de ses contrôles de validité.

Les errata de RFC 6154 contiennent à ce sujet un retour d’expérience précis. L’entrée 4422 relate un test informel d’interopérabilité du 19 juillet 2015 : un serveur supposait que le client initialiserait les usages, tandis qu’un client supposait que le serveur s’en chargerait.

Ce témoignage a le statut Held for Document Update. Les remèdes qu’il propose ne sont pas de nouvelles obligations normatives. Il ne mesure pas non plus les services actuels. Il montre un échec plus restreint : deux capacités compatibles peuvent rester sans effet si personne ne possède la tâche d’initialisation.

Lorsque la boîte spéciale et la boîte nommée font toutes deux défaut, Sieve applique le traitement ordinaire d’une destination inexistante. L’argument explicite :create demande la création nécessaire de la boîte nommée. Si le serveur permet CREATE-SPECIAL-USE, l’extension recommande d’attribuer l’usage demandé à cette nouvelle boîte. La recommandation n’est pas une garantie valable pour toutes les implémentations.

Une suite de dépôts réussis par le nom par défaut peut ainsi masquer une initialisation des usages jamais achevée. Le service fonctionne, mais pas nécessairement par la branche de sélection attendue.

Ne pas chercher partout

La recherche d’une boîte spéciale est limitée à l’espace de noms personnel. Étendre la recherche à tout le magasin de courrier augmenterait la charge et pourrait diriger des messages vers une boîte partagée portant le même attribut.

La question devient alors : qui peut rendre un emplacement éligible à recevoir le courrier d’un autre utilisateur ? Une recherche plus large déplace ce pouvoir. RFC 8579 cite les dépôts inattendus, voire malveillants, que sa restriction cherche à éviter.

Cette limite ne signifie pas que toute boîte personnelle est impossible à partager. Elle ne soumet pas non plus automatiquement une destination par défaut explicitement nommée à la même recherche par attribut. RFC 6154 souligne séparément que certaines attributions peuvent déclencher des actions automatiques et exposer du courrier privé dans un espace partagé.

Il faut donc conserver le périmètre exact de chaque règle, sans lui prêter une promesse générale de confidentialité.

Lire les règles sans inventer une panne

Cette analyse ne repose sur aucun compte inspecté, fournisseur évalué ou incident observé. Les documents établissent les mécanismes et leurs limites. L’erratum technique vérifié 5877 de RFC 8579 corrige un opérateur de correspondance dans un exemple ; il ne modifie pas la séparation entre recherche de destination et échec du dépôt. Aucun de ces exemples n’a été exécuté pour cet article.

La question posée par Lu Heng sur le problème d’agence éclaire le cas sans prouver de mauvaises intentions : celui qui améliore son indicateur supporte-t-il les coûts qu’il déplace ? Un filtre peut enregistrer moins d’échecs en dispersant davantage les messages que d’autres devront ensuite retrouver.

Dans sa présentation du rôle de BTW, Lu Heng demande de décrire les structures plutôt que de mener une campagne. Ici, la structure tient dans une distinction exigeante : trouver une destination et réussir à y écrire sont deux problèmes. La solution du premier n’est pas automatiquement autorisée pour le second.