Mailing List Archive

On Tue, 24 Feb 2004, Kurt Yoder wrote:
> >> Received: from ANeuilly-105-1-3-194.w80-13.abo.wanadoo.fr
> >> (ANeuilly-105-1-3-194.w80-13.abo.wanadoo.fr [80.13.58.194])
> >> by madagascar.shcorp.com (8.12.3/8.12.3/Debian-6.6) with SMTP id
> >> Received: from paypal.com (smtp1.nix.paypal.com [64.4.240.74])
> >> by ANeuilly-105-1-3-194.w80-13.abo.wanadoo.fr (Postfix) with ESMTP

> >> I don't know how it is making this decision, since
> >> the only reliable information is of course the ip address of the connecting
> >> server; in this case ANeuilly-105-1-3-194.w80-13.abo.wanadoo.fr
> >> [80.13.58.194]. I checked the BSP list and this IP is definitely not in
> >> there.

But is it checking the 'paypal' address that was spoofed? Perhaps this is
a flaw in the 'bondedsender' program?

> >> I'd guess the same for the default whitelist.

I thought 'DEF' stood for 'defined', as in 'user defined whitelist'?
You should check whatever whitelists you have, to see if 'paypal' is among
them?

- Charles

At 09:52 AM 2/24/2004, Charles Gregory wrote:
>But is it checking the 'paypal' address that was spoofed? Perhaps this is
>a flaw in the 'bondedsender' program?

If that's what it's checking, the flaw isn't with the bonded sender program
but with SpamAssassin. You can only really trust the last received header
added by a trusted host, SA should only be checking up to that point.

If someone puts a forged Received line indicating the mail came from
whatever.server.paypal.com, but your server actually gets it from
random.dsl.account.sbc.net, your copy of SpamAssassin should only check
random.dsl.account.sbc.net against the BSP list. SA shouldn't trust the
next line enough to even look.

If SA doesn't already do this, or if it's supposed to but doesn't, a bug
should be opened in Bugzilla.


Kelson Vibber
SpeedGate Communications <www.speed.net>

>> >a flaw in the 'bondedsender' program?

> If that's what it's checking, the flaw isn't with the bonded sender
> program but with SpamAssassin. You can only really trust the last
> received header added by a trusted host, SA should only be checking up
> to that point.
>
> If someone puts a forged Received line indicating the mail came from
> whatever.server.paypal.com, but your server actually gets it from
> random.dsl.account.sbc.net, your copy of SpamAssassin should only
> check random.dsl.account.sbc.net against the BSP list. SA shouldn't
> trust the next line enough to even look.
>
> If SA doesn't already do this, or if it's supposed to but doesn't, a
> bug should be opened in Bugzilla.

This is true, but I've had spam that triggered the rule, but none of the
hops were or ever had been in the BSP list. In fact, when I ran the spam
subsequently through Spamassassin, it would not trigger the rule again.

Regards,
John

At 02:50 PM 2/23/2004, Kurt Yoder wrote:
>Hi list
>
>I got a message with these (censored) headers recently:
<snip>

>Unfortunately, SA seems to think that this information is enough to score this
>message heavily negative. I don't know how it is making this decision, since
>the only reliable information is of course the ip address of the connecting
>server; in this case ANeuilly-105-1-3-194.w80-13.abo.wanadoo.fr
>[80.13.58.194]. I checked the BSP list and this IP is definitely not in there.
>I'd guess the same for the default whitelist.
>
>Is this a bug in the SA code or implementation? Or am I missing something?
>Please let me know; I'm setting both of these scores to 0 for now.


Kurt,

Looking at your message, it appears that SA's trust path code is a bit
confused.

Do you have an internal mailserver that runs SA which has a NATed IP
address? If so you MUST declare trusted_networks manualy. When SA fails to
determine any trust path, it goes a bit wonky and starts checking every
Received header against every rule, regardless of any matters of trust or
"notfirsthop".


The only IP which should be checked against bondedsender is the
80.13.58.194 address.. However, in this case, it also checked 64.4.240.74.
That particular Received: header is a forgery, and shouldn't be checked.


USER_IN_DEF_WHITELIST does mean it's in the "default" whitelist.. However,
many people use "def_whitelist_from_rcvd" in their own configs instead of
"whitelist_from_rcvd", which means that it doesn't have to be a default
whitelist, but it should be.

Again, the default whitelist shouldn't match, but does because the trusted
path code is confused. It should only be verifying the first RCVD header,
and not the second one.

What version of SA are you running? If not 2.63, is there any way you can
test against 2.63?

Could you run this through spamassassin with the -D flag? The debug output
can give some insight into the trust decisions SA is making.

