Florian Weimer wrote:
alleged "DNS gurus" wanted a PermError.
If this is a problem, I can go guru shopping and find
someone with proper credentials who strongly opposes
such a requirement.
Yes, please do so, if possible not James deBoynePollard.
We used to have our own DNS guru here in 2004 (Stephane),
but IIRC he never commented this point.
you and others were in favor of PermError-ing as often
as possible, with all the consequences (e.g.
<42F32E72(_dot_)7EDB(_at_)xyzzy(_dot_)claranet(_dot_)de>).
Yes. That article was lame, for the original conflict see
<http://mid.gmane.org/42904317(_dot_)1574(_at_)xyzzy(_dot_)claranet(_dot_)de>
and
<http://mid.gmane.org/429E989F(_dot_)3AD0(_at_)xyzzy(_dot_)claranet(_dot_)de>
Your third point indicates that you'd prefer to treat these
issues as TempErrors. Let's say that they need their own
(third) class of error.
I don't think more error codes help. In the end, all I'm
interested in (as a prospective SPF record publisher) is how
receivers interpret my SPF record, in terms of message
rejection, queuing, and so on.
Publishers of sender policies will try something like
"include:eample.org" as often as
"inlude:example.org"
With PermError it should be clear that nobody has good reasons
to do this intentionally. BTW, my POV is attacker or receiver.
Publishers should at least get it right. After all they want
something from both spammers ("forge another domain") and
receivers ("reject forged mails, don't accept and bounce").
More error codes do not help in this context, because in
general, they introduce more room for interpetation by
implementators and system administrators. This means that
the policy expressed in the SPF record is ambiguous.
"inlude:example.org" is unambiguous, it's wrong. The variant
"include:eample.org" is less clear _iff_ it's only a temporary
problem. But if "eample.org" really has no sender policy, or
in fact it doesn't exist at all, then it's not "better" than a
syntax error "inlude".
Back to the critical "include" table, we have in chapter 4.4:
| If the DNS lookup returns a server failure (RCODE 2), or
| other error (RCODE other than 0 or 3), or the query times
| out, check_host() exits immediately with the result
| "TempError".
An "included" TempError is mapped to TempError, that should be
okay. But "include:eample.org" is RCODE 3, the domain doesn't
exist, let alone any sender policy, the "include" returns NONE
mapped to PermError. IMHO also okay.
Maybe what you really want is two versions of NONE, a normal
"policy doesn't exist" vs. a different "domain doesn't exist"
- Julian proposed something in this direction, but it had a
problem elsewhere (resulting in even more PermErrors than we
have now).
His concept OTOH was clear, preserve the info you have, either
"no policy" or "no domain", don't fold it in one obscure NONE.
So if we had NONE-1 and NONE-2 (the latter for "no domain") we
could do something smart with a NONE-1 in the case of "include"
or "redirect=".
Tricky. If I got it right you propose NONE-1 => TempError and
NONE-2 (NXDOMAIN) => PermError, _only_ for include / redirect=.
the SPF standardization process has such a tendency towards
ambiguities (even if they undermine the S in SPF) for two
reasons: Unresolved conflict (and some discussions on this
reflect this), and a desire not to make deployed
implementations non-conforming.
Yes. This include-detail hunts us for more than a year now.
And I didn't see that it's related to Julian's point - I only
saw that his concept is cleaner but unfortunately incompatible.
But maybe using it only "internally" in the form of NONE-1 for
include / redirect= is a possibility. The very same point is
also an issue in Andy's "SPF considerations", see also:
draft-newton-maawg-spf-considerations-00
Many of these SPF considerations are now obsolete or beside the
point, but _everybody_ (now you) is fascinated by this include
issue, it might be really unresolved. <sigh />
the latter part troubles me because this means that most of
the discussion about defects in the spec becomes pointless.
Introducing completely new concepts of PermError isn't possible
for v=spf1 - the former editor (Mark L.) and Julian already hit
that wall, don't try it, it hurts. But getting the "include"
issue right could be easy, we already tried almost everything,
therefore we are free to get it right now.
Bye, Frank