ietf-dkim
[Top] [All Lists]

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

2008-01-24 10:39:23
On Thursday 24 January 2008 12:12, Michael Thomas wrote:
Damon wrote:
On Jan 24, 2008 11:18 AM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
Stephen Farrell wrote:
1521    Limit the application of SSP to unsigned messages    new dkim
Nobody    0 dhc(_at_)dcrocker(_dot_)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.

Isn't that what we are doing?

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>