6. Commandes du client
RFC 3501 IMAPv4 March 2003
Par exemple, les séquences de commandes non bloquantes suivantes sont invalides :
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
Les exemples suivants sont des exemples de séquences de commandes non bloquantes valides :
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
UID SEARCH + UID SEARCH peut être valide ou invalide en tant que séquence
de commandes non bloquantes, selon que la seconde UID SEARCH contient ou
non des numéros de séquence de message.
6. Commandes du client
Les commandes IMAP4rev1 sont décrites dans cette section. Les commandes sont organisées par l'état dans lequel la commande est permise. Les commandes qui sont permises dans plusieurs états sont listées dans l'état minimal permis (par exemple, les commandes valides dans les états authentifié et sélectionné sont listées dans les commandes de l'état authentifié).
Les arguments de commande, identifiés par « Arguments : » dans les descriptions de commandes ci-dessous, sont décrits par fonction, et non par syntaxe. La syntaxe précise des arguments de commande est décrite dans la section Syntaxe formelle.
Certaines commandes provoquent le renvoi de réponses de serveur spécifiques ; celles-ci sont identifiées par « Responses : » dans les descriptions de commandes ci-dessous. Voir les descriptions des réponses dans la section Réponses du serveur pour des informations sur ces réponses, et la section Syntaxe formelle 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 requièrent 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 documentées comme modifiant l'état. Une commande rejetée (réponse BAD) ne modifie jamais l'état de la connexion ni de la boîte aux lettres sélectionnée. Une commande en échec (réponse NO) ne modifie généralement pas l'état de la connexion ni de la boîte aux lettres sélectionnée ; à l'exception des commandes SELECT et EXAMINE.
RFC 3501 IMAPv4 March 2003
6.1. Commandes du client - Tout état
Les commandes suivantes sont valides dans tout état : CAPABILITY, NOOP et LOGOUT.
6.1.1. Commande CAPABILITY
Arguments : aucun
Réponses : réponse non étiquetée REQUISE : CAPABILITY
Résultat : OK - capacité terminée BAD - commande inconnue ou arguments invalides
La commande CAPABILITY demande une liste des capacités prises en charge par
le serveur. Le serveur DOIT (MUST) envoyer une seule réponse non étiquetée
CAPABILITY avec « IMAP4rev1 » comme l'une des capacités listées avant la
réponse OK (étiquetée).
Un nom de capacité commençant par « AUTH= » indique que le serveur prend en
charge ce mécanisme d'authentification particulier. Tous ces noms font, par
définition, partie de cette spécification. Par exemple, la capacité
d'autorisation pour un authentificateur expérimental « blurdybloop » serait
« AUTH=XBLURDYBLOOP » et non « XAUTH=BLURDYBLOOP » ou « XAUTH=XBLURDYBLOOP ».
D'autres noms de capacités font référence à des extensions, révisions ou
amendements à cette spécification. Voir la documentation de la réponse
CAPABILITY pour des informations supplémentaires. Aucune capacité, au-delà
de l'ensemble de base IMAP4rev1 défini dans cette spécification, n'est activée
sans action explicite du client pour invoquer la capacité.
Les implémentations client et serveur DOIVENT (MUST) implémenter les capacités
STARTTLS, LOGINDISABLED et AUTH=PLAIN (décrites dans [IMAP-TLS]). Voir la
section Considérations de sécurité pour des informations importantes.
Voir la section intitulée « Commandes du client - Expérimental/Extension »
pour des informations sur la forme des capacités spécifiques à un site ou à
une implémentation.
RFC 3501 IMAPv4 March 2003
Exemple : C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev1 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.
Puisque toute commande peut renvoyer une mise à jour d'état sous forme de
données non étiquetées, la commande NOOP peut être utilisée comme sondage
périodique de nouveaux messages ou de mises à jour d'état de message durant
une période d'inactivité (c'est la méthode préférée pour ce faire). La
commande NOOP peut aussi être utilisée pour réinitialiser tout minuteur
de déconnexion automatique pour inactivité sur le serveur.
Exemple : C: a002 NOOP S: a002 OK NOOP completed . . . C: a047 NOOP S: * 22 EXPUNGE S: * 23 EXISTS S: * 3 RECENT S: * 14 FETCH (FLAGS (\Seen \Deleted)) S: a047 OK NOOP completed
RFC 3501 IMAPv4 March 2003
6.1.3. Commande LOGOUT
Arguments : aucun
Réponses : réponse non étiquetée REQUISE : BYE
Résultat : OK - déconnexion 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 (MUST) envoyer une réponse non étiquetée BYE
avant la réponse OK (étiquetée), puis fermer la connexion réseau.
Exemple : C: A023 LOGOUT S: * BYE IMAP4rev1 Server logging out S: A023 OK LOGOUT completed (Le serveur et le client ferment alors la connexion)
6.2. Commandes du client - État non authentifié
Dans l'état non authentifié, la commande AUTHENTICATE ou LOGIN établit l'authentification et entre dans l'état authentifié. La commande AUTHENTICATE fournit un mécanisme général pour une variété de techniques d'authentification, de protection de confidentialité et de vérification d'intégrité ; tandis que la commande LOGIN utilise une paire traditionnelle nom d'utilisateur et mot de passe en clair et n'a aucun moyen d'établir une protection de confidentialité ou une vérification d'intégrité.
La commande STARTTLS est une forme alternative d'établissement de protection de confidentialité et de vérification d'intégrité de session, mais n'établit pas l'authentification ni n'entre dans l'état authentifié.
Les implémentations serveur PEUVENT (MAY) autoriser l'accès à certaines boîtes aux lettres sans établir d'authentification. Cela peut être fait au moyen de l'authentificateur ANONYMOUS [SASL] décrit dans [ANONYMOUS]. Une ancienne convention est une commande LOGIN utilisant l'identifiant « anonymous » ; dans ce cas, un mot de passe est requis bien que le serveur puisse choisir d'accepter tout mot de passe. Les restrictions placées sur les utilisateurs anonymes dépendent de l'implémentation.
Une fois authentifié (y compris comme anonyme), il n'est pas possible de revenir à l'état non authentifié.
RFC 3501 IMAPv4 March 2003
En plus des commandes universelles (CAPABILITY, NOOP et LOGOUT), les commandes suivantes sont valides dans l'état non authentifié : STARTTLS, AUTHENTICATE et LOGIN. Voir la section Considérations de sécurité pour des informations importantes sur ces commandes.
6.2.1. Commande STARTTLS
Arguments : aucun
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - starttls terminée, début de la négociation TLS BAD - commande inconnue ou arguments invalides
Une négociation [TLS] commence immédiatement après le CRLF à la fin de la
réponse OK étiquetée du serveur. Une fois qu'un client a émis une commande
STARTTLS, il NE DOIT PAS (MUST NOT) émettre d'autres commandes jusqu'à ce
qu'une réponse de serveur soit vue et que la négociation [TLS] soit terminée.
Le serveur reste dans l'état non authentifié, même si des identifiants de
client sont fournis durant la négociation [TLS]. Cela n'exclut pas un
mécanisme d'authentification tel que EXTERNAL (défini dans [SASL]) utilisant
l'identité du client déterminée par la négociation [TLS].
Une fois [TLS] démarré, le client DOIT (MUST) ignorer les informations en
cache sur les capacités du serveur et DEVRAIT (SHOULD) réémettre la commande
CAPABILITY. Cela est nécessaire pour se protéger contre les attaques de
l'homme du milieu qui modifient la liste des capacités avant STARTTLS. Le
serveur PEUT (MAY) annoncer des capacités différentes après STARTTLS.
Exemple : C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
RFC 3501 IMAPv4 March 2003
6.2.2. Commande AUTHENTICATE
Arguments : nom de mécanisme d'authentification
Réponses : données de continuation peuvent être demandées
Résultat : OK - authentification terminée, maintenant dans l'état authentifié NO - échec d'authentification : mécanisme d'authentification non pris en charge, identifiants rejetés BAD - commande inconnue ou arguments invalides, échange d'authentification annulé
La commande AUTHENTICATE indique un mécanisme d'authentification [SASL] au
serveur. Si le serveur prend en charge le mécanisme d'authentification
demandé, il effectue un échange de protocole d'authentification pour
authentifier et identifier le client. Il PEUT (MAY) aussi négocier une couche
de sécurité optionnelle pour les interactions de protocole ultérieures. Si le
mécanisme d'authentification demandé n'est pas pris en charge, le serveur
DEVRAIT (SHOULD) rejeter la commande AUTHENTICATE en envoyant une réponse NO
étiquetée.
La commande AUTHENTICATE ne prend pas en charge la fonctionnalité
« réponse initiale » optionnelle de [SASL]. La section 5.1 de [SASL] précise
comment gérer un mécanisme d'authentification qui utilise une réponse
initiale.
Le nom de service spécifié par le profil de [SASL] de ce protocole est « imap ».
L'échange de protocole d'authentification consiste en une série de défis du
serveur et de réponses du client spécifiques au mécanisme d'authentification.
Un défi du serveur consiste en une réponse de demande de continuation de
commande avec le jeton « + » suivi d'une chaîne codée en BASE64. La réponse du
client consiste en une seule ligne consistant en une chaîne codée en BASE64.
Si le client souhaite annuler un échange d'authentification, il émet une ligne
consistant en un seul « * ». Si le serveur reçoit une telle réponse, il DOIT
(MUST) rejeter la commande AUTHENTICATE en envoyant une réponse BAD étiquetée.
Si une couche de sécurité est négociée via l'échange d'authentification [SASL],
elle prend effet immédiatement après le CRLF qui conclut l'échange
d'authentification pour le client, et le CRLF de la réponse OK étiquetée pour
le serveur.
Alors que les implémentations client et serveur DOIVENT (MUST) implémenter la
commande AUTHENTICATE elle-même, il n'est pas requis d'implémenter un
mécanisme d'authentification autre que le mécanisme PLAIN décrit dans
[IMAP-TLS]. Aussi, un mécanisme d'authentification n'est pas requis pour
prendre en charge des couches de sécurité.
Note : une implémentation serveur DOIT (MUST) implémenter une
configuration dans laquelle elle ne PERMET PAS de mécanismes de mot de
passe en clair, à moins que la commande STARTTLS n'ait été négociée ou
qu'un autre mécanisme protégeant la session contre l'interception des
mots de passe n'ait été fourni. Les sites serveur NE DEVRAIENT PAS
(SHOULD NOT) utiliser de configuration qui permet un mécanisme de mot de
passe en clair sans un tel mécanisme de protection contre l'interception
des mots de passe. Les implémentations client et serveur DEVRAIENT
(SHOULD) implémenter des mécanismes [SASL] supplémentaires qui
n'utilisent pas de mots de passe en clair, tels que le mécanisme GSSAPI
décrit dans [SASL] et/ou le mécanisme [DIGEST-MD5].
Les serveurs et clients peuvent prendre en charge plusieurs mécanismes
d'authentification. Le serveur DEVRAIT (SHOULD) lister ses mécanismes
d'authentification pris en charge dans la réponse à la commande CAPABILITY
afin que le client sache quels mécanismes d'authentification utiliser.
Un serveur PEUT (MAY) inclure un code de réponse CAPABILITY dans la réponse OK
étiquetée d'une commande AUTHENTICATE réussie afin d'envoyer des capacités
automatiquement. Il est inutile pour un client d'envoyer une commande
CAPABILITY séparée s'il reconnaît ces capacités automatiques. Cela ne doit
être fait que si une couche de sécurité n'a pas été négociée par la commande
AUTHENTICATE, car la réponse OK étiquetée dans le cadre d'une commande
AUTHENTICATE n'est pas protégée par le chiffrement/la vérification
d'intégrité. [SASL] exige du client de réémettre une commande CAPABILITY dans
ce cas.
Si une commande AUTHENTICATE échoue avec une réponse NO, le client PEUT (MAY)
essayer un autre mécanisme d'authentification en émettant une autre commande
AUTHENTICATE. Il PEUT (MAY) aussi tenter de s'authentifier en utilisant la
commande LOGIN (voir la section 6.2.3 pour plus de détails). En d'autres
termes, le client PEUT (MAY) demander des types d'authentification par ordre
de préférence décroissant, avec la commande LOGIN comme dernier recours.
L'identité d'autorisation passée du client au serveur durant l'échange
d'authentification est interprétée par le serveur comme le nom d'utilisateur
dont le client demande les privilèges.
RFC 3501 IMAPv4 March 2003
Exemple : S: * OK IMAP4rev1 Server C: A001 AUTHENTICATE GSSAPI S: + C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0 b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW Lud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg== S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0 uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg== C: S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe ceP2CWY0SR0fAQAgAAQEBAQ= C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP wkhbfa2QteAQAgAG1yYwE= S: A001 OK GSSAPI authentication successful
Note : les sauts de ligne dans les défis du serveur et les réponses du
client sont pour la clarté éditoriale et ne sont pas dans les
authentificateurs réels.
6.2.3. Commande LOGIN
Arguments : nom d'utilisateur mot de passe
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - connexion terminée, maintenant dans l'état authentifié NO - échec de connexion : nom d'utilisateur ou mot de passe rejeté BAD - commande inconnue ou arguments invalides
La commande LOGIN identifie le client au serveur et transporte le mot de
passe en clair authentifiant cet utilisateur.
RFC 3501 IMAPv4 March 2003
Un serveur PEUT (MAY) inclure un code de réponse CAPABILITY dans la réponse OK
étiquetée à une commande LOGIN réussie afin d'envoyer des capacités
automatiquement. Il est inutile pour un client d'envoyer une commande
CAPABILITY séparée s'il reconnaît ces capacités automatiques.
Exemple : C: a001 LOGIN SMITH SESAME S: a001 OK LOGIN completed
Note : l'utilisation de la commande LOGIN sur un réseau non sécurisé (tel
qu'Internet) est un risque de sécurité, car toute personne surveillant le
trafic réseau peut obtenir des mots de passe en clair. La commande LOGIN
NE DEVRAIT PAS (SHOULD NOT) être utilisée sauf en dernier recours, et il
est recommandé que les implémentations client aient un moyen de désactiver
toute utilisation automatique de la commande LOGIN.
À moins que la commande STARTTLS n'ait été négociée ou qu'un autre mécanisme
protégeant la session contre l'interception des mots de passe n'ait été
fourni, une implémentation serveur DOIT (MUST) implémenter une configuration
dans laquelle elle annonce la capacité LOGINDISABLED et ne PERMET PAS la
commande LOGIN. Les sites serveur NE DEVRAIENT PAS (SHOULD NOT) utiliser de
configuration qui permet la commande LOGIN sans un tel mécanisme de
protection contre l'interception des mots de passe. Une implémentation
client NE DOIT PAS (MUST NOT) envoyer une commande LOGIN si la capacité
LOGINDISABLED est annoncée.
6.3. Commandes du client - État authentifié
Dans l'état authentifié, les commandes qui manipulent les boîtes aux lettres en tant qu'entités atomiques sont permises. De ces commandes, les 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é : SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS et APPEND.
RFC 3501 IMAPv4 March 2003
6.3.1. Commande SELECT
Arguments : nom de boîte aux lettres
Réponses : réponses non étiquetées REQUISES : FLAGS, EXISTS, RECENT réponses OK non étiquetées REQUISES : UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY
Résultat : OK - sélection terminée, maintenant dans l'état sélectionné NO - échec de sélection, maintenant dans l'état authentifié : pas de telle boîte aux lettres, impossible d'accéder à la boîte BAD - commande inconnue ou arguments invalides
La commande SELECT sélectionne une boîte aux lettres afin que les messages
dans la boîte aux lettres puissent être accessibles. Avant de renvoyer un OK
au client, le serveur DOIT (MUST) envoyer les données non étiquetées suivantes
au client. Notez que les versions antérieures de ce protocole n'exigeaient
que les données non étiquetées FLAGS, EXISTS et RECENT ; par conséquent, les
implémentations client DEVRAIENT (SHOULD) implémenter un comportement par
défaut pour les données manquantes comme discuté avec l'élément individuel.
FLAGS Indicateurs définis dans la boîte aux lettres. Voir la
description de la réponse FLAGS pour plus de détail.
`<n>` EXISTS Le nombre de messages dans la boîte aux lettres. Voir la
description de la réponse EXISTS pour plus de détail.
`<n>` RECENT Le nombre de messages avec l'indicateur \Recent défini.
Voir la description de la réponse RECENT pour plus de détail.
OK [UNSEEN `<n>`]
Le numéro de séquence de message du premier message non lu
dans la boîte aux lettres. S'il est absent, le client ne peut
faire aucune hypothèse sur le premier message non lu dans la
boîte aux lettres, et doit émettre une commande SEARCH s'il
veut le trouver.
OK [PERMANENTFLAGS (`<liste d'indicateurs>`)]
Une liste d'indicateurs de message que le client peut modifier
de manière permanente. S'il est absent, le client doit supposer
que tous les indicateurs peuvent être modifiés de manière
permanente.
OK [UIDNEXT `<n>`]
La prochaine valeur d'identifiant unique. Reportez-vous à la
section 2.3.1.1 pour plus d'informations. S'il est absent, le
client ne peut faire aucune hypothèse sur la prochaine valeur
d'identifiant unique.
RFC 3501 IMAPv4 March 2003
OK [UIDVALIDITY `<n>`]
La valeur de validité de l'identifiant unique. Reportez-vous à
la section 2.3.1.1 pour plus d'informations. S'il est absent, le
serveur ne prend pas en charge les identifiants uniques.
Une seule boîte aux lettres peut être sélectionnée à la fois dans une connexion
; l'accès simultané à plusieurs boîtes aux lettres nécessite plusieurs
connexions. La commande SELECT désélectionne automatiquement toute boîte aux
lettres actuellement sélectionnée avant de tenter la nouvelle sélection. Par
conséquent, si une boîte aux lettres est sélectionnée et qu'une commande
SELECT qui échoue est tentée, aucune boîte aux lettres n'est sélectionnée.
Si le client est autorisé à modifier la boîte aux lettres, le serveur DEVRAIT
(SHOULD) préfixer le texte de la réponse OK étiquetée avec le code de réponse
« [READ-WRITE] ».
Si le client n'est pas autorisé à modifier la boîte aux lettres mais est
autorisé en accès en lecture, la boîte aux lettres est sélectionnée en lecture
seule, et le serveur DOIT (MUST) préfixer le texte de la réponse OK étiquetée
à SELECT avec le code de réponse « [READ-ONLY] ». L'accès en lecture seule via
SELECT diffère de la commande EXAMINE en ce que certaines boîtes aux lettres en
lecture seule PEUVENT (MAY) permettre la modification de l'état permanent sur
une base par utilisateur (par opposition à globale). Les messages Netnews
marqués dans un fichier .newsrc basé sur le serveur sont un exemple d'un tel
état permanent par utilisateur qui peut être modifié avec des boîtes aux
lettres en lecture seule.
Exemple : C: A142 SELECT INBOX S: * 172 EXISTS S: * 1 RECENT S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Deleted \Seen *)] Limited S: A142 OK [READ-WRITE] SELECT completed
RFC 3501 IMAPv4 March 2003
6.3.2. Commande EXAMINE
Arguments : nom de boîte aux lettres
Réponses : réponses non étiquetées REQUISES : FLAGS, EXISTS, RECENT réponses OK non étiquetées REQUISES : UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY
Résultat : OK - examen terminé, maintenant dans l'état sélectionné NO - échec d'examen, maintenant dans l'état authentifié : pas de telle boîte aux lettres, impossible d'accéder à la boîte BAD - commande inconnue ou arguments invalides
La commande EXAMINE est identique à SELECT et renvoie la même sortie ;
toutefois, la boîte aux lettres sélectionnée est identifiée en lecture seule.
Aucune modification de l'état permanent de la boîte aux lettres, y compris
l'état par utilisateur, n'est permise ; en particulier, EXAMINE NE DOIT PAS
(MUST NOT) faire perdre l'indicateur \Recent aux messages.
Le texte de la réponse OK étiquetée à la commande EXAMINE DOIT (MUST)
commencer par le code de réponse « [READ-ONLY] ».
Exemple : C: A932 EXAMINE blurdybloop S: * 17 EXISTS S: * 2 RECENT S: * OK [UNSEEN 8] Message 8 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS ()] No permanent flags permitted S: A932 OK [READ-ONLY] EXAMINE completed
6.3.3. Commande CREATE
Arguments : nom de boîte aux lettres
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - création terminée NO - échec de création : impossible de créer la boîte aux lettres avec ce nom BAD - commande inconnue ou arguments invalides
La commande CREATE crée une boîte aux lettres avec le nom donné. Une réponse
OK n'est renvoyée que si une nouvelle boîte aux lettres avec ce nom a été
créée. Il est une erreur de tenter de créer INBOX ou une boîte aux lettres
dont le nom fait référence à une boîte aux lettres existante. Toute erreur de
création renverra une réponse NO étiquetée.
RFC 3501 IMAPv4 March 2003
Si le nom de la boîte aux lettres est suffixé par le caractère séparateur de
hiérarchie du serveur (tel que renvoyé par le serveur par une commande LIST),
c'est une déclaration que le client a l'intention de créer des noms de boîtes
aux lettres sous ce nom dans la hiérarchie. Les implémentations serveur qui
n'exigent pas cette déclaration DOIVENT (MUST) ignorer la déclaration. Dans
tous les cas, le nom créé est sans le séparateur de hiérarchie final.
Si le caractère séparateur de hiérarchie du serveur apparaît ailleurs dans le
nom, le serveur DEVRAIT (SHOULD) créer tous les noms hiérarchiques supérieurs
nécessaires pour que la commande CREATE soit complétée avec succès. En d'autres
termes, une tentative de création de « foo/bar/zap » sur un serveur où « / »
est le caractère séparateur de hiérarchie DEVRAIT (SHOULD) créer foo/ et
foo/bar/ s'ils n'existent pas déjà.
Si une nouvelle boîte aux lettres est créée avec le même nom qu'une boîte aux
lettres qui a été supprimée, ses identifiants uniques DOIVENT (MUST) être
supérieurs à tout identifiant unique utilisé dans l'incarnation précédente de
la boîte aux lettres À MOINS QUE la nouvelle incarnation n'ait une valeur de
validité d'identifiant unique différente. Voir la description de la commande
UID pour plus de détail.
Exemple : C: A003 CREATE owatagusiam/ S: A003 OK CREATE completed C: A004 CREATE owatagusiam/blurdybloop S: A004 OK CREATE completed
Note : l'interprétation de cet exemple dépend de si « / » a été renvoyé
comme séparateur de hiérarchie par LIST. Si « / » est le séparateur de
hiérarchie, un nouveau niveau de hiérarchie nommé « owatagusiam » avec un
membre appelé « blurdybloop » est créé. Sinon, deux boîtes aux lettres au
même niveau de hiérarchie sont créées.
6.3.4. Commande DELETE
Arguments : nom de boîte aux lettres
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - suppression terminée NO - échec de suppression : impossible de supprimer la boîte aux lettres avec ce nom BAD - commande inconnue ou arguments invalides
RFC 3501 IMAPv4 March 2003
La commande DELETE supprime de manière permanente la boîte aux lettres avec le
nom donné. Une réponse OK étiquetée n'est renvoyée que si la boîte aux lettres
a été supprimée. Il est une erreur de tenter de supprimer INBOX ou un nom de
boîte aux lettres qui n'existe pas.
La commande DELETE NE DOIT PAS (MUST NOT) supprimer les noms hiérarchiques
inférieurs. Par exemple, si une boîte aux lettres « foo » a un inférieur
« foo.bar » (en supposant que « . » est le caractère séparateur de hiérarchie),
la suppression de « foo » NE DOIT PAS (MUST NOT) supprimer « foo.bar ». Il est
une erreur de tenter de supprimer un nom qui a des noms hiérarchiques
inférieurs et a aussi l'attribut de nom de boîte aux lettres \Noselect (voir la
description de la réponse LIST pour plus de détails).
Il est permis de supprimer un nom qui a des noms hiérarchiques inférieurs et
n'a pas l'attribut de nom de boîte aux lettres \Noselect. Dans ce cas, tous les
messages dans cette boîte aux lettres sont supprimés, et le nom acquerra
l'attribut de nom de boîte aux lettres \Noselect.
La valeur de l'identifiant unique le plus utilisé de la boîte aux lettres
supprimée DOIT (MUST) être préservée afin qu'une nouvelle boîte aux lettres
créée avec le même nom ne réutilise pas les identifiants de l'incarnation
précédente, À MOINS QUE la nouvelle incarnation n'ait une valeur de validité
d'identifiant unique différente. Voir la description de la commande UID pour
plus de détail.
Exemples : C: A682 LIST "" * S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/" foo S: * LIST () "/" foo/bar S: A682 OK LIST completed C: A683 DELETE blurdybloop S: A683 OK DELETE completed C: A684 DELETE foo S: A684 NO Name "foo" has inferior hierarchical names C: A685 DELETE foo/bar S: A685 OK DELETE Completed C: A686 LIST "" * S: * LIST (\Noselect) "/" foo S: A686 OK LIST completed C: A687 DELETE foo S: A687 OK DELETE Completed
RFC 3501 IMAPv4 March 2003
C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed
6.3.5. Commande RENAME
Arguments : nom de boîte aux lettres existant nouveau nom de boîte aux lettres
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - renommage terminé NO - échec de renommage : impossible de renommer la boîte aux lettres avec ce nom, impossible de renommer vers la boîte aux lettres avec ce nom BAD - commande inconnue ou arguments invalides
La commande RENAME change le nom d'une boîte aux lettres. Une réponse OK
étiquetée n'est renvoyée que si la boîte aux lettres a été renommée. Il est une
erreur de tenter de renommer à partir d'un nom de boîte aux lettres qui
n'existe pas ou vers un nom de boîte aux lettres qui existe déjà. Toute erreur
de renommage renverra une réponse NO étiquetée.
Si le nom a des noms hiérarchiques inférieurs, alors les noms hiérarchiques
inférieurs DOIVENT (MUST) aussi être renommés. Par exemple, un renommage de
« foo » en « zap » renommera « foo/bar » (en supposant que « / » est le
caractère séparateur de hiérarchie) en « zap/bar ».
Si le caractère séparateur de hiérarchie du serveur apparaît dans le nom, le
serveur DEVRAIT (SHOULD) créer tous les noms hiérarchiques supérieurs
nécessaires pour que la commande RENAME se complète avec succès. En d'autres
termes, une tentative de renommage de « foo/bar/zap » en baz/rag/zowie sur un
serveur où « / » est le caractère séparateur de hiérarchie DEVRAIT (SHOULD)
créer baz/ et baz/rag/ s'ils n'existent pas déjà.
RFC 3501 IMAPv4 March 2003
La valeur de l'identifiant unique le plus utilisé de l'ancien nom de boîte
aux lettres DOIT (MUST) être préservée afin qu'une nouvelle boîte aux lettres
créée avec le même nom ne réutilise pas les identifiants de l'incarnation
précédente, À MOINS QUE la nouvelle incarnation n'ait une valeur de validité
d'identifiant unique différente. Voir la description de la commande UID pour
plus de détail.
Le renommage d'INBOX est permis, et a un comportement spécial. Il déplace tous
les messages dans INBOX vers une nouvelle boîte aux lettres avec le nom donné,
laissant INBOX vide. Si l'implémentation du serveur prend en charge des noms
hiérarchiques inférieurs d'INBOX, ceux-ci ne sont pas affectés par un renommage
d'INBOX.
Exemples : C: A682 LIST "" * S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/" foo S: * LIST () "/" foo/bar S: A682 OK LIST completed C: A683 RENAME blurdybloop sarasoop S: A683 OK RENAME completed C: A684 RENAME foo zowie S: A684 OK RENAME Completed C: A685 LIST "" * S: * LIST () "/" sarasoop S: * LIST (\Noselect) "/" zowie S: * LIST () "/" zowie/bar S: A685 OK LIST completed
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed
RFC 3501 IMAPv4 March 2003
6.3.6. Commande SUBSCRIBE
Arguments : boîte aux lettres
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - abonnement terminé NO - échec d'abonnement : impossible de s'abonner à ce nom BAD - commande inconnue ou arguments invalides
La commande SUBSCRIBE ajoute le nom de boîte aux lettres spécifié à
l'ensemble des boîtes aux lettres « actives » ou « abonnées » du serveur tel
que renvoyé par la commande LSUB. Cette commande renvoie une réponse OK
étiquetée seulement si l'abonnement réussit.
Un serveur PEUT (MAY) valider l'argument de boîte aux lettres de SUBSCRIBE
pour vérifier qu'il existe. Toutefois, il NE DOIT PAS (MUST NOT) supprimer
unilatéralement un nom de boîte aux lettres existant de la liste d'abonnement
même si une boîte aux lettres portant ce nom n'existe plus.
Note : cette exigence est due au fait qu'un site serveur peut choisir
de supprimer régulièrement une boîte aux lettres avec un nom bien connu
(par exemple « system-alerts ») après l'expiration de son contenu, dans
l'intention de la recréer lorsque de nouveaux contenus sont appropriés.
Exemple : C: A002 SUBSCRIBE #news.comp.mail.mime S: A002 OK SUBSCRIBE completed
6.3.7. Commande UNSUBSCRIBE
Arguments : nom de boîte aux lettres
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - désabonnement terminé NO - échec de désabonnement : impossible de se désabonner de ce nom BAD - commande inconnue ou arguments invalides
La commande UNSUBSCRIBE supprime le nom de boîte aux lettres spécifié de
l'ensemble des boîtes aux lettres « actives » ou « abonnées » du serveur tel
que renvoyé par la commande LSUB. Cette commande renvoie une réponse OK
étiquetée seulement si le désabonnement réussit.
Exemple : C: A002 UNSUBSCRIBE #news.comp.mail.mime S: A002 OK UNSUBSCRIBE completed
RFC 3501 IMAPv4 March 2003
6.3.8. Commande LIST
Arguments : nom de référence nom de boîte aux lettres avec caractères génériques possibles
Réponses : réponses non étiquetées : LIST
Résultat : OK - liste terminée NO - échec de liste : impossible de lister cette référence ou ce nom BAD - commande inconnue ou arguments invalides
La commande LIST renvoie un sous-ensemble de noms de l'ensemble complet de
tous les noms disponibles au client. Zéro ou plusieurs réponses LIST non
étiquetées sont renvoyées, contenant les attributs de nom, le séparateur de
hiérarchie et le nom ; voir la description de la réponse LIST pour plus de
détail.
La commande LIST DEVRAIT (SHOULD) renvoyer ses données rapidement, sans retard
indu. Par exemple, elle NE DEVRAIT PAS (SHOULD NOT) faire trop d'efforts pour
calculer le statut \Marked ou \Unmarked ou effectuer un autre traitement ; si
chaque nom nécessite 1 seconde de traitement, alors une liste de 1200 noms
prendrait 20 minutes !
Un argument de nom de référence vide (chaîne « ») indique que le nom de boîte
aux lettres est interprété comme par SELECT. Les noms de boîtes aux lettres
renvoyés DOIVENT (MUST) correspondre au motif de nom de boîte aux lettres
fourni. Un argument de nom de référence non vide est le nom d'une boîte aux
lettres ou d'un niveau de hiérarchie de boîtes aux lettres, et indique le
contexte dans lequel le nom de boîte aux lettres est interprété.
Un argument de nom de boîte aux lettres vide (chaîne « ») est une demande
spéciale pour renvoyer le séparateur de hiérarchie et le nom racine du nom
donné dans la référence. La valeur renvoyée comme racine PEUT (MAY) être la
chaîne vide si la référence n'est pas enracinée ou est une chaîne vide. Dans
tous les cas, un séparateur de hiérarchie (ou NIL s'il n'y a pas de
hiérarchie) est renvoyé. Cela permet à un client d'obtenir le séparateur de
hiérarchie (ou de découvrir que les noms de boîtes aux lettres sont plats)
même lorsqu'aucune boîte aux lettres de ce nom n'existe actuellement.
Les arguments de référence et de nom de boîte aux lettres sont interprétés en
une forme canonique qui représente une hiérarchie non ambiguë de gauche à
droite. Les noms de boîtes aux lettres renvoyés seront dans la forme
interprétée.
RFC 3501 IMAPv4 March 2003
Note : l'interprétation de l'argument de référence est définie par
l'implémentation. Elle dépend de si l'implémentation du serveur a un
concept de « répertoire de travail courant » et de « caractères
d'échappement » initiaux qui remplacent le répertoire de travail
courant.
Par exemple, sur un serveur qui exporte un système de fichiers UNIX ou
NT, l'argument de référence contient le répertoire de travail courant,
et l'argument de nom de boîte aux lettres contiendrait le nom tel
qu'interprété dans le répertoire de travail courant.
Si une implémentation serveur n'a pas de concept de caractères
d'échappement, la forme canonique est normalement le nom de référence
suivi du nom de boîte aux lettres. Notez que si le serveur implémente la
convention d'espace de noms (section 5.1.2), « # » est un caractère
d'échappement et doit être traité comme tel.
Si l'argument de référence n'est pas un niveau de hiérarchie de boîtes
aux lettres (c'est-à-dire, c'est un nom \NoInferiors), et/ou l'argument
de référence ne se termine pas par le séparateur de hiérarchie, il est
défini par l'implémentation comment cela est interprété. Par exemple, une
référence de « foo/bar » et un nom de boîte aux lettres de « rag/baz »
pourraient être interprétés comme « foo/bar/rag/baz », « foo/barrag/baz »
ou « foo/rag/baz ». Un client NE DEVRAIT PAS (SHOULD NOT) utiliser un tel
argument de référence sauf à la demande explicite de l'utilisateur. Un
navigateur hiérarchique NE DOIT PAS (MUST NOT) faire d'hypothèse sur
l'interprétation serveur de la référence à moins que la référence ne soit
un niveau de hiérarchie de boîtes aux lettres ET se termine par le
séparateur de hiérarchie.
Toute partie de l'argument de référence incluse dans la forme interprétée
DEVRAIT (SHOULD) préfixer la forme interprétée. Elle DEVRAIT (SHOULD) aussi
être dans la même forme que l'argument de nom de référence. Cette règle permet
au client de déterminer si le nom de boîte aux lettres renvoyé est dans le
contexte de l'argument de référence, ou si quelque chose concernant l'argument
de boîte aux lettres a remplacé l'argument de référence. Sans cette règle, le
client devrait avoir connaissance de la sémantique de nommage du serveur
incluant quels caractères sont des « échappements » qui remplacent un contexte
de nommage.
RFC 3501 IMAPv4 March 2003
Par exemple, voici quelques exemples de comment les références et noms de
boîtes aux lettres pourraient être interprétés sur un serveur basé sur
UNIX :
Référence Nom de boîte Interprétation
------------ ------------ --------------
~smith/Mail/ foo.* ~smith/Mail/foo.*
archive/ % archive/%
#news. comp.mail.* #news.comp.mail.*
~smith/Mail/ /usr/doc/foo /usr/doc/foo
archive/ ~fred/Mail/* ~fred/Mail/*
Les trois premiers exemples illustrent des interprétations dans le
contexte de l'argument de référence. Notez que « ~smith/Mail » NE DEVRAIT
PAS (SHOULD NOT) être transformé en quelque chose comme « /u2/users/smith/
Mail », ou il serait impossible pour le client de déterminer que
l'interprétation était dans le contexte de la référence.
Le caractère « * » est un caractère générique, et correspond à zéro ou
plusieurs caractères à cette position. Le caractère « % » est similaire à « * »,
mais il ne correspond pas à un séparateur de hiérarchie. Si le caractère
générique « % » est le dernier caractère d'un argument de nom de boîte aux
lettres, des niveaux de hiérarchie correspondants sont aussi renvoyés. Si ces
niveaux de hiérarchie ne sont pas non plus des boîtes aux lettres sélectionnables,
ils sont renvoyés avec l'attribut de nom de boîte aux lettres \Noselect (voir la
description de la réponse LIST pour plus de détails).
Les implémentations serveur sont autorisées à « masquer » des boîtes aux
lettres autrement accessibles des caractères génériques, en empêchant certains
caractères ou noms de correspondre à un générique dans certaines situations. Par
exemple, un serveur basé sur UNIX pourrait restreindre l'interprétation de « * »
afin qu'un caractère initial « / » ne corresponde pas.
Le nom spécial INBOX est inclus dans la sortie de LIST, si INBOX est pris en
charge par ce serveur pour cet utilisateur et si la chaîne en majuscules « INBOX »
correspond aux arguments de référence et de nom de boîte aux lettres interprétés
avec caractères génériques comme décrit ci-dessus. Le critère pour omettre INBOX
est si SELECT INBOX renverra un échec ; il n'est pas pertinent si la vraie INBOX
de l'utilisateur réside sur ce serveur ou sur un autre.
RFC 3501 IMAPv4 March 2003
Exemple : C: A101 LIST "" "" S: * LIST (\Noselect) "/" "" S: A101 OK LIST Completed C: A102 LIST #news.comp.mail.misc "" S: * LIST (\Noselect) "." #news. S: A102 OK LIST Completed C: A103 LIST /usr/staff/jones "" S: * LIST (\Noselect) "/" / S: A103 OK LIST Completed C: A202 LIST ~/Mail/ % S: * LIST (\Noselect) "/" ~/Mail/foo S: * LIST () "/" ~/Mail/meetings S: A202 OK LIST completed
6.3.9. Commande LSUB
Arguments : nom de référence nom de boîte aux lettres avec caractères génériques possibles
Réponses : réponses non étiquetées : LSUB
Résultat : OK - lsub terminé NO - échec de lsub : impossible de lister cette référence ou ce nom BAD - commande inconnue ou arguments invalides
La commande LSUB renvoie un sous-ensemble de noms de l'ensemble des noms que
l'utilisateur a déclarés comme « actifs » ou « abonnés ». Zéro ou plusieurs
réponses LSUB non étiquetées sont renvoyées. Les arguments de LSUB sont sous la
même forme que ceux de LIST.
La réponse LSUB non étiquetée renvoyée PEUT (MAY) contenir des indicateurs de
boîte aux lettres différents d'une réponse LIST non étiquetée. Si cela devait
arriver, les indicateurs dans la LIST non étiquetée sont considérés plus
autoritaires.
Une situation spéciale survient lors de l'utilisation de LSUB avec le caractère
générique « % ». Considérez ce qui arrive si « foo/bar » (avec un séparateur de
hiérarchie de « / ») est abonné mais « foo » ne l'est pas. Un caractère générique
« % » pour LSUB doit renvoyer foo, et non foo/bar, dans la réponse LSUB, et il
DOIT (MUST) être marqué avec l'attribut \Noselect.
Le serveur NE DOIT PAS (MUST NOT) supprimer unilatéralement un nom de boîte aux
lettres existant de la liste d'abonnement même si une boîte aux lettres portant
ce nom n'existe plus.
RFC 3501 IMAPv4 March 2003
Exemple : C: A002 LSUB "#news." "comp.mail.*" S: * LSUB () "." #news.comp.mail.mime S: * LSUB () "." #news.comp.mail.misc S: A002 OK LSUB completed C: A003 LSUB "#news." "comp.%" S: * LSUB (\NoSelect) "." #news.comp.mail S: A003 OK LSUB completed
6.3.10. Commande STATUS
Arguments : nom de boîte aux lettres noms d'éléments de données d'état
Réponses : réponses non étiquetées : STATUS
Résultat : OK - état terminé NO - échec d'état : pas d'état pour ce nom BAD - commande inconnue ou arguments invalides
La commande STATUS demande l'état de la boîte aux lettres indiquée. Elle ne
modifie pas la boîte aux lettres actuellement sélectionnée, ni n'affecte
l'état d'aucun message dans la boîte aux lettres interrogée (en particulier,
STATUS NE DOIT PAS (MUST NOT) faire perdre l'indicateur \Recent aux messages).
La commande STATUS fournit une alternative à l'ouverture d'une seconde connexion
IMAP4rev1 et à l'exécution d'une commande EXAMINE sur une boîte aux lettres pour
interroger l'état de cette boîte aux lettres sans désélectionner la boîte aux
lettres actuellement sélectionnée dans la première connexion IMAP4rev1.
Contrairement à la commande LIST, la commande STATUS n'est pas garantie d'être
rapide dans sa réponse. Dans certaines circonstances, elle peut être assez
lente. Dans certaines implémentations, le serveur est obligé d'ouvrir la boîte
aux lettres en lecture seule en interne pour obtenir certaines informations
d'état. Aussi, contrairement à la commande LIST, la commande STATUS n'accepte
pas de caractères génériques.
Note : la commande STATUS est destinée à accéder à l'état de boîtes aux
lettres autres que la boîte aux lettres actuellement sélectionnée. Parce
que la commande STATUS peut provoquer l'ouverture interne de la boîte aux
lettres, et parce que cette information est disponible par d'autres moyens
sur la boîte aux lettres sélectionnée, la commande STATUS NE DEVRAIT PAS
(SHOULD NOT) être utilisée sur la boîte aux lettres actuellement
sélectionnée.
RFC 3501 IMAPv4 March 2003
La commande STATUS NE DOIT PAS (MUST NOT) être utilisée comme une
opération « vérifier les nouveaux messages dans la boîte aux lettres
sélectionnée » (reportez-vous aux sections 7, 7.3.1 et 7.3.2 pour plus
d'informations sur la méthode appropriée de vérification de nouveaux
messages).
Parce que la commande STATUS n'est pas garantie d'être rapide dans ses
résultats, les clients NE DEVRAIENT PAS (SHOULD NOT) s'attendre à pouvoir
émettre de nombreuses commandes STATUS consécutives et obtenir des
performances raisonnables.
Les éléments de données d'état actuellement définis qui peuvent être demandés
sont :
MESSAGES
Le nombre de messages dans la boîte aux lettres.
RECENT
Le nombre de messages avec l'indicateur \Recent défini.
UIDNEXT
La prochaine valeur d'identifiant unique de la boîte aux lettres.
Reportez-vous à la section 2.3.1.1 pour plus d'informations.
UIDVALIDITY
La valeur de validité de l'identifiant unique de la boîte aux lettres.
Reportez-vous à la section 2.3.1.1 pour plus d'informations.
UNSEEN
Le nombre de messages qui n'ont pas l'indicateur \Seen défini.
Exemple : C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) S: A042 OK STATUS completed
RFC 3501 IMAPv4 March 2003
6.3.11. Commande APPEND
Arguments : nom de boîte aux lettres liste d'indicateurs entre parenthèses FACULTATIVE chaîne date-heure FACULTATIVE littéral de message
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - ajout terminé NO - erreur d'ajout : impossible d'ajouter à cette boîte aux lettres, erreur dans les indicateurs ou date-heure ou texte du message BAD - commande inconnue ou arguments invalides
La commande APPEND ajoute l'argument littéral comme nouveau message à la fin de
la boîte aux lettres de destination spécifiée. Cet argument DEVRAIT (SHOULD)
être au format d'un message [RFC-2822]. Les caractères 8 bits sont permis dans
le message. Une implémentation serveur incapable de préserver correctement les
données 8 bits DOIT (MUST) être capable de convertir de manière réversible les
données APPEND 8 bits en 7 bits en utilisant un codage de transfert de contenu
[MIME-IMB].
Note : il PEUT (MAY) y avoir des exceptions, par exemple des messages
brouillon, dans lesquels les lignes d'en-tête [RFC-2822] requises sont
omises dans l'argument littéral de message à APPEND. Les implications
complètes de le faire DOIVENT (MUST) être comprises et soigneusement
pesées.
Si une liste d'indicateurs entre parenthèses est spécifiée, les indicateurs
DEVRAIENT (SHOULD) être définis dans le message résultant ; sinon, la liste
d'indicateurs du message résultant est définie à vide par défaut. Dans les deux
cas, l'indicateur Recent est aussi défini.
Si une date-heure est spécifiée, la date interne DEVRAIT (SHOULD) être définie
dans le message résultant ; sinon, la date interne du message résultant est
définie à la date et l'heure courantes par défaut.
Si l'ajout échoue pour une raison quelconque, la boîte aux lettres DOIT (MUST)
être restaurée à son état avant la tentative APPEND ; aucun ajout partiel n'est
permis.
Si la boîte aux lettres de destination n'existe pas, un serveur DOIT (MUST)
renvoyer une erreur, et NE DOIT PAS (MUST NOT) créer automatiquement la boîte
aux lettres. À moins qu'il ne soit certain que la boîte aux lettres de
destination ne peut être créée, le serveur DOIT (MUST) envoyer le code de
réponse « [TRYCREATE] » comme préfixe du texte de la réponse NO étiquetée. Cela
donne un indice au client qu'il peut tenter une commande CREATE et réessayer
l'APPEND si le CREATE réussit.
RFC 3501 IMAPv4 March 2003
Si la boîte aux lettres est actuellement sélectionnée, les actions normales de
nouveau message DEVRAIENT (SHOULD) se produire. Spécifiquement, le serveur DEVRAIT
(SHOULD) notifier le client immédiatement via une réponse EXISTS non étiquetée.
Si le serveur ne le fait pas, le client PEUT (MAY) émettre une commande NOOP (ou
à défaut, une commande CHECK) après une ou plusieurs commandes APPEND.
Exemple : C: A003 APPEND saved-messages (\Seen) \{310\}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <[email protected]>
C: Subject: afternoon meeting
C: To: [email protected]
C: Message-Id: <[email protected]>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed
Note : la commande APPEND n'est pas utilisée pour la remise de messages,
car elle ne fournit pas de mécanisme pour transférer les informations
d'enveloppe [SMTP].
6.4. Commandes du client - État sélectionné
Dans l'état sélectionné, les commandes qui manipulent les messages dans une boîte aux lettres sont permises.
En plus des commandes universelles (CAPABILITY, NOOP et LOGOUT), et des commandes de l'état authentifié (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS et APPEND), les commandes suivantes sont valides dans l'état sélectionné : CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY et UID.
6.4.1. Commande CHECK
Arguments : aucun
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - vérification terminée BAD - commande inconnue ou arguments invalides
La commande CHECK demande un point de contrôle de la boîte aux lettres
actuellement sélectionnée. Un point de contrôle fait référence à toute
maintenance dépendante de l'implémentation associée à la boîte aux lettres (par
exemple, résolution de l'état en mémoire du serveur de la boîte aux lettres avec
l'état sur son disque) qui n'est pas normalement exécutée dans le cadre de
chaque commande. Un point de contrôle PEUT (MAY) prendre un temps réel non
instantané pour se compléter. Si une implémentation serveur n'a pas de telles
considérations de maintenance, CHECK est équivalent à NOOP.
Il n'y a aucune garantie qu'une réponse EXISTS non étiquetée se produise à la
suite de CHECK. NOOP, et non CHECK, DEVRAIT (SHOULD) être utilisé pour le
sondage de nouveaux messages.
Exemple : C: FXXZ CHECK S: FXXZ OK CHECK Completed
6.4.2. Commande CLOSE
Arguments : aucun
Réponses : aucune réponse spécifique pour cette commande
Résultat : OK - fermeture terminée, maintenant dans l'état authentifié BAD - commande inconnue ou arguments invalides
La commande CLOSE supprime de manière permanente tous les messages qui ont
l'indicateur \Deleted défini de la boîte aux lettres actuellement sélectionnée,
et revient à l'état authentifié depuis l'état sélectionné. Aucune réponse
EXPUNGE non étiquetée n'est envoyée.
Aucun message n'est supprimé, et aucune erreur n'est donnée, si la boîte aux
lettres est sélectionnée par une commande EXAMINE ou est autrement sélectionnée
en lecture seule.
Même si une boîte aux lettres est sélectionnée, une commande SELECT, EXAMINE ou
LOGOUT PEUT (MAY) être émise sans avoir préalablement émis une commande CLOSE.
Les commandes SELECT, EXAMINE et LOGOUT ferment implicitement la boîte aux
lettres actuellement sélectionnée sans faire d'expurge. Toutefois, lorsque
beaucoup de messages sont supprimés, une séquence CLOSE-LOGOUT ou CLOSE-SELECT
est considérablement plus rapide qu'une séquence EXPUNGE-LOGOUT ou
EXPUNGE-SELECT car aucune réponse EXPUNGE non étiquetée (que le client
ignorerait probablement) n'est envoyée.
Exemple : C: A341 CLOSE S: A341 OK CLOSE completed
RFC 3501 IMAPv4 March 2003
6.4.3. Commande EXPUNGE
Arguments : aucun
Réponses : réponses non étiquetées : EXPUNGE
Résultat : OK - expurge terminé NO - échec d'expurge : impossible d'expurger (par exemple, permission refusée) BAD - commande inconnue ou arguments invalides
La commande EXPUNGE supprime de manière permanente tous les messages qui ont
l'indicateur \Deleted défini de la boîte aux lettres actuellement sélectionnée.
Avant de renvoyer un OK au client, une réponse EXPUNGE non étiquetée est envoyée
pour chaque message qui est supprimé.
Exemple : C: A202 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 5 EXPUNGE S: * 8 EXPUNGE S: A202 OK EXPUNGE completed
Note : dans cet exemple, les messages 3, 4, 7 et 11 avaient l'indicateur
\Deleted défini. Voir la description de la réponse EXPUNGE pour plus
d'explications.
6.4.4. Commande SEARCH
Arguments : spécification [CHARSET] FACULTATIVE critères de recherche (un ou plusieurs)
Réponses : réponse non étiquetée REQUISE : SEARCH
Résultat : OK - recherche terminée NO - erreur de recherche : impossible de rechercher ce [CHARSET] ou ces critères BAD - commande inconnue ou arguments invalides
La commande SEARCH recherche dans la boîte aux lettres les messages qui
correspondent aux critères de recherche donnés. Les critères de recherche
consistent en une ou plusieurs clés de recherche. La réponse SEARCH non
étiquetée du serveur contient une liste de numéros de séquence de message
correspondant à ceux des messages qui correspondent aux critères de recherche.
RFC 3501 IMAPv4 March 2003
Lorsque plusieurs clés sont spécifiées, le résultat est l'intersection (fonction
ET) de tous les messages qui correspondent à ces clés. Par exemple, les critères
DELETED FROM "SMITH" SINCE 1-Feb-1994 font référence à tous les messages
supprimés de Smith qui ont été placés dans la boîte aux lettres depuis le 1
février 1994. Une clé de recherche peut aussi être une liste entre parenthèses
d'une ou plusieurs clés de recherche (par exemple, pour utilisation avec les
clés OR et NOT).
Les implémentations serveur PEUVENT (MAY) exclure les parties de corps [MIME-IMB]
avec des types de média de contenu terminal autres que TEXT et MESSAGE de la
considération dans la correspondance SEARCH.
La spécification [CHARSET] FACULTATIVE consiste en le mot « CHARSET » suivi d'un
[CHARSET] enregistré. Elle indique le [CHARSET] des chaînes qui apparaissent
dans les critères de recherche. Les codages de transfert de contenu [MIME-IMB],
et les chaînes [MIME-HDRS] dans les en-têtes [RFC-2822]/[MIME-IMB], DOIVENT
(MUST) être décodés avant de comparer le texte dans un [CHARSET] autre que
US-ASCII. US-ASCII DOIT (MUST) être pris en charge ; d'autres [CHARSET] PEUVENT
(MAY) être pris en charge.
Si le serveur ne prend pas en charge le [CHARSET] spécifié, il DOIT (MUST)
renvoyer une réponse NO étiquetée (et non BAD). Cette réponse DEVRAIT (SHOULD)
contenir le code de réponse BADCHARSET, qui PEUT (MAY) lister les [CHARSET]
pris en charge par le serveur.
Dans toutes les clés de recherche qui utilisent des chaînes, un message
correspond à la clé si la chaîne est une sous-chaîne du champ. La correspondance
ne distingue pas la casse.
Les clés de recherche définies sont les suivantes. Reportez-vous à la section
Syntaxe formelle pour les définitions syntaxiques précises des arguments.
`<ensemble de séquences>`
Messages avec des numéros de séquence de message correspondant à l'ensemble
de numéros de séquence de message spécifié.
ALL
Tous les messages dans la boîte aux lettres ; la clé initiale par défaut pour
l'opération ET.
ANSWERED
Messages avec l'indicateur \Answered défini.
RFC 3501 IMAPv4 March 2003
BCC `<chaîne>`
Messages qui contiennent la chaîne spécifiée dans le champ BCC de la
structure d'enveloppe.
BEFORE `<date>`
Messages dont la date interne (sans tenir compte de l'heure et du fuseau
horaire) est antérieure à la date spécifiée.
BODY `<chaîne>`
Messages qui contiennent la chaîne spécifiée dans le corps du message.
CC `<chaîne>`
Messages qui contiennent la chaîne spécifiée dans le champ CC de la
structure d'enveloppe.
DELETED
Messages avec l'indicateur \Deleted défini.
DRAFT
Messages avec l'indicateur \Draft défini.
FLAGGED
Messages avec l'indicateur \Flagged défini.
FROM `<chaîne>`
Messages qui contiennent la chaîne spécifiée dans le champ FROM de la
structure d'enveloppe.
HEADER `<nom de champ>` `<chaîne>`
Messages qui ont un en-tête avec le nom de champ spécifié (tel que défini
dans [RFC-2822]) et qui contient la chaîne spécifiée dans le texte de
l'en-tête (ce qui vient après les deux-points). Si la chaîne à rechercher est
de longueur nulle, cela correspond à tous les messages qui ont une ligne
d'en-tête avec le nom de champ spécifié indépendamment du contenu.
KEYWORD `<indicateur>`
Messages avec l'indicateur mot-clé spécifié défini.
LARGER `<n>`
Messages avec une taille [RFC-2822] supérieure au nombre d'octets spécifié.
NEW
Messages qui ont l'indicateur \Recent défini mais pas l'indicateur \Seen.
Cela est fonctionnellement équivalent à « (RECENT UNSEEN) ».
RFC 3501 IMAPv4 March 2003
NOT `<clé de recherche>`
Messages qui ne correspondent pas à la clé de recherche spécifiée.
OLD
Messages qui n'ont pas l'indicateur \Recent défini. Cela est
fonctionnellement équivalent à « NOT RECENT » (par opposition à « NOT NEW »).
ON `<date>`
Messages dont la date interne (sans tenir compte de l'heure et du fuseau
horaire) est dans la date spécifiée.
OR `<clé1>` `<clé2>`
Messages qui correspondent à l'une ou l'autre clé de recherche.
RECENT
Messages qui ont l'indicateur \Recent défini.
SEEN
Messages qui ont l'indicateur \Seen défini.
SENTBEFORE `<date>`
Messages dont l'en-tête [RFC-2822] Date: (sans tenir compte de l'heure et du
fuseau horaire) est antérieur à la date spécifiée.
SENTON `<date>`
Messages dont l'en-tête [RFC-2822] Date: (sans tenir compte de l'heure et du
fuseau horaire) est dans la date spécifiée.
SENTSINCE `<date>`
Messages dont l'en-tête [RFC-2822] Date: (sans tenir compte de l'heure et du
fuseau horaire) est dans ou postérieur à la date spécifiée.
SINCE `<date>`
Messages dont la date interne (sans tenir compte de l'heure et du fuseau
horaire) est dans ou postérieur à la date spécifiée.
SMALLER `<n>`
Messages avec une taille [RFC-2822] inférieure au nombre d'octets spécifié.
RFC 3501 IMAPv4 March 2003
SUBJECT `<chaîne>`
Messages qui contiennent la chaîne spécifiée dans le champ SUBJECT de la
structure d'enveloppe.
TEXT `<chaîne>`
Messages qui contiennent la chaîne spécifiée dans l'en-tête ou le corps du
message.
TO `<chaîne>`
Messages qui contiennent la chaîne spécifiée dans le champ TO de la
structure d'enveloppe.
UID `<ensemble de séquences>`
Messages avec des identifiants uniques correspondant à l'ensemble
d'identifiants uniques spécifié. Des plages d'ensembles de séquences sont
permises.
UNANSWERED
Messages qui n'ont pas l'indicateur \Answered défini.
UNDELETED
Messages qui n'ont pas l'indicateur \Deleted défini.
UNDRAFT
Messages qui n'ont pas l'indicateur \Draft défini.
UNFLAGGED
Messages qui n'ont pas l'indicateur \Flagged défini.
UNKEYWORD `<indicateur>`
Messages qui n'ont pas l'indicateur mot-clé spécifié défini.
UNSEEN
Messages qui n'ont pas l'indicateur \Seen défini.
RFC 3501 IMAPv4 March 2003
Exemple : C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" S: * SEARCH 2 84 882 S: A282 OK SEARCH completed C: A283 SEARCH TEXT "string not in mailbox" S: * SEARCH S: A283 OK SEARCH completed C: A284 SEARCH CHARSET UTF-8 TEXT \{6\} C: XXXXXX S: * SEARCH 43 S: A284 OK SEARCH completed
Note : puisque ce document est limité au texte ASCII 7 bits, il n'est pas
possible d'afficher de données UTF-8 réelles. Le « XXXXXX » est un
substitut de ce qui seraient 6 octets de données 8 bits dans une transaction
réelle.
6.4.5. Commande FETCH
Arguments : ensemble de séquences noms d'éléments de données de message ou macro
Réponses : réponses non étiquetées : FETCH
Résultat : OK - récupération terminée NO - erreur de récupération : impossible de récupérer ces données BAD - commande inconnue ou arguments invalides
La commande FETCH récupère les données associées à un message dans la boîte
aux lettres. Les éléments de données à récupérer peuvent être soit un atome
unique, soit une liste entre parenthèses.
La plupart des éléments de données, identifiés dans la syntaxe formelle sous la
règle msg-att-static, sont statiques et NE DOIVENT PAS (MUST NOT) changer pour
un message particulier. D'autres éléments de données, identifiés dans la syntaxe
formelle sous la règle msg-att-dynamic, PEUVENT (MAY) changer, soit à la suite
d'une commande STORE, soit en raison d'événements externes.
Par exemple, si un client reçoit une ENVELOPE pour un message dont il
connaît déjà l'enveloppe, il peut ignorer en toute sécurité l'enveloppe
nouvellement transmise.
Il y a trois macros qui spécifient des ensembles couramment utilisés d'éléments
de données, et peuvent être utilisées à la place d'éléments de données. Une
macro doit être utilisée seule, et non conjointement avec d'autres macros ou
éléments de données.
RFC 3501 IMAPv4 March 2003
ALL
Macro équivalente à : (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
FAST
Macro équivalente à : (FLAGS INTERNALDATE RFC822.SIZE)
FULL
Macro équivalente à : (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
Les éléments de données actuellement définis qui peuvent être récupérés sont :
BODY
Forme non extensible de BODYSTRUCTURE.
BODY[`<section>`]`<\\<partiel>`>
Le texte d'une section de corps particulière. La spécification de section est
un ensemble de zéro ou plusieurs spécificateurs de partie délimités par des
points. Un spécificateur de partie est soit un numéro de partie, soit l'un
des suivants : HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME et TEXT. Une
spécification de section vide fait référence au message entier, y compris
l'en-tête.
Chaque message a au moins un numéro de partie. Les messages non [MIME-IMB],
et les messages non multipartie [MIME-IMB] sans message encapsulé, n'ont
qu'une partie 1.
Les messages multiparties se voient attribuer des numéros de partie
consécutifs, tels qu'ils apparaissent dans le message. Si une partie
particulière est de type message ou multipartie, ses parties DOIVENT (MUST)
être indiquées par un point suivi du numéro de partie dans cette partie
multipartie imbriquée.
Une partie de type MESSAGE/RFC822 a aussi des numéros de partie imbriqués,
faisant référence aux parties du corps de la partie MESSAGE.
Les spécificateurs de partie HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT et TEXT
peuvent être le seul spécificateur de partie ou peuvent être préfixés par un
ou plusieurs spécificateurs de partie numériques, à condition que le
spécificateur de partie numérique fasse référence à une partie de type
MESSAGE/RFC822. Le spécificateur de partie MIME DOIT (MUST) être préfixé par
un ou plusieurs spécificateurs de partie numériques.
Les spécificateurs de partie HEADER, HEADER.FIELDS et HEADER.FIELDS.NOT
font référence à l'en-tête [RFC-2822] du message ou d'un message encapsulé
[MIME-IMT] MESSAGE/RFC822. HEADER.FIELDS et HEADER.FIELDS.NOT sont suivis
d'une liste de noms de nom de champ (tels que définis dans [RFC-2822]), et
renvoient un sous-ensemble de l'en-tête. Le sous-ensemble renvoyé par
HEADER.FIELDS ne contient que les champs d'en-tête dont le nom de champ
correspond à l'un des noms de la liste. Le sous-ensemble renvoyé par
HEADER.FIELDS.NOT contient tous les champs d'en-tête sauf ceux dont le nom de
champ correspond à l'un des noms de la liste. Le sous-ensemble renvoyé par
HEADER.FIELDS et HEADER.FIELDS.NOT comprend la ligne vide de séparation
[RFC-2822] entre l'en-tête et le corps.
BODY.PEEK[`<section>`]`<\\<partiel>`>
Équivalent à BODY[`<section>`]`<\\<partiel>`>, mais sans implicitement
définir l'indicateur \Seen pour le message.
BODYSTRUCTURE
Liste entre parenthèses décrivant la structure de corps [MIME-IMB] d'un
message. Cela est calculé par le serveur en analysant les champs d'en-tête
[MIME-IMB], en utilisant des valeurs par défaut pour divers champs si
nécessaire.
ENVELOPE
Liste entre parenthèses décrivant la structure d'enveloppe du message. Voir
la section 2.3.4 pour la discussion de l'enveloppe.
FLAGS
Liste entre parenthèses des indicateurs définis sur le message. Voir la
section 2.3.2 pour la liste des indicateurs.
INTERNALDATE
Chaîne représentant la date interne du message.
RFC822
Équivalent à BODY[].
RFC822.HEADER
Équivalent à BODY[HEADER]. Notez que l'indicateur \Seen n'est pas défini, car
la réponse RFC822.HEADER résulte d'une récupération RFC822.HEADER. La réponse
BODY[HEADER] résulte d'une récupération BODY[HEADER] (qui définit \Seen) ou
BODY.PEEK[HEADER] (qui ne le définit pas).
RFC822.SIZE
Nombre représentant la taille du message en octets.
RFC822.TEXT
Équivalent à BODY[TEXT].
UID
Nombre représentant l'identifiant unique du message.
Exemple : C: A654 FETCH 2:4 FLAGS S: * 2 FETCH (FLAGS (\Seen \Deleted)) S: * 3 FETCH (FLAGS (\Seen)) S: * 4 FETCH (FLAGS (\Seen)) S: A654 OK FETCH completed
6.4.6. Commande STORE
Arguments : ensemble de messages élément de données de commande store
Résultat : aucune réponse spécifique
La commande STORE modifie les indicateurs associés à un message dans la boîte aux lettres sélectionnée. L'ensemble de messages détermine les messages auxquels la commande s'applique. L'élément de données de commande store détermine les indicateurs à modifier :
FLAGS Remplace les indicateurs du message par l'ensemble d'indicateurs donné.
FLAGS.SILENT Remplace les indicateurs du message par l'ensemble d'indicateurs donné, sans renvoyer de réponse de récupération FETCH non étiquetée.
+FLAGS Ajoute les indicateurs au jeu d'indicateurs du message.
+FLAGS.SILENT Ajoute les indicateurs au jeu d'indicateurs du message, sans renvoyer de réponse de récupération FETCH non étiquetée.
-FLAGS Supprime les indicateurs du jeu d'indicateurs du message.
-FLAGS.SILENT Supprime les indicateurs du jeu d'indicateurs du message, sans renvoyer de réponse de récupération FETCH non étiquetée.
La commande STORE renvoie une réponse de récupération FETCH (non étiquetée) pour chaque message modifié. La réponse FETCH contient les indicateurs du message après la modification.
Exemple : C: A003 STORE 2:4 +FLAGS (\Deleted) S: * 2 FETCH (FLAGS (\Seen \Deleted)) S: * 3 FETCH (FLAGS (\Deleted)) S: * 4 FETCH (FLAGS (\Seen \Deleted)) S: A003 OK STORE completed
6.4.7. Commande COPY
Arguments : ensemble de messages boîte aux lettres
Résultat : aucune réponse spécifique
La commande COPY copie le texte du message spécifié (et ses données d'en-tête [RFC-2822]) à la fin de la boîte aux lettres de destination indiquée. La destination est interprétée comme indiqué dans la section 5.1.
Si la destination nommée n'existe pas, le serveur renvoie une réponse NO.
Si le message copié fait partie d'une transaction, le message copié DOIT (MUST) avoir l'indicateur \Recent défini. Son numéro de séquence de message est son propre numéro dans la boîte aux lettres de destination. Sa copie ne modifie pas les numéros de séquence de message existants des autres messages dans la boîte aux lettres de destination.
Exemple : C: A002 COPY 2:4 MEETING S: A002 OK COPY completed
6.4.8. Commande UID
Arguments : commande (COPY, FETCH, SEARCH, STORE)
Résultat : aucune réponse spécifique
La commande UID permet au client d'utiliser un identifiant unique au lieu d'un numéro de séquence de message dans les commandes COPY, FETCH, SEARCH et STORE. Les identifiants uniques sont des nombres (voir la section 2.3.1.1). Les commandes UID fonctionnent de la même manière que leurs homologues non UID, sauf que les numéros de séquence de message sont remplacés par des identifiants uniques.
Pour les commandes UID FETCH et UID STORE, le serveur renvoie des réponses FETCH (non étiquetées) avec des numéros de séquence de message ; les réponses FETCH contiennent aussi un élément de données UID. Pour la commande UID COPY, le serveur renvoie une réponse OK contenant un code de réponse COPYUID (voir la section 2.3.1.1). Pour la commande UID SEARCH, le serveur renvoie une liste d'identifiants uniques au lieu de numéros de séquence de message.
Exemple : C: A001 UID FETCH 500:600 FLAGS S: * 3 FETCH (FLAGS (\Seen) UID 550) S: * 5 FETCH (FLAGS (\Seen) UID 552) S: * 7 FETCH (FLAGS (\Seen) UID 571) S: A001 OK UID FETCH completed
6.5. Commandes X
Les commandes commençant par « X » ne sont pas standardisées et sont réservées aux expérimentations locales. Certaines implémentations de serveur peuvent offrir des commandes X non documentées publiquement. Un client NE DOIT PAS (MUST NOT) envoyer de commande X sauf si l'utilisateur a explicitement demandé ou autorisé l'utilisation d'une telle commande.