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

Murray S. Kucherawy msk at sendmail.com
Wed Mar 4 11:51:29 PST 2009

Two ABNF issues have been brought to my attention regarding 

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.


More information about the mail-vet-discuss mailing list