John Rudd writes:
> 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.
That would be the case if the PBL rule looked like:
header RCVD_IN_PBL eval:check_rbl('zen', 'zen.spamhaus.org.',
'127.0.0.1[01]')
instead of
header RCVD_IN_PBL eval:check_rbl('zen-notfirsthop',
'zen.spamhaus.org.', '127.0.0.1[01]')
note "notfirsthop" --
=item selecting all IPs except for the originating one
This is accomplished by placing '-notfirsthop' at the end of the set name.
This is useful for querying against DNS lists which list dialup IP
addresses; the first hop may be a dialup, but as long as there is at least
one more hop, via their outgoing SMTP server, that's legitimate, and so
should not gain points. If there is only one hop, that will be queried
anyway, as it should be relaying via its outgoing SMTP server instead of
sending directly to your MX (mail exchange).
(Actually, I was off with my first reply -- it doesn't rely on
trusted/internal_networks at all.)
--j.
