spf-discuss
[Top] [All Lists]

RE: Odd Problem

2004-11-12 07:22:20
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of James 
Couzens
Sent: Friday, November 12, 2004 9:20 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Odd Problem


On Fri, 2004-11-12 at 09:04 -0500, Scott Kitterman wrote:


-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of 
James Couzens
Sent: Friday, November 12, 2004 8:53 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Odd Problem


On Fri, 2004-11-12 at 07:39 -0500, Matt wrote:

So how is SPF supposed to work?  Is it supposed to care about the
previous IP that the user used to connect?   I've got (and am getting
from this mailing list) the impression that it should not care, since
the mail server is authorized... but here is what I got from
barracude....  any insight?


--------------------------------

Barracuda Support wrote:

Hello Matt,

The sender is from IP  198.69.X.X   does not match your SPF
record 63.174.244.0/24

Barracuda is correct.

I already answered this for you, so here it is again:

james(_at_)code3 ~ $ /usr/local/bin/spfqtool_static -d 0 -s
jcouzens(_at_)chilitech(_dot_)net -i 198.69.197.61 -h test

SPF short result:   fail
SPF verbose result: policy result: (fail) from rule (-all)

RFC2822 header:     Received-SPF: fail (test: domain of
jcouzens(_at_)chilitech(_dot_)net
                   does not designate 198.69.197.61 as
permitted sender)
                   receiver=test; client_ip=198.69.197.61;
                   envelope-from=jcouzens(_at_)chilitech(_dot_)net;

This is because his DNS is not published correctly.  Upon further
examination you'll see that his PTR record does not match because its
does not validate.  It does not validate because the reversely obtained
hostname 'du1-61-as5800-towanda.dial.chilitech.net' (from 198.69.197.61)
does not in turn then resolve forward to '198.69.197.61' and thus misses
the PTR bus and hops on the fail train.

Either *FIX* your PTR record so that the forward matches the reverse,
and vice versa, or simply add either ip4:198.69.197.0/24 or
ip4:198.69.197.61 to your SPF record.

Hoping that helps.

Cheers,

James

--
James Couzens,
Programmer

Except that he doesn't want 198.69.197.61 to pass.

Looking back at the original headers he posted, see below, it
seems pretty
clear that the edge MTA was smtp1-ha.chilitech.net
(smtp1-ha.chilitech.net
[63.174.244.3]) and that the message should have passed.
There's no reason
for 198.69.197.61 or the PTR to even come into it.

If that is the case (it does appear so although those headers are a
ghastly mess at least on my MUA) then you are quite right.  What
confused me is that somehow my e-mail to SPF-HELP never made it there or
was not "moderated" appropriately.  This is what it said:

This test shows your spf records 'mx' and 'ip4' mechanisms to function
appropriately as you can see I get a pass.

james(_at_)code3 ~ $ spfqtool -d 1 -s jcouzens(_at_)chilitech(_dot_)net -i 
63.174.244.1
-h test
SPF Query Tool v0.4 - James Couzens <jcouzens(_at_)codeshare(_dot_)ca>
[DEBUG]: Debugging level:    1
[DEBUG]: RFC2821 Mail From:  jcouzens(_at_)chilitech(_dot_)net
[DEBUG]: RFC2821 HELO:       test
[DEBUG]: Purported address:  63.174.244.1
[DEBUG]: SPF Explanation:    Disabled
[DEBUG]: Trusted Forwarder:  Disabled
[DEBUG]: Best Guess:         Disabled

SPF short result:   pass
SPF verbose result: policy result: (pass) from rule (ptr)
RFC2822 header:     Received-SPF: pass (test: domain of
jcouzens(_at_)chilitech(_dot_)net designates 63.174.244.1 as permitted sender)
receiver=test; client_ip=63.174.244.1;
envelope-from=jcouzens(_at_)chilitech(_dot_)net;

From rom your headers:

Received: from unknown (HELO thepurplebeast) ([198.69.197.61])
          (envelope-sender <pioneer(_at_)chilitech(_dot_)net>)
          by 0 (qmail-ldap-1.03) with SMTP
          for <hofr(_at_)gemabooks(_dot_)com>; 9 Nov 2004 22:21:20 -0000


Had he seen this he would have gotten the right idea (likely) and this
wouldn't have dragged on.  It does appear that the Barracuda device is
looking at the wrong ip, but then, would they not be screwing up every
SPF check?

Cheers,

James


Hard to say.  It definitely looks like they picked the wrong IP in this
case.  Why is probably a question best directed at Barracuda.

Scott Kitterman


<Prev in Thread] Current Thread [Next in Thread>