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