Aller au contenu principal

6.3 Commandes client - État authentifié (Client Commands - Authenticated State)

Dans l'état authentifié, les commandes qui manipulent les boîtes aux lettres en tant qu'entités atomiques sont autorisées. Parmi ces commandes, SELECT et EXAMINE sélectionneront une boîte aux lettres pour l'accès et entreront dans l'état sélectionné.

En plus des commandes universelles (CAPABILITY, NOOP et LOGOUT), les commandes suivantes sont valides dans l'état authentifié : ENABLE, SELECT, EXAMINE, NAMESPACE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, STATUS, APPEND et IDLE.

6.3.1 Commande ENABLE​

Arguments : noms de capacités

Réponses : aucune réponse spécifique pour cette commande

Résultat :

  • OK - Capacités pertinentes activées
  • BAD - Aucun argument, ou erreur de syntaxe dans un argument

Plusieurs extensions IMAP permettent au serveur de renvoyer des réponses non sollicitées spécifiques à ces extensions dans certaines circonstances. Cependant, les serveurs ne peuvent pas envoyer ces réponses non sollicitées (à l'exception des codes de réponse (voir Section 7.1) inclus dans les réponses OK/NO/BAD étiquetées ou non étiquetées, qui peuvent toujours être envoyées) jusqu'à ce qu'ils sachent que les clients prennent en charge de telles extensions et seront donc en mesure d'analyser et de traiter correctement les données de réponse d'extension.

La commande ENABLE fournit une indication explicite du client qu'il prend en charge des extensions particulières. Elle est conçue de telle sorte que le client puisse envoyer une simple chaîne constante avec les extensions qu'il prend en charge, et le serveur activera le sous-ensemble partagé que les deux prennent en charge.

La commande ENABLE prend une liste de noms de capacités et demande au serveur d'activer les extensions nommées. Une fois activée à l'aide d'ENABLE, chaque extension reste active jusqu'à la fermeture de la connexion IMAP. Pour chaque argument, le serveur fait ce qui suit :

  • Si l'argument n'est pas une extension connue du serveur, le serveur doit (doit) ignorer l'argument.

  • Si l'argument est une extension connue du serveur, et qu'il n'est pas spécifiquement autorisé à être activé à l'aide d'ENABLE, le serveur doit (doit) ignorer l'argument. (Notez que connaître une extension n'implique pas nécessairement la prise en charge de cette extension.)

  • Si l'argument est une extension prise en charge par le serveur et qui doit être activée, le serveur doit (doit) activer l'extension pour la durée de la connexion. Notez qu'une fois qu'une extension est activée, il n'y a aucun moyen de la désactiver.

Si la commande ENABLE réussit, le serveur doit (doit) envoyer une réponse ENABLED non étiquetée (Section 7.2.1), qui inclut toutes les extensions activées comme spécifié ci-dessus. La réponse ENABLED est envoyée même si aucune extension n'a été activée.

Les clients devraient (devraient) inclure uniquement les extensions qui doivent être activées par le serveur. Par exemple, un client peut activer un comportement spécifique à IMAP4rev2 lorsque IMAP4rev1 et IMAP4rev2 sont tous deux annoncés dans la réponse CAPABILITY. Les futurs RFC peuvent ajouter à cette liste.

La commande ENABLE n'est valide que dans l'état authentifié, avant qu'une boîte aux lettres ne soit sélectionnée. Les clients ne doivent pas (ne doivent pas) émettre ENABLE une fois qu'ils ont SELECT/EXAMINE une boîte aux lettres ; cependant, les implémentations de serveur n'ont pas à vérifier qu'aucune boîte aux lettres n'est sélectionnée ou n'a été précédemment sélectionnée pendant la durée d'une connexion.

La commande ENABLE peut être émise plusieurs fois dans une session. Elle est additive ; c'est-à-dire que "ENABLE a b", suivi de "ENABLE c", est identique à une seule commande "ENABLE a b c". Lorsque plusieurs commandes ENABLE sont émises, chaque réponse ENABLED correspondante devrait (devrait) contenir uniquement les extensions activées par la commande ENABLE correspondante, c'est-à-dire que, pour l'exemple ci-dessus, la réponse ENABLED à "ENABLE c" ne devrait pas contenir "a" ou "b".

Il n'y a aucune limitation sur la mise en pipeline d'ENABLE. Par exemple, il est possible d'envoyer ENABLE puis immédiatement SELECT, ou un LOGIN immédiatement suivi d'ENABLE.

Le serveur ne doit pas (ne doit pas) modifier la liste CAPABILITY à la suite de l'exécution d'ENABLE ; c'est-à-dire qu'une commande CAPABILITY émise juste après une commande ENABLE doit (doit) lister les mêmes capacités qu'une commande CAPABILITY émise avant la commande ENABLE. Cela est démontré dans l'exemple suivant. Notez que ci-dessous "X-GOOD-IDEA" est une capacité d'extension fictive qui peut être ENABLED.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA
S: t2 OK foo
C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t3 OK foo again

Dans l'exemple suivant, le client active l'extension Conditional Store (CONDSTORE) [RFC7162] :

C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled

6.3.1.1 Note aux concepteurs d'extensions qui peuvent utiliser la commande ENABLE​

Les concepteurs d'extensions IMAP sont découragés de créer des extensions qui nécessitent ENABLE à moins qu'il n'y ait pas de bonne conception alternative. Plus précisément, les extensions qui provoquent des changements de comportement potentiellement incompatibles avec les réponses de serveur déployées (et bénéficient donc d'ENABLE) ont un coût de complexité plus élevé que les extensions qui ne le font pas.

Dernière mise à jour le