RCVD_IN_BSP_TRUSTED

[Glenn Steen]

On 23/10/06, Jim Coates <jimc at laridian.com> wrote:
> > -----Original Message-----
> > From: mailscanner-bounces at lists.mailscanner.info
> [mailto:mailscanner-bounces at lists.mailscanner.info] On Behalf Of Matt >
> Kettler
> > Sent: Monday, October 23, 2006 1:18 PM
> > To: MailScanner discussion
> > Subject: Re: RCVD_IN_BSP_TRUSTED
> >
> >
> > Jim Coates wrote:
> >
> >>
> >>
> >> Matt,
> >>
> >> No - I believe the other tests have been working fine.  Here are a few
> >> examples of test results:
> >
> > Yeah, but those do not tell me if the other tests are working correctly.
> >
> >
> >> All three of these came from inline image spam.  All three managed to
> >> get a pretty big boast in the HAM direction because of the BSP_TRUSTED
> >> rule.
> >
> > You have two options:
> >
> > 1) Feed the message manually to spamassassin -t on the command line. This
> will tell you in the body-text report which IP > matched BSP trusted.
> >
> > It should be the IP that delivered the message to your MX. If it's not,
> your trust path is broken.
> >
> >
> >
> > 2) Find out which IP is delivering the message to your network. That
> should be the one checked against BSP_TRUSTED.
> >
> > Reverse the IP, and do a manual lookup against
> sa-trusted.bondedsender.org.
> >
> > ie: to look up 66.135.209.212, an e-bay MX which is BSP listed:
> >
> > # dig 212.209.135.66.sa-trusted.bondedsender.org
> >
> > <snip>
> >
> > ;; ANSWER SECTION:
> > 212.209.135.66.sa-trusted.bondedsender.org. 0 IN A 127.0.0.10
> >
> >
> > If it's not listed, your trust path is broken. You can try the other IPs
> to see which one SA is testing against. My > guess is it's going out one-hop
> too far and trusting a forged header.
>
> Matt,
>
> I tried running the IPs from the email header (every one I could find)
> through the sa-trusted.bondedsender.org test and none of them triggered it
> using "dig".   What is interesting is that I tried our own mail server IP
> (which I know is listed with Bonded Sender) and it didn't trigger it either.

Ok....

>
> However, in my searching, I found a few things:
>
> 1) We are allowing SpamAssassin to "guess" the trusted path (rather than
> specifying it)
Right, so things sent "by you" would definitely trigger it then,
regardless (well, no.. but:-) if it gets the trust_path right or not.

> and
>
> 2) All of the emails I looked at where actually retrieved from a common mail
> server at our ISP via fetchmail to our private mail server.  IE - all of
> those were delivered to a backup mail server, then fetched via fetchmail to
> our primary box.
And fetchmail (in its blessedly naive way:-):-) will retransmitt every
mail from that "backup MX" as a locally submitted mail. Presto, there
you have it.

> I don't know if this is part of what's confusing the rule or not.
I'd hazard that it does;).

> I did some searching on some forums that claim the best use of the
> RCVD_IN_BSP_TRUSTED rule is to score it at 0 to keep it from doing anything.
Well, you could do that, or perhaps augment it a bit (with a test
specific to trigger for those fetchmailed backup-MX thingies).

Or you could set up a real backup that would do real MS testing too,
and forgo passing it through your "primary". Or something similar.

-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se