On voit souvent des administrateurs de serveurs de
messagerie demander des conseils sur la configuration d'un
serveur de secours, un MX secondaire. Est-ce vraiment utile ?
Pour la grande majorité des sites, non, un MX secondaire ne sert
pas à grand'chose et présente des risques, notamment en terme de lutte
anti-spam.
En effet, le courrier électronique n'est pas
le Web. Il est
asynchrone et peu pressé. En cas de panne du
serveur de messagerie, les autres serveurs qui tentent de lui envoyer
du courrier feront comme les MTA ont toujours
fait depuis l'aube des temps : ils attendront et réessaieront (la
plupart du temps, pendant cinq jours, la durée maximum configurée par
défaut dans sendmail et
Postfix).
Il n'y a donc aucun risque de perte du courrier si le serveur de
messagerie est coupé ou bien injoignable pendant quelques jours.
En revanche, le serveur de secours, le MX secondaire (du nom des
enregistrements MX du
DNS) présente des pièges, notamment en ce qui concerne les règles anti-spam. Par
exemple, les listes noires ne servent à rien si on a un MX secondaire
(les spammeurs se connectent souvent au MX de plus basse priorité,
comptant, en général à juste titre, qu'il est moins protégé). À moins
que le MX secondaire soit configuré avec exactement les mêmes règles
anti-spam que le serveur principal (ce qui est difficile à faire,
surtout s'il est situé dans une autre organisation), il représentera
le maillon faible de la résistance aux spams.
Avoir un second serveur viole surtout le principe de
simplicité : deux serveurs sont plus compliqués à
configurer qu'un, augmentant ainsi les probabilités de problème. C'est
en général au moment où le primaire tombe en panne qu'on s'aperçoit
soudain que le secondaire n'acceptait plus du courrier pour le domaine
depuis des mois, sans que personne n'ait détecté ce changement de configuration.
Et si les utilisateurs réclament leur courrier immédiatement, sans
délai, même si le serveur primaire est en panne ? Il faut d'abord
expliquer à ces utilisateurs que le courrier, service asynchrone, n'a jamais été prévu pour
cela, et leur dire que, s'ils veulent du
synchrone, il y a le téléphone ou
Jabber. (Amavis est, par
exemple, un bon moyen de retarder le courrier, souvent de plusieurs
heures.) Ensuite, il faut
noter qu'il ne suffit pas d'un MX secondaire pour avoir une délivrance
rapide même en cas de panne du primaire. Il faut aussi
que ce MX secondaire puisse délivrer directement dans les boîtes aux
lettres. Cela implique en général qu'il soit sur le même site que le
primaire, augmentant ainsi la probabilité qu'il tombe en panne en même temps,
victime de la même pelleteuse.
D'autres regretteront que, en cas de panne du primaire, les
expéditeurs distants peuvent voir qu'on est en panne, avec la commande
mailq sur leur serveur de messagerie
Postfix. Mais peu d'expéditeurs suivent ainsi le cheminement de leur
courrier, comme si c'était un colis envoyé par
FedEx. En revanche, c'est vrai que les bêtes
messages de retard qu'envoient certains serveurs à leurs utilisateurs
« Your message was not delivered yet, we continue to try, you
have nothing to do » peuvent perturber leur lecteur, qui ne
le comprend pratiquement jamais (et
qu'il interprète parfois de façon farfelue). À une époque, c'était le comportement par défaut de sendmail.
Un autre cas où il peut-être utile d'avoir plusieurs MX est celui
où on tient absolument à garder trace des messages, en les laissant
rentrer sur une machine qu'on contrôle, même si on le les délivre pas
tout de suite dans les boîtes aux lettres. C'est dangereux, car, en
acceptant les messages, on accepte aussi une responsabilité. Il faut
être sûr de pouvoir les traiter un jour.
Mais, diront enfin certains, Gmail ou
Yahoo ont plusieurs serveurs, comme on peut le
voir avec un dig MX gmail.com. Ma réponse est
que, si vous êtes responsable du courrier de Gmail, vous n'allez
probablement pas chercher des conseils sur ce blog. Mais, pour les
nombreux sites qui sont nettement plus petits et
moins pourvus en ressources humaines que Gmail, ces conseils de
simplicité peuvent vous être utiles.
(Merci à Gilles Mocellin, Yves Rutschle, Benoit Lathière, François
Tourde, Vincent Bernat et Daniel Caillibaud, pour une intéressante
discussion sur la liste des utilisateurs francophones de
Debian. Naturellement, les idées exprimées ici
sont uniquement les miennes et patati et patata.)
Antoine cite d'autres cas où l'utilisation d'un MX secondaire est
utile (à condition qu'on ait les moyens humains de le configurer
correctement :
- Le délai de cinq jours, qui est par défaut le temps d'attente
maximal de la plupart des MTA peut être trop court si le seul
administrateur système du site part en vacances une semaine. Le MX
secondaire peut être configuré pour garder le courrier plus longtemps
(peu le sont).
- Si (c'est un gros Si) le MX secondaire permet de consulter le
courrier mis en attente (ne serait-ce qu'en utilisant
more sur les fichiers du spool), alors
cela permet, en dépannage, de voir « le courrier du client que l'on
attend maintenant tout de suite immédiatement », même quand le serveur
de courrier principal est tombé.