hello, Histoire de rebondir sur les discussions ;)
Le sujet mail est largement couvert et géré collégialement à niveau monde (car démocratisé) pour que l'on puisse imaginer que les acteurs nationaux passent à coté comme sous-entendus ... => Le filtrage du TCP 25 est la recommandation officielle sur les Best Practices de la communauté Internet, souvent appelé "managing port 25". Il ne sagit pas de filtrer spécifiquement ses propres IP, il s'agit surtout de séparer le process de soumission MSA du process de transmission de l'email MTA. Le TCP 587 en SMTPAUTH est ouvert normalement sans aucun filtrage permettant d'utiliser le MSA de son FAI depuis n'importe ou dans le monde, c'est la règle pour offrir de la mobilité (un telnet sur le 587 depuis n'importe quel FAI vers un serveur distant est censé fonctionner). L'objectif du filtrage TCP 25 est bien de ne permettre la communication uniquement entre MTA, donc entre serveur de messagerie. Pour héberger un serveur chez soi, il suffit d'être en IP fixe et les règles de filtrage peuvent être abolie. Il n'y a pas de logique, en particulier avec des méchanismes comme SPF, de souhaiter transmettre du flux TCP 25 depuis une IP dyn. Voir aussi le doc en ligne : http://www.maawg.org/system/files/pubdocs/MAAWG_Port25rec0511.pdf => SPF est bien implémenté sur plusieurs domaines de FAI comme AOL sur "aol.com", "verizon.com", mais aussi sur des FAI nationaux (voir "sfr.fr"), mais il faut avoir l'oeil, car ce n'est pas forcément là on l'attend le plus :) par exemple sur le domaine "orange.com", ce qui démontre que la culture du sujet est bien connue et maîtrisées des acteurs cités dans les échanges précédents. L'implémentation repose surtout sur l'état d'usage permettant ou non son implémentation sans impact sur les usagers. [HLA] → dig txt orange.com | grep spf orange.com. 22570 IN TXT "v=spf1 include:spf-a.orange.com include:spf-b.orange.com include:spf-c.orange.com include:spf-d.orange.com include:spf-e.orange.com ~all" [HLA] → dig txt aol.com | grep spf aol.com. 3341 IN TXT "spf2.0/pra ptr:mx.aol.com ?all" aol.com. 3341 IN TXT "v=spf1 ptr:mx.aol.com ?all" [admin.admin-PC] → dig txt sfr.fr | grep spf sfr.fr. 2813 IN TXT "v=spf1 ip4:93.17.128.0/24 ip4:160.92.187.254 ip4:160.92.187.251 ip4:160.92.187.226 ?all " => Concernant la remarque sur la gestion des plaintes abuses par les FAI. je pense que vue de l'intérieur la collaboration entre tous les FAI nationaux est bien existante et largement consolidée aujourd'hui. Les différents acteurs abuse-desk traitent et collaborent. ça ne sera jamais assez (au vue de l'enjeux conditionnéé par le volume), mais il est certains que même la flemme est rapidement sanctionée par les RBL, donc ça ne dure généralement pas très longtemps ;) dans le passé on disait aussi "haaa .... sorbs quand tu nous tiens ...." (un kiss à Michelle) => Concernant SPF à proprement parlé, si cette technique, tout comme DKIM, n'est pas généralisée, c'est bien parcequ'il existe des limitations et des effets de bord, en particulier sur des domaines utilisés par des millions d'utilisateurs (il suffit d'une source non conforme pour empêcher l'implémentation d'un tel système). le protocole SMTP n'a initialement pas été pensé pour savoir répondre nativement à l'anti-spam, Dave Crocker disait d'ailleurs : "si je savais tout ce que je sais maintenant, jamais je n'aurais fait SMTP ainsi". Un mail n'est pas qu'un simple envoi et terminé, il y a tous les autres usages comme le forward, la question est de savoir quelle IP doit être autorisée pour un mail retransmis dont le FROM ne changerait pas, ces questions on été traitées http://www.openspf.org/Best_Practices/Forwarding mais demandent aux implémenteurs de designer très précisément leurs SPF records pour ne rien planter. en tout cas, j'avoue que sur ce coup, "Meng Weng Wong" a effectivement proposé une idée qui apporte quelque chose et de manière assez simple. => Concernant DKIM : même histoire sur les forward, je vérifie quelle signature ? toutes sur l'entête les unes après les autres, ou la dernière ... et ensuite qu'est ce que je fais, je le sors de l'antispam car "certified" ou le filtre en antispam ? ce qui demande ensuite de renouveler périodiquement les clés publiques dans les domaines clients en jouant sur les selectors ... DKIM a un coût de fonctionnement (check signature, gestion ...) pour un gain à mon avis encore discutable, en particulier si personne ne généralise. => maintenant dernier STEP, j'implémente SPF + DKIM + IPV6 et enfin DNSSEC et je regarde le résultat : l'empillement est complexe (cf taille des paquets ....) dans l'ordre des priorités je dirais : IPV6, ensuite DNSSEC, puis le reste. Au final, je ne pense pas que le sujet puisse se résumer aussi simplement que dans les échanges précédents. bon grand week. HLA From: Eric Fourage Date: 2012-04-27 11:32 To: nicolas CC: frnog-tech Subject: Re: [FRnOG] [TECH] records SPF des domaines de messagerie des FAI ADSL/cable Le 27 avril 2012 00:57, Nicolas Limage <nico...@xephon.org> a écrit : > Le 2012-04-26 14:53, Eric Fourage a écrit : > > mais "normalement" avec un ?all il ne devrait pas y avoir de rejets, en >> tous cas chez les providers mail serieux ? >> concernant Gmail c'est plutot l'absence de records qui augmente les >> chances >> d'être rejetté ou mis en quarantaine/spams. >> > > Le problème est essentiellement historique. > > Comme tout le monde a été habitué à avoir un SMTP de FAI "open relay" > depuis > le réseau de celui-ci (essentiellement pour ne pas se prendre la tete avec > les clients), et que toutes les documentations ont été imprimées comme ca, > la situation va avoir du mal à changer (toujours pour éviter la prise de > tête) > > Tant que chaque "fournisseur de mail" ne fournit pas un serveur sortant > avec du SMTP authentifié, on aura toujours besoin de ce relais SMTP des > FAI. > > Mais avoir un serveur sortant, ça prend du temps, des ressources, > et ca oblige à gérer toutes les problématiques de spam sortant, bref la > question qui va émerger est : "pourquoi se prendre la tête alors qu'on peut > s'en passer ? > > Au niveau des FAI, c'est plus simple de filtrer sur les IPs que de mettre > en > place une authentification. Et limiter les envois à son réseau, ça évite > aussi > les problèmes de spammeurs extérieurs. > on est bien d'accord > Sans cette condition de fournir un SMTP sortant, le fournisseur de mail > "... de fournir un SMTP sortant authentifié" ne peut pas contrôler les IPs qui émettront des emails avec son domaine, > ce qui empêche de mettre en place une politique stricte SPF et DKIM. > sauf que justement SPF prévoit ça avec un softfail/none sur les records ~all / ?all .... > Avoir des politiques strictes et dropper des mails va aussi créer > des plaintes utilisateurs là où il n'y en avait pas. > mais les rejets/drops sont du fait des messagerie du destinataire, pas du FAI "source", c'est à eux qu'il faut se plaindre ! > Donc aujourd'hui, ce type de mécanismes reste, à mon avis, pour les FAI, > plus indicatif qu'autre chose, mais toujours bon à donner à manger > à un antispam pour l'aider à améliorer ses décisions. > tout le monde y gagne à le mettre en place, à condition de le faire correctement coté FAI, et de l'interpréter comme il se doit coté récepteur (antispam). > -- > Nicolas Limage > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Eric FOURAGE 5 av. de la république 69160 TASSIN-LA-DEMI-LUNE gsm: 06 03 35 80 81 tel: 09 51 31 44 14 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
