Table des matières

1 La messagerie électronique 3I Émission et réception de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1. Pré-requis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42. Exim4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63. Relaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74. Livraison des messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

II Récupération des mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101. Protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102. Dovecot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

III Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2

Chapitre 1La messagerie électronique

Introduction

La messagerie éléctronique est devenue le système critique d’une entreprise puisque c’est le cœur detoutes communications entre employés.Le fonctionnement de ce service impactera directement sur l’activitéde votre compagnie et dès lors, vous devrez rééllement penser et préparer toute manipulation sur vos serveurs.

Si un service doit être favorisé (système de sauvegarde, sécurité, qualité de service, etc.), c’est celui-ci.Nous décrirons dans ce module les bases de l’administration d’un serveur de messagerie et nous accom-pagnerons ce cours par des recommandations.

Une messagerie est décomposée en au moins deux étapes significatives et indépendantes : l’envoi et laréception. Le nommage de ces deux activités est maladroit et abusif (car tout dépend si on parle de dialoguesentre serveurs ou d’un échange client vers serveur), mais reflète assez bien l’image qu’on peut avoir du sys-tème.

Avant d’entrer dans les détails, étudions la manière dont est délivré un message électronique provenantde joe@testme.fr vers foo@eof.eu.org.

L’utilisateur Joe, de l’entreprise testme envoie via son logiciel de messagerie (Mozilla Thunderbird parexemple) qui est un Mail User Agent (MUA ) un message électronique en passant par le serveur mail de sonentreprise. Pour la soumission de message, on utilise le Simple Mail Transfert Protocol (SMTP ) du client vers leserveur. Le serveur de mail est appelé un Mail Transfert Agent (MTA ), son rôle est de relayer les mailsou de les accepter s’ils sont destinés au domaine courant.

C’est donc ce que fait le serveur smtp de testme.fr, il doit transmettre le message de joe vers secretariat@eof.eu.org.Pour connaître l’adresse du serveur de mail du domaine eof.eu.org, le mta fait une requête DNS de type MXsur le domaine cible.

En réponse, il obtient la liste des serveurs de messagerie de eof.eu.org capables d’accepter les mailspour le domaine. L’échange entre ces deux serveurs (les deux MTA ) se fait via le protocole smtp. Le mtad’eof.eu.org sait que ce domaine est local, il ne lui reste plus qu’à délivrer son message dans la boîte auxlettre de l’utilisateur correspondant à secretariat@eof.eu.org.

C’est alors à l’utilisateur de se connecter à sa boîte aux lettres via le protocole IMAP ou POP3 et de récu-pérer ses mails. Nous détaillerons plus tard les différences entre ces deux protocoles.

3

I. Émission et réception de messages

I Émission et réception de messages

1. Pré-requis

a. Ressources DNS

Nous avons vu dans le module précédent (sr005 sur le protocole DNS) que les serveurs de messagerieétaient listés dans la zone du domaine via les enregistrements MX.

La configuration type pour un serveur Bind est :

$ttl 8640

testme.fr. IN SOA ns0.testme.fr. postmaster.testme.fr. (

2005050600

3600 ; refresh

3600 ; retry

60480 ; expire

8640 )

testme.fr. IN NS ns0.testme.fr.

testme.fr. IN NS ns0.monfai.fr.

testme.fr. IN MX 10 mx.testme.fr.

testme.fr. IN MX 20 mx1.monfai.net.

mx IN A 82.23.21.3

Pour le domaine testme.fr, nous avons déclaré deux serveurs mail (mx.testme.fr et mx1.monfai.net)avec une priorité respective de 10 et 20. Cela signifie que si le premier MX (mx.testme.fr) n’est plus dispo-nible, il faut se tourner vers mx1.monfai.net qui est un serveur de secours capable de délivrer les mailscorrectement aux utilisateurs ou de les garder dans sa file d’attente pour les émettre à nouveau dès que leserveur principal sera revenu.

Aujourd’hui, la mise en place de serveur de secours (appelé aussi MX secondaire) soulève quelques inter-rogations quant à son utilité. En effet, lorsqu’un domaine de messagerie n’est pas disponible (car un serveurest tombé en panne ou le service DNS délivre des informations incorrectes par exemple), le mta de l’émetteurest tenu de retenter l’envoi plusieurs fois avant de finalement abandonner et renvoyer un message d’erreur(un bounce, ou Delivery Status Notification) à l’émetteur.

