Monter une architecture de messagerie électronique

Auteur et mainteneur : Marc FALZON

Contents

  1. Monter une architecture de messagerie électronique
    1. Introduction
    2. Logiciels utilisés
    3. On coule la dalle (configuration de l'OS)
      1. Contexte technique
      2. Réglages
    4. On monte les murs (configuration de Postfix)
    5. On pose le toit (configuration de Dovecot)
    6. On pose les portes (sécurisation des services et des connexions)
      1. Minimum serious, please
      2. Restrictions d'accès au service
      3. Chiffrement des connexions
      4. Blocage du spam
    7. On place les meubles (configuration du webmail)
    8. Conclusion
    9. Notes
    10. Références

Introduction

Autrefois réservée à une élite de barbus asociaux, l'administration système tend à se démocratiser à mesure que les tarifs pour les locations de serveurs dédiés baissent. Moyennent quelques dizaines d'euros par mois, le quidam peut souscrire à une offre dédiée chez un fournisseur d'hébergement Internet (pas fournisseur d'accès Internet, attention à la confusion) et se faire une installation comme il l'entend avec les services dont il a envie, configurés selon ses besoins. Nous allons voir dans ce document comment monter une plateforme de messagerie électronique multi-domaines (E-mail) à moindre coût en se basant exclusivement sur des logiciels libres. Au final, notre architecture sera capable d'envoyer et de recevoir des e-mails de plusieurs domaines, et ce en SMTP(S), POP3(S) et IMAP(S) avec une authentification SMTP-AUTH.

Cet article est destiné à des sysadmins confirmés : je considère que vous avez une bonne connaissance en administration système GNU/Linux ainsi que des protocoles que nous allons mettre en oeuvre ici (SMTP, POP3, IMAP, TCP/IP et DNS).

Logiciels utilisés

Dans un souci de fiabilité, de faible coût et surtout de liberté nous n'utiliserons que des logiciels libres. À noter également que le système d'exploitation utilisé pour réaliser cette documentation est GNU/Linux Debian 4.0 "Etch" (stable).

