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

[Damon]

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.
 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