Auparavant, les connexions à Internet étaient mauvaises et peu fiables donc on utilisait massivement lesserveurs de secours pour améliorer les choses. Mais ce temps est révolu pour les entreprises. De plus, avoir unserveur de secours implique l’administration d’un serveur en plus et l’hébergement de ce serveur dans unesalle réseau différente du MX principal (en cas de panne de la salle réseau). Les spammeurs ont bien comprisque la configuration des MX secondaires était souvent réduite au minimum, de fait, la protection contre le spams’en trouve fortement diminuée.

b. Serveur mail

Le choix du type de serveur mail à utiliser pour votre système est encore un sujet houleux dans la com-munauté. Ainsi, nous n’allons pas faire de prosélytisme et nous vous conseillons d’utiliser le mta que vous

4

I. Émission et réception de messages

connaissez le mieux. Dans ce cours, nous nous pencherons particulièrement sur Exim4 car c’est celui queconnaît le mieux l’auteur de ce cours.

Mais présentons tout de même les autres mta puisque vous allez les cotoyer sur Internet :

Sendmail est le doyen de tous les serveurs de messagerie et fût à une époque le plus répandu sur les réseauxgrâce à ses bonnes performances et une grande publicité par les universités. Malheureusement, il est égalementle plus connu pour son fichier de configuration compliqué pour une personne normalement constituée. Denombreuses failles de sécurité criblent malheureusement ce vénérable mta. La prochaine version, SendmailX, est actuellement en développement et représente un renouveau complet avec une syntaxe lisible et unearchitecture axée sur les performances et la sécurité. Beaucoup pensent que cette réorientation est arrivée troptard, en particulier car Sendmail X apporte peu à face à Postfix,

Postfix est développé par le célèbre spécialiste en sécurité Wietse Venema et a tout axé sur l’écriture d’unremplaçant performant et sécurisé de Sendmail. Objectif réussi puisque Postfix est devenu l’une des référencesgrâce à la qualité du programme et son architecture modulaire. Enfin il dipose de nombreuses fonctionnalitéset également d’une syntaxe « humaine »,

Exim4 Bien que plus discret face à ses concurrents, est très présent sur Internet, en particulier chez diversfournisseurs d’accès mais aussi dans de grandes universités. La chose la plus appréciable dans Exim4 est samodularité de configuration, il est ainsi possible de faire tout ce que l’on veut dès lors que l’on est prêt àretrousser ses manches. Même si la sécurité n’est pas aussi forte que sous Posftix, son auteur Philip Hazel s’estattaché à ne pas reproduire le passé de Sendmail. Dernier point et non des moindres, Exim est le seul mta a êtresous licence GPL, contrairement à qmail

Qmail est le fruit du travail de Dan Bernstein, également auteur de djbdns. Les remarques concernant djbdnss’appliquent également sur qmail : implémentation « personnelle » du protocole SMTP et licence non libre.

Microsoft Exchange est sûrement le serveur mail qui va vous causer le plus de soucis : ce serveur disposed’une pauvre implémentation du protocole SMTP et vous aurez souvent à retrousser vos manches pour com-prendre pourquoi votre mail n’a pas été délivré.

c. Fonctionnalités nécessaires

Le choix de vos serveurs doit faire intervenir à la fois votre préférence mais aussi vos besoins, certainesconfigurations sont plus facilement réalisables sur un mta plutôt qu’un autre. En plus du choix du mta, vousdevez également tenir compte du serveur pop ou imap que vous allez utiliser donc ne négligez pas votrechoix : tous les composants de votre service de messagerie devront pouvoir s’interfacer entre eux.

Exemple de besoin :

– Domaines virtuels– Utilisateurs virtuels– Quotas– Authentification via fichiers plats, base de données, annuaire, etc.– « Besoin d’ouverture » : le format de stockage des messages doit être standard (Maildir, mbox, etc.)– Filtrage du mail (Anti-virus, anti-spam, etc.)– Classement des mails (Sieve, Exim filters, procmail, etc.)

5

I. Émission et réception de messages

À l’heure actuelle, la solution la plus simple pour gérer des domaines et utilisateurs virtuels est l’utilisa-tion de vpopmail, qui est malheureusement énormément lié à qmail. Il semble néanmoins possible d’inter-facer ce composant avec Postfix.

