IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Cours d'introduction à TCP/IP


précédentsommairesuivant

11. Courrier électronique

11-1. Généralités sur le courrier électronique

Le courrier électronique, ou « mail » est l'un des deux services les plus populaires sur le réseau, avec le web.

C'est aussi l'un des plus vieux services du réseau, bien avant que le réseau existe sous la forme que l'on pratique aujourd'hui(126). La préface de la [RFC 822], document fondamental parmi les documents fondamentaux pour ce chapitre, laisse supposer l'existence de nombreux formats d'échanges électroniques sur l'Arpanet, et ce avant 1977.

Sa popularité repose sur sa grande souplesse et rapidité d'emploi. Il permet aussi bien les échanges professionnels que les échanges privés ; son mode d'adressage donne la possibilité d'envoyer un courrier à une personne comme à une liste de personnes ou encore à un automate capable de rediffuser vers un groupe (« mailing-list »).

De nombreux outils développés, à l'origine essentiellement sur le système Unix, autour de ce concept ouvrent un vaste champ de possibilités aux utilisateurs de tous les systèmes d'exploitation, comme la ventilation des courriers par thème, le renvoi automatique, le répondeur (pendant les absences), l'accès à sa boîte aux lettres depuis des endroits différents, la réception de fax... La liste ne peut pas être exhaustive !

