Le meilleur serveur mail ?
J’ai récemment acheté 2/3 noms de domaine chez OVH, dont un en .email pour moi et ma famille. Depuis que je possède « pingex.net », les mails allaient sur les serveurs d’OVH grâce à la mini-offre de mutu qui allait avec les noms. J’ai jusqu’à présent utilisé leurs serveurs par soucis de simplicité, je ne voulais pas maintenir un serveur mail pour une seule boîte. Aujourd’hui les choses ont changé avec l’achat des nouveaux noms. Il m’a fallu maintenant une solution me permettant de centraliser toutes les boîtes de tous les domaines que je possède. De plus je ne voulais plus passer par une infra web/mail mutualisée. La solution ? Mettre en place un serveur mail !
Ayant vécu l’enfer qu’est la mise en place d’un serveur mail brique par brique sous Linux, j’ai décidé de plutôt chercher une solution « tout-en-un » (panel admin, antispam, antivirus, etc.). C’est tout l’objet de ce post.
Cherchons
Le plus simple reste évidemment une petite recherche Google « mail server » sur les quelques premières pages. On tombe rapidement sur des trucs plus ou moins intéressants. Si je fais abstraction des logiciels spécifiques Windows et/ou payants, il me reste la liste suivante:
J’ai également exclu tous les logiciels du type « Groupware » car ces deniers sont plus orientés entreprise et organisations et sont « overkill » pour l’usage que j’en ai. Les solutions que j’ai listé ci-dessus ont l’avantage de reposer sur les mêmes briques open-sources que ceux qu’on utiliserait pour construire un serveur mail manuellement. Je vais donc détailler chacune de ces 3 solutions, ainsi que leurs avantages et inconvénients selon moi.
iRedMail : quick ‘n dirty
iRedMail reprend presque n’importe quelle installation UNIX existante pour la transformer en serveur mail. iRedMail mise sur l’open-source et met en évidence, notamment lors de l’installation, toutes les briques installées. Ceci a l’avantage de donner au sysadmin la possibilité de bricoler le serveur derrière. Il faut cependant garder en tête que iRedMail installe ses propres fichiers de configurations et ces derniers sont bien différents de ceux par défaut. Un sysadmin installant iRedMail risque d’être bien dérouté, notamment lors de la configuration d’Apache ou Nginx.
L’installation en elle-même est relativement simple, pour peu qu’on suive bien la documentation qui va avec. On peut choisir ce qu’on veut installer (webmail, panel admin, etc), je trouve que c’est une bonne chose. A la fin de l’installation, iRedMail laisse derrière lui un fichier contenant explications, traces d’installations, identifiants et coordonnées d’accès.
Le panel d’administration est simple, voire trop simple. On peut difficilement faire autre chose qu’ajouter ou supprimer des utilisateurs/domaines. Afin de pouvoir gérer les alias ou bien des points spécifiques du serveur, il faut mettre la main dans le cambouis et aller directement bricoler la base de données et les fichiers de configurations des briques. C’est bien dommage car iRedMail peut être très puissant et pratique à l’usage. Cependant tout n’est pas perdu ! Moyennant quelques centaines de dollars, vous pouvez débloquer le vrai panel d’administration… ou bien créer le vôtre si vous n’avez pas de sous à dépenser !
Au final, iRedMail est un package pouvant très bien s’intégrer dans une infrastructure existante puisqu’il peut s’appuyer sur un annuaire LDAP ou une base MySQL. On peut également automatiser les tâches d’administration au moyen de quelques scripts interagissant directement avec la base de données et les fichiers de configurations. iRedMail n’est cependant pas très pratique pour quelqu’un qui a besoin d’un serveur mail personnel et qui ne veut pas devoir modifier tous les fichiers pour le moindre changement. Toutefois voici quelques screenshots:
poste.io : quick ‘n clean
J’entends de plus en plus parler de l’utilisation de Docker pour le déploiement de différents services. Il s’agit d’utiliser des conteneurs dans le même style que LXC mais pré-configurés avec les services que l’on souhaite déployer. poste.io rentre très bien dans ce cadre en fournissant rapidement et facilement un service qui est la gestion des mails, le tout dans un conteneur Docker.
Comme je n’ai jamais utilisé Docker auparavant il m’a fallu d’abord comprendre comment l’installer et le faire fonctionner. J’ai donc suivi ce petit guide me permettant de le mettre en place sur une Debian 8. Le déploiement du conteneur par la suite est assez simple en suivant le Getting Started de poste.io. Attention cependant à bien virer exim (apt-get remove exim* ) installé de base sur Debian afin d’éviter un conflit sur le port 25.
Lors de l’accès initial à l’interface d’administration, nous avons d’abord droit à 2/3 pages de setup avant d’atterrir sur l’interface principale. Simple et efficace, on peut y effectuer différentes tâches d’administration. Les utilisateurs peuvent accéder eux-mêmes à l’interface d’administration et changer les paramètres leur concernant: mot de passe, redirections, etc. On trouve également un dashboard donnant quelques statistiques sur le serveur ainsi qu’un écran de diagnostic des différents services fonctionnant sur le serveur. A déplorer cependant le manque de documentation de la part des développeurs (ou bien je ne l’ai pas trouvée ?). De plus l’utilisation d’un conteneur me complique l’utilisation de certain services externes tels que munin ou fail2ban.
En somme poste.io est un très bon package, facile à setup. Voici quelques screenshots:
Mail-in-a-Box : trop, mais pas assez
D’emblée j’ai été surpris par le fait que Mail-in-a-Box m’a obligatoirement demandé une machine Ubuntu 14.04 en 64 bits clean, et rien d’autre. Bon clean ça peut se comprendre, je m’attendais bien à un script à la iRedMail. Je n’ai cependant pas immédiatement compris pourquoi Ubuntu 14.04. Ayant donc installé Ubuntu sur une VM, j’ai exécuté le script d’installation de Mail-in-a-Box. Installation relativement bien automatisée, aucun soucis à signaler de ce côté là.
Ma surprise à la fin de l’installation lors de la découverte de tout ce qu’il m’a installé. J’ai eu entres autres:
- Évidemment mon serveur mail SMTP/POP/IMAP,
- Un panel d’administration,
- Un serveur DNS,
- Une instance d’ownCloud,
- Un hébergement web statique,
- Et un Munin (munin entier et pas juste munin-node).
Woah ! Je n’ai pas demandé tout ça. Bon Mail-in-a-Box semble très bien pour quelqu’un qui veut juste quelque chose qui s’apparente à du groupware, mais en plus personnel et simple. Je n’ai pas la place sur mon serveur pour ça malheureusement.
Un petit mot maintenant sur l’interface d’administration: esthétiquement sobre, le panel manque cependant de fonctionnalités (pire qu’avec le panel de iRedMail). On peut à peine manipuler des comptes mails. C’est dommage par rapport à tout ce qui est fourni avec ce soft. Point positif cependant: le panel fait le diagnostic du serveur et fait état des différents problèmes auquel le serveur doit faire face (DNS, NAT, disque dur, etc.). De plus le panel donne tous les paramètres de connexion pour les clients externes.
Mail-in-a-Box est en somme très user-friendly, cependant très limité. Il cache toute la misère qu’est la gestion d’un serveur mail dans différentes automatisations et auto-configurations. Voici quelques screenshots:
Conclusion
Nous avons là 3 solutions qui répondent à un besoin qui n’est pas tout à fait le même dans chaque cas. On peut résumer les besoins comme suit:
- Déployer une « base » de serveur mail, puis broder autour en fonction de ses besoins => iRedMail
- Un serveur mail rapide, fonctionnel et qui ne demande pas à mettre la main dans le cambouis => poste.io
- Un cloud ou mini-groupware pour des personnes avec des connaissances limitées en sysadmin => Mail-in-a-Box
Après avoir testé les 3 solutions, je peux affirmer que poste.io est la meilleure réponse à mon problème. Il me reste maintenant à chercher comment résoudre les quelques problèmes posés par le conteneur, notamment:
- Gestion de fail2ban
- Comment indiquer à fail2ban d’aller chercher les logs des mails à un endroit spécifique ?
- Comment faire en sorte que les bans soient effectifs malgré les règles de DNAT de Docker ?
- Gestion de Munin
- Comment ajouter et gérer les plugins munin-node spécifiques aux mails ? (pourquoi n’utiliser Munin qu’à moitié sinon ?)
Je vais tenter de résoudre ces problèmes dans un prochain post.