Mailing List Archive

Re: Last erratum last call
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 ;-)

> 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
Re: Re: Last erratum last call [ In reply to ]
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@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
Re: Last erratum last call [ In reply to ]
Boyd Lynn Gerber wrote:

> I know I voted for PermError, but I assumed I was in the
> minority.

Oops, sorry, I missed that. In the last round since about
November 2007 I only counted Ale, Julian, Stuart, and Terry.

> I agree with the below.

Okay, if Julian, Terry, or somebody else doesn't scream I'll
try the "both okay, and certainly not TempError" approach.

We clearly have consensus for "no TempError", and it is not
only rough.

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
Re: Re: Last erratum last call [ In reply to ]
Frank Ellermann wrote:
> Stuart D. Gathman wrote:
>> 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.

While the DSN is questionable as usual, an auto-note to postmaster in
case of PermError should trigger the desired effect.

> 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.

That looks appealing. Is it possible to also add similar debugging
features to the ~all setting, along the same line of reasoning?

-------------------------------------------
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
Re: Re: Last erratum last call [ In reply to ]
On Mon, 7 Apr 2008, Boyd Lynn Gerber wrote:

> > 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 ?

Perhaps suitably contrived examples involving a,mx,ptr, and "-include"
might detect inconsistent usage - I do something similar to detect
valid HELO via the SPF record. I'll play with it. There is no specification
for "all results in this group must be the same". We could add it, but I don't
think it is worth the test driver complication.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
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
Re: Last erratum last call [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First, I apologize for having been AWOL for several months and having
dropped the ball on the test-suite release. I got overrun by a move and a
new job.

Frank Ellermann wrote:
> Okay, if Julian, Terry, or somebody else doesn't scream I'll try the
> "both okay, and certainly not TempError" approach.
>
> We clearly have consensus for "no TempError", and it is not only rough.

Frank, thanks for writing up the erratum proposal:

http://www.openspf.org/RFC_4408/Errata?action=browse&diff=1&revision=58&diffrevision=53

I think all of us are mostly on the same page now with regard to the issue
matter. I do have one concern about the erratum wording, though. Your
proposal puts all the stuff in the "PermError" definition in section
2.5.7. I don't think that's appropriate. How about the attached diff
instead?

In any case I have adjusted the test suite to allow both the "PermError"
and no-match behaviors:

http://www.openspf.org/source/project/test-suite/rfc4408-tests.yml?rev=98&view=markup
http://www.openspf.org/source/project/test-suite/rfc4408-tests.CHANGES?rev=98&view=auto

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkimGeIACgkQwL7PKlBZWjtWiACfd/uDjVrt3DhIgqIxYrErLbHv
u2AAn0c//HMjhknhvnY9wBufVS5uyn0w
=5DFP
-----END PGP SIGNATURE-----



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1007/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1007/
Powered by Listbox: http://www.listbox.com
Re: Last erratum last call [ In reply to ]
Julian Mehnle wrote:


Hi Julian,

> a move and a new job.

Hopefully that went well.

> I think all of us are mostly on the same page now with
> regard to the issue matter.

Yes, as far as possible. Clearly an issue that needs a
better fix than the "last erratum" at some point in time.

> Your proposal puts all the stuff in the "PermError"
> definition in section 2.5.7. I don't think that's
> appropriate.

More like KISS than appropriate. And your concern was
that some implementations don't return a PemError, but
ignore the directive.

> How about the attached diff instead?

I've split the text in "variant 1" (as it was), adding
your text as "variant 2".

"Variant 2" consists of two parts, the forward pointer
to section 8 (macros) is replaced by a forward pointer
to section 4.8 (domain-spec).

The second part of "variant 2" is a new paragraph to be
inserted at the end of section 4.8. One statement in
your proposal IMO needs some wordsmithing before a new
consensus poll:

? Some implementations choose to treat as a no-match
? mechanisms, and ignore modifiers, with such names,
? whereas others throw a "PermError" exception.

| Some implementations treat such situations as "no
| match", i.e. ignore the directive, whereas others
| throw a "PermError" exception.

Is that what you mean ? Simply edit it on the wiki
as it should be. While you are at it, there are two
other points:

+ Note: Historically, this document has made no
+ provisions for how to handle <domain-spec>s, or
+ macro-expansions thereof, that are syntactically
+ invalid per [RFC1035]

"Historically, this document has made" sounds odd in
an erratum supposed to be a part of what the document
really does. IOW, it sounds like text for a 4408bis.

How about "This document does not exactly specify
how to handle" ... ? After all we are going to say
one thing, either "no match" or "PermError", in the
next statement.

> In any case I have adjusted the test suite to
> allow both the "PermError" and no-match behaviors

Great. As we are clear about what we want, only the
precise way how to say it is still open, you could
publish it now. Maybe add my new "macro mania" test
cases fixed by Stuart, see:

<http://article.gmane.org/gmane.mail.spam.spf.devel/1938>

The rationale for the new "macro mania" tests was a
developer trying to use a seriously limited .NET DNS
API.

The "quoted string" + "quoted pair" business will be
a bit more complex, it could go into an update of the
test suite when we have that clear.

Using upper case %{S} in a <domain-spec> can also have
odd effects, especially in conjunction with the "last"
erratum limit 63:

mail from: <123...25@789...50.example.com>

"v=spf1 exists:%{S} ?all"

.example (8) + .com (4) + 25 + @ (1) + 24 => 62. But
if the @ is URL encoded for an upper case S it is 64.

Frank



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1007/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1007/
Powered by Listbox: http://www.listbox.com