Subject: [ietf-dkim] mailing lists and -base

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Mar 2006 06:57:53 -0800

It occurs to me since the last go-round that our disagreements with 
mailing lists are far far away with the actual mechanisms of -base,
and are mainly in the realm of SSP and a subsequent BCP.

So I'll ask: is there anybody out there who thinks that the current
set of mechanisms in -allman-01 is insufficient and/or wrong for dealing
with this problem? If we can at least get concensus around this, we'll
be able to move defer this issue until we have a more conducive context
in the working group (SSP, BCP).

		Mike, count me as "no changes necessary for -allman-01 

                       wrt mailing lists"
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Mar 2006 08:16:13 -0800

At 6:57 AM -0800 3/28/06, Michael Thomas wrote:
>with this problem?

Yes (insufficient). The current proposal for allowing signers to only 
have to compute the hash once for large message bodies that will be 
sent out numerous times (such as in a mailing list) seems like an 
improvement.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Mar 2006 17:21:55 +0100

Paul Hoffman wrote:
> have to compute the hash once for large message bodies that will be sent 
> out numerous times (such as in a mailing list) seems like an improvement.

Arrgh! Don't cross the threads! (Wasn't that in ghostbusters or
something:-)

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 28 Mar 2006 10:21:44 -0600

> The current proposal for allowing signers to only have to compute the
 > hash once for large message bodies that will be sent out numerous
 > times (such as in a mailing list) seems like an improvement.

I can not disagree.  It isn't always the case, but it is often the case, 
and likely always at least optional that mailing lists personalize the 
TO header.  When this is done, a single body hash which could be reused 
is an improvement.

-- 
Arvel

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Mar 2006 17:33:39 +0100

> Arrgh! Don't cross the threads! (Wasn't that in ghostbusters or

I should explain I guess (got an offlist mail implying so anyway).

I interpreted Mike's posting as being about issue #1224 and not
being about #1193. Mike - do correct me if I'm wrong there.

Stephen.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 28 Mar 2006 08:35:12 -0800

> sent out numerous times (such as in a mailing list) seems like an
IMO (In My Observations), most mailing lists don't need this feature
because they send the same message, body and headers, to all recipients
so the signature is the same even under the allman-01 mechanism.  I get
a few messages with customized To: addresses, but most of them have
customized body content as well.

Paul, do any of the mailing lists you administer send the same body with
different headers to different subscribers?

Don't interpret this as an argument against the new hashing proposal.  I
just want the decision to be based on correct information.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 28 Mar 2006 09:21:38 -0800

Paul Hoffman wrote:
> At 8:35 AM -0800 3/28/06, Jim Fenton wrote:
>> Paul Hoffman wrote:
> No, but that's not the point.
>
> The term "mailing list" can mean discussion lists like the one we are
> on, and it can also mean one-way lists, like the ones that many
> commercial organizations use to talk to their customers. The latter
> type often used customized bodies, customized headers, or both. We
> don't get as much of that now as we should because wanted commercial
> email often looks like spam. If the DKIM protocol can support one-way
> mailing lists better than -allman-01, it should.
Thanks for clarifying.  So really this helps a subset of mailing lists
that customizes the headers but not the bodies.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Mar 2006 09:27:51 -0800

> that customizes the headers but not the bodies.

Here's my question: how can we actually determine whether we _should_
be helping (ie, providing an optimization), and more importantly whether
they will appreciate the "help". I don't seem to recall any consituency
clamouring for this before.

		Mike

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 28 Mar 2006 13:16:04 -0500

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Jim Fenton" <[email-masked]>
Cc: "Paul Hoffman" <[email-masked]>; "IETF-DKIM"
<[email-masked]>
Sent: Tuesday, March 28, 2006 12:27 PM
Subject: Re: [ietf-dkim] mailing lists and -base

> clamouring for this before.

A true protocol doesn't make the distinction.  This isn't about helping one
big name company other some other group of folks.  This is about making it
work for everyone, and as one the few people here with a total framework
mail system in the market place, I think I have the credentials to provide
my engineering input. I can assure you its not done with greedy ambitions or
self-serving attitudes.  I certainly hope that is not what you are asking
about.

Beside this was discussed last year in the list, Mike, in several versions
of threads. I don't recall anyone making or spelling out a specific proposal
detailing a method, but rather the concept was brought up multiple times to
address or sorts of system engineering issues regarding DKIM.

So all the problems were known. 1193 was the first concrete proposal to help
resolve many of them.

Let me do a quick search for the threads:

http://mipassoc.org/pipermail/ietf-dkim/2005q3/000285.html
http://mipassoc.org/pipermail/ietf-dkim/2005q4/000827.html

and there are other threads.

"Do the Search"  This is not the first time it has been discussed.  1193 is
just the first concrete proposal and quite frankly, when I first saw it
presented as a BOF new issue, I was tinkled pink about it. My initial
reaction was this "WG" works and that people do read peoples input and
discussions, providing the synergism for a courageous person to make the
proposal official.   So it wasn't just made up, Mike.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Mar 2006 09:11:04 -0800

--Paul Hoffman

---

From: John Levine <[email-masked]>
Date: 30 Mar 2006 12:26:12 -0000

> The latter type often used customized bodies, customized headers, or both.

I see a lot of list mail where everyone gets the same header and body,
a lot of list mail where everyone gets a different header and
different body, but I don't think I see any where the header is
customized and the body isn't.  I'm not denying this scenario could be
useful in theory, but how many people actually see it in practice?

R's from NZ,
John

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Mar 2006 13:51:00 +0100

I think that the bodyhash thing in this context is a side-issue.
Isn't the main thing here that we need to figure out:-

- what base needs to say about cases where a message containing
   >1 signature is presented for verification, noting that that
   could happen for alg. agility reasons or else because some list
   s/w, or some otherwise odd MTA, added its own signature to an
   already signed message

- whether base needs to have any mandates or guidance for signers
   who want to add a signature to an already-signed message they
   receive (note the above doesn't exclude the advice being "don't
   do it"), and if so, then what (e.g. some ideas about signing a
   few list related headers were batted about previously)

- what guidance the overview (assuming the current charter
   deliverables) ought include for mail list administrators, including
   stuff related to both of the above points

Stephen.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Mar 2006 08:05:59 -0800

>   few list related headers were batted about previously)

I agreed in Dallas to write up a proposal for these. That should be 
within a few days.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html