RCVD_IN_BSP_TRUSTED

[Jim Coates]

>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

Yes, the backup mail server is one that is shared among various domains
hosted at the rack space where our servers are located, so I really don't
have the choice of modifying them.

I guess I will take a look at modifying the rules since it seems that
everything is working properly, and see what happens.

Thanks!
Jim