ietf-dkim
[Top] [All Lists]

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

2008-01-24 09:58:35
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.
 I have always frowned upon senders using MY email address as a From:
when the content was generated and delivered by THEM. Use my address
as a nice name or Sender: but not as the From:. I have worked hard to
remove this practice from the applications within the companies I have
worked for.

Regards,
Damon Sauer
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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