Résumé

  • Le RFC 2061 laisse aux développeurs le choix d’accepter les anciens logiciels ; ses adaptations ne sont pas des obligations d’IMAP4.
  • Récupérer des octets, compenser un changement d’état et préserver toutes les fonctions sont des promesses différentes. Une compatibilité honnête doit les distinguer.

Un aperçu peut afficher le bon texte tout en modifiant la boîte aux lettres. Le remplacement de BODY.PEEK[section] par BODY[section], suivi si nécessaire du retrait de \Seen, concentre le problème : obtenir le contenu ne signifie pas avoir exécuté une opération sans effet sur l’état. C’est l’une des adaptations du RFC 2061.

Une rencontre entre plusieurs générations

En décembre 1996, Mark Crispin, affilié à University of Washington, décrit IMAP2bis comme très courant et largement diffusé avec Pine, mais dépourvu de description définitive. Son mémo informatif, nourri de connaissances incomplètes et de traditions d’implémentation, vise la variante ancienne alors la plus susceptible d’être rencontrée, non toutes les variantes. Ce témoignage ne mesure ni parts de marché ni déploiement actuel.

Le socle IMAP2 du RFC 1176, d’août 1990, n’est pas une spécification définitive d’IMAP2bis. Le RFC 1730 décrit IMAP4 en décembre 1994 ; le RFC 2060, IMAP4rev1 en décembre 1996. Les développeurs visant les deux doivent consulter les deux textes. Le RFC 1732, de décembre 1994, couvre plus largement les anciennes variantes ; il ne se confond pas avec le propos resserré de 1996.

Reconnaître n’est pas garantir

Le repli commence par CAPABILITY. Avec OK, le client examine les variantes annoncées ; s’il n’en reconnaît aucune, le mémo conseille de traiter le serveur comme IMAP2bis. BAD indique IMAP2bis ou plus ancien dans cette méthode. Un délai d’attente, une erreur quelconque ou un échec de sécurité ne valent pas BAD. Cette orientation du client n’est ni une identification définitive ni la validation des commandes suivantes. (RFC 2061)

Trois catégories permettent d’évaluer les adaptations ; ce classement est éditorial, non une nomenclature du RFC.

Substitution utile, proche de l’opération recherchée. LIST devient FIND ALL.MAILBOXES, dont la syntaxe et les réponses ressemblent à celles de FIND MAILBOXES dans le RFC 1176 ; cette dernière commande risque toutefois de fournir peu d’informations utiles. L’astérisque * d’une séquence devient le nombre de messages reçu dans une réponse EXISTS non sollicitée, sans garantir un instantané immuable. (RFC 2061)

Approximation ou compensation. Les extensions de SEARCH reviennent à la syntaxe du RFC 1176, parfois au prix de plusieurs recherches : cela ne recrée pas tous les jeux de caractères ni critères. BODYSTRUCTURE devient BODY, non extensible ; les sections HEADER, TEXT, MIME, HEADER.FIELDS et HEADER.FIELDS.NOT se réduisent aux numéros de section. Réécrire ne restitue pas les fonctions perdues. (RFC 2061)

Absence d’équivalent. L’élément de récupération UID, les commandes UID et CLOSE n’ont pas d’équivalent fonctionnel. Les numéros de séquence ne remplacent pas les UID ; un montage autour d’EXPUNGE ne remplace pas CLOSE. LSUB, SUBSCRIBE et UNSUBSCRIBE n’ont pas d’équivalent direct. Les anciens bboards relevaient d’un concept distinct ; le mémo déconseille leurs commandes dans les logiciels nouveaux, y compris les serveurs accueillant d’anciens clients. (RFC 2061)

Une correction n’efface pas l’intervalle

Le RFC 2060 précise que BODY[section] positionne implicitement \Seen, contrairement à BODY.PEEK[section]. Il admet les changements de drapeaux par d’autres agents et recommande leur notification automatique. Le RFC 2061 propose la récupération ordinaire, puis le retrait manuel de \Seen si nécessaire.

