cm
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'huiXI1. 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 champs 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 boite 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 arrivent plus tard, si besoin est.
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.
cm
Pour un courrier électronique les besoins sont quasiment identiques !
cm
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 postale (Voir page ![[*]](crossref.png)
) puisse router et
finalement délivrer le courrier à son (ses) destinataire(s).
cm
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é `` sendmailXI2 ''. Il existe d'autres alternatives non abordées dans ce document, comme le programme `` qmailXI3 '' ou encore le programme `` postfixXI4 ''.
Tous les courriers électroniques ont un destinataire précisé par son adresse électronique, ou `` E-mailXI5 ''. Celle-ci précise le nom du destinataire et le site où il reçoit son courrier électronique.
Le nom du destinaire 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 boite 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 un 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 est 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ée 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].
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 en-tête et un corps de message, séparés par une ligne blanche (deux CRLFXI6 qui se suivent).
Le contenu de l'en-tê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 XI7.
Une partie de l'en-tê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'en-tête est constitué de lignes construites sur le modèle :
identificateur : [ valeur ] CRLF
L'identificateur ne peut pas contenir le caractère `` : '' parcequ'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é.
figure XI.01 -- Format d'un e-mail
L'ordre d'apparition de ces champs est quelconque. Seule l'organisation de la figure XI.01 doit être globalement respectée. Le lecteur soucieux d'une description exhaustive de ce en quoi peut être constitué un en-tête pourra se repporter au paragraphe 4.1 de la RFC (SYNTAX).
Certains champs de l'en-tête proviennent de la configuration du MTA, d'autres sont crées en interne par le MTA lui-même, d'autres enfin sont gérées par le MUA, donc accessible à l'utilisateur final.
2.1 Quelques champs couramment rencontrés dans les en-tê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-
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 :
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.
Des valeurs courantes sont base64, quoted-printable,
8bit,....
Pour écrire les caractères accentués du français, par exemplen
il faut avoir un champ de cette forme
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'en-tête va servir à séparer les
différentes parties du message comme dans :
La chaine ``
nombre_de_secondes.identificateur_de_queue@domaine
Exemple : Message-ID: <20051104121857.GC44788@laissus.fr>
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)
Content-Type: text/plain; charset=ISO-8859-1
Content-Type: multipart/mixed; boundary="opJtzjQTFsWocga"
opJtzjQTFsWocga '' sert alors de marqueur pour
repérer chaque partie du mail (corps du message et
pièces jointes).
).
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 GreylistingXI9
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 UUCPXI10, donc sur liaison série via modem !
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 telnetXI11 :
$ 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 XI12, 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
cm
Et le courrier reçu, lu aussi avec mail :
cm
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 !:)
cm
Il est également intéressant d'observer à ce niveau que les caractères du courrier ont été considérablement enrichis par un en-tê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'en-tête par le MUA de l'écrivain du message.
Cette partie de l'en-tê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'en-tête SMTP reste codée 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.
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 succintement 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édement s'utilisent toujours dans cet ordre. Examinons succintement leur usage :
Synopsis : HELO <espace> <domaine> <CRLF>
3.2.1 Commande HELO
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 !
Synopsis : MAIL <espace> FROM: <chemin inverse> <CRLF>
3.2.2 Commande MAIL
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.
cm
Par exemple :
cm
MAIL FROM:<@mailhub.ici:@mailhost.labas:Lambda@mondomain.fr>
Synopsis : RCPT <espace> TO: <destinataire> <CRLF>
3.2.3 Commande RCPT
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 '').
cm
Par exemple :
cm
RCPT TO:<Lambda@mondomain.fr>
cm
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
page .
Synopsis : DATA <CRLF>
3.2.4 Commande DATA
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 XI.01.
Synopsis : QUIT <CRLF>
3.2.5 Commande QUIT
Marque la fin de la session et entraine la clôture de la connexion.
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 final (finaux).
cm
figure XI.02 -- MUA - MSA - MTA - LDA - OS
Il existe un très grand nombre de MUAs 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 !
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 :
Le rôle du MSA est de vérifier et de complèter
ces en-têtes avant de soumettre les mails au MTA
pour le routage.
Les MTAs écoutent le réseau sur le port 25 et dialoguent
entre-eux avec le protocole SMTP (ESMTPXI14).
La figure XI.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 ''.
cm
figure XI.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 :
L'adresse de l'émetteur aura la forme :
user@domaine
au lieu de :
user@machine.domaine.
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,...
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 boites 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 ?
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.
Comme 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).
).
C'est une question ouverte...
S'il est évident que l'il humain reconnait 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 terme 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'en-tête du mail. L'exemple qui suit illustre cette faille :
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 boite 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 boite 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 boite de
l'utilisateur ou après rapatriement (voir
page ) 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.
Les éléments de la connexion (voir page
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 ''.
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
`` GreyListingXI17 ''
qui stoppe bon nombre de spams en spéculant sur le fait que les
spammeurs sont des gens pressés et que leur 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 procotole à 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.
)
fournissent l'adresse IP et le port d'origine.
4 Exemple de MTA - `` Sendmail '' et son environnement
Comme nous l'avons évoqué au paragraphe 1.2
page , la relation entre
le MTA et le DNS est étroite. Sendmail a besoin du serveur de noms
pour les opérations suivantes :
cm
figure XI.04 -- MX primaire et secondaires
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 XI.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
4.2 Relations avec le système d'exploitation
Sendmail a de multiples relations avec le système d'exploitation. La figure XI.5 en fait un résumé :
cm
figure XI.05 -- Relation entre Sendmail et le système d'exploitation
L'activité opérationnelle de sendmail est consignée à l'aide de
syslogXI18, ce qui explique la présence de la ligne
suivante trouvée dans le fichier /etc/syslog.conf :
mail.info /var/log/maillog
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
page
Un certain nombre d'alias sont requis par la [RFC 1123],
d'autres sont conseillés par la [RFC 2142].
Un court extrait du-dit fichier :
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
Acceptera de relayer tout mail pour le domaine MonDomain.tld
mais rejetera tout mail en provenance du domaine suivant.
Par exemple :
Dans la première ligne le
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.
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éaux contre lequel il est
difficile de se prémunir sauf à agrandir perpétuellement la
taille de la partition /var...!:(
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 :
Ou encore :
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 boite par défaut, on pourrait écrire un fichier
.procmailrc de configuration contenant les
lignes suivantes :
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 capable de fonctionner avec
sendmail et son interface MILTER, liste non
exhaustive : MIMEDefangXI20,
ClamavXI21,
milter-greylistXI22,...
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 boite aux lettres unix (un fichier au format
mailbox qui porte comme nom le login de l'utilisateur et 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 boite 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.
.
# 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 q'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.
`` sendmail -bi '' souvent
liée à `` newaliases ''
MonNouveauDomain.tld RELAY
Connect:microsoft.com REJECT
un.autre.domain.tld smtp:autre.machine.tld
mon.domain.a.moi local:
@MonAncienDomaine.tld %1-old@MonNouveauDomaine.tld
webmaster@MonNouveauDomaine.tld wbm-new@AutreDomaine.tld
%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.
moi@ailleurs.tld
Tous les courriers envoyé à cette utilisateurs sont renvoyés
à l'adresse indiquée.
"|exec /usr/local/bin/procmail"
:0 H:
* ^To[ :]+.*-old@MonNouveauDomaine.tld
${HOME}/Mail/Rougnes
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 manuellementXI23.
POP est l'acronyme de `` Post Office Protocol '', il permet l'accès à un serveur de courrier depuis des clients PC sous Windows, voire même des stations unix distantes, par exemple via ppp, qui ne sont pas configurées pour faire un trafic SMTP entrant. POP dans sa version 3 est défini par la [RFC 1939].
cm
figure XI.06 -- Le cas de POP
Les clients POP sont légions sur les PCs et sur les stations de travail sous Unix. Pour celles-ci citons : kmailXI24, mh, pine, elm, mutt, gnus pour emacs, ou encore sylpheed et thunderbird. La liste n'est pas exhaustive, loin s'en faut.
POP est un protocole très simple qui fonctionne parfaitement mais qui n'est pas dénué de défauts :
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 boite 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
(voir page ), ou un remplaçant du procole 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 XI.06 reste valable, pratiquement il suffit d'y remplacer le mot `` POP '' par `` IMAPXI25 '' !
Les fonctionnalités sont plus riches et surtout pallient aux 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 boites 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 :
Un excellent comparatif des deux protocoles est accessible ici :
Le programme sendmail s'appuie sur un ensemble de règles de
réécritures (figure XI.05 page ) 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 jeux de macros m4XI26 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 !
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 XI.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.
cm
figure XI.07 -- Concentration du mail sur un `` mailhub ''
Le fichier de configuration pour la station pourrait être :
![\framebox[14cm][l]{
\parbox[l]{14cm}{
\begin{center}
\includegraphics{config.mc.eps}
\end{center} }
}](img123.png)
m4 m4/cf.m4 config.mc > sendmail.cf
Pour générer en final le fichier attendu, dont le nombre de lignes excèdent 1400 ! Il faut noter que le MSA se configurent de manière similaire, à partir de son propre fichier de configuration.
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).
)) 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)
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 BSDXI27.
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.
Les règles de réécritures 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 XI.7 ont comme but essentiel d'analyser puis de prendre les bonnes décisions en fonction des adresses trouvées dans l'en-tê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 jeux de données initiales, ici une ou plusieurs adresses électroniques.
La partie gauche (ou lhsXI28) sert de déclencheur (`` pattern matching '') pour une règle.
La partie droite (ou rhsXI29) 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 reinjecté dans le système de production et ce jusqu'à épuisement des possibilités.
La figure XI.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 parcequ'elles traitent d'un objectif commun.
cm
figure XI.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'en-tê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 aliases aient été appliqués.
Les paquets de règles sont repérés par la lettre S, qui en balise le nom, comme dans :
###################################### ### Ruleset 0 -- Parse Address ### ###################################### Sparse=0
Quant aux règles, elles démarrent toutes avec la lettre R, comme dans :
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 :
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 (notament dans la `` ruleset 3 '') :
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 possiblité 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 :
# # 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)...
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.
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...
Pour en savoir davantage, on pourra consulter `` les bons auteurs '' suivants :
Et pour en savoir encore plus...
Next: XII Instrumentalisation de réseaux
Up: C Protocoles applicatifs
Previous: X Serveur de noms
Contents
Index
François Laissus
2009-02-27