-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alex van den Bogaerdt wrote:
On Sat, Mar 11, 2006 at 11:58:08AM +0000, Julian Mehnle wrote:
Unintended results will happen either way:
a) the included domain normally does have an SPF(TXT) record but due
to a mistake it does no longer have one
b) the included domain does not have such a record
If treated as "no-match" then case [a] is undesirable; the user
probably wants to know there's a problem.
If treated as "error" then case [b] is undesirable; the user doesn't
care enough to understand or investigate.
I think most errors will be type [b] but should ignorance win?
I disagree. This is not generally a matter of ignorance, but of how
we perceive SPF. IMO an "include:foo" means "apply the policy of
domain foo, then continue". If you view a domain policy not just as a
concrete DNS RR but as an abstract policy, then a missing DNS RR would
also be a valid (though empty) policy.
[...]
I fail to see where this newly proposed behaviour is user friendly,
helpful, better than the current behaviour etc.
As you said above, desired and undesired results can occur for both the
existing "include:domain-w/o-spf-record throws error" and the proposed
"include: domain-w/o-spf-record is ignored" behavior. I also understand
that interpreting "undefined" as the empty set may be problematic. I'll
have to think about it more before I comment further on the issue.
Other argument: the not-so-bright and/or the lazy now create policies
looking like "v=spf1 a mx ptr a:hostname_here mx:hostname_here
ptr:hostname_here -all" and continue expanding `until it works'.
Allow empty includes and be prepared to see:
"v=spf1 a mx ptr include:email_provider include:access_provider
include:web_provider include:grandpa's_provider
include:neightbour's_provider -all" `until it works'. Yes, I really
think it is that bad. No, I don't believe it is pessimism or even
sarcasm.
Your assumption of users wanting to include every domain on the world
"unless we stop them" is unrealistic, and I don't believe it is our
obligation to preempt such supposedly broken configurations.
* Tolerate circular inclusions
(a.org: include:b.org, b.org: include:a.org)
ugh... can we say can of worms?
Detecting circles is trivial, so what would the harm be?
Is it? I am too lazy to look it up but ISTR discussion on this for the
current spec and think the outcome is that circular references need not
be detected because of other limits. The reason this was discussed: it
is far from trivial to detect circular references not being trivial
cases themselves.
I don't know what ISTR is, but if we maintain the current recursion limit
of 10 lookups, we can detect circles with a simple (associative) array with
a maximum size of 10 elements.
Two examples out of an infinite number of possibilities:
1) Circular reference detecting fails,
Circle detection is 100% reliable under the given circumstances.
2) a includes b, b includes c, c includes d, d used to be without
includes. d has problems, the others are unaware and unaffected. d gives
up, looks at what a has achieved, appreciates the good results so stops
publishing his own record and just includes a.
Sorry, but I don't understand your case. :-( Why should anyone retract
their own record because of inclusions?
Tolerating circular inclusions would be important in order for the
more abstract concept of domain policies to work (domains should be
able to mutually "trust" each other).
You mean like this?
example.org txt "v=spf1 include:_spf.example.com include:_spf.example.org
-all"
example.com txt "v=spf1 include:_spf.example.com include:_spf.example.org
-all"
_spf.example.org txt "v=spf1 ip4:a.b.c.d -all"
_spf.example.com txt "v=spf1 mx -all"
No, like this:
example.org TXT "v=spf1 a mx include:example.com -all"
example.com TXT "v=spf1 a mx include:example.net -all"
example.net TXT "v=spf1 a mx include:example.org -all"
The domains involved don't necessarily have to be within the same
administrative domain, i.e. owned by the same person/organization. Your
example requires cooperation, mine doesn't (if circular inclusion is
allowed).
Instead they will leave "op=testing" forever. IOW: what's the
benefit?
That they're _aware_ that they're still in testing mode. Many don't
know that "~" is specifically meant for testing.
s/know/want to know/
I doubt that most domain owners using "~all" don't _want_ to know that it
is meant for testing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEEz9BwL7PKlBZWjsRAijlAJ4jqI66dXCNqJ//3ytotMXlFV+lBgCePaGG
jCJM//wSsMg0cjofZs+vPP0=
=PU99
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
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