2. Aperçu du protocole (Protocol Overview)

2.1 Niveau de liaison (Link Level)

Le protocole IMAP4rev2 suppose un flux de données fiable tel que celui fourni par TCP. Lorsque TCP est utilisé, un serveur IMAP4rev2 écoute sur le port 143 (port en texte clair) ou le port 993 (port TLS implicite).

2.2 Commandes et réponses (Commands and Responses)

Une connexion (Connection) IMAP4rev2 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 (Client Command), des données serveur (Server Data) et une réponse de résultat de completion du serveur (Server Completion Result Response).

Toutes les interactions transmises par le client et le serveur sont sous forme de lignes, c'est-à-dire des chaînes se terminant par CRLF. Le récepteur de protocole d'un client ou serveur IMAP4rev2 lit soit une ligne, soit une séquence d'octets avec un compte 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é "étiquette" (Tag). Une étiquette différente est générée par le client pour chaque commande. Plus formellement : le client devrait (SHOULD) générer une étiquette unique pour chaque commande, mais un serveur doit (MUST) accepter la réutilisation des étiquettes.

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 dans lesquels 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 (Literal) dans la section 4.3) ; dans l'autre cas, les arguments de commande nécessitent un retour du serveur (voir la commande AUTHENTICATE dans la section 6.2.2). Dans l'un ou l'autre cas, le serveur envoie une réponse de demande de continuation de commande (Command Continuation Request Response) 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 a détecté une erreur dans la commande, il envoie une réponse de completion BAD avec une étiquette correspondant à la commande (comme décrit ci-dessous) pour rejeter la commande et empêcher le client d'envoyer davantage de la commande.

Il est également possible que le serveur envoie une réponse de completion pour une autre commande (si plusieurs commandes sont en cours) ou des données non étiquetées (Untagged Data). 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 l'envoi de continuations de commande pour la commande) avant d'initier une nouvelle commande.

Le récepteur de protocole d'un serveur IMAP4rev2 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 completion 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 completion de la commande sont préfixées par le jeton "*" et sont appelées réponses non étiquetées (Untagged Responses).

Les données serveur peuvent (MAY) être envoyées en tant que 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 résultant d'une commande spécifique et les données serveur envoyées unilatéralement.

La réponse de résultat de completion du serveur indique le succès ou l'échec de l'opération. Elle est étiquetée avec la même étiquette que la commande client qui a commencé l'opération. Ainsi, si plusieurs commandes sont en cours, l'étiquette dans une réponse de completion du serveur identifie la commande à laquelle la réponse s'applique. Il existe trois réponses de completion du 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 réponses et données envoyées par le serveur au client ne doivent pas (MUST NOT) utiliser d'étiquettes de commande non décrites dans la syntaxe formelle (Formal Syntax).

La réponse de résultat de completion du serveur peut (MAY) contenir un code de réponse (Response Code) optionnel qui fournit des informations supplémentaires sur l'état de completion. Les codes de réponse consistent en des données entourées de crochets ([...]). Les clients qui ne comprennent pas un code de réponse particulier doivent (MUST) pouvoir accepter ce code de réponse sans effet négatif. Cela signifie que n'importe quel code de réponse peut être ajouté en toute sécurité à n'importe quelle réponse de completion sans causer de problèmes aux anciens clients.

Le récepteur de protocole d'un client IMAP4rev2 lit les réponses du serveur et les traite de manière appropriée.

---

2.3 Attributs de message (Message Attributes)

En plus des textes de message (Message Texts), plusieurs attributs (Attributes) sont associés à chaque message. Ces attributs peuvent être récupérés par numéro de séquence de message (Message Sequence Number) ou identifiant unique (Unique Identifier, UID).

2.3.1 Numéros de message (Message Numbers)

Les messages ont deux formes d'identification : le numéro de séquence de message et l'identifiant unique (UID).

2.3.1.1 Attribut de message identifiant unique (UID) (Unique Identifier (UID) Message Attribute)

