Mon blog

Python & Datalove <3

Lecture de RFC

Oui, alors je sais bien que je devais parler de ma configuration de Vim d'après mon dernier article, mais j'ai finalement changé d'avis. C'est mon blog après tout, et puis personne ne me lit...

Les mots clefs

J'ai donc entamé la lecture de la RFC 5321 et j'ai commencé à mettre de côté tout ce qui peut me servir comme informations. Typiquement, je me suis surtout concentré sur ces fameux mots clefs qui pimentent les RFC :

  • MUST (et sa variante MUST NOT)
  • REQUIRED
  • SHALL (SHALL NOT)
  • SHOULD (SHOULD NOT)
  • RECOMMENDED
  • MAY
  • OPTIONAL

Ces mots clefs sont de première importance lorsqu'on lit une RFC, ils permettent de bien voir où sont les limites entre ce qu'on peut faire et ce qu'on ne peut pas faire.

Le vocabulaire

De même, la RFC décrit tout un tas de terme qui devraient permettre de bien comprendre le contenu de la discussion.

La définition du modèle SMTP

Le modèle SMTP est assez particulier dans le monde du réseau moderne. En effet, en général on a un client et un serveur et puis c'est à peu près tout. Ici, il faut comprendre deux points importants :

  • Premièrement, à l'époque de la création de SMTP, il n'y a pas autant d'ordinateurs. Cela coûte cher et on estime donc qu'un ordinateur est éteint la plupart du temps. Il y a une vraie différence entre un ordinateur personnel et un serveur. Il n'y a pas de "box", il faut utiliser un modem pour se connecter au réseau et ça bloque la ligne et ça coûte cher.
  • Deuxièmement, le but est de pouvoir connecter des réseaux entre eux, et de prendre en compte que, peut-être, le réseau cible n'est pas tout à fait équivalent à celui que l'émetteur utilise; les protocoles utilisés en interne sont potentiellement différent. En gros, TCP/IP n'est pas la norme de facto.