C'est souvent pour avoir l'usage du courrier électronique que les entités (s'il en reste) non encore reliées à l'Internet franchissent le pas. L'usage des autres services arrive plus tard, si besoin est.

11-1-1. Métaphore du courrier postal - L'enveloppe

Un courrier postal (ou de surface, « s-mail ») a fondamentalement besoin de l'adresse du destinataire et de l'adresse de l'émetteur (pour la réponse). L'usage du timbre et de l'enveloppe répondent à d'autres critères.

Une fois dans la boîte aux lettres, l'enveloppe est routée de la poste locale vers la poste la plus proche du destinataire, pour être finalement délivrée par un facteur.

Pour un courrier électronique, les besoins sont quasiment identiques !

Le concept d'enveloppe est conservé, il s'agit de l'adresse de l'émetteur du courrier et de celle(s) du (des) destinataire(s), propagées de manière bien séparée du corps du message afin que le protocole SMTP qui joue le rôle du service postal puisse router et finalement délivrer le courrier à son (ses) destinataire(s).

Il existe de très nombreux outils pour lire/écrire un mail, des outils pour jouer le rôle du bureau de poste et/ou du facteur. Sous Unix, le facteur est le système lui-même, le bureau de poste un programme nommé « sendmail(127) ».

Il existe d'autres alternatives non abordées dans ce document, comme le programme « qmail(128) » ou encore le programme « postfix(129) ».

11-1-2. Adresse électronique

Tous les courriers électroniques ont un destinataire précisé par son adresse électronique, ou « E-mail(130) ». Celle-ci précise le nom du destinataire et le site où il reçoit son courrier électronique.

Le nom du destinataire est une chaîne de caractères. Traditionnellement et pour des raisons techniques, sur le système Unix, le login de l'utilisateur peut être également le nom de sa boîte aux lettres. Cette possibilité est de moins en moins vraie à mesure que d'autres systèmes avec d'autres logiques de fonctionnement existent également sur le réseau (notamment la lecture du mail via une interface HTML ou encore lorsque le mail est délivré directement dans une une base de données et non délivré dans un fichier).

Par exemple, il est assez fréquent de voir employer le nom complet (prénom et nom de famille) pour désigner l'interlocuteur distant. La conversion ultime entre cette convention et la boîte aux lettres de l'utilisateur est l'affaire du « bureau de poste le plus proche », c'est-à-dire le programme « sendmail » pour ce document (voir plus loin au paragraphe 4).

Le caractère « @ » (lire « at ») sépare l'identificateur du destinataire de la destination.

La destination peut être vide (il s'agit alors d'un destinataire sur la machine courante, ou d'un synonyme (« alias ») que le sendmail local sait traiter), être un nom de machine du domaine local, le nom d'un autre domaine ou d'une machine sur un autre domaine.

Les adresses suivantes ont un format valide :

user1 Destinataire local.
user2@nom de machine Destinataire sur une machine du domaine courant (rappelez-vous, il existe un mécanisme de complétion dans le « resolver »).
user3@nom de machine.domaine Destinataire sur une machine particulière d'un domaine particulier (non forcément local).
user4@domaine Destinataire sur un domaine particulier (même remarque que ci-dessus).

On devine aisément que le fonctionnement du courrier électronique sur une machine distante est fortement lié au bon fonctionnement du serveur de noms (chapitre IX).

Qui plus est, lorsque seul un nom de domaine est précisé à droite du caractère « @ », une information manque apparemment quant à la machine susceptible de recevoir le mail.

Le lecteur en quête de plus de précisions trouvera une description exhaustive de la syntaxe d'une adresse au paragraphe 6 de la [RFC 822].

11-2. Format d'un « E-mail » - RFC 822

Les octets qui composent un courrier électronique obéissent à une structure bien définie par la [RFC 822] de David H. Crocker : un entête et un corps de message, séparés par une ligne blanche (deux CRLF(131) qui se suivent).

Le contenu de l'entête dans son intégralité n'est pas toujours spontanément montré par les outils qui nous permettent de lire et d'envoyer du courrier électronique. Une option est toujours accessible pour ce faire, comme « h » sous mutt(132).

Une partie de l'entête est générée automatiquement par le programme qui se charge du transfert (le paragraphe suivant nous dira qu'il s'agit d'un MTA), une autre est ajoutée par le programme qui permet de composer le mail, le MUA, une autre enfin est tapée par l'utilisateur lui-même.

L'entête est constitué de lignes construites sur le modèle :

  • identificateur : [ valeur ] CRLF

L'identificateur ne peut pas contenir le caractère « : » parce qu'il sert de séparateur avec la partie droite. Il est constitué de caractères ASCII codés sur 7 bits et imprimables (c'est-à-dire comprise dans le segment [33, 126]), excepté l'espace.

Valeur est optionnelle. L'usage des majuscules ou des minuscules est indifférencié.

Image non disponible
figure X.01 - Format d'un e-mail

L'ordre d'apparition de ces champs est quelconque. Seule l'organisation de la figure X.01 doit être globalement respectée. Le lecteur soucieux d'une description exhaustive de ce en quoi peut être constitué un entête pourra se reporter au paragraphe 4.1 de la RFC (SYNTAX).

Certains champs de l'entête proviennent de la configuration du MTA, d'autres sont créés en interne par le MTA lui-même, d'autres enfin sont gérés par le MUA, donc accessibles à l'utilisateur final.

11-2-1. Quelques champs couramment rencontrés dans les entêtes

Type d'information Noms des champs
Destinataire(s) du courrier To, Cc, Bcc
Origine du courrier From, Reply-To
Identification du courrier Message-ID
Cheminement du courrier Received, Priority
Nature du contenu Content-Transfer-Encoding, Content-Type
Divers Date, Subject
Champs étendus X-?
  • To (The primary recipients) : il s'agit du (des) destinataire(s) principaux du message (« recipient »). Ce champ peut éventuellement être vide, le MTA prend alors une décision paramétrable pour le compléter. La valeur undisclosed-recipient est courante dans ce cas.
  • Cc (Carbon copy) : ce champ est dans le fonctionnement un doublon de To, mais l'usage en nuance le sens, c'est une copie pour information qui est transmise au(x) destinataire(s) listé(s).
  • Bcc (Blind carbon copy) : une copie du message est transmise au(x) destinataire( s) listé(s), sans que les destinataires principaux des champs To et Cc en soient informés.
  • From (The sender) : il s'agit de l'émetteur du message. Le plus souvent il s'agit d'une seule personne, quand ce champ en liste plusieurs (le séparateur est la virgule « , ») le champ Sender doit préciser l'adresse de celui qui a effectivement envoyé le message.
  • Reply-To (Alternative reply address) : ce champ précise une adresse alternative à celle du champ From pour l'envoi de la réponse. Cette disposition est utilisée par les robots de gestion des mailing-list, pour distinguer l'auteur du message et le destinataire de la réponse.
  • Message-ID (Unique identifier for message) : ce champ est censé identifier de manière unique le message. Il est fabriqué dès sa soumission au premier MTA (MSA). Il est constitué traditionnellement de la manière suivante :
 
Sélectionnez
Message-ID: <20051104121857.GC44788@laissus.fr>
  • Received (Trace routing of mail) : c'est une trace du routage suivi par le message, depuis sa soumission jusqu'à sa délivrance finale. Chaque MTA ajoute un champ de ce type. Le cheminement est à suivre en commençant en fin de l'entête.
    Chaque champ est constitué au minimum de from, le nom canonique de la machine de qui le MTA a reçu le message, de by le nom canonique du MTA qui a reçu le message et ajouté ce champ et enfin de la date de la transaction. Exemple :
 
Sélectionnez
Received: from mailhost.sio.ecp.fr (mailhost.sio.ecp.fr [138.195.52.34])
by leopard.ecp.fr (Postfix) with ESMTP id A6C1D37C91
for <fr.laissus@laissus.fr>; Thu, 3 Nov 2005 13:56:58 +0100 (CET)
  • Priority (Determine timeouts in the queue) : en fonction d'une valeur qui est urgent, normal ou non-urgent les messages qui ne peuvent être délivrés immédiatement sont placés dans une file d'attente dont la date d'expiration est d'autant plus courte que le message est urgent. L'émetteur du message reçoit d'abord un avertissement puis une erreur si le message n'est pas délivré quand arrive la date d'expiration.
  • Content-Transfer-Encoding (Auxiliary MIME encoding) : indique comment est encodé le corps du message pour supporter les caractères hors jeu ASCII 7 bits (SMTP ne transporte que des caractères 7 bits). Des valeurs courantes sont base64, quoted-printable, 8bit....
  • Content-Type (The nature of the body of the message) : ce champ indique comment est constitué le corps du message. Par défaut il est supposé être constitué que de caractères 8 bits dont le bit de poids fort est sans signification (7 bits effectifs). Pour écrire les caractères accentués du français, par exemple, il faut avoir un champ de cette forme Content-Type: text/plain; charset=ISO-8859-1 Dans ce cas, le corps du message ne contient que du texte. Le cas contraire est celui d'un message qui contient des pièces jointes, une balise introduite en supplément dans l'entête va servir à séparer les différentes parties du message comme dans :
 
Sélectionnez
Content-Type: multipart/mixed; boundary="opJtzjQTFsWocga"

La chaine « opJtzjQTFsWocga » sert alors de marqueur pour repérer chaque partie du mail (corps du message et pièces jointes).

  • Date (The origin date) : c'est la date à laquelle le message a été envoyé initialement. Ce champ est obligatoire.
  • Subject (Topic of the message) : c'est une courte chaîne de caractères qui résume le message. Les MUA montrent ce champ pour permettre une meilleure sélection des messages avant de les lire.
  • MIME-Version (This message conforms to MIME standards) : niveau de MIME pour l'encodage du corps de message.
  • X-* C'est un entête spécifiquement ajouté par le MUA ou par un processus de la chaîne de traitement du courrier. Un exemple parmi tellement d'autres :
 
Sélectionnez
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2

Ajouté par un mécanisme extérieur au MTA, qui agit contre le spam, et nommé le Greylisting(133).

11-3. Protocole SMTP - RFC 821

Le protocole SMTP, ou « Simple Mail Transfer Protocol » a comme objet le transport du courrier électronique de manière fiable et efficace. Il est défini dans la [RFC 821] de Jonathan B. Postel.

Indépendant par sa conception d'un quelconque sous-système de transport, il est principalement aujourd'hui encapsulé dans des paquets TCP à destination du port 25 (cf. le fichier /etc/services). Dans un passé pas si lointain, l'accès réseau de beaucoup de sites se résumait au courrier électronique encapsulé dans des trames du protocole UUCP(134), donc sur liaison série via modem !

11-3-1. Protocole SMTP

SMTP est un protocole ASCII (7 bits, « human readable »). La partie cliente de la transaction se connecte sur le port 25 du serveur et envoie des commandes auxquelles le serveur répond par des codes numériques qui indiquent le statut de la prise en compte de la commande.

C'est pourquoi il est aisé de se connecter sur un MTA avec un simple telnet(135) :

 
Sélectionnez
$ telnet localhost 25
Connected to localhost.
Escape character is '^]'.
220 host.mondomain.fr ESMTP Sendmail 8.12.6; Mon, 20 Jan 2003 15:34:45 +0100 (CET)
NOOP
250 2.0.0 OK
QUIT
221 2.0.0 host.mondomain.fr closing connection
Connection closed by foreign host.

Dans cet exemple le MTA est le programme Sendmail(136), qui répond à la connexion par un code 220 pour dire que le service est opérationnel (« service ready »), suivi du nom de la machine, de la bannière du programme, de la version de sa configuration, et de sa date courante.

Puis l'utilisateur a tapé la commande NOOP qui n'a d'autre effet que de forcer le serveur à répondre et renvoyer un code (250) pour dire que tout va bien.

Enfin l'utilisateur a tapé QUIT pour finir proprement la transaction. La réponse du serveur est un code 221 pour signifier la fin canonique de la connexion.

Dans un deuxième essai nous utilisons l'option -v du programme mail, pour visualiser les échanges entre le MUA (machine athome.mondomain.fr) et le MTA local (machine mailhub.mondomain.fr).

Essayons :

 
Sélectionnez
$ sendmail -v user@mondomain.fr
Subject: test
Ca passe ?
. <<<--- A taper pour marquer la fin du mail dans ce mode.
EOT
user@mondomain.fr... Connecting to mailhub.mondomain.fr. via relay...
220 mailhub.mondomain.fr HP Sendmail (1.37.109.4/user-2.1) ready at Mon,
26 Jan 98 14:08:57 +0100
>>> HELO athome.mondomain.fr
250 mailhub.mondomain.fr Hello athome.mondomain.fr, pleased to meet you
>>> MAIL From:<user@mondomain.fr>
250 <user@mondomain.fr>... Sender ok
>>> RCPT To:<user@mondomain.fr>
250 <user@mondomain.fr>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 Ok
user@mondomain.fr... Sent (Ok)
Closing connection to mailhub.mondomain.fr.
>>> QUIT
221 mailhub.mondomain.fr closing connection

Et le courrier reçu, lu aussi avec mail :

 
Sélectionnez
Message 208/208 User Lambda Jan 26, 98 02:09:06 pm +0100
From user@mondomain.fr Mon Jan 26 14:09:08 1998
Received: from mailhub.mondomain.fr by athome.mondomain.fr with SMTP (8.8.7/8.8.7/f
la.2.1) id OAA27655; Mon, 26 Jan 1998 14:09:08 +0100 (CET)
Received: from athome.mondomain.fr by mailhub.mondomain.fr with SMTP (1.37.109.4/fl
a-2.1) id AA06996; Mon, 26 Jan 98 14:08:57 +0100
From: User Lambda <user@mondomain.fr>
Received: by athome.mondomain.fr
Date: Mon, 26 Jan 1998 14:09:06 +0100 (CET)
Message-Id: <199801261309.OAA27653@athome.mondomain.fr>
To: user@mondomain.fr
Subject: test
Ca passe ?

Manifestement, ça passe ! :)

Il est également intéressant d'observer à ce niveau que les caractères du courrier ont été considérablement enrichis par un entête volumineux (relativement).

En effet, chaque nœud traversé (MTA) ajoute un champ « Received » permettant après coup de suivre le trajet du courrier. Les autres champs comme Date :, Subject : ou Message-Id : sont ajoutés dans l'entête par le MUA de l'écrivain du message.

Cette partie de l'entête ajoutée par le MUA d'origine est souvent destinée à piloter le comportement du MUA du destinataire du message plus que pour être lue. Cette attitude s'est généralisée au point de devenir assez compliquée et être formalisée dans un ensemble de règles baptisées MIME comme « Multipurpose Internet Mail Extensions » ([RFC 2184]).

La fonction la plus répandue et la plus simple de MIME est d'autoriser l'usage des caractères accentués (codage sur 8 bits ou plus) à l'intérieur du corps du message (l'entête SMTP reste codé sur 7 bits). L'utilisateur voit alors apparaître des lignes supplémentaires comme celles-ci :

 
Sélectionnez
X-Mime-Autoconverted: from 8bit to quoted-printable by bidule.domain id SAA23150
X-MIME-Autoconverted: from quoted-printable to 8bit by mamachine.ici id QAA29283

