On 2017-11-08, Mark Carroll <m...@ixod.org> wrote: > I am looking to expand my spamd.conf's blacklisting and I now see that > some providers prefer one to rsync their blacklist rather than simply > fetching it and more others make their lists queryable by DNS only.
Commercial dnsbl operators will be taking value from your queries (so they can identify sender IP addresses and approximate levels of mail based on lookups), those that do provide rsync access often charge for it. > I am not missing some easy rsync syntax for spamd.conf right? It is a > sufficient workaround to just rsync to a local file then have the base > spamd look at that. The fast table lookups that pf can do are great. Correct, that is the way to handle rsync. > As for the DNSBLs, last year Clint Pachl kindly shared a spamd-dnsbl > script here which every few minutes looks to trap hosts while they are > graylisted. Also promising is https://github.com/echothrust/pf-diverters > though the README warns "IN NO-WAY PRODUCTION READY" and dnsbl-divert > is "still work-in-progress" and there are no recent commits. Maybe it's > more reliable than it seems though I am still trying to understand the > implications of a divert-packet to something that then does DNS lookups: > this is a side of pf that's new to me. > > For using IP blacklists to immediately divert senders to spamd, it'd be > interesting to try Spamhaus Zen and similar. How are people approaching > this? Is there a "good" OpenBSD way to do it or maybe the whole idea is > ill-conceived. The usual way to run spamd is in greylisting mode, in which case the script to check greylisted hosts isn't a bad idea. The dnsbl-divert approach might be useful if spamd is in blacklist-only mode. The biggest risk is that it makes your DNSBL/s a point of failure; something that works at the SMTP rather than TCP connect level can cope with longer lookup delays, and has enough time and information to make more complex decisions. I'm not sure how well (if at all) dnsbl-divert could combine with spamd, it seems like an alternative rather than an addition to me. It would be interesting to have something which can proxy directly to a backend mail server (i.e. accept an incoming connection, stutter at the sender, do some basic checks which could include dnswl, dnsbl and smtp protocol enforcement, then transparently proxy to the backend from "rcpt to" reducing spamd's 3 connections to hit the real MTA to 2). It would be quite a different beast though. What MTA do you have behind spamd? Some (e.g. postfix/postscreen) have spamd-like functionality that can make more complex decisions (additional checks on SMTP protocol, dnsbl lookups, etc). That's all I'm using in early SMTP nowadays (plus after-DATA checks via rspamd as a milter). For the mail I have to receive, dnswl support is a must, really.
