After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won.

/after-self-hosting-my-email-for-twenty-

  • @biggrizzly
    BigGrizzly CC BY-NC-SA
    3
    @ericw
    @george
    @jeanmarie
    3

    Gmail And Yahoo Inbox Updates & What They Mean For Senders | Mailgun
    ▻https://www.mailgun.com/blog/deliverability/gmail-and-yahoo-inbox-updates-2024

    The requirement from both Gmail and Yahoo is to set up strong authentication with “SPF, DKIM, and DMARC for your domain.” Previously not a requirement, this move towards implementing DMARC is something Sinch Mailgun’s Jonathan Torres had already predicted in our guide on email security and compliance.

    (...) For­ DMAR­C you will­ need­ to set at mini­mum a p=no­ne poli­cy. (...)

    Il ne suffit plus d’avoir SPF et DKIM, il va aussi falloir implémenter l’enregistrement DMARC, en mode « none » au minimum.

    BigGrizzly CC BY-NC-SA
    • @flofoi
      FloFoi

      Je ne comprend pas pourquoi le standard mail n’évolue pas.
      Si les corps de mails étaient stockés sur le serveur d’émission et non sur celui de réception, le stockage des spam serait à la charge de l’émetteur. Du coup :
      1. les serveurs de réception pourraient accepter beaucoup plus facilement les entêtes
      2. le corps pourrait être scanné pour les spams uniquement lorsque l’utilisateur demande l’affichage d’où une réduction de charge.
      3. le volume global de transaction et de stockage serait beaucoup plus faible (seuls les entêtes seraient copiés pour un mail à plusieurs destinataire)

      En fait on est resté sur un modèle basé sur les lettres papiers.

      FloFoi
    • @klaus
      klaus++

      After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won.
      Carlos Fenollosa
      ►https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-
      Le problème est plus grave. Das Internet ist kaputt. L’exclusion des petit prestataires est sytématique. Depuis au moins deux ans je ne propose plus l’hébergement de boîtes email (sur mes serveurs). Ce monsieur espagnol explique pourquoi.

      September 04, 2022 — Many companies have been trying to disrupt email by making it proprietary. So far, they have failed. Email keeps being an open protocol. Hurray?

      No hurray. Email is not distributed anymore. You just cannot create another first-class node of this network.
      ...

      #monopoles #oligopoles #email #internet

      klaus++
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      De mon côté, depuis 2 ans, ça va mieux.

      Mieux : les serveurs Microsoft se font jeter par Google, et réciproquement. Parce que ponctuellement, les uns et les autres ne sont pas capables de respecter les RFC. Quand ça tombe sur un client que j’ai été contraint de migrer vers MS, ça fait plaisir de pouvoir lui dire que Microsoft n’est pas la panacée non plus.

      Ça va mieux au sens où MS et Google ont cessé de filtrer sur des règles arbitraires (surtout MS d’ailleurs). Il reste Orange, avec des règles absurdes, mais c’est vraiment rare qu’on doive intervenir.

      On en reste de notre côté à 3 points à contrôler :
      1) Les DNS conformes : SPF, DKIM, DMARC ; parfois, DKIM est compliqué, selon l’hébergement final utilisé
      2) Les IP émettrices identifiées et en nombre limité : ici, on concentre les flux sur deux IP RIPE
      3) La surveillance des DNSBL, pour être toujours au vert ; pas mal de temps qu’on n’a pas eu besoin de faire quoi que ce soit à ce sujet

      BigGrizzly CC BY-NC-SA
    • @jeanmarie
      jeanmarie CC BY-NC-SA

      De ce que je lis ici, l’enregistrement #DMARC est imposé uniquement si on envoie plus de 5000 e-mails par période de 24 heures sur un service (GMail ou Yahoo donc) :

      ▻https://www.it-connect.fr/fevrier-2024-google-et-yahoo-imposent-utilisation-spf-dkim-dmarc

      En dessous, la norme reste SPF et/ou DKIM. Par contre, "Tous les domaines et adresses IP utilisées pour émettre des e-mails doivent avoir un enregistrement DNS de type « PTR » (reverse) correctement configuré" et ça, je ne sais pas trop ce que ça veut, si quelqu’un·e a des infos...

      Bon, j’imagine que ce n’est qu’une première étape et ça sera généralisé à terme.

      jeanmarie CC BY-NC-SA
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      L’enregistrement PTR, c’est de s’assurer que si ton serveur de messagerie répond qu’il se nomme toto.domain.tld, il faut que l’IP publique émettrice réponde « toto.domain.tld » à une recherche inverse.

      En mode Linux, avec la commande host, je vérifie la résolution dans les deux sens, nom vers IP et IP vers nom (PTR) :

      $ host seenthis.net
      seenthis.net has address 217.182.178.243
      $ host 217.182.178.243
      243.178.182.217.in-addr.arpa domain name pointer seenthis.net.

      Et là, je vérifie ce que répond le serveur de messagerie dans sa réponse d’accueil :
      $ nc seenthis.net 25
      220 seenthis.net ESMTP Postfix (Debian/GNU)

      Tout est conforme, donc.

      BigGrizzly CC BY-NC-SA
    Écrire un commentaire
  • @arno
    ARNO* ART LIBRE

    Encore une alerte de mon hébergeur qui me dit de résoudre ceci (au risque de voir mon serveur désactivé) :

    Madame, Monsieur,

    L’Agence nationale de la sécurité des systèmes d’information (ANSSI : [▻https://www.ssi.gouv.fr/]) vous contacte car un service LemonLDAP-NG présent sur des réseaux vous appartenant sont susceptibles d’être concernés par une vulnérabilité critique.

    Le CERT-FR vous recommande de prendre en compte ces informations dans les meilleurs délais. Cette vulnérabilité pourrait être exploitée de façon imminente, le risque de compromission est donc élevé, c’est pourquoi nous prenons l’initiative de vous transmettre ce signalement.

    Références :
    Avis de sécurité LemonLDAP-NG du 28 mars 2023
    ▻https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/releases/v2.16.1
    Publication de CERT-FR CERTFR-2023-AVI-0300 du 12 avril 2023
    ▻https://www.cert.ssi.gouv.fr/avis/CERTFR-2023-AVI-0300
    Systèmes affectés
    L’éditeur indique que les systèmes suivants sont affectés :

    LemonLDAP-NG versions antérieures à 2.16.1
    Détails de la vulnérabilité et conséquences
    La vulnérabilité CVE-2023-28862 permet à un attaquant de contourner l’authentification multifacteur. Son score CVSSv3 est de 9,8 (sur 10).

    Evolution de la menace
    En date du 19 avril 2023, l’ANSSI n’a connaissance ni de code d’exploitation public, ni d’exploitation active de la vulnérabilité CVE-2023-28862.

    Recommandations
    L’ANSSI recommande fortement de procéder aux opérations suivantes :

    appliquer la mise à jour dans les meilleurs délais.

    Rappels

    Le guide d’hygiène informatique : ▻https://www.ssi.gouv.fr/uploads/2017/01/guide_hygiene_informatique_anssi.pdf

    Sauf que je ne trouve aucune trace de ce LemonLDAP-NG sur ma machine. En fait, je ne suis même pas certain de ce qu’il faut faire pour vérifier que ce n’est pas sur la machine (j’ai fait par exemple un locate lemonldap, qui ne me retourne rigoureusement rien).

    ARNO* ART LIBRE
    • @emanuel
      Bourbaki

      C’est développé par la gendarmerie nationale.
      Si tu es sous debian regarde si le paquet lemonldap-ng est installé.
      Pour passer en 2.16 c’est un paquet testing en stable on est en version 2.0.11.

      Bourbaki
    • @arno
      ARNO* ART LIBRE

      C’est bien une Debian, mais si je fais :

      apt-get remove lemonldap-ng

      ça me dit que je l’ai pas.

      Je ne comprends pas comment eux détecteraient que j’ai ce package installé sur mon serveur ? Il y a une méthode pour le savoir de l’extérieur ? (Que je pourrais donc tester ?) Ou bien que j’ai une Debian, et du coup ils écrivant à tous les gens qui ont une Debian ?

      ARNO* ART LIBRE
    • @klaus
      klaus++

      J’ai eu un message comparable de la part de notre BSI (▻https://www.bsi.bund.de) à cause d’une instance Owncloud qui n’était pas accessible publiquement. Je leur ai écrit en les remerciant en ajoutant que mon installation n’était pas concernée par la faille de sécurité connue de la version en question. Ceci m’a valu une réponse prèsque agressive de leur part.

      Depuis je les considère comme « just another spammer » et j’ai envoié un message d’avertissement à mon hébergeur afin de l’empêcher de suivre leurs ordres et recommandations en ce qui me concerne. Toutefois on ne peut jamais savoir comment et s’il prend en compte mon message, alors je suis obligé de me coltiner le maintien de clônes des sites du serveur public afin de pouvoir les activer au cas où.

      C’est le genre d’ennuis qui te font arrêter de fournir des services internet à des clients.
      cf. ►https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-
       :-(

      #internet de #merde

      klaus++
    Écrire un commentaire
  • @supergeante
    Supergéante

    After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won.
    Email is now an oligopoly, a service gatekept by a few big companies which does not follow the principles of net neutrality.
    ►https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-

    This doesn’t only affect contrarian nerds
    No need to trust my word. Google has half a billion results for “my email goes directly to spam”. 
Search any technical forum on the internet and you will find plenty of legitimate people complaining that their emails are not delivered.

    What’s the usual answer from experienced sysadmins? “Stop self-hosting your email and pay [provider].”

    Having to pay Big Tech to ensure deliverability is unfair, especially since lots of sites self-host their emails for multiple reasons; one if which is cost.

    Newsletters from my alumni organization go to spam. Medical appointments from my doctor who has a self-hosted server with a patient intranet go to spam. Important withdrawal alerts from my bank go to spam. Purchase receipts from e-commerces go to spam. Email notifications to users of my company’s SaaS go to spam.

    You can no longer set up postfix to manage transactional emails for your business. The emails just go to spam or disappear.

    (...)
    Big email servers permanently blacklist whole IP blocks and delete their emails without processing or without notice. Some of those blacklists are public, some are not.

    When you investigate the issue they give you instructions with false hopes to fix deliverability. “Do as you’re told and everything will be fine”.

    Supergéante
    Écrire un commentaire
  • @biggrizzly
    BigGrizzly CC BY-NC-SA
    10
    @colporteur
    @ericw
    @alexcorp
    @arno
    @grommeleur
    @fil
    @7h36
    @touti
    @b_b
    @monolecte
    10

    After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won.
    ►https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-

    Many companies have been trying to disrupt email by making it proprietary. So far, they have failed. Email keeps being an open protocol. Hurray?

    No hurray. Email is not distributed anymore. You just cannot create another first-class node of this network.

    Email is now an oligopoly, a service gatekept by a few big companies which does not follow the principles of net neutrality.

    I have been self-hosting my email since I got my first broadband connection at home in 1999. I absolutely loved having a personal web+email server at home, paid extra for a static IP and a real router so people could connect from the outside. I felt like a first-class citizen of the Internet and I learned so much.

    BigGrizzly CC BY-NC-SA
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      Tout à la fois.
      D’un côté, ce qui rend le service : Dovecot+Postfix+DKIM+SPF+SOGo+RoundCube
      De l’autre, ce qui permet de gérer les comptes et les flux : aujourd’hui, on utilise ISPConfig et Plesk. Mais les deux sont moyens, par rapport à ce que propose par exemple MS, pour ne pas les nommer.
      Et il y a aussi la dimension archivage pour laquelle je ne connais pas d’outil opensource évident/convaincant.

      BigGrizzly CC BY-NC-SA
    • @rastapopoulos
      RastaPopoulos CC BY-NC

      C’est sur la formulation je vois pas comment il peut y avoir « UNE solution opensource de gestion », ça n’a vraiment rien à voir la partie serveur et la ou les parties clientes non ? C’est complètement illusoire une unique solution unifiée qui aurait tout de bout en bout, ya que les énormes monopoles qui font ça justement. Le principe dans le libre ça a toujours été « on fait une chose et on le fait bien », avec des protocoles interopérables. Donc bah sur toute la chaine la majeure partie des éléments ya des trucs libres pour, qui sont loin d’être parfaits et qu’il faudrait améliorer (notamment en ergo pour les webmails), mais pas un énorme monstre unique.

      RastaPopoulos CC BY-NC
    • @biggrizzly
      BigGrizzly CC BY-NC-SA

      ISPConfig ou Plesk le font, mais à mon sens, ils le font mal. Ils n’intègrent pas SOGo non plus d’ailleurs.

      Ils le font mal parce qu’ils font tout à la fois, DNS, Web, et enfin le mail, comme si c’était une verrue.
      Pour ISPConfig, leur interface de gestion fait le travail, on peut désactiver tout ce qui concerne DNS et Web, mais... c’est un responsive médiocre avec des erreurs de conception qui font soupirer fort, et il n’y a pas vraiment d’API pour tenter d’en créer une autre plus moderne, et la navigation est médiocre, avec par exemple impossibilité d’utiliser le bouton « Précédent » du navigateur. Des petits détails qui irritent fort au quotidien, et font fuir les utilisateurs qui préfèrent le backoffice Microsoft.

      Si je parle d’une solution qui intègre tout, c’est pour enfin pouvoir proposer un service concurrent de ce que proposent les GAFAM sans le côté déprimant de l’opensource où il manque toujours qq chose pour que ça fonctionne juste sans difficultés.

      Là, sur ISPConfig, les alias de mails ne gèrent pas convenablement le DKIM des mails sortants. Par exemple. Et modifier la méthode de configuration de postfix pour le corriger obligerait à sortir du cadre de cette distribution, qui comme Plesk, prétend nous aider à tout faire (web, dns, conteneurs, .......), et pas seulement le mail.

      BigGrizzly CC BY-NC-SA
    • @b_b
      b_b PUBLIC DOMAIN

      L’article aborde plutôt le problème des méthodes utilisées par les « gros fournisseurs » pour « protéger » leur utilisateurs du spam, et la proposition de l’auteur est la suivante.

      I’m not asking for a revolution. Please hear my simple proposal out:

      – Let’s keep antispam measures. Of course. Continue using filters and crowdsourced/AI signals to reinforce the outputs of those algorithms.
      – Change blacklisting protocols so they are not permanent and use an exponential cooldown penalty. After spam is detected from an IP, it should be banned for, say, ten minutes. Then, a day. A week. A month, and so on. This discourages spammers from reusing IPs after the ban is lifted and will allow the IP pool to be cleaned over time by legitimate owners.
      – Blacklists should not include whole IP blocks. I am not responsible for what my IP neighbor is doing with their server.
      – Stop blackholing. No need to bounce every email, which adds overhead, but please send a daily notification to postmaster alerting them.
      – There should be a recourse for legitimate servers. I’m not asking for a blank check. I don’t mind doing some paperwork or paying a fee to prove I’m legit. Spammers will not do that, and if they do, they will get blacklisted anyways after sending more spam.

      b_b PUBLIC DOMAIN
    Écrire un commentaire