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

[Michael Thomas]

Dave Crocker wrote:

> Michael Thomas wrote:
>
>>>> ... but training users to only expect to hear from paypal from
>>>> paypal.com is most likely part of the solution. 
>>>
>>>
> ...
>
>>> 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.
>
>
> Michael, please review your original text, noted above.
>
> 1) No one said anything about "only", so I'm not clear why you 
> introduced it.

Steve Atkins -- who I was replying to -- asked what "the" reason for SSP 
was.
As if there were one and only one. It's an unfair question on its face 
because it
limits you to choose exactly one reason which can then be shot down because
it in and of itself is inadequate justification. There are a range of 
possible reasons
for SSP, both tangible and intangible. I offered one in each category: the
spamassassin rule and the possibility that SSP's constraints may lead to 
better
outcomes given user and phished company training.

> 2. )You cite a specific training goal.

I suggested no such goal for this working group.  Just like there's a 
lot of people
who think that DKIM-base could be a useful tool with reputation -- it 
just becomes
one of many reason why the protocol is worthwhile standardizing. We 
don't have
to go down any of those paths to do our work, nor was I suggesting that.

Frankly, if justifying any IETF work requires the degree of prescience some
people seem to be demanding, we might as well pick up our marbles and go 
home.
I happen to think that paralysis due to lack of a functioning crystal 
balls is really lame.

       Mike