Le « quoted-printable » est une forme possible du codage des caractères accentués, définie dans la [RFC 822]. Le plus souvent on trouve des lignes comme celles-ci :

 
Sélectionnez
Mime-version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfert-Encoding: quoted-printable
Content-ID: Content-ID: <Pine.FBSD.3.14.1592654.19971998X.domain>
Content-Description: arlg.c

D'autres formes de MIME peuvent conduire à l'exécution d'un programme extérieur au MUA, ce qui constitue une dangereuse faille potentielle dans la sécurité des réseaux, donc à éviter.

11-3-2. Principales commandes de SMTP

Expérimentalement nous avons découvert quelques-uns des mots réservés du protocole : HELO, MAIL, RCPT, DATA, QUIT. Une implémentation minimale de SMTP en comprend deux autres en plus : RSET et NOOP. C'est donc un protocole assez simple, du moins dans sa version de base.

Les codes de retour sont organisés sur trois chiffres, le premier chiffre donne le sens général de la réponse, très succinctement ce qui débute par 1,2 ou 3 a une signification positive, 4 ou 5 signifie une erreur. Une information plus détaillée se trouve à l'annexe E de la RFC.

Les cinq commandes découvertes précédemment s'utilisent toujours dans cet ordre. Examinons succinctement leur usage :

11-3-2-1. Commande HELO

Synopsis : HELO <espace> <domaine> <CRLF>

Cette commande est utilisée pour identifier l'émetteur du mail. L'argument qui suit, domain est le nom de la machine ou du domaine d'où provient la connexion.

En réponse le serveur envoie une bannière dans laquelle il s'identifie et donne la date courante. Cette information est optionnelle, ce qui compte c'est le code de retour pour confirmer l'aptitude au travail du serveur !

11-3-2-2. Commande MAIL

Synopsis : MAIL <espace> FROM : <chemin inverse> <CRLF>

Cette commande débute un transfert de mail. En argument sont transmis (chemin inverse) l'adresse e-mail de l'émetteur et la liste des machines qui ont relayé le mail courant. La première machine est la plus récente. Cette information est utilisée pour renvoyer, s'il y a lieu, une notification de problème à l'émetteur du mail.

Par exemple :

 
Sélectionnez
MAIL FROM:<@mailhub.ici:@mailhost.labas:Lambda@mondomain.fr>
11-3-2-3. Commande RCPT

Synopsis : RCPT <espace> TO : <destinataire> <CRLF>

Cette commande est la deuxième étape dans la procédure d'envoi d'un mail. Il y a une commande de ce type par destinataire du courrier (« recipient »).

Par exemple :

 
Sélectionnez
RCPT TO:<Lambda@mondomain.fr>

Il est intéressant de noter que les arguments de cette commande et ceux de la précédente (MAIL) forment l'enveloppe du mail (expéditeur et destinataire) comme nous en avons signalé l'existence conceptuelle.

11-3-2-4. Commande DATA

Synopsis : DATA <CRLF>

Après réception de la commande, le serveur lit les lignes de texte en provenance du client jusqu'à rencontrer la séquence <CRLF>.<CRLF> qui marque la fin du message. Il faut remarquer que celui-ci comprend l'intégralité de la figure X.01.

11-3-2-5. Commande QUIT

Synopsis : QUIT <CRLF>

Marque la fin de la session et entraîne la clôture de la connexion.

11-3-3. Propagation du courrier électronique

SMTP est défini comme un protocole de transfert, donc un moyen pour router et délivrer le message à son (ses) destinataire(s) final (finaux).

Image non disponible
figure X.02 - MUA - MSA - MTA - LDA - OS

MUA « Mail User Agent » ou encore « mailer »

  • C'est le programme qui permet de lire et écrire le corps du courrier et de paramétrer quelques éléments de l'entête, principalement l'adresse du destinataire, et le sujet du message. Il existe un très grand nombre de MUA sous Unix, il est courant de rencontrer mail, mailx, elm, pine, mutt, mh, eudora, kmail, thundermail, sylpheed... Il y en a pour tous les goûts !

MSA « Mail Submission Agent »

  • C'est une « nouveauté » définie par la [RFC 2476] et qui joue le rôle d'interface entre le MUA et le MTA. L'objet du MSA est de séparer les fonctions de transfert du courrier et d'acceptation de nouveaux courriers émis depuis les MUA. Cette séparation des tâches améliore deux aspects :
    • la sécurité, les nouveaux mails sont soumis à un daemon qui ne s'exécute pas avec les droits du root(137) ;
    • la conformité aux standards, les messages proviennent de MUA qui ne respectent pas forcément tous les prérequis de formulation des entêtes.
  • Le rôle du MSA est de vérifier et de compléter ces entêtes avant de soumettre les mails au MTA pour le routage.

MTA « Mail Transfer Agent »

  • C'est le programme qui prend en charge le transfert du courrier. Sous Unix c'est un daemon. Par exemple : MMDF, Smail, Zmailer, sendmail, postfix, qmail...
  • Les MTA écoutent le réseau sur le port 25 et dialoguent entre eux avec le protocole SMTP (ESMTP(138)).

LDA « Local Delivery Agent »

  • C'est l'entité qui délivre effectivement le mail, soit dans une boîte aux lettres, soit dans une base de données, par exemple une base Cyrus(139).

OS « Operating System »

  • Le système d'exploitation sur lequel fonctionnent ces programmes.

La figure X.2 illustre la possibilité la plus simple d'échange entre deux MTA : la connexion directe. Cela signifie que le MTA de la station émettrice contacte le MTA de la station réceptrice et lui délivre directement le message.

La vie « réelle » est plus compliquée, car elle tient compte de l'organisation hiérarchique des réseaux et surtout de la sécurité qui est un aspect devenu important sur l'Internet. Cela se traduit par un emploi généralisé de machines relais ou « mailhub ».

Image non disponible
figure X.03 - Trajet d'un mail

Une telle machine concentre tous les courriers électroniques d'un site, vers l'extérieur et inversement. Elle a des avantages, notamment :

  • avoir une politique de sécurité concentrée sur un petit nombre de machines exposées(140), plutôt que sur toutes les stations du réseau : le routeur filtrant n'autorise les accès extérieurs que sur le port smtp(25) de ces quelques machines dédiées ;
  • avoir une politique centralisée pour le filtrage des contenus indésirables (virus) et des émetteurs suspects (spams) ;
  • limiter le nombre de configurations compliquées de sendmail à un petit nombre de machines. Les stations des utilisateurs peuvent se contenter d'une configuration standard plus facile à distribuer et à adapter automatiquement ;
  • permettre de masquer plus facilement les machines internes du réseau vis-à-vis de l'extérieur. En clair, les courriers auront l'air de provenir de cette machine plutôt que de la station d'un utilisateur sur le réseau interne. L'adresse de l'émetteur aura la forme « user@domaine » au lieu de « user@machine.domaine » ;
  • permettre le stockage intermédiaire du courrier en attente d'une délivrance : les stations des utilisateurs ne sont pas toujours en fonctionnement.

