On Thu, 24 Jun 2010 15:59:24 -0400 Michael Scheidell <scheid...@secnap.net> wrote:
> On 6/24/10 3:51 PM, Ned Slider wrote: > > The danger comes when people use the PBL incorrectly and deep parse > > all headers which *will* lead to copious FPs. > > > > Either way, I'd have no hesitation blocking outright on PBL or > > scoring very highly in SA. > > The current scores are actually: RCVD_IN_PBL 0 3.558 0 3.335 > since the PBL also lists 'dialups'. and if a dialup user connects to > their legitimate smtp host for their provider and sends an email, > their dialup ip will still be in the received headers. > > that is why, as Ned said, you have to only use it on the LAST > UNTRUSTED ip. (or first received header). or on your MTA. > NOTE; if you use it in your MTA, and you are using a caching DNS > server, then you are not making any redundant outbound DNS queries, > one for the MTA, one for SA. SA does a zen lookup for all the untrusted relays. Zen encodes SBL,PBL and XBL into one look-up. All the SBL results are used, but the PBL and XBL results are used on the last-external IP. One score that I do find odd is: RCVD_IN_SBL 0 2.596 0 0.141 I suspect that if SBL were split into separate, mutually exclusive, deep and last-external checks, the deep check wouldn't get pushed down so much in the bayes+net scoreset.