Nous en déduisons une limite : lorsque ces drapeaux sont partagés et modifiables, récupérer puis corriger constitue une succession d’écritures, pas une garantie d’absence de changement intermédiaire observable. Un \Seen préexistant ne doit pas être retiré aveuglément ; un autre agent peut aussi modifier l’état entre-temps. Le mémo ne fournit ni restauration atomique, ni politique universelle de partage, ni incident établissant un conflit systématique.

Les éléments FLAGS.SILENT, +FLAGS.SILENT et -FLAGS.SILENT deviennent leurs variantes STORE non silencieuses ; le client ignore les réponses FETCH non étiquetées correspondantes. Les ignorer localement ne supprime ni leur émission ni les effets de l’opération pour le serveur ou d’autres observateurs. (RFC 2061)

Les limites d’un résultat positif

Pour COPY, le RFC 2061 juge impossible de savoir, dans ce cadre de compatibilité, si le serveur conserve drapeaux et dates internes. Le SHOULD de conservation du RFC 2060 ne s’applique pas rétroactivement à IMAP2bis. Un succès n’est pas un reçu de préservation ; un essai sur un serveur établit un cas observé, pas une règle universelle.

En IMAP2bis, TRYCREATE arrive dans un OK non sollicité séparé, et non à l’intérieur du NO. Le client doit interpréter cette forme en conservant le contexte d’échec : cet indice ne transforme pas un COPY manqué en réussite. (RFC 2061)

Dans l’autre sens, le mémo ne signale, pour un client IMAP2bis bien écrit face à un serveur IMAP4, que l’incompatibilité de l’antislash dans les chaînes entre guillemets. Il conseille les littéraux lorsqu’un antislash ou un guillemet est inclus. Ce constat limité n’est pas un certificat pour tous les anciens clients. (RFC 2061)

Enfin, remplacer AUTHENTICATE par LOGIN est un conseil historique du mémo, qui exclut explicitement les questions de sécurité. Le RFC 8314 de l’IETF, publié en janvier 2018, fournit un repère ultérieur en faveur de TLS pour l’accès et la soumission du courrier. Cette substitution de 1996 n’est ni une recommandation actuelle de connexion en clair ou de dégradation de sécurité, ni une preuve de déploiement de TLS à l’époque.

Annoncer une promesse plus étroite

Dans son essai de 2026 sur l’adoption volontaire, Lu Heng écrit : « Non-adoption is not a violation. » Sa notion d’ensembles de compatibilité éclaire, par rapprochement éditorial, le choix de refuser un repli ou d’en accepter un périmètre limité. Dans son essai de 2025 sur les niveaux de réalité, Lu Heng affirme : « Most conflicts persist because participants mix these layers. » Nous appliquons cette distinction à l’écart entre une capacité annoncée et les effets réellement produits. Ces jugements ultérieurs ne prouvent ni les intentions de Mark Crispin ni le comportement des serveurs de 1996. La compatibilité doit annoncer ce qu’elle conserve, réduit et abandonne.

Sources

Source Apport et limite
RFC 2061 — décembre 1996 Mémo informatif : adaptations, incertitudes et périmètre IMAP2bis.
RFC 2060 — décembre 1996 IMAP4rev1 : récupération, drapeaux et conservation recommandée lors de COPY.
RFC 1176 — août 1990 Socle IMAP2 et ancienne syntaxe ; pas de définition exhaustive d’IMAP2bis.
RFC 1730 — décembre 1994 Version IMAP4 distincte de la révision de 1996.
RFC 1732 — décembre 1994 Conseils de compatibilité antérieurs, au périmètre plus large.
RFC 8314 — janvier 2018 Repère TLS ultérieur, uniquement pour borner la lecture du conseil LOGIN.
Lu Heng — spécification minimale et adoption volontaire, 2026 Cadre interprétatif de coordination ; aucune preuve historique sur IMAP.
Lu Heng — niveaux de réalité et pouvoir symbolique, 2025 Distinction conceptuelle appliquée ici par l’analyse, non par le RFC.