Protocole applicatif IMAP :

Constitution de la trace

On observe un échange de trames reposant sur ETHERNET-IP-TCP et sur ETHERNET-IP-TCP-IMAP
Au niveau du serveur, le port employé est le port 143 (le port par defaut pour un serveur imap)

Pourquoi cet échange?

Un client se trouvant dans le sous reseau 10.40.4.0/24 sur la machine 0.0.0.2 souhaite récupérer ses mails sur le serveur mail implémentant le protocole IMAP et se trouvant dans le sous-reseau 10.40.3.0/24, sur la machine 0.0.0.2

Le client utilise alors un client mail gratuit, Kmail, livré avec KDE sous Fedora.
Au niveau du serveur, il y a un serveur mail gratuit MMS (Macallan Mail Solution) sous Windows 2008 serveur.

Le client configure Kmail: il introduit son login et mot de passe (Samir et Pfres). Il introduit l'adresse du serveur imap (imap.ent2.com) et smtp (smtp.ent2.com, smtp sera vu dans la trace smtp lors d'un envoi de mail par client mail).

Une foit de plus, un filtre d'affichage nous permet de voir que les requête et réponse imap:

imap <Return>

Nous avons 18 trames à commenter.

Protocole IMAP

Le protocole Imap est un protocole qui permet de recevoir des mails sur un serveur.
Il travaille en 5 étapes numérotées de c00000 à c00005: le client émet une requete "request c0000x blabla" et le serveur répond par une "reponse c0000x blablabla" et ainsi de suite. A l'issue de l'étape C00005, le client reçoit les mails de sa boite. (ou uniquement les plus récents s'il possède une copie de ses mails sur sa machine) ici, la question ne se pose pas...
​Le Rfc 3501 peut aider à sa compréhension.

Echange proprement dit

I/ Négociations..:

* A la connection le serveur se présente en informant de la version d'imap qu'il implémente

* Le client demande alors

* Serveur l'informe qu'il y a besoin de s'authentifier et envoie un second message

* Le client envoie alors

* Serveur informe que l'authentification est conforme, le login et pass fournis correspondent bien à un compte de messagerie avec le message

* Le client envoie alors la requête

* Serveur répond par deux messages:
1) <* LIST () "/" "INBOX">
2) <* LIST () "/" "sent messages">
On comprend que les comptes rattachés au login samir@ent2.com ont deux dossiers: inbox (boite mails des mails arrivés) et sent messages (pour les messages envoyés)

* Le client envoie alors la requête

* On pouvait s'y attendre, le serveur répond par deux messages:
1) <* LSUB () "/" "INBOX">
2) <* LSUB () "/" "sent messages">
On comprend que les 2 dossiers fournis precedemment par LIST sont actifs.

* Le client envoie alors la requête

* La boite de reception passe à l'etat SELECTIONNE. Le serveur vérifie alors l'etat de cette boite et envoie deux messages:
1) <* 1 EXISTS>
2) <* 1 RECENT>
On comprend que la boite ne comprend qu'un message, et que celui ci est récent, (pas forcément non encore ouvert un mail non ouvert apparait en général "unseen").

* Dernier message du client.
Il demande

* Le serveur n'a qu'un mail à afficher, il lui :
1) <* 1 EXISTS>
2) <* 1 RECENT>
On comprend que la boite ne comprend qu'un message, et que celui ci est récent, (pas forcément non encore ouvert un mail non ouvert apparait en général "unseen").