Le protocole HTTP:

Le Protocole HTTP ( hypertext transfert protocol ) sert ( entre autre ) au dialogue entre votre navigateur Web et un serveur.

Comme la plupart des protocoles internet, c'est un protocole texte basé sur TCP. Il suffit donc d'ouvrir une connexion TCP sur le port 80 du serveur, et d'envoyer une requête texte vers le serveur. Il est très facile de faire des tests avec la commande telnet: telnet www.iprelax.net 80.

La requête a la forme suivante: GET /index.html HTTP/1.1 (suivi de 2 retours chariot complet 'rn'). Elle permet de demander le fichier index.html sur le serveur www.iprelax.net

La réponse sera composée de deux parties, l'entète qui indique si la requête a reussi et le corps du message.

Remarques: en plus de la ligne GET ..., la requête peut contenir des champs supplémentaires sur les lignes suivantes, tel que Host qui est indispensable si l'on passe par un proxy. Cette information est utilisée dans le programme client. En effet, si vous vous êtes connectés à un proxy ( eg: telnet proxy 8080 ), il faut spécifier le nom du serveur. Cela donne:

GET /index.html HTTP/1.1rn
Host: www.iprelax.netrn
rn

Dans la section 'programmes', vous trouverez de nombreux programmes qui montrent comment utiliser ce protocole. Pour connaitre toutes les options et les messages, consultez la RFC.

Le protocole SMTP:

Le protocole SMTP ( simple mail transfert protocol ) sert à transférer des mails d'une machine à une autre.

Pour envoyer un mail il suffit de se connecter sur le port TCP 25 d'un serveur, et moyennant quelques commandes très simples en mode texte de donner ses instructions.

Voici ci-dessous les différentes phases du dialogue pour envoyer un mail.

Envoyeur (client)                  Receveur (serveur)
          _________________                  __________________
           
établissement de la connection
                           <--------------220 'server domain' Service Ready

        HELO 'sender domain'---------------->
                           <--------------250 'server domain' OK           

        MAIL FROM: '@ envoyeur' ------------>
                           <--------------250 OK                           

        RCPT TO: '@ destinataire' ---------->
                           <--------------250 OK                           

        DATA                ---------------->
                           <--------------354 Start mail input, end with .
        line1               ---------------->
        line2               ---------------->
        line3               ---------------->
        .                   ---------------->
                           <--------------250 OK                           

        QUIT                ---------------->
                           <--------------221 'server' closing connection

Dans la partie Data, on peut ajouter des informations :

to	destinataire(s) principal du message. ( si on met RCPT TO sans to: le destinataire sera en bcc au lieu de to )
cc	copy carbon.
from	envoyeur.
Subject	sujet du message.

POP ( post office protocol ) ( la version standard est POP3, definie dans la RFC 1939) est la manière dont les clients email récupèrent les emails sur les serveurs internet. Comme la plupart des protocoles internet, il est basé sur la ligne de commande, c'est à dire que toutes les operations sont faites à partir d'un texte de commandes qui est envoyé au serveur. Il est donc tres simple de simuler un client à partir d'une connection telnet sur le serveur ( et le bon port ), il est donc aussi facile d'écrire un client spécialisé à certaines taches basées sur le mail.

Le serveur POP3 écoute sur le port 110, Si vous faites un telnet vers un serveur POP3 sur le port 110, vous obtiendrez quelque chose du genre :
+OK POP3 pop3.serveur.com v4.38 server ready
La ligne commence par un indicateur d'état +OK. Chaque réponse commence par +OK ou -ERR. Faciiiile !!

Au début de la session, vous êtes en mode login. Les seules commandes autorisées sont USER, PASS et QUIT. Donc pour vous logger :

> USER nicolas
        > PASS coucou

Faciiiile (bis) !!

Une fois que vous etes loggés, vous avez accés à votre mailbox, il ne reste plus qu'à utiliser les commandes suivantes:

