2. Aperçu du protocole (Protocol Overview)
2.1. Niveau de liaison (Link Level)
Le protocole IMAP4rev1 suppose un flux de données fiable tel que celui fourni par TCP. Lorsque TCP est utilisé, un serveur IMAP4rev1 écoute sur le port 143.
2.2. Commandes et réponses (Commands and Responses)
Une connexion IMAP4rev1 consiste en l'établissement d'une connexion réseau client/serveur, un message d'accueil initial du serveur et des interactions client/serveur. Ces interactions client/serveur consistent en une commande client, des données serveur et une réponse de résultat de complétion de commande serveur.
Toutes les interactions transmises par le client et le serveur sont sous forme de lignes, c'est-à-dire des chaînes se terminant par un CRLF. Le récepteur de protocole d'un client ou serveur IMAP4rev1 lit soit une ligne, soit une séquence d'octets avec un comptage connu suivi d'une ligne.
2.2.1. Émetteur de protocole client et récepteur de protocole serveur (Client Protocol Sender and Server Protocol Receiver)
La commande client commence une opération. Chaque commande client est préfixée par un identifiant (généralement une courte chaîne alphanumérique, par exemple A0001, A0002, etc.) appelé un « tag ». Un tag différent est généré par le client pour chaque commande.
Les clients doivent (MUST) suivre strictement la syntaxe décrite dans cette spécification. C'est une erreur de syntaxe d'envoyer une commande avec des espaces ou des arguments manquants ou superflus.
Il existe deux cas où une ligne du client ne représente pas une commande complète. Dans un cas, un argument de commande est cité avec un comptage d'octets (voir la description du littéral dans Chaîne sous Formats de données) ; dans l'autre cas, les arguments de commande nécessitent un retour du serveur (voir la commande AUTHENTICATE). Dans les deux cas, le serveur envoie une réponse de demande de continuation de commande s'il est prêt pour les octets (le cas échéant) et le reste de la commande. Cette réponse est préfixée par le jeton « + ».
Note : Si au contraire, le serveur détecte une erreur dans la commande, il envoie une réponse de complétion BAD avec un tag correspondant à la commande (comme décrit ci-dessous) pour rejeter la commande et empêcher le client d'envoyer davantage de commande.
Il est également possible que le serveur envoie une réponse de complétion pour une autre commande (si plusieurs commandes sont en cours), ou des données non taguées. Dans les deux cas, la demande de continuation de commande est toujours en attente ; le client prend l'action appropriée pour la réponse et lit une autre réponse du serveur. Dans tous les cas, le client doit (MUST) envoyer une commande complète (y compris la réception de toutes les réponses de demande de continuation de commande et les continuations de commande pour la commande) avant d'initier une nouvelle commande.
Le récepteur de protocole d'un serveur IMAP4rev1 lit une ligne de commande du client, analyse la commande et ses arguments, et transmet les données serveur et une réponse de résultat de complétion de commande serveur.
2.2.2. Émetteur de protocole serveur et récepteur de protocole client (Server Protocol Sender and Client Protocol Receiver)
Les données transmises par le serveur au client et les réponses d'état qui n'indiquent pas la complétion de commande sont préfixées par le jeton « * », et sont appelées réponses non taguées (untagged responses).
Les données serveur peuvent (MAY) être envoyées en résultat d'une commande client, ou peuvent (MAY) être envoyées unilatéralement par le serveur. Il n'y a pas de différence syntaxique entre les données serveur qui résultent d'une commande spécifique et les données serveur qui ont été envoyées unilatéralement.
La réponse de résultat de complétion serveur indique le succès ou l'échec de l'opération. Elle est taguée avec le même tag que la commande client qui a commencé l'opération. Ainsi, si plus d'une commande est en cours, le tag dans une réponse de complétion serveur identifie la commande à laquelle la réponse s'applique. Il existe trois réponses de complétion serveur possibles : OK (indiquant le succès), NO (indiquant l'échec), ou BAD (indiquant une erreur de protocole telle qu'une commande non reconnue ou une erreur de syntaxe de commande).
Les serveurs devraient (SHOULD) imposer strictement la syntaxe décrite dans cette spécification. Toute commande client avec une erreur de syntaxe de protocole, y compris (mais sans s'y limiter) des espaces ou des arguments manquants ou superflus, devrait (SHOULD) être rejetée avec une réponse de complétion BAD.
2.3. Attributs de message (Message Attributes)
En plus des attributs de message (Message Attributes), IMAP prend en charge plusieurs éléments de données définis par le serveur. Ces éléments de données serveur peuvent varier selon l'implémentation du serveur et sont extensibles.
2.3.1. Numéros de message (Message Numbers)
Les messages sont identifiés soit par un numéro de séquence de message (Message Sequence Number), soit par un identifiant unique (Unique Identifier, UID).
2.3.1.1. Attribut de message identifiant unique (UID) (Unique Identifier (UID) Message Attribute)
L'identifiant unique (Unique Identifier, UID) est une valeur de 32 bits associée à un message dans une boîte aux lettres. Cet identifiant unique doit (MUST) être unique dans la boîte aux lettres au fil du temps. Les UID ne changent pas lorsque les messages sont supprimés.
Les UID doivent (MUST) être strictement croissants.
Chaque fois qu'un message est ajouté à la boîte aux lettres, on lui attribue un UID plus grand que tout UID précédemment utilisé, même si les UID précédents ne sont plus utilisés (c'est-à-dire si les messages ont été supprimés).
L'exigence d'unicité des UID nécessite que le serveur maintienne un enregistrement de chaque UID précédemment utilisé et ne le réutilise pas. La façon la plus simple de garantir l'unicité des UID est simplement d'attribuer des UID de manière monotone, c'est-à-dire d'attribuer à chaque nouveau message qui arrive un UID supérieur d'un à celui du message précédent.
2.3.1.2. Attribut de message numéro de séquence de message (Message Sequence Number Message Attribute)
Le numéro de séquence de message (Message Sequence Number) est la position relative d'un message dans la boîte aux lettres. Les numéros de séquence de message sont des entiers consécutifs allant de 1 au nombre total de messages dans la boîte aux lettres.
Les numéros de séquence de message peuvent changer lorsque le contenu de la boîte aux lettres change. En particulier, lorsque des messages sont supprimés ou ajoutés, tous les numéros de séquence de message après le numéro de séquence de message affecté changent.
Les numéros de séquence de message ne sont valides que pendant la session. Lorsque la session se termine, les numéros de séquence de message perdent leur signification.
2.3.2. Attribut de message drapeaux (Flags Message Attribute)
Les drapeaux (Flags) sont des mots-clés ou des jetons associés à un message. Il existe deux types de drapeaux : les drapeaux système et les mots-clés.
Les drapeaux système sont des drapeaux avec une signification spéciale qui commencent par le caractère barre oblique inverse (« \ »). Les drapeaux système sont :
\Seen- Le message a été lu\Answered- Une réponse au message a été envoyée\Flagged- Le message est marqué\Deleted- Le message est marqué pour suppression\Draft- Le message est un brouillon\Recent- Le message est récemment arrivé (cette session)
Les mots-clés sont des drapeaux définis par le serveur ou le client. Les mots-clés ne doivent pas (MUST NOT) commencer par une barre oblique inverse.
2.3.3. Attribut de message date interne (Internal Date Message Attribute)
La date interne (Internal Date) est la date et l'heure auxquelles le message est arrivé dans la boîte aux lettres. Cela peut être différent du champ d'en-tête Date: du message.
2.3.4. Attribut de message taille [RFC-2822] ([RFC-2822] Size Message Attribute)
La taille [RFC-2822] est la taille du message en octets.
2.3.5. Attribut de message structure d'enveloppe (Envelope Structure Message Attribute)
La structure d'enveloppe (Envelope Structure) est l'information dérivée de l'en-tête du message.
2.3.6. Attribut de message structure de corps (Body Structure Message Attribute)
La structure de corps (Body Structure) est l'information sur la structure MIME du message.
2.4. Textes de message (Message Texts)
Les textes de message (Message Texts) comprennent l'en-tête complet et le corps du message. Les textes de message doivent (MUST) être au format [RFC-2822].