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.
Besides, I don't think we should harden the border between "has SPF RR" and
"has no SPF RR" domains -- IOW, why should a domain not be allowed to
include another domain's policy in the anticipation that the include
target will publish an explicit domain in the near or not so near future?
Thus: a user thinks "let's allow every host `example.com' approves of,
deny the right to all other hosts".
The resulting policy: (spf version number not important here)
"v=spf1 include:example.com -all"
Now we have reached the situation you speak of: the user applies the
policy of `example.com'. What the user does not know/understand is
that this policy is non-existant.
Desired behaviour: allow servers belonging to example.com
Obtained behaviour: allow no single server
I fail to see where this newly proposed behaviour is user friendly,
helpful, better than the current behaviour etc.
And: case [a] can always be detected immediately, because "511 PermError:
SPF-less domain included" and "511 Fail" are likely to be treated identi-
cally by receivers.
Differences:
-1- the first may result in further actions, such as DSN
-2- both will result in a bounce.
-2a- the message was not sent via a relay: the user will get
to see the error message
-2b- the message was sent via a relay, resulting in a DSN.
the user gets to see this DSN.
(disfunctional software, such as outlook express, may
need some major upgrading. NOP.)
continue 2:
the user is informed that the message was rejected due to
either a syntax error in the SPF record or due to his host
not being allowed. Big difference.
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.
* 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.
Two examples out of an infinite number of possibilities:
1) Circular reference detecting fails, processing needs to be stopped by
other means such as a timer or even a complete systems shutdown (due to
all memory and cpu being consumed, resulting in no time left to trash).
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.
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"
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/
Let's agree to disagree. I see no point in discussing this further.
Alex
-------
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