Il est très important de poser tous ses besoins sur une feuille et d’examiner chaque logiciel pour voir s’ilest capable de les remplir. Par exemple, si vous utilisez la suite Cyrus, vous aurez le support des domainesvirtuels mais vous ne pourrez plus utiliser un autre serveur pour accéder aux mails, étant donné que lesmessages sont conservés dans un format spécial.

Nous ne détaillerons pas l’installation système de votre serveur de messagerie mais entamerons direc-tement sa configuration par le relaying : recevoir les messages des utilisateurs internes et les redistribuer surInternet ou en local.

2. Exim4

a. Architecture

Exim4 a été développé autour d’une architecture monolithique (c’est-à-dire qu’il n’y a qu’un seul grosprogramme qui tourne plutôt que plusieurs petits programmes avec des privilèges différents), son auteur Phi-lip Hazel avait pourtant essayé de le rendre modulaire de la même facon que Postfix mais cette séparationentrainait une forte duplication de codes pour gérer toutes les fonctionnalités disponibles.

Il faut tout de même relativiser : l’architecture monolithique du programme ne facilite pas une approchesécuritaire mais le logiciel est l’œuvre d’une seule personne en grande partie, le code est donc cohérent et tousles points critiques sont connus de son auteur.

Par le passé, il y a eu quelques vulnérabilités, mais elles n’étaient exploitables que dans une configurationextrêmement favorable et atypique. Cela-dit, si vous n’avez pas confiance en Exim4, vous pouvez renforcer lasécurité de votre système d’exploitation (protection de l’espace mémoire des processus, randomization, ACL,etc.) ou essayer un autre mta !

b. Configuration

Exim4 décompose sa configuration en six parties, la première est implicite et correspond à la déclarationde variables générables, les sections suivantes sont délimitées par une directive begin xxx.

Vous devez suivre l’ordre suivant :

begin acl

begin routers

begin transports

begin retry

begin rewrite

begin authenticators

Exim4, de base, se configure à l’aide d’un fichier texte1 ou si vous utilisez les paquets Debian et que vousavez activé l’option, vous pouvez éclater votre fichier de configuration en de multiples fichiers de configurationet répertoires. Cette division est faîte pour bien dissocier les sections, routeurs, transports, ou ACL.

1/etc/exim4/exim4.conf

6

I. Émission et réception de messages

3. Relaying

a. Configuration de base

Servir de relais signifie accepter les messages d’un client et tout faire pour le délivrer à bon port, si au-cune restriction n’est imposée, c’est la porte ouverte à toutes les malveillances : votre serveur peut servir derelais pour les spammeurs par exemple. En plus de votre amour propre, servir de relais va vous apporter denombreux problèmes, comme une consommation de bande passante énorme, une charge de vos serveurs demessagerie conséquente, une mauvaise publicité pour votre entreprise si cela venait à être relaté et surtout, vosadresses IP risquent de se retrouver dans des listes noires, vous empêchant d’envoyer des mails vers beaucoupde domaines : il est très facile d’y rentrer mais quasiment impossible d’en sortir !

Vous veillerez donc à configurer votre serveur pour limiter drastiquement l’accès à votre relais, la confi-guration la plus simple est de ne relayer que les messages provenant du réseau local.

Exim4 fournit un système d’ACL (contrôle d’accès) pour gérer ces limitations. L’ACL suivante permet dene relayer que les messages venant de votre réseau local ou de la machine elle-même (127.0.0.1).

accept hosts = 192.168.72.0/24 : 127.0.0.1

deny message = relay not permitted

Les ACLs sont lues séquentiellement jusqu’à ce qu’une règle accepte (accept) ou rejette (deny) le mes-sage. La dernière règle correspond en général à un deny afin de convenir à une politique de « Je bloque toutpar défaut et je n’ouvre que le nécessaire ».

Cette ACL convient lorsque vos utilisateurs souhaitent envoyer des mails depuis leurs postes de travail,mais elle s’avérera insuffisante s’ils veulent pouvoir émettre des messages depuis chez eux puisqu’ils aurontdes adresses IP inconnues. Autoriser certaines adresses ou plages IP n’est pas une solution viable et ne pourraqu’être sujet à des problèmes plus tard.

