Re: [FRnOG] Re: [TECH] RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
Hello, intéressant ces échanges. Quoiqu'il en soit, SPF me semble tout de même intéressant comme concept, je me rappelle encore de Meng Weng Wong au sommet de sa gloire trônant au premier rang avec son pancho en 2006. Si nous demandons aux admins de mettre en oeuvre l'ensemble des dispositifs imaginés pour tenter de contenir les libertés de SMTP (Dave Crocker avait d'ailleurs donné une conférence qui s'appelait (je crois) si je savais tout ce que je sais maintenant, jamais je n'aurais fait SMTP comme ça. ... ça donne le ton, mais j'avoue m'être assoupi pendant ^^), nous nous retrouverions dans un espèce de *clash of clan* Internet :) ... du management du port 25 (soit du déploiement d'acl) au profit du 587 pour le service de MSA, en passant par SPF Vs SSID, puis DKIM ou encore DMARC auxquels on doit ajouter les classiques notation antispam, les Blacklist type RBL, le check du reverse DNS et enfin les dispositifs d'analyse comportementale, le tout saupoudré de DNSSEC et des discussions autours du MTA sur IPv6 Vs IPv4 ... nous pouvons arriver à un niveau de complexité assez ... intéressant et d'efficacité assez ... aléatoire. Concernant SPF, je m'étais arrêté pour ma part aux histoires des forward car les discussions m'avaient rapidement noyé dans un véritable spam :) Ce qui pourrait être utile à produire est une sorte de BCP (Best Commom Practices) d'assemblage efficace des ces dispositifs d'assainissement mail avec quelques stats à l'appuie pour aiguiller la communauté sur l'efficacité de l'implémentation et imbrication de tel ou tel *outil*. Travail qui me semble à première vue assez laborieux. Et dire que Atos avait prédit la fin de l'email ... http://www.silicon.fr/thierry-breton-atos-origin-le-mail-nest-plus-un-outil-approprie-desormais-44716.html puis : http://www.lemonde.fr/economie/article/2013/04/15/la-machine-arriere-d-atos-sur-l-ambition-zero-e-mail_3159874_3234.html et enfin reviennent avec un *zero mail concept*. Cyril H. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
Stephane Bortzmeyer, le Mon 28 Apr 2014 15:14:43 +0200, a écrit : On Mon, Apr 28, 2014 at 03:10:07PM +0200, Samuel Thibault samuel.thiba...@ens-lyon.org wrote a message of 19 lines which said: Oui, on a le souci chez @ens-lyon.org. Dans ce cas on utilise SRS pour réécrire le Return-path, et ça passe. Une autre solution est de refaire un message avec le même contenu RFC 5322 mais une enveloppe différente). Dans ce cas, les rebonds iront au forwarder, ce qui est raisonnable. Heu, je ne suis pas sûr de comprendre la différence. Dans ton autre solution, est-ce que l'on garde les enveloppes existantes ? Est-ce que le From est modifié ? Dans notre solution, le Return-path est positionné à notre domaine de forward, et donc on récupère les rebonds, est-ce cela que tu entends par les rebonds iront au forwarder ? On s'occupe alors de relayer à l'adresse d'origine, ce qui est a priori ce qui est voulu par les utilisateurs. Samuel --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
On Mon, Apr 28, 2014 at 03:10:07PM +0200, Samuel Thibault samuel.thiba...@ens-lyon.org wrote a message of 19 lines which said: Oui, on a le souci chez @ens-lyon.org. Dans ce cas on utilise SRS pour réécrire le Return-path, et ça passe. Une autre solution est de refaire un message avec le même contenu RFC 5322 mais une enveloppe différente). Dans ce cas, les rebonds iront au forwarder, ce qui est raisonnable. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
On Mon, Apr 28, 2014 at 03:18:12PM +0200, Thibaud CANALE thi...@thican.net wrote a message of 53 lines which said: Ça modifie l'en-tête In-Reply-To, de recréer un courriel en tant que « message transmis », non ? Non, je disais de ne _pas_ modifier le message (en-têtes et corps), seulement l'enveloppe. --- Liste de diffusion du FRnOG http://www.frnog.org/