On coule la dalle (configuration de l'OS)

Contexte technique

Notre serveur de messagerie est connecté directement sur Internet et dispose donc d'une adresse IP publique. Pendant toute la durée des travaux, assurez-vous bien que l'accès à la machine ne soit pas entravé par un firewall (à moins de savoir ce que vous faites) : nous verrons plus tard comment le régler pour laisser passer les flux requis.

À titre d'exemple, nous allons utiliser les domaines legumes.org, yaourts.fr et fruits.net afin de simuler une activité multi-domaines.

Réglages

Avant d'attaquer le gros des travaux nous devons régler quelques détails sur l'OS sur lequel notre architecture va reposer. Voici les quelques paramètres à ajuster pour la bonne conduite de notre projet (à remplacer bien entendu par vos propres valeurs) :

De plus, les domaines pour lesquels nous serons déclarés MX (serveur de messagerie) doivent comporter un champ MX dans leurs informations de zone ; voici un exemple de configuration pour nos domaines d'exemple : 

fruits.net    IN     MX 10   pomme.fruits.net.
yaourts.fr    IN     MX 10   pomme.fruits.net.
legumes.org   IN     MX 10   pomme.fruits.net.

Un enregistrement MX doit désigner impérativement un nom d'hôte direct (non CNAME) et non une adresse IP ! (cf. RFC 1912, paragraphe 2.4)

Nous considérons que le système sur lequel nous basons notre architecture est fonctionnel et "propre" - idéalement, tout juste installé. Le plus important est qu'aucun autre MTA ne doit être déjà installé avant ou pendant, veillez à effacer tous ses fichiers de configuration si tel était le cas. Sur un système Debian le MTA Exim est installé de base : pour le supprimer, tapez la commande suivante(2) : 

root@pomme# aptitude remove --purge exim4 exim4-base exim4-config exim4-daemon-config

On monte les murs (configuration de Postfix)

Et c'est parti : on commence par installer le serveur SMTP Postfix à l'aide de la commande aptitude : 

root@pomme# aptitude install postfix

Ce paquet install au passage les dépendances openssl et ssl-certs ; le script de configuration post-installation du paquet postfix vous propose plusieurs configurations type : optez pour "Pas de configuration" afin de partir sur une base neutre, puis arrêtez le service lancé automatiquement par l'installeur : 

root@pomme# /etc/init.d/postfix stop

C'est maintenant que les choses se gâtent : il est l'heure de configurer Postfix. Bien que SMTP ne soit pas un protocole très complexe en soi, les MTA ont la fâcheuse tendance à être relativement difficiles à configurer et Postfix, bien que plus simple que le très redouté Sendmail ne fait pas exception à la règle.

La configuration que je vais vous proposer est volontairement simple - voire simpliste - mais a le mérite de fonctionner ; une fois que votre base sera fonctionnelle, vous aurez tout le loisir de rajouter des couches de restrictions et autres optimisations. Voici le contenu du fichier /etc/postfix/main.cf, fichier de configuration principal de Postfix :

/etc/postfix/main.cf 

  1. biff = no
  2. myhostname = pomme.fruits.net
  3. mydomain = fruits.net
  4. myorigin = $mydomain
  5. mydestination = $myhostname, localhost.$mydomain, localhost
  6. relayhost =
  7. mynetworks = 127.0.0.0/8
  8. inet_interfaces = all
  9. recipient_delimiter = +
 10. append_dot_mydomain = no
 11. alias_maps = hash:/etc/aliases
 12. alias_database = hash:/etc/aliases

Explications :

Les paramètres commençant par le signe $ (dollar) sont des variables remplacées en interne par la valeur du paramètre de même nom.

Exemple : écrire "myorigin = $myhostname" revient au même que "myorigin = pomme.fruits.net" car $myhostname vaut "pomme.fruits.net".

À ce stade de la configuration, notre serveur SMTP est en mesure d'envoyer des e-mails mais pas encore d'en réceptionner. Il manque en effet les directives permettant d'indiquer à Postfix où stocker le courier et surtout pour qui : c'est la configuration des comptes "virtuels". Ces lignes sont à ajouter à la suite des précédentes :

/etc/postfix/main.cf (suite) 

 1. virtual_uid_maps = static:5000
 2. virtual_gid_maps = static:5000
 3. virtual_mailbox_base = /var/spool/mail
 4. virtual_mailbox_domains = /etc/postfix/virtual/domains
 5. virtual_mailbox_maps = hash:/etc/postfix/virtual/boxes
 6. virtual_alias_maps = hash:/etc/postfix/virtual/aliases

Explications :

Nous pouvons à présent passer au contenu des fichiers définissant quels sont les noms de domaines que nous gérons, quelles seront les BAL de chacun de ses domaines ainsi que leurs alias. Dans un souci de clarté, nous créons un répertoire virtual/ où nous stockerons nos fichiers de définitions : 

root@pomme# mkdir /etc/postfix/virtual
root@pomme# cd /etc/postfix/virtual

À l'aide de votre éditeur de texte favori, nous éditons le fichier qui recensera les noms de domaines dont nous sommes destinataires. Voici le contenu du fichier /etc/postfix/virtual/domains pour notre contexte :

/etc/postfix/virtual/domains 

fruits.net
legumes.org
yaourts.fr

Jusqu'ici rien de bien méchant : un nom de domaine par ligne, et rien d'autre. Passons maintenant à la déclaration des BAL pour chaque domaine. Dégainez une fois de plus votre éditeur de texte et tirez sur le fichier /etc/postfix/virtual/boxes :

/etc/postfix/virtual/boxes 

marc@fruits.net            fruits.net/marc/
postmaster@legumes.org     legumes.org/postmaster/
contact@yaourts.fr         yaourts.fr/contact/

Voilà qui est déjà plus intéressant. Nous constatons que chaque ligne est composée de deux colonnes (deux "champs") : le premier champ est l'adresse e-mail et le second précise le répertoire où doivent être stockés sur le système les e-mails destinés à cette adresse. Ce chemin relatif est concaténé au chemin défini précédemment dans le fichier main.cf par la directive "virtual_mailbox_base" : pour la première ligne le chemin entier est donc /var/spool/mail/fruits.net/marc/, pour la deuxième /var/spool/mail/legumes.org/postmaster/ et ainsi de suite. Le slash final est très important : c'est grâce à cela que nous pourrons stocker les mails au format Maildir(4).

Notez au passage que nous avons opté pour une centralisation de toutes les BAL de chaque domaine dans un répertoire de même nom que le domaine. Avant de tester notre système, nous allons déclarer quelques alias dans le fichier /etc/postfix/virtual/aliases :

/etc/postfix/virtual/aliases 

postmaster@fruits.net        marc@fruits.net
patatemaster@legumes.org     postmaster@legumes.org

Ici nous venons de créer deux alias : postmaster@fruits.net qui est un alias de marc@fruits.net et patatemaster@legumes.org qui est un alias de postmaster@legumes.org. Notez au passage qu'il est possible de créer un alias qui pointe vers plusieurs adresses (les écrire les unes à la suite des autres, séparées uniquement par des virgules sans espaces), créant ainsi une liste de diffusion de fortune ; cette méthode a le mérite d'être extrêmement simple et rapide à mettre en place, toutefois il est recommandé d'utiliser des logiciels de gestion de listes de diffusions prévus à cet effet(5) pour des listes de tailles conséquentes.

Contrairement au fichier domains, nous avons une petite manipulation supplémentaire à faire pour boxes et aliases. En effet, dans le fichier de configuration main.cf le chemin vers ces deux fichiers est préfixé d'un hash: : ceci indique à postfix que ces fichiers sont hachés, c'est-à-dire rédigés sous une forme "clé/valeur" (les deux champs dont nous parlions précédemment). En interne, Postfix cherchera à lire non pas le fichier spécifié mais sa version binaire (suffixée d'une extension ".db") : pour hacher nos fichiers, nous devons utiliser la commande postmap comme suit : 

root@pomme# postmap /etc/postfix/virtual/aliases
root@pomme# postmap /etc/postfix/virtual/boxes

Nous hachons aussi au passage le fichier d'alias système : 

root@pomme# postalias /etc/aliases

Maintenant que nous avons déclaré quelques BAL et alias et générés les index des fichiers hachés, créons les répertoires des domaines dans le répertoire spécifié par la directive virtual_mailbox_base : 

root@pomme# cd /var/spool/mail
root@pomme# mkdir fruits.net legumes.org yaourts.fr
root@pomme# chmod 750 *
root@pomme# chown 5000:5000 *

Nous n'avons pas besoin de créer les répertoires des BAL, Postfix le fait automatiquement quand il reçoit un e-mail et que la BAL n'existe pas. Test de la configuration

Voici l'heure de vérité : il est temps de tester si notre configuration fonctionne. Pour ce faire, démarrons le service et envoyons un e-mail depuis la machine à l'adresse marc@fruits.net : 

root@pomme# etc/init.d/postfix start
root@pomme# echo "Ceci est un test" | mail -s "Mail de test" marc@fruits.net

Dans les logs du système (/var/log/mail.log), nous avons la confirmation de remise de l'e-mail que nous venons d'envoyer : 

Apr 26 15:58:45 pomme postfix/master[2902]: daemon started -- version 2.3.8, configuration /etc/postfix
Apr 26 17:16:06 pomme postfix/pickup[2904]: 4C27427BF4: uid=0 from=<root>
Apr 26 17:16:06 pomme postfix/cleanup[3001]: 4C27427BF4: message-id=<20070426151606.4C27427BF4@pomme.fruits.net>
Apr 26 17:16:06 pomme postfix/qmgr[2905]: 4C27427BF4: from=<root@fruits.net>, size=310, nrcpt=1 (queue active)
Apr 26 17:16:06 pomme postfix/virtual[3003]: 4C27427BF4: to=<marc@fruits.net>, relay=virtual, delay=0.17, 
        delays=0.13/0.01/0/0.03, dsn=2.0.0, status=sent (delivered to maildir)
Apr 26 17:16:06 pomme postfix/qmgr[2905]: 4C27427BF4: removed

En effet, si nous regardons dans le répertoire du domaine fruits.net nous voyons que la BAL de l'adresse marc@fruits.net a été créée automatiquement, et le mail que nous venons d'envoyer est bien présent : 

root@pomme# ls -l /var/spool/mail/fruits.net/
total 4
drwx------ 5 5000 5000 4096 2007-04-27 01:46 marc

root@pomme# cat /var/spool/mail/fruits.net/marc/new/1177631215.V801I17d0eM958472.pomme
Return-Path: <root@fruits.net>
X-Original-To: marc@fruits.net
Delivered-To: marc@fruits.net
Received: by pomme.fruits.net (Postfix, from userid 0)
id D921517D0B; Fri, 27 Apr 2007 01:46:55 +0200 (CEST)
To: marc@fruits.net
Subject: Mail de test
Message-Id: <20070426234655.D921517D0B@pomme.fruits.net>
Date: Fri, 27 Apr 2007 01:46:55 +0200 (CEST)
From: root@fruits.net (root)

Ceci est un test

Vous pouvez souffler, le plus dur est fait ;-)

On pose le toit (configuration de Dovecot)

Envoyer et recevoir des e-mails c'est bien, mais on aimerait bien pouvoir les lire de temps en temps. Nous allons maintenant installer et configurer Dovecot, le serveur POP3 et IMAP.

Toujours à l'aide de la commande aptitude, nous installons les paquets nécessaires : 

root@pomme# aptitude install dovecot-common dovecot-imapd dovecot-pop3d

Ces paquets installent également en dépendances les librairies nécessaires pour interfacer avec les bases de données MySQL, PostgreSQL et SQLite. Comme pour Postfix, assurons-nous que le service est bien arrêté pendant que nous le configurons : 

root@pomme# etc/init.d/dovecot stop

Par défaut, le fichier de configuration de Dovecot (/etc/dovecot/dovecot.conf) contient toutes les directives de configuration possibles, mais la plupart sont commentées et leur valeur fixée comme valeur par défaut (qui sont dans la plupart des cas appropriées). Voici une configuration minimale, mais fonctionnelle : 

  1. protocols = imap pop3
  2. disable_plaintext_auth = no
  3. mail_location = maildir:/var/mail/%d/%n
  4. log_timestamp = "%Y-%m-%d %H:%M:%S "
  5.
  6. protocol pop3 {
  7.      pop3_uidl_format = %08Xu%08Xv
  8. }
  9.
 10. auth default {
 11.      mechanisms = plain login
 12.
 13.      passdb passwd-file {
 14.           args = /etc/postfix/virtual/passwds
 15.      }
 16.
 17.      userdb static {
 18.           args = uid=5000 gid=5000 home=/var/mail/%d/%n/
 19.      }
 20. }

Explications :

Il nous faut maintenant déclarer les mots de passe protégeant l'accès aux BAL. Comme spécifié dans le fichier de configuration ci-dessus, nous plaçons notre fichier passwds avec les autres fichiers dans le répertoire /etc/postfix/virtual pour une question de cohérence.

L'utilitaire dovecotpw, fourni avec Dovecot, permet de générer des mots de passe. À l'instar des fichiers utilisés par Postfix, le fichier qui va contenir nos mots de passe se compose de lignes à la syntaxe simplissime ; dans l'exemple qui suit nous affectons le mot de passe "marc" à la BAL marc@fruits.net : 

root@pomme# cd /etc/postfix/virtual
root@pomme# echo "marc@fruits.net:`dovecotpw -p m0nP4s$`" > passwds
root@pomme# cat passwds 
marc@fruits.net:{HMAC-MD5}82d79042a587dc82256017754ddaff6d750b93bc6c64b48cca25f33880653bc2

Ici le séparateur de champs n'est pas l'espace (ou tabulation) mais le signe deux points (":") ; chaque ligne est composée au minimum de deux champs (6), le premier est l'adresse e-mail de la BAL et le second le mot de passe crypté (préfixé par l'algorithme utilisé pour le crypter entre deux accolades). Pour nous assurer du bon fonctionnement de notre serveur POP3/IMAP, essayons de lire notre e-mail précédemment envoyé en POP3 : 