Cette architecture est théorique, en pratique il peut y avoir une hiérarchie de « relay mail » plus compliquée. Par exemple une grappe de machines distinctes suivant que le courrier entre ou sort du site, une arborescence de machines relais quand l'entreprise est elle-même répartie sur plusieurs sites géographiques et ne possède qu'une liaison vers l'extérieur...

11-3-4. Courriers indésirables - Le spam

Le spam est l'aspect très désagréable du courrier électronique.

Par « spam » on désigne ces innombrables courriers, le plus souvent à caractère commercial, qui envahissent nos boîtes aux lettres électroniques. Certaines estimations tablent sur au moins 30 % de spam dans le trafic mail mondial et cette estimation est régulièrement revue à la hausse.

Deux questions se posent, comment le caractériser et surtout comment l'éviter ?

11-3-4-1. Caractériser le spam
  • Un contenu commercial, publicitaire, financier, ou qui tente de retenir l'attention du lecteur à partir d'une histoire dont l'issue est toujours pécuniaire et au détriment du destinataire.
  • Une importante liste de destinataires. Le champ Cc : peut contenir par exemple des centaines de destinataires.
  • Un entête de message truqué. Par exemple le champ Message-ID : qui est censé identifier le message de manière unique est absent ou incohérent.
  • Un grand nombre d'exemplaires du même message envoyé dans un court laps de temps. Cette caractéristique ne concerne pas le contenu du mail, mais la manière avec laquelle il est envoyé. C'est le MTA qui reçoit les demandes de connexions qui peut détecter cette caractéristique.
  • Utilisation de l'adresse d'un destinataire sans son consentement explicite pour ce type d'envoi.
  • Usage d'un site « open mail relay » pour l'émission. L'émetteur du mail peut alors usurper le nom du domaine d'émission. Pour mémoire, un site « open mail relay » autorise un RCPT qui ne désigne pas un destinataire pour lequel la délivrance des mails est autorisée sur ce site. Le site sert alors en quelque sorte de tremplin pour le mail, avec un effet de dissimulation du site émetteur véritable. Les versions modernes des MTA interdisent cette possibilité par défaut.
  • Champs To et From de l'entête invalides. Par exemple l'utilisation comme adresse e-mail d'origine du mail celle d'un utilisateur n'ayant strictement rien à voir avec le message (c'est l'enveloppe qui compte pour la délivrance du mail).
  • Le contenu du mail contient un virus, soit dans le corps du message, soit dans une pièce jointe. Par abus, ce genre de mail est parfois traité comme du spam.
11-3-4-2. Éviter le spam

C'est une question ouverte...

S'il est évident que l'œil humain reconnaît un tel courrier de manière quasi infaillible, il n'en est pas de même pour la machine.

Il n'existe pas de méthode de lutte unique et infaillible. Un bon résultat (plus de 99% du trafic de spam bloqué) peut cependant être atteint en passant par l'usage d'une palette d'outils et de dispositifs extérieurs. Toutefois l'ensemble de ce dispositif a un coût non négligeable en terme de cycles CPU consommés pour un mail délivré, d'une part, et d'autre part en termes de coût de maintenance, car l'architecture logicielle qui en découle est complexe et demande du temps de spécialiste de bon niveau pour sa maintenance.

Tout d'abord, une bonne partie de l'origine du spam vient du fait que le protocole SMTP lui-même est beaucoup trop permissif.

Conçu à une époque où le réseau était constitué sur la base de la confiance et de la collaboration entre sites honorables, il n'est plus adapté à ce qu'est devenu le réseau. La faille la plus navrante est que l'enveloppe transmise lors de l'échange protocolaire n'est pas nécessairement identique à ce qui figure dans l'entête du mail. L'exemple qui suit illustre cette faille :

 
Sélectionnez
telnet mailhost.mondomain.fr 25
Connected to mailhost.mondomain.fr.
Escape character is '^]'.
220 mailhost.mondomain.fr ESMTP
HELO UnSiteQuelconque.com
250 mailhost.mondomain.fr Hello UnSiteQuelconque.com, pleased to meet you
MAIL From:<>
250 2.1.0 <>... Sender ok
RCPT To:<lambda@mondomain.fr>
250 2.1.5 <lambda@mondomain.fr>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
From:<NePasRepondre@XXX.com>
To:<TuPeuxToujoursEssayer@YYY.com>
Unsollicited Bulk Email (UBE) or
Unsollicited Commercial Email (UCE).
.

Et le mail sera délivré dans la boîte aux lettres de l'utilisateur « lambda » avec des champs From : et To : complètement inexploitables !

Pour éviter la délivrance de ce mail, la configuration du MTA de mondomain.fr pourrait mettre en place une protection agissant en trois temps : lors de l'établissement de la connexion, lors de la réception de l'enveloppe puis à la réception du message lui-même.

Le protocole SMTP ne comprend pas d'accusé de réception. Si l'honnête utilisateur de ce protocole envoie un courrier routé silencieusement, par erreur, dans une boîte aux lettres de courriers indésirables (en général non lus et souvent supprimés automatiquement), c'est regrettable et d'autant plus préjudiciable que le contenu du mail est important. Il est donc bien plus efficace de refuser le message tant que la connexion avec le MTA qui l'émet est maintenue, car, quel que soit le contenu de l'enveloppe (les Reply-to et From sont peut être faux ou inexistants), le MTA qui route ce mail est à l'autre bout de la connexion et est supposé, par construction, être le mieux placé pour prévenir l'auteur du mail que la transaction actuelle est refusée.

Autrement dit, il est bien préférable d'effectuer le tri en temps réel plutôt qu'en temps différé lors de la délivrance dans la boîte de l'utilisateur ou après rapatriement des mails par son MUA.

