Re: Authentication-Results: header draft

Murray S. Kucherawy wrote:

  [skipping the cleared nits, thanks] About 'iprev':
>> I like it, but better copy some "security considerations"
>> from RFC 4408 and the reverse mapping I-D.

> OK, I'll look into this stuff.

Okay, buy some asbestos.  Wayne added the PTR processing
limit of ten names to SPF because there can be lots of
names, e.g. an IP of a Web hoster.

>> IMO <version> for a header field is hopeless, besides
>> you can't have two different unrelated <version>
>> definitions in the ABNF.  Just kill the first (used in
>> <header>).

> I don't follow.  There can't be later versions of the
> Authentication-Results: header specification that might
> require some means of disambiguation?

Version numbers as in MIME-Version: 1.0 or in v=spf1 make
me nervous, nobody's going to upgrade their software just
because a future RFC hopes they'll do.  Assuming that A-R
gets traction it will be what you specify now.

Header field names (or FWIW "tags" introducing text in a
TXT or SPF record) are no limited resource, if somebody
really wants an Authentication-Results-Episode-2 header
field in a future RFC let them do it.

I'd be also worried if the <version> offers "them" to
http://en.wikipedia.org/wiki/Embrace%2C_extend_and_extinguish
Authentication-Results "version 1" by a bogus "version 2".

If you keep it anyway one of the two <version> needs a new
name.

>> The idea to allow [CFWS] before and after "." in the
>> <propspec> is outright horrible, please get rid of it.

> Why is it horrible?  Spaces and wrapping have no semantic
> importance

CFWS can be also a comment, it will confuse naive parsers
implementing what 99.99% of all <procspec> will do, simply
smtp.from or senderid.resent-sender without embedded CFWS.

You use <dot-atom-text> elsewhere, that has no CFWS before
or after its dots.  CFWS can contain stuff like NO-WS-CTL,
obs-FWS, quoted-pair, nested comments over several lines.

RFC 2822 says that folding SHOULD be limited to placing
the CRLF at higher-level syntactic breaks.  Explicitly
allowing it within <procspec> calls for unnecessary trouble.

Maybe it's only a matter of taste, I'd stay away from it.

>> value = [CFWS] ( token / addr-spec ) [CFWS]
[...]
> <addr-spec> is what I'm looking for there.  I can switch
> to that one.  I don't see any productions that I don't
> want in that case.

One potential problem, do you need an "empty value" for an
"empty reverse path" or similiar situations ?  You don't
have angle brackets for <> if you use <addr-spec> or the
equivalent 2821 <Mailbox>.

>> Example 3:  Should spf=pass [email protected]
>> actually be spf=pass [email protected] ?
>> Ditto in example 4+5.

Not sure if you have that.

>> I think you'd better add an example for auth=pass where
>> that's added by the MSA.

> Why would the MSA add that for outbound mail?


MSAs typically do SMTP AUTH, see RFC 4409 and RFC 5068,
they could wish to note their authentication efforts in
a header field.  But I now guess that's not the scenario
you have in mind, you want the border MTA to strip any
old Authentication-Results in section 5 of the draft.

I'm not sure if that's a good idea, "trace header fields"
are meant to stay, aren't they ?

 Frank
-- 
Repost, Cc: to list didn't work for new address