marc@banane:~% telnet pomme.fruits.net 110
Trying 89.142.23.50...
Connected to pomme.fruits.net.
Escape character is '^]'.
+OK Dovecot ready.
user marc@fruits.net
+OK
pass m0nP4s$
+OK Logged in.
list
+OK 1 messages:
1 405
.
retr 1
+OK 405 octets
Return-Path: <root@fruits.net>
X-Original-To: marc@fruits.net
Delivered-To: marc@fruits.net
Received: by pomme.fruits.net (Postfix, from userid 0)
id D921517D0B; Fri, 27 Apr 2007 01:46:55 +0200 (CEST)
To: marc@fruits.net
Subject: Mail de test
Message-Id: <20070426234655.D921517D0B@pomme.fruits.net>
Date: Fri, 27 Apr 2007 01:46:55 +0200 (CEST)
From: root@fruits.net (root)

Ceci est un test
.
quit
+OK Logging out.

Tout est OK, nous pouvons désormais aussi consulter notre courier.

On pose les portes (sécurisation des services et des connexions)

Minimum serious, please

Avant de nous attaquer à des changement en profondeur nous pouvons commencer par le minimum syndical. Tout d'abord il est vivement recommandé de masquer les versions des logiciels que nous utilisons - voire les logiciels si c'est possible - afin d'empêcher les mauvais lutins préparant un complot contre notre rutilante architecture de messagerie de se renseigner sur des failles potentielles des services selon les versions.

