Mon blog

Dans son travail, l'IETF utilise énormément les listes de diffusion. Afin de s'assurer que le travail de normalisation soit ouvert et transparent, ces listes sont publiquement accessibles. Mais il n'existe pas de moyen très pratique de naviguer dans les archives de ces listes, alors qu'il serait tentant de pouvoir le faire en utilisant le protocole normalisé d'accès à des boîtes aux lettres, IMAP. Ce court RFC est le cahier des charges du projet « Accès en IMAP aux archives des listes IETF ».

Les principaux accès à ces listes actuellement se font via le Web (qui fait l'objet d'un travail analogue pour améliorer ce service, cf. RFC 6778) ou en travaillant sur des copies locales des boîtes (pas forcément pratique). Bien des membres de l'IETF réclament un accès IMAP (RFC 9051), chaque liste étant représentée par une boîte IMAP. On pourra ainsi utiliser son client IMAP favori (mutt, Thunderbird, etc) pour accéder à ces archives.

Les exigences les plus importantes de ce cahier des charges (section 2) :

• Même si l'archive est publique (le cas le plus fréquent) et accessible par tous, il faudra que le système permette de se loguer (avec la base d'identité du datatracker), afin de pouvoir marquer les messages (lu, non lu, etc). Il est souhaitable que d'autres annotations soient possibles, comme décrit dans les RFC 5257 et RFC 5464. Pour l'accès « anonyme », le système devra utiliser le mécanisme SASL du RFC 4505, ou bien un compte spécial (login anonymous / mot de passe anonymous...)
• À part ces marques et ces annotations, il ne faut évidemment pas que les utilisateurs puissent modifier ou supprimer les messages.
• Il faut que les fonctions de recherche d'IMAP soient mises en œuvre, avec les fonctions décrites dans le RFC 6778, de préférence en utilisant les extensions à IMAP des RFC 5256 (le tri), RFC 6237 (recherche multi-boîtes, depuis remplacé par le RFC 7377) et RFC 6203 (la recherche floue...)

Si vous êtes programmeur et que vous envisagez de se lancer dans ce travail, attention, la section 3 précise que le système devra prévoir une future extension aux adresses de courrier en Unicode.

Des problèmes de sécurité ? La section 4 en voit quelques uns. La fonction de recherche peut être très gourmande en CPU et en E/S. Un client méchant ou simplement avide pourrait mettre à genoux le serveur en multipliant les requêtes. Le système doit donc être capable de limiter la consommation de ressources par utilisateur. Un problème analogue se pose pour les annotations, dont il faut limiter la consommation d'espace disque.

Je n'ai pas trouvé trace d'un appel d'offres formel de l'IETF correspondant à ce RFC. Plus tard, peut-être ?