mail-vet-discuss
[Top] [All Lists]

[mail-vet-discuss] Auth-Results ABNF bugs

2009-03-04 15:26:34
Two ABNF issues have been brought to my attention regarding 
Authentication-Results:

1) The current definition of the "ptype.property=pvalue" construction is 
in conflict with the examples.  In particular, "pvalue" is defined as:

        pvalue = [CFWS] ( token / addr-spec ) [CFWS]

...with "addr-spec" imported from RFC5322.  However, "addr-spec" can't 
have an empty local-part, so DKIM's "i=" example of "@example.com" as a 
"pvalue" isn't permitted by the current ABNF.  My proposed solution is to 
tweak the ABNF to become:

        pvalue = [CFWS] ( token / [ [ local-part ] "@" ] domain-name ) [CFWS]

...with "domain-name" imported from RFC4871 (DKIM).  I believe I can do 
this during AUTH48.

2) Since "property" is a "token" (from MIME), it can start with a ".". 
This allows "header..foo=bar", which at least aesthetically looks like a 
bug in the ABNF.  The person who brought this to my attention suggests 
redefining "propspec" as:

        propspec = ptype [CFWS] "/" [CFWS] property [CFWS] "=" pvalue

This seems reasonable to me, but my concern is the number of deployed 
implementations out there (mine included) which already implement the 
current ABNF and separate "ptype" and "property" on the first "." found. 
Such parsers seeing "header..foo=bar" would get the "ptype" as "header" 
and the "property" as ".foo" which I contend is correct, so there's 
actually no ambiguity.  However, I also understand the concern.

Thus, being sensitive to the deployed base out there, my suggestion would 
be to leave this as-is and note it in an erratum once the draft publishes 
as an RFC for later use in a revision draft.

Opinions on both points are welcome.

-MSK
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html 

<Prev in Thread] Current Thread [Next in Thread>
  • [mail-vet-discuss] Auth-Results ABNF bugs, Murray S. Kucherawy <=