spamassassin-dev November 2011 archive
Main Archive Page > Month Archives  > spamassassin-dev archives
spamassassin-dev: [Bug 6567] Clean up zen rbl rules

[Bug 6567] Clean up zen rbl rules

From: <bugzilla-daemon_at_nospam>
Date: Thu Nov 03 2011 - 20:12:05 GMT

Kevin A. McGrail <> changed:

           What |Removed |Added
             Status|NEW |RESOLVED
                 CC| |
         Resolution| |INVALID

--- Comment #1 from Kevin A. McGrail <> 2011-11-03 20:12:05 UTC ---
Three separate issues:

INVALID - 1) Change XBL and PBL to use check_rbl_sub.

KAM: From the docs
"Note: the set name must be exactly the same for as the main query rule,
including selections like '-notfirsthop' appearing at the end of the set

So changing those without changing the zen call would be incorrect.

UNCLEAR - 2) Switch everything to -firsttrusted. I believe -lastexternal
trusted_networks, which I don't think is appropriate?

KAM: So switching -lastexternal to -firsttrusted would really need some FPs
that show this as an issue.

Looking at lib/Mail/SpamAssassin/Plugin/, the nuance differences
between these flags elude me.

Warren's sandbox for example flip-flops between them. I have to assume he had
his reasons.

TOO BROAD A QUESTION - 3) And for the ones that don't have -lastexternal or
-firsttrusted, I think it's checking *all* untrusted hops? Is that really

KAM: Deep header parsing is something I try to avoid because it catches people
that authenticate but use DHCP pools that have been added to RBLs.

This is a highly debatable / controversial issue.

Can you open a ticket on a per-RBL that is doing this, please? Each RBL and
their purpose has to be considered for this change.

For example, SBL is for "sending, hosting or origination of Unsolicited Bulk
Email" so deepheader parsing for that list is within the intent of that list.

Of course, I don't recommend using ANY rbls for the blocking of email, just for
scoring. But that's debatable as well.

-- Configure bugmail: ------- You are receiving this mail because: ------- You are the assignee for the bug.