how to stop SPF checks from going past trusted host?

[Jo Rhett-3]

I'm trying to figure out how to stop SPF_FAIL on messages generated on  
an internal rfc1918 network and routed through a trusted host.

Host A: generates mail, origin IP 10.x.x.x

Host B: relays mail for Host A, to Host C

Host C: receives mail, marks SPF_FAIL

Host B is both in the valid SPF record, and in trusted networks.

Example:

     host A: 10.0.0.1 generates e-mail, routes via HostB

     Host B: has outside IP 64.13.143.16

     Host C: sees message from Host B, sees Host B is valid SPF  
sender, sees Host B is trusted Host

_APPARENTLY_ skips to the next Received header because B is trusted.

> Received: from arran.svcolo.com (arran.sc.svcolo.com  
> [64.13.143.17]) by kininvie.sv.svcolo.com (8.14.1/8.14.1) with ESMTP  
> id m5K2o3it016795 for <facility-admin@...>; Thu, 19 Jun 2008  
> 19:50:03 -0700 (PDT) (envelope-from facility-admin@...)
>
> Received: from apc0.sv.svcolo.com (apc0.sv [10.0.0.1]) by  
> arran.svcolo.com (8.13.8/8.13.4) with SMTP id m5K2o1sL002910 for <facility-admin@...
> >; Thu, 19 Jun 2008 19:50:02 -0700 (PDT) (envelope-from facility-admin@...
> )
>
> X-Spam-Status: Yes, score=4.157 tagged_above=-10 required=4  
> tests=[AWL=0.656, NORMAL_HTTP_TO_IP=0.001, SPF_FAIL=3.5
>

Obviously, putting 10/8 into the published SPF record makes no sense  
at all, nor does adding 10/8 to the trusted_networks.

So... how can I say "I trust Host B so much that I don't want to go  
any farther for SPF checks?"

--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

[John Hardin]

On Thu, 2008-06-19 at 20:37 -0700, Jo Rhett wrote:


> Example:
>
>      host A: 10.0.0.1 generates e-mail, routes via HostB
>
>      Host B: has outside IP 64.13.143.16

> > Received: from arran.svcolo.com (arran.sc.svcolo.com  
> > [64.13.143.17]) by kininvie.sv.svcolo.com (8.14.1/8.14.1) with ESMTP  
> > id m5K2o3it016795 for <facility-admin@...>; Thu, 19 Jun 2008  
> > 19:50:03 -0700 (PDT) (envelope-from facility-admin@...)
> >
> > Received: from apc0.sv.svcolo.com (apc0.sv [10.0.0.1]) by  
> > arran.svcolo.com (8.13.8/8.13.4) with SMTP id m5K2o1sL002910 for <facility-admin@...
> > >; Thu, 19 Jun 2008 19:50:02 -0700 (PDT) (envelope-from facility-admin@...
> > )
> >
> > X-Spam-Status: Yes, score=4.157 tagged_above=-10 required=4  
> > tests=[AWL=0.656, NORMAL_HTTP_TO_IP=0.001, SPF_FAIL=3.5
> >
> Obviously, putting 10/8 into the published SPF record makes no sense  
> at all, nor does adding 10/8 to the trusted_networks.
>
> So... how can I say "I trust Host B so much that I don't want to go  
> any farther for SPF checks?"

Do you *need* to get the SPF test to pass, or do you just want to lower
the score?

If the latter, how about:

header  XX Received =~ /from \S+\.svcolo\.com (\S+ \[10\.\d\.\d\.\d\])
by arran\.svcolo\.com (/
score  XX  -5


--
 John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
 jhardin@...    FALaholic #11174     pgpk -a jhardin@...
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
  Perfect Security is unattainable; beware those who would try to sell
  it to you, regardless of the cost, for they are trying to sell you
  your own slavery.
-----------------------------------------------------------------------
 15 days until the 232nd anniversary of the Declaration of Independence

[Matt Kettler-3]

Jo Rhett wrote:

> I'm trying to figure out how to stop SPF_FAIL on messages generated on
> an internal rfc1918 network and routed through a trusted host.
>
> Host A: generates mail, origin IP 10.x.x.x
>
> Host B: relays mail for Host A, to Host C
>
> Host C: receives mail, marks SPF_FAIL
>
> Host B is both in the valid SPF record, and in trusted networks.
>
> Example:
>
>     host A: 10.0.0.1 generates e-mail, routes via HostB
>
>     Host B: has outside IP 64.13.143.16
>
>     Host C: sees message from Host B, sees Host B is valid SPF sender,
> sees Host B is trusted Host
>
> _APPARENTLY_ skips to the next Received header because B is trusted.

That is correct, SPF checks are applied to the first untrusted host. The
question here would be if 10.x.x.x is in fact an internal, and
presumably trusted, network, why isn't it trusted?

Also, presuming we're talking about your own domain, why aren't you
using split DNS and declaring 10.x.x.x as a valid source in your
internal SPF record (but not the one you expose to the outside world)

>> Received:     from arran.svcolo.com (arran.sc.svcolo.com
>> [64.13.143.17]) by kininvie.sv.svcolo.com (8.14.1/8.14.1) with ESMTP
>> id m5K2o3it016795 for <facility-admin@...>; Thu, 19 Jun 2008
>> 19:50:03 -0700 (PDT) (envelope-from facility-admin@...)
>>
>> Received:     from apc0.sv.svcolo.com (apc0.sv [10.0.0.1]) by
>> arran.svcolo.com (8.13.8/8.13.4) with SMTP id m5K2o1sL002910 for
>> <facility-admin@...>; Thu, 19 Jun 2008 19:50:02 -0700 (PDT)
>> (envelope-from facility-admin@...)
>>
>> X-Spam-Status:     Yes, score=4.157 tagged_above=-10 required=4
>> tests=[AWL=0.656, NORMAL_HTTP_TO_IP=0.001, SPF_FAIL=3.5
>>
> Obviously, putting 10/8 into the published SPF record makes no sense
> at all, nor does adding 10/8 to the trusted_networks.

Why do neither of those options make sense? I do both in my network,
albeit that version SPF is only in my internal view, and I actually use
10.xx.0.0/16 not 10/8. (I only use a /16, not the whole /8)

Is there some detail that's missing here? ie: do you have a compelling
reason to not trust your internal hosts using 10/8?


> So... how can I say "I trust Host B so much that I don't want to go
> any farther for SPF checks?"
Modify the SPF code. There's no such option at present.

[John Hardin]

On Thu, 2008-06-19 at 20:54 -0700, John Hardin wrote:

> header  XX Received =~ /from \S+\.svcolo\.com (\S+ \[10\.\d\.\d\.\d\]) by arran\.svcolo\.com (/
> score  XX  -5

Oops. Need some plusses in there...

/from \S+\.svcolo\.com (\S+ \[10\.\d+\.\d+\.\d+\]) by arran\.svcolo\.com
(/

--
 John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
 jhardin@...    FALaholic #11174     pgpk -a jhardin@...
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
  Perfect Security is unattainable; beware those who would try to sell
  it to you, regardless of the cost, for they are trying to sell you
  your own slavery.
-----------------------------------------------------------------------
 15 days until the 232nd anniversary of the Declaration of Independence

[mouss-2]

John Hardin wrote:

> On Thu, 2008-06-19 at 20:54 -0700, John Hardin wrote:
>
>  
>> header  XX Received =~ /from \S+\.svcolo\.com (\S+ \[10\.\d\.\d\.\d\]) by arran\.svcolo\.com (/
>> score  XX  -5
>>    
>
> Oops. Need some plusses in there...
>
> /from \S+\.svcolo\.com (\S+ \[10\.\d+\.\d+\.\d+\]) by arran\.svcolo\.com
> (/
>
>  

What happens if such header was forged?

[Henrik K]

On Fri, Jun 20, 2008 at 12:12:45AM -0400, Matt Kettler wrote:
>
> That is correct, SPF checks are applied to the first untrusted host.

Matt, you should know better. ;) It's first _external_ host.

[Matt Kettler-3]

Henrik K wrote:
> On Fri, Jun 20, 2008 at 12:12:45AM -0400, Matt Kettler wrote:
>  
>> That is correct, SPF checks are applied to the first untrusted host.
>>    
>
> Matt, you should know better. ;) It's first _external_ host.
>
>
>  
Doh.. my bad.

[Matt Kettler-3]

Matt Kettler wrote:
> Why do neither of those options make sense? I do both in my network,
> albeit that version SPF is only in my internal view, and I actually
> use 10.xx.0.0/16 not 10/8. (I only use a /16, not the whole /8)
>
> Is there some detail that's missing here? ie: do you have a compelling
> reason to not trust your internal hosts using 10/8?

Side note:

There is no risk of "trusting everyone's email" when you add 10/8 to
your trusted_networks. This is because trust in spamassassin is a chain
that must be unbroken to work. Once an message has been handled by an
untrusted host, you can't trust any earlier Recieved: headers.

Take an example where email comes from the outside (headers simplified,
it's an example...):

Received from trusted_host.jrhett.com [64.13.143.10] by
sa_box.jrett.com; 12:02:00 +0000
Received from example.somoutsidedomain.com[1.1.1.1] by
trusted_host.jrhett.com; 12:01:00 +0000
Received from insideclient.someoutsidedomain [10.1.1.1] by
example.somoutsidedomain.com; 12:00:00 +0000

Here, spamassassin will trust "trusted_host.jrhett.com [64.13.143.10]",
because it's been configured to do so. However, it does not trust
example.somoutsidedomain.com[1.1.1.1].
Because example.somoutsidedomain.com[1.1.1.1] is untrusted,  
insideclient.someoutsidedomain [10.1.1.1] is also untrusted, even though
10/8 is in trusted_networks.

[John Hardin]

On Fri, 20 Jun 2008, mouss wrote:

> John Hardin wrote:
>>  On Thu, 2008-06-19 at 20:54 -0700, John Hardin wrote:
>>
>> >  header  XX Received =~ /from \S+\.svcolo\.com (\S+ \[10\.\d\.\d\.\d\])
>> >  by arran\.svcolo\.com (/
>> >  score  XX  -5
>>
>>  Oops. Need some plusses in there...
>>
>>  /from \S+\.svcolo\.com (\S+ \[10\.\d+\.\d+\.\d+\]) by arran\.svcolo\.com (/
>
> What happens if such header was forged?

Then the message gets -5 points added to it's score.

How likely is a header forged with that particular data going to be sent
in a message to that particular SA host?

If that's a concern then add a rule to verify that the SA host received
the message from the relay, use a meta to AND them, and score the meta
rule at -5.

--
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@...    FALaholic #11174     pgpk -a jhardin@...
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Efficiency can magnify good, but it magnifies evil just as well.
   So, we should not be surprised to find that modern electronic
   communication magnifies stupidity as *efficiently* as it magnifies
   intelligence.                                   -- Robert A. Matern
-----------------------------------------------------------------------
  14 days until the 232nd anniversary of the Declaration of Independence

[Jo Rhett-3]

On Jun 19, 2008, at 9:12 PM, Matt Kettler wrote:
> That is correct, SPF checks are applied to the first untrusted host.  
> The question here would be if 10.x.x.x is in fact an internal, and  
> presumably trusted, network, why isn't it trusted?

The mail server I'm receiving this on is in the outside world.  If a  
10.x address connects to it, I don't want that address to be trusted  
for any reason.  Only 10.x addresses that came via a trusted host ;-)

> Also, presuming we're talking about your own domain, why aren't you  
> using split DNS and declaring 10.x.x.x as a valid source in your  
> internal SPF record (but not the one you expose to the outside world)

Split DNS only applies if the mail is on the "inside" which it isn't.

There actually isn't an "inside" network at all, except for this one  
non-routed private network used for monitoring physical gear.  It does  
not route to the outside world, with the exception of mail relay.

>>> Obviously, putting 10/8 into the published SPF record makes no  
>>> sense at all, nor does adding 10/8 to the trusted_networks.

> Why do neither of those options make sense? I do both in my network,  
> albeit that version SPF is only in my internal view, and I actually  
> use 10.xx.0.0/16 not 10/8. (I only use a /16, not the whole /8)

No internal view, no internal DNS.  Putting 10/8 into external DNS is  
nonsense ;-)

> Is there some detail that's missing here? ie: do you have a  
> compelling reason to not trust your internal hosts using 10/8?

Those internal hosts cannot connect to the mail server directly.  Any  
10.x address that does connect to the mailserver is guaranteed to be a  
spammer.

--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

[Jo Rhett-3]

>> On Fri, Jun 20, 2008 at 12:12:45AM -0400, Matt Kettler wrote:
>>> That is correct, SPF checks are applied to the first untrusted host
>>

> Henrik K wrote:
>> Matt, you should know better. ;) It's first _external_ host.

On Jun 20, 2008, at 3:54 AM, Matt Kettler wrote:
> Doh.. my bad.


Huh?  How are you defining "external" in this context?  What prevents  
me from trusting an external hosts?

I don't actually have any "internal" hosts -- no NAT, no firewall,  
it's all outside.  There's hosts I trust, but none that aren't external.

--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

[Benny Pedersen]

On Fredag, 20/6 2008, 05:37, Jo Rhett wrote:
> I'm trying to figure out how to stop SPF_FAIL on messages generated on
> an internal rfc1918 network and routed through a trusted host.

netconsonance.com. IN TXT "v=spf1 ip4:64.13.134.178 ip4:64.13.143.17
ip4:209.157.140.144 mx ~all"

not you ?

>> Received: from arran.svcolo.com (arran.sc.svcolo.com
>> [64.13.143.17]) by kininvie.sv.svcolo.com (8.14.1/8.14.1) with ESMTP
>> id m5K2o3it016795 for <facility-admin@...>; Thu, 19 Jun 2008
>> 19:50:03 -0700 (PDT) (envelope-from facility-admin@...)



Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098

[Henrik K]

On Fri, Jun 20, 2008 at 10:28:25AM -0700, Jo Rhett wrote:

>>> On Fri, Jun 20, 2008 at 12:12:45AM -0400, Matt Kettler wrote:
>>>> That is correct, SPF checks are applied to the first untrusted host
>>>
>
>> Henrik K wrote:
>>> Matt, you should know better. ;) It's first _external_ host.
>
> On Jun 20, 2008, at 3:54 AM, Matt Kettler wrote:
>> Doh.. my bad.
>
>
> Huh?  How are you defining "external" in this context?  What prevents me
> from trusting an external hosts?

Nothing prevents you from trusting external hosts, you should do it as
necessary.

Here we go again..

internal_networks = internal/external
trusted_networks = trusted/untrusted

Both define borders which things are checked against. Internal is your
"MX-border", against which SPF and RBL checks are made (all internal must be
in trusted also). Trusted can expand further to prevent RBL checks against
trusted hosts and allows kind of whitelisting with ALL_TRUSTED rule.

http://wiki.apache.org/spamassassin/TrustPath

PS. https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5856

[Jo Rhett-3]

> On Fredag, 20/6 2008, 05:37, Jo Rhett wrote:
>> I'm trying to figure out how to stop SPF_FAIL on messages generated  
>> on
>> an internal rfc1918 network and routed through a trusted host.
>
On Jun 20, 2008, at 10:37 AM, Benny Pedersen wrote:
> netconsonance.com. IN TXT "v=spf1 ip4:64.13.134.178 ip4:64.13.143.17
> ip4:209.157.140.144 mx ~all"
>
> not you ?


Nope ;-)

--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

[Jo Rhett-3]

On Jun 20, 2008, at 10:44 AM, Henrik K wrote:

> On Fri, Jun 20, 2008 at 10:28:25AM -0700, Jo Rhett wrote:
>>>> On Fri, Jun 20, 2008 at 12:12:45AM -0400, Matt Kettler wrote:
>>>>> That is correct, SPF checks are applied to the first untrusted  
>>>>> host
>>
>>> Henrik K wrote:
>>>> Matt, you should know better. ;) It's first _external_ host.
>>
>> On Jun 20, 2008, at 3:54 AM, Matt Kettler wrote:
>>> Doh.. my bad.
>>
>>
>> Huh?  How are you defining "external" in this context?  What  
>> prevents me
>> from trusting an external hosts?
>
> Nothing prevents you from trusting external hosts, you should do it as
> necessary.
>
> Here we go again..
>
> internal_networks = internal/external
> trusted_networks = trusted/untrusted
>
> Both define borders which things are checked against. Internal is your
> "MX-border", against which SPF and RBL checks are made (all internal  
> must be
> in trusted also). Trusted can expand further to prevent RBL checks  
> against
> trusted hosts and allows kind of whitelisting with ALL_TRUSTED rule.

Okay, so my understanding is correct.  So why did you correct Matt?  
He said first untrusted host.  You said first external host.  If  
internal hosts must all be trusted, and some external hosts may be  
trusted, then the SPF check would be applied to the first untrusted  
host, not the first external host.

--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

[Benny Pedersen]

On Fredag, 20/6 2008, 10:04, Henrik K wrote:
> On Fri, Jun 20, 2008 at 12:12:45AM -0400, Matt Kettler wrote:
>> That is correct, SPF checks are applied to the first untrusted host.
> Matt, you should know better. ;) It's first _external_ host.

and is most of the time olso first untrusted ? :)

both is imho correct


Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098

[Jo Rhett-3]

On Jun 19, 2008, at 9:21 PM, John Hardin wrote:
> /from \S+\.svcolo\.com (\S+ \[10\.\d+\.\d+\.\d+\]) by arran\.svcolo
> \.com
> (/


You actually need some backslashes too, but I figured it out.  Thanks.

See my other note about trusted_hosts breaking all forms of  
whitelisting, FYI.  This kind of hackery (although appreciate the  
help) is kindof nonsense :-(

--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

[John Hardin]

On Fri, 20 Jun 2008, Jo Rhett wrote:

> On Jun 19, 2008, at 9:21 PM, John Hardin wrote:
>> /from \S+\.svcolo\.com (\S+ \[10\.\d+\.\d+\.\d+\]) by arran\.svcolo\.com (/
>
> You actually need some backslashes too, but I figured it out.  Thanks.

D'oh!

> See my other note about trusted_hosts breaking all forms of
> whitelisting, FYI.  This kind of hackery (although appreciate the help)
> is kindof nonsense :-(

Yeah. Trust and Internal properly set up and working is, of course, the
optimal solution. Just wanted to point out it's not the _only_ solution.

Also:

> On Jun 19, 2008, at 9:12 PM, Matt Kettler wrote:
>> That is correct, SPF checks are applied to the first untrusted host. The
>> question here would be if 10.x.x.x is in fact an internal, and presumably
>> trusted, network, why isn't it trusted?
>
> The mail server I'm receiving this on is in the outside world. If a 10.x
> address connects to it, I don't want that address to be trusted for any
> reason.  Only 10.x addresses that came via a trusted host ;-)

10.x is (supposedly) not routable on the public internet. If you see 10.x
(or other RFC-1918) traffic coming in from the world, your ISP is broken.

--
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@...    FALaholic #11174     pgpk -a jhardin@...
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Perfect Security is unattainable; beware those who would try to sell
   it to you, regardless of the cost, for they are trying to sell you
   your own slavery.
-----------------------------------------------------------------------
  14 days until the 232nd anniversary of the Declaration of Independence