[ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSPtounsigned messages

[MH Michael Hammer (5304)]

 Ok, now I'm confused......

Does -1 mean remove the text or does -1 mean oppose the proposal. My
intent is to oppose the proposal to remove text.

Mike

>-----Original Message-----
>From: ietf-dkim-bounces at mipassoc.org 
>[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of MH 
>Michael Hammer (5304)
>Sent: Thursday, January 24, 2008 1:56 PM
>To: dcrocker at bbiw.net; ietf-dkim
>Subject: RE: [ietf-dkim] Re: ISSUE 1521 -- Limit the 
>application of SSPtounsigned messages
>
>
>Apologies for top posting if it offends anyone. 
>
>-1  I OPPOSE this proposal for the following reasons. 
>
>The D in DKIM refers to Domain, not user. If it cannot be used 
>to strongly protect the purported originating domain based on 
>that domains stated assertions and policy, then DKIM-SSP is of 
>limited value. 
>
>Without requiring a check (not saying what action the receiver must
>take) of the From address, what we are saying is that bad guy 
>signature on evil nasty email is just as worthwhile of a 
>signature as that of the owner of the domain in the From address. 
>
>Anyone care to argue that a signature from 
>randomrotating.randomrotating_evil.ru is a sufficient and 
>trustworthy signature for an email purporting to be from this 
>list even though mipassic.org isn't DKIM signing? BTW, isn't 
>ironic that an organization that is pushing DKIM isn't signing 
>even with t=y?
>
>Requiring a check of From does not dictate the decision the 
>receiver (MTA,MUA, person at keyboard, whatever) chooses to do 
>with the results.
>The folks in favor of removing the text are concerned about 
>what receivers will do based on such a check. Shouldn't that 
>choice be left to the individual? 
>
>This is almost like arguing that a sign saying "DANGER, 
>Shallow Water - Do not Dive" should be removed because some 
>people might want to ignore the sign and dive in headfirst anyways. 
>
>Feel free to ignore the from DKIM signature in your personal 
>implementation but please don't weaken the opportunity for the 
>owner of a domain to make an assertion through DKIM-SSP and 
>expect that people following the standard have at least 
>checked their disclaimer. If a domain owner chooses not to 
>make an assertion or chooses to make a weaker assertion, that 
>is their perogative. 
>
>Mike
>
>
>
>
>
>>
>>
>>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.
>
>
>_______________________________________________
>NOTE WELL: This list operates according to 
>http://mipassoc.org/dkim/ietf-list-rules.html
>