On May 28, 2009, at 5:00 PM, J.D. Falk wrote: > Barry Leiba wrote: >> Just on one portion, here: >> >> On Thu, May 28, 2009 at 3:30 PM, Doug Otis<[email protected]> >> wrote: >>> Some systems handle message attachments separately, and at times >>> may exclude attachments. Eventually, a practice similar to DKIM >>> should be established to separately encapsulate attachments. Once >>> such a convention exists, separating message attachment hashes >>> will better ensure textual portions of a message can be handled >>> independently from that of message attachments. >> >> Hm. >> I should think that the DKIM way to handle the removal of >> attachments would be for the agent that remove the attachments to >> re-sign the message after it does so. > > Agreed. No matter which MIME part was affected, it's still a > modification of the original message and thus invalidates the > assertions inherent in the original signature.
I don't agree. Information can be contained within a message that indicates the existence of the attachments, and even, after extracted from some repository, what their hash results should be. I also agree with John about providers being unlikely to go to any additional effort. It not in their nature, but of course only time will tell. We should take the time to discover how DKIM and A-R will be abused or misused. One thing is fairly certain. The l= parameter might greatly assist MUAs in isolating cruft added by a provider. Unfortunately, when the debate is about security, or what a provider can get away with, security always is at the short end of the stick. When a reputation service bases a recommendation upon the DKIM signer, an MUA finding the original signature and a broken hash due to some notice or ad, could still utilize the l= parameter to differentiate what had been appended or prefixed by some third-party. It will be exceedingly difficult to establish fully independent two-way reputations. The reputation of the signer, and that of the provider which might include some unknown fly-by-night ad links. The recipient is likely to think they are trusting big-bank endorsed by the reputation check, only to find the link contains an iFRAME that installs malware because the ad server was improperly secured. Only when an MUA carefully annotates what is the signed content, can the reputation be based upon the source of the message, independent of notices that may have been included. Needing a single reputation result rather than two makes resolving the l= issue well worth the effort. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
