> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of John Levine > Sent: Monday, October 18, 2010 10:55 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] detecting header mutations after signing > > >There's a strong correlation between badly structured emails (SMTP, > >MIME, HTML) and email that the recipient doesn't want to see. > > You're right, but I think that's largely orthogonal to DKIM. If a > message has a good signature from a credible signer, I expect I'd want > to show it to the user even if it had structure problems. I'd like to > make the trust model as simple as possible, preferably > > good signature -> good messsage >
Look further down the email at your comment "Personally, I have no idea which signing domains are credible and which aren't..." and then explain the leap to good signature -> good message. Don't you mean Good signature -> authenticated message (that is, someone accepts responsibility) > rather than > > good signature + tidy SMTP + correct headers + unobjectionable HTML > + favorable phase of moon -> good message > > If a message doesn't have a credible signature, then you still use the > structure heuristics. > > >OTOH, we already have a SHOULD that tells MUA writers > >to splatter the d= field somewhere in the GUI where the user > >can't ignore it > > Ugh, you're right. Now that I look at it, I'd like to completely > delete Appendix D, since it says some things that are just wrong, > i.e. language that implies that the signature contains someone's email > address, and some stuff that hasn't been implemented and quite > possibly never will be, e.g., highlighting the signed parts of the > message. > > Personally, I have no idea which signing domains are credible and > which aren't, and I have no interest in my MUA showing them to me so I > can try and guess. That's much better handled in the MTA or MDA, > using something like VBR to check the signer's credibility. > > R's, > John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html