On ne doit plus se reposer sur la simple « authentification » par adresse IP mais utiliser un vrai systèmed’authentification basé sur un identifiant et mot de passe (ou utiliser des choses plus compliquées). Le proto-cole SMTP a donc évolué pour tenir compte de ces nouvelles problèmatiques et la RFC2554 définit le SMTPAUTH (SMTP Authentification).

Un autre système utilisé pour autoriser le relaying est de faire du POP-Before-SMTP, cela signifie qu’onautorise de relayer un message d’une adresse IP quelconque si celle-ci s’est authentifiée au serveur POP pré-cédemment. Cette technique est à éviter car elle montre beaucoup de faiblesses et reste une bidouille.

b. Authentification SMTP

Si vous n’utilisez pas d’utilisateurs virtuels (c’est-à-dire un compte UNIX correspond à un compte mail),il est très simple de configurer Exim pour réaliser du SMTP AUTH :

login:

driver = plaintext

public_name = LOGIN

server_prompts = Username:: : Password::

server_condition = ${if pam{$1:${sg{$2}{:}{::}}} \

{yes}{no} }

server_set_id = $1

7

I. Émission et réception de messages

La partie précédente est à placer dans la section Authentificator du fichier de configuration d’Exim. Cesdirectives ne sont que « le moteur », elles indiquent quelle méthode utiliser (LOGIN, de type plaintext) etcomment réaliser l’authentification via server_condition qui indique d’utiliser la fonction pam{}.

Si cela peut vous rassurer, la configuration associée aux méthodes d’authentifications est la partie la pluscomplexe dans vos fichiers de configuration puisqu’elles mélangent beaucoup de fonctionnalités d’Exim etvous devrez vous familiariser avec les accolades en grand nombre.

Maintenant que nous avons défini un moteur d’authentification, nous devons indiquer à Exim de propo-ser cette méthode aux clients lors de la connexion :

# dans la section principale du fichier de conf

# on propose à tout le monde le SMTP AUTH

auth_advertise_hosts = *

Dans l’exemple précédent, nous avons utilisé un mode d’authentification qui laisse passer les mots depasse en clair sur le réseau (contrairement à des mécanismes comme CRAM-MD5) donc on pourrait préférerlimiter l’utilisation de l’authentification si et seulement si le client est connecté via une liaison chiffrée. Si c’estle cas, alors la variable $tls_cipher contient l’algorithme de chiffrement utilisé, sinon il est vide.

# On ne propose l’authentification que si la liaison est chiffrée

# c’est-à-dire si la variable $tls_cipher n’est pas vide

auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}

Il ne reste plus qu’à modifier nos ACLs pour servir de relais pour les personnes qui ont réussi à s’authen-tifier ou des clients qui viennent de notre réseau local :

accept hosts = 192.168.72.0/24 : 127.0.0.1

accept authenticated = *

deny message = relay not permitted

c. Notes

Désormais, il n’est pas rare que les fournisseurs d’accès à Internet filtrent le port 25 en sortie de leursréseaux afin de vous obliger à passer par leurs serveurs SMTP. Ils appliquent cette politique pour limiter lesvirus ou vers qui tentent d’envoyer du spam sur Internet.

C’est pour cela qu’il est conseillé de mettre votre serveur SMTP à l’écoute sur le port 25 (classique) maiségalement sur le port 587 qui a été attribué pour le Message Submission Agent (RFC2476). Ainsi vos clientsfiltrés pourront toujours émettre leurs messages via ce port standardisé.

Cette configuration permet de bien différencier les flux de communication « serveur vers serveur » ou« client vers serveur » et d’améliorer votre politique de filtrage.

Maintenant que nous avons correctement reçu le message, il est nécessaire d’aiguiller le message pourqu’il arrive.

8

I. Émission et réception de messages

4. Livraison des messages

a. Routeurs et transports

Lorsqu’Exim doit décider où envoyer un message, il le fait passer dans chaque routeur jusqu’à ce qu’und’eux matche. Les paramètres de filtre peuvent être variés comme les adresses IP, taille du message, type deconnexion, adresses mail, etc. Toutes les variantes possibles sont à votre disposition et votre imaginations’ébouillantera devant le manuel d’Exim4.

