Gmail And Yahoo Inbox Updates & What They Mean For Senders

/gmail-and-yahoo-inbox-updates-2024

  • 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.

    • 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.

    • 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

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

      $ 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.