De l'intérêt d'un MX de secours dans le cadre de la gestion de mon service mail personnel
La redondance, les sauvegardes sont des notions primordiales en informatique. La tolérance de pannes doit faire partie des critères majeurs à prendre en considération y compris dans le cadre de l'auto-hébergement.
Ainsi, je dispose de 4 serveurs DNS maitre et esclaves autoritaires sur ma zone et d'un système de backup incrémentiel pour sauvegarder tout ce qui est important. Jusqu'à présent, j'avais fait le choix de ne disposer que d'un unique serveur SMTP pour les raisons suivantes :
- En cas de crash d'un serveur SMTP, les autres serveurs de messagerie tenteront de lui renvoyer les mails qui lui sont destinés pendant quelques jours (5 jours par défaut).
- Trop souvent (à tort), le MX secondaire est peu protégé, il devient la proie des spammeurs en tout genre.
- Augmentation des risques et des problèmes liés à la configuration de deux services SMTP au lieu d'un.
- Si le MX de secours se trouve sur un site distant (solution optimale), cela complique la possibilité pour celui-ci de délivrer les mails directement dans les boites utilisateurs.
- Le serveur de secours ne fait pas forcément de contrôle des destinataires. Ne sachant pas quels destinataires sont valides pour les domaines dont il est serveur de secours, il accepte tous leurs messages et essaie de les délivrer au serveur primaire. Celui-ci va ensuite refuser les destinataires invalides, obligeant le serveur de secours à renvoyer ces messages à leurs expéditeurs. C'est ce que l'on appelle les notifications indésirables.
- L'argument ci-dessus entraîne deux conséquences majeures, possibilité de saturation de la file d'attente et envoi de notifications indésirables sur des adresses mails d'utilisateurs réels utilisées par les spammeurs.
Ces arguments proviennent de l'excellent article de Stéphane Bortzmeyer sur son blog personnel mais aussi du livre "Monter son serveur de mail sous Linux" de Magnus Bäck, Patrick Ben Koetter, Ralf Hilderbandt, Alistair McDonald, David Rusenko, Carl Taylor aux éditions Eyrolles.
Cependant, la question de la mise en place d'un MX secondaire pour les particuliers ou les TPE suscite le débat et plusieurs contre-arguments peuvent être avancés et notamment le fait que :
- Si je pars en vacances plus de 5 jours, je serai suceptible de perdre un certain nombre de mails potentiellement importants
- Que le délai de 5 jours n'est pas forcément respecté par tous les serveurs SMTP présents sur le NET
- Qu'il est quand même possible de consulter les mails stockés en file d'attente sur le serveur SMTP de secours
- Qu'il est possible d'avoir des outils de contrôle des SPAM et des expéditeurs sur le MX secondaire
Après mûre réflexion, j'ai donc décidé de mettre en place un MX secondaire pour ma messagerie hébergé sur un serveur dédié dans un datacenter. Ce qui a décuplé ma motivation est également la découverte de OpenSMTPD et de SPAMD sans oublier le fameux "Just for Fun" ;)
Me voilà donc parti, je décide d'installer et de paramétrer OpenSMTPD, SPAMD sur FreeBSD.
Avant de paramétrer ces différents outils, je génère un certificat X509 et une clef privée de chiffrement afin de pouvoir mettre en oeuvre TLS sur le serveur SMTP
Attention au Common Name que vous précisez lors de la création du certificat (il correspondant au nom de domaine FQDN de votre serveur) ainsi qu'aux permissions attribuées aux fichiers générés précedemment.
Je passe maintenant à la configuration d'OpenSMTPD et là ce n'est que du bonheur ! Une syntaxe simple, claire, efficace et minimaliste permettant de bénéficier d'un service SMTP fonctionnel en quelques minutes (coucou Postfix et surtout coucou Sendmail !) :
# Déclaration certificat et clef privée pour TLS
pki mx2.mondomaine.fr key "/usr/local/etc/mail/certs/mx2.mondomaine.fr.key"
pki mx2.mondomaine.fr certificate "/usr/local/etc/mail/certs/mx2.mondomaine.fr.crt"
listen on sis0 port 25 hostname mx2.mondomaine.fr tls pki mx2.mondomaine.fr
listen on sis0 port 587 hostname mx2.mondomaine.fr tls-require pki mx2.mondomaine.fr
# On accepte de traiter les mails à destination de mon domaine en tant que backup
accept from any for domain mondomaine.fr relay backup mx2.mondomaine.fr
On enchaîne avec la configuration du daemon SPAMD :
all:\
:uatraps:nixspam:china:korea:
# University of Alberta greytrap hits.
# Addresses stay in it for 24 hours from time they misbehave.
uatraps:\
:black:\
:msg="Your address %A has sent mail to a ualberta.ca spamtrap\n\
within the last 24 hours":\
:method=http:\
:file=www.openbsd.org/spamd/traplist.gz
# Nixspam recent sources list.
# Mirrored from http://www.heise.de/ix/nixspam
nixspam:\
:black:\
:msg="Your address %A is in the nixspam list\n\
See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
:method=http:\
:file=www.openbsd.org/spamd/nixspam.gz
# Mirrored from http://www.okean.com/chinacidr.txt
china:\
:black:\
:msg="SPAM. Your address %A appears to be from China\n\
See http://www.okean.com/asianspamblocks.html for more details":\
:method=http:\
:file=www.okean.com/chinacidr.txt:
# Mirrored from http://www.okean.com/koreacidr.txt
korea:\
:black:\
:msg="SPAM. Your address %A appears to be from Korea\n\
See http://www.okean.com/asianspamblocks.html for more details":\
:method=http:\
:file=www.okean.com/koreacidr.txt:
Cette configuration fonctionne à la fois avec un système de blacklist défini par des fichiers présents sur des serveurs web définissant un certain nombre de spammeurs ou de blocs d'adresses IP interdites (chine, corée du sud...) mais aussi avec un système de greylist combiné à Packet-Filter (sans oublier les whitelists) :
mail_serv = "{ 25, 587 }"
table <whitelist> persist file "/usr/local/etc/mail/whitelist.txt"
table <spamd-white> persist
no rdr proto tcp from <spamd-white> to any \
port $mail_serv
no rdr proto tcp from <whitelist> to any \
port $mail_serv
rdr pass proto tcp from any to any \
port $mail_serv -> 127.0.0.1 port spamd
# Autoriser acces direct SMTP whitelist
pass in on $int proto tcp from <whitelist> to $int port $mail_serv
pass in on $int iproto tcp from <spamd-white> to $int port $mail_serv
Si vous souhaitez consulter les adresses IP présentes dans une table, en supprimer ou en ajouter, voici les commandes adéquates :
$ sudo pfctl -t spamd-white -T delete 192.0.2.10
$sudo pfctl -t spamd-white -T add 192.0.2.150
On active les services OpenSMTPD et SPAMD au démarrage du serveur dédié :
obspamd_enable="YES"
obspamd_flags="-v -b"
On redémarre les différents services afin que les modifications soient prises en compte :
Il ne reste plus qu'à modifier ma zone DNS afin de déclarer un mx de secours (numéro de priorité le plus élevé) :
10800 IN MX 20 mx2.mondomaine.fr.
On redémarre Bind après avoir incrémenté le numéro de série de la zone bien entendu ;)
Et voilà, je dispose maintenant d'un serveur SMTP de secours qui me servira en cas de crash de mon MX principal et d'absence prolongée de ma part. J'ai essayé de limiter l'utilisation de celui-ci par des spammeurs sans scrupules. Je vous ferai certainement un retour d'expérience dans les prochains mois sur ce point précis. À noter que malgré la jeunesse du projet OpenSMTPD, il semble être promis à un bel avenir, tant on prend plaisir à le configurer et à le mettre en place.
Enfin, n'hésitez pas à me faire partager vos retours, vos conseils et vos remarques concernant ce billet, je suis preneur ! Toutes propositions d'amélioration et sécurisation d'un MX secondaire complémentaires sont également les bienvenues.
Références :
http://www.bortzmeyer.org/mx-secondaire.html
http://guillaumevincent.com/2015/01/31/OpenSMTPD-Dovecot-SpamAssassin.html
http://home.nuug.no/~peter/pf/en/spamd.html
http://home.nuug.no/~peter/pf/en/spamd.setup.html