On Mon, 7 Apr 2008, Frank Ellermann wrote:
Stuart D. Gathman wrote:
You had me convinced that PermError was better than nomatch.
LOL, for the old 3:2 "rough" consensus I could claim that it
was actually 4:1 pretending that I changed my mind, now we
could be back at 2:3 ;-)
I know I voted for PermError, but I assumed I was in the minority. I
agree with the below.
literally putting a:example..com is a plausible typo that
should get a PermError
Yes. And dynamically getting example..com as a <target-name>
is also not what section 4.8 wants: A fully qualified domain
name with a series of labels separated by dots. There is no
DNS-syntactically valid FQDN with an empty label. Ignoring
empty label for the root here - nobody adds a dot at the end
of <target-name> if it is already there, permitted in AUTH48.
For include:example..com the outcome is a PermError. That is
consistent for check_host() results PermError or "no match",
both are mapped to PermError.
For "a" and "mx" an invalid <target-name> is arguably unclear.
Unfortunately "ptr" explicitly specifies "no match" for DNS
errors, and if ptr:example..com queries work in some way the
result can only be an error.
Yesterday I found a dig for W2K, it says that example..com is
not a legal name. W2K nslookup reports an unspecified error,
with -d it admits that res_mkquery() didn't work. JFTR, it's
of course not different from what I got on OS/2 a year ago.
The "last erratum" could admit what Julian said, RFC 4408 is
very unclear wrt this issue, and implementations could handle
it differently, but please not as TempError.
I was considering posting an auto-note to postmaster in case
of PermError in addition to a DSN, but PermError from macros
would discourage that.
Point. For the erratum, if we allow both outcomes, I could
add a caveat that implementations should state how they handle
invalid <target-name>. They could even offer to configure the
desired behaviour.
For the test suite allowing both is simple. But insisting on
"whatever you do be consistent" in the test suite is something
it can't do, or can it ?
Frank
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/1007/=now
RSS Feed: http://www.listbox.com/member/archive/rss/1007/
Powered by Listbox: http://www.listbox.com
--
Boyd Gerber <gerberb(_at_)zenez(_dot_)com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
-------------------------------------------
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