spamd.conf with rsync and DNS-based lists

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

spamd.conf with rsync and DNS-based lists

Mark Carroll
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.

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.

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.

-- Mark

Reply | Threaded
Open this post in threaded view
|

Re: spamd.conf with rsync and DNS-based lists

Pierre Emeriaud
2017-11-08 17:01 GMT+01:00 Mark Carroll <[hidden email]>:
> 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.

> Is there a "good" OpenBSD way to do it or maybe the whole idea is
> ill-conceived.

I'd say go with bgp-spamd (http://bgp-spamd.net), but that's the
networker I am talking :)

Peter Hessler gave several talks about it, here are the slides from
one of his talks:
https://www.openbsd.org/papers/asiabsdcon2015-bgp-spamd.pdf

Reply | Threaded
Open this post in threaded view
|

Re: spamd.conf with rsync and DNS-based lists

Stuart Henderson
In reply to this post by Mark Carroll
On 2017-11-08, Mark Carroll <[hidden email]> 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.