gerberb at zenez
Apr 6, 2008, 11:38 PM
Post #2 of 5
(465 views)
Permalink
|
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.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/1007/=now
RSS Feed: http://www.listbox.com/member/archive/rss/1007/
Powered by Listbox: http://www.listbox.com
|
