> Is this built on top of RFC 822 or 2822? If 2822, then CWFS should not
> be specified before the :.
Good catch. It should be 2822 so the CFWS before the colon should be
removed.
The rest of your message below is what I was asking for in my previous
email. +1 for change along these lines from me.
--
Arvel
Tony Hansen wrote:
I have a couple of comments about the ABNF.
header = "Authentication-Results" CFWS ":" CFWS hostname CFWS
headerspec *(CFWS ";" CFWS method CFWS "=" CFWS result)
CFWS
Is this built on top of RFC 822 or 2822? If 2822, then CWFS should not
be specified before the :.
header = "Authentication-Results:" CFWS hostname CFWS
headerspec *(CFWS ";" CFWS method CFWS "=" CFWS result)
CFWS
For the remaining discussion, here is a sample of A-R headers I've
collected from various DKIM/DK/SPF test auto-responders. (I've changed
"hostname" in all cases to example.com. I've changed the sending
system's name to example.net. The references to tony(_at_)att(_dot_)com are
what is
in the rfc822.from header.)
Authentication-Results: example.com from=tony(_at_)att(_dot_)com;
sender-id=fail (DomainDoesNotExist);
spf=fail (DomainDoesNotExist)
Authentication-Results: example.com smtp(_dot_)mail=tony(_at_)att(_dot_)com;
spf=neutral
Authentication-Results: example.com header(_dot_)from=tony(_at_)att(_dot_)com;
domainkeys=neutral (not signed);
dkim=neutral (not signed)
Authentication-Results: example.com from=tony(_at_)att(_dot_)com;
sender-id=fail (DomainDoesNotExist);
spf=fail (DomainDoesNotExist)
Authentication-Results: example.com
header(_dot_)From=tony(_at_)example(_dot_)net;
dkim=pass (768-bit key)
Authentication-Results: example.com from=tony(_at_)att(_dot_)com;
sender-id=neutral;
spf=neutral
Authentication-Results: example.com; header(_dot_)From=tony(_at_)att(_dot_)com;
dkim=neutral
Authentication-Results: example.com;
header(_dot_)DKIM-Signature=(_at_)example(_dot_)net;
dkim=fail (DKIM RR problem for example.net/shan.
missing/bad public key; example.net/shan fail; );
header(_dot_)From=tony(_at_)att(_dot_)com; dkim=neutral
Authentication-Results: example.com header(_dot_)from=tony(_at_)att(_dot_)com;
domainkeys=neutral (not signed);
dkim=pass (1:0:good;)
The most common mistake I see in here that's related to the ABNF is the
introduction of a ";" after the hostname.
Part of this issue will be taken care of if we move the headerspec as
suggested in a previous note.
I'm going to propose the following to move headerspec:
header = "Authentication-Results:" CFWS hostname CFWS
*(CFWS ";" CFWS method CFWS "=" CFWS result
CFWS headerspec ) CFWS
Secondly, there is a reduction error in the use of "hostname" from
[MAIL]. "hostname" already contains optional CFWS, so you essentially
have CFWS twice. Similarly another error occurs with "value" because
mailbox also contains optional CFWS.
[MAIL] solves some of these problems by keeping the the CFWS pieces of
the ABNF associated with the leaves, and not with the higher-level
productions.
Thirdly, saying CFWS means that you MUST put in whitespace or a comment.
[MAIL] uses [CFWS] to make it optional.
Fourth, this can be made clearer if method=result were split out
separately into a combined production. Making these changes gives the
following:
header = "Authentication-Results:" hostname
*([CFWS] ";" methodspec headerspec )
; hostname allows CFWS
methodspec = [CFWS] method [CFWS] "=" [CFWS] result [CFWS]
headerspec = ptype [CFWS] "." [CFWS] "=" value
value = [CFWS] token [CFWS] / mailbox
; mailbox allows CFWS
I think this is easier to follow, and convert to a real parser.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html