Matt Kettler said:
>
>
> At 02:50 PM 2/23/2004, Kurt Yoder wrote:
>>Hi list
>>
>>I got a message with these (censored) headers recently:
> <snip>
>
>>Unfortunately, SA seems to think that this information is enough to score
>> this
>>message heavily negative. I don't know how it is making this decision, since
>>the only reliable information is of course the ip address of the connecting
>>server; in this case ANeuilly-105-1-3-194.w80-13.abo.wanadoo.fr
>>[80.13.58.194]. I checked the BSP list and this IP is definitely not in
>> there.
>>I'd guess the same for the default whitelist.
>>
>>Is this a bug in the SA code or implementation? Or am I missing something?
>>Please let me know; I'm setting both of these scores to 0 for now.
>
>
> Kurt,
>
> Looking at your message, it appears that SA's trust path code is a bit
> confused.
>
> Do you have an internal mailserver that runs SA which has a NATed IP
> address? If so you MUST declare trusted_networks manualy. When SA fails to
> determine any trust path, it goes a bit wonky and starts checking every
> Received header against every rule, regardless of any matters of trust or
> "notfirsthop".

Yes, I have an internal private IP. But the spamassassin machine is the first
IP that mail from the internet goes to on the route into our network. After
the email is scanned by spamassassin, it is then handed to a second machine,
then is delivered on a third machine. I ran -tD on the message as it was on
the third machine (see my earlier post in this thread). The extra headers
*may* have confused spamassassin, however that still doesn't explain why the
two "wrong" tests triggered on the mail when it first was scanned.

> What version of SA are you running? If not 2.63, is there any way you can
> test against 2.63?

I'm running 2.60. I can't really upgrade right now due to time constraints.
It's not a huge deal; I've disabled these two tests for now so that I don't
get any more false positives.

> Could you run this through spamassassin with the -D flag? The debug output
> can give some insight into the trust decisions SA is making.

See an earlier post by me to the list in this thread on Tue, February 24, 2004
10:52.

--
Kurt Yoder

At 01:09 PM 2/25/2004, Kurt Yoder wrote:

>Yes, I have an internal private IP. But the spamassassin machine is the first
>IP that mail from the internet goes to on the route into our network. After
>the email is scanned by spamassassin, it is then handed to a second machine,
>then is delivered on a third machine. I ran -tD on the message as it was on
>the third machine (see my earlier post in this thread). The extra headers
>*may* have confused spamassassin, however that still doesn't explain why the
>two "wrong" tests triggered on the mail when it first was scanned.

Yes it does explain why two "wrong" tests triggered. Both of the tests in
question rely on the trust-path code.

RCVD_IN_BONDEDSENDER must only be checked by IPs inserted by trusted servers.

And the "whitelist_from_rcvd" code must only check IPs inserted by trusted
servers.

If SA trusts the wrong list of servers, it can be foold by spammer's forged
headers..

proper trust is VERY critical to the proper operation of these rules.


> > Could you run this through spamassassin with the -D flag? The debug output
> > can give some insight into the trust decisions SA is making.
>
>See an earlier post by me to the list in this thread on Tue, February 24, 2004
>10:52.

Got it.. and I can see that SA is incorrectly declaring trust when it
shouldn't:

debug: received-header: 'from' 10.5.1.6 has reserved IP
debug: received-header: 'from' 10.5.1.6 is near to first 'by'
debug: received-header: relay 10.5.1.6 trusted? yes
debug: received-header: 'by' server1.shcorp.com has reserved IP
10.5.1.6
debug: received-header: 'by' server1.shcorp.com has no public IPs
debug: received-header: relay 80.13.58.194 trusted? yes
debug: received-header: 'by'
ANeuilly-105-1-3-194.w80-13.abo.wanadoo.fr has public IP 80.13.58.194
debug: received-header: relay 64.4.240.74 trusted? no

Note that in this case, the wanadoo.fr server is the first public IP'ed
machine in the received: path. Thus, SA incorrectly assumes that
80.13.58.194 is YOUR mailserver. So, SA declares it to be trusted, along
with everything leading up to it.

Since SA has decided to trust the wanadoo.fr machine, the forged relay
headers to it get checked against bondedsender and the whitelist rcvd paths.


add "trusted_networks 10.5.1.6/32" to your local.cf and see if it fixes the
problem.

You probably will also be experiencing FP problems with the dynablock DNSBL
until you fix this, for the same basic reasons... SA thinks that 10.5.1.6
isn't your border gateway.. it thinks the next machine out is... ouch.

Matt Kettler said:
> add "trusted_networks 10.5.1.6/32" to your local.cf and see if it fixes the
> problem.
>
> You probably will also be experiencing FP problems with the dynablock DNSBL
> until you fix this, for the same basic reasons... SA thinks that 10.5.1.6
> isn't your border gateway.. it thinks the next machine out is... ouch.

Good to know. I've added the trusted_networks config and put the two relay
test rules back in place. Running the same message through -tD indicated that
the problem has been fixed for the most part, though I'm still seeing

-0.1 RCVD_IN_BSP_OTHER RBL: Sender is in Bonded Sender Program (other relay)

I don't know why this is, but I guess it's better than -8.

Thanks

--
Kurt Yoder