Nous gérons le cas par des trusted host : ici, on considère que gmail a
déjà fait son boulot de vérification des spf (et autres contrôles
anti-spam) et sont les seuls à avoir le droit de te transmettre des
mails, donc on accepte tout ce qui vient des serveurs google (cf les
champs SPF justement de _netblocks.google.com et
_netblocks2.google.compour de l'ipv6), en faisant gaffe de pas devenir
pour autant openrelay de nos amis google.
Ensuite pour les mails sortants, c'est selon :
-soit tu refait passer tes mails par google, dans ce cas là ton
champ spf sera du type : spf1 include:_spf.google.com -all"
-soit tu relais via ta/tes lignes internets, auquel cas ça
ressemblerait plus à : spf1 ip4:x.x.x.x ip4:y.y.y.y -all"
Dans tous les cas, il faut faire confiance à google (je ne me permettrai
pas de troll aujourd'hui).
Bonne soirée.
Le 28/04/2014 15:00, Thibaud CANALE a écrit :
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,
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
