Gmail And Yahoo Inbox Updates & What They Mean For Senders

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