Subject: [ietf-dkim] Discussion lists and broadcast lists are not the same thing

From: Wietse Venema <[email-masked]>
Date: Fri, 24 Sep 2010 08:40:22 -0400 (EDT)

Alessandro Vesely:
> On 23/Sep/10 21:16, John R. Levine wrote:
> > All of this emphasis on complex designs for MLMs strikes me as a waste
> > of time, since it's a tiny corner of the mail space that has not
> > historically been a vector for abuse, and shows no sign of becoming one.
> >
> > That's why my advice is that lists should sign their mail, which is
> > easy and at worst harmless, and we're done.
> 
> According to Murray's definition, MLMs include ESPs and email 
> marketers, which originate a volume of traffic and have historically 
> been a vector for abuse.  Indeed, except for subscription mechanisms 
> and deployed software, most of the problems are similar.

It may be productive if we distinguish between two-way discussion
lists where participants send mail to the list, and one-way broadcast
lists where only the owner (or their agent) sends mail to the list.

The difference between these is to be large enough that the concepts
do not generalize that well.

	Wietse
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 24 Sep 2010 10:52:51 -0400

> do not generalize that well.

Since I work for an ESP, I agree with this statement.

-- 
Jeff Macdonald
Ayer, MA

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 24 Sep 2010 08:06:48 -0700

On 9/24/2010 7:52 AM, Jeff Macdonald wrote:
>> It may be productive if we distinguish between two-way discussion lists
>> where participants send mail to the list, and one-way broadcast lists where
>> only the owner (or their agent) sends mail to the list.
>>
>> The difference between these is to be large enough that the concepts do not
>> generalize that well.
>

In terms of the vocabulary used in the Email Architecture document[1], these two
services are completely different.

An MLM really is a mailing list [2].

A bulk, one-way sending service is an entirely different kind of entity and 
service.[3]

d/

[1]  <http://bbiw.net/specifications/rfc5598-email-arch.html#Mediator>

[2]  <http://bbiw.net/specifications/rfc5598-email-arch.html#rfc.section.5.3>

[3]  <http://bbiw.net/specifications/rfc5598-email-arch.html#service-mua>:

> One example is a bulk sending service...
> These services are not to be confused with a Mailing List Mediator, since
> there is no incoming message triggering the activity of the automated
> service.

(This mode probably should get its own name and should be documented up in the 
Mediator text, rather than be buried in the MUA text.  /d)

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Sep 2010 11:14:21 -0400

> do not generalize that well.

+1.

This has been highlighted many times. Thanks for reminding the WG.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 24 Sep 2010 18:46:33 +0200

>>  Since I work for an ESP, I agree with this statement.

Do concepts generalize enough to allow issuing 
draft-ietf-dkim-mailinglists also for these "authoring" MLMs?  I agree 
that some solutions, e.g. publishing a key on behalf of an MLM, suit 
ESPs better than regular mailing lists; but why is it important to 
differentiate them, given that, in principle, the solution could work 
for both?

> A bulk, one-way sending service is an entirely different kind of entity and

Yes, and there are behaviors in between...

> [1]<http://bbiw.net/specifications/rfc5598-email-arch.html#Mediator>
>
> [2]<http://bbiw.net/specifications/rfc5598-email-arch.html#rfc.section.5.3>
>
> [3]<http://bbiw.net/specifications/rfc5598-email-arch.html#service-mua>:
>

An ESP may let clients compose their text on a web form or else accept 
it via SMTP --in this respect it resembles a MUA.  However, MUAs 
require that recipients be typed, or selected from personal address 
books.  The process of substituting email addresses --PII-- from a 
corporate data base on the server makes a relevant difference; 
privacy-based legal arguments hinge on it.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 24 Sep 2010 13:13:05 -0400

> differentiate them, given that, in principle, the solution could work

I don't think ESPs fit into this draft at all. I believe the draft
should just target MLMs that re-author the original message.

-- 
Jeff Macdonald
Ayer, MA

---

From: John Levine <[email-masked]>
Date: 24 Sep 2010 18:05:32 -0000

> draft-ietf-dkim-mailinglists also for these "authoring" MLMs?

No.  All of the complications in mailing lists arise from the fact
that the author of the message is not related to the operator of the
list.

Even though ESPs are generally sending mail on behalf of customers,
their relationship to the customers allows them to be the customer, as
far as mail authentication is concerned.  There are some issues about
how a customer delegates part of its identity to its ESP, but they are
completely, totally, unrelated to the MLM issues we've been arguing
about.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 28 Sep 2010 11:34:03 -0700

> completely, totally, unrelated to the MLM issues we've been arguing

A document on those delegation issues might be helpful also.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 28 Sep 2010 12:26:11 -0700

> A document on those delegation issues might be helpful also.

I cover the main approaches I'm aware of, briefly, at http://dkimcore.org/deployment/esp.html

I'm planning on fleshing that out a bit this weekend[1] to turn it into more of a design manual. If anyone has any docs or thoughts about ESP-style DKIM delegation I'd love to share.

Cheers,
  Steve

[1] Yay for long, boring plane flights!
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 28 Sep 2010 22:40:56 -0400

> A document on those delegation issues might be helpful also.

I'd be happy to work on one if anyone thinks that ESPs who don't already 
everything it says will read it.

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 29 Sep 2010 14:40:52 -0400

> everything it says will read it.

I'm coming up blank on what those issues would be. If we are talking
about how ESPs could go about it, last time I read Steve Atkins' web
page, it seemed like a good start. Is there something more?

-- 
Jeff Macdonald
Ayer, MA