Résumé

  • RFC 2449 a doté POP3 de CAPA, une méthode structurée pour découvrir extensions et comportements au lieu de les apprendre uniquement par essais ou en interprétant des erreurs en langage courant.
  • La liste dépendait de l’état de la session : elle ne valait ni autorisation ni preuve de réussite, et pouvait évoluer avec l’authentification, la politique propre à l’utilisateur et la protection d’intégrité.

« Que sait faire ce serveur ? » paraît appeler une réponse unique. POP3 avait déjà rendu la question plurielle. Les commandes facultatives, les méthodes d’authentification et certains comportements variaient, mais les clients les découvraient souvent en essayant les commandes, en lisant des erreurs rédigées pour des humains ou en demandant à l’utilisateur de modifier un réglage de compatibilité. Publié en novembre 1998 comme mise à jour de RFC 1939 sur le Standards Track, RFC 2449 a introduit CAPA pour obtenir un inventaire lisible par une machine avant de choisir une extension.

Cet inventaire n’est pas devenu une fiche permanente du serveur. CAPA est disponible dans l’état AUTHORIZATION, avant la connexion de l’utilisateur, et dans TRANSACTION, après authentification. Chaque définition de capacité doit préciser les états où elle est annoncée et ceux où ses commandes sont valides. Une capacité disponible avant l’authentification doit être annoncée dans les deux états ; ses paramètres peuvent pourtant devenir plus précis une fois l’utilisateur connu. L’étiquette, sa valeur et l’action qu’elle rend possible sont des faits liés, mais distincts.

Deux politiques l’illustrent. Si LOGIN-DELAY varie selon le compte, le serveur doit annoncer avant authentification le délai maximal possible, puis devrait communiquer à l’utilisateur authentifié une valeur plus exacte. EXPIRE indique une durée minimale de conservation garantie, non le jour où un message donné disparaîtra. Si cette durée dépend de l’utilisateur, la valeur pré-authentification doit être la plus faible possible ; après connexion, le serveur devrait préciser la politique applicable. La première réponse est prudente parce que le serveur ignore encore quel régime s’applique.

L’authentification peut aussi modifier le contexte de sécurité. RFC 2449 recommande de relancer CAPA lorsqu’une couche d’intégrité est négociée, afin de détecter une rétrogradation active. RFC 5034 formule ensuite clairement la limite pour les couches de sécurité SASL : le client abandonne les informations précédemment apprises sur le serveur, y compris l’ancienne liste. Une information obtenue hors du canal protégé ne devient pas automatiquement une preuve dans ce nouveau contexte.

Une liste positive ne garantit pas non plus que chaque utilisateur puisse agir. La capacité USER annonce que USER et PASS sont pris en charge, mais RFC 2449 précise qu’ils ne sont pas nécessairement accessibles à tous. Un mécanisme SASL annoncé peut échouer selon les identifiants ou la politique locale ; une connexion réussie peut encore échouer à ouvrir la boîte. Si CAPA renvoie -ERR, c’est la commande de découverte qui manque et le client doit revenir aux essais antérieurs. La découverte améliore le parcours sans effacer l’incertitude héritée.

RFC 2449 a également défini des codes de réponse structurés pour éviter que le logiciel déduise chaque échec du texte libre. Les codes inconnus doivent être ignorés : la couche commune reste stable pendant l’évolution des extensions. Le RFC avertit toutefois qu’une liste peut révéler les mécanismes d’authentification, même si leur détection automatique aide aussi le client à choisir une option plus robuste. L’information exploitable a une valeur opérationnelle et un coût de divulgation.

La contribution n’était donc pas de garantir l’interchangeabilité des serveurs POP3 ni de mettre fin aux essais de commandes. Elle consistait à délimiter ce que le serveur pouvait annoncer, dans quel état et selon les règles de chaque extension. La liste éclaire une décision ; seule la commande suivante, sa réponse et une observation ultérieure de la boîte peuvent montrer ce qui s’est réellement produit. Le statut du RFC et l’existence d’un registre IANA ne prouvent pas une implémentation ou un déploiement universels.

Sources

RFC 2449 ; notice RFC 2449 ; errata RFC 2449 ; RFC 1939 ; RFC 1957 ; RFC 5034 ; RFC 1734 ; RFC 4422 ; registre IANA POP3 ; RFC 2384 ; Heng Lu, primauté du code en fonctionnement ; Heng Lu, spécification initiale minimale et adoption volontaire.