On Jan 24, 2008 11:18 AM, Dave Crocker <[EMAIL PROTECTED]> wrote: > > > Stephen Farrell wrote: > >>> 1521 Limit the application of SSP to unsigned messages new dkim > >>> Nobody 0 [EMAIL PROTECTED] 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
