On 04/18/2006 14:18, Douglas Otis wrote:
On Apr 18, 2006, at 10:42 AM, Scott Kitterman wrote:
From a protocol design perspective, I think the right answer is to
design for the case where the receiving MTA/MDA will check the
signature and record a result that, if appropriate, an MUA can use.
Depending upon an unsigned "results" header being added to the
message is an unsafe practice.
It is not practical to determine who added the "results" header,
whether the MDA strips/adds all prior results headers, and whether
all possible backup and alternative paths also strip/adds all
"results" headers. Retaining the integrity of the DKIM signature for
a suitable period should permit message verification for transports
that carry messages beyond the MDA. Message protection beyond SMTP
is an important aspect of DKIM. Reliance upon a results header may
produce many years of victims that DKIM intended to protect.
Explain the motivation for not including DKIM protection beyond SMTP?
-Doug
The problem is inherent in your statement, "a suitable period". What's that
and how do we figure it out? If you include the MUA, then the only suitable
period is essentially forever.
If we decide to design for MSA/MTA/MDA, but do nothing that would explicitly
preclude MUA use (which is, as I understand it the approach currently
intended) then MUA based verifiers would likely be able to work reasonably
well, but without forcing us into a corner on what "a suitable period" is for
an MUA.
I would not say that we shouldn't include DKIM protection beyond SMTP, but
that whatever happens after delivery shouldn't distract us from the primary
use case.
Some method that can be relied on to store the verification result for future
use is going to need to be needed in any case so that the verification state
of stored e-mail can be retrieved when needed. Whatever solution that is,
should also work for MDA to MUA delivery of the result.
No reason that I can see that the MDA couldn't add an Auth results header
field, re-sign the message with it's own DKIM signature (including signing
the Auth results) and then deliver it. That would allow the MUA to rely on
the results header field. Since the MDA and the MUA are generally in the
same adminstrative domain, any key rollover issues could be handled
internally. I'm not saying that's the right answer, just one possibility
(and yet another potential reason to solve multiple signatures).
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html