7. Réponses du serveur
Les données associées à un message sont dont le contenu du message (c'est-à-dire le corps du message et divers en-têtes de message), certains des drapeaux de système et d'utilisateur associés au message, et l'« enveloppe » du message.
Une « enveloppe » du message contient la date, l'objet et les informations d'adressage du message. La notion d'enveloppe est décrite dans l'appendice de syntaxe formelle de ce document (section 9). L'enveloppe est calculée par le serveur en analysant les en-têtes [RFC-2822] du message en ses constituants.
Bien que le serveur calcule l'enveloppe à partir des en-têtes [RFC-2822] du message, les informations d'adressage de l'enveloppe peuvent différer des informations d'enveloppe [SMTP] inscrites dans le message. Par exemple, un message peut être acheminé via plusieurs serveurs de messagerie et avoir plusieurs lignes Received, mais n'a pas d'en-tête [RFC-2822] indiquant les informations d'origine [SMTP].
L'enveloppe consiste en :
date Une chaîne représentant la date et l'heure à laquelle le message a été envoyé.
subject Une chaîne représentant l'objet du message.
from Une liste d'adresses (voir ci-dessous) représentant l'expéditeur du message.
sender Une liste d'adresses représentant le véritable envoyeur du message, s'il diffère de l'expéditeur.
reply-to Une liste d'adresses indiquant où les réponses doivent être envoyées.
to Une liste d'adresses représentant les destinataires principaux du message.
cc Une liste d'adresses représentant les autres destinataires du message.
bcc Une liste d'adresses représentant les destinataires qui ont reçu le message aveuglément (c'est-à-dire, la liste des destinataires qui ne sont pas visibles pour les autres destinataires).
in-reply-to Une chaîne contenant l'en-tête In-Reply-To du message.
message-id Une chaîne contenant l'en-tête Message-ID du message.
Une adresse consiste en :
personal name Une chaîne représentant le nom de la personne.
RFC 3501 IMAPv4 March 2003
[SMTP] at-domain-list (source route) Une liste de domaines à la source indiquant le chemin de routage depuis l'expéditeur. Cette liste est généralement vide.
mailbox name Une chaîne représentant la partie locale de l'adresse (avant le signe "@").
host name Une chaîne représentant le nom d'hôte du domaine (après le signe "@").
Les éléments de données suivants permettent d'accéder aux données associées à un message. Certains de ces éléments de données nécessitent des paramètres supplémentaires :
BODY Un en-tête de message peut être récupéré en utilisant BODY avec
un spécificateur de section [HEADER]. Un sous-ensemble d'en-têtes
peut être récupéré en utilisant BODY avec un spécificateur de
section [HEADER.FIELDS (<nom de champ>)] ou [HEADER.FIELDS.NOT
(<nom de champ>)].
Une chaîne est retournée comme élément de données de réponse
(c'est-à-dire un littéral suivi d'un CRLF). Par exemple :
BODY[HEADER] renvoie l'en-tête de message entier, y compris les
lignes vides de séparation [RFC-2822].
Lorsqu'un spécificateur de section n'est pas présent (c'est-à-dire
BODY[]), l'ensemble du corps du message est récupéré.
Lorsqu'un spécificateur de section [TEXT] est présent, seul le
corps du message, sans les en-têtes [RFC-2822], est récupéré.
Les spécificateurs de section de la forme [section] peuvent être
utilisés pour récupérer des parties du corps d'un message MIME
[MIME-IMB] multipartie.
Les spécificateurs de section de la forme [section.part] peuvent
être utilisés pour récupérer des sous-parties de corps d'un
message MIME [MIME-IMB].
Sur un message ayant un type de corps MESSAGE, le propriétés du
sous-message peuvent être récupérées en utilisant un spécificateur
de section de la forme [section.MIME]. Les en-têtes du sous-message
peuvent être récupérés en utilisant un spécificateur de section de
la forme [section.HEADER]. Les sous-parties du sous-message peuvent
être récupérées en utilisant un spécificateur de section de la
forme [section.part].
La taille d'une réponse de récupération partiellen peut être
limitée en spécifiant une plage d'octets de la forme
[section]``<début fin>`` ou [section.part]``<début fin>``.
Le point de départ et le point de fin de la plage d'octets sont
comptés à partir de 0, où 0 est le premier octet du corps ou de la
partie de corps. La plage d'octets est inclusive. Par exemple,
BODY[]``<0.1024>`` du premier kilooctet du corps du message, et
BODY[]``<1024.2048>`` renvoie les octets 1024 à 2048 du corps du
message.
L'utilisation de la syntaxe BODY[...]``<début>`` est une erreur de
syntaxe, et le serveur DOIT (MUST) renvoyer une réponse BAD pour un
tel élément de données de récupération.
Le serveur DOIT (MUST) renvoyer un élément de données de
récupération BODY supplémentaire si nécessaire. S'il ne le fait
pas, le client DOIT (MUST) traiter les données comme tronquées.
Un client ne DOIT PAS (MUST NOT) demander la même partie de corps
plus d'une fois.
Un client ne DOIT PAS (MUST NOT) demander des tailles de réponse
partielles qui se chevauchent.
BODYSTRUCTURE Identique à BODY, mais sans récupérer le contenu du message. Cet élément de données renvoie des informations sur la structure MIME du message.
ENVELOPE Renvoie l'enveloppe du message.
FLAGS Renvoie les indicateurs (flags) définis pour le message. Voir la section 2.3.2 pour la liste des indicateurs.
INTERNALDATE Renvoie 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 Renvoie la taille du message en octets.
RFC822.TEXT Équivalent à BODY[TEXT].
UID Renvoie 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.5. Élément de données de commande de récupération
RFC 3501 IMAPv4 March 2003
Les éléments de données de récupération sont retournés comme des éléments de réponse FETCH. Les éléments de données de récupération décrits dans cette section sont utilisés comme arguments de la commande FETCH.
BODY[<section>]<\<octet d'origine>>
Une chaîne représentant le contenu de corps de la section
spécifiée. La chaîne DOIT (SHOULD) être interprétée par le client
conformément au codage de transfert de contenu, au type de corps et
au sous-type.
Si un octet d'origine est spécifié, cette chaîne est une sous-chaîne
du corps entier commençant à cet octet d'origine. Cela signifie que
BODY[]``<0>`` peut être tronqué, mais BODY[] ne l'est jamais.
Note : la fonctionnalité d'octet d'origine ne DOIT PAS (MUST NOT)
être utilisée par le serveur dans une réponse FETCH, sauf si le
client la demande explicitement par un élément de données de
récupération BODY[``<section>``]``<\<partiel>>``.
Les données texte 8 bits sont autorisées si l'identifiant
[CHARSET] fait partie de la liste de paramètres de corps de cette
section. Notez que les en-têtes (spécificateur de partie HEADER ou
MIME, ou la partie d'en-tête d'un message MESSAGE/RFC822) DOIVENT
(MUST) être en 7 bits. Les caractères 8 bits ne sont pas autorisés
dans les en-têtes. Notez également que la ligne vide de séparation
[RFC-2822] entre l'en-tête et le corps n'est pas affectée par la
sous-définition des lignes d'en-tête. La ligne vide est toujours
incluse dans les données d'en-tête, sauf dans le cas d'un message
sans corps ni ligne vide.
Les données non textuelles, telles que les données binaires,
DOIVENT (MUST) être codées en transfert sous forme de texte (tel que
BASE64) avant d'être envoyées au client. Pour dériver les données
binaires d'origine, le client DOIT (MUST) décoder la chaîne codée en
transfert.
BODYSTRUCTURE Une liste entre parenthèses décrivant la structure de corps [MIME-IMB]. Elle est calculée par le serveur en analysant les en-têtes [MIME-IMB] et en utilisant des valeurs par défaut pour divers champs si nécessaire.
Par exemple, un message texte simple de 48 lignes et 2279 octets
peut avoir une structure de corps telle que : ("TEXT" "PLAIN"
("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)
Les multiparties sont indiquées par l'imbrication de parenthèses.
Au lieu d'avoir un type de corps comme premier élément de la liste
entre parenthèses, il y a une séquence d'une ou plusieurs structures
de corps imbriquées. Le deuxième élément de la liste entre parenthèses
est le sous-type multipartie (mixed, digest, parallel, alternative,
etc.).
RFC 3501 IMAPv4 March 2003
Par exemple, un message à deux parties composé de texte et d'une
pièce jointe texte codée BASE64 peut avoir une structure de corps
telle que : (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT"
1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
"``<[email protected]>``" "Compiler diff"
"BASE64" 4554 73) "MIXED")
Les données d'extension suivent, après le sous-type multipartie.
Les données d'extension ne sont jamais renvoyées par une récupération
"BODY", mais peuvent l'être par une récupération "BODYSTRUCTURE". Si
des données d'extension sont présentes, elles DOIVENT (MUST) être
dans l'ordre défini. L'ordre des données d'extension pour une partie
de corps multipartie est :
body parameter parenthesized list
liste entre parenthèses de paires attribut/valeur [par ex.
("foo" "bar" "baz" "rag") où "bar" est la valeur de "foo", "rag"
est la valeur de "baz"] (défini dans [MIME-IMB]).
body disposition
liste entre parenthèses composée d'une chaîne de type de
disposition et, suivie, d'une liste entre parenthèses de paires
attribut/valeur de disposition telle que définie dans
[DISPOSITION].
body language
chaîne ou liste entre parenthèses donnant la valeur de langue de
corps telle que définie dans [LANGUAGE-TAGS].
body location
liste de chaînes donnant l'URI de contenu de corps telle que
définie dans [LOCATION].
Les données d'extension qui suivent ne sont pas encore définies dans
cette version du protocole. De telles données d'extension peuvent
consister en zéro ou plusieurs NIL, chaînes, nombres ou listes entre
parenthèses potentiellement imbriquées de telles données. Les
implémentations client effectuant une récupération BODYSTRUCTURE
DOIVENT (MUST) être prêtes à accepter de telles données d'extension.
Les implémentations serveur ne DOIVENT PAS (MUST NOT) générer de
telles données d'extension jusqu'à ce qu'elles soient définies par
une révision de ce protocole.
Les champs de base pour une partie de corps non multipartie sont dans
l'ordre suivant :
body type
chaîne donnant le nom de type de média de contenu tel que défini
dans [MIME-IMB].
RFC 3501 IMAPv4 March 2003
body subtype
chaîne donnant le nom de sous-type de contenu tel que défini dans
[MIME-IMB].
body parameter parenthesized list
liste entre parenthèses de paires attribut/valeur [par ex.
("foo" "bar" "baz" "rag") où "bar" est la valeur de "foo", "rag"
est la valeur de "baz"] (défini dans [MIME-IMB]).
body id
chaîne donnant l'id de contenu tel que défini dans [MIME-IMB].
body description
chaîne donnant la description de contenu telle que définie dans
[MIME-IMB].
body encoding
chaîne donnant le codage de transfert de contenu tel que défini
dans [MIME-IMB].
body size
nombre donnant la taille du corps en octets. Notez que cette
taille est celle du codage de transfert, et non le résultat
décodé.
Pour un type de corps MESSAGE dont le sous-type est RFC822, après
les champs de base, la structure d'enveloppe, la structure de corps et
la taille en lignes de texte du message encapsulé sont incluses.
Pour un type de corps TEXT, après les champs de base, la taille du
corps en nombre de lignes de texte est incluse.
Les données d'extension suivent les champs de base et les champs
spécifiques au type ci-dessus. Les données d'extension ne sont jamais
renvoyées par une récupération "BODY", mais peuvent l'être par une
récupération "BODYSTRUCTURE". Si des données d'extension sont
présentes, elles DOIVENT (MUST) être dans l'ordre défini. L'ordre des
données d'extension pour une partie de corps non multipartie est :
body MD5
chaîne donnant la valeur MD5 du corps telle que définie dans
[MD5].
RFC 3501 IMAPv4 March 2003
body disposition
liste entre parenthèses ayant le même contenu et la même fonction
que la disposition de corps multipartie.
body language
chaîne ou liste entre parenthèses donnant la valeur de langue de
corps telle que définie dans [LANGUAGE-TAGS].
body location
liste de chaînes donnant l'URI de contenu de corps telle que
définie dans [LOCATION].
Les données d'extension qui suivent ne sont pas encore définies dans
cette version du protocole, et sont comme décrit ci-dessus pour les
données d'extension multiparties.
ENVELOPE Liste entre parenthèses décrivant la structure d'enveloppe du message. Voir la discussion de l'enveloppe dans la section 2.3.4.
FLAGS Liste entre parenthèses des indicateurs définis sur le message.
INTERNALDATE Chaîne représentant la date interne du message.
RFC822 Équivalent à BODY[].
RFC822.HEADER Équivalent à BODY[HEADER]. Notez que \Seen n'est pas défini.
RFC822.SIZE Nombre représentant la taille du message.
RFC 3501 IMAPv4 March 2003
RFC822.TEXT Équivalent à BODY[TEXT].
UID Nombre représentant l'identifiant unique du message.
Exemple : S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
6.4.6. Commande STORE
Arguments : ensemble de messages élément de données d'commande store
Résultat : unaffected
La commande STORE modifie les indicateurs (flags) 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 d'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 : unaffected
La commande COPY copie le texte du message spécifié (et ses données d'en-tête [RFC-2822]) dans 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 : unaffected
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 également 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.
7. Réponses du serveur
Les réponses du serveur sont envoyées du serveur au client. Une réponse est soit :
(1) une réponse d'état (tagged ou untagged),
(2) une réponse de données du serveur (untagged), ou
(3) une demande de continuation de commande (indiquée par un "+" à la place d'un tag).
Les réponses d'état indiquent le résultat d'une commande précédente (par exemple, OK, NO ou BAD). Les réponses d'état étiquetées ont la même étiquette que la commande à laquelle elles répondent. Les réponses d'état non étiquetées indiquent un changement d'état du serveur ou de la boîte aux lettres.
Les réponses de données du serveur (non étiquetées) contiennent des données demandées ou non demandées qui ne sont pas le résultat direct d'une commande.
La demande de continuation de commande indique que le serveur est prêt à accepter la suite d'une commande.
Les réponses du serveur peuvent être envoyées à tout moment par le serveur, et le client DOIT (MUST) être prêt à les recevoir. Cela contraste avec les commandes, qui ne peuvent être envoyées que lorsque le client attend une réponse de commande.
Les codes de réponse suivants sont utilisés dans les réponses d'état. Ils sont placés entre crochets après le type de réponse (OK, NO ou BAD) :
ALERT Le texte qui suit contient un message d'alerte du système que le client DOIT (MUST) afficher à l'utilisateur.
BADCHARSET Le texte qui suit énumère les jeux de caractères valides pour la recherche. Un client DOIT (MUST) utiliser l'un de ces jeux de caractères dans une commande SEARCH.
CAPABILITY Le texte qui suit énumère les capacités du serveur.
PARSE Le texte qui suit décrit une erreur d'analyse du serveur sur un message envoyé par le client.
PERMANENTFLAGS Le texte qui suit énumère les indicateurs qui le serveur conservera de manière permanente.
READ-ONLY Le texte qui suit indique que la boîte aux lettres est en lecture seule.
READ-WRITE Le texte qui suit indique que la boîte aux lettres est en lecture et écriture.
TRYCREATE Le texte qui suit indique que la boîte aux lettres ne peut pas être sélectionnée et doit d'abord être créée avec la commande CREATE.
UIDNEXT Le texte qui suit donne la valeur UIDNEXT de la boîte aux lettres.
UIDVALIDITY Le texte qui suit donne la valeur UIDVALIDITY de la boîte aux lettres.
UNSEEN Le texte qui suit donne le numéro de séquence de message du premier message non lu de la boîte aux lettres.
7.1.1. Réponse OK
Contenu : code de réponse facultatif texte lisible par un humain
La réponse OK indique que la commande associée du client s'est terminée avec
succès. La réponse OK peut transporter des données supplémentaires du serveur
sous forme d'un code de réponse facultatif (voir ci-dessus). Le texte lisible
par un humain est destiné à l'information de l'utilisateur ou à la journalisation.
Exemple : S: * OK IMAP4rev1 server ready C: A001 LOGIN fred blurdybloop S: * OK [ALERT] System shutdown in 10 minutes S: A001 OK LOGIN Completed
7.1.2. Réponse NO
Contenu : code de réponse facultatif texte lisible par un humain
La réponse NO indique un message d'erreur opérationnelle du serveur.
Lorsqu'elle est étiquetée, elle indique l'échec de la commande associée.
La forme non étiquetée indique un avertissement ; la commande peut tout
de même se terminer avec succès. Le texte lisible par un humain décrit la
condition.
Exemple : C: A222 COPY 1:2 owatagusiam S: * NO Disk is 98% full, please delete unnecessary data S: A222 OK COPY completed C: A223 COPY 3:200 blurdybloop S: * NO Disk is 98% full, please delete unnecessary data S: * NO Disk is 99% full, please delete unnecessary data S: A223 NO COPY failed: disk is full
7.1.3. Réponse BAD
Contenu : code de réponse facultatif texte lisible par un humain
La réponse BAD indique un message d'erreur du serveur. Lorsqu'elle est
étiquetée, elle signale une erreur de niveau protocole dans la commande du
client ; l'étiquette indique la commande à l'origine de l'erreur. La forme
non étiquetée indique une erreur de niveau protocole pour laquelle la
commande associée ne peut être déterminée ; elle peut aussi indiquer une
défaillance interne du serveur. Le texte lisible par un humain décrit la
condition.
RFC 3501 IMAPv4 March 2003
Exemple : C: ...very long command line... S: * BAD Command line too long C: ...empty line... S: * BAD Empty command line C: A443 EXPUNGE S: * BAD Disk crash, attempting salvage to a new disk! S: * OK Salvage successful, no data lost S: A443 OK Expunge completed
7.1.4. Réponse PREAUTH
Contenu : code de réponse facultatif texte lisible par un humain
La réponse PREAUTH est toujours non étiquetée, et est l'une des trois
salutations possibles au démarrage de la connexion. Elle indique que la
connexion a déjà été authentifiée par des moyens externes ; ainsi, aucune
commande LOGIN n'est nécessaire.
Exemple : S: * PREAUTH IMAP4rev1 server logged in as Smith
7.1.5. Réponse BYE
Contenu : code de réponse facultatif texte lisible par un humain
La réponse BYE est toujours non étiquetée, et indique que le serveur est
sur le point de fermer la connexion. Le texte lisible par un humain PEUT
(MAY) être affiché à l'utilisateur dans un rapport d'état par le client.
La réponse BYE est envoyée dans l'un des quatre cas suivants :
1) dans le cadre d'une séquence de déconnexion normale. Le serveur
fermera la connexion après l'envoi de la réponse OK étiquetée à la
commande LOGOUT.
2) comme annonce d'arrêt en panique. Le serveur ferme la connexion
immédiatement.
3) comme annonce de déconnexion automatique pour inactivité. Le serveur
ferme la connexion immédiatement.
4) comme l'une des trois salutations possibles au démarrage de la
connexion, indiquant que le serveur n'est pas disposé à accepter une
connexion de ce client. Le serveur ferme la connexion immédiatement.
RFC 3501 IMAPv4 March 2003
La différence entre un BYE survenant dans le cadre d'une séquence LOGOUT
normale (le premier cas) et un BYE survenant en raison d'une défaillance
(les trois autres cas) est que la connexion se ferme immédiatement dans le
cas de défaillance. Dans tous les cas, le client DEVRAIT (SHOULD) continuer
à lire les données de réponse du serveur jusqu'à la fermeture de la
connexion ; cela garantira que toute réponse non étiquetée ou de fin en
attente soit lue et traitée.
Exemple : S: * BYE Autologout; idle for too long
7.2. Réponses du serveur - État du serveur et de la boîte aux lettres
Ces réponses sont toujours non étiquetées. C'est ainsi que les données d'état du serveur et de la boîte aux lettres sont transmises du serveur au client. Bon nombre de ces réponses résultent typiquement d'une commande portant le même nom.
7.2.1. Réponse CAPABILITY
Contenu : liste de capacités
La réponse CAPABILITY survient à la suite d'une commande CAPABILITY. La
liste de capacités contient une liste de noms de capacités séparés par des
espaces que le serveur prend en charge. La liste de capacités DOIT (MUST)
inclure l'atome "IMAP4rev1".
De plus, 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.
Un nom de capacité commençant par "AUTH=" indique que le serveur prend en
charge ce mécanisme d'authentification particulier.
La capacité LOGINDISABLED indique que la commande LOGIN est désactivée, et
que le serveur répondra par une réponse NO étiquetée à toute tentative
d'utiliser la commande LOGIN même si le nom d'utilisateur et le mot de
passe sont valides. Un client IMAP NE DOIT PAS (MUST NOT) émettre la
commande LOGIN si le serveur annonce la capacité LOGINDISABLED.
D'autres noms de capacités indiquent que le serveur prend en charge une
extension, une révision ou un amendement au protocole IMAP4rev1. Les
réponses du serveur DOIVENT (MUST) être conformes à ce document jusqu'à ce
que le client émette une commande utilisant la capacité associée.
Les noms de capacités DOIVENT (MUST) soit commencer par "X", soit être des
extensions, révisions ou amendements IMAP4rev1 standard ou de piste
standard enregistrés auprès de l'IANA. Un serveur NE DOIT PAS (MUST NOT)
offrir de noms de capacités non enregistrés ou non standard, à moins que de
tels noms ne soient préfixés par un "X".
RFC 3501 IMAPv4 March 2003
Les implémentations client NE DEVRAIENT PAS (SHOULD NOT) exiger de nom de
capacité autre que "IMAP4rev1", et DOIVENT (MUST) ignorer tout nom de
capacité inconnu.
Un serveur PEUT (MAY) envoyer des capacités automatiquement, en utilisant
le code de réponse CAPABILITY dans les réponses initiales PREAUTH ou OK, et
en envoyant un code de réponse CAPABILITY mis à jour dans la réponse OK
étiquetée dans le cadre d'une authentification réussie. Il est inutile pour
un client d'envoyer une commande CAPABILITY séparée s'il reconnaît ces
capacités automatiques.
Exemple : S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
7.2.2. Réponse LIST
Contenu : attributs de nom séparateur de hiérarchie nom
La réponse LIST survient à la suite d'une commande LIST. Elle renvoie un
seul nom correspondant à la spécification LIST. Il peut y avoir plusieurs
réponses LIST pour une seule commande LIST.
Quatre attributs de nom sont définis :
\Noinferiors
Il n'est pas possible qu'il existe des niveaux enfants de hiérarchie
sous ce nom ; aucun niveau enfant n'existe maintenant et aucun ne peut
être créé à l'avenir.
\Noselect
Il n'est pas possible d'utiliser ce nom comme boîte aux lettres
sélectionnable.
\Marked
La boîte aux lettres a été marquée « intéressante » par le serveur ; la
boîte aux lettres contient probablement des messages qui ont été ajoutés
depuis la dernière sélection de la boîte aux lettres.
\Unmarked
La boîte aux lettres ne contient aucun message supplémentaire depuis la
dernière sélection de la boîte aux lettres.
RFC 3501 IMAPv4 March 2003
Si le serveur ne peut pas déterminer si la boîte aux lettres est
« intéressante », ou si le nom est un nom \Noselect, le serveur NE DEVRAIT
PAS (SHOULD NOT) envoyer ni \Marked ni \Unmarked.
Le séparateur de hiérarchie est un caractère utilisé pour délimiter les
niveaux de hiérarchie dans un nom de boîte aux lettres. Un client peut
l'utiliser pour créer des boîtes aux lettres enfants, et pour rechercher des
niveaux supérieurs ou inférieurs de la hiérarchie de nommage. Tous les
enfants d'un nœud de hiérarchie de niveau supérieur DOIVENT (MUST) utiliser
le même caractère séparateur. Un séparateur de hiérarchie NIL signifie
qu'aucune hiérarchie n'existe ; le nom est un nom « plat ».
Le nom représente une hiérarchie non ambiguë de gauche à droite, et DOIT
(MUST) être valide pour une utilisation comme référence dans les commandes
LIST et LSUB. Sauf si \Noselect est indiqué, le nom DOIT (MUST) aussi être
valide comme argument pour les commandes, telles que SELECT, qui acceptent
des noms de boîtes aux lettres.
Exemple : S: * LIST (\Noselect) "/" ~/Mail/foo
7.2.3. Réponse LSUB
Contenu : attributs de nom séparateur de hiérarchie nom
La réponse LSUB survient à la suite d'une commande LSUB. Elle renvoie un
seul nom correspondant à la spécification LSUB. Il peut y avoir plusieurs
réponses LSUB pour une seule commande LSUB. Les données sont identiques en
format à la réponse LIST.
Exemple : S: * LSUB () "." #news.comp.mail.misc
7.2.4. Réponse STATUS
Contenu : nom liste d'état entre parenthèses
La réponse STATUS survient à la suite d'une commande STATUS. Elle renvoie
le nom de boîte aux lettres correspondant à la spécification STATUS et les
informations d'état de boîte aux lettres demandées.
Exemple : S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
RFC 3501 IMAPv4 March 2003
7.2.5. Réponse SEARCH
Contenu : zéro ou plusieurs nombres
La réponse SEARCH survient à la suite d'une commande SEARCH ou UID SEARCH.
Le(s) nombre(s) font référence aux messages correspondant aux critères de
recherche. Pour SEARCH, ce sont des numéros de séquence de message ; pour
UID SEARCH, ce sont des identifiants uniques. Chaque nombre est délimité
par un espace.
Exemple : S: * SEARCH 2 3 6
7.2.6. Réponse FLAGS
Contenu : liste d'indicateurs entre parenthèses
La réponse FLAGS survient à la suite d'une commande SELECT ou EXAMINE. La
liste d'indicateurs entre parenthèses identifie les indicateurs (au
minimum, les indicateurs définis par le système) applicables à cette boîte
aux lettres. Des indicateurs autres que les indicateurs système peuvent
également exister, selon l'implémentation du serveur.
La mise à jour issue de la réponse FLAGS DOIT (MUST) être enregistrée par le
client.
Exemple : S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
7.3. Réponses du serveur - Taille de la boîte aux lettres
Ces réponses sont toujours non étiquetées. C'est ainsi que les changements de taille de la boîte aux lettres sont transmis du serveur au client. Juste après le jeton "*" se trouve un nombre représentant un compte de messages.
7.3.1. Réponse EXISTS
Contenu : aucun
La réponse EXISTS indique le nombre de messages dans la boîte aux lettres.
Cette réponse survient à la suite d'une commande SELECT ou EXAMINE, et si la
taille de la boîte aux lettres change (par exemple, nouveaux messages).
La mise à jour issue de la réponse EXISTS DOIT (MUST) être enregistrée par
le client.
Exemple : S: * 23 EXISTS
RFC 3501 IMAPv4 March 2003
7.3.2. Réponse RECENT
Contenu : aucun
La réponse RECENT indique le nombre de messages avec l'indicateur \Recent
défini. Cette réponse survient à la suite d'une commande SELECT ou EXAMINE,
et si la taille de la boîte aux lettres change (par exemple, nouveaux
messages).
Note : il n'est pas garanti que les numéros de séquence de message des
messages récents forment une plage contiguë des n plus hauts messages
de la boîte aux lettres (où n est la valeur indiquée par la réponse
RECENT). Des exemples de situations où il en est ainsi : plusieurs
clients ayant la même boîte aux lettres ouverte (la première session
notifiée la verra comme récente, les autres la verront probablement
comme non récente), et lorsque la boîte aux lettres est réordonnée par
un agent non IMAP.
La seule façon fiable d'identifier les messages récents est de regarder
les indicateurs de message pour voir lesquels ont l'indicateur \Recent
défini, ou d'effectuer un SEARCH RECENT.
La mise à jour issue de la réponse RECENT DOIT (MUST) être enregistrée par
le client.
Exemple : S: * 5 RECENT
7.4. Réponses du serveur - État du message
Ces réponses sont toujours non étiquetées. C'est ainsi que les données de message sont transmises du serveur au client, souvent à la suite d'une commande portant le même nom. Juste après le jeton "*" se trouve un nombre représentant un numéro de séquence de message.
7.4.1. Réponse EXPUNGE
Contenu : aucun
La réponse EXPUNGE indique que le numéro de séquence de message spécifié a
été supprimé de manière permanente de la boîte aux lettres. Le numéro de
séquence de message de chaque message successif dans la boîte aux lettres est
immédiatement décrémenté de 1, et ce décrément est reflété dans les numéros
de séquence de message des réponses suivantes (y compris d'autres réponses
EXPUNGE non étiquetées).
RFC 3501 IMAPv4 March 2003
La réponse EXPUNGE décrémente également le nombre de messages dans la boîte
aux lettres ; il n'est pas nécessaire d'envoyer une réponse EXISTS avec la
nouvelle valeur.
En raison de la règle de décrément immédiat, les numéros de séquence de
message apparaissant dans un ensemble de réponses EXPUNGE successives
dépendent du fait que les messages sont supprimés en commençant par les
numéros les plus bas vers les plus hauts, ou des plus hauts vers les plus
bas. Par exemple, si les 5 derniers messages d'une boîte aux lettres de 9
messages sont purgés, un serveur « du bas vers le haut » enverra cinq
réponses EXPUNGE non étiquetées pour le numéro de séquence de message 5,
tandis qu'un serveur « du haut vers le bas » enverra des réponses EXPUNGE
non étiquetées successives pour les numéros de séquence de message 9, 8, 7,
6 et 5.
Une réponse EXPUNGE NE DOIT PAS (MUST NOT) être envoyée lorsqu'aucune
commande n'est en cours, ni lors de la réponse à une commande FETCH, STORE
ou SEARCH. Cette règle est nécessaire pour éviter une perte de
synchronisation des numéros de séquence de message entre le client et le
serveur. Une commande n'est « en cours » qu'une fois la commande complète
reçue ; en particulier, une commande n'est pas « en cours » pendant la
négociation de continuation de commande.
Note : UID FETCH, UID STORE et UID SEARCH sont des commandes
différentes de FETCH, STORE et SEARCH. Une réponse EXPUNGE PEUT (MAY)
être envoyée pendant une commande UID.
La mise à jour issue de la réponse EXPUNGE DOIT (MUST) être enregistrée par
le client.
Exemple : S: * 44 EXPUNGE
7.4.2. Réponse FETCH
Contenu : données de message
La réponse FETCH renvoie des données sur un message au client. Les données
sont des paires de noms d'éléments de données et de leurs valeurs entre
parenthèses. Cette réponse survient à la suite d'une commande FETCH ou
STORE, ainsi que par décision unilatérale du serveur (par exemple, mises à
jour d'indicateurs).
Les éléments de données actuels sont :
BODY
Une forme de BODYSTRUCTURE sans données d'extension.
RFC 3501 IMAPv4 March 2003
BODY[\<section>]\<\<octet d'origine>>
Une chaîne exprimant le contenu de corps de la section spécifiée. La
chaîne DOIT (SHOULD) être interprétée par le client conformément au
codage de transfert de contenu, au type de corps et au sous-type.
Si l'octet d'origine est spécifié, cette chaîne est une sous-chaîne de
l'ensemble du contenu du corps, commençant à cet octet d'origine. Cela
signifie que BODY[]\<0> PEUT (MAY) être tronqué, mais BODY[] n'est
JAMAIS tronqué.
Note : la fonctionnalité d'octet d'origine NE DOIT PAS (MUST NOT)
être utilisée par un serveur dans une réponse FETCH, sauf si le
client l'a explicitement demandée par une récupération d'un élément de
données BODY[\<section>]\<\<partiel>>.
Les données textuelles 8 bits sont autorisées si un identifiant [CHARSET]
fait partie de la liste de paramètres de corps entre parenthèses pour
cette section. Notez que les en-têtes (spécificateurs de partie HEADER ou
MIME, ou la partie d'en-tête d'un message MESSAGE/RFC822) DOIVENT (MUST)
être en 7 bits ; les caractères 8 bits ne sont pas autorisés dans les
en-têtes. Notez également que la ligne vide de délimitation [RFC-2822]
entre l'en-tête et le corps n'est pas affectée par le sous-ensemble des
lignes d'en-tête ; la ligne vide est toujours incluse dans les données
d'en-tête, sauf dans le cas d'un message n'ayant ni corps ni ligne vide.
Les données non textuelles telles que les données binaires DOIVENT (MUST)
être codées en transfert sous forme textuelle, telle que BASE64, avant
d'être envoyées au client. Pour dériver les données binaires d'origine,
le client DOIT (MUST) décoder la chaîne codée en transfert.
BODYSTRUCTURE
Une liste entre parenthèses décrivant la structure de corps [MIME-IMB]
d'un message. Elle est calculée 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.
Par exemple, un message texte simple de 48 lignes et 2279 octets peut
avoir une structure de corps de : ("TEXT" "PLAIN" ("CHARSET" "US-ASCII")
NIL NIL "7BIT" 2279 48)
Les parties multiples sont indiquées par l'imbrication de parenthèses.
Au lieu d'un type de corps comme premier élément de la liste entre
parenthèses, il y a une séquence d'une ou plusieurs structures de corps
imbriquées. Le deuxième élément de la liste entre parenthèses est le
sous-type multipartie (mixed, digest, parallel, alternative, etc.).
RFC 3501 IMAPv4 March 2003
Par exemple, un message à deux parties composé de texte et d'une pièce
jointe texte codée BASE64 peut avoir une structure de corps de :
(("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT"
"PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
"``<[email protected]>``" "Compiler diff" "BASE64" 4554
73) "MIXED")
Les données d'extension suivent le sous-type multipartie. Les données
d'extension ne sont jamais renvoyées avec la récupération BODY, mais
peuvent l'être avec une récupération BODYSTRUCTURE. Les données
d'extension, si présentes, DOIVENT (MUST) être dans l'ordre défini. Les
données d'extension d'une partie de corps multipartie sont dans l'ordre
suivant :
body parameter parenthesized list
Une liste entre parenthèses de paires attribut/valeur [par ex. ("foo"
"bar" "baz" "rag") où "bar" est la valeur de "foo", et "rag" est la
valeur de "baz"] telle que définie dans [MIME-IMB].
body disposition
Une liste entre parenthèses, composée d'une chaîne de type de
disposition, suivie d'une liste entre parenthèses de paires
attribut/valeur de disposition telle que définie dans [DISPOSITION].
body language
Une chaîne ou liste entre parenthèses donnant la valeur de langue de
corps telle que définie dans [LANGUAGE-TAGS].
body location
Une liste de chaînes donnant l'URI de contenu de corps telle que
définie dans [LOCATION].
Toutes les données d'extension suivantes ne sont pas encore définies dans
cette version du protocole. De telles données d'extension peuvent
consister en zéro ou plusieurs NIL, chaînes, nombres, ou listes entre
parenthèses potentiellement imbriquées de telles données. Les
implémentations client effectuant une récupération BODYSTRUCTURE DOIVENT
(MUST) être prêtes à accepter de telles données d'extension. Les
implémentations serveur NE DOIVENT PAS (MUST NOT) envoyer de telles
données d'extension tant qu'elles n'ont pas été définies par une révision
de ce protocole.
Les champs de base d'une partie de corps non multipartie sont dans
l'ordre suivant :
body type
Une chaîne donnant le nom de type de média de contenu tel que défini
dans [MIME-IMB].
RFC 3501 IMAPv4 March 2003
body subtype
Une chaîne donnant le nom de sous-type de contenu tel que défini dans
[MIME-IMB].
body parameter parenthesized list
Une liste entre parenthèses de paires attribut/valeur [par ex. ("foo"
"bar" "baz" "rag") où "bar" est la valeur de "foo", et "rag" est la
valeur de "baz"] telle que définie dans [MIME-IMB].
body id
Une chaîne donnant l'id de contenu tel que défini dans [MIME-IMB].
body description
Une chaîne donnant la description de contenu telle que définie dans
[MIME-IMB].
body encoding
Une chaîne donnant le codage de transfert de contenu tel que défini
dans [MIME-IMB].
body size
Un nombre donnant la taille du corps en octets. Notez que cette taille
est la taille dans son codage de transfert et non la taille résultante
après tout décodage.
Un type de corps de type MESSAGE et de sous-type RFC822 contient, juste
après les champs de base, la structure d'enveloppe, la structure de corps
et la taille en lignes de texte du message encapsulé.