Stuart D. Gathman wrote:
Y'all are going to hate me.
NAK
Section 4.3 clearly spells out what happens for a
too long label in MAIL FROM.
Or in HELO, yes. It's about the initial processing,
when you try to locate sender policy. If the input
is is unusable you can't find a sender policy, and
then the result is NONE.
Several mechanisms rely on information fetched from
DNS. For these DNS queries, except where noted, if
the DNS server returns an error (RCODE other than 0
or 3) or the query times out, the mechanism throws
the exception "TempError".
Yes, mapped to a PermError if a redirect= is broken,
and otherwise taken as result, even for an include:
Don't ask why redirect= derives from this model, it
sounds like another erratum, IIRC we wanted redirect=
to behave exactly like include: wrt errors and NONE (?)
If the server returns "domain does not exist" (RCODE 3),
then evaluation of the mechanism continues as if the
server returned no error (RCODE 0) and zero answer
records.
Quoted from the intro of section 5, yes.
A too long label, as well as an empty label, return
error codes from the resolver.
If you ask DNS. But you're supposed to detect syntax
errors first. 4.6: "in all cases, any syntax errors
anywhere in the record MUST be detected."
Now we're down to decide if "too long" is a syntax
error or not.
the behaviour is not explicitly specified.
If it's no syntax error it's a TempError based on
your quote from chapter 5 (RCODE neither 0 nor 3).
The test suite currently allows either temperror
or no-match.
No match isn't a specified possibility...
Are we really justified in requiring no-match?
...nope. But when you say "temperror or no-match"
it sounds like "allowing no-match", not requiring
it. The "initial processing" in 4.3 tells us that
a label with more than 63 octets is "malformed",
and that magic number is mentioned quite often in
the spec. (in conjunction with local parts).
In 4.3 "too long" and other cases of "malformed"
are mapped to the same NONE result as RCODE 3, in
4.4 *other* server errors are mapped to RCODE 2.
So for the *initial* processing you're supposed
to know what "too long" means. We could say that
SPF implementations should also know "malformed"
later. And take it as syntax error (PermError),
because it makes no sense to try again until the
policy is fixed.
I think it needs an official errata. If fact,
there is a proposed errata (for empty label,
but should apply to long label as well) - but
it requires permerror!!
The 4.2 definition of "malformed" explicitly
mentions empty (zero length) and "too long", we
would need a very compelling reason to arrive
at different interpretations of "malformed".
Devil's advocate: The syntax clearly doesn't
permit an "empty" domain, that's not the same
as an empty label. The proposed erratum about
a malformed <target-name> says that TempError
is obviously a bad idea. The confirmed errata
don't mention PermError for malformed labels.
IOW we can still do what we like best, and I
don't like TempError. This "last" erratum is
a can of worms (if it is the last, Julian and
now you proposed fresh errata in a similar
direction).
Let's tackle it backwards, arguably the spec.
says TempError, and obviously "we" don't like
this outcome, or does anybody ? Therefore it
*IS* an erratum, we can't trash it.
Arguably PermError is desirable for malformed
domains hardcoded in the policy. It's not so
clear that this also affects a <target-name>
after macro expansion, the spec. nowhere says
that <target-name> after macro expansion has
to be checked.
Is no-match desirable for a malformed domain ?
Is it desirable after macro expansion ? IFF
not we clearly want PermError, and can resolve
this old and the new (not yet noted) errata.
Otherwise, what do you propose ? If in doubt
no-match ?
Frank
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=74293494-984a3c
Powered by Listbox: http://www.listbox.com