J.D. Falk wrote:
Siegel, Ellen wrote:
I agree with Doug's point here. The problem is that the more I think
about it, the more I think it's a mistake for us to put MUA advice
into the standards-track documents, and I'm inclined, rather, to want
to remove what's there rather than to change it.
+1
+1
+1
I don't completely agree with John, though -- I think this group /could/
come up with a fairly sane set of recommendations for MUA developers who
want to display information based on DKIM results, so long as we're careful
to confine it to what the results mean to end recipients and not get into
whether the buttons should be painted periwinkle or mauve -- but if we do,
it has to be a separate informational document.
We have 4-5 MUAs under our belt from console, native gui, web gui,
pop, imap, etc. All in all, you generally have three types:
- Online MUAs
- Offline MUAs
- Hybrid MUAs
If the backend does not support DKIM, you can have two considerations:
- Passthru of RFC formats
- Gateways, transformations.
If the backend does support DKIM, for us, this can/will change or add
new considerations.
- Passthru of RFC formats + status DKIM header
- Gateways with DKIM status headers NO DKIM SIGNATURES
What the MUA will need #1 is to determine if DKIM was or was not
evaluated.
If its hasn't been evaluated, then the MUA is open do to whatever it
wants, the HOST is ignorant about DKIM.
If its been evaluated by the HOST, it depends on the type of MUA.
With online and possibly hybrids, the server can control the display
presentation.
For Offline, like the RFC based mail readers, need a header that is
associated with the mail pickup host only - the DKIM status header.
Can the Authorization-Result header make due?
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html