Bonjour,
Vu qu’on héberge des mails nous aussi, on peut décrire un peu notre infrastructure à notre tour.
Nous utilisons docker-mailserver (Licence MIT), qui est donc une solution « toute prête » embarquant tout un tas de paquets utiles pour faire tourner le serveur : les incontournables postfix et dovecot, spamassassin, clamav, opendkim, opendmarc, fail2ban, fetchmail, postgrey, amavis, etc.
Un fichier de configuration est fourni avec, il suffit de le parcourir et d’activer ou désactiver les fonctionnalités souhaitées.
Un script est aussi fourni et documenté, pour faciliter l’ajout ou la suppression de comptes et/ou d’alias et d’appliquer des paramètres de configuration « à chaud ».
Avec une bonne configuration DNS (notamment du reverse), on respecte les normes d’envoi et de réception d’emails, on ne se fait pas blacklist et le service est stable ; le conteneur consomme 220 Mo de RAM en moyenne et quasiment pas de CPU.
Disclaimer
Bien entendu, utiliser une solution « out-of-the-box » implique de savoir utiliser et installer soi-même ces mêmes outils à la main, sans aide, sans conteneurs ni images qui nous facilitent la vie. C’est une épreuve, mais c’est indispensable, ne serait-ce que pour des raisons de sécurité : ne pas savoir exactement ce qui tourne dans un conteneur en production revient au même que d’utiliser des logiciels propriétaires.
(Neil) Personnellement j’ai commencé par héberger mes propres mails (à titre personnel donc) sur un serveur sans conteneurisation pendant un an et j’ai beaucoup appris de cette expérience ; c’est notamment dans le domaine de la sécurité que je pense en avoir tiré des leçons.
Maintenances et astuces
Un serveur mail nécessite une maintenance presque quotidienne, à la limite bihebdomadaire, surtout si vous choisissez de construire votre propre blacklist de zéro au lieu d’utiliser des blacklists publiques : votre serveur sera exposé h24 à des tentatives de bruteforce ; et même avec un fail2ban fonctionnel, les bots apprennent vite à doser leur spam pour passer entre les mailles du filet.
Nous avons fait le choix de construire notre propre blacklist afin de s’assurer que chaque ban soit justifié et qu’une grande entreprise n’ait pas la main sur ce que nous décidons de blacklist ou non.
En trois mois de fonctionnement, cette blacklist comporte 92 entrées et augmente de jour en jour.
Au moins deux fois par semaine, on consulte les logs de notre serveur :
- On regarde les attaques sur SMTP avec un
grep "HELO" puis un grep "EHLO" ;
- On regarde les attaques sur IMAP avec un
grep "auth:" ;
- On lit en diagonale les logs bruts voir s’il n’y a pas d’indicateurs d’une activité suspecte.
On ban l’IP de manière permanente dès qu’on relève un comportement hostile.
Une technique pour limiter les risques : ces bots vont tenter de se connecter à des adresses communément utilisées : admin@, contact@, test@, user@, 123@, help@, info@, root@, no-reply@, webmaster@, etc.
Si vous laissez vos utilisateurs choisir leur adresse mail (ce qui semble légitime), établissez une blacklist de ces adresses courantes afin de ne pas exposer l’utilisateur à un potentiel bruteforce. Si vous ne savez pas quoi blacklist, laissez tourner un serveur mail sans blacklist pendant quelques jours et vous saurez bien vite quelles sont les adresses les plus ciblées.
Assurez-vous d’ajouter un captcha à l’inscription, vous n’êtes pas à l’abri d’un éventuel contournement de vos services, même à la taille d’un CHATONS. Bien entendu, évitez reCAPTCHA.
Surveillez régulièrement les mails envoyés (leur fréquence, pas nécessairement leur contenu), au cas où un membre enverrait subitement 30 mails à 500 adresses différentes en une journée, ce qui n’est peut-être pas normal.
Surveillez également la fréquence des mails reçus (grep "saved") pour repérer une éventuelle adresse extérieure qui enverrait des emails en masse sur les adresses de votre serveur.
Très important aussi, surveillez les publications de sécurité des logiciels que vous utilisez, surtout postfix et dovecot. Faites votre veille technologique, les failles / CVE graves sont courantes, surtout sur les MTA. (Exim récemment)
Nos camarades chez le CHATONS Elukerio ont plus d’expérience que nous sur le domaine avec leur service libmail, peut-être pourront-ils vous apporter des indications supplémentaires si besoin.
~ N&B
, errreur sur tout mes serveurs : ben voila pourquoi les verif « Issuers » openssl déconnaient !!! … lourds tout ces certficats 
)
!