On Monday 16 August 2010 09:25:06 Dave CROCKER wrote: > On 8/14/2010 8:50 PM, Daniel Black wrote: > > I intially saw a need for a MUA considerations because: > > * I still hope DKIM will help protect email identity > > "email identity" is an ambiguous term. > > All sorts of value-added enhancements might be possible, on top of DKIM, > but "protecting email identity" isn't really what DKIM is defined to do.
rfc4781 Abstract - last sentence. Still abstract however this was a general lead-in discussion. > > * end users rely, or should rely, on their MUA to present verified > > identity information in an easily digestable way. > > Human usability issues with respect to security is, at best, extremely > poorly understood. The state of the design art appears to have no idea > what is effective. There are a number of significant papers on the topic available. Either way DKIM provides a domain responsibility signature and providing some information to the end user is useful. I agree that informational rfcs should stay away from design art however I do see a description of useful information as constructive to MUA implementors. > > * MLMs break signatures and MUA will still need to present verified > > identity > > As noted, you are seeking to have DKIM perform functions it was not > designed to perform. There should be no surprise that it falls shy of > your desired mark. While it seems to be the intent of many within this working group to define dkim in such a way that its only plausable use is dkim reputation, a little constructive thought to other benefits for verifiers, filters and recipients would be appreciated. If it could be done without snarky comments that would be even better. Recipients are an important aspect of the message flow and an attempting to define a benefit to them from DKIM is an element of what I'm attempting to define. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