Un identifiant unique (Unique Identifier, UID) est une valeur entière non signée non nulle de 32 bits associée à un message. Le but principal du UID est de fournir un identifiant pour le message qui persiste à travers plusieurs sessions (Sessions) IMAP. Le serveur doit (MUST) s'assurer qu'un UID unique est attribué à chaque message dans la boîte aux lettres.

Contrairement aux numéros de séquence de message, le UID d'un message augmente strictement (mais pas nécessairement de manière consécutive), même pendant la session. Le serveur doit (MUST) s'assurer que si un nouveau message est ajouté à la boîte aux lettres, le UID du nouveau message est supérieur au UID de tout message existant dans la boîte aux lettres.

Une exception à l'unicité et à l'augmentation stricte du UID est la valeur de validité UID (UIDVALIDITY Value). La valeur UIDVALIDITY est associée à la boîte aux lettres et est retournée avec la boîte aux lettres (par exemple, dans les réponses SELECT et EXAMINE). La valeur UIDVALIDITY est utilisée pour détecter si les UID dans la boîte aux lettres ont été réinitialisés.

La valeur UIDVALIDITY doit (MUST) être supérieure à zéro. Le but principal de la valeur UIDVALIDITY est de fournir une garantie dans les cas où la persistance du UID ne peut pas être maintenue. Par exemple, dans les cas suivants, le serveur doit (MUST) utiliser une valeur UIDVALIDITY différente dans les sessions futures :

1. Une boîte aux lettres doit (MUST) se voir attribuer une nouvelle valeur UIDVALIDITY si les messages correspondant aux UID existants ne sont plus valides dans la boîte aux lettres. Par exemple, si la boîte aux lettres est supprimée et recréée.

2. Pour plus de clarté : si une ancienne boîte aux lettres est supprimée et qu'une nouvelle boîte aux lettres avec le même nom est créée, la nouvelle boîte aux lettres doit (MUST) avoir une valeur UIDVALIDITY différente de l'ancienne boîte aux lettres.

3. Une boîte aux lettres ne doit pas (MUST NOT) être déplacée d'un serveur IMAP à un autre serveur IMAP sans changer sa valeur UIDVALIDITY, sauf si les deux serveurs IMAP fournissent un accès à un référentiel de boîtes aux lettres commun. Cas spécial : le serveur peut (MAY) réattribuer une boîte aux lettres à un utilisateur différent avec une valeur UIDVALIDITY différente tout en conservant le même nom.

4. La combinaison du nom de boîte aux lettres, UIDVALIDITY et UID doit (MUST) faire référence à un seul message immuable (ou supprimé) sur ce serveur pour toujours. En particulier, la date interne (Internal Date), RFC822.SIZE, l'enveloppe (Envelope), la structure du corps (Body Structure) et les textes de message (tous les éléments de données de récupération BODY[...]) ne doivent jamais (MUST) changer. Cela n'inclut pas les numéros de séquence de message, ni les attributs qui peuvent être définis par une commande STORE (tels que FLAGS). Lorsqu'un message est supprimé, son UID ne doit pas (MUST NOT) être réutilisé sous la même valeur UIDVALIDITY.

2.3.1.2 Attribut de message numéro de séquence de message (Message Sequence Number Message Attribute)

Un numéro de séquence de message (Message Sequence Number) est une position relative de 1 au nombre de messages dans la boîte aux lettres. Cette position doit (MUST) être ordonnée par identifiants uniques croissants. Lorsque chaque nouveau message est ajouté, il se voit attribuer un numéro de séquence de message qui est supérieur de 1 au nombre de messages dans la boîte aux lettres avant l'ajout de ce nouveau message.

Les numéros de séquence de message peuvent être réattribués pendant la session. Par exemple, lorsqu'un message est supprimé définitivement (expunged) de la boîte aux lettres, le numéro de séquence de message de tous les messages suivants est décrémenté. Le nombre de messages dans la boîte aux lettres est également décrémenté. De même, un nouveau message peut se voir attribuer un numéro de séquence de message qui était autrefois détenu par un autre message avant une suppression.