Par exemple, si le domaine destinataire (la partie foo.org dans bar@foo.org) se trouve dans le fichierCONFDIR/to-not-relay-myself, alors, le routeur indique qu’il faut utiliser le transport remote_smtpavec en paramètre une route_list particulière qui route les messages comme nous le souhaitons.

not_relay_myself:

driver = manualroute

domains = lsearch;CONFDIR/to-not-relay-myself

transport = remote_smtp

route_list = * smtp.monfai.fr

Le routeur suivant est utilisé pour les mails à destination d’un domaine considéré comme local dontl’utilisateur existe (dans /etc/passwd par exemple) et qu’il ne soit pas root. Si cela est vrai, alors on appellele transport spool_file :

local_user:

driver = accept

domains = +local_domains

check_local_user

local_parts = ! root

transport = spool_file

La variable local_domain est une liste des domaines locaux pour laquelle nous sommes MX. Le nom dela variable importe peu pour Exim, elle doit juste être consistente avec tous vos routeurs et ACL.

Les routeurs sont lus dans l’ordre de votre fichier de configuration et le premier qui est sélectionné in-dique un transport à utiliser. Ce transport est le module qui va réellement délivrer le mail. La livraison peutêtre locale (écrire dans un fichier ou passer le message à un programme par exemple) ou bien distante (sile message est destiné à un domaine qui n’est pas le nôtre comme pour le relaying). Toutes les informationsnécessaires à la livraison sont gérées par le routeur : le transport ne fait qu’appliquer la configuration.

b. Transports possibles

Les transports ne sont appellés que par des routeurs, en conséquence, l’ordre dans le fichier de configu-ration n’est pas important.

Encore une fois, nous ne pouvons pas être exhaustifs sur les routeurs et transports tellement les possibi-lités sont nombreuses mais vous trouverez toutes les informations nécessaires dans le (volumineux) manuel.

Nous n’allons détailler que les transports les plus importants. Le premier est celui qui est appellé lors-qu’un message n’est pas à destination d’un domaine local et qu’il faut relayer : remote_smtp.

remote_smtp:

driver = smtp

9

II. Récupération des mails

Ici, peu de choses puisque tout a été pris en charge par le routeur qui a donné tous les paramètres delivraison. Voyons maintenant le transport pour une boîte aux lettres au format Maildir :

maildir_home:

driver = appendfile

directory = $home/Maildir

create_directory

delivery_date_add

envelope_to_add

return_path_add

maildir_format

mode = 0600

Exim délivrera le message dans le répertoire /̃Maildir/ (la variable $home étant évaluée en fonctionde l’utilisateur cible), créera le répertoire au format Maildir si nécessaire et le masque des nouveaux fichierssera 0600 (permission en lecture et écriture pour l’utilisateur).

Il est très fortement conseillé d’utiliser le format Maildir pour stocker les boîtes aux lettres de vos utili-sateurs ; Sa particularité est de stocker un mail par fichier contrairement à l’ancien format Mailbox (mbox) quimettait tous les mails dans le même fichier. Malheureusement, ce format pose de nombreux problèmes : il n’estpas possible d’avoir des performances honorables, il est quasi-impossible de gérer les accès concurrents à cefichier de manière sûre, enfin, jusqu’à quelques années, sa taille était limitée à la taille maximale d’un fichiersur les systèmes UNIX (exemple, 2 Go sur x86).

Son auteur n’est autre que Dan Bernstein, le fameux auteur de Qmail, ce format a sû remporter les plébis-cites de la majorité des administrateurs de messagerie car Maildir règle tous les problèmes d’accès concur-rents tout en étant très scalable : les répertoires de boîtes aux lettres peuvent contenir des centaines de milliersde messages sans aucun souci (modulo quelques optimisations du système de fichiers).

Maintenant que les messages ont été acheminés dans la boîte aux lettres du destinataire, c’est au tour desutilisateurs de lire leurs messages.

II Récupération des mails

À l’heure actuelle, deux méthodes se cotoient pour la récupération de mails bien qu’ils aient deux philo-sophies totalement différentes : le Post Office Protocol (POP) et l’Internet Message Access Protocol (IMAP).

1. Protocoles

a. POP3

