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.3341IN TXT "spf2.0/pra ptr:mx.aol.com ?all"
aol.com.3341IN TXT "v=spf1 ptr:mx.aol.com ?all"
[admin.admin-PC] → dig txt sfr.fr | grep spf
sfr.fr. 2813IN 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