En plus d'accéder aux messages par position relative dans la boîte aux lettres, les numéros de séquence de message peuvent être utilisés dans des calculs mathématiques. Par exemple, si un "11 EXISTS" non étiqueté est reçu, et qu'un "8 EXISTS" non étiqueté a été reçu précédemment, trois nouveaux messages sont arrivés avec les numéros de séquence de message 9, 10 et 11. Comme autre exemple, si le message 287 dans une boîte aux lettres de 523 messages a le UID 12345, il y a exactement 286 messages qui ont des UID inférieurs et 236 messages qui ont des UID supérieurs.

2.3.2 Attribut de message drapeaux (Flags Message Attribute)

Un message a une liste de zéro ou plusieurs jetons nommés (Named Tokens), appelés "drapeaux" (Flags), qui lui sont associés. Un drapeau est défini par son ajout à cette liste et est effacé par sa suppression. Il existe deux types de drapeaux dans IMAP4rev2 : les drapeaux système (System Flags) et les mots-clés (Keywords). Un drapeau de l'un ou l'autre type peut être permanent ou uniquement pour la session.

Un drapeau système est un nom de drapeau prédéfini dans cette spécification et commençant par "". Certains drapeaux système (\Deleted et \Seen) ont une sémantique spéciale décrite ailleurs dans ce document. Les drapeaux système actuellement définis sont :

• \Seen - Le message a été lu
• \Answered - Le message a reçu une réponse
• \Flagged - Le message est "marqué" pour une attention urgente/spéciale
• \Deleted - Le message est "supprimé" pour suppression ultérieure par EXPUNGE
• \Draft - Le message n'a pas terminé la composition (marqué comme brouillon)
• \Recent - Ce drapeau était utilisé dans IMAP4rev1 et est maintenant déprécié

Un mot-clé (Keyword) est défini par l'implémentation du serveur. Les mots-clés ne commencent pas par "". Les serveurs peuvent (MAY) permettre au client de définir de nouveaux mots-clés dans la boîte aux lettres (voir la description du code de réponse PERMANENTFLAGS pour plus d'informations). Certains mots-clés commençant par "$" sont également définis dans cette spécification.

Ce document définit plusieurs mots-clés qui n'étaient pas définis à l'origine dans [RFC3501] mais qui ont été jugés utiles par les implémentations client. Ces mots-clés devraient (SHOULD) être pris en charge par les implémentations serveur (autorisés dans SEARCH et autorisés et conservés dans les commandes APPEND, COPY et MOVE) :

$Forwarded
Le message a été transféré à une autre adresse e-mail en étant intégré ou joint à un nouveau message. Un client de messagerie définit ce mot-clé lorsqu'il transfère avec succès le message à une autre adresse e-mail. L'utilisation typique de ce mot-clé est d'afficher une icône différente (ou supplémentaire) pour un message qui a été transféré. Une fois défini, le drapeau ne devrait pas (SHOULD NOT) être effacé.

$MDNSent
Une notification de disposition de message (Message Disposition Notification) [RFC8098] a été générée et envoyée pour ce message. Voir [RFC3503] pour plus de détails sur la façon dont ce mot-clé est utilisé et pour les exigences sur les clients et les serveurs.

$Junk
L'utilisateur (ou un agent de distribution au nom de l'utilisateur) peut choisir de marquer un message comme contenant définitivement du courrier indésirable ($Junk ; voir aussi le mot-clé associé $NotJunk). Le mot-clé $Junk peut être utilisé pour marquer, regrouper ou masquer les messages indésirables (et ces messages peuvent être déplacés ou supprimés ultérieurement). Voir [IMAP-KEYWORDS-REG] pour plus d'informations.

$NotJunk
L'utilisateur (ou un agent de distribution au nom de l'utilisateur) peut choisir de marquer un message comme ne contenant définitivement pas de courrier indésirable ($NotJunk ; voir aussi le mot-clé associé $Junk). Le mot-clé $NotJunk peut être utilisé pour marquer, regrouper ou afficher les messages que l'utilisateur souhaite voir. Voir [IMAP-KEYWORDS-REG] pour plus d'informations.

$Phishing
Le mot-clé $Phishing peut être utilisé par un agent de distribution pour marquer un message comme très probablement un e-mail de phishing. Un message déterminé comme étant un e-mail de phishing par l'agent de distribution devrait (SHOULD) également être considéré comme un courrier indésirable et avoir le filtrage de courrier indésirable approprié appliqué, y compris la définition du drapeau $Junk et le placement du message dans la boîte aux lettres à usage spécial \Junk (voir section 7.3.1, si disponible).

Si les drapeaux $Phishing et $Junk sont tous deux définis, l'agent utilisateur devrait (SHOULD) afficher un message d'avertissement supplémentaire à l'utilisateur. De plus, l'agent utilisateur peut afficher un avertissement lorsque l'utilisateur clique sur des hyperliens dans le message.

$Junk et $NotJunk sont mutuellement exclusifs. Si plusieurs de ces drapeaux sont définis pour un message, le client doit (MUST) le traiter comme si aucun n'était défini, et il devrait (SHOULD) désactiver les deux sur le serveur IMAP.

D'autres mots-clés enregistrés peuvent être trouvés dans le registre "IMAP and JMAP Keywords" [IMAP-KEYWORDS-REG]. Les nouveaux mots-clés devraient (SHOULD) être enregistrés dans ce registre en utilisant la procédure spécifiée dans [RFC5788].

Un drapeau peut être permanent ou uniquement pour la session sur une base par drapeau. Les drapeaux permanents (Permanent Flags) sont ceux que le client peut ajouter ou supprimer des drapeaux de message de manière permanente ; c'est-à-dire que les sessions simultanées et ultérieures verront tout changement dans les drapeaux permanents. Les modifications des drapeaux de session (Session Flags) ne sont valables que dans cette session.

2.3.3 Attribut de message date interne (Internal Date Message Attribute)

Un attribut de message date interne (Internal Date) est la date et l'heure internes du message sur le serveur. Ce n'est pas la date et l'heure dans l'en-tête [RFC5322] mais plutôt une date et une heure qui reflètent quand le message a été reçu. Dans le cas de messages livrés via [SMTP], c'est la date et l'heure de la livraison finale du message telle que définie par [SMTP]. Dans le cas de messages créés par les commandes IMAP4rev2 COPY ou APPEND, c'est la date et l'heure spécifiées par ces commandes.

2.3.4 Attribut de message RFC822.SIZE (RFC822.SIZE Message Attribute)

RFC822.SIZE est le nombre d'octets dans le message lorsque le message est exprimé au format [RFC5322]. Cette taille devrait (SHOULD) correspondre au résultat d'une commande "FETCH BODY[]". Si le message est stocké en interne dans un autre format, le serveur calcule la taille et la stocke souvent pour une utilisation ultérieure afin d'éviter le besoin de recalcul.

2.3.5 Attribut de message structure d'enveloppe (Envelope Structure Message Attribute)

Une structure d'enveloppe (Envelope Structure) est une représentation analysée de l'en-tête [RFC5322] du message. Notez que la structure d'enveloppe IMAP n'est pas la même qu'une enveloppe [SMTP].

2.3.6 Attribut de message structure de corps (Body Structure Message Attribute)

Une structure de corps (Body Structure) est une représentation analysée des informations de structure de corps [MIME-IMB] du message.

2.4 Textes de message (Message Texts)

En plus de pouvoir récupérer le texte [RFC5322] complet d'un message, IMAP4rev2 permet la récupération de portions du texte de message complet. Plus précisément, il est possible de récupérer l'en-tête de message [RFC5322] (Message Header), le corps de message [RFC5322] (Message Body), une partie de corps [MIME-IMB] (Body Part), ou un en-tête [MIME-IMB].

---