Il est donc compréhensible que, partant de ces notions, le protocole SMTP doit permettre à deux machines potentiellement éteintes de pouvoir communiquer à travers un réseau plus ou moins hétérogène (plutôt plus à l'époque).

Je reprends directement le schéma de la RFC :

              +----------+                +----------+
  +------+    |          |                |          |
  | User |<-->|          |      SMTP      |          |
  +------+    |  Client- |Commands/Replies| Server-  |
  +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
  | File |<-->|          |    and Mail    |          |<-->| File |
  |System|    |          |                |          |    |System|
  +------+    +----------+                +----------+    +------+
               SMTP client                SMTP server

On a donc, à gauche, un humain (User) qui souhaite envoyer un message à un autre humain (qui n'apparait pas ici d'ailleurs). Et le protocole SMTP va se baser sur l'existant : le système de courier physique connu de tous avec ses factrices, ses postes, ses boites aux lettres, etc...

Pour envoyer un courier, l'utilisateur va donc utiliser un logiciel client (la boite aux lettres publique, ou le facteur qui vient la vider) pour envoyer un message. Le facteur va acheminer ce message au serveur (la poste locale).

À son tour, le serveur (la poste locale) va se débrouiller pour transmettre le message à travers plusieurs réseaux potentiellement différents (ferroviaire, routier, maritime, aérien) via d'autres serveurs (des postes régionales) pour enfin aboutir à un serveur final (la poste locale du destinataire) qui positionnera le courier dans la boite aux lettres du destinataire (via le facteur local).

Enfin, le destinataire ira relever le contenu de sa boite aux lettres une fois de temps en temps (et non toutes les 5 minutes comme le font la plupart de nos clients, quand ce n'est pas plus).

Ainsi, le protocole SMTP n'est là que pour imiter le fonctionnement d'un courier physique (système plutôt bien éprouvé depuis des années). Cela explique le fonctionnement asynchrone du courier électronique mais également le fait qu'un courier peut prendre un certain temps à être distribué, le protocole sait gérer les quelques complications de la vie d'un message.

Attention, il est important de noter que, comme dans la vraie vie, le protocole SMTP n'essaye pas de définir le contenu du message. Tout au plus, il spécifie le moyen de destiner celui-ci, voire de spécifier quelques options tout comme lorsque vous écrivez à quelqu'un vous devez bien mettre une adresse, affranchir le courier, etc...

De même, il n'est pas question de savoir comment le destinataire vérifie sa boite aux lettres. Et c'est pour cela qu'on utilise les protocoles IMAP et POP3.

Mail

Un mail est l'objet transporté par le protocole SMTP. Il est constitué d'une enveloppe et d'un contenu (on voit bien ici les termes repris du monde physique).

L'enveloppe est constituée d'unités distinctes :

  • Une adresse d'origine (pour lui retourner d'éventuels problèmes)
  • Une ou plusieurs adresses destinataires (pour leur transmettre le contenu du mail)
  • Et potentiellement des options spécifiques aux extensions possibles

On voit donc qu'une enveloppe est ultra simple, comme le nom du protocole le suggérait.

Le contenu, lui, est constitué de deux parties :

  • Les entêtes
  • Le corps

Chaque entête contient un nom et une valeur, séparés par le caractère ":".

Le corps est une suite de caractères plus ou moins complexes (suivant l'extension utilisée ou pas).

Expéditeur, Destinataire, Client, et Serveur

Ici, l'expéditeur est celui qui transmet le message vers le destinataire, mais le monde du réseau préfère parler de Client et de Serveur. Pour autant, une même machine peut servir à la fois de Client et de Serveur lorsqu'il sert à relayer un mail.

MUA, MTA, MDA

MTA signifie Mail Transfer Agent et indique un outil de transfert de courier. Les clients aussi bien que les serveurs ont cette fonction de transférer les messages.

MUA signifie Mail User Agent et représente à la fois la source des messages et leur destination. Le premier peut être représenté comme la boite aux lettres publique dans laquelle vous déposer votre messages. Le second peut être représenté comme la boite aux lettres finale qui stocke le courrier reçu. Ce sont les points d'entrée et de sortie du système.

MDA signifie Mail Delivery Agent représente le facteur qui prend le courrier depuis la poste locale et le dépose (s'en débarasse) dans votre boite aux lettres.

On voit donc bien que les explications ne sont pas toujours aussi claires et limpides que l'on voudrait et que certains profils se recoupent. En gros, on peut considérer que votre logiciel de messagerie va être un client SMTP qui va déposer un mail dans le "circuit" auprès d'un serveur SMTP spécifié (celui de votre FAI en général). Que ce dernier va transporter (le T de SMTP) les mails vers le serveur SMTP de destination (et donc en tant que client) potentiellement en étant passer par plusieurs autres serveurs SMTP de relais. Et enfin, lorsque le courier est déposé sur un serveur, le client de messagerie du destinataire agira comme ... eh bien comme rien du tout car on n'est alors plus dans la partie SMTP et donc le client agira via POP3 ou IMAP.

Hôte

L'hôte est un ordinateur connecté à un réseau et supportant le protocole SMTP. Un hôte est défini par un nom.

Nom de domaine

Un nom de domaine (ou juste domaine) est constitué de mots séparés si besoin par le caractère ".". Chaque mot est constitué de lettres, de chiffres et de caractères "-".

Les noms de domaines doivent être pleinement qualifiés, c'est à dire qu'ils doivent pointer vers une machine donnée.

Buffer (tampon) et table d'états

Le protocole SMTP est une discussion synchrone entre deux ordinateurs. Afin de se souvenir des décisions prises, une table d'état et un tampon sont utilisés.

Commandes et réponses

Les commandes et les réponses SMTP sont transmises par ligne.

Les commandes sont constituées de mots séparés par des espaces.

Les réponses sont constituées d'un nombre suivi éventuellement d'un texte explicatif.

Ligne

Les lignes (commandes et réponses lors des échanges) sont constituées de 0 à n caractères et sont terminées par les caractères spéciaux de saut de ligne <CR> et <LF>.

Conclusion

Wouh, je ne pensais pas écrire autant sur tout ça. Je vais m'arrêter là pour aujourd'hui et continuer la lecture et l'étude de cette RFC ô combien passionnante.

La prochaine fois, on parlera peut-être de tous ce qui est induis par les mots clefs de la RFC.