Rolf E. Sonneveld wrote:
b) If an application is presented two different From: fields and handed them
to DKIM, and the signature passes, the bottom one is the one that was
signed. We verify from the bottom up specifically to deal with the case
where a message has "m" signed instances but "n" total instances, where "m"
is less than "n".
Right. But this is DKIM logic, 4871bis. By not specifying the address in
the output, it means that the upper layer application needs to follow
the DKIM spec (4871bis) in order to be able to determine which From
address it should use for whatever function it provides (e.g. determine
1st vs 3rd party signature or determine whether something is an author
domain signature). In other words: by not specifying this type of
information in the output of DKIM we create a layering violation, as the
upper layer needs to be aware of the way DKIM deals with this kind of
situation. Or we rest with a situation where all sorts of functionality
in layered applications will never be developed, as the required
information is missing.
+1.
The issue as I see is that is that DKIM (RFC4871bis) audience can be
easily confused by reading RFC5585 Figure 1.
Figure 1 is a very good software engineer process flow diagram called
DKIM Service Architecture. It properly depicts the optional module
(trapezoid) for Checking Signing Practices.
So the question is should that be part of RFC4871bis to help avoid
implementor confusion. After all, that is the goal in protocol designs.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html