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

[Scott Kitterman]

On Thursday 24 January 2008 12:12, Michael Thomas wrote:
> 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.

Isn't that what we are doing?

Scott K