#spf

  • #Degooglisation : question - Beaucoup de mes contacts ne reçoivent pas les mails que j’envoie depuis l’une ou l’autre adresse dégooglisée. Ces mails sont soit totalement bloqués soit atterrissent dans les spams, m’obligeant à garder un adresse google en back up. Avez-vous déjà rencontré le problème, comment faites vous pour le régler/contourner le retour à ggl. Merci #seenthis.

    • Figurez-vous que cette semaine, j’étais absent, et c’est le moment que hotmail a choisi pour griller l’IP d’un de mes serveurs.

      Dans ce cas là, mes utilisateurs reçoivent ce gentil message... et ils comprennent que leur mail n’a pas été transmis, ce qui est plutôt positif, entre nous...

      bounced (host eur.olc.protection.outlook.com[XX.XX.XX.XX] said: 550 5.7.1 Unfortunately, messages from [XX.XX.XX.XX] weren’t sent. Please contact your Internet service provider since part of their network is on our block list (S3140). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [PU1APC01FT014.eop-APC01.prod.protection.outlook.com] (in reply to MAIL FROM command))

      Mais les utilisateurs, ils se tournent alors vers moi. Et ils me disent que ça ne va pas. Et j’en ai plusieurs des utilisateurs...

      Microsoft, qui gère Hotmail, a mis en place des outils pour aider à résoudre ces blocages. Et on finit par obtenir le déblocage. J’étais absent, je n’ai pas réussi à débloquer rapidement... il a fallu 4 jours... c’est énorme. Et il a fallu s’y reprendre à 3 fois.

      D’expérience, chez Google, ils peuvent refuser de prendre en charge un message pendant plusieurs heures/jours. Mais ils finissent en général par l’accepter. C’est le cas lorsque trop de messages ont été transmis en même temps depuis un serveur particulier, et que ces messages sont louches ou trop nombreux à la fois.

      Free, c’est plus opaque. Ils bloquent... avec un délai de 24 heures ou plus. Puis ils débloquent... et ils rebloquent, parce qu’ils considèrent que c’est toujours du spam... Les mails du serveur SeenThis vers Free ont été bloqués pendant plusieurs mois de ce fait, ils étaient remis... avec plusieurs jours/semaines de retard. Jusqu’à ce que mes mails de demande de prise en compte de la spécificité du serveur transmis à l’adresse dédiée à ces demandes aboutissent... sans pour autant qu’un quelconque échange avec un humain ait eu lieu.

      Mon problème le plus cruel est celui que je rencontre au quotidien avec les mails transmis chez Microsoft (tous les utilisateurs Office 365). J’ai des utilisateurs hébergés sur mes infras Linux qui ont un mal fou à communiquer avec Microsoft. Et pour cause, il y a des filtres sur des critères impossibles à deviner... et qui font que certains noms de domaines expéditeurs ont leurs mails qui passent systématiquement en « courrier indésirable » quand ils arrivent sur Office 365. Pire... apparemment, parfois, des mails n’arrivent tout simplement pas. Dans ces cas là, je demande les détails techniques à mon utilisateur... heure, expéditeur, destinataire, et je vérifie dans les logs. Et systématiquement, je transmet à mon client les accusés de réception de la part de Microsoft. Le mail en question a bien été reçu par Office 365, mais il a été ensuite... effacé ? Je n’en sais rien. Et le support Microsoft ne veut/peut pas répondre. Quand j’en cause avec un humain, c’est forcément la faute de mes IP dont la réputation est mauvaise... des accusations sans éléments factuels...

      Le monde du mail est une jungle où chacun expérimente les solutions les plus absurdes en décidant qu’il est légitime de supprimer des mails sans avertir personne.

      Quand je suis parano, j’en viens à penser qu’il s’agit d’une stratégie volontaire. Un de mes clients, qui n’en pouvaient plus de devoir demander à ses interlocuteurs d’aller dans le dossier des Courriers indésirables, a fini par me demander à être migré chez Office 365. C’est une aberration à mon sens. Mais c’est comme cela que de plus en plus de mes clients vont chez Microsoft. Je gagne toujours de l’argent, mais ça m’écœure.

      Anecdote : en même temps que je vous cause de mes déboires de messagerie Internet, j’ai des logs en visualisation :

      «relay»: «tigre.interieur.gouv.fr»,
      «to»: «secretariat-prefet@rhone.pref.gouv.fr»,

      Les préfectures ont un serveur de messagerie dont le nom de domaine est « tigre ». Comme le surnom de Clémenceau ?

    • Très juste @gastlag, outil utile entre gens civilisés. Si on a 10/10 et que les mails ne passent pas, c’est qu’on ne peut pas faire grand chose.
      Et c’est bien mon problème systématiquement 10/10 (car SPF, DKIM, DMARC, pas d’image, pas d’url, pas de signature à rallonge...) et Office 365 qui te marque « SPAM » dans l’entête reçu.

    • Pour un conseil complémentaire à Gastlag, c’est qu’il faut demander à ton hébergeur d’activer SPF et DKIM sur ton domaine. Et de lui demander à vérifier que ses IP d’émission de mails sont bien « vertes » sur les principales listes noires. Pour les admins de serveur qui ne connaitraient pas, on utilise ces deux outils :
      https://rblwatcher.com
      https://mxtoolbox.com/blacklists.aspx

      Le second, sachez que c’est celui vers lequel le support Microsoft renvoie quand il vous explique que vos mails ne peuvent pas fonctionner, parce que l’IP qui héberge votre site Web est dans le rouge sur une des 70 listes disponibles (l’IP du site de ma société n’est pas utilisée pour envoyer des mails, d’où l’aspect incongru de la réponse du support...)

    • J’ai des potes qui utilisent une adresse gmail (si, si :-D). A une époque je n’avais plus que 7/10 au test, à cause d’une config que j’avais pétée en déménageant le serveur (spf je crois)... Après correction, malgré le retour du 10/10 évoqué plus haut, les mails de mon serveur arrivaient encore dans leurs SPAM... Retroussage de manches, adresses de test, etc. La « solution » super facile : les contacter pour qu’ils retirent/effacent du dossier SPAM tous les mails légitimes qui s’y trouvent et tous ceux que je leur avais envoyé en particulier...
      Hotmail fonctionne parfois, parfois pas... J’ai tenté d’y voir plus clair avec une voisine. A priori, il faut suivre un peu les services qui listent les serveurs/IP spammeurs et réagir à chaque fois puis attendre... Je fais ça de temps en temps du coup (et je pense sérieusement à basculer les mails sur un service dédié...). Mais là aussi il semble qu’on dépende du fait d’avoir des mails dans les dossiers SPAM du destinataire...

    • J’ai des potes qui utilisent une adresse gmail (si, si :-D). A une époque je n’avais plus que 7/10 au test, à cause d’une config que j’avais pétée en déménageant le serveur (spf je crois)... Après correction, malgré le retour du 10/10 évoqué plus haut, les mails de mon serveur arrivaient encore dans leurs SPAM... Retroussage de manches, adresses de test, etc. La « solution » super facile : les contacter pour qu’ils retirent/effacent du dossier SPAM tous les mails légitimes qui s’y trouvent et tous ceux que je leur avais envoyé en particulier...
      Hotmail fonctionne parfois, parfois pas... J’ai tenté d’y voir plus clair avec une voisine. A priori, il faut suivre un peu les services qui listent les serveurs/IP spammeurs et réagir à chaque fois puis attendre... Je fais ça de temps en temps du coup (et je pense sérieusement à basculer les mails sur un service dédié...). Mais là aussi il semble qu’on dépende du fait d’avoir des mails dans les dossiers SPAM du destinataire...




  • gmx.de und web.de haben Mail-Rejects durch SPF
    https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-rejects-durch-spf


    Comment vivre avec les attitudes aléatoires des admins des géants du net quand tu n’est qu’un pauvre admin d’associations à but non lucratif. La gestion d’un serveur mail devient de plus en plus difficile à cause de la multiplication des méthodes employées contre le SPAM et surtout à cause de leur interprétations et implémentations différentes chez les grands fournisseurs de services mail.

    SPF „Bullshit und Broken by Design“
    Wer „-all“ einträgt muss mit Mailverlust leben wollen
    Absender können immer auch von anderen Mailservern kommen

    Warum SRS das Problem nicht löst
    1. Es gibt keine funktionierenden direkten SRS-Implementierungen in SMTP-Standardsoftware wie Postfix. Obwohl seit 10 Jahren immer wieder nachgefragt, hat Postfix-Erfinder Wietse Venema diesbezügliche Ansinnen stets abgelehnt. Kurz gefaßte Begründung: Weil’s Bullshit by Design ist und er kein Bullshit by Design implementiert. -Dem kann man nur zustimmen.
    2. Unklar ist, wie bei mehrfachen Weiterleitungen zu Verfahren ist. Was passiert, wenn der Empfänger bei B seinerseits auf Domain C weiterleitet? Zugegeben: Grundsätzlich kann diese SRS-Umschreibung immer wieder erfolgen. Aber praktisch bricht hier bei Kettenweiterleitungen über kurz oder lang das Chaos aus.
    3. Wie und auf welchen Weg sollen Bounces und andere Unzustellbarkeitsmeldungen „rückabgewickelt“ werden? Soll die Kette rückwärts wieder aufgedröselt werden?

    La raison pour le choix de SPF chez GMX et WEB.DE n’est pas intelligible.

    Warum machen GMX und web.de das?

    Tja, die Frage ist schwierig zu beantworten. Irgendwie hat SPF bei GMX und (weil es der gleiche Konzern ist) bei web.de einen guten Stand. Schon vor knapp 10 Jahren gab es am Rande des Anti-Spam-Summits des IT-Branchenverbands ECO im Schloß Biebrich Wiesbaden beim Social Event mit Rotwein und Fingerfood in der hessischen Staatskanzlei eine hitzige Diskussion zu SPF zwischen acht Postmastern der großen Provider, der ich beiwohnen durfte (naja: ich habe sie angezettelt). In Sachen SPF gab es nur einen einzigen Führsprecher: der Kollege von GMX. Und der beendete die durchaus sehr kompetent geführte Fachdiskussion nach einer guten Dreiviertelstunde mit den für mich unvergesslichen Worten: „Ja, SPF geht nicht, wir machen es aber trotzdem!“ Wirklich so gesagt und geschehen. Und da kann man dann nicht mehr diskutieren oder irgendwas verstehen wollen.

    Seitens GMX und web.de wird vermutlich auf SRS verwiesen und die Schuld (fast allen) anderen Providern zugeschoben, die halt bitteschön SRS hätten implementieren sollen. Nun, das ist ein Standpunkt und deren gutes Recht. Jedoch nicht viele Kollegen und Mailserver-Experten teilen diese Auffassung.

    Pourtant il y une solution mais elle n’est pas aussi simple à gérer que SPF.

    Was wirklich hilft: DKIM

    Die ganze leidige SPF-Diskussion ist vor allem deshalb so frustrierend, weil mit der Technik „Domain Keys Identified Mail“ (DKIM) eine Lösung zur Verfügung steht, die ebenfalls den Mißbrauch von Absendern wirkungsvoll einschränken kann (und nebenbei sogar noch die Unverfälschtheit der Mail sicherstellt). DKIM führt dazu eine Crypto-Signatur im Mailheader ein, also eine digitale Unterschrift des Mailservers. Dieser DKIM-Header ist nicht an die IP-Adresse gebunden und bleibt auch bei Weiterleitungen problemlos erhalten, solange die Mail unverändert ist (und das ist ja sehr positiv). Ähnlich wie beim SPF-Record kann der Domainbesitzer auch hier über DMARC festlegen, dass seine Mails wirksam DKIM-signiert sein müssen und wie mit Mails zu verfahren ist, denen diese Signatur fehlt. Mehr dazu im unten genannten Vortrag von uns.

    infos supplémentaires

    Sender Policy Framework
    https://en.wikipedia.org/wiki/Sender_Policy_Framework

    SPF Query Tool
    http://www.kitterman.com/spf/validate.html

    How To Implement SPF In Postfix
    https://www.howtoforge.com/postfix_spf

    DomainKeys Identified Mail
    https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

    Ubuntu+ISPConfig+DKIM | Howtoforge - Linux Howtos and Tutorials
    https://www.howtoforge.com/community/threads/ubuntu-ispconfig-dkim.72473

    ISPConfig – DKIM-Patch 1.0 – florian @it
    155 Gedanken zu “ISPConfig – DKIM-Patch 1.0”
    https://blog.schaal-24.de/ispconfig/dkim-patch-1-0

    How to send emails properly – florian @it
    https://blog.schaal-24.de/mail/emails-richtig-versenden/?lang=en

    #internet #email #SPF #DKIM #DMARC


  • RFC 7960 : Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows

    Le mécanisme #DMARC permet d’indiquer dans le #DNS la politique d’un domaine concernant l’authentification du courrier. Si je reçois un message prétendant venir de ma-banque.example, et qu’il n’est pas authentifié (ni #SPF, ni #DKIM, ni autre chose), comment savoir si c’est parce que ma banque est nulle en sécurité du courrier, ou bien parce que le message est un faux ? DMARC permet de répondre à cette question en publiant un enregistrement qui indique si le courrier est censé être authentifié ou pas. Comme toutes les techniques de sécurité, ce mécanisme est imparfait et il pose notamment des problèmes avec les messages indirects. Par exemple, si vous avez une adresse à votre ancienne université, alice@univ.example et que le courrier qui lui est adressé est automatiquement transmis à votre adresse professionnelle, alice@evilcorp.example, comment DMARC va-t-il réagir avec cette indirection ? C’est ce qu’explore ce #RFC.

    http://www.bortzmeyer.org/7960.html

    #sécurité_courrier_électronique

    • Et, en parlant des ré-expéditeurs, les listes de diffusion, pas vraiment prévues par DKIM , que faire pour elles ? Le RFC 6377 a déjà traité leur cas. Une technique courante est de modifier le champ From : pour mettre l’adresse de la liste, réduisant l’auteur original à un commentaire dans cet en-tête (avis personnel : je déteste ça). Comme cela rend difficile de répondre en privé au vrai auteur d’un message, l’ajout d’un Reply-To : peut aider. Une autre solution est d’emballer le message original dans une partie MIME message/rfc822. Cette partie resterait intact et le message emballant aurait comme expéditeur la liste. Mais peu de MUA savent afficher proprement ce genre de messages (spécialement dans le monde des mobiles).

      #sympa #infini


  • RFC 7372 : Email Authentication Status Codes

    Il existe désormais plusieurs techniques d’authentification du courrier électronique, comme #SPF ou #DKIM. Elles permettent à un serveur de messagerie, s’il le désire, d’accepter ou de rejeter le courrier entrant s’il échoue à ces tests d’authentification. Mais il n’existait pas jusqu’à présent de moyen standard de prévenir l’expéditeur, lors de la session #SMTP, de la raison de ce rejet. C’est désormais fait, avec ce nouveau #RFC, qui permet de renvoyer des codes de retour SMTP explicites, si on veut.

    http://www.bortzmeyer.org/7372.html



  • RFC 7208 : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

    On le sait, le #courrier_électronique, tel qu’il est spécifié dans les RFC 5321 et RFC 5322, ne fournit aucune authentification, même faible, de l’émetteur. Un expéditeur de courrier peut toujours prétendre être François Hollande <president@elysee.fr> et il n’y a aucun moyen de l’en empêcher. C’est parfois pratique mais c’est aussi un gros obstacle lorsqu’on tente de gérer le problème des courriers non désirés comme le spam. #SPF vise à diminuer cette facilité de frauder en permettant à un titulaire de nom de domaine de déclarer quelle(s) adresse(s) IP sont autorisées à envoyer du courrier pour ce domaine. Ce nouveau #RFC représente la première norme SPF (le premier RFC, le RFC 4408, était officiellement une expérimentation, sans le statut de norme.)

    http://www.bortzmeyer.org/7208.html

    Notez que SeenThis a un enregistrement SPF :

    % dig +short TXT seenthis.net
    "v=spf1 a mx ip4:88.190.11.5 ~all"

  • Bye bye #Gmail !
    http://www.framablog.org/index.php/post/2014/02/05/Bye-bye-Gmail

    Nous l’avions dit lors de notre campagne de don 2013 : 2014 sera l’année du « Moins de #Google et plus de Libre » Un semblant de planning a été dévoilé dans le récent billet intitulé « Manger la pâtée de son chien ». C’est le 1er février que nous devions nous séparer de #Gmail, et nous l’avons fait ! Nous sommes maintenant complètement autonomes pour la gestion de nos mails. Comme annoncé précédemmen […]

    C’est la dernière chose qu’il me reste à auto-héberger (j’ai un compte email chez #OVH). Il y a quand même un problème important, c’est que les emails libres tombent une fois sur deux dans les #spams chez les #Google, #Microsoft et #Yahoo !… Et je pense pas qu’il faillent attendre d’eux qu’ils corrigent ça.


  • RFC 7001 : Message Header Field for Indicating Message Authentication Status

    Il existe désormais plusieurs techniques pour authentifier les courriers électroniques. Certaines peuvent nécessiter des calculs un peu compliqués et on voudrait souvent les centraliser sur une machine de puissance raisonnable, dotée de tous les logiciels nécessaires. Dans cette hypothèse, le MUA (le logiciel de l’utilisateur) ne recevra qu’une synthèse (« Ce message vient bien de example.com ») et pourra alors prendre une décision, basée sur cette synthèse. C’est le but de l’en-tête Authentication-Results :, normalisé originellement dans le RFC 5451 quatre ans plus tôt, RFC que ce nouveau #RFC met légèrement à jour (il y a peu de changements).

    http://www.bortzmeyer.org/7001.html

    #sécurité #courrier_électronique #DKIM #SPF



  • RFC 6686 : Resolution of The SPF and Sender ID Experiments

    L’#IETF avait créé en 2004 un groupe de travail nommé MARID, qui avait pour tâche de normaliser un mécanisme d’authentification faible du courrier électronique par le biais de la publication dans le #DNS des serveurs autorisés à envoyer du courrier pour un domaine. Deux propositions étaient sur la table, #SPF et #Sender-ID. #Microsoft avait pratiqué une intense obstruction contre SPF, pour promouvoir sa propre solution, Sender-ID. En 2006, l’IETF avait cédé devant cette obstruction, en renonçant à normaliser SPF, déjà très répandu, et en publiant les deux protocoles avec le statut Expérimental : RFC 4408 pour SPF et RFC 4406 pour Sender"ID. Cette solution peu courageuse avait été contestée, notamment pour le risque que la coexistence de deux protocoles incompatibles faisait peser sur la bonne délivrance du courrier. Officiellement, la retraite de l’IETF devait être provisoire : une période de deux ans d’observation était prévue, suite à laquelle des conclusions pourraient être tirées sur l’expérience. En fait, c’est seulement six ans après qu’est publié notre #RFC 6686 qui conclut enfin officiellement que Sender-ID est un échec total et que seul SPF est déployé et utilisé.

    http://www.bortzmeyer.org/6686.html

    #sécurité #courrier_électronique #spam