Mailing List Archive

Errata and <quoted-string>s (was: Upcoming new test-suite release)
Julian Mehnle wrote:

> I think 2.5.7/1/3 (the third sentence, which I quoted in
> the message you are referring below) is actually a mistake.

Okay, let's see how far we get with this theory - nobody is
pressing for a completed errata page.. ;-)

There's a note at the top of the 4408 page saying that we'll
send the errata to the IETF, I'm not sure what it means:

I've submitted the URL of our collection to the RFC editor,
and they've added it on their 4408 errata page (plain text,
but who cares) as "reported". At some pont in time we'll
want it listed as "confirmed", with the "new" procedure an
area director has to confirm it. That "new" procedure is
something the IESG might be unwilling to subscribe to:

It means a lot of work to "confirm" errata reported in the
last three years, and I wouldn't like to bother them with
our stuff before they had a chance to get used to the "new"
procedure and clean up more important errata like RFC 1123
before (I'm not talking about 5.3.6(a) ;-)

> the entirety of RFC 4408 doesn't spell out the concept of
> doing any syntax checking _after_ macro expansion, except
> for this one sentence. Even if we think it would have
> been a good idea, it simply isn't in the spec.

Unreliable Permerrors are bad, but if 2.5.7 really meant
an "unusable <target-name> after odd SMTP syntax errors"
it wouldn't be too bad - receivers can reject such crap
without asking SPF, if they don't do this and ask SPF for
a 2nd opinion we only need to make sure that this is no
"try again later" TempError.

OTOH an ideal policy ends with -all or whatever a sender
dares say, and an ideal FAIL would be better than a shaky
PermError only justified by an unclear note in 2.5.7.

Apparently I can live with both solutions, so let's pick
your proposal "no match" :-)

>> That wannabe-erratum doesn't propose a fix, I guess
>> what I meant is "whatever you do, this is no TempError",
>> or "better let's say what it is" (no match or PermError).

> Good. Can you think of a possible wording (and place in
> the RFC to put it)?

Wording similar to a bad exp= <target-name>, adding it to
4.8, noting the two exceptions redirect= <target-name> and
include: <target-name>, where a bad <target-name> really is
a PermError. I think, at least for redirect= that is clear.

Or maybe not noting the two exceptions in 4.8, but in 2.5.7:
Possibly that's what 2.5.7 wanted to say. It's too odd if
2.5.7 tried to talk about a *general* PermError concept not
mentioned anywhere else.

If we have a complete proposal let's try to ask Wayne what
he was up to, it's perfectly possible that the 2.5.7 clause
was my idea related only to redirect= and include: issues,
because I was intrigued by these "PermError, but no syntax
error" exceptions.

>> good..dots.example queries won't work for %{l}.example,
>> while good\.\.dots.example should work.

> I think that's exactly the case that 2.5.7/1/3 is referring
> to (even though SPF doesn't know any concept of \-escaping,
> so your second example would consist of four (4) labels,
> not two).

Yes, this escaping is AFAIK used as notation in an RFC about
DNS. I've no idea what resolver APIs want in queries with
embedded dots. Checking nslookup bad\.\.dots.claranet.de I
get a timeout from my server, with bad..dots.claranet.de I
get an unspecified error: *.claranet.de is a wildcard, the
bad..dots should "exist" like foo.bar or xyzzy.

> We can always revive the idea for SPFv3.

SPFv3 can say whatever it wishes, 4408bis is more limited
to "lessons learned and incorporating errata while at it".

[local part queries derived from a <quoted-string>]
> It might make sense, but the concept would be completely
> novel to RFC 4408, so I don't think we can do that.

2821bis says that users SHOULD NOT use such addresses, on
that base I'm also happy with a "won't work" decree, if
"won't work" results reliably in "no match". Covered by
the test suite, and any "updates 4408" draft discussing
such oddities.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1007/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1007/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311533&id_secret=74037202-664037
Powered by Listbox: http://www.listbox.com