Ce document décrit l'installation d'un serveur e-mail complet en utilisant les logiciels exposés dans le titre.
N'hésitez pas à me contacter pour d'éventuelle suggestions. Le document se base sur Debian GNU/Linux en version Lenny.
 
1° Introduction :
 
Ici vous trouverez rien de très essentiel (si ce n'est les quelques dernières lignes), c'est pour la forme quoi :-)
Pourquoi ce tutoriel est-il intéressant ?

Si vous cherchez sur le web des tutoriels de ce type qui font ce que je décrit, vous vous rendrez vite compte que tous (ou alors j'ai pas assez cherchez) vous obligent à recompiler vos logiciels. On ne trouve pas de tutoriel pour gérer des comptes virtuels (stockés dans MySQL) + gestion des quotas sans recompilation. Pourquoi c'est mal de compiler me direz vous ?

Disons que dans le pire des cas, vous installerez vos logiciel dans /usr/bin. Si vous faites cela, vous risquez d'entrer en conflit avec votre gestionnaire de paquet (écrasement de vos fichiers, ou bien le gestionnaire refusera d'installer certains autres logiciels. Dans tout les cas, ça risque de casser votre système). Dans un cas un peut moins mauvais, vous installez dans /usr/local/bin et là vous risquez des problèmes de PATH, donc des binaires qui ne seront pas trouvés. En plus, si vous compilez vous n'aurez jamais de support de mise à jour automatique (pour des problèmes de sécurités par exemple) qu'un gestionnaire de paquet peut vous permettre d'avoir (et donc vous risquez de casser les dépendances de votre application). Si malgré tout vous voulez quand même compiler vos paquets créer votre propre paquet qui au moins s'intégrera au gestionnaire de paquet existant. Mais dans tout les cas, utiliser les paquets de sa distribution, c'est plus simple et plus pratique que de recompiler systématiquement (comme beaucoup de tutoriels le propose).

De plus, la plupart du temps, vous utiliserez plus de logiciels que dans ce tutoriel, l'installation est donc plus complexe et cela consomme plus de ressource (on retrouve souvent amavis qui consomme une certaine quantité de mémoire). Dans notre cas, il y aura uniquement postfix, courier et Clamav qui tourne en permance (MySQL aussi forcément). Les comparatifs indiquent également que maildrop est plus performant que le célèbre procmail, de part la manière donc maildrop lit les emails avant de les placer dans la bonne mailbox (procmail charge complètement l'e-mail en mémoire ce qui peut-être peut performant avec de gros emails).

Ce que ce tutoriel n'abordera pas :

L'installation d'un webmail (comme webmail simple, roundcube est très bien). L'installation d'une interface web de gestion des emails (comme postfixadmin). L'amélioration de l'antispam (certaines techniques ne sont pas abordées : fuzzyocr, greylisting par exemple).

2° Installation des logiciels et fichiers nécessaires :
 
C'est assez simple, pour l'installation tapez :
apt-get install postfix postfix-mysql courier-authlib-mysql courier-pop courier-pop-ssl courier-imap clamav clamav-testfiles maildrop spamassassin razor pyzor
 
Tout les fichiers de configuration sont disponibles dans cette archive. Dans l'archive il y a un répertoire postfix :

Un répertoire postfix : les fichiers de configuration de postfix. Un répertoire courier : les fichiers de configuration de courier. Un répertoire local_bin : quelques outils à placer dans /usr/local/bin Un répertoire autre : La c'est surtout les fichiers maildroprc et quotawarnmsg qui sont intéressants (il y a aussi un exemple de config spamassasin + clamav). Les fichiers maildroprc et quotawarnmsg doivent être placé dans le répertoire /etc.

Ce qu'il faut customiser :

Les mots de passe d'accès à votre base de donnée (dans postfix, courier et les scripts php).

Le fichier main.cf pour utiliser votre nom de domaine et redéfinir la taille maximale d'un email (30mo dans le fichier de config). Le fichier /etc/quotawarnmsg pour mettre une adresse d'administrateur (au lieu de admin@example.com). Par défaut (dans de nombreux tutoriels), la limite fixée pour scanner un mail est de 26ko (dans maildroprc), cette taille est assez petite et je vous conseille de l'adapter à vos besoins (50 ko min). Peut-être d'autres choses en fonction de vos besoins.

