No that doesn't help.. I'm still getting two different answers...
One is that it's the MTA only that I need to worry about with my SPF records.
The other is that it's all my dial pools that I need in my SPF records.
I really don't want my dial-up users being able to send mail
directly.... but that's irrelivant to the question.
So far I've been told twice now two different things.
Is it the MTA ip or the ip of the sending user that SPF checks? Can
a third party confirm this?
When I dial-up to this same pool and send mail to the spftest address
it doesn't come back to me, so it seems to me that the correct way is
to have it look at the IP of your MTA and *not* as you state the
dial/highspeed/whatever pools your users are connecting to.
On Fri, 12 Nov 2004 05:52:30 -0800, James Couzens <jcouzens(_at_)6o4(_dot_)ca>
wrote:
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
( ( (
((__)) __\|/__ __|-|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com