About a forwarded message X -> Y -> Z, I wrote:
Y verifies X's signature, writes an A-R line, and signs it. Later on, Z
verifies Y's signature. However, Z's A-R will not repeat all of Y's resinfos:
Although Z has verified that Y's A-R is pristine, it doesn't take the
responsibility of reasserting those claims, even at the cost of significantly
increasing the complexity of consuming Y's A-R downstream.
The complexity increase consists of having to identify and inspect the
relevant DKIM-Signature field, count how many times
"Authentication-Results" appears within its "h=" tag, and count
existing A-Rs to check that Y's one was actually signed and verified.
It may seem that this task would be more easily carried out by a
C-written filter on X during signatures verification than by a client
extension.
Would it make sense for Z to write something like the following?
Authentication-Results: Z.example;
dkim=pass header(_dot_)i=(_at_)Y(_dot_)example;
resent-dkim=pass header(_dot_)i=(_at_)X(_dot_)example authserv-id=Y.example
...
Received: from Y.example by Z.example
Authentication-Results: Y.example;
dkim=pass header(_dot_)i=(_at_)X(_dot_)example
Received: from X.example by Y.example
(Multiple forwarders could be arranged in a comma separated list, e.g.
authserv-id=Y2.example,Y1.example for X -> Y1 -> Y2 -> Z.)
I'd really prefer the simpler case of signatures not getting broken.
However, the syntax above would still be useful for reporting spf and
auth results, that can be verified by a single server only.
Just a thought.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html