Si l'origine du mail est honnête, l'émetteur sera tout de suite prévenu (mail d'erreur) et pourra agir en conséquence, dans le cas contraire le spammeur réceptionnera autant de messages d'erreurs que de spams envoyés (un rêve...) ce qui ne manquera pas de le gêner considérablement. Nous ne le plaindrons pas.

À l'établissement de la connexion, le MTA peut vérifier que le taux de demandes de connexions n'excède pas un certain ratio (par exemple pas plus de 30 connexions TCP par minutes).

  • Les éléments de la connexion fournissent l'adresse IP et le port d'origine.
  • L'adresse IP doit pouvoir être résolue dans le tld in-addr.arpa, le cas contraire est rédhibitoire.
  • L'adresse IP peut être tout simplement réfutée localement, tout comme le domaine (au sens du DNS).
  • L'adresse IP peut être également réfutée après interrogation des DNSBL (« Domain Name Services BlackList ») qui sont des bases de données de sites reconnus comme étant à l'origine de spams ou connus comme « open mail relay ».

À la réception de l'enveloppe le MTA peut demander une authentification de l'émetteur (login et mot de passe) du mail.

Le MTA peut également consulter une base locale de champs From et To refusés.

Il existe un mécanisme assez ingénieux et récent, nommé le « GreyListing(141) » qui stoppe bon nombre de spams en spéculant sur le fait que les spammeurs sont des gens pressés et que leurs mails sont envoyés en très grand nombre (des centaines de milliers d'unités) et le plus vite possible.

En conséquence, si l'établissement du protocole SMTP ne fonctionne pas du premier coup, la plupart d'entre eux se découragent et ne réessaient pas (contrairement à ce que le protocole SMTP prévoit).

Ce dispositif consiste donc à faire patienter tout le monde (sauf peut être une liste d'adresses de correspondants ou de domaines réputés fiables) et seuls ceux qui respectent le protocole à la lettre finissent par pouvoir transmettre leur mail, d'autant plus que s'ils ont patienté une fois ils sont placés dans une liste d'accès sans délai pendant un temps programmable (par exemple 24h). En pratique la connexion est coupée après émission d'un message d'erreur qui invite à recommencer ultérieurement.

À la réception du corps du mail, des filtres peuvent être appliqués sur l'entête pour en vérifier la consistance, sur le corps du message pour réagir sur la présence de tels ou tels mots clefs (de tels filtres ont en général un fonctionnement statistique basé sur l'apprentissage d'une base de spams et d'une base de non-spams et sont enrichis continuellement avec les messages indésirables) enfin les pièces jointes sont extraites du courrier et examinées à l'aide d'un dispositif de reconnaissance des virus (une base de virus doit être mise à jour très régulièrement).

11-4. Exemple de MTA - « Sendmail » et son environnement

11-4-1. Relations avec le DNS

Comme nous l'avons évoqué au paragraphe 1.2, la relation entre le MTA et le DNS est étroite. Sendmail a besoin du serveur de noms pour les opérations suivantes :

Image non disponible
figure X.04 - MX primaire et secondaire
  • Transformer le nom de la machine distante en adresse IP.
  • Canoniser le nom de la machine locale.
  • Canoniser le nom de la machine qui se connecte.
  • Déterminer quelles sont les machines susceptibles de recevoir du courrier pour le domaine à atteindre.

Le quatrième point est le plus crucial. Si le DNS du domaine à atteindre (une adresse est toujours mise sous la forme « nom@domain ») ne désigne pas de machine capable de recevoir le courrier, le mail ne passera jamais pour ce domaine.

Le champ RR (« Resource Record ») correspondant est du type MX (« Mail Exchanger »). Il spécifie une liste d'hôtes pondérés par des préférences, à qui on peut envoyer du courrier. La pondération indique l'ordre à suivre pour les tentatives de connexions : il faut commencer par la valeur la plus basse. Si cette liste est explorée de bout en bout sans succès il y a échec de la transmission du courrier.

S'il y a échec de la réémission, le mail est conservé un certain temps, puis est finalement rejeté s'il y a persistance de l'échec. Le résultat est matérialisé dans un fichier nommé dead.letter

Figure X.4, Le contenu du champ RR renvoyé par le DNS pourrait avoir la constitution suivante :

 
Sélectionnez
;
;[name] [ttl][class] MX preference mail exchanger
;
domaineD IN MX 10 machineA.domaineD
IN MX 20 machineB.domaineD
IN MX 30 machineC.domaineX

Il est important de remarquer qu'une machine baptisée « MX » par le DNS n'est pas forcément localisée dans le domaine pour lequel elle reçoit le courrier, c'est même souvent le cas pour les machines « relay ». C'est le cas de la troisième ligne, machineC.domaineX

11-4-2. Relations avec le système d'exploitation

Sendmail a de multiples relations avec le système d'exploitation. La figure X.5 en fait un résumé :

Image non disponible
figure X.05 - Relation entre Sendmail et le système d'exploitation

L'activité opérationnelle de sendmail est consignée à l'aide de syslog(142), ce qui explique la présence de la ligne suivante trouvée dans le fichier /etc/syslog.conf : mail.info /var/log/maillog

UUCP, X.400, SMTP, sont autant de moyens de propager le courrier. Ces supports peuvent cohabiter au sein d'une même configuration ; autant de « Mailer » sélectionnés en fonction de l'adresse du destinataire (cf. sendmail.cf).

/etc/mail/sendmail.cf est le fichier de configuration de sendmail qui fonctionne en tant que MTA. Sa présence est indispensable.

La configuration standard livrée est en générale à adapter aux impératifs de fonctionnement du réseau local. Voir à ce propos le paragraphe 5.

  • /etc/mail/submit.cf est le fichier de configuration de sendmail en tant que MSA. Sa présence est optionnelle si le fichier précédent indique explicitement le contraire.
  • /etc/mail/aliases est une base de synonymes. Quand sendmail reçoit un courrier, il tente de reconnaître le nom du destinataire dans cette base et si c'est le cas de lui appliquer la transformation prescrite.

Un certain nombre d'alias sont requis par la [RFC 1123], d'autres sont conseillés par la [RFC 2142]. Un court extrait dudit fichier :

 
Sélectionnez
# Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
postmaster: root
# Well-known aliases -- these should be filled in!
root: user
info: root
marketing: root
sales: root
support: root
www: webmaster
webmaster: root
...

Cela signifie par exemple que chaque fois qu'un courrier est envoyé au « postmaster » de ce site, sendmail transforme « postmaster » en « root », puis « root » en « user ». Si cette dernière chaîne ne fait pas l'objet d'une autre transformation par cette table, il s'agit d'un utilisateur de la machine courante.

L'entretien de la table des alias est de la responsabilité de l'administrateur de la machine. La table des alias d'un domaine est un fichier stratégique qu'il convient de mettre à jour soigneusement (droits d'accès, utilisateurs inexistants, boucles...).

À chaque changement dans cette table, l'administrateur doit fabriquer une table d'accès rapides (« hash table ») à l'aide de la commande « sendmail -bi » souvent liée à « newaliases ».

  • /etc/mail/access, c'est un fichier qui regroupe des autorisations spécifiques d'accès ou de rejet des mails entrants. Par exemple :
 
Sélectionnez
208 Courrier électronique
MonNouveauDomain.tld RELAY
Connect:microsoft.com REJECT

Acceptera de relayer tout mail pour le domaine MonDomain.tld, mais rejettera tout mail en provenance du domaine suivant.

  • /etc/mail/local-host-names, ce fichier collecte tous les noms sous lesquels la machine qui exécute le MTA est connue ce qui évite que celui-ci rejette le mail en refusant de le relayer.
  • /etc/mail/mailertable, un MTA peut accepter d'effectuer le routage du courrier pour un grand nombre de domaines. Ce fichier permet d'effectuer un routage en fonction du domaine, par exemple :
 
Sélectionnez
un.autre.domain.tld smtp:autre.machine.tld
mon.domain.a.moi local:
  • /etc/mail/virtusertable, ce fichier permet d'effectuer des réécritures d'adresses d'un domaine vers un autre domaine avec plus de possibilités d'expression que le fichier des alias. Par exemple :
 
Sélectionnez
@MonAncienDomaine.tld %1-old@MonNouveauDomaine.tld
webmaster@MonNouveauDomaine.tld wbm-new@AutreDomaine.tld

Dans la première ligne le %1 est remplacé dynamiquement par tout ce qui précède le @ de @MonAncienDomaine.tld ce qui permettra par exemple d'effectuer un tri au moment de la délivrance des messages, entre ceux envoyés pour le nouveau domaine et l'ancien.

  • /etc/mail/userdb, cette table, « User Database » permet au sendmail d'effectuer une traduction de chaîne sur les noms des utilisateurs pour les courriers sortants. Cette disposition permet de traduire un nom de login en « Prenom.Nom », donc d'avoir une adresse de retour de la forme « Prenom.Nom@domaine » ce qui fait toujours plus chic !
  • /var/spool/mqueue, dans ce répertoire sont stockés les mails en attente d'une délivrance. Il peuvent y rester plusieurs jours (c'est un paramètre de la configuration du sendmail), on peut visualiser cette file d'attente avec la commande mailq.

Si un grand nombre de courriers sont en attente, et ça peut être le cas pour les machines relais, la section du disque dur qui supporte cette partition (ici /var) doit faire l'objet d'un dimensionnement en conséquence, sous peine d'obliger sendmail à refuser les mails faute de place disque.

  • /var/mail/userX, chaque utilisateur de la machine locale (il peut ne pas y en avoir sur un serveur) a une boîte aux lettres (« mail box ») repérée comme un fichier ayant comme nom son login. Par exemple /var/spool/mail/root.

Ce fichier est mis à jour automatiquement par le MTA local en cas d'arrivée de courrier.

De même que pour le répertoire de file d'attente, le répertoire des boîtes aux lettres des utilisateurs doit faire l'objet d'une attention particulière de la part de l'administrateur ; la prolifération des « documents attachés » aux courriers électroniques est un fléau contre lequel il est difficile de se prémunir sauf à agrandir perpétuellement la taille de la partition /var... ! :(

  • ${HOME}/.forward, avant d'être finalement délivré dans la boîte aux lettres de l'utilisateur, sendmail lit le contenu de ce fichier, ${HOME} étant le répertoire racine des fichiers de l'utilisateur en question.

Le fichier .forward est la base personnelle d'alias pour chaque utilisateur, ça permet de renvoyer son courrier vers d'autres sites, voire aussi d'effectuer des transformations avant de stocker les mails (procmail).

Si le .forward contient la chaîne suivante : moi@ailleurs.tld, tous les courriers envoyés à ces utilisateurs sont renvoyés à l'adresse indiquée. Ou encore : "|exec /usr/local/bin/procmail" qui permet d'invoquer l'usage du programme procmail, celui-ci est un très puissant filtre qui permet de faire un tri des courriers électroniques avec des expressions régulières (indispensable pour gérer de multiples abonnements à des « mailing-lists »). Par exemple, avec la configuration virtusertable ci-dessus, pour forcer la délivrance des mails adressés à @MonAncienDomaine.tld dans un fichier spécial plutôt que la boîte par défaut, on pourrait écrire un fichier .procmailrc de configuration contenant les lignes suivantes :

 
Sélectionnez
:0 H:
* ^To[ :]+.*-old@MonNouveauDomaine.tld
${HOME}/Mail/Rougnes
  • Socket locale Sendmail peut communiquer avec des programmes extérieurs par le biais d'une socket locale (UNIX). Le dialogue est facilité par une bibliothèque nommée MILTER(143) liée à sendmail lors de sa compilation.

L'idée est qu'il est plus intéressant de refuser éventuellement un mail dès que les premiers éléments du protocole SMTP (ou ultérieurement en examinant le corps du message) sont connus, plutôt que d'attendre que la connexion soit close et que le mail soit délivré. De ce fait, l'émetteur, quel qu'il soit (honnête utilisateur ou spammeur) sera immédiatement prévenu que son mail est refusé et pourra agir en conséquence.

De nombreux outils sont capables de fonctionner avec sendmail et son interface MILTER, liste non exhaustive : MIMEDefang(144), Clamav(145), milter-greylist(146),...

  • Outil externe de délivrance, le message prêt à être délivré est confié par sendmail aux bons soins d'un programme extérieur. Si la délivrance s'effectue dans une boîte aux lettres Unix (un fichier au format mailbox qui porte comme nom le login de l'utilisateur et qui est situé généralement dans le répertoire /var/mail/), ce programme se nomme local.mail en standard. Il peut être remplacé par d'autres, notamment par le programme procmail déjà cité, si on souhaite effectuer un filtrage supplémentaire à ce niveau du traitement, par exemple pour mettre dans une boîte aux lettres spéciale les mails considérés comme étant du spam en laissant à l'utilisateur le soin de les détruire par lui-même.

Enfin on peut remarquer qu'aucun signal n'est prévu pour indiquer à sendmail qu'il faut relire son fichier de configuration, c'est voulu par le concepteur. Lors de la mise au point de ce fichier, il faut arrêter puis le relancer manuellement(147).

11-4-3. Le cas de POP

POP est l'acronyme de « Post Office Protocol », il permet l'accès à un serveur de courrier depuis des clients PC sous Windows, voire des stations Unix distantes, par exemple via ppp, qui ne sont pas configurés pour faire un trafic SMTP entrant. POP dans sa version 3 est défini par la [RFC 1939].

Image non disponible
figure X.06 - Le cas de POP

Les clients POP sont légion sur les PC et sur les stations de travail sous Unix. Pour celles-ci, citons : kmail(148), mh, pine, elm, mutt, gnus pour emacs, ou encore sylpheed et thunderbird. La liste n'est pas exhaustive, tant s'en faut.

POP est un protocole très simple qui fonctionne parfaitement, mais qui n'est pas dénué de défauts :

  • L'authentification (login/password) est bien souvent échangée en « clair » sur le réseau.
  • Sur l'architecture Unix, l'utilisateur doit avoir un compte sur la machine serveur (une base de données des utilisateurs est toutefois possible).
  • Les messages doivent être récupérés sur le poste client pour être manipulés (en POP3 un double peut rester sur le serveur).
  • La boîte aux lettres ne peut être consultée que par un seul client à la fois.

Ces points deviennent vite rédhibitoires quand le poste client doit accéder au serveur au travers d'un réseau non sûr, et surtout lorsque le détenteur de la boîte aux lettres veut consulter ses mails depuis des postes différents. Ce cas de figure est de plus la réalité de toute personne qui se déplace et souhaite un contact mail permanent avec ses correspondants.

C'est pourquoi d'autres solutions se sont développées et sont de plus en plus utilisées : les messageries accessibles via un browser web (webmail), donc qui utilisent comme support le protocole HTTP, ou un remplaçant du protocole POP, le protocole IMAP!

11-4-4. Le cas de IMAP

Bien que largement déployé que depuis quelques années, le protocole IMAP - « Internet Message Access Protocol » - a été développé à l'université de Stanford en 1986. C'est actuellement la version 4rev1 qui est utilisée, définie dans la [RFC 3501].

L'architecture présentée figure X.06 reste valable, pratiquement il suffit d'y remplacer le mot « POP » par « IMAP(149) » !

Les fonctionnalités sont plus riches et surtout pallient les inconvénients listés pour POP. En clair, les points négatifs listés pour POP sont tous réglés.

IMAP est conçu pour pouvoir accéder à ses boîtes aux lettres depuis de multiples machines, n'importe où sur le réseau, alors que POP est plus adapté à une machine unique.

Voici ses objectifs principaux :

  • Être compatible avec les standards, MIME par exemple.
  • Permettre l'accès et la gestion des mails depuis plus d'une machine.
  • Fournir un mode de fonctionnement en ligne et hors-ligne.
  • Supporter les accès concurrents aux mêmes boîtes aux lettres.
  • Être indépendant du stockage des mails (fichiers ou base de données, par exemple).

Un excellent comparatif des deux protocoles est accessible ici :

  • http://www.imap.org/papers/imap.vs.pop.brief.html

11-5. Configuration du Sendmail

Le programme sendmail s'appuie sur un ensemble de règles de réécriture (figure X.05) par défaut regroupées dans les fichiers /etc/mail/sendmail.cf et /etc/mail/submit.cf.

La plupart des cas de la vie courante se traitent sans avoir besoin de modifier manuellement ces deux fichiers. L'usage d'un jeu de macros M4(150) très complet et puissant suffit pour générer les configurations ci-dessus, après l'écriture d'un fichier de requêtes de quelques lignes. M4 génère ensuite les fichiers attendus à partir de ces requêtes, et d'un modèle (« template ») installé avec le programme sendmail.

Il faut noter qu'un certain nombre d'administrateurs système, formés à la « vieille école », aiment bien conserver la maîtrise totale de ce qu'ils produisent et préfèrent donc écrire eux-mêmes manuellement leurs règles, ces macros ne leur sont donc pas destinées !

11-5-1. Configuration à l'aide de M4

Le point d'entrée pour utiliser cet outil est une documentation livrée avec la distribution du programme sendmail et nommée :

  • <préfixe d'installation>/cf/README

Considérons la situation réseau de la figure X.07. Le courrier au départ de la station, soumis par exemple au MSA local, doit être routé systématiquement vers une machine nommée mailhub.mondomain.fr, et qui concentre tout le trafic local sortant, d'où d'ailleurs son nom de « mailhub ».

Celle-ci est censée savoir router le mail qu'elle reçoit, mais ce n'est pas notre préoccupation ici.

Image non disponible
figure X.07 - Concentration du mail sur un mailhub

Le fichier de configuration pour la station pourrait être :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
divert(0)
VERSIONID(?mondomain-fla-04-05-2005')dnl
OSTYPE(freebsd5)dnl
define(?confSMTP_LOGIN_MSG',?$j --- STATION LAMBDA --- $b')dnl
dnl
FEATURE(always_add_domain)dnl
MASQUERADE_AS(mondomaine.fr)dnl
FEATURE(allmasquerade)dnl
dnl
define(?MAIL_HUB',?smtp:mailhub.mondomain.fr.')dnl
define(?SMART_HOST',?smtp:mailhub.mondomain.fr.')dnl
dnl
MAILER(smtp)dnl

Et ce fichier (config.mc) est utilisé de cette manière :

 
Sélectionnez
1.
m4 m4/cf.m4 config.mc > sendmail.cf

Pour générer en final le fichier attendu, dont le nombre de lignes excède 1400 ! Il faut noter que le MSA se configure de manière similaire, à partir de son propre fichier de configuration.

  • Ligne 1, c'est la définition d'un canal de sortie pour M4 (cf. man m4).
  • Ligne 2, c'est une étiquette (« tag ») insérée dans le fichier généré et qui servira à l'identifier, par exemple avec la commande ident si l'étiquette est un identifiant de rcs ou cvs.

Remarque : dnl est un mot clef de M4, au même titre que divert, et qui signifie qu'on peut ignorer (discard) tous les caractères jusqu'au prochain retour à la ligne (nl).

  • Ligne 3, c'est un identifiant du système d'exploitation pour que M4 puisse faire les choix adaptés (choix des chemins standards par exemple).
  • Ligne 4, définition de la bannière de HELO du protocole SMTP. $j est une variable qui contient le nom canonique (FQDN) de la machine hôte. La bannière de HELO smtp de la station ressemblera à ça :
 
Sélectionnez
1.
220 stationYXZ.mondomain.fr ESMTP --- STATION LAMBDA --- (date du jour)
  • Ligne 6, ajout systématique du nom de domaine, même et surtout pour les courriers locaux (donc dans le domaine local par défaut).
  • Ligne 7 et 8, ces deux lignes entraînent la réécriture des adresses From de telle sorte qu'elles se présentent toujours sous la forme <untel@mondomain.fr> au lieu de leur forme par défaut <untel@station.mondomain.fr> qui est nuisible au retour du courrier, car la machine station.mondomain.fr n'est très vraisemblablement pas atteignable directement depuis le réseau global sur son port 25.
  • Ligne 10, tout le mail local doit être envoyé à la machine mailhub.mondomain.fr.
  • Ligne 11, tout le mail autre que local doit être envoyé à la machine mailhub.mondomain.fr.
  • Ligne 13, normalement inutile dans le cas présent (pas de « delivery » sur cette machine).

Pour conclure, sendmail comme tous les outils, évolue plusieurs fois par an. Si à chaque version il est nécessaire de reconstruire manuellement son fichier sendmail.cf, il est probable que votre emploi du temps va être sérieusement amputé d'un temps précieux... Mieux vaut avoir juste à taper « make » dans le bon répertoire pour reconstruire un fichier de configuration tout beau tout propre !

11-5-2. Configuration manuelle

Cette section est une extraction libre et incomplète du paragraphe 5 du document intitulé « Sendmail Installation and Operation Guide », disponible dans toute distribution de la V8. On peut également trouver ce document dans la section « System Manager's Manual » (SMM) des systèmes BSD(151).

Le fichier de configuration sendmail.cf est organisé comme une série de lignes, le premier caractère de chacune d'elles en précise le type. Une ligne vide ou qui débute par un # est ignorée (commentaire), une ligne qui débute par un espace ou une tabulation est la continuation de la précédente.

11-5-2-1. Règles de réécriture

Les règles de réécriture sont repérables comme ces lignes qui démarrent par un S (début d'un paquet de règles) ou un par un R (simple règle). Les paquets de règles (organisation d'ensemble figure X.7 ) ont comme but essentiel d'analyser puis de prendre les bonnes décisions en fonction des adresses trouvées dans l'entête. C'est une démarche purement formelle.

Ces règles utilisent une syntaxe dense qui rebute généralement les administrateurs.

Il faut imaginer qu'elles sont intégralement analysées chaque fois que le programme sendmail est invoqué, c'est-à-dire en gros pour chaque e-mail entrant ou sortant. Elles doivent donc être faciles à analyser, même par un CPU de modeste performance (ou très chargé, ce qui revient finalement au même).

L'ensemble fonctionne comme un système de production, c'est-à-dire qui consomme des règles lues séquentiellement et les applique à un jeu de données initiales, ici une ou plusieurs adresses électroniques.

La partie gauche (ou lhs(152)) sert de déclencheur (« pattern matching ») pour une règle.

La partie droite (ou rhs(153)) est déclenchée si le motif de la partie gauche est reconnu dans le flux de données. Le résultat produit, s'il existe, est réinjecté dans le système de production et ce jusqu'à épuisement des possibilités.

La figure X.7 donne un aperçu du fonctionnement de l'automate, les chiffres (0,1,2,3,4) sont autant de « ruleset », comprendre des paquets de règles qui sont regroupées ensembles parce qu'elles traitent d'un objectif commun.

Image non disponible
figure X.08 - Règles de réécriture

Les règles sont numérotées, le premier chiffre dit à quel paquet elles appartiennent.

  • Le paquet de règles 0 sert essentiellement à déterminer le « mailer » c'est-à-dire le moyen d'envoyer le courrier (SMTP, ESMTP, UUCP...).
  • Les paquets de règles 1 et 2 sont appliqués respectivement à l'entête des messages qui sortent (« send ») ou qui entrent (« receive »).
  • Le paquet de règles 3 est appliqué systématiquement à toutes les adresses.
  • Le paquet de règles 4 est appliqué à toutes les adresses dans le message, typiquement pour passer d'une forme interne à une forme externe.
  • Le paquet de règles 5, non représenté sur l'automate, sert à traiter les adresses locales après que les alias aient été appliqués.

Les paquets de règles sont repérés par la lettre S, qui en balise le nom, comme dans :

 
Sélectionnez
######################################
### Ruleset 0 -- Parse Address ###
######################################
Sparse=0

Quant aux règles, elles démarrent toutes avec la lettre R, comme dans :

 
Sélectionnez
R$* $: $>Parse0 $1 initial parsing
R<@> $#local $: <@> special case error msgs
R$* $: $>ParseLocal $1 handle local hacks
R$* $: $>Parse1 $1 final parsing

Deux remarques s'imposent :

  • 1. Chaque ligne forme une règle, sur le modèle :
 
Sélectionnez
Rlhs rhs commentaire
  • 2. Le séparateur de champ entre les trois parties de ces règles est la tabulation (une au minimum).

L'adresse postmaster@mondomain.fr, par exemple, quand elle se présente devant le paquet de règles 0 qui démarre ci-dessus, a été mise sous une forme canonique par d'autres règles appliquées préalablement (notamment dans la « ruleset 3 ») :

 
Sélectionnez
1.
postmaster < @ mondomain . fr . >

Le « pattern matching » va tenter de rapprocher cette suite de mots ou tokens de la partie gauche des règles (lhs) pour déterminer celles qui peuvent être déclenchées.

Dans la partie gauche $? s'applique à toute suite de tokens, même vide.

Donc la première ligne convient. La deuxième ne le pourrait pas, car la chaîne « postmaster » précède le caractère « < » et le « @ » est suivi de « mondomain . fr . ».

La troisième et la quatrième règle sont également déclenchables, mais présentement l'ordre d'apparition est également l'ordre de déclenchement, cette possibilité sera donc examinée éventuellement plus tard.

La partie droite de la première règle commence par $ : $>Parse0 ce qui signifie l'appel d'un autre paquet de règles que l'on pourra trouver plus loin dans le fichier sendmail.cf :

 
Sélectionnez
#
# Parse0 -- do initial syntax checking and eliminate local addresses.
# This should either return with the (possibly modified) input
# or return with a #error mailer. It should not return with a
# #mailer other than the #error mailer.
#
SParse0

Le $1 signifie que l'on ne transmet que le premier des tokens reconnus dans la partie gauche (« postmaster » dans l'exemple)...

11-5-2-2. Exemple de sortie de debug

Il est utile d'avoir ce schéma en tête quand on débogue les règles : avec l'option -bt de sendmail on peut suivre la progression de la transformation, règle par règle.

 
Sélectionnez
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 postmaster@mondomain.fr
rewrite: ruleset 3 input: postmaster @ mondomain . fr
rewrite: ruleset 96 input: postmaster < @ mondomain . fr >
rewrite: ruleset 96 returns: postmaster < @ mondomain . fr . >
rewrite: ruleset 3 returns: postmaster < @ mondomain . fr . >
rewrite: ruleset 0 input: postmaster < @ mondomain . fr . >
rewrite: ruleset 199 input: postmaster < @ mondomain . fr . >
rewrite: ruleset 199 returns: postmaster < @ mondomain . fr . >
rewrite: ruleset 98 input: postmaster < @ mondomain . fr . >
rewrite: ruleset 98 returns: postmaster < @ mondomain . fr . >
rewrite: ruleset 198 input: postmaster < @ mondomain . fr . >
rewrite: ruleset 90 input: < mondomain . fr > postmaster < @ mondomain . fr . >
rewrite: ruleset 90 input: mondomain . < fr > postmaster < @ mondomain . fr . >
rewrite: ruleset 90 returns: postmaster < @ mondomain . fr . >
rewrite: ruleset 90 returns: postmaster < @ mondomain . fr . >
rewrite: ruleset 95 input: < mailhub . mondomain . fr > postmaster < @ mondomain . fr . >
rewrite: ruleset 95 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . >
rewrite: ruleset 198 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . >
rewrite: ruleset 0 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . >
>

Plus en TP...

11-6. Bibliographie

Pour en savoir davantage, on pourra consulter « les bons auteurs » suivants :

  • Eric Allman- « Sendmail Installation and Operation Guide »-document au format PostScript jointe à toutes les distributions de la V8.xx.
  • Bryan Costales with Eric Allman & Neil Rickert - « Sendmail » - O'Reilly & Associates Inc. - 1994
  • « Installing and Administering ARPA Services » - Hewlett-Packard - 1991
  • Douglas E. Comer - « Internetworking with TCP/IP - Volume I » (chapter 19) - Prentice All - 1988
  • W. Richard Stevens - « TCP/IP Illustrated Volume I » (chapter 28) - Prentice All - 1994

Et pour en savoir encore plus...

  • RFC 821 « Simple Mail Transfer Protocol. » J. Postel. Aug-01-1982. (Format : TXT=124482 bytes) (Obsoletes RFC0788) (Also STD0010) (Status : STANDARD)
  • RFC 822 « Standard for the format of ARPA Internet text messages. » D. Crocker. Aug-13-1982. (Format : TXT=109200 bytes) (Obsoletes RFC0733) (Updated by RFC1123, RFC1138, RFC1148, RFC1327) (Also STD0011) (Status : STANDARD)
  • RFC 974 « Mail routing and the domain system. » C. Partridge. Jan-01- 1986. (Format : TXT=18581 bytes) (Status : STANDARD)
  • RFC 1123 « Requirements for Internet hosts - application and support. R.T. » Braden. Oct-01-1989. (Format : TXT=245503 bytes) (Updates RFC0822) (Updated by RFC2181) (Status : STANDARD)
  • RFC 1652 « SMTP Service Extension for 8bit-MIMEtransport. » Klensin, N. Freed, M. Rose, E. Stefferud & D. Crocker. July 1994. (Format : TXT=11842 bytes) (Obsoletes RFC1426) (Status : DRAFT STANDARD)
  • RFC 1939 « Post Office Protocol - Version 3. » J. Myers & M. Rose. May 1996. (Format : TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957) (Also STD0053) (Status : STANDARD)
  • RFC 2060 « Internet Message Access Protocol - Version 4rev1. » M. Crispin. December 1996. (Format : TXT=166513 bytes) (Obsoletes RFC1730) (Status : PROPOSED STANDARD)
  • RFC 2184 « MIME Parameter Value and Encoded Word Extensions : Character Sets, Languages, and Continuations. » N. Freed, K. Moore. August 1997. (Format : TXT=17635 bytes) (Updates RFC2045, RFC2047, RFC2183) (Status : PROPOSED STANDARD)
  • RFC 2476 « Message Submission. » R. Gellens, J. Klensin. December 1998. (Format : TXT=30050 bytes) (Status : PROPOSED STANDARD)
  • RFC 2821 « Simple Mail Transfer Protocol. » J. Klensin, Ed. April 2001. (Format : TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869) (Status : PROPOSED STANDARD)
  • RFC 2822 « Internet Message Format. » P. Resnick, Ed. April 2001. (Format : TXT=110695 bytes) (Obsoletes RFC0822) (Status : PROPOSED STANDARD)

précédentsommairesuivant
Un historique intéressant http://www.fnet.fr/history/
Version 8.13.5 en septembre 2005 - http://www.sendmail.org/
http://www.qmail.org/
http://postfix.eu.org/start.html
Terme francisé en « mèl », ou « courriel » pour les documents administratifs... ;-)
Il s'agit respectivement des caractères 13 et 10 de la table ASCII - cf. « man ascii ».
http://www.mutt.org/ - le MUA (Mail User Agent) préféré de l'auteur :-)
http://projects.puremagic.com/greylisting/whitepaper.html
http://fr.wikipedia.org/wiki/Unix_to_Unix_Copy_Protocol
Attention toutefois de ne pas abuser de cette pratique, car de nombreuses attaques de sites ont démarré par le passé à l'aide un détournement de sendmail. Les administrateurs réseau sont donc attentifs au trafic sur le port 25 ; il est préférable de réserver ce genre de tests uniquement sur son propre site.
http://www.sendmail.org/
SUID bit
Extented SMTP
http://asg.web.cmu.edu/cyrus/
Ce qui n'exclut pas bien entendu d'avoir une politique de sécurité pour le mail sur le réseau interne.
http://projects.puremagic.com/greylisting/whitepaper.html
Chapitre III du cours de programmation - éléments de serveurs.
http://www.milter.org
http://www.mimedefang.org/
http://www.clamav.net/
http://hcpnet.free.fr/milter-greylist/
Par exemple sur une machine NetBSD/FreeBSD en tapant /etc/rc.d/sendmail restart
De l'environnement de bureau KDE - http://www.kde.org/
Consultez http://www.imap.org/ pour plus d'informations.
Macro processeur bien connu dans le monde Unix.
pour FreeBSD, NetBSD ou OpenBSD ça se trouve dans le répertoire /usr/share/doc/smm/08.sendmailop/
« left hand side »
« right hand side »

Copyright © 2009 François Laissus. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.