> -----Original Message-----
> From: [email protected] [mailto:ietf-dkim-
> [email protected]] On Behalf Of John Levine
> Sent: Monday, October 18, 2010 10:55 PM
> To: [email protected]
> 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
