Compatibilité de IMAP4 avec IMAP2BIS

Statut du présent mémoire

Le présent mémoire apporte des informations à la communauté de l’Internet. Le présent mémoire ne spécifie aucune sorte de norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.

Introduction

Le protocole d’accès au message Internet (IMAP, Internet Message Access Protocol) a subi plusieurs révisions et variantes au cours des dix années de son histoire. Nombres d’elles ont connu l’extinction ou sont devenues extrêmement rares ; en particulier, plusieurs variantes non documentées et les variantes décrites dans les RFC 1064, RFC 1176, et RFC 1203 tombent dans cette catégorie.

Une variante, IMAP2bis, est, au moment de la rédaction du présent document, devenue très courante et a été largement distribuée avec le système de messagerie Pine. Malheureusement, il n’y a pas de document précis qui décrive IMAP2bis. Le présent document est conçu pour être lu en conjonction avec la RFC 1176 et la plus récente des spécifications IMAP4 (la RFC 2060) pour aider les développeurs à créer une mise en œuvre IMAP4 qui interopère avec les mises en œuvre qui se conforment aux spécifications plus anciennes. Rien dans le présent document n’est exigé par la spécification IMAP4 ; les développeurs doivent décider par eux-mêmes si ils veulent que leur produit fonctionne ou non lorsqu’il rencontre un vieux logiciel.

Au moment de la rédaction du présent document, IMAP4 a été mis à jour par rapport à la version décrite dans la RFC 1730. Un développeur qui souhaite interopérer à la fois avec la RFC 1730 et la RFC 2060 devrait se reporter à ces deux documents.

Ces informations ne sont pas complètes ; elle reflètent les connaissances actuelles des mises en œuvre de serveur et de client ainsi que le "folklore" accumulé dans l’évolution du protocole. Ce N’EST PAS une description de la façon d’interopérer avec toutes les variantes de IMAP, mais plutôt avec l’ancienne variante qui a le plus de chance d’être rencontrée. Pour des informations détaillées sur l’interfonctionnement avec les autres anciennes variantes, se reporter à la RFC 1732.

Interopérabilité du client IMAP4 avec les serveurs IMAP2bis

Un moyen rapide de vérifier si une mise en œuvre de serveur prend en charge la spécification IMAP4 est d’essayer la commande CAPABILITY. Une réponse OK indiquera quelle ou quelles variantes de IMAP4 sont acceptées par le serveur.

Si le client ne trouve aucune des variantes qu’il connaît dans la réponse, il devrait traiter le serveur comme étant IMAP2bis. Une réponse BAD indique un serveur IMAP2bis ou plus ancien.

La plupart des facilités de IMAP4 sont dans IMAP2bis. Il existe les exceptions suivantes :

Commande CAPABILITY
L’absence de cette commande indique IMAP2bis (ou plus ancien).

Commande AUTHENTICATE.
Utiliser la commande LOGIN.

Commandes LSUB, SUBSCRIBE, et UNSUBSCRIBE
Pas d’équivalent fonctionnel direct. IMAP2bis avait un concept appelé "bboards" qui n’est plus dans IMAP4. La RFC 1176 prenait cela en charge avec les commandes BBOARD et FIND BBOARDS. IMAP2bis ajoutait à cela les commandes FIND ALL.BBOARDS, SUBSCRIBE BBOARD, et UNSUBSCRIBE BBOARD. Il est recommandé de ne mettre en œuvre aucune de ces commandes dans les nouveaux logiciels, y compris de serveurs qui prennent en charge d’anciens clients.

Commande LIST
Utiliser la commande FIND ALL.MAILBOXES, qui a une syntaxe et une réponse similaires à la commande FIND MAILBOXES décrite dans la RFC 1176. Selon toute vraisemblance, la commande FIND MAILBOXES ne produira pas d’informations utiles.

* dans une séquence
Utilise le nombre de messages dans la boîte aux lettres à partir de la réponse non sollicitée EXISTS.

Extensions SEARCH (jeu de caractères, critères supplémentaires)
Reformule la demande de recherche en utilisant seulement la syntaxe de la RFC 1176. Cela permet de faire plusieurs recherches pour obtenir les résultats désirés.

Élément d’extraction de données BODYSTRUCTURE
Utiliser l’élément de données non extensible BODY.

Sections de corps HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT
Utiliser seulement les numéros de section de corps.

BODY.PEEK[section]
Utiliser BODY[section] et éliminer manuellement le fanion \Seen en tant que de besoin.

Éléments de mémorisation de données FLAGS.SILENT, +FLAGS.SILENT, et -FLAGS.SILENT
Utiliser les versions non-SILENT correspondantes et ignorer les réponses FETCH sans étiquette qui reviennent.

Élément d’extraction de données UID et les commandes UID
Pas d’équivalent fonctionnel.

Commande CLOSE
Pas d’équivalent fonctionnel.

Dans IMAP2bis, le jeton d’information spéciale TRYCREATE est envoyé comme réponse d’accord (OK) non sollicitée séparée au lieu d’être à l’intérieur de la réponse NO.

IMAP2bis est ambigu sur la question de savoir si des fanions ou des dates internes sont préservées sur COPY. Il est impossible de savoir quel comportement est accepté par le serveur.

Interopérabilité du serveur IMAP4 avec les client IMAP2bis

Le seul problème d’interopérabilité entre le serveur IMAP4 et un client IMAP2bis bien conformé est une incompatibilité avec l’utilisation de "\" dans les chaînes entre guillemets. Ceci peut être évité par l’utilisation de descriptions littérales au lieu des chaînes entre guillemets si "\" ou <"> est incorporé dans la chaîne.

Considérations sur la sécurité

Les questions de sécurité ne sont pas discutées dans le présent mémoire.

Adresse de l’auteur

Mark R. Crispin
Networks and Distributed Computing
University of Washington
4545 15th Aveneue NE
Seattle, WA 98105-4527
téléphone : (206) 543-5762
mèl : MRC@CAC.Washington.EDU