Aller au contenu principal

6. Commandes client (Client Commands)

Les commandes IMAP4rev2 sont décrites dans cette section. Les commandes sont organisées par l'état dans lequel la commande est autorisée. Les commandes autorisées dans plusieurs états sont répertoriées dans l'état minimum autorisé (par exemple, les commandes valides dans les états authentifié et sélectionné sont répertoriées dans les commandes d'état authentifié).

Les arguments de commande, identifiés par "Arguments:" dans les descriptions de commande ci-dessous, sont décrits par fonction, et non par syntaxe. La syntaxe précise des arguments de commande est décrite dans "Syntaxe formelle" (Section 9).

Certaines commandes provoquent le renvoi de réponses de serveur spécifiques ; elles sont identifiées par "Responses:" dans les descriptions de commande ci-dessous. Consultez les descriptions de réponse dans "Réponses" (Section 7) pour plus d'informations sur ces réponses et dans "Syntaxe formelle" (Section 9) pour la syntaxe précise de ces réponses. Il est possible que des données de serveur soient transmises à la suite de toute commande. Ainsi, les commandes qui ne nécessitent pas spécifiquement de données de serveur spécifient "aucune réponse spécifique pour cette commande" au lieu de "aucune".

Le "Result:" dans la description de la commande fait référence aux réponses d'état étiquetées possibles à une commande et à toute interprétation spéciale de ces réponses d'état.

L'état d'une connexion n'est modifié que par des commandes réussies qui sont documentées comme changeant d'état. Une commande rejetée (réponse BAD) ne change jamais l'état de la connexion ou de la boîte aux lettres sélectionnée. Une commande échouée (réponse NO) ne change généralement pas l'état de la connexion ou de la boîte aux lettres sélectionnée, à l'exception des commandes SELECT et EXAMINE.

6.1 Commandes client - N'importe quel état (Client Commands - Any State)​

Les commandes suivantes sont valides dans n'importe quel état : CAPABILITY, NOOP et LOGOUT.

6.1.1 Commande CAPABILITY​

Arguments : aucun

Réponses : Réponse non étiquetée REQUISE : CAPABILITY

Résultat :

  • OK - capability terminée
  • BAD - arguments invalides

La commande CAPABILITY demande une liste des capacités (par exemple, extensions et/ou modifications du comportement du serveur) que le serveur prend en charge. Le serveur doit (doit) envoyer une seule réponse CAPABILITY non étiquetée avec "IMAP4rev2" comme l'une des capacités répertoriées avant la réponse OK (étiquetée).

Un nom de capacité qui commence par "AUTH=" indique que le serveur prend en charge ce mécanisme d'authentification particulier tel que défini dans la couche d'authentification et de sécurité simple (SASL) [SASL]. Tous ces noms font, par définition, partie de cette spécification.

Les autres noms de capacité font référence aux extensions, révisions ou amendements à cette spécification. Consultez la documentation de la réponse CAPABILITY dans la Section 7.2.2 pour plus d'informations. Si la capacité IMAP4rev1 n'est pas annoncée, aucune capacité, au-delà de l'ensemble IMAP4rev2 de base défini dans cette spécification, n'est activée sans action client explicite pour invoquer la capacité. Si les capacités IMAP4rev1 et IMAP4rev2 sont toutes deux annoncées, aucune capacité, au-delà de l'ensemble IMAP4rev1 de base spécifié dans [RFC3501], n'est activée sans action client explicite pour invoquer la capacité.

Les implémentations client et serveur doivent (doivent) implémenter les capacités STARTTLS (Section 6.2.1) et LOGINDISABLED sur les ports en texte clair. Les implémentations client et serveur doivent (doivent) également implémenter la capacité AUTH=PLAIN (décrite dans [PLAIN]) sur les ports en texte clair et TLS implicite. Consultez les Considérations de sécurité (Section 11) pour des informations importantes.

Sauf indication contraire, toutes les extensions enregistrées à IMAP4rev1 sont également des extensions valides à IMAP4rev2.

Exemple :

C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTTLS completed
<Négociation TLS, les commandes suivantes sont sous couche TLS>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed

6.1.2 Commande NOOP​

Arguments : aucun

Réponses : aucune réponse spécifique pour cette commande (mais voir ci-dessous)

Résultat :

  • OK - noop terminée
  • BAD - commande inconnue ou arguments invalides

La commande NOOP réussit toujours. Elle ne fait rien.

Étant donné que toute commande peut renvoyer une mise à jour de statut en tant que données non étiquetées, la commande NOOP peut être utilisée comme sondage périodique pour de nouveaux messages ou des mises à jour de statut de message pendant une période d'inactivité (la commande IDLE ; voir Section 6.3.13) devrait être utilisée au lieu de NOOP si des mises à jour en temps réel de l'état de la boîte aux lettres sont souhaitables). La commande NOOP peut également être utilisée pour réinitialiser tout minuteur de déconnexion automatique d'inactivité sur le serveur.

Exemple :

C: a002 NOOP
S: a002 OK NOOP completed
   . . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 14 FETCH (UID 1305 FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed

6.1.3 Commande LOGOUT​

Arguments : aucun

Réponses : Réponse non étiquetée REQUISE : BYE

Résultat :

  • OK - logout terminée
  • BAD - commande inconnue ou arguments invalides

La commande LOGOUT informe le serveur que le client a terminé avec la connexion. Le serveur doit (doit) envoyer une réponse BYE non étiquetée avant la réponse OK (étiquetée), puis fermer la connexion réseau.

Exemple :

C: A023 LOGOUT
S: * BYE IMAP4rev2 Server logging out
S: A023 OK LOGOUT completed
(Le serveur et le client ferment ensuite la connexion)

Note : Le Chapitre 6 est étendu et contient plusieurs sous-sections. Pour la liste complète des commandes, veuillez vous référer aux sous-sections individuelles :

Dernière mise à jour le