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

Mais c’est du pur cancel !

Donc, boycott Microsoft outlook en bonne mesure de rétorsion proportionnée ?

J’ajoute que depuis 24 heures, on doit se prendre une nouvelle surcharge de bots absurdes. Pas vraiment le loisir de m’en occuper, mais je vais tâcher de comprendre de quoi il s’agit sans trop tarder.

Rien d’étonnant
►https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-
...

Email is now an oligopoly, a service gatekept by a few big companies which does not follow the principles of net neutrality.
...
Over time I realized that residential IP blocks were banned on most servers. I moved my email server to a VPS. No luck. I quickly understood that self-hosting email was a lost cause. Nevertheless, I have been fighting back out of pure spite, obstinacy, and activism. In other words, because it was the right thing to do.
...
But my emails are just not delivered anymore. I might as well not have an email server.

#email #oligopoles #monopolisme

La circulation des emails vers Microsoft est rétablie. Je n’ai rien fait.

Si à une époque, l’arbitraire des GAFAM était en quelque sorte la règle, en ce moment, il y a tout de même une forme de bonne volonté pour ne pas trop aller à l’encontre de la neutralité du net...

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.

Du coup, faut qu’on fasse des trucs avec nos mails d’hébergeurs ?

Faut faire qq chose si tu gères ton email sur ton propre nom de domaine.

en ce qui me concerne : baisser les bras, abandonner, lâcher l’affaire

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

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

Juste pour mémoire, l’enregistrement DNS minimaliste à créer est le suivant :
_dmarc          IN      TXT     "v=DMARC1; p=none"

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.

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) :

#email #self-hosting #autogestion #internet #SPF #DKIM #DMARC

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.

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

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 ?

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

Ici aussi ▻https://seenthis.net/messages/971980 :)

Merci. Ces pratiques mettent aussi en péril les petits hébergeurs militants qui peinent à suivre les règles obscures et changeantes des crirères de diffusion des mails de gmail et d’hotmail. Un vrai casse-tête... qui pousse vers soit les messageries à tout faire fermées...

Le souci majeur, à mon sens, ce sont les IP sortantes.

On pourrait sans doute mutualiser des ressources, entre hébergeurs indépendants. De notre côté, nous avons des stratégies sur ce point précis qui font que nous nous en sortons mieux qu’à d’autres époques.

Yep, chez Infini on a des problèmes car on exploite pas assez les 8 IPs qu’on a à dispo, c’est une des points sur lequel on doit travailler prochainement pour que les piles de mails ne stagnent pas...

C’est un texte important. Voici donc une traduction en allemand. ▻https://seenthis.net/messages/975941

Ici, on ne s’avoue pas vaincu, mais on est en attente d’une vraie solution opensource de gestion des emails. On a envie de la créer. Mais c’est tout de même un sacré investissement.

De gestion dans quel sens @biggrizzly, de quelle partie ? Serveur, client, webmail ?

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.

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.

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.

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.