Voici la directive à ajouter dans le main.cf de Postfix pour limiter la bannière à sa plus simple expression : 

smtpd_banner = $mydomain SMTP

Ainsi, notre serveur se présentera en tant que "pomme.fruits.net SMTP". Idem pour Dovecot, nous ajoutons au dovecot.conf la ligne suivante : 

 login_greeting = pomme.fruits.net POP3/IMAP

Aussi, nous réajustons les permissions sur les fichiers de configuration car ils contiennent des informations plus que sensibles : 

root@pomme# find /etc/dovecot -type f -exec chmod 600 {} \;
root@pomme# find /etc/postfix -type f -exec chmod 600 {} \;
root@pomme# chmod u+x /etc/postfix/postfix-script /etc/postfix/post-install

Restrictions d'accès au service

Nous pouvons mainenant envoyer et recevoir des e-mails, seulement un problème se pose : comment faire pour permettre à des utilisateur de se servir de notre serveur SMTP à distance (comprendre : sans se logger sur la machine) sans pour autant permettre à tout le monde de le faire (y compris les spammeurs) ? Notre machine était directement connectée sur Internet et nos utilisateurs légitimes pouvant se situer n'importe où dans le monde, ils peuvent avoir des adresses IP très diversifiées : il n'est donc pas envisageable d'autoriser uniquement une plage réseau à envoyer des e-mails via notre serveur.

