-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
Sent: Monday, October 18, 2010 10:55 PM
To: ietf-dkim(_at_)mipassoc(_dot_)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