[ietf-dkim] Collection of use cases for SSP requirements
mike at mtcc.com
Fri Nov 10 08:46:04 PST 2006
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_
>> 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
As if there were one and only one. It's an unfair question on its face
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
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
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
one of many reason why the protocol is worthwhile standardizing. We
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
I happen to think that paralysis due to lack of a functioning crystal
balls is really lame.
More information about the ietf-dkim