Justin Mason wrote:
snowcrash+spamassassin writes:
reading at the spamhaus site abt PBL i note,
wow dude, that's quick -- I hear it went live only a few hours
ago ;)
"WARNING! Some post-delivery filters use "full Received line
traversal" or "deep parsing", where the filter reads all the IPs in
the Received lines. Legitimate users, correctly sending good mail out
through their ISP's smarthost, will have PBL-listed IPs show up in the
first (lowest) Received header where their ISP picks it up. Such mail
should not be blocked! So, you should tell your filters to stop
comparing IPs against PBL at the IP which hands off to your mail
server! That last hand-off IP is the one which PBL is designed to
check. If you cannot configure your filters that way, then do not use
PBL to filter your mail."
with the ever-smarter filters available with SA & SARE etc, what -- if
anything -- should 'we' do/configure differently in SA's confs/ops to
avoid this issue?
As long as "trusted_networks" and "internal_networks" are configured
correctly, it'll be fine.
I don't think that's true.
SA's RBL support looks at all of the received headers, last time I
checked. So, if you have a received header pattern like this:
Trusted Local Machine
Untrusted Remote ISP
Untrusted Remote Client*
(* in PBL because this is what the PBL lists: ISP clients)
Then SA will trigger PBL on it, even though it really shouldn't. The
fact that the trusted_networks and internal_networks are set properly
doesn't help the situation.
Either the PBL mechanism should _only_ look at the first untrusted
header, or the PBL rule is going to need to be set to a VERY low score
(because if the PBL is a success, virtually every end client will be in
it, and thus it will trigger on a lot of ham), or there needs to be no
PBL rule at all**.
(** and in that last case, a "ZEN" rule should not include PBL results)
Of the 3 choices, I think the first one is the best candidate, but also
the most complex implement (and, also,I should probably write a
BOTNET_PBL rule that does exactly that, since it's a different strategy
for the same goal, and Botnet is already trying to do that "look at the
first untrusted" approach). Otherwise, I think the 3rd one is kind of
inevitable ... so many hosts will eventually be listed, and it will
match so many received headers, that it wont be a useful SA spam sign.
