1. Le système de messagerie InterNet

Cette documentation est extraite du site de Pierre David, coauteur du kit jussieu qui est une aide à la configuration du logiciel sendmail.

Ce qui est marqué en Note : est rajouté par moi.

Un système de messagerie InterNet contient les composants suivants :

agent utilisateur (ou user agent, ou UA)

Un UA est un programme que l’utilisateur emploie pour composer son message et l’envoyer à l’agent de routage (voir ci-dessous) qui va l’injecter dans le système de messagerie.

Un UA permet également la lecture du courrier. C’est la phase finale. Il y a un UA à chaque extrémité du système de messagerie.

Note : Aujourd’hui les principaux UA sont netscape messenger, Eudora, Outlook, mozilla, evolution, pine, mutt...

agent de routage des messages

Un agent de routage reçoit un message. En fonction de l’adresse du destinataire, il décide de faire appel à un agent de transport de messages, dont le but est d’acheminer le message dans la direction du destinataire.

Les agents de routage sous Unix sont, entre autres, sendmail, smail et mmdf. Toutefois, le plus répandu est incontestablement sendmail.

Note : qmail et surtout postfix s’imposent de plus en plus.

agent de transport des messages

Un agent de transport reçoit un message et une direction, et l’achemine à l’endroit indiqué. Il faut bien comprendre que l’agent de transport des messages ne prend pas de décision quant au routage. Cette décision lui est indiquée par l’agent de routage qui lui transmet le message.

Un agent de transport de messages est spécialisé pour un type de transmission. Par exemple, il y aura un agent de transport pour SMTP (le protocole utilisé sur l’InterNet), un autre pour la remise physique du message (lorsque le courrier arrive dans la boîte aux lettres du destinataire), un troisième pour l’expédition vers un site UUCP, etc.

En terminologie sendmail, un agent de transport est appelé un mailer (bien qu’en terminologie Unix, on appelle traditionnellement mailer un UA).

Les agents de transport des messages typiques sous Unix sont sendmail (une partie de sendmail est dédiée au protocole SMTP), uucp pour l’acheminement vers un site UUCP, ou encore /bin/mail pour la remise physique.

Note : l’agent de transport utilisé à l’UFR est /usr/bin/procmail.

une boîte aux lettres

Sur les systèmes Unix, une boîte aux lettres est simplement un fichier dans /var/spool/mail (systèmes d’origine Berkeley) ou dans /usr/mail (systèmes d’origine System V).

Note : ce fichier a pour nom le login de l’utilisateur.

Dans un tel fichier, tout nouveau message débute par une ligne From (sans caractère << : >>). Cette ligne, qu’on appelle souvent le << From Unix >> sert à délimiter les différents messages : elle fait partie de l’enveloppe qui correspond à des champs SMTP tels que le nom de la machine émettrice, l’adresse mail de l’émetteur et celles des destinataires.

Les adresses utilisées dans l’InterNet sont définies par la RFC 822 et amendées par la RFC 1123. Il n’y a pas de distinction entre minuscules et majuscules (sauf dans les commentaires ou les chaînes de caractères). Les messages propement dits, eux, sont constitués de deux parties distinctes :

  L’en-tête est une suite de champs, définis par la RFC 822 et amendés par la RFC 2045. La plupart des en-têtes dupliquent les informations de l’enveloppe.

  Le corps est le contenu du message proprement dit. Il est séparé de l’en-tête par au moins une ligne vide. Pendant longtemps, le contenu du corps n’était réglementé que par la RFC 821 (lignes de 1000 caractères au maximum et caractères tronqués à 7 bits). Le standard MIME définit dorénavant une structure pour le corps.

Un exemple de message est donné ici.

2. Le Protocole smtp (RFC 821)

Les lignes qui suivent sont également largement extraites du document de Pierre David (cf. ci-dessus).

Le protocole SMTP (Simple Mail Transport Protocol) est le protocole du service de courrier électronique. Il opère à travers TCP sur le port 25. Le plus populaire serveur SMTP du monde UNIX est sendmail.

Note : c’est celui que nous utilisons à l’UFR.

