Re: spamd - DNS whitelist

[Michael McConville]

Bob Beck wrote:
> No.  DNS based whitelisting does not belong in there. because it is
> slow and DOS'able
> 
> spamd is designed to be high speed low drag. If you want to do a DNS
> based whitelist, write a little co-thing that spits one into a file or
> into your nospamd table that then spamd *does not even see*.
> 
> In short *spamd* is the wrong place to do this.  put your dns based
> whitelist in a table periodically

This sounds like a potentially problematic approach. There are now spam
networks that circumvent DNS blacklists, even if the SMTP server queries
for each domain it receives. The best I can tell, they do this by
burning through domains on cheap TLDs like .xyz. Locally caching DNS
blacklist responses seems like it could magnify this problem
substantially.

Re: spamd - DNS whitelist - with prototype

[Christopher Zimmermann]

I forgot to attach my prototype. Here it is.

On 2016-03-29 Bob Beck  wrote:
> No.  DNS based whitelisting does not belong in there. because it is
> slow and DOS'able
> 
> spamd is designed to be high speed low drag. If you want to do a DNS
> based whitelist, write a little co-thing that spits one
> into a file or into your nospamd table that then spamd *does not even
> see*.

That's kind of what my prototype implementation does.

> In short *spamd* is the wrong place to do this.  put your dns based
> whitelist in a table periodically

I put the ips into the table on demand since I cannot simply download a
dnswl. I already suspected relayd might be a better place to do this.
Or keep it in a separate program. Sadly I cannot reinject the diverted
SYN into pf.

> On Tue, Mar 29, 2016 at 1:11 PM, Christopher Zimmermann
>  wrote:
> > Hi,
> >
> > I want to use a DNS white list to skip greylisting delays for known
> > good addresses, which would pass the greylist anyway.
> > To do this with spamd and OpenSMTPd I wrote a prototype which
> > intercepts the initial SYN packet from any non-whitelisted ip. It
> > then queries DNS whitelists and on any positive reply it whitelists
> > the ip. The SYN packet is dropped. Any sane smtp server will very
> > shortly resend the SYN and get through to OpenSMTPd.
> > This program is only a proof-of-concept. I think the same
> > functionality could be integrated into spamd or as transparent
> > relay into relayd. Is this a sensible approach?
> >
> > Christopher
> >
> >
> > On 2016-03-15 Stuart Henderson  wrote:  
> >> On 2016/03/15 12:55, Craig Skinner wrote:  
> >> > 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).


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#define DEBUG 0

#define DIVERT_PORT 25

#define NSTATES 10

struct dns_header {
uint16_tid;
uint16_tflags;
#define QR 0x8000
#define OPCODE_MASK 0x7800
#define OPCODE_SHIFT 11
#define AA 0x0400
#define TC 0x0200
#define RD 0x0100
#define RA 0x0080
#define AD 0x0020
#define CD 0x0010
#define RCODE_MASK 0x000f
#define RCODE_SHIFT 0
uint16_tqdcount;
uint16_tancount;
uint16_tnscount;
uint16_tarcount;
};

struct dns_record {
uint16_ttype;
uint16_tclass;
uint32_tttl;
uint16_tlength;
};

struct state {
union {
struct in_addr in4;
struct in6_addr in6;
uint8_t octets[sizeof(struct in6_addr)];
} addr;
struct timespec timeout;
int af;
uint16_t dnskey;
} states[NSTATES];

void send_query(struct state *state, const char *question);
void process_response();

enum color { white, grey };
void enlist(struct state *state, enum color color);

int dnssock, pfdev;

const char *const whitelists[] = {
"list.dnswl.org",
"swl.spamhaus.org"
};

int main(int argc, char *argv[])
{
int i, ret, timeout;
time_t t;
struct sockaddr_in sin4;
struct sockaddr_in6 sin6;
struct group *group;
struct passwd *passwd;
struct pollfd fds[3];

pfdev = open("/dev/pf", O_RDWR);
if (pfdev == -1) err(1, "open(\"/dev/pf\") failed");

ret = IPPROTO_DIVERT_INIT;
setsockopt(fds[1].fd, IPPROTO_IP, IP_DIVERTFL, , sizeof(ret));
setsockopt(fds[2].fd, IPPROTO_IPV6, IP_DIVERTFL, , sizeof(ret));

/* DNS */
if (res_init() == -1) err(1, "res_init");
assert(_res_ext.nsaddr_list[0].ss_family != 0);
fds[0].fd = dnssock = socket(_res_ext.nsaddr_list[0].ss_family,
   SOCK_DGRAM | SOCK_DNS, 0);
if (fds[0].fd == -1) err(1, "socket");

if (connect(fds[0].fd, (struct sockaddr *)&_res_ext.nsaddr_list[0],

Re: spamd - DNS whitelist

[Bob Beck]

No.  DNS based whitelisting does not belong in there. because it is
slow and DOS'able

spamd is designed to be high speed low drag. If you want to do a DNS
based whitelist, write a little co-thing that spits one
into a file or into your nospamd table that then spamd *does not even see*.

In short *spamd* is the wrong place to do this.  put your dns based
whitelist in a table periodically


On Tue, Mar 29, 2016 at 1:11 PM, Christopher Zimmermann
 wrote:
> Hi,
>
> I want to use a DNS white list to skip greylisting delays for known
> good addresses, which would pass the greylist anyway.
> To do this with spamd and OpenSMTPd I wrote a prototype which intercepts
> the initial SYN packet from any non-whitelisted ip. It then queries DNS
> whitelists and on any positive reply it whitelists the ip. The SYN
> packet is dropped. Any sane smtp server will very shortly resend the
> SYN and get through to OpenSMTPd.
> This program is only a proof-of-concept. I think the same functionality
> could be integrated into spamd or as transparent relay into relayd. Is
> this a sensible approach?
>
> Christopher
>
>
> On 2016-03-15 Stuart Henderson  wrote:
>> On 2016/03/15 12:55, Craig Skinner wrote:
>> > 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).
>>
>
>
>
> --
> http://gmerlin.de
> OpenPGP: http://gmerlin.de/christopher.pub
> 2779 7F73 44FD 0736 B67A  C410 69EC 7922 34B4 2566

Re: spamd - DNS whitelist

[Christopher Zimmermann]

Hi,

I want to use a DNS white list to skip greylisting delays for known
good addresses, which would pass the greylist anyway.
To do this with spamd and OpenSMTPd I wrote a prototype which intercepts
the initial SYN packet from any non-whitelisted ip. It then queries DNS
whitelists and on any positive reply it whitelists the ip. The SYN
packet is dropped. Any sane smtp server will very shortly resend the
SYN and get through to OpenSMTPd.
This program is only a proof-of-concept. I think the same functionality
could be integrated into spamd or as transparent relay into relayd. Is
this a sensible approach? 

Christopher


On 2016-03-15 Stuart Henderson  wrote:
> On 2016/03/15 12:55, Craig Skinner wrote:
> > 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).
> 



-- 
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
2779 7F73 44FD 0736 B67A  C410 69EC 7922 34B4 2566


pgp3n09YtGV91.pgp
Description: OpenPGP digital signature