ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

2010-09-10 17:48:39
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 
<hsantos(_at_)isdg(_dot_)net>

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(_dot_)com%ietf-dkim(_at_)mipassoc(_dot_)org

... such that recipients (or their MUAs) know that this mail
was sent by steve(_at_)blighty(_dot_)com via a mailing list at
dkim.org.

There's nothing to stop me from sending mail
From: billing%paypal(_dot_)com%ietf-dkim(_at_)mipassoc(_dot_)org, as
the mailing list isn't using ADSP. And there's certainly
nothing to prevent me from sending mail from
billing%paypal(_dot_)com%ietf-dkim(_at_)blighty(_dot_)com 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" billing(_at_)paypal(_dot_)com,
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

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