SMTP est un protocole point à point (serveur à serveur) mais il se peut qu’il ne concerne qu’un seul serveur lorsque vous envoyez un message à quelqu’un qui est géré par le même serveur de mail que vous. SMTP ne sert qu’à envoyer des messages : il est le protocole commun d’envoi de message. Il vous faudra ensuite utiliser un autre protocole pour aller lire vos messages (POP3, IMAP, ...). SMTP définit le format des messages comme la forme des adresses, les différents champs de votre courrier (FROM :, TO :, SUBJECT :, ...), ainsi que l’horodatage des mails.

Le SMTP est accessible sous shell et les messages qui circulent entre le serveur et le client sont facilement interprétables. Comme le langage HTTP, SMTP est syntaxiquement défini par une grammaire BNF. L’utilisateur bénéficie d’une liste de commande pour envoyer son courrier dont voici les plus parlantes :

Commandes

Les mots-clefs (ou commandes) du protocole SMTP sont listés ci-dessous. Chaque mot-clef est cité avec son nom, sa syntaxe (entre parenthèses, sans distinction entre minuscules et majuscules) et sa signification.

Hello (HELO site-émetteur) : Commence une session SMTP par une identification des deux parties. Le récepteur s’identifie dans sa réponse

Mail (MAIL FROM : expéditeur) : Commence une nouvelle transaction. Spécifie l’expéditeur, pour le renvoi des messages d’erreur éventuels

Recipient (RCPT TO : destinataire) : Spécifie un destinataire. Cette procédure peut être répétée autant de fois que nécessaire. Si le destinataire n’est pas valide, un code d’erreur est renvoyé aussitôt

Data (DATA) : Envoie le message (en-tête + corps) terminé par une ligne ne contenant qu’un point. Pour ne pas interférer avec le message à transmettre, toute ligne du message contenant un point en première position est modifiée en insérant un point supplémentaire en début. Ce point supplémentaire est supprimé par le récepteur (hidden dot algorithm)

Verify (VRFY destinataire) : Demande au site récepteur de vérifier que le destinataire est une adresse valide

Expand (EXPN destinataire) : Demande au site récepteur, d’une part de vérifier que le destinataire est une adresse de liste de diffusion valide, et d’autre part de renvoyer les identités des membres de la liste ;

Help (HELP) ou Help (HELP commande) : Renvoie la liste des commandes SMTP admises par le site récepteur

Noop (NOOP) : Ne fait rien

Quit (QUIT) : Termine la session SMTP

La première commande est obligatoirement HELO (ou EHLO) et la dernière QUIT.

SMTP est un protocole qui souffre de quelques limitations :

  La première est que SMTP n’offre aucune garantie concernant l’identité de l’émetteur du message.

  La deuxième est que SMTP est un protocole fermé, sans possibilité de modification, donc d’évolution. Compte-tenu des besoins immédiats, tels que l’échange de courriers contenant des caractères accentués, et des besoins ultérieurs qui ne manqueront pas d’apparaître, deux approches complémentaires ont été adoptées en 1992 :

• définition de MIME (Multipurpose Internet Mail Extensions) pour être capable, entre autres, et si besoin est, d’échanger des messages contenant des accents (donc sur 8 bits) ou des données binaires sur un canal SMTP conforme strictement à la RFC 821

• définition de ESMTP (Extended SMTP), extension au protocole SMTP, afin de pouvoir faire évoluer le protocole tout en gardant la compatibilité avec les implémentations actuelles ou à venir.

Principes de ESMTP

L’idée de ESMTP est d’étendre SMTP sans compromettre la compatibilité avec les implémentations antérieures. La RFC 1651 décrit un nouveau mot-clef, EHLO (les lettres E et H sont inversées), qui introduit un dialogue ESMTP si les deux parties le reconnaissent.

Si le serveur distant ne le reconnaît pas, le mot-clef est ignoré et le dialogue continue en SMTP classique : le client ESMTP, à la réception du message d’erreur du serveur, envoie le mot-clef HELO traditionnel et la conversation continue.

Si le serveur distant reconnaît EHLO, il envoie la liste des extensions qu’il supporte et le client peut alors utiliser celles qu’il souhaite.

