/dev/rob0 | 15 Feb 17:51 2011

My postscreen results

I went live with my postscreen blocking mail, after some time of 
non-blocking while watching logs. Here's a discussion of those 
results (both non-blocking and blocking.) I've singled out some of 
the items which interested me; perhaps they will interest you as 
well. (Possibly all old-hat to the ones who leapt in early.)

* Settings

postscreen_dnsbl_sites =
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce

* Gripe

The one thing I do not like about it is that the DNSBL given as the
reason for rejection is semi-random, specifically it seems to be the 
first one to hit dnsblog(8) for that client.

My postscreen_dnsbl_sites are arranged in trust order. If a real 
person was to see one of these rejections, I would prefer that this 
person see Spamhaus or Barracuda or NJABL, not SORBS, Spamcop, or 
TRBL. I know my workaround is to use postscreen_dnsbl_reply_map,
shown here in pcre:
    !/^zen\.spamhaus\.org$/    multiple DNS-based blocklists
But, I'd prefer for logging to sort the dnsblog names by score, 
highest first, and use that DNSBL name as the reason.

(This workaround is in place and working fine.)

* Scoring and whitelists

Thanks to Noel for getting me thinking about DNS whitelists. I am 
doubtful that they will matter much overall, but they do seem to be 
conservative so far. Mine have offset only a few negatively-scored 
hosts from my less-trusted (1 point) DNSBLs, mostly. There were 2 
DNSWL hits for spameatingmonkey hosts, and zero for AHBL, so I am 
considering switching their places (and scores) in the above list.

The largest part of my DNSWL hits are weighted toward lower-scored 
hosts. Out of 610 in the sample period I had 474 + 89 + 34 + 13 of 
127.0.x.Y where Y is 0, 1, 2, and 3 respectively. I'm not seeing a 
lot of hits in SWL so far, and the few I did see were also found in 
DNSWL. (No SWL host was listed in any of the DNSBLs.)

Overlap between dnswl.org and the DNSBLs listed was as follows:

  Also listed in:
  bl.spameatingmonkey.net   2
  bl.spamcop.net            4
  dnsbl.sorbs.net          24
  spamtrap.trblspam.com    52

Of these, only 5 were listed on more than one DNSBL. All 5 of these 
were listed on TRBL; 3 also on spam.dnsbl.sorbs.net (, and 
the other 2 also on bl.spameatingmonkey.net ( Not 
surprisingly, each of the DNSWL listings was a .0 (trust level 

  --------------   list.dnswl.org   bl.spameatingmonkey.net   spamtrap.trblspam.com   list.dnswl.org   bl.spameatingmonkey.net   spamtrap.trblspam.com

Note, the DNSWL-SEM-TRBL triples are right next door to one another, 
which suggests that a netblock listing might have been done. These 
particular hosts are an ESP:
I don't know how good (or bad) they are, but they do offer a free 
trial, so they're likely to attract spammers.

  ----------------  list.dnswl.org  dnsbl.sorbs.net  spamtrap.trblspam.com   list.dnswl.org   dnsbl.sorbs.net   spamtrap.trblspam.com   list.dnswl.org   dnsbl.sorbs.net   spamtrap.trblspam.com

The first two of those are the ESP iContact.com. The latter is KPN, 
an ISP in Europe.

The breakdown of dual listings by DNSWL trust level is what I would 

  dnswl.org returns: ##   ## per DNSBL
  ------------------ --   ------------
  127.0.x.3 (high)    3    2 TRBL
                           1 SORBS spam (
  127.0.x.2 (medium)  0
  127.0.x.1 (low)     0    9 SORBS spam (All of these: Facebook)
  127.0.x.0 (none)   70   50 TRBL
                          14 SORBS spam
                           4 Spamcop
                           2 Spameatingmonkey 

FWIW the three high-trust hosts are all well-known listservers: 
outgoing.securityfocus.com and webster.isc.org on TRBL; and 
vger.kernel.org on SORBS. No, I'd not want to lose mail from them.

The non-trust hosts are about evenly split between ESPs and ISPs. 
These, I did not bother to examine as carefully other than that. 
Seems like some more aggressive sites might want to score lower for 
dnswl.org's 127.0.[5;15].0 than for other values of the third quad.

Oh, and of course, thanks also to Mathias for running DNSWL. Looks 
like you're doing a good job. I signed up and got listed with a 
"medium" trust score (which is probably fair; if anything, to be 
honest, possibly a bit too high. I'm not full-time on this, and if
something went wrong and we were being used by a spammer, there 
could be a delay in our response to complaints.)

* Subjective & Plans, Conclusions

I have (had!) pretty good spam controls in place before this. I do 
not expect to see any substantial decrease in spam getting through, 
simply because most that the postscreen blocks was already being 
blocked by smtpd. I did see a couple in the last few days before 
starting postscreen_dnsbl_action=enforce which were not in Zen, yet 
scored above my postscreen_dnsbl_threshold.

Whilst I do not relish a return to the pain of greylisting, I am 
planning to activate the deep protocol tests after a bit. I'm 
thinking that the post-220 tests might nearly wipe out the spam I get 
other than snowshoe, and delays can indeed help with snowshoe in some 
cases (giving the DNSBLs more time to list them.)

I'm still not using any kind of content filtering here, but that 
remains a possibility for the future. URIBL checking should mop up 
the snowshoe spam and "leakage" from the otherwise legitimate mail 

I am pleased with my list of DNSBL (and dnswl) sites and their 
scoring. I could add in a few more and still feel safe, except for 
having more DNSBLs to keep up with.

I'm confident in those lists insofar as that they're adhering to 
their policies. I'm sure their spamtraps are being hit by the 
whitelisted hosts; but I'd not be comfortable using TRBL or SORBS as 
a reject_rbl_client lookup.

It's not a FUSSP, and it won't be, unless/until a new secure mail 
protocol is adopted and everyone switches to it. Spammers will be a 
moving target, always. But I definitely feel like we're ahead in the 
game for now. Thanks Wietse, and also thanks to those early adopters 
who provided the feedback on postscreen.

    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header