-----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
Matthew(_dot_)van(_dot_)Eerde(_at_)hbinc(_dot_)com
Sent: Tuesday, August 24, 2004 3:08 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Some thoughts about spam and SPF
Scott Kitterman wrote:
dnsmadeeasy.com. 1800 TXT "v=spf1 ip4:63.219.151.0/24 a mx
include:tiggee.com -all"
... and tiggee.com has no SPF record
Is there a standard way to interpret a null include: result?
... attempting to retrieve a non-existant
record will reliably get you an error result.
But isn't that exactly as it should be? If I read the record
from left to right:
Anything in 63.219.151.0/24 will return a PASS
Any A record in dnsmadeeasy.com will return a PASS
Any MX record in dnsmadeeasy.com will return a PASS
Anything that falls through to tiggee.com will depend on them
(currently ERROR)
Anything that fails all of the above will return a FAIL
So how is that broken? Seems good enough to me. Of course, it
will be better when tiggee.com publishes something (even if it's
just v=spf1 -all)
It can never return a fail. Once you get an error, the return condition is
error. If that weren't the case, then anything that went out via a
tiggee.com server would return fail. That would be bad.
So, if you snip off "Anything that fails all of the above will return a
FAIL", you would be correct. Anything that gets to the tiggee.com include
will always return an error.
Since the record as written (and as not supported by tiggee.com) can't
detect a forgery, I'd describe it as broken.
Scott Kitterman