[ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages

Steve Atkins steve at blighty.com
Thu Jan 24 19:17:21 PST 2008


On Jan 24, 2008, at 6:14 PM, Hector Santos wrote:

> Mark Delany wrote:
>> On Jan 24, 2008, at 8:37 AM, Wietse Venema wrote:
>>>> Summary of proposal:
>>>>
>>>>> All text that causes SSP to be applied to an already-signed  
>>>>> message
>>>>> needs to be removed.
>>>
>>> I would take this further: remove all text that says when to apply
>>> SSP.  Instead, provide text that states the contribution that SSP
>>> can make under different conditions:  mail with valid first-party
>>> signature, mail with valid third-party signature, and mail without
>>> valid signature.
>> +1
>> If for no other reason than the obvious fact that SSP is not making  
>> progress as it stands. We need some sort of reset if we hope to  
>> proceed.
>
> Its unfortunate that it has nothing to do with technical reasons but  
> the  powers that are pushing reputations instead. The fact is,  
> Dave's never cared for SSP and its spelled out in his deployment  
> guide, and the other guy pushing his reputation service has no room  
> for SSP because SSP threatens that service business.
>
> It is would be one thing to kill SSP for its technical merits, but  
> no one has SHOWN it is flawed system. NO one.

Sure they have. Numerous times. Anyone who doesn't recognize that it
has flaws is, honestly, not technically knowledgeable enough to be able
to offer anything useful to the spec development.

That SSP has some serious flaws isn't, in itself, a reason not to  
develop
it and deploy it. But if the people who are developing the specification
are not capable of recognizing that there are flaws, we have a problem.

>
>
> Purely based on self interest, and unfortunately we have a few cogs  
> who are masters of getting things KILLED if they want it to DIE.
>
> It is a very SAD that not enough the technical developers are here  
> to mandate the direction.

On the contrary. It's those with most technical experience who see the
flaws in it, generally.

Cheers,
   Steve



More information about the ietf-dkim mailing list