Forums d'entraide informatique - Astuces - Conseils

Installer un serveur de
mail
Si vous êtes un habitué des applications mail comme celle incluse dans Netscape ou Mozilla, effacez tout ce qui concerne le principe de fonctionnement de votre mémoire. Avec un système de type Unix, la gestion du courrier électronique se divise en deux parties. Ceci est totalement occulté par les applications qui expédient directement un mail en contactant un serveur spécifique. Ici, vous devrez apprendre comment tout cela fonctionne pour mettre en oeuvre votre propre serveur.
Les deux parties dont nous venons de parler se répartissent la tâche de la gestion du courrier :
•    le MUA (Mail User Agent) est l'interface entre le système de messagerie et l'utilisateur. Il ne s'agit en réalité que d'un simple utilitaire permettant de lire les messages. Il existe bon nombre de MUA sous Linux. Les plus connus sont Mutt, Pine, ou encore le couple E,nacslGnus. Ces applications ne s'occupent absolument pas (en principe) de l'expédition et de la réception des messages. Elles ne font que présenter les données à l'utilisateur afin qu'il puisse les lire et les utiliser.
•    le MTA (Mail Transfer Agent) est l'application qui s'occupe de la livraison des messages. Le plus connu des MTA est sans le moindre doute Sendmail. Mais il n'est pas le seul et l'utilisateur pourra en choisir un qui correspondra le mieux à ses goûts : Postfix, Qmail ou encore Exim, qui est le MTA installé par défaut sur une distribution Debian. Le MTA se charge normalement de délivrer des messages localement (d'utilisateur à utilisateur d'un même hôte) et sur le réseau.
Le MTA est donc chargé, comme l'acronyme l'indique, du transport du courrier électronique. Lorsque cela se fait via un réseau, il utilise un protocole particulier : SMTP (Simple Mail Transfer Protocol). L'envoi d'un message d'une machine à une autre est une négociation entre le MTA local et celui distant via SMTP. En simplifiant grandement les choses, on peut dire alors qu'un message provenant de Mr X sur l'hôte machineX à destination de Mme Y sur l'hôte machineY est une expédition de fichier déclenchée par le MUA de Mr X via son MTA, vers la boîte de Mme Y via son MTA.
Pour en revenir aux applications que vous êtes censé oublier, elles incluent directement une gestion
du protocole SMTP. Ceci afin de contacter le serveur SMTP de votre fournisseur d'accès et lui demander d'envoyer votre courrier. Dans la même situation, le MUA Mutt vous permettra de formater votre message et de le passer à votre MTA local. Ce dernier contactera alors le serveur SMTP de votre fournisseur d'accès à Internet et lui demandera d'envoyer le message au destinataire.
Le routage
Le routage est la technique qui consiste à envoyer un message d'un destinataire local vers une autre machine. Le transfert de message ne se fait, en effet, pas à l'aveuglette. Le MTA local doit, avant toutes choses. déterminer en fonction de l'adresse du destinataire, quelle machine il doit contacter. Ceci peut paraître surprenant à première vue, puisqu'on considère généralement qu'une adresse moi@monsite.com informe implicitement qu'on souhaite contacter monsite.com et délivrer le message à moi. Mais ceci est impossible, monsite.com est un domaine et non une machine.
En réalité, un hôte spécifique doit être désigné comme responsable de la gestion de la messagerie pour un ou plusieurs domaine(s). Ceci se fait sous la forme d'un enregistrement DNS. Rappelez-vous les manipulations décrites dans le précédent hors série consacré à la mise en oeuvre d'un service HTTP. Nous avons, à ce moment, décrit l'utilisation d'un serveur DNS public permettant d'associer notre nom www.monsite.com à l'adresse IP de notre serveur. C'est également là que nous désignerons la machine chargée de la gestion du courrier électronique pour notre ou nos domaine(s).
Deux cas se présentent alors, tout comme dans le numéro précédent :

