[ietf-dkim] Output summary
Murray S. Kucherawy
msk at cloudmark.com
Thu Apr 28 15:48:54 PDT 2011
> -----Original Message-----
> From: Rolf E. Sonneveld [mailto:R.E.Sonneveld at sonnection.nl]
> Sent: Thursday, April 28, 2011 2:12 PM
> To: Murray S. Kucherawy
> Cc: ietf-dkim at mipassoc.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. The reverse, however, is not a constraint; an assessment module that knows it's consuming DKIM output is allowed to know something about what's coming up from below. That's consistent with the idea that such a layer knows DKIM only validates header fields from the bottom up.
If you're adding DKIM to an application, it doesn't seem a layer violation to me to understand and apply what it's telling you, provided it's well-documented.
As another example, your web browser chooses how to render pages by parsing the content it's given by the TCP stack and applying it accordingly. The transport layer doesn't know anything about the data it's handing up the chain, but the layers sitting on top of it do have some idea of how to make proper use of it.
More information about the ietf-dkim