La méthode pour laquelle j'ai opté s'appelle SMTP-AUTH. Nous partons du principe que nous n'autorisons l'envoi d'e-mails via notre serveur SMTP que pour nos utilisateurs, par conséquent ceux qui disposent d'au moins une BAL sur notre serveur. En pratique, nous allons faire en sorte que Postfix reconnaisse les utilisateurs du service POP3/IMAP en se servant directement du mécanisme d'authentification de Dovecot. Pour ce faire, nous ajoutons les lignes suivantes dans le fichier main.cf de Postfix : 

 1. smtpd_sasl_auth_enable = yes
 2. broken_sasl_auth_clients = yes
 3. smtpd_sasl_type = dovecot
 4. smtpd_sasl_path = private/auth
 5. smtpd_sasl_security_options = noanonymous
 6. smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Explications :

Il faut également ajouter quelques lignes de configuration dans le dovecot.conf de Dovecot (au sein de la section auth default { ... }) : 

 1. socket listen {
 2.      client listen {
 3.           path = /var/spool/postfix/private/auth
 4.           mode = 0660
 5.           user = postfix
 6.           group = postfix
 7.      }
 8. }

Redémarrez maintenant Dovecot puis Postfix : vous constatez qu'une nouvelle socket auth s'est ajoutée aux autres sockets de Postfix dans le répertoire /var/spool/postfix/private.

Explications :

Testons à présent notre configuration en situation réelle : 

marc@banane:~% telnet pomme.fruits.net 25
Trying 89.142.23.50
Connected to pomme.
Escape character is '^]'.
220 pomme.fruits.net ESMTP Postfix
helo esmtp
250 pomme.fruits.net
mail from: marc@fruits.net
250 2.1.0 Ok
rcpt to: postmaster@bouh.com
554 5.7.1 <postmaster@bouh.com>: Relay access denied

Ici nous constatons que les restrictions imposées à Postfix sont entrées en vigueur : lorsque l'on essaye d'envoyer un e-mail à une adresse extérieure à nos domaines sans avoir été authentifié notre tentative est rejetée. Essayons à present en nous authentifiant au préalable : 

auth plain AG1hcmNAZnJ1aXRzLm5ldABtYXJj
235 2.0.0 Authentication successful
mail from: marc@fruits.net
250 2.1.0 Ok
rcpt to: postmaster@bouh.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
coucou !
.
250 2.0.0 Ok: queued as 4998727C60
quit
221 2.0.0 Bye
Connection closed by foreign host.

