Stuart D. Gathman wrote:
I was for TempError myself. But no match is ok.
Okay, let's say TempError is out, depending on how we
read RFC 4408 that alone is not necessarily an erratum.
There should probably be an errata to modify 2.5.7 if
we go with no match.
ACK, "no match" is not what 2.5.7 proposes, if we want
"no match" it needs an erratum.
[2.5.7]
This does not say specifically that 'example..com'
should be a PermError, just that some unspecified
condition might result in one.
The leading / trailing / adjacent dot cases as well as
macro-expanded label too long, or anything else that
makes it impossible to ask DNS for a second opinion,
are in an "unexpected format" (actually unsupported,
as far as DNS is concerned).
IMO it's not "some unspecified condition", it is an
"unexpected condition" from SPF's POV. The DNS STDs
specify that labels can't have zero length (excluding
the root), arguably that covers all dot-issues. The
DNS STDs also tell us various length limits, and IIRC
RFC 4408 cites them elsewhere.
ITYM "some unexpected conditions not specified in RFC
4408, but elsewhere" (RFC 1034/1035/1123, but I didn't
check the details).
Since 'example..com' cannot actually be sent to a DNS
server, it cannot result in an RCODE other than 0 or
3, and cannot result in a timeout, and hence cannot
be a TempError.
+1, TempError is no sound option.
Besides, in the non-macro case, the error is decidedly
permanent, no temporary.
+1
A PermError is wrong because in the macro case, the
error is *not* permanent, but may depend on the sender.
Here we have a disconnect, the same MAIL FROM and HELO
combo from the same IP with the same policy will always,
permanently, reproducible fail. Of course depending on
the alleged sender, that's just the S in SPF.
If it is a legit sender the policy needs to be fixed to
work also for the given MAIL FROM and HELO. If it's a
weird policy where the problem depends on a legit IP it
also needs to be fixed.
If it is spam we are not sure what is the best course,
the next matching mechanism after "no match" can be -all,
+all or anything, nothing an RFC 4408 erratum could say
is guaranteed to do the right thing after "no match".
But for legit mail it is a broken policy, and I'd have
no problem with saying PermError.
the spec is far from clear on the point, despite what
Julian says.
If we'd say PermError the wannabe-erratum degenerates
into a clarification, to be inserted at the end of 2.5.7.
The more important question is what you want in the test
suite and by extension in conforming SPF implementations.
Not necessarily what implementations happen to do today
with this obscure corner case, but what they *should* do:
Is it really "okay" (= no match) if a legit mail results
in an invalid <target-name> after macro-expansion, or is
this an error of the domain owner, his policy not working
for legit local parts used in his domain (or similar) ?
Do I miss an important case "permanently" triggering this
condition (any legit case, not abuse), where a "no match"
handling could be intended or at least better ?
Frank
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com