Bonjour à tous. 2014-04-27T10:06:46+0200, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > http://www.bortzmeyer.org/7208.html
../.. Je n'ai pas lu la RFC elle-même, que l'article de Bortzmeyer, mais qu'en est-il des cas avec alias ? J'ai rencontré de nombreux cas où une personne utilise une adresse électronique, comme l'adresse de son lieu de travail par exemple, comme foo....@monemploi.com, mais qui se traduit par un alias vers la boîte personne de la personne, comme jean.dup...@mamaison.com. Et comme attendu, le serveur qui se trouve à l'adresse mamaison.com, voit arriver un courriel, avec l'adresse de l'expéditeur, sauf que c'est le serveur monemploi.com qui est vu comme l'expéditeur du courriel en question. Du coup, s'il y a un enregistrement TXT (je pensais que SPF était utilisé maintenant) disant "mx -all", et que le serveur mamaison.com a un politique sévère, les courriels n'arriveront jamais à destination. Ce type d'exemple arrive souvent, je vois de nombreux courriels, les personnes utilisant Ghandi pour avoir un TLD, font une redirection vers leur boîte GMail, et à chaque fois : Received-SPF: fail (google.com: domain of XXX(at)thican.net does not designate 2001:4b98:c:538::198 as permitted sender) client-ip=2001:4b98:c:538::198; En conclusion, nous sommes plusieurs à penser que le Sender Policy Framework est un projet mort-né. Je ne veux pas provoquer les personnes qui travaillent dessus, mais faire des alias est monnaie courante, et de nombreux services de boîte courriels (GMail dans cette exemple), traduisent donc les politiques hardfail en softmail, au risque de voir des tas de courriels ne jamais arrivaient à destination, rendant inefficace ce dispositif (« La décision finale est une décision locale. »), mais vu qu'il s'agit de la majorité, cet outil devient désuet avant même qu'il n'est eu le temps de se démocratiser. Bonne journée, -- Thibaud CANALE thican [at] thican [dot] net http://thican.net/ GPG: 4096R/50733A18
signature.asc
Description: Digital signature
