[ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations
dhc at dcrocker.net
Mon Aug 16 10:09:27 PDT 2010
On 8/15/2010 6:25 PM, Daniel Black wrote:
>> "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.
That's why the bis draft uses different language. It's also why wg docs written
aftr 4871 have been searching for better language.
>>> * 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.
I've no idea what you mean by this. If you mean that there's been research on
security and usability, yeah that's true. So what?
My point is that the track record for developing mass-market user interfaces
that produce good security-related interactions with end-uses is essentially non
existent. My other point is that the level of the research on this topic, to
date, is extremely limited and poor.
> Either way
> DKIM provides a domain responsibility signature and providing some information
> to the end user is useful.
The assertion that it is useful is different from saying that the information is
objectively meaningful. To say it is useful, there must be some basis for
knowing that users will actually be able to employ the information to a
The reality is that the minimal research that has been done so far suggests that
such information more often confuses uses. Their cognitive model of the system
and especially of security issues is far, far more limited that folks tend to
realize. In addition, the presentation of the information is usually problematic.
>> 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.
There is a difference between defining new semantics, versus applying existing
semantics in new ways. You appear to be doing the former. That, therefore,
goes beyond the DKIM Signing specification.
> 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
That's clear. It's also beyond the skillset of this group. It's also not
required for DKIM to be useful.
More information about the ietf-dkim