Specific suggestions:
1) Move the headerspec to after the method=result.
2) Make the headerspec ptype a list of "smtp", "header" and "body".
3) Make the headerspec property an optional value to be specified by the
registration specifics for a given authentication method. So whatever
document is used to define how A-R is used by dkim would also specify
what value should go here. Not all authentication methods will need a
property.
4) Make the headerspec value a mailbox, domain or token. Which it is
would also to be specified in the authentication method specific
registration for a given method.
Here is an example of an A-R header with multiple results combined together:
Authentication-Results: example.com;
dkim=pass header+body=foo.example.org (comments);
spf=fail (comments);
csv=pass smtp.ehlo=foo.example.org (comments);
sidf=pass body(_dot_)sender=user(_at_)foo(_dot_)example(_dot_)org
(comments)
Note how the headerspec varies with the method and its results reflect
both: 1) what was used to do the tests, and 2) the identity that was
verified.
Thoughts?
Tony Hansen
tony(_at_)att(_dot_)com
Arvel Hathcock wrote:
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.
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?
Yes, this is an issue that's been brought up several times. Currently,
if the headerspec needs to change you have to create multiple AR headers
IIRC. I'd prefer an approach where the headerspec and the methods that
were used with it were grouped together somehow and we could do this in
a single header.
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.
Could you provide a sample of how one of those headers might look? I
think I'm on the same page with you but want to see one to make sure.
In the samples, some authors have punted and just put in a
"header.from" value,
That's because some things don't have a corrolation to anything in the
envelope or headers as you've said. For example, how to you
'headerspec' the DKIM identity that was verified?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html