On 4/29/11 12:48 AM, Murray S. Kucherawy wrote:
-----Original Message-----
From: Rolf E. Sonneveld
[mailto:R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl]
Sent: Thursday, April 28, 2011 2:12 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary
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.
Layering design stipulates that the lower layers don't depend on the upper ones.
Don't get me wrong, I just wanted to demonstrate that, IF we follow the
logic of not crossing protocol boundaries strictly, THEN communicating
the d= payload /without additional information/, we
* either enforce upper layers to violate layers or
* in advance we discourage in advance the design and development of
a number of useful applications that otherwise could have been
built on top of DKIM.
In the archives I found exactly this same concern and discussion, see
for example the contribution of Jim:
http://www.mail-archive.com/ietf-dkim(_at_)mipassoc(_dot_)org/msg11105.html
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html