URL: https://linuxfr.org/users/perdu/journaux/heberger-son-serveur-de-mails-c-est-nul Title: Héberger son serveur de mails, c'est nul Authors: Perdu Date: 2020年12月11日T10:44:43+01:00 License: CC By-SA Tags: postfix, auto-hébergement et courriel Score: 42 Cher journal, Je t'écris pour développer un point de vue particulièrement vendredesque : l'auto-hébergement mail, c'est de la m*. Bon, en fait, pas vraiment et on va être plus subtils que ça, mais il faut bien une accroche provocante pour que tu continues à lire, hein. Plus sérieusement, cela fait quelques années que j'héberge pour propre serveur de mail avec postfix/dovecot + plugin SPF, et c'est *galère*. Il y a peu, j'ai eu la merveilleuse idée d'utiliser aussi mon serveur perso pour les mails pros. Parce qu'avoir son adresse en `contact@moi.tld` ou `monnom@maboite.com`, c'est classe quand même. Et aussi parce qu'il paraît que le mail, c'est censé fonctionner comme ça à la base, de manière décentralisée (oui je sais, c'est fou). Et après tout, ça fait plusieurs années que je corrige les problèmes divers sur des mails non importants, donc ça doit être bon maintenant, hein ? De nouveaux problèmes ne vont pas survenir, hein ? Hein ? HEIN ??? S'il n'y a qu'une chose à retenir de ce journal : faites-le pour le fun ou pour apprendre, mais certainement pas avec vos mails pros ou importants. Entrons dans le vif du sujet. Pourquoi ça craint ? Bon, déjà, il faut noter que le logiciel de référence (postfix), provient d'un temps ancien où on parlait encore du futur bug de l'an 2000 et pas encore de celui de l'an 2038. Les fichiers de configuration ont une syntaxe pour le moins absconse et il est plus que conseillé de suivre à la lettre un tutoriel détaillé pour ne pas finir en relai ouvert permettant de se retrouver à relayer du spam au bout d'un jour et sur toutes les listes noires au bout de deux. Mais bon, je suis sûr qu'il existe des logiciels à la configuration plus simple, donc passons cet argument. Voyons plutôt une série de plusieurs incidents (certains hypothétiques, certains non. Je vais laisser le doute planer pour maintenir ma réputation) : 1. Le démon mail, ça fait peur. Imaginez que vous fassiez une erreur de config et que votre serveur mail soit indisponible plusieurs jours. Que se passe-t-il si on essaye de vous écrire ? Le MTA (relai) le plus proche de vous échouera à vous contacter, et votre expéditeur recevra un soigneux message d'erreur du _mail daemon_ expliquant délicatement le soucis. Le problème ? Le démon parle une langue ésotérique du fond de l'enfer qui effraiera immédiatement votre interlocuteur (l'anglais), ce dernier ayant pour habitude d'ignorer tout message émis dans une langue différente du latin`^W` français. Il finira pas vous dire par d'autres moyens que votre serveur, y-marche-pas (ne vous attendez pas à plus de détails de sa part) en vous demandant si vous avez pas une adresse gmail, parce que hein, ça juste marche, et ça crie pas des trucs en hébreux ancien (ou en anglais). 2. Parfois, le FAI s'y mêle. Mon fournisseur d'accès, que nous nommerons en utilisant le mystérieux pseudonyme de Frit, se vend comme ouvert aux sollicitations spécifiques des personnes plutôt techniciennes. Par exemple, il propose une option pour configurer son _reverse DNS_, ce qui me permettrait de ne pas être bloqué aléatoirement par certains serveurs mails. Chouette ! Le problème ? Ce service est cassé depuis des années, comme en témoignent de nombreux utilisateurs sur des forums publics, qui diagnostiquent un problème réseau du côté de Frit1. Et bien sûr, le service client est inutile sur le sujet et ne répond pas au mot de passe de [Shibboleet](https://xkcd.com/806/)2. En conséquence, certains de mes mails sont bloqués aléatoirement (et silencieusement, parce que sinon ce ne serait pas drôle, merci Mic`^W` fournisseur d'adresses mails que je ne nommerai pas), et je ne peux rien y faire. (Et encore, j'ai la chance d'avoir un FAI permettant d'émettre des mails...) 3. Comme cela arrive parfois, mon contrat de travail prend fin. La boîte (enfin, le labo de recherche) qui m'embauchait propose une redirection mail (plutôt indispensable puisque ledit mail est sur tous mes papiers publiés), mais interdit (avec raison !) la redirection vers des services type gmail. Eh, cela tombe bien, j'ai mon propre serveur mail ! Redirection faite, je fais quelques tests et tout fonctionne bien. Parfait. Sauf que... Non. Plusieurs mois plus tard, je me rends compte qu'on me transfère des mails que j'aurais pourtant dû recevoir. Qu'est-ce qu'il se passe ? Eh bien, après investigation, il s'avère que le concept de redirection de mails n'est pas compatible avec SPF3 : le serveur reçoit des mails ayant divers champs _From:_ et pour adresse IP d'origine celle de mon ancienne boîte, donc si l'expéditeur original provient d'un serveur demandant l'application stricte de SPF, le mail est rejeté. Et comme tous les serveurs n'ont pas la même politique SPF, certains mails passent quand même, ce qui empêche de repérer rapidement le problème. Il y a une solution à ça, qui est que le serveur effectuant la redirection implémente SRS ([_Sender Rewriting Scheme_](http://www.open-spf.org/srs/)). Or, ce n'est pas le cas pour mon ancien labo. Donc je perds des mails. Bon, ok, on pourra me rétorquer que ce problème n'est pas dû à l'auto-hébergement, et que cela me permet même de le régler facilement (en mettant les IPs de ma boîte sur liste blanche de SPF), mais c'est plutôt le genre de soucis que j'aurais préféré déléguer à un fournisseur (et surtout, ça me permet de détailler un problème sur lequel on peut tomber). 4. Imaginez. C'est lundi matin, une longue semaine de travail s'annonce. Vous avez plusieurs _deadlines_ prévues qui vous stressent pas mal. Et là, surprise ! Votre serveur perso a crashé ! Un bon gros crash matériel non réparable comme on les aime. Le bon point, c'est que vous comprenez maintenant pourquoi votre serveur était si lent récemment... Hum hum. Bon, ce n'est pas grave, vos amis tiendront bien plusieurs jours sans votre [bot Jabber](https://github.com/Perdu/panu) et les quelques visiteurs de votre site web ne vous en voudront pas trop s'il n'est pas accessible, puisque les bots russes n'ont pas de sentiment, il paraît. Mais vos mails pros ? Déjà, vous avez perdu tous ceux livrés depuis la veille, jusqu'au crash. Le reste sera conservé par un MTA quelques jours avant d'être retourné à l'expéditeur, donc il faut remonter un serveur fonctionnel d'ici là. Tic tac, tic tac... Et vous ne pouvez plus répondre aux mails avec adresse pro. C'est comme ça que vous avez envie de démarrer votre semaine ? Ah, bien sûr, ça fonctionne aussi avec une coupure internet (non, ça ne vient pas aussi de m'arriver...). 5. Le mail, c'est pratique pour surveiller son serveur. En cas de problème (notamment une erreur lors de l'exécution d'un script cron), vous recevez un mail. Mais si c'est votre serveur mail qui plante, qu'est-ce qu'il se passe ? Non, vous ne recevrez pas un courrier recommandé avec accusé de réception de la part de la machine sous votre bureau, il ne se passera juste rien. Vous vous rendrez compte au bout de 2 semaines que votre serveur mail a crashé et que vous avez probablement raté pas mal de mails. Chouette, vos client ne vous boudent pas ! Enfin, pas il y a 2 semaines, mais maintenant peut-être que si. 6. Enfin, et pour généraliser le point 2, les règles de blocage des spammeurs sont légion, et chaque fournisseur de mails en implémente arbitrairement. On se retrouve parfois à devoir aller faire un tour sur un site de sortie de liste noire pour expliquer qu'on n'est pas un robot. Pire, pour compliquer la vie des spammeurs (et la vôtre au passage), les blocages sont souvent silencieux. Vous ne saurez jamais que Jacqueline n'a pas reçu votre mail sur les endives au fromage parce que son fournisseur mail vous a trouvé trop louche. Bref, en 2020 le mail est devenu complexe à gérer à cause de règles de sécurité non normalisées (ou plutôt de normes non respectées). En conclusion : héberger son propre serveur mail c'est fun, on apprend plein de truc sur les protocoles mail et sur les problèmes réseau. Mais pour vos mails importants, préférez un système plus sûr (par exemple un hébergement associatif par des gens compétents, et surtout avec de l'expérience en la matière et du temps à perdre dessus). Et prévoyez des solutions de secours en cas de crash. Oui je sais, ce n'est pas la découverte du siècle, mais bon, je vous avais prévenu dès le début, c'est un journal de vendredi. 1: Non, ce n'est pas une histoire de friture sur la ligne (badum_tss.wav) 2: En réalité, votre serviteur a trop de respect pour les travailleurs délocalisés pour avoir réellement essayé. 3: _Sender Policy Framework_, une norme permettant d'indiquer dans l'enregistrement DNS de votre serveur quelles IP vous autorisez à émettre du courrier pour ce nom de domaine. Sert à limiter le spam et l'usurpation d'identité.

AltStyle によって変換されたページ (->オリジナル) /