La première instruction déclenche l'authentification SMTP-AUTH (ici en utilisant le mécanisme PLAIN, c'est-à-dire non chiffré(9)). Une fois authentifié(10), nous rententons d'envoyer un message à l'adresse extérieure : Postfix nous laisse maintenant faire.

Chiffrement des connexions

Si toutefois vous pensez qu'on vous espionne, que votre vie est en danger mais que vous n'avez pas trop envie de courir dans les rues de New York en peignoir poursuivi par des agents de la NSA, alors vous voudrez peut-être chiffrer les connexions SMTP, POP3 et IMAP entre les utilisateurs et le serveur. Voici les directives de configuration à ajouter dans le main.cf de Postfix pour activer le support de TLS au niveau SMTP : 

 1. smtpd_use_tls = yes
 2. smtpd_tls_security_level = may
 3. smtpd_tls_cert_file = /etc/ssl/certs/pomme.crt
 4. smtpd_tls_key_file = /etc/ssl/certs/pomme.key
 5. smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
 6. smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

Explications :

Au passage, notons qu'il est possible d'exiger que l'authentification des utilisateurs lors du SMTP-AUTH soit chiffrée par TLS ; il vous faut ajouter cette directive dans le même fichier de configuration : 

smtpd_tls_auth_only = yes

De même, nous ajoutons à Dovecot le support du POP3S et IMAPS à l'aide des directives suivantes dans le dovecot.conf : 

 1. ssl_cert_file = /etc/ssl/certs/pomme.crt
 2. ssl_key_file = /etc/ssl/certs/pomme.key

Explications : 

 * lignes 1 et 2 : localisation du certificat x509 et de sa clé privée sur le système ; il est tout à fait possible d'utiliser les mêmes que pour Postfix.

À cela il faut ajouter les mots clés pop3s et imaps à la directive procotols (cf. ligne 1 du listing au chapitre 5) pour que Dovecot supporte explicitement les protocoles POP3S et IMAPS : 

protocols = imap imaps pop3 pop3s

Il est possible d'interdire l'authentification d'utilisateurs par des méchanismes faisant transiter les mots de passe en clair (méthodes PLAIN et LOGIN notamment), ou plutôt de ne les autoriser qu'au sein d'une connexion TLS. Pour ce faire, il faut ajouter cette directive aux deux précédentes : 

disable_plaintext_auth = yes

Redémarrez une fois de plus Postfix et Dovecot : vous pouvez à présent accéder à votre serveur e-mail en SMTP(S), POP3(S) et IMAP(S) !

Blocage du spam

Pour tout sysadmin il est une association d'idée inévitable quand on parle d'e-mail : le spam. Fléau quasi impossible à éradiquer définitivement, difficile à juguler... Voici une méthode parmi d'autres, mais qui a à mon sens le meilleur rapport complexité de mise en oeuvre/rendement.

Notre protection antispam va consister à refuser tous les e-mails envoyés depuis un hôte présent sur une blacklist recensant les émetteurs de spam (type Spamhaus, SpamCop) ou dont la structure n'est pas conforme aux RFC (normes et protocoles standardisés internationalement) - signe distinctif de l'écrasante majorité des spammeurs. Grâce à une poignée de directives à ajouter au fichier de configuration main.cf de Postfix il est possible d'éliminer efficacement près de 95% du spam reçu : 

  1. smtpd_helo_required = yes
  2. disable_vrfy_command = yes
  3. smtpd_recipient_restrictions = permit_mynetworks
  4.           permit_sasl_authenticated
  5.           reject_unauth_destination
  6.           reject_unknown_recipient_domain
  7.           reject_unknown_sender_domain
  8.           reject_unknown_helo_hostname
  9.           reject_unknown_client_hostname
 10.           reject_unverified_recipient
 11.           reject_unverified_sender
 12.           reject_non_fqdn_recipient
 13.           reject_non_fqdn_sender
 14.           reject_non_fqdn_helo_hostname
 15.           reject_invalid_helo_hostname
 16.           reject_rbl_client list.dsbl.org
 17.           reject_rbl_client zen.spamhaus.org
 18.           reject_rbl_client l1.spews.dnsbl.sorbs.net
 19.           reject_rbl_client combined.njabl.org
 20.           reject_rbl_client bl.spamcop.net
 21.           reject_rhsbl_sender dsn.rfc-ignorant.org
 22.           reject_rhsbl_sender bogusmx.rfc-ignorant.org
 23.           reject_rhsbl_sender rhsbl.sorbs.net
 24.           reject_rhsbl_client dsn.rfc-ignorant.org
 25.           reject_rhsbl_client bogusmx.rfc-ignorant.org
 26.           reject_rhsbl_client rhsbl.sorbs.net

Explications :

Avec tout cela, les spammeurs seront bien (mal) reçus ;-) Mon serveur de messagerie tourne avec cette configuration, et depuis je ne reçois presque plus de spam tout en recevant toujours les e-mails "légitimes", même les plus commerciaux d'entre eux. Il est arrivé qu'un de mes utilisateurs se plaigne de ne pas recevoir des e-mails, après inspection des logs il s'est avéré que le serveur SMTP de l'université était blacklisté par http://rfc-ignorant.org...

On place les meubles (configuration du webmail)

Parce que nos utilisateurs peuvent être soumis à des contraintes diverses et variées (firewall d'entreprise, déplacements fréquents etc.) il peut être confortable de pouvoir accéder à ses e-mails via un webmail depuis un simple navigateur.

J'ai opté pour Squirrelmail, un webmail en PHP qui a fait ses preuves depuis plusieurs années et qui est activement maintenu par la communauté du logiciel libre. De plus, il est simple mais efficace. Pour l'utiliser, vous devez disposer d'un serveur HTTP et de PHP : ici nous utiliserons Apache comme serveur web. Afin de ne pas sortir du contexte de ce guide je considère que vous disposez d'une configuration HTTP/PHP fonctionnelle : nous ne verrons ici que la configuration du virtual host de notre webmail. 

root@pomme# aptitude install squirrelmail squirrelmail-locales gettext
root@pomme# /etc/init.d/apache2 stop

Opérant sur un serveur "vierge" ne disposant pas encore de serveur web, APT nous installe au passage les dépendances apache2-* et php4-* : si vous voulez utiliser PHP5 il vous faudra installer ce dernier avant Squirrelmail. Notez aussi que nous installons les locales de Squirrel pour disposer de la traduction française : il faut installer le paquet gettext car l'internationalisation est basée sur ce logiciel.

Le paquet squirrelmail fournit un utiliaire squirrelmail-configure faciliant la configuration du webmail, recommandé afin d'éviter toute erreur de le fichier de configuration. Passons maintenant à la configuration du vhost : il doit contenir au moins les lignes suivantes 

   1. <VirtualHost *>
   2.      ServerName mail.fruits.net
   3.      DocumentRoot /usr/share/squirrelmail
   4.
   5.      <Directory /usr/share/squirrelmail>
   6.           Options -Indexes FollowSymLinks MultiViews
   7.           AllowOverride All
   8.           Order allow,deny
   9.           allow from all
  10. </Directory>
  11. </VirtualHost>

Rien de bien insurmontable : on définit le FQDN du vhost à mail.fruits.net et on spécifie où sont localisés les fichiers de Squirrelmail (par défaut sur Debian, dans /usr/share/squirrelmail). Une fois le fichier édité, démarrez le serveur web Apache ; pensez à déclarer mail.fruits.net au niveau DNS (vers pomme.fruits.net ou directement sur l'adresse IP du servuer), soit chez votre registrar ou directement dans la zone si vous gérez le domaine vous-même.

Pointez maintenant votre navigateur sur http://mail.fruits.net/ : vous êtes redirigé vers la page de login de Squirrelmail. Entrez votre login (adresse e-mail entière) et mot de passe (défini au chapitre 5 dans le fichier passwds), et le tour est joué ! Vous pouvez là aussi ajouter une couche de chiffrement SSL/TLS si votre paranoïa vous le recommande, mais cela dépasse le cadre de cet article.

Conclusion

Si tout s'est passé comme prévu vous devriez à présent disposer d'une plateforme de messagerie simple, fonctionnelle, performante et surtout (relativement) sécurisée. Si vous jugez que vous recevez encore trop de spam vous pouvez passer au calibre supérieur et utiliser un filtre de contenu tel que Spamassassin et un antivirus. Personnellement, j'estime que la configuration proposée dans ce guide blinde suffisament le serveur contre le spam et que tout filtrage supplémentaire incombe aux utilisateurs.

Notes

Références

origamix.docs: ArchiMail (last edited 2008-10-21 13:08:25 by MarcFalzon)