SPF-aware greylisting et filter-greylist · poolp.org

[poolpOrg]

[22decembre]

Bonjour et merci.

J'adore ton travail et je l'utilise moi-même (opensmtpd). Concernant ce concept de spf-aware greylisting, serais-tu en discussion avec le dev' de spamd pour pouvoir y integrer ton code (ou la fonction, avec un code propre) ? Je n'ai pas encore essayé ton filtre pour l'instant.

Sinon, bah ca fait un peu doublon, parce qu'il faut toujours éviter aux Big Corps de passer devant spamd... D'autre part, spamd n'écoute toujours pas en ipv6, donc ca m'interesse de voir que tu l'a fais toi.

Merci

[poolpOrg]

Non, je n'ai pas discuté avec le développeur de spamd(8) pour deux raisons:

La première est qu'il y a de grandes chances que si je touche à spamd(8), je me retrouve mainteneur alors que je ne l'utilises pas et que je ne suis pas convaincu de son utilité.

La seconde, comme dit dans l'article est que:

Il n’est pas possible d’implémenter cela dans un daemon comme spamd(8), la décision de greylister ou de laisser la session progresser est prise au moment du MAIL FROM, là ou la redirection spamd(8) est décidée par le firewall à la connexion.

Que ce soit spamd(8) ou filter-rspamd, la condition pour passer le greylisting est fondamentalement la même, il n'y a donc aucune utilité à chainer les deux. Si un client réussi à passer spamd(8), il est censé réussir à passer filter-rspamd, la réciproque n'est pas vraie mais uniquement en raison du SPF.

[B4rb3rouss]

Ces progrès sont effectivement très intéressants sur le principe par domaine plutôt que par IP, et puisque spamd ne gère pas l'ipv6 comme l'a indiqué 22decembre.
Cependant, spamd reste à mon avis très utile pour appliquer des sanctions, ce que tu évoques à la fin de ton article. Les spamtraps sont vraiment puissants et permettent une lutte active contre les spammeurs : on réplique au lieu de subir.
À titre indicatif, j'utilise quelques spamtraps comme le fait P. N. M. Hansteen selon les essais de certains bots, et des listes noires pour piéger les spammeurs :

• nixspam : listée par défaut dans spamd
• bgp-spamd
• Celle de Peter sus-mentionnée
• UceProtect qui en propose un petit paquet

En une journée, chaque liste a permis de piéger des spammeurs pendant la durée suivante :

• nixpam : 2290 s
• bgp-spamd : 1543 s
• uceprotect : 20704 s
• spamtraps personnels générés à partir des logs ssh et smtp : 18297 s

(données variables selon les jours bien sûr)/

Cela fait un petit total de 42834 s soit presque 12 heures de perdues pour les spammeurs. Et ce, avec mon petit serveur auto-hébergé. C'est autant d'argent perdu pour les spammeurs, qui ont plus de chances de se "décourager".

Autant spamd a des défauts certains mentionnée dans l'article et par 22decembre, mais pouvoir lutter "activement" contre le spam le rend encore important à mes yeux.

[z3bra]

Très bonne idée d'intégrer le SPF-walk au processus de greylisting!
J'utilise spamd(8) personnellement et j'en suis très content, outre le besoin de gérer le whitelisting des domaines multi-MX à la main.

Je ne sais pas où en est ton développement sur filtre-greylisting, mais il y a un cas qui n'est pas couvert, c'est celui des domaines relayés par d'autres mailers.
Typiquement les noms de domaines d'entreprises utilisant les mailers de google ou microsoft. Ces derniers n'ont pas d'enregistrement SPF “à eux” et pointent leurs MX sur ceux de leur fournisseurs.
Pour traiter ces cas là, il faudrait que ton filtre teste le SPF, non pas du domaine d'envoi, mais du MX associé.

Qu'en penses tu?

[poolpOrg]

Tu verrais ça marcher comment ?

[z3bra]

J'avoue n'avoir pas trop réfléchit au différents use-cases, je calque ça sur la manière dont je maintient ma whitelist pour `spamd`. De temps à autres je reçois un mail, disons de "[email protected]", que je veux whitelister. Le problème, c'est que cette entreprise n'a pas ses propres mailers, et utilise ceux de "bigmailercorp.tld", donc ils n'ont pas de SPF sur leur DNS. Il faut donc que je procède en 2 étapes: 1. `dig mx entreprise.tld` -> mx{1,2,3,4,5}.bigmailercorp.tld 2. `echo bigmailercorp.tld | smtpctl spf walk >> whitelist.txt` Pour automatiser ça, il faudrait résoudre le SPF des serveurs MX associés au domaine, plutôt que ceux du domaine lui-même. Il y a une difficulté cependant, car résoudre le MX d'un domaine retourne le nom d'une machine, est pas le domaine sur lequel se trouve le SPF. Il faut donc être capable d'extraire un nom de domaine depuis un FQDN. Apparement la function `getdomainname(2)` permet ça. Une fois le domaine du MX extrait, on pourra requêter la liste des domaines autorisé en SPF. C'est toutefois assez lourd comme procédure je le reconnais…