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
