John Levine wrote: >> 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.
John, Please take a step back (into the balcony) to reflect on what you are saying here. I personally appreciated your recent input in the threads hitting the right notes. I think Appendix D touches base with some impractical MUA considerations regarding different bits - its either good or bad. I've written several (long) drafts of a response and concluded with something I believe we already discussed in years past: MUA trust of the Backend Information provided. Its a simplistic statement but hopefully one can see based on the realistic backend/MUA operations. Overall, we have two types of MUAs: - Online MUA with complete backend control of what is rendered based on a suite of backend available information. - Offline MUA where the backend has to pass "information" to the MUA in a common standard data format we call RFC 5322. Lets use gmail or yahoo as an example as you once reference these as quick ways to test verify signature generations. These were online MUA methods and both systems had control on how to convey valid DKIM signatures with their online GUI display. But as you are aware, the user can also setup his account to pick yup mail via POP3 (or IMAP) for users who wish to use an RFC-based offline mail reader (like Outlook, Thunderbird, etc). In this case, we have yet to developed a way to convey the same online experience in a time-shifted offline manner. Gmail can only pass the A-R (Authentication-Results) header. But I believe we concluded long ago the general MUA can not trust headers like A-R. The offline MUA developer is not going adding support for A-R unless he is 100% sure it is a trusted header generated by the back end host. ISP, ESP, etc. If the offline MUA does not get what is needed from an authenticated mail pickup, then it may redundantly repeat the DKIM verification. It might do this anyway to cover the market of non-DKIM supportive mail pickup host. Overall, the point is the backend has complete control of what to display for its online access user interfaces. But for the offline MUA, there wasn't muuc we done to give them trust and avoid repeating the DKIM verification. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html