Vous avez une adresse IP fixe (merci Nerim) et dans ce cas, vous avez précédemment ajouté un champ "A" dans votre enregistrement DNS pour votre serveur Web. Il vous suffira donc d'ajouter un nouvel hôte nommé, par exemple, maiLmonsite.com. En fait, vous n'êtes absolument pas obligé de faire cela, mais l'ajout d'une machine mail.monsite.com facilite grandement la gestion des domaines. Autant avoir un peu d'ordre et faire cela proprement. De plus, dédier un nom de machine uniquement pour la messagerie vous permettra de l'utiliser pour tous vos domaines sans vous mélan- ger les crayons...
• Ou vous utilisez une adresse IP dynamique et faites usage d'un service comme dyndns.org. Dans ce cas, vous n'ajouterez aucune entrée "A" (surtout pas, d'ailleurs) ou "CNAME" (alias).
A présent, il vous suffit d'ajouter une entrée "MX", en d'autres termes ajouter un renseignement per- mettant de définir quelle machine gère la message- rie pour un domaine. Le DNS public de ZoneEdit utilise des pages de configuration relativement intuitives et la simple lecture du formulaire vous renseignera sur la manière de procéder. Allez sur wwwzoneedit.com, authentifiez-vous, entrez dans la configuration de votre domaine et utilisez l'onglet Mail Servers. On trouve ici un formulaire : [champ] handle mail pst] for domain [champ], ce qui donne en français [champ] gérer les mails en [premier] pour le domaine [champ]. Le premier champ est le nom de votre machine qui gère la messagerie (mail.monsite.com pour une adresse fixe ou votre nom de machine DynDNS en cas d'adresse IP dyna- mique). Le sélecteur central vous permet de définir une préférence si vous spécifiez plusieurs entrées "MX". Ne nous fatiguons pas ici ; de toutes manières, en principe, nous n'avons qu'un seul ser- veur. Enfin, le dernier champ vous permet de spéci- fier le domaine dont s'occupe votre machine SMTP. Il peut s'agir tout simplement du domaine en cours. Nous ne pousserons pas plus loin, mais sachez qu'une configuration DNS permet bien plus, comme la mise en place de WWw titi.monsite.com, perso.monsite.com, etc. et pour chaque domaine, il est possible de dési- gner un serveur de mail différent.
Ceci fait, voilà comment les choses vont se passer. Une personne, quelque part sur Internet, va vous envoyer un courrier électronique à moi@monsite.com. Son client mail va passer le mes-
sage à son serveur SMTP (ou celui de son fournis- seur d'accès). Ce dernier va consulter un serveur DNS pour déterminer quelle machine s'occupe de la gestion des messages pour monsite.com, il recevra maiiinonsite.com et l'adresse IP correspondante en guise de réponse. Enfin, il pourra contacter votre MTU via le protocole SMTP et lui passer le message. Note : En réalité, s'il n'y a pas d'entrée "MX" cor- respondant à un domaine, le MTA va essayer de contacter la machine dont !'IP est associée au domaine lui-même. Mais prudence est mère de sûre- té... Ne l'oubliez pas.
Votre serveur
Vous l'aurez compris, il faut que sur votre machine SMTP (mail.monsite.com par exemple) réside un MTA correctement configuré pour gérer les mes- sages. Nous traiterons ici du MTA exim installé par défaut sur la distribution que nous avons choisie comme support depuis le hors série précédent. Si vous utilisez une distribution différente, un package exim existe sans doute, mais il ne sera peut-être pas utilisé par défaut. Consultez alors la liste des pac- kages pour retirer le MTA actuel et installer exim. La configuration d'exim repose sur un fichier de configuration principal, habituellement /etc/exim/.conf OU /etc/exim/config. Quelle que soit votre distribution, vous pourrez trouver l'em- placement et le nom du fichier de configuration et vérifier par la même occasion la présence du MTA :
# exim -bP configure_file /etc/exim.conf
# exim -bV
Exim version 3.12 #1 built 03-Jan-2002 02:45:13 Copyright (c) University of Cambridge 1999
Ici, nous avons donc affaire à un exim 3.12 et devons éditer /etc/exim.conf. Afin de conserver une compatibilité avec tous les MUA, mais égale- ment les scripts shell ou Perl, et les utilitaires divers qui envoient des mails, un lien symbolique est créé entre /usr/sbin/exim et /usr/sbin/sendmail. Enfin, pour en finir avec la configuration globale du système, il faut savoir qu'exim peut fonctionner en standalone en tant que démon, ou être appelé par le super démon inetd dès qu'une connexion sur le port SMTP (25) arrive. Par défaut, c'est ce dernier mode de fonctionnement qui est utilisé sur une Debian. Il pourrait cependant vous être utile deInstaller un serveur de mail
choisir le mode démon en cas de charge importante sur le serveur. En effet, le démarrage d'exim par inetd prend un certain temps et le choix du mode démon dans ce cas améliorerait les performances de votre serveur étant donné qu'exim serait déjà présent en mémoire et n'aurait qu'à forker.
Voyons à présent ce qui se trouve dans le fichier de configuration par défaut. Nous nous pencherons ensuite sur les couples problème/solution au cas par cas.
qualify_domain monsite.com
permet d'ajouter le nom de domaine que vous avez déposé pour les messages envoyés depuis l'hôte local.
local_domains    localhost:egon:monsite.org
spécifie les noms de domaine pour lesquels exim gère le courrier. Dans le cas où cette configuration d'exim doit gérer les messages de plus d'un domaine. vous pouvez les spécifier tout en les séparant d'un double-point. Dans le cas où le nombre de domaines est très important, plutôt que de tous les spécifier ici, il est possible de les stocker dans un fichier de base de données. Pour cela, commencez par créer un fichier source contenant les noms de tous les domaines :
# fichier domain.lst
monsite.com
autresite.org
encoreunsite.net
Ensuite, utilisez exim_dbmbui 1 d pour créer le fichier database domains à partir de domain. lst : # exim_dbmbuild domain.lst domains
3 entries written
Dès lors, le fichier domains pourra être utilisé à la place des mentions des domaines dans le fichier de configuration. Il suffira d'utiliser la directive dbm suivie du chemin complet vers le fichier fraîchement créé :
local_domains    localhost:dbm;/etc/exim/domains
Un grand nombre d'options peuvent être configurées de la sorte dans le fichier de configuration. Dès que vous avez affaire à une liste, vous pouvez, en principe, utiliser un fichier database à la place en utilisant la même syntaxe.
local_domains_include_host    true
local_domains_include_host_literals    true
Accepte respectivement les mails à destination de votre nom d'hôte et de votre adresse IP.
host_accept_relay    localhost
Voici un paramètre très important. Il vous permet de spécifier de quelle machine notre serveur acceptera des messages à envoyer. Ici, seul le localhost est autorisé à demander des envois de mail ou plus exactement, il est le seul à bénéficier du relaying. Votre fournisseur d'accès, par exemple, autorisera le relaying pour tous ses clients ou, en d'autres termes, pour toutes les adresses IP qui font partie de son réseau.
Si votre serveur de courrier électronique fait également passerelle NAT pour partager votre connexion Internet avec un réseau local, vous pouvez tout naturellement autoriser les machines du LAN à utiliser votre serveur SMTP pour l'envoi de mails : soit le réseau local 192.168.0.0. Si vous désirez faire la manipulation, vous ajouterez alors ici : host_accept_relay locainost:192.168.0.0/24
Vous pouvez, comme ici. spécifier une plage d'adresses IP, mais vous pouvez également définir plusieurs IP ou noms d'hôte distincts. Encore une fois, ce qui peut être défini par une ligne de plusieurs éléments peut l'être à l'aide d'un fichier de base de données.
Attention ! Ne mettez JAMAIS un masque comme 0.0.0.0/0, même si cela vous semble une très bonne solution pour vous faciliter la maintenance. En effet, vous autoriseriez ainsi n'importe quelle machine à utiliser votre serveur SMTP. En faisant cela, votre serveur serait en open relay et il ne tarderait pas à crouler sous la charge tant des personnes peu scrupuleuses s'en serviraient pour inonder des utilisateurs de publicité. De plus, il faut savoir qu'un grand nombre de serveurs SMTP vont vérifier si votre machine est en open relay. Si c'est le cas, votre IP sera automatiquement ajouté dans une base de données mondiale, une liste noire de serveurs dont il ne faut pas accepter de messages.
smtp_verify = true
Ceci permet d'ajouter une compatibilité avec la commande VRFY utilisée par certains serveurs SMTP. Autant éviter les problèmes et rester compatible avec le plus grand nombre.
smtp_accept_queue_per_connection    100
Cette ligne permet de définir un nombre maximal d'entrées dans la file d'attente pour une connexion. Le mécanisme des files d'attente sera discuté un peu plus loin dans l'article.
freeze_tell_mailmaster    true
Ceci permet d'informer la personne responsable de la maintenance du serveur de mails (vous ?) qu'un message est gelé. Il existe un grand nombre de rai- sons pour lesquelles cela peut arriver, comme par exemple le fait que le SMTP destinataire ne répon- de pas. Dans ce cas précis, d'autres tentatives auront lieu avant l'abandon de la procédure et le retour du message à l'expéditeur. Cependant, un tel problème n'est pas forcément dû à une erreur sur l'hôte dis- tant et l'administrateur doit être tenu au courant afin qu'il corrige un éventuel problème local.
received_header_text    "Received: \
${if def:sender_rcvhost {from ${sender_rovhost}\n\t}\
{S{if def:sender_ident (from ${sender_ident} }}\
${if def:sender_helo_name ((helo.${sen- der_helo_name})\n\t))))\
by ${primary_hostname} \
S{if def:received_protocol {with ${recei- ved_protocol}}} \
(Exim ${version_number) #${compile_num- ber} (Debian))\n\t\
id ${message_id)\
${if def:received_for (\n\tfor <$recei- ved_for>))"
end
Ce gros bloc d'instructions permet de composer les champs Received des messages. Ceci n'est absolu- ment pas obligatoire, mais permet de connaître le chemin pris par le message. De plus. ceci étant placé par défaut dans le fichier de configuration, autant en profiter. Voici un exemple de champ Received dans un message reçu :
Received: from [193.252.208.11] (helo.egon) by www.lefinnois.net with esmtp (Exim 3.13 #1 (Debian))
id 16U3Z4-0006SD-00
for <lefinnois@lefinnois.net>; Fri, 25 Jan 2002 11:26:34 +0100
Received: from denis by egon with local (Exim 3.12 #1 (Debian))
id 16U3QW-0000nT-00
for <lefinnois@lefinnois.net›; Fri, 25 Jan 2002 11:17:44 +0100
Ce message a été reçu par egon (notre localhost) sur l'ordre de l'utilisateur denis à 11:17. De là, le
message est parti et a été ensuite reçu par www. lefinnois . net à 11:26. Il était destiné à l'uti- lisateur lefinnois du domaine lefinnois .net. Enfin, ce message reçu par www. lefinnois . net provenait de 193.252.208.11. Nous pouvons donc suivre le chemin emprunté par le message et, en cas de problème, vérifier chaque point de passage.
Nous allons maintenant aborder les trois points importants du mécanisme de livraison de courrier électronique tel qu'il est prévu dans exim. Le traite- ment du courrier se fait par le biais de trois pilotes différents : les Transports, les Directors et les routers. Le schéma en figure 1 montre l'organisation et la répartition des tâches entre les différents pilotes.
Les Transports
Un Transport est un pilote qui a pour tâche de transmettre un message d'une file d'attente vers un destinataire. Un Transport dans le fichier de configuration est défini par son nom suivi d'un double- point. Les lignes suivantes sont les directives du Transport en question jusqu'à la mention d'une nouvelle définition ou de l'instruction end. L'ordre d'apparition des Transports n'a aucune importance. Voici les Transports définis dans le fichier de configuration par défaut :
local_delivery:
driver appendfile
group = mail
mode = 0660
mode_fail_narrower    false
envelope_to_add true
file    /var/spool/mail/${1ocal_part}
Le Transport local_delivery définit la manière de délivrer un message à un utilisateur local. On utilise le pilote appendf i le intégré (built-in) dans exim pour ajouter le message dans le fichier de mail de l'utilisateur concerné (/var/spool /mail/ [uti- lisateur]).
address_pipe: driver pipe return_output
Ce Transport décrit la manière de traiter un tube (pipe) généré par un fichier de redirection personne (-/ forward) ou un alias (les alias seront vus plus loin dans l'article). address_pipe définit par défaut l'utilisation du pilote intégré pipe, et si la redirection génère une sortie sur stdout, le retour

aller un serveur de mail
du résultat à l'expéditeur. Nous pouvons facilement illustrer ceci en imaginant un utilisateur toto ayant placé dans son . forward une ligne :
"I /usr/bin/script.p1", toto
Cette ligne définit qu'un message arrivant à toto@monsi te . com sera "tuyauté" vers le script script . pl et envoyé en parallèle à l'utilisateur toto . Peu importe ici ce que fera script.p1,1a chose importante est de savoir qu'en utilisant return_output dans le Transport, tout ce qu'affichera (sur stdout) le script sera automatiquement renvoyé à l'expéditeur du message original. Ceci peut être très utile dans certains cas, pour que l'expéditeur puisse connaître le résultat de sa manipulation. En revanche, si le script est, par exemple, un système d'archivage ou autre, mieux vaut se passer de return_output en le mettant en commentaire (avec un #) et ajouter return_fail outputw ne renvoyant la sortie qu'en cas de problème.
Soyez très vigilant en ce qui concerne les scripts et autres programmes que vous allez écrire pour ce genre de chose. Il vous faudra faire extrêmement attention en ce qui concerne la sécurité et la fiabilité de vos créations. En "tuyautant" un message vers un tel script, vous risquez, en cas d'erreur de conception ou d'implémentation, de perdre des messages ou, pire encore, d'ouvrir des failles de sécurité dans votre système.
address_file:
driver = appendfile
Voici un Transport très simple puisqu'il est destiné à ajouter le message dans un fichier désigné par un alias ou . forward d'un utilisateur. address_directory:
driver appendfile
no_from_hack
prefix    ""
suffix    ""
Ce Transport applique le même principe que le précédent, à la différence qu'il concerne un répertoire et non un fichier désigné par un alias ou un . forward. Dans ce cas, chaque message sera placé dans un fichier spécifique dans le répertoire défini. Il est également possible de demander une organisation de type maildir. Il s'agit d'un format utilisé par certains clients mail pour organiser leurs messages. Pour ce faire, il vous suffira d'ajouter une ligne supplémentaire contenant maildir_format.
address_reply:
driver = autoreply
Le Transport address_reply est utilisé pour les réponses automatiques dans les procédures de filtrage de messages. En effet, exim dispose d'un mécanisme permettant d'analyser les différentes caractéristiques d'un message (en-tête, corps, taille. etc.) et de réagir en conséquence. Le mécanisme de filtrage peut, le cas échéant, être amené à répondre à l'expéditeur d'un message afin de l'informer de ce qui se passe (refus de livraison en raison d'une taille trop importante par exemple).
procmail_pipe:
driver = pipe
command = "/usr/bin/procmail -d ${1ocal_part}" return_path_add
delivery_date_add envelope_to_add check_string    "From
escape_string = ">From
user = $local_part group = mail
Ce Transport est défini pour le cas où vous souhaiteriez faire usage de procmail. Cet utilitaire est un MDA (Mail Delivery Agent) qui a pour but d'organiser, de trier et de "dispatcher" les messages en fonction de plusieurs critères dans des comptes ou des fichiers différents. Un bon exemple est le cas où vous vous inscrivez à plusieurs listes de diffusion sous une seule et même adresse et que vous souhaitez répartir les messages reçus dans différents fichiers en fonction de la liste dont ils proviennent. Si vous installez ce type de mécanisme utilisant procmail, vous devrez utiliser ce Transport afin de rediriger tous les messages vers le MDA. Sachez cependant qu'exim dispose d'un mécanisme de filtrage permettant de faire la même chose et surtout, que vous êtes en train de configurer votre propre serveur. En conséquence, vous pouvez à souhait créer des comptes pour chaque liste à laquelle vous vous abonnez.
remote_smtp: driver = smtp
Enfin, voici le dernier Transport défini par défaut. Il permet le traitement des redirections et des renvois de messages via SMTP. La définition des Transports se termine ensuite avec une ligne :