On Friday, September 10, 2010 06:37:46 pm Steve Atkins wrote: > On Sep 10, 2010, at 2:31 PM, Scott Kitterman wrote: > > On Friday, September 10, 2010 03:17:47 pm Steve Atkins wrote: > >> On Sep 10, 2010, at 11:27 AM, Charles Lindsey wrote: > >>> On Fri, 03 Sep 2010 15:15:37 +0100, Hector Santos <[email protected]> > > > > wrote: > >>>> I think you need to better appreciate and understand how fundamental > >>>> the "Message" From field for any forms of communications and/or mail > >>>> networks is. It would be a radical change to open up this door and > >>>> "Pandora box" to make it the norm and mindset that a From: is > >>>> unreliable. Not saying it is not prone to abusive, but fundamentally, > >>>> when people believe in the message, they also make that natural > >>>> trusted tie to the author of the message. > >>> > >>> Yes, but nobody is trying to change that. We seem to be agreed that > >>> what a mailing list sends is, from some POV, a "new" message, and so > >>> logically a new "From:" is not wholly out of order. > >> > >> What's the benefit to this, though, other than obscuring the original > >> author? > > > > If you agree with John Levine's proposal that mailing list mail is, in > > general, not a problem then there is negative value in mailing lists > > throwing away (discarding) good mail from domains that happen to use > > ADSP Discardable (or any other mechanism for inferring something from > > the lack of a signature - this isn't really ADSP specific, it's just the > > implementation we have at the moment). If this negative event can be > > avoided by the simple mechanism of using a mailing list specific > > "Message" From, then that is a benefit. > > Rather than go into the general reasons why I think this is not > something that ADSP users really want, I'll give a concrete > example. > > Lets say this mailing list rewrites the From: address in some > reasonably mechanical manner, and the From: field of > this message were rewritten as (making up syntax on > the fly)... > > From: steve%blighty.com%[email protected] > > ... such that recipients (or their MUAs) know that this mail > was sent by [email protected] via a mailing list at > dkim.org. > > There's nothing to stop me from sending mail > From: billing%paypal.com%[email protected], as > the mailing list isn't using ADSP. And there's certainly > nothing to prevent me from sending mail from > billing%paypal.com%[email protected] that has > a valid first-person signature. > > That means that, as far as the end user is concerned, > I can send them email that is "from" [email protected], > even though paypal.com is using ADSP to ask receivers > to discard mail that claims to be from paypal.com but > is not validly signed by paypal.com. > > Given the whole point of ADSP is "Discard if you're not > sure", I don't think that's what an ADSP using domain > would want. > > (The effect is softened somewhat if you use random > from addresses with no connection to the real address, > but only somewhat. And that damages the communication > between users quite a bit more. That's what I meant when > I talked about obscuring the author, upthread). > > > This is > > > > not the only potential use of such a feature. I've spoken to one MLM > > developer who told me the feature has been previously requested for > > privacy reasons nothing to do with DKIM or ADSP. > > That would be "for obscuring the original author", and > it's certainly possible for MLMs to do that now, though few > do. > > > I think this is quite reasonable as it would inoculate MLM users from > > ADSP (or similar) problems in a way that does not limit their ability to > > promote communication among their subscribers (which is what mailing > > lists do). > > I don't think it inoculates them against ADSP problems - rather > it opens them up to violations of the security model that ADSP > would like to impose. > This is only true if John is wrong and mailing lists are a vector that we need to worry about. I happen to generally agree with him on this.
Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
