Cours d'introduction à TCP/IP

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) ».

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 :

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].

• 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 :

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 :

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 :

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 :

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).

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) :

$ 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 :

$ 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 :

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 :

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 :

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.

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▲

11-3-2-2. Commande MAIL▲

MAIL FROM:<@mailhub.ici:@mailhost.labas:Lambda@mondomain.fr>

11-3-2-3. Commande RCPT▲

RCPT TO:<Lambda@mondomain.fr>

11-3-2-4. Commande DATA▲

11-3-2-5. Commande QUIT▲

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).

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 ».

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...

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▲

11-3-4-2. Éviter le spam▲

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).
.

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 :

• 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 :

;
;[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

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

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 :

# 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 :

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 :

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 :

@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 :

: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).

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].

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!

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

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.

Le fichier de configuration pour la station pourrait être :

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 :

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 :

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 !

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.

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▲

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 . >
>