As a prelude to the following 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;)
I have a variety of problems with the "headerspec" value.
It's unclear how multiple methods are to be combined together into a
single header; what happens with the "headerspec" value? If you wanted
to put in an A-R header saying that the message passed CSV, SIDF, SPF
and DKIM, how would those be combined? Each of those could and possibly
should have totally different values for headerspec. Messages often have
multiple identities that are confirmed differently by the various
authentication methods. CSV can identify the relay hostname. SIDF can
identify the rfc822.sender/from/etc. SPF can identify the smtp.from
hostname. DKIM can identify the sender's hostname. Which one goes into
the headerspec?
In the samples, some authors have punted and just put in a "header.from"
value, a choice totally divorced from the mechanism. One author
improperly put in multiple headerspecs. One author eliminated the
headerspec entirely. One author chose a headerspec based on the method.
My proposal is to either eliminate the headerspec from A-R, or to make
it subordinate to the method=result. In other words, the headerspec
should be supporting information to what was validated, not the other
way around.
If headerspec is kept, note the varying use of what's put there. Let's
think about what the values for ptype first. The spec says either "smtp"
or "header". Note that DKIM doesn't match either of these, because it
uses both the header and the body to do verification (and a DNS entry
too). Hmmm; should token be listed? No, I wouldn't want that. But I'm
not sure what to replace it with. Note that in the samples, some people
ignored the "ptype" entirely; perhaps it should be eliminated after all.
Also lots of people got this wrong: for example, DKIM does not usually
provide a username as the identity, so should not be listed with a
headerspec of header(_dot_)from=tony(_at_)att(_dot_)com(_dot_) The closest I
saw to what I'd
consider proper usage of a headerspec for DKIM was
header(_dot_)DKIM-Signature=(_at_)example(_dot_)net(_dot_)
Argh.
Back to first principles: what's the headerspec supposed to provide?
From the comments in the ABNF, I see three things: 1) which part(s) of
the message transmission was being evaluated (smtp, header or body); 2)
what identity was extracted from those parts; and 3) what in particular
within those parts was used to determine the identity. (Ok, body isn't
listed in #1, but should have been.)
From this, we can see that a headerspec should be totally dependent on
the type of authentication that's being performed, and the types of
values that should go into it are also totally dependent on the type of
authentication.
This implies to me that the headerspec should be: 1) subordinate to the
authentication results; and the choice of what should be used for ptype
and property should be specified by protocols that use this specification.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html