L’exemple suivant illustre le début d’une connexion ESMTP, dans lequel le client (pc704i-1.ens.math-info.univ-paris5.fr) s’annonce avec EHLO sous le nom d’unknown.ens.math-info.univ-paris5.fr. En retour, le serveur (mail.mydomain.net) annonce ses extensions et le dialogue s’instaure.

L’utilisateur testuser@mydomain.net reçoit ainsi le message suivant.

Cet exemple montre bien que l’utilisateur moil a tenté sans succès de falsifier l’identité de sa machine mais qu’il a réussi à envoyer un courrier avec une adresse bidon.

3. Protocole pop3 (RFC 1725)

Pop3 est un protocole qui va permettre à un client de messagerie de télécharger les messages d’un utilisateur situés sur un serveur de messagerie.

Le port dédié à pop3 est le numéro 110.

La session POP3 se déroule en plusieurs phases :

  L’ouverture de session.

  L’authentification du client soit par les deux commandes USER+PASS ou directement APOP : le serveur et le client partagent un mot de passe pour crypter le mot du passe du client afin que celui-ci ne passe pas en clair sur le réseau.

  La transaction : lecture des mails, gestion des mails, ...

  La commande QUIT qui engendre la mise à jour du compte mail du client.

  La fermeture de la connexion.

L’exemple suivant permet à l’utilisateur moil de consulter un message avec la commande telnet depuis la machine pc704i-1.

4. Imap (RFC 1731 et 1732)

Ce protocole est très puissant mais sa mise en place est assez délicate. Au contraire de POP qui n’offre qu’un accès exclusif à une boîte mail, IMAP est capable de gérer plusieurs boîtes simultanément avec des accès multiples.

Un client imap visualise les messages sur le serveur, au contraire du client POP qui les télécharge sur la machine cliente.

Le travail effectué étant de type client/serveur, imap requiert donc une bonne connexion.

En outre, l’administrateur doit s’assurer que les utilisateurs détruisent régulièrement le contenu de leur boîte (ou qu’ils transfèrent leurs messages via des filtres appropriés).

Le port dédié à imap est le numéro 143.

Pop3 et imap sont des applications clients/serveur. Tous les clients populaires de messagerie (UA) possèdent à la fois un client pop3 et un client imap.

Les logiciels de webmail twig et imp utilisent SMTP pour l’envoi de messages et imap pour accéder aux boîtes des utilisateurs.

5. Cycle simplifié d’un message

Dans ce schema, les deux utilisateurs sont situés sur des réseaux différents.

L’utilisateur 1 envoie un message avec un UA quelconque (ex. mozilla).

Le message est transmis au SMTP de son réseau local (ex. wanadoo.fr) qui contacte le SMTP qui gère le domaine de l’utilisateur 2 (ex. opale pour le domaine ens.math-info.univ-paris5.fr).

Celui-ci accepte le message, le passe à l’agent de transport qui écrit le message dans la boîte de l’utilisateur 2.

Si l’utilisateur 2 utilise pop, il télécharge le message sur son disque dur. S’il utilise imap, il visualise le contenu de sa boîte dans son UA (ex. mozilla).

Il n’y a donc pas de dialogue direct entre les deux UA, le seul dialogue qui existe se situe entre les deux SMTP.

Le SMTP 2 ne peut pas s’assurer que c’est bien l’utilisateur 1 qui a envoyé le message, il fait confiance au SMTP 1 qui peut donc lui « raconter » n’importe quoi.

Lorsque sendmail reçoit un message destiné à un utilisateur de l’UFR, il procède d’abord à une série de contrôles :

  contrôle du SMTP expéditeur, voire du client (inscription dans le DNS)

  contrôle de l’émetteur du message (inscription sur une liste noire...)

  contrôle de la validité de l’utilisateur local (s’il existe), etc.

Puis est testée l’existence éventuelle d’un fichier .forward (le message serait dans ce cas réexpédié à l’adresse indiquée dans ce fichier).

Enfin sendmail passe le relai à l’agent de transport utilisé pour la remise physique (chez nous procmail) qui va se charger d’écrire dans la boîte de l’utilisateur.