STAT	Cette commande renvoie une ligne avec 2 nombres : le premier correspond au nombre de messages, le second à la taille totale des messages. En fait, cette commande ne nous sert pas a grand chose !!.
LIST	LIST donne le contenu de la mailbox de la façon suivante: LIST +OK Mailbox contents follow 1 7774 2 513 3 10493 . La dernière ligne est simplement un point, méthode assez standard dans les protocoles sur le mail. Chaque ligne est composée du numéro du message et de sa taille. Attention les numéros ne sont pas forcément sequentiels !! Si vous en supprimez un il disparait simplement.
RETR msg	RETR récupère un message. Utilisez le numéro fournit par LIST. Vous allez recevoir l'entête du message, puis le contenu et enfin une ligne avec simplement un point. Si le contenu a une ligne avec simplement un point, il sera doublé, à vous donc de corriger l'affichage pour supprimer les doublons inutiles.
DELE msg	DELE supprime un message, mais il ne sera réellemnt supprimer qu'au moment de la commande QUIT, vous pouvez donc le récupérer avec la commande RSET.
TOP msg n	TOP renvoie l'entête du message plus les n premières lignes de son contenu. n peut etre nulle. Cette commande est optionelle mais généralement supportée.
QUIT	QUIT termine la session et supprime les messages marqués par DELE.

Le protocole POP:

Voila ça devrait vous suffire pour faire plein de trucs rigolos, à commencer par écraser par erreur les mails sur votre serveur :-) .

Une dernière info quand même. POP étant un protocole texte sur une connexion telnet, si vous vous authentifié en utilisant la méthode USER/PASS, votre mot de passe circule en claire sur le réseau. Vous pouvez donc utiliser la commande APOP (facultative et donc pas toujours supportée par le serveur) qui s'utilise de la façon suivante: APOP login digest. Le digest est la signature MD5 de votre mot de passe et du tag renvoyé par le serveur au moment de la connexion.
Le protocole IMAP

Introduction