POP3 est le protocole le plus ancien et également le plus rustique, son seul but est de permettre à l’utili-sateur de télécharger sa boîte de réception sans autre interaction. De fait, le protocole est relativement simpleet mal adapté à l’usage qu’en font les gens aujourd’hui. En effet auparavant, les fournisseurs d’accès (ou deservices) ne proposaient qu’un accès POP3 à leurs clients, or, ces derniers désiraient une solution leur permet-tant d’avoir accès à leurs mails depuis n’importe où. Ils laissaient alors, tant bien que mal, leurs messages surle serveur POP dans leur boîte de réception.

10

II. Récupération des mails

b. IMAP

Le protocole IMAP répond à ces besoins de nomadisme en proposant une multitude de fonctionnalitéscomplexes, ce fût une sorte de révolution lorsque les utilisateurs ont pû stocker, dans la limite de leurs quotas,tous leurs messages sur le serveur qui les maintenaient classés et avec les attributs donnés par les utilisateurs.

Derrière le rideau, l’inconvénient d’IMAP est justement sa complexité à cause de ses options et possibilités.Mais cela ne nous dérangera pas puisque ce sont les développeurs de serveur IMAP qui s’en sont chargés pournous ! Nous nous intéresserons à Dovecot2 car c’est un serveur réputé pour ses performances et sa sécurité.

2. Dovecot

a. Installation

Les nouvellesrelease candidates pour la 1.0 sont suffisamment stables et matures pour être mises en pro-duction, elles apportent de nouvelles fonctionnalités et dans certains cas, des performances supérieures. Parmiles améliorations, on trouve une plus grande souplesse dans les modules d’authentification : la mise en placede domaines ou utilisateurs virtuels est ainsi simplifiée par exemple.

Si votre serveur tourne sous Debian Stable, le backport de la version disponible en Unstable ou Testing esttrivial et ne nécessite qu’un dpkg-buildpackage.

b. Configuration

On se place dans le même cas que pour la configuration d’Exim : les adresses destinatrices des mails cor-respondent à des utilisateurs UNIX. Ainsi, nous n’avons pas à nous préoccuper du problème de permissions,UID, authentification, etc.

Ainsi, on peut limiter la configuration à ces quelques lignes :

protocols = imap imaps

## activer le chiffrement des flux

ssl_disable = no

ssl_cert_file = /etc/ssl/imap.cert

ssl_key_file = /etc/ssl/imap.key

ssl_parameters_file = /var/run/dovecot/ssl-parameters.dat

## répertoire où sont stocker les boîtes aux lettres

## - qui sont au format Maildir

## - qui sont dans le répertoire $HOME/Maildir de l’utilisateur

default_mail_env = maildir:~/Maildir

## utiliser l’authentification par la méthode IMAP PLAIN en utilisant

## la base de mot de passe PAM

login = imap

auth = default

auth_mechanisms = plain

auth_userdb = passwd

2http://dovecot.org

11

III. Conclusion

auth_passdb = pam

## utiliser les privilèges root pour faire l’authentification

auth_user = root

III Conclusion

Nous avons pu voir une solution simple mais concrète d’un serveur de messagerie dans une entreprise detype PME. Plus on monte en nombre d’utilisateurs, plus on préfère se dissocier du modèle d’authentificationUNIX : on préfère alors les utilisateurs virtuels. Pour cela, nous plaçons dans un fichier texte (ou dans une basede données relationnelle) toutes les informations nécessaires et demandons à Exim et Dovecot d’aller chercherdedans ce qu’ils souhaitent.

Cette solution, bien que plaisante à première vue, est un casse-tête pour réaliser de l’hébergement demasse car dès qu’on construit sa propre solution d’authentification, il est nécessaire d’adapter toutes les pro-cédures soi-même :changement de mot de passe, révocation de compte, renommage de compte, listes de dif-fusion, etc.

Cela représente beaucoup de détails à gérer et il n’existe pas à l’heure actuelle de solutions out-of-the-box,sauf, comme précisé en début de cours le module vpopmail (orienté qmail) qui répond à de nombreusesattentes d’utilisateurs.

Le but de ce module était de vous présenter la configuration d’un serveur de messagerie simple, maisfonctionnel, nous ne sommes donc pas entré dans tous les détails comme le chiffrement des communications,l’authentification par challenge-réponse, la gestion de MX secondaire, etc. Néanmoins, si vous vous posez en-core des questions, n’hésitez pas à me contacter.

12