Comme on peut le voire dans le fichier main.cf, il est prévu que l'utilisateur vmail possède l'uid 5000.
Pour ce faire, tapez :
 
useradd vmail -s /bin/false -u 5000
 
Dans la configuration de postfix, le répertoire contenant les mails est : /home/mail. Donc on le crée :
 
mkdir /home/mail && chown vmail:vmail /home/mail && chmod 700 /home/mail
 
On s'assure que les programmes de /usr/local/bin sont éxecutables :
 
chmod +x /usr/loca/bin/*
 
Normallement le répertoire /var/spool/vmail est utilisé pour stocker les e-mails des comptes virtuels. Pour que tout aille dans /home/mail, on peut taper :
 
rmdir /var/spool/vmail && ln -s /home/mail /var/spool/vmail
 
Dans le répertoire /home/mail la structure sera :

/home/mail/domain.tld /home/mail/domain.tld/mail_adr_prefix

Où mail_adr_prefix est un répertoire maildir.

On vérifie que les droits sont bons sur les fichiers de config de postfix, courier et les scripts php (car ils contiennent vos mots de passe MySQL) :
 
chmod 700 /usr/local/bin/* && chmod 600 /etc/postfix/mysql-* && chmod 600 /etc/courier/authmysqlrc chown vmail:vmail /usr/local/bin/maildrop_wrapper.php && chmod 655 /usr/local/bin/clamscan.sh
 
Remarque :

1° Pour utiliser les scripts php, vous aurez besoin de l'extension php5-cli

2° Dans le fichier /etc/courier/authmysqlrc on peut définir si les mots de passe sont chiffrés ou non (dans la base de donnée). Soit vous utilisez le champ MYSQL_CLEAR_PWFIELD (pour le mot de passe en claire), soit MYSQL_CRYPT_PWFIELD (pour le mot de passe chiffré avec la fonction ENCRYPT de MySQL). Les deux champs peuvent être utilisé simunltanément (selon la doc, je ne l'ai pas testé).

3° Création de la base de donnée :
 
Attention, selon le nombre de mailbox que vous utiliserez, il se peut que le nombre maximum de connexion pour MySQL par défaut (100) ne suffisent pas, dans ce cas il faut l'augmenter (à condition que le serveur suivent bien sur) dans le fichier my.cnf. Dans notre exemple, l'utilisateur MySQL se nomme postfix et la base de donnée se nomme postfix aussi. Je vous conseille de garder ces noms car ils sont utilisés à plein d'endroit et on oublie facilement d'en changer un (et du coup, ça marche pas). Il suffit d'éxecuter cette requête SQL :
 
CREATE TABLE `alias` ( `source` varchar(255) NOT NULL default '', `destination` varchar(255) NOT NULL, UNIQUE KEY `source` (`source`,`destination`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Alias Virtuels';
CREATE TABLE `domain` ( `domain` varchar(255) NOT NULL default '', PRIMARY KEY (`domain`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Domaines Virtuels';
CREATE TABLE `mailbox` ( `email` varchar(255) NOT NULL default '', `login` varchar(255) NOT NULL default '', `password` varchar(255) NOT NULL default '', `quota` varchar(20) NOT NULL default '0' COMMENT 'Quota in MBytes, 0 = no quota', `imap` tinyint(1) NOT NULL default '1', `pop3` tinyint(1) NOT NULL default '1', PRIMARY KEY (`email`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Boites Emails Virtuelles';
 
Quelques remarques :

1° La première étape pour gérer un domaine consiste à insérer le domaine en question dans la table domain (sinon postfix refusera de prendre le mail).

2° Dans mailbox, le champ imap et pop3 permettent d'activer (1) ou de désactiver (0) ces fonctionnalités.

3° Dans mailbox, le champ quota expriment un quota en megabytes (0 pour illimité).

4° Configuration de maildrop :
 
C'est là que je suis plus ou moins sorti des chantiers batus (ou parti en free style, prenez votre expression préférée) avec le script php. Le problème de base :

Dans postfix, quand on veut passer par un MDA comme maildrop, on peut utiliser les arguments suivants : En gros il y a l'expéditeur du mail, le destinataire, le domaine du destinataire et le préfixe et de l'adresse email du destinataire. Avec ces champs là et ma structure (dans laquelle le login n'a potentiellement rien à voire avec l'adresse email), je ne sais pas utiliser l'argument -d de maildrop. Si vous regardez le fichier master.cf, maildrop attend un argument -d précisant le login de l'utilisateur (le destinataire du mail). Étant donné que je ne sais pas fournir ce champ (le login) et que la relation destinataire (email) et login est unique, on peut écrire un wrapper.

Ce que le wrapper fait :

Il prend comme paramètre le destinataire et regarde quel(s) utilisateur(s) doivent recevoir le mail. Il fait cela en gérant les alias, on peut utiliser plusieurs niveaux d'alias mais il faut savoir que cela impactera les performances (car pour définir l'utilisateur final il y aura plus de requête SQL). Le mail peut très bien être délivré dans plusieurs boites mails (par exemple si l'alias info@example.com pointe vers test1@example.com et test2@example.com les deux mailbox recevront l'email). Dans la fonction deliver, on voit à un moment l'option -w 90 (ligne 49). Cela veut dire qu'on demande à maildrop d'envoyer un warning à l'utilisateur si il utilise 90 % de son quota. Ce warning sera répété toute les 24 heures tant que la mailbox sera utilisée à plus de 90%. Postfix envoie les mails via l'entrée standard du programme, si il n'y a que un destinataire, alors le script php utilisera directement son stdin pour envoyer l'email à maildrop. Sinon il faudra obligatoirement sauvegarder au préalable l'email (vu qu'on ne lit le stdin qu'une fois). Si vous n'utilisez pas ces fonctionnalités, vous pouvez utiliser directement maildrop dans notre master.cf.

Ce que le wrapper ne fait pas :

Votre café.

Le fichier /etc/maildroprc :

C'est le fichier de configuration de maildrop. Ici on appelle Clamav (via le script clamscan.sh qui vient d'un wiki de Gentoo) et spamassassin. Dans le cas ou le mail est considéré comme spam ou comme virus, il ira dans le dossier .Junk de l'utilisateur (le but étant que l'utilisateur puisse vérifier ses spams via un webmail).

Le fichier /etc/quotawarnmsg :

C'est l'alerte envoyée à l'utilisateur si il utilise plus de 90% de son quota. Vous devez le personnaliser pour mettre une adresse d'administrateur (au lieu de admin@example.com).

5° Mise en place des taches cron :
 
C'est ici que les autres scripts interviennent. D'abord leurs utilité :

spam_learn.sh : Permet d'entrainer le moteur d'auto-apprentissage de spamassassin sur base des Junk box des utilisateurs.

spam_roller.php : Dans notre système, rien n'est prévu pour vider le dossier .Junk, ce sera donc le rôle de ce script. On lui donne un quota de spam par mailbox (en bytes, 2.5 mo par défaut) et si on dépasse ce quota, il supprime les plus vieux spams pour repasser en dessous du quota. Il ne vide pas tout, toujours pour permettre à l'utilisateur de checker ses spams en cas d'erreur.

maildir_make.php : Ce script vérifie les nouvelles mailbox crée dans la table mailbox et crée les répertoires nécessaires.

Ce que je propose comme taches cron :
 
30 3 * * * /usr/local/bin/spam_learn.sh
20 4 * * * /usr/local/bin/spam_roller.php
*/15 8-23 * * * /usr/local/bin/maildir_make.php
 
Ce qui est important c'est de lancer spam_learn.sh avant spam_roller.php, sinon spamassassin ne s'entrainera pas avec tout le spam disponible. Pour le script maildir_make.php, inutile de le faire tourner à des heures ou vous ne travaillez pas (pour un humain normal, mettre 8 à 23 heure, pour un geek normal mettre 13 à 04 heure me semble de bonnes valeurs).
 
6° Conclusion :
 
Ce tutoriel étant assez conséquent, j'ai peut-être oublié des choses, il y a peut-être des fautes ou des points pas claires. Pour toutes remarques ou suggestions, veuillez me contacter par e-mail ou laisser un commentaire. Sinon je peut juste vous dire que chez moi ça marche. Vous pouvez testez l'installation en insérant un tuple dans la table mailbox. Si dans le quart d'heure suivant vous pouvez consulter votre mailbox, envoyez vous un mail test pour vérifier que tout fonctionne.