Le protocole IMAP est né en 1986 à l'Université de Stanford, bien qu'il ne fut pas documenté avant les spécifications RFC 1064 de juillet 1998. Cette dernière ayant elle-même subit de multiples révisions jusqu'à aujourd'hui, la version actuelle étant IMAP4rev1, décrite dans RFC 2060.IMAP a été d'abord pensé pour supporté le mode d'accès en-ligne (cf. paradigmes d'accès aux messages), c'est pourquoi "IMAP" signifiait d'abord "Interactive Message Acces Protocol", mais le nom a été changé en 1993, au cours de l'effort de standardisation fait par l'IETF, pour rendre compte des possibilités actuelles offertes par IMAP. Ce protocole regroupe toutes les fonctionnalités offertes par POP, et supporte donc complètement le mode d'accès hors-ligne. En plus, avec les ajouts apportés à la version 4, il supporte maintenant le mode déconnecté.

Le but n'est pas ici de fournir une description détaillée et complète de ce protocole, mais plutôt d'expliquer son fonctionnement global et ses fonctionnalités dans les grandes lignes, afin de pouvoir aborder les spécifications avec plus de facilité. Ainsi la syntaxe des commandes et des réponses n'est pas du tout traitée. Pour une description complète de celle-ci, il est fortement conseillé de consulter directement les spécification officielles (RFC 2060).

La version du protocole considérée est ici le version 4, révision 1 (IMAP4rev1), décrite dans RFC 2060.

Fonctionnement

1 Niveau de connexion

Le protocole IMAP s'appuie sur l'hypothèse d'un flux de données stable, comme celui fournit par TCP. Lorsque TCP est utilisé, un serveur IMAP écoute le port 143.

2 Commandes et réponses

Une connexion IMAP comprend d'abord l'établissement d'une connexion réseau client/serveur, puis un message de salutation initial du serveur et enfin d'interactions client/serveur. Ces interactions client/serveur consistent en une suite de commandes/réponses entre le client et le serveur. Toutes les données transmises entre le client et le serveur se présentent sous forme de lignes qui se terminent par CRLF.

3 Client émetteur du protocole et serveur récepteur

Une commande du client commence une opération. Chaque commande du client est préfixée par un identificateur (typiquement une chaîne alphanumérique courte (par exemple : A0001, A0002, etc.) appelé tag. Un tag différent est généré par le client pour chaque nouvelle commande.
Le serveur IMAP lit une ligne de commande reçue du client, parcourt la commande et ses arguments et transmets les données appropriées ainsi qu'une réponse résultat de commande complétée.

4 Serveur émetteur du protocole et client récepteur

Les données transmises au client par le serveur et les réponses de statut n'indiquant pas qu'une commande a été complétée sont préfixées par "*" , et sont appelées réponses sans tag (untagged). Les données transmises par le serveur peuvent être le résultat d'une commande du client, mais aussi d'une décision unilatérale du serveur. Il n'y a aucune différence syntaxique entre des données qui sont le résultat d'une commande et celles qui sont le résultat d'un décision unilatérale du serveur. La réponse résultat de commande complétée indique le succès ou l'échec de l'opération. Le tag de cette réponse est le même que celui de la commande du client qui a lancé l'opération. Ainsi, si plus d'une commande sont en cours d'exécution, le tag permet d'identifier la commande à laquelle cette réponse est destinée. Il y a trois réponses de commande complété possibles :
" OK : indique que l'opération s'est déroulée avec succès
" NO : indique que l'opération a échouée
" BAD : indique une erreur de protocole, comme une commande non reconnue ou une erreur de syntaxe
Le client lit une ligne de réponse du serveur. Il agit ensuite en fonction du premier token de la réponse, qui peut être un tag, "*" ou "+".

3.ETAT

Un session IMAP peut se trouver dans quatre états différents. La plupart des commandes sont valides seulement dans certains états. Un client qui tente d'exécuter une commande qui n'est pas valide dans l'état actuel commet une erreur de protocole. Dans une telle situation, le serveur répondra par BAD ou NO (suivant l'implémentation).

1 Etat non-authentifié (non-authentificated)

Dans l'état non-authentifié, le client doit fournir une authentification correcte avant que la plupart des commandes ne soient permises. Le serveur entre dans cet état lorsqu'une connexion qui n'a pas été pré-authentifiée commence.

2 Etat authentifié (authentificated)

Dans l'état authentifié, le client est authentifié et doit sélectionner une boîte aux lettres à laquelle accéder avant que les commandes opérant sur les messages soient autorisées. Le serveur entre dans cet état lorsqu'une connexion pré-authentifiée est ouverte, lorsqu'une authentification correcte a été fournie ou encore lorsqu'une erreur s'est produite lors de la sélection de la boîte aux lettres.

3 Etat sélectionné (selected)

Dans l'état sélectionné, une boîte aux lettres a laquelle accéder a été sélectionnée. Le serveur entre dans cet état lorsqu'une boîte aux lettres a été correctement sélectionnée.

4 Etat déconnexion (logout)

Dans l'état déconnexion, la connexion se termine et le serveur ferme cette connexion. Le serveur entre dans cet état suite à une requête d'un client ou suite à une décision unilatérale.

Diagramme d'état

+--------------------------------------------------+
        |        connexion initiale et salutations         |
        +--------------------------------------------------+
             || (1)             || (2)               || (3)
             VV                 ||                   ||
        +-----------------+     ||                   ||
        |non-authentifiée |     ||                   ||
        +-----------------+     ||                   ||
         || (7)       || (4)    ||                   ||
         ||           VV        VV                   ||
         ||        +----------------+                ||
         ||        |  authentifiée  |<====++         ||
         ||        +----------------+     ||         ||
         ||         || (7)    || (5)      ||(6)      ||
         ||         ||        VV          ||         ||
         ||         ||    +--------+      ||         ||
         ||         ||    |selected|======++         ||
         ||         ||    +--------+                 ||
         ||         ||        || (7)                 ||
         VV         VV        VV                     VV
        +--------------------------------------------------+
        |                   déconnexion                    |
        +--------------------------------------------------+

(1) connexion sans pré-authentification (OK greeting)
(2) connexion pré-authentifiée (PREAUTH greeting)
(3) connexion rejetée (BYE greeting)
(4) commande LOGIN ou AUTHENTICATE complétée avec succès
(5) commande SELECT ou EXAMINE complétée avec succès
(6) commande CLOSE, ou échec de la commande SELECT ou EXAMINE
(7) commande LOGOUT, arrêt du serveur, ou fermeture de connexion

Formats de données

IMAP utilise des commandes et réponses textuelles. Les données peuvent se présenter sous différentes formes : atomes, nombre, chaîne, liste parenthèsée ou NIL.

1 Atome

Un atome consiste en un ou plus caractères non spéciaux.

2 Nombre

Un nombre consiste en un ou plusieurs chiffres et représente une valeur numérique.

3 Chaîne

Une chaîne peut avoir deux formes : littérale ou "quoted". Le forme littérale est la forme générale d'une chaîne. La forme "quoted" est une variante qui évite qu'un caractère littéral ne soit traiter comme une commande, cependant les caractères qui peuvent être utilisés dans une chaîne "quoted" sont limités. Une chaîne littérale est une séquence de zéro octets ou plus ouverte par une accolade ouvrante (" {" ), fermée par une accolade fermante (" } ") et suivie de CRLF.
Dans le cas où des chaîne littérales sont transmisses par le serveur au client, CRLF est immédiatement suivit par l'octet de données.
Dans le cas d'une chaîne littérale transmise par le client vers le serveur, le client doit attendre que le serveur soit prêt et ensuite seulement, il peut envoyer l'octet de données.
Une chaîne "quoted" est une séquence de zéro caractères 7 bits ou plus, sauf CR et LF, ouverte et fermée par des guillemets.
La chaîne vide est représentée soit par "" (une chaîne "quoted" avec zéro caractères), soit par {0} suivit de CRLF (une chaîne littérale avec zéro octets).

4 Listes parenthèsées

Les structures de données sont représentées sous forme de listes parenthèsées : une séquence d'objets de données séparés par des espaces, chaque objet étant enfermé dans une paire de parenthèses. Une liste parenthèsée peut contenir d'autre listes parenthèsées.
La liste vide est représentée par () c à d une liste ne contenant aucun membre.

5 NIL

L'atome spécial NIL représente la non-existence d'un objet de données particulier. NIL permet de faire une distinction entre une chaîne ou une liste vide et une chaîne ou une liste qui n'existe pas.

5. Paradigmes d'accés aux messages
Il existe différentes approches permettant de mettre en place une infrastructure distribuée pour le courrier électronique. Parmi celles-ci : les stratégies de systèmes de fichiers partagés, les protocoles propriétaires orientés LAN, le protocole X 400 P7 et les protocoles d'accès aux messages Internet, dont : POP, DMSP (Distributed Mail System Protocol) et IMAP. De ces trois derniers protocoles, POP est le plus ancien et par conséquent le plus connu. DMSP est limité à une seule application, PCMAIL, et est principalement connu pour ses capacités en mode déconnecté. IMAP supplante POP et DMSP dans les capacités et permet l'accès aux messages dans les trois modes de connexion à distance : hors-ligne, en-ligne et déconnecté.

1 Accès en mode hors-ligne

Le programme de courrier client, ou "Mail User Agent" (MUA), récupère les messages sur le serveur, les sauvegarde sur la machine depuis laquelle est exécuté le MUA puis supprime les messages du serveur. Tout traitement sur le courrier est alors effectué localement sur la station de travail cliente.
Ce modèle est parfait lorsque l'utilisateur accède à son courrier toujours depuis le même ordinateur et se contente d'avoir la copie principale de ses messages toujours sur cette seule machine. Si au contraire l'utilisateur a besoin d'accéder à ses messages depuis plusieurs machines, ou qu'il désire laisser son courrier sur une machine différente de celle avec laquelle il interagit directement, le modèle hors-ligne est inapproprié.

2 Accès en mode en-ligne

Les messages sont laissés sur le serveur et sont manipulés à distance par le MUA. Ce type d'accès implique un temps de connexion plus long que pour les modes hors-ligne et déconnecté.

3 Accès en mode déconnecté

Le client se connecte au serveur de courrier, fait une copie des messages sélectionnés, puis se déconnecte du serveur pour se reconnecter plus tard. Ce mode d'opération se distingue du mode hors-ligne par le fait que les messages originaux sont laissés sur le serveur. Le client doit se reconnecter et synchronisé les statuts des messages entre le serveur et le cache. Le temps de connexion pour ce genre d'accès est sensiblement le même que pour le mode hors-ligne.