> > Generally, everything has changed from file feeds to DNS. > > Yep, because for the more actively maintained ones 1) new entries show > up more quickly than any sane rsync interval, this is quite important > for good blocking these days 2) DNS is less resource intensive and more > easily distributed than rsync, and 3) importantly for the rbl providers, > it gives additional input to them about new mail sources (if an rbl > suddenly starts seeing queries from all over the world for a previously > unseen address, it's probably worth investigation - I am sure this is > why some of the commercial antispam operators provide free DNS-based > lookups for smaller orgs). > > A more flexible approach would be to skip the PF table integration > completely and do DNS lookups in spamd (or, uh, relayd, or something > new) and based on that it could choose whether to tarpit, greylist or > transparent-forward the connection to the real mail server. This > would also give a way to use dnswl.org's whitelist to avoid greylisting > for those hosts where it just doesn't work well (gmail, office365 etc).
The argument does not make sense. There are numerous tools that can do DNS lookup in userland. spamd was the only one which could do it via radix tables on the kernel edge, which even allows you to do management in a bridge. pf integration is the basis of spamd, that is how it steps out of the accepted address list, so that userland can make the decision. Your proposal can be summed up as: delete spamd.
