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

[Michael Thomas]

Damon wrote:
> On Jan 24, 2008 11:18 AM, Dave Crocker <dhc at dcrocker.net> wrote:
>>
>> Stephen Farrell wrote:
>>>>> 1521    Limit the application of SSP to unsigned messages    new dkim
>>>>> Nobody    0 dhc at dcrocker.net    9 days ago        9 days ago    0
>>>>> Proposal: REJECT, but some wording changes may be needed for the next
>>>>> rev, thread is [4] I mainly saw opposition to the change suggested in
>>>>> the issue, and little support, but some text clarifying changes were
>>>>> suggested (e.g. [5]). [4]
>>>>> http://mipassoc.org/pipermail/ietf-dkim/2007q4/008424.html [5]
>>>>> http://mipassoc.org/pipermail/ietf-dkim/2007q4/008467.html
>>>> Would you please explain the basis for assessing that this topic got
>>>> sufficient discussion and that there was rough consensus on it?
>>> See above "I mainly saw..."
>>
>> Summary of proposal:
>>
>>> All text that causes SSP to be applied to an already-signed message
>>> needs to be removed.
>>
>> Folks,
>>
>> I've reviewed the thread that took place on this topic.  Here are summary
>> statistics:
>>
>>    Total postings in thread:  46
>>
>>    Number of different people posting:  14
>>
>>    Apparent REJECT of proposal: 4
>>
>>    Apparent ACCEPT of proposal: 5
>>
>>
>> I would like to ask folks with an opinion about this proposal to post an
>> explicit note stating support or opposition.  Some of the existing posts were
>> about substantive issues in the proposal, but did not clearly indicate support
>> or opposition.
>>
>> Given that this issue goes to the core of a significant fraction of the
>> current specification's functionality and given that there is at least an
>> implied requirement for the functionality in the SSP requirements RFC, I'll
>> ask folks to do both a +1/-1 *and* to explain their reasons.
>>
>> I also do not find a record in the archive of working group agreement to add
>> the features in question.  So an assumption that the features should be
>> retained unless there is a rough consensus *against* is problematic.  Citing
>> the SSP requirements RFC is comforting, but questionable, absent any history
>> of group discussion and clear rough consensus about the matter.
>>
>> d/
>>
>> --
> -1
> 
> Creating the ability for any bad domain to bypass policy of other
> domains or worse, non-participating domains, IMO pokes a hole big
> enough to drive a truck through.

-1 also. I'd go farther and say that it would make the entire protocol
completely useless.

		Mike