[ietf-dkim] Collection of use cases for SSP requirements

Michael Thomas mike at mtcc.com
Thu Nov 9 11:50:48 PST 2006


Dave Crocker wrote:

>
>
> Michael Thomas wrote:
>
>>> Phishing doesn't have to use the real domain. There are *countless* 
>>> ways of
>>> phishing that don't require it. ...
>>
>>
>> This assumes that social problems have to be solved only in the 
>> technical
>> realm in order to be useful. I'm sure that John will snort his coffee 
>> through
>> his nose, but training users to only expect to hear from paypal from
>> paypal.com is most likely part of the solution. 
>
> However my own view is that it is entirely reasonable to include the 
> possibility of user training in discussions about problems and 
> solutions that directly involve users.
>
> On the other hand, training users is known to be particularly 
> difficult and to be plausible only when satisfying some rather severe 
> constraints that ensure very high motivation, very simple mechanisms, 
> very clear information, and a slew of additional "very"s.
>
> Best of all is that the realm of human factors usability and training 
> is entirely outside the skillset of an IETF working group, no matter 
> the skills of any particular participant.


Good thing that none of this is predicated on that being the _only_ reason.
Or that there need be an _only_ reason.

>
> At a minimum, any proposal in the working group that entails multiple 
> changes throughout the system -- such as including user training -- 
> needs to specifify all of the components that need changing, what the 
> changes need to be, and what the basis is for believing that the 
> aggregate set of changes will have efficacy.


Good thing that nobody's proposing that then because it sounds hard. 
Something
that might as a side benefit help that along seems worth considering as 
a plus. Just like
we hope that a side benefit of DKIM will be to enable better reputation, 
etc.

> Oh, and it also needs to include a cost/benefit discussion, since 
> anything entailing changing multiple components is certain to be 
> expensive and likely to be risky.


I don't know what "it" is here because it doesn't seem to have anything 
to do
with what I was talking about.

       Mike



More information about the ietf-dkim mailing list