Aller au contenu principal

8. Exemple de connexion IMAP4rev1

Le type de corps TEXT comprend, juste après les champs de base, la taille du corps en nombre de lignes de texte. Notez que cette taille est celle du codage de transfert de contenu, et non le résultat décodé.

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 (fetch) "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 le suivant :

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 du corps telle que définie dans [LANGUAGE-TAGS].

body location Liste de chaînes donnant l'URI de contenu du corps telle que définie dans [LOCATION].

Les données d'extension qui suivent sont, dans cette version du protocole, non encore définies, et sont comme décrit ci-dessus pour les données d'extension multiparties.

ENVELOPE Liste entre parenthèses décrivant la structure de l'enveloppe du message. Elle est calculée par le serveur en analysant les en-têtes [RFC-2822] en leurs constituants, en utilisant des valeurs par défaut pour divers champs si nécessaire.

  Les champs de la structure d'enveloppe sont dans l'ordre suivant : date,
  subject, from, sender, reply-to, to, cc, bcc, in-reply-to, message-id.
  Les champs date, subject, in-reply-to, message-id sont des chaînes. Les
  champs from, sender, reply-to, to, cc, bcc sont des listes entre
  parenthèses de structures d'adresse.

  Une structure d'adresse est une liste entre parenthèses décrivant une
  adresse de courrier électronique. Les champs d'une structure d'adresse
  sont dans l'ordre suivant : nom personnel, liste de domaines à la
  source (source route) [SMTP], nom de boîte aux lettres, nom d'hôte.

  La syntaxe de groupe [RFC-2822] est indiquée par une forme spéciale de
  structure d'adresse où le champ nom d'hôte est NIL. Si le champ nom de
  boîte aux lettres est aussi NIL, cela indique un marqueur de fin de
  groupe (le point-virgule de la syntaxe RFC 822). Si le champ nom de
  boîte aux lettres est non NIL, cela indique un marqueur de début de
  groupe, et le champ nom de boîte aux lettres contient la phrase de nom
  de groupe.

  Si les lignes d'en-tête [RFC-2822] Date, Subject, In-Reply-To,
  Message-ID sont absentes, le membre correspondant de l'enveloppe est
  NIL. Si ces lignes d'en-tête sont présentes mais vides, le membre
  correspondant de l'enveloppe est la chaîne vide.

RFC 3501 IMAPv4 March 2003

     Note : il existe des serveurs qui renvoient un membre d'enveloppe
     NIL dans le cas « présent mais vide ». Les clients DEVRAIENT (SHOULD)
     traiter NIL et la chaîne vide de manière équivalente.

     Note : [RFC-2822] exige que tout message possède un en-tête Date
     valide. Par conséquent, le membre date de l'enveloppe ne peut être
     ni NIL ni une chaîne vide.

     Note : [RFC-2822] exige que, lorsqu'elles sont présentes, les
     en-têtes In-Reply-To et Message-ID aient un contenu non vide. Par
     conséquent, les membres in-reply-to et message-id de l'enveloppe ne
     peuvent être des chaînes vides.

  Si les lignes d'en-tête [RFC-2822] From, To, cc, bcc sont absentes, ou
  présentes mais vides, le membre correspondant de l'enveloppe est NIL.

  Si les lignes d'en-tête [RFC-2822] Sender ou Reply-To sont absentes, ou
  présentes mais vides, le serveur définit le membre correspondant de
  l'enveloppe à la même valeur que le membre from (le client n'est pas
  censé le faire).

     Note : [RFC-2822] exige que tout message possède un en-tête From
     valide. Par conséquent, les membres from, sender, reply-to de
     l'enveloppe ne peuvent être NIL.

FLAGS Liste entre parenthèses des indicateurs (flags) définis sur ce 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, car les données de réponse RFC822.HEADER résultent d'une récupération RFC822. HEADER. Les données de réponse BODY[HEADER] résultent d'une récupération BODY[HEADER] (qui définit \Seen) ou BODY.PEEK[HEADER] (qui ne le définit pas).

RFC822.SIZE Valeur numérique représentant la taille [RFC-2822] du message.

RFC 3501 IMAPv4 March 2003

RFC822.TEXT Équivalent à BODY[TEXT].

UID Valeur numérique représentant l'identifiant unique (UID) du message.

Exemple : S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

7.5. Réponses du serveur - Demande de continuation de commande​

La réponse de demande de continuation de commande est indiquée par le jeton "+" à la place d'une étiquette (tag). Cette forme de réponse indique que le serveur est prêt à accepter la suite de la commande du client. Le reste de cette réponse est une ligne de texte.

Cette réponse est utilisée dans la commande AUTHENTICATE pour envoyer des données de serveur au client et demander des données client supplémentaires. Elle est également utilisée si l'un des arguments de la commande est un littéral.

Le client NE DOIT PAS (MUST NOT) envoyer les octets du littéral à moins que le serveur n'indique qu'il les attend. Cela permet au serveur de traiter la commande et de rejeter les erreurs ligne par ligne. Le reste de la commande, y compris le CRLF qui la termine, suit les octets du littéral. Si des arguments de commande supplémentaires existent, ils suivent les octets du littéral avec un espace.

Exemple : C: A001 LOGIN {11} S: + Ready for additional command text C: FRED FOOBAR {7} S: + Ready for additional command text C: fat man S: A001 OK LOGIN completed C: A044 BLURDYBLOOP {102856} S: A044 BAD No such command as "BLURDYBLOOP"