Journal Héberger son serveur de mails, c'est nul

Posté par  (site Web personnel) . Licence CC By‑SA.
42
11
déc.
2020

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 Frit¹. Et bien sûr, le service client est inutile sur le sujet et ne répond pas au mot de passe de Shibboleet². 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 SPF³ : 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). 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 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.

¹: Non, ce n'est pas une histoire de friture sur la ligne (badum_tss.wav)

²: En réalité, votre serviteur a trop de respect pour les travailleurs délocalisés pour avoir réellement essayé.

³: 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é.

  • # Tu as oublié...

    Posté par  . Évalué à 10.

    … la sécurité !

    Sur le mien tourne en permanence clamav (avec des paramètres stricts et des listes supplémentaires) qui me "bouffe" 60% du CPU (bon OK petite machine en même temps…). parfois même à 100% au redémarrage…

    Bien sûr le fail2ban pour les attaques "brute force" sur la base SASL …

    Pour la supervision un "vieux" Centreon (que je vais incessamment sous peu remplacer par icinga) dans un onglet épinglé de mon brouteur préféré.

    Maintenant ça fait 8 ans que j'héberge mon propre serveur et j'ai connu fort peu d'incidents (trois jours d'interruption il y a deux ans pour cause de casse disque… Oui je fais partie des admins qui font des backups, depuis :-D )

    Que du bonheur, mais chronophage au possible ;-)

    Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.

    • [^] # Re: Tu as oublié...

      Posté par  . Évalué à 10.

      Sur le mien tourne en permanence clamav

      Et ça sert à quelque chose ?

      Je veux dire : il y a des vrais positifs ? Qui n'auraient pas été rejetés par un rspamd bien configuré ?

  • # C'est pas uniquement que c'est en anglais

    Posté par  (site Web personnel) . Évalué à 8.

    Mais, il y a tellement de trucs autour de la raison qui explique pourquoi le message n'a pas été reçu, n'est pas arrivé, vous revient dans les gencives, etc. qu'il faut savoir où la trouver dans tout ça et l'aspect du message et tout l'emballage en klingon ne donne pas trop envie de se livrer à des fouilles.

    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: C'est pas uniquement que c'est en anglais

      Posté par  (site Web personnel) . Évalué à 8.

      Donc un travail sur la présentation des messages d'erreur pourrait aider ?
      Par expérience, le béotien a tendance à ne pas lire les messages d'erreurs, même s'ils sont très clairs…

      • [^] # Re: C'est pas uniquement que c'est en anglais

        Posté par  (site Web personnel) . Évalué à 5.

        Oui je pense que ça pourrait aider, même si on n'a pas une tendance naturelle à les lire :-)

        La plupart du temps, visuellement, les messages des mailer daemon t'envoient d'entrée de jeu le message "de toute façon tu ne vas pas comprendre donc inutile d'aller plus loin et de lire pour savoir pourquoi tu reçois ça".

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

        • [^] # Re: C'est pas uniquement que c'est en anglais

          Posté par  . Évalué à 10.

          Et encore, tu peux avoir un message d'erreur d'un mailer daemon ayant reçu un message d'erreur d'un autre mailer daemon par erreur, le tout avec un problème d'encodage, renvoyé par un utilisateur effrayé copié collé dans un mail en html uniquement. Toi tu ouvre innocemment le chose avec ton mutt et trois heures après, tu achète un billet aller simple pour la Nouvelle Zélande, il parait qu'ils cherchent des bergers pour garder leur moutons, enfin c'est ce que j'ai cru comprendre en regardant cette vidéo : https://youtu.be/_UEJqURDf3Q

          Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

      • [^] # Re: C'est pas uniquement que c'est en anglais

        Posté par  (site Web personnel) . Évalué à 4.

        En fait les messages et les codes d'erreur ne sont pas normalisés. Vite fait sur un serveur là :

        4.2.2 mailbox full
        452-4.2.2 The email account that you tried to reach is over quota.
        554 5.7.1 Recipient address rejected: Mailbox full
        451 4.7.1 Recipient address rejected: "------ Boit…veuillez renvoyer votre message plus tard / Mailbox overquota please send your message later ------"

        difficile du coup de remonter quelque chose de convivial, clair et localisé

        • [^] # Re: C'est pas uniquement que c'est en anglais

          Posté par  (site Web personnel) . Évalué à 3.

          Il est quand même écrit plusieurs fois que c'est plein ou qu'il y a le dépassement d'une limite.

          Ensuite, ce n'est pas en français… c'est comme ça. On va pas envoyer les messages d'erreurs dans toutes les langues, si?

          C'est peut être à paramétrer par l'admin-sys, mais même quand ce sera écrit en Français, il y aura toujours des gens pour ne pas comprendre, soit parce que ça les dépasse, soit parce qu'ils ne lisent pas.

          Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

          • [^] # Re: C'est pas uniquement que c'est en anglais

            Posté par  . Évalué à 5.

            On va pas envoyer les messages d'erreurs dans toutes les langues, si?

            Mais on va traduire les logiciels et si possible mapper les erreurs. Même sans traduction ça aide d'avoir une bidirectionnalité entre une cause d'erreur et son résultat (rien que pour la supervision par exemple). Maintenir les choses cryptiques n'aide en rien du ce n'est à maintenir une classe de sachant distinct de la plèbe.

            Mais ça ne sera jamais corrigé c'est comme ça que le mail c'est construit bon gré mal gré.

  • # Surveillance externe

    Posté par  . Évalué à 8.

    En effet, pour surveiller son serveur de mail, il faut en avoir un autre.

    Moi, j'ai choisi le mode CHATONS : je connais un bon pote qui me fournit un mail, et un DNS secondaire auto-hébergé. Même qu'une fois, pendant une longue panne de réseau, il m'a annoncé comme MX le temps que ça revienne. Plus de filtres de message, juste un tas dans un répertoire, mais c'est déjà VACHEMENT bien.

    Avoir des relations sociales, c'est bien !

    • [^] # Re: Surveillance externe

      Posté par  (site Web personnel) . Évalué à 6.

      En effet, pour surveiller son serveur de mail, il faut en avoir un autre.

      Un simple ESP8862 peut faire l'affaire, c'est d'ailleurs un super petit projet d'IOT.
      Un microcontroleur wifi à quelques euros, il faut bien entendu développer une interface web pour les paramètres wifi et lister les serveurs à surveiller : IP ou nom d'hôte, port, type de service (mail, http, ssh, …), fréquence de vérification).
      - Si un serveur / service est down : au choix allumer une led et aller sur l'interface web de l'IOT voir quel serveur est down, ou mieux afficher le problème sur un petit écran LCD/OLED, avec même une petite sirène d'alarme si besoin.
      - une autre diode / affichage d'erreur si c'est le wifi/accès internet qui est down.

      En veille (entre deux checks), la consommation est quasi-nulle (quelques mA sous 3.3V ou 5V), environ 80mA pendant le check (quelques secondes), et ça prend moins de place qu'un switch 4 ports.
      Je crois que je vais me lancer, tiens.

  • # Meuh non, c'est pas nul !

    Posté par  (site Web personnel) . Évalué à 10.

    J'ai également un serveur mail dovecot/sendmail/spamassassin/clamav qui tourne dans le garage, et j'utilise encore le dinosaure sendmail et son langage de configuration encore plus abscons que Postfix !
    Le tout suivant une architecture qui ressemble à peu près à ça (pour plus de détails voir par )

    Titre de l'image

    en revanche, je n'ai pas choisi de monter un SMTP visible d'internet, je me repose sur le SMTP de mon hébergeur pour l'envoi, ça supprime une bonne part des problèmes liés à l'autohébergement.

    Les avantages d'avoir son propre serveur mail sont :
    - de pouvoir avoir la main sur tout le processus de filtrage des mails, puisque généralement ceux proposés par les FAI et autres services type gmail sont au mieux médiocres
    - de stocker en local ses mails et les rendre accessible de n'importe où (y compris de mon mobile à l'autre bout du monde) sans dépendre d'un quelconque service sur internet dont on peut douter de l'usage qu'il pourra faire des mails stockés

    https://www.funix.org mettez un manchot dans votre PC

    • [^] # Re: Meuh non, c'est pas nul !

      Posté par  (site Web personnel) . Évalué à 6.

      Dans les avantages, pouvoir créer des adresses à la volée est vraiment pratique (par exemple pour s'inscrire à des services divers et fermer l'adresse en cas de spam publicitaire)

      • [^] # Re: Meuh non, c'est pas nul !

        Posté par  (site Web personnel) . Évalué à 2.

        J'ai cet avantage avec un fournisseur externe, pas besoin de faire de l'auto-hébergement pour cela.

      • [^] # Re: Meuh non, c'est pas nul !

        Posté par  (site Web personnel) . Évalué à 6. Dernière modification le 12/12/20 à 10:34.

        C'est la crainte de perdre cette possibilité qui m'avait fait hésiter à aller chez un fournisseur externe, mais j'en ai trouvé un qui :

        • autorisait la création d'alias (mais en nombre limité) ; finalement, j'utilise cette fonctionnalité assez peu grâce aux trois fonctionnalités suivantes ;
        • gère le signe + : toto+…@exemple.com se retrouve dans toto@exemple.com, toto pouvant être un alias ;
        • permet d'associer un autre domaine au domaine principal (…@autre-exemple.org se retrouve dans …@exemple.com) ;
        • propose un compte catch-all, c'est-à-dire que n'importe quoi en @exemple.com qui ne correspond pas une adresse existante ou n'est pas géré par l'une des fonctionnalités ci-dessus se retrouve dans ce compte ;
        • obtient le score maximal aux tests anti-spam.

        Toolkit Atlas : un moyen simple et rapide pour ajouter une interface graphique à vos applications… (voir 'site Web personnel").

    • [^] # Re: Meuh non, c'est pas nul !

      Posté par  . Évalué à 6.

      Je comprends bien l'intérêt de tout cela mais, sans vouloir dénigrer, il ne s'agit pas vraiment d'auto-hébergement d'un système de messagerie.
      Tu dépends complètement de fournisseurs externes, aussi bien pour la réception que pour l'envoi des mails et tu ne gères pas de domaine de messagerie. La création d'une BAL, avec son adresse, doit être faite chez un prestataire qui recevra les mails et les stockera jusqu'à ce que tu les récupères (ce qui lui laissera largement le temps de les analyser pour pour enrichir ses données marketing).

      • [^] # Re: Meuh non, c'est pas nul !

        Posté par  (site Web personnel) . Évalué à 7.

        Exact, mon architecture est hybride et présente l'inconvénient que tu exposes, j'ai laissé tomber l'autohébergement complet car ça présentait bien trop d'inconvénients par rapport aux bénéfices que je pouvais en tirer, et dans ce cas oui je rejoins l'avis de ce journal.

        https://www.funix.org mettez un manchot dans votre PC

  • # Friture sur la ligne

    Posté par  . Évalué à 10.

    J'auto-héberge mes mails depuis plus de 10ans.
    Je suis passé sur du matériel exotique (Guruplug / Cubiboard / Soekris / Odroid H2), changé d'OS (Debian => OpenBSD) de serveur mail MTA (Postfix => OpenSMTPd), mais pas de MDA (Dovcote).
    J'ai eu des casses matériels, logiciels, lignes, déménagement, etc.

    Je ne suis pas d'accord avec toi avec le coté chronophage, une fois que la conf est en place, la maintenance est assez réduite.
    Je me suis simplifié la vie en ayant des règles d'acceptation de mail quasi inexistant. Pas de filtre SPF, DMARC ni anti-spam ! Et finalement je reçois bien moins de SPAM que sur mes boites de secours chez de grand hébergeurs.
    Par contre de mon coté j'essaye de montrer patte blanche le maximum, donc SPF, DMARC etc.

    Le coté chiant sont les gros serveur de mail qui ont une politique en vers les «petit» exécrable, je te l'accorde, mais ce ne sont pas les pires. Certains «moyen» n'accepte QUE si ton IP n'est pas classé comme «FAI grand public» (coucou Bouyges). La peur du SPAM est forte, mais pas insurmontable.
    Ton FAI Friture n'est plus geek depuis belle lurette … j'avais usé de leur service de rDNS pendant un temps, mais au passage à la fibre ça ne fonctionnait plus et j'ai vite compris que ça ne fonctionnerais jamais. Pendant un temps je suis passé par son relai SMTP, mais je ne trouve pas que ce soit une solution acceptable.

    Du coup pour passer outre toutes ces problématiques d'adresse IP à blanchir régulièrement je me suis pris un VPN dans une asso local. Au passage j'y gagne l'avantage d'un support très sympathique, surtout autour d'un verre, compétent et une IP « fixe », dans le sens ou un déménagent ou un problème sur ta ligne te permet de poser rapidement ton serveur chez un ami sans touché à la conf ! Testé et approuvé !
    Pour t'éviter encore plus de problème, tu as toujours la solution de prendre un hébergement chez un hébergeur. Comme ça plus de soucis purement matériel. Tu passe d'un modèle distribué(auto-hébergement) à décentralisé.

    • [^] # Re: Friture sur la ligne

      Posté par  (site Web personnel) . Évalué à 5.

      Ah oui diantre les déménagements, j'ai oublié cet inconvénient majeur lors de l'écriture, zut. Surtout quand ton nouveau FAI met un mois à t'envoyer une box…

    • [^] # Re: Friture sur la ligne

      Posté par  . Évalué à 3. Dernière modification le 14/12/20 à 22:40.

      Ton FAI Friture n'est plus geek depuis belle lurette … j'avais usé de leur service de rDNS pendant un temps, mais au passage à la fibre ça ne fonctionnait plus et j'ai vite compris que ça ne fonctionnerais jamais.

      J'avais ce problème avant mon déménagement ADSL (j'étais déjà en ADSL), le simple changement d'IP lié au déménagement a permit que ça fonctionne (passage de 82.64.199.xx à 82.233.216.xx) ! Pourtant, avant sur l'interface web ça me disait bien que c'était pris en compte, mais évidement ça n'a jamais fonctionné.

      Je constate que les serveurs DNS autoritaires ne sont pas les mêmes que mon ancienne IP :

          $ dig NS 199.64.82.in-addr.arpa. +short
          ns2.proxad.net.
          ns3.proxad.net.
          $ dig NS 216.233.82.in-addr.arpa. +short
          ns3-rev.proxad.net.
          ns2-rev.proxad.net.

      C'est potentiellement lié au pool IP attribué, en faisant un whois sur l'ancienne IP, c'est indiqué "Dynamic pool", or j'avais une IP fixe (dual Stack v4/v6 demandé via l'interface web Freebox)). Avec mon IP actuelle, c'est bien indiqué pool IP statique. La description des objets du whois n'est pas forcément une valeur sûre mais ça peut donner quelques pistes…

  • # monitoring de service => healthchecks.io

    Posté par  . Évalué à 3.

    Tout d'abord merci pour ton retour d'expérience.
    Je ne me suis pas encore lancé dans l'exercice d'héberger du mail car oui c'est hyper casse gueule.
    J'utilise des adresses sur domaines grand public ou des adresses sur des domaines que je possède mais gérés par un tiers.
    Si je devais me lancer sur de l'auto-hébergement, je ne pense pas que je le ferai à la maison. Je grille pain qui fait sauter les plombs, c'est du vécu.

    Mais quelque soit le service hébergé, ce qui est primordiale c'est le monitoring. Il faut surveiller les métriques, les logs et paramétrer les alertes. J'aime bien utiliser healthchecks.io (ou une de ses instances) car il permet aussi d'alerter quand le service n'est plus là! C'est tout bête et très puissant : le service ou une sonde pingue healthchecks.io et si il pingue pas dans les temps ou si il ping avec un "fail" tu es alerté. Moi j'aime bien l'alerte par bot Telegram ou par SMS.

    Le ping peut se faire par HTTP ou par mail. Sûrement pratique pour un serveur de mail. Je vois bien un petit job cron, sur le serveur de mail ou sur un autre, qui utilise le serveur de mail pour mailer healthchecks.io.

    Bon courage

  • # mais non, c'est pas nul

    Posté par  (site Web personnel) . Évalué à 10. Dernière modification le 11/12/20 à 13:13.

    C'est marrant, on en parlait un peu là récemment : Linux ne m'intéresse plus

    Il est certain que le ticket d'entrée est plus élevé qu'avant, à force de rajouter des couches et des couches, et ça arrange bien les très gros (google…) qui se régalent de tous ces mails qu'ils analysent avec délectation.

    Je ne délègue que ma merde (ma boîte spéciale spam) à Microsoft, histoire de me venger un peu d'avoir parfois à utiliser windows.
    Ma boîte pro est auto-hébergée et tout se passe bien : pas de spam et mes mails arrivent bien à destination, pas de coupure (et pas encore de disques ou machines HS, croisons les doigts).
    C'est sûr que ça demande un sacré boulot à mettre en place : IP fixe (et pas résidentielle, donc location d'un serveur), reverse dns, spf, dkim, dmarc… pas de relay, comptes devant s'authentifier pour recevoir et envoyer, tout en TLS/SSL, etc.

    Entre autres raisons, la peur de mal configurer le truc (maîtriser tous les paramètres de postfix ou autres) a fait que j'ai développé un serveur pop et smtp moi-même (signature DKIM inclus), afin d'en comprendre tous les rouages et configurer exactement comme je le veux avec un simple fichier de conf et des logs lisibles humainement.

    J'ai un serveur miroir en cas de pépin, le plus long sera la propagation DNS, pas un drame.
    Finalement, une fois en place, il n'y a vraiment rien à faire, et ce n'est pas moins fiable que les gros (la boîte où je bossais avant utilisait 365, fallait voir le nombre d'incidents… affolant.)

    Je compte bien continuer ainsi car il est hors de question de laisser les mails devenir le domaine réservé de quelques gros acteurs peu scrupuleux.

    • [^] # Re: mais non, c'est pas nul

      Posté par  . Évalué à 10.

      Entre autres raisons, la peur de mal configurer le truc (maîtriser tous les paramètres de postfix ou autres) a fait que j'ai développé un serveur pop et smtp moi-même

      Et quand t'a peur de pas savoir utiliser un appel système tu écrit ton propre OS ?

    • [^] # Re: mais non, c'est pas nul

      Posté par  (site Web personnel) . Évalué à 6.

      C'est sûr que ça demande un sacré boulot à mettre en place : IP fixe (et pas résidentielle, donc location d'un serveur), reverse dns, spf, dkim, dmarc… pas de relay, comptes devant s'authentifier pour recevoir et envoyer, tout en TLS/SSL, etc.

      Avec le problème du spam et la mise en place de nécessaire de SPF, DMARC, DKIM, l’hébergement de courriels s’est considérablement compliqué avec le temps. Une difficulté pour le débutant est le nombre de programmes différents, chacun dédié à une sous-tâche, qu’il faut faire interagir entre eux. Personnellement, après avoir hébergé mes courriels sur un serveur « fait maison » pendant longtemps, je commençais à avoir du mal à suivre. Heureusement, des solutions faciles à prendre en main et à mettre à jour, et bien adaptées pour de l’auto-hebérgement de particulier sont apparues (YunoHost, FreedomBox pour parler de celles que j’ai testées et approuvées). Je ne recommanderais pas pour de l’hébergement pro, mais ça ronronne chez moi sans problème et sans prise de tête pour du courrier électronique, et même plus.

  • # autohébergement et haute dispo

    Posté par  . Évalué à 4.

    L'auto hébergement n'empêche pas la haute dispo.

    Mais j'avoue ça le complique un peu. Donc quand on n'a pas 2 domiciles, faut s'associer à un proche/amis, idéalement tout aussi versé dans le truc pour qu'il accepte d'avoir un truc allumé 24/7 chez lui, pour autohéberger la partie redondante et/ou le monitoring/backup.

    Parce que bon ton serveur a pêté, t'aurais pu avoir de la redondance à la maison et ça aurait potentiellement pu te sauver mais ça aurait pu être une panne internet: chez moi les fibres ne courrent pas à l'intérieur des murs, mais sur 25 mètres autour des plinthes et cadrant de portes de la cuisine au salon, à l'air libre et seulement guidées plus ou moins souplement par quelques crochets métaliques. Et évidemment j'ai des enfants dont les mains sont baladeuse, je les vois souvent accrocher la fibre par mégarde, jusqu'à maintenant sans gravité.

    Et finalement quand on fait de l'autohébergement on constate aussi que le cloud c'est pas forcément si mal. Pas forcément pour les services hébergés, mais par exemple pour une décentralisation de sauvegarde ou le monitoring. C'est pas si mal d'avoir des sondes dans le nuage qui peuvent via un autre service t'envoyer un sms (ou tout autre truc indépendant des services que tu hébèrge) en cas de problème.

    • [^] # Re: autohébergement et haute dispo

      Posté par  (site Web personnel) . Évalué à 4.

      j'ai pas mal de services auto hébergés et si ça ne coutait pas un bras je louerai un serveur, en trouvant un qui m'assure les questions de backup. Déjà ça prendrait moins de place chez moi, au prix du mètre carré bon ça se tient. Et puis c'est vrai que certains être humais peuvent s'intéresser au logiciel sans s'intéresser au matériel ; s'il y a une défaillance matos sur mon serveur ça va me gaver grave.

      Et oui bien sûr c'est arrivé avant que je parte en vacances, histoire de n'avoir plus aucun service durant la durée des vacances… pas grave j'héberge des trucs plutôt loisirs ( média, rss, ..) - mais dans le cas d'un serveur mail il ne me viendrait même pas à l'idée d'utiliser du matos à la maison;

      En plus j'ai beau faire des backups ; ce sont des backup chez moi. Bon les incendies c'est pas tous les deux jours mais ce serait trop con.

  • # L'hébergement à la maison c'est compliqué

    Posté par  (site Web personnel) . Évalué à 9.

    La moitié de tes problèmes sont liés à l'hébergement à la maison. Gestion du hardware qui pète, FAI peu accommodant sur ce cas d'usage, Internet qui lâche, etc.
    Entre le serveur qui plante toujours pendant les vacances, l'alim qui pète et les soucis d'ADSL, j'ai laissé tomber. Quelques déménagements plus tard je suis aussi bien content de ne pas avoir à me trimballer mon serveur de mail en plus.

    J'héberge mon mail moi-même, mais dans une infra cloud. Depuis, j'ai 0 problème d'infra, et un ou deux problème de spam/non réception à gérer par an.

  • # Je confirme

    Posté par  . Évalué à 4.

    C'est franchement dur, à tel point que j'ai abandonné après plusieurs tentatives infructueuses il y a une bonne dizaine d'années. Je ne pense d'ailleurs pas que la situation se soit améliorée depuis malheureusement.

    Moi, j'ai fait le choix du payant avec Tutanota et eux qui sont pros ont des soucis de disponibilités en raison d'attaques DDOS. Même en payant j'ai du mal à conseiller une adresse gérée par des pros.

    Pourtant, l'auto-hébergement est une nécessité pour que l'Internet ne soit pas le Minitel 2.0, j'en suis convaincu.

    • [^] # Re: Je confirme

      Posté par  (site Web personnel) . Évalué à 6.

      Sinon, il y Lautre.net pour 23€ par an de cotisation, association qui milite pour la neutralité du Net en particulier.

      Et pour de l'auto-hébergement, AlternC est une solution viable, qui a aussi pas mal évolué.

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # iRedMail

    Posté par  . Évalué à 5.

    En fait j'ai fait exactement cela il y a deux mois. J'ai utilisé iRedMail et c'était vraiment simple à mettre en place.

    La partie la plus compliquée a été de faire passer mes mails chez Hotmail. Il faut aussi s'assurer d'avoir DKIM, DMARC et SPF ainsi qu'une IP non blacklistée. Eviter de voir ses mails attérir dans le spam folder est vraiment le plus compliqué.

    Mes raisons étaient de passer toute mon infra sur AWS. J'ai pris une instance ARM avec contrat de 3 ans et cela m'a couté 34 dollars pour 3 ans d'avoir une machine à moi de manière permanent avec ssh, IP statique, … dur à battre…

    • [^] # Re: iRedMail

      Posté par  . Évalué à 2. Dernière modification le 12/12/20 à 14:49.

      et ca ? https://poste.io/ ; ha zut, ca n'est pas vraiment Free.

      • [^] # Re: iRedMail

        Posté par  . Évalué à 4.

        en voici un autre embarqué dans du container docker, tout-en-un : https://mailu.io/

        • [^] # Re: iRedMail

          Posté par  (site Web personnel) . Évalué à 1.

          Mailu est vraiment bien, je l'ai mis en place chez moi, ça a mis 1 bonne heure pour régler la conf correctement (ce qui est vraiment rien pour une stack mail complète).

          En plus il a le bon goût de ne pas mettre les données dans un volume docker mais dans un répertoire de l'hôte, ce qui est fort pratique pour les gens habitués à aller taper dans leur Maildir à la main.

      • [^] # Re: iRedMail

        Posté par  . Évalué à 1. Dernière modification le 13/12/20 à 07:49.

        Je connaissais pas mais en regardant je trouves iRedMail bcp plus clair et documenté, et en plus il utilise les paquets du système plutôt que des containers venus d'ailleurs ce qui lui a permis de fonctionner pour mon Ubuntu ARM qui est un système pas trop offert par les containers d'habitude (qui visiblement ont tous 2 ans si j'en crois Docker Hub)

  • # Tuto: comment résoudre la moitié des problèmes de ce journal en 5 minutes !

    Posté par  . Évalué à 4.

    Et bien en fait, j'ai menti, ca prend un peu plus que 5 min et c'est pas gratuit.

    Le principe est très simple, c'est de ne pas s'auto-hébergé sur sa connexion maison mais de prendre deux serveurs dédiés en datacenter.
    Entre les coupures intempestives d'internet à cause d'une raison X ou Y, de la grande tante de l'arrière petite fille qui débranche le serveur pour passer l'aspirateur, les blacklistages des connexions résidentielles les problèmes de rDNS (apparemment, chez Free c'est plus ou moins officiellement cassé sur les connexions fibre, sauf quand on est chanceux), c'est assez exaspérant.
    A côté, deux dédiés en datacenter, ca coute moins cher que votre connexion internet (merci OVH) faut juste éviter de les prendre en même temps pour essayer de les avoir dans des datacenters différents. Là-bas, peu de coupure d'internet ou d'électricité (ou alors c'est la moitié du web francais qui est en rad), pas de problème d'ip résidentielle, un rDNS qui marche, etc.
    Pourquoi deux dédiés et pas un seul ? Et pourquoi essayer de les avoir dans des DC différents ? Pour limiter les risques de pannes. De préférence, déployer ces serveurs sous des distros, voir OS différents. Pour la synchro des courriels entre les serveurs, pleins de solutions existent, je me contenterais de citer Syncthing pour un setup simple.

    Est-ce que ce setup m'a totalement évité les pannes ? Non, j'ai largement eu le loisir de casser mes serveurs. J'ai juste évité que les deux le soit en même temps, du coup je n'ai pas de pertes de courriels.

    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 !

    Je ne pense pas que ca soit courant comme proposition de la part de son ex-employeur. Mais dans ce cas, ne serait-il pas plus judicieux à la place de mettre une réponse automatique indiquant aux contacts de t'écrire sur une autre adresse ? Que se passerait-il si, soudainement, ton ancien employeur changeait de solution de courriels et ne permettait plus la redirections de ceux qui te sont destinés ?

    Emacs le fait depuis 30 ans.

    • [^] # Re: Tuto: comment résoudre la moitié des problèmes de ce journal en 5 minutes !

      Posté par  (site Web personnel) . Évalué à 2. Dernière modification le 11/12/20 à 22:38.

      Je ne pense pas que ca soit courant comme proposition de la part de son ex-employeur. Mais dans ce cas, ne serait-il pas plus judicieux à la place de mettre une réponse automatique indiquant aux contacts de t'écrire sur une autre adresse ? Que se passerait-il si, soudainement, ton ancien employeur changeait de solution de courriels et ne permettait plus la redirections de ceux qui te sont destinés ?

      Ben comme tu dis, c'est déjà rare que ce soit mis en place, alors pouvoir négocier les conditions de cette mise en place, il faut pas trop y compter (je vois pas comment mettre en place ta solution de mon côté puisqu'il faut déjà que les mails me parviennent).
      Si l'ancien employeur arrête la redirection, les personnes souhaitant m'écrire n'auront plus qu'à chercher mon adresse à jour sur un moteur de recherche… C'est assez courant en fait. Du coup il faudrait plutôt interroger la pertinence de mettre des adresses mail institutionnelles de chercheurs précaires sur les articles de recherche…

  • # Compromis: Kimsufi + Yunohost

    Posté par  . Évalué à 9.

    C'est pas de l'auto-hébergement strict, mais tu peux louer un serveur à pas cher.
    En ce qui me concerne, c'est un Kimsufi.

    Configuration et maintenance: j'ai installé Yunohost, et je n'ai quasiment plus à m'en soucier.
    J'ai juste ajouté des jokers pour les adresses email ("." et "_") pour me faire des adresses dédiées à la volée à chaque service auquel je m'inscris.

    Je fais des backup toutes les semaines vers un service dans les nuages (avec un script que je lance encore à la main), mais j'envisage de passer à quelque chose de plus modulaire, fréquent, et automatisé.
    Je vais certainement aussi me faire un serveur de secours. Je crois qu'il y a une app dans Yunohost pour ça aussi.

    Tant que rien ne pète, ça ne me prend pas plus de temps que ça. Je touche du bois…

  • # La supervision, c'est bien, mangez-en !

    Posté par  . Évalué à 8. Dernière modification le 12/12/20 à 13:07.

    Pas mal de problèmes qui pourraient être évités avec de la supervision :
    - le scan régulier des blacklist pour vérifier que l'on n'est pas dedans
    - l'état du serveur, pour éviter le crash silencieux
    - la validité de ton super certificat TLS (le script ACME/Let's Encrypt qui s'en occupe peut tomber en panne…)

    Et j'en passe…

  • # C'est nul mais c'est possible

    Posté par  (site Web personnel) . Évalué à 10.

    Les mails est le seul système de communication électronique universel que tu peux héberger toi même.

    Essaye de devenir ton propre fournisseur SMS :-)

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # De la bonne manière pour avoir de la disponibilité

    Posté par  . Évalué à 4.

    Alors je dirais que ton problème c'est que tu n'as pas abordé l'auto-hébergement de la bonne manière : selon moi il faut toujours prévoir de la disponibilité (je ne vais pas appeler ça « haute » disponibilité, ça serait mentir) avec des tiers. L'e-mail et le DNS ont justement été conçus dès le début pour ça, autant en profiter !

    Et donc pour l'e-mail, toujours prévoir un MX secondaire qui te garde tes mails au chaud ailleurs pendant que le premier est hors-ligne ou en galère. Ça résout ton 1 (partiellement, il peut toujours arriver que le primaire soit on-line mais renvoie une erreur pour une autre raison), ton 4 (tu peux même avoir une autre secondaire chez toi, aussi, et le passer en primaire en cas de besoin ; oui, pour ça il te faudra plusieurs IP, mais IPv6 sais faire, et les gros fournisseurs aussi), et ton 5. Perso, j'ai tenu un déménagement (que tu évoques dans les commentaires) off-line de 15 jours sans problème (j'avais même la délégation DNS sur cette ligne, et avec des zones correctement en cache les NS secondaires ont répondu pendant mon absence sans problème, tout comme le MX secondaire).

    Pour le reverse en 2, il faut effectivement être chez un FAI correct, et ça n'est pas facile à trouver, mais ça se fait. Et ça résout potentiellement ton 6 si ça n'est pas un des gros qui classe bêtement tout le monde en « résidentiel ».

    Quant au 3, SPF, le problème est dans la question : SPF veut combattre le spam, certes, mais tue le principe décentralisé (et non-authentifié, d'où le problème du spam) de l'e-mail. Donc oui, si tu t'y conformes, tu vas forcément tomber dans ce genre de problème un jour. Il faut donc accepter le spam…

    Bon, je ne vais pas dire que ça n'est pas du bouleau de gérer tout ça, mais comme ont dit certains autres, c'est du boulot au début, mais une fois bien fait la maintenance est relativement légère.

    Merci en tous cas de tes retours, c'est toujours intéressants de lever les problèmes, car tout n'est pas tout blanc dans l'auto-hébergement, c'est sûr.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.