Subject: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-02.txt

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Nov 2006 07:49:15 -0800

Folks,

[email-masked] wrote:
> 	Title		: DomainKeys Identified Mail (DKIM) Service Overview
> 	Author(s)	: T. Hansen, et al.
> 	Filename	: draft-ietf-dkim-overview-02.txt
> 	Pages		: 41
> 	Date		: 2006-10-24

It's been a week.  Has anyone had time to look the document over, enough to have 
any initial reactions?

d/

-- 

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

---

From: John Levine <[email-masked]>
Date: 3 Nov 2006 23:49:58 -0000

>It's been a week.  Has anyone had time to look the document over, enough
>to have any initial reactions?

I did, due to the magic of long plane trips.

It sure does have a lot of informative info, and still needs lots of
work.

My first question is who the target audience is.  The lengthy
discussions in sections 7, 8, and 9 leave me wondering whose questions
they're supposed to answer.

The discussion of mailing lists in 9.3 is just wrong.  (A
parenthetical comment correctly suggests it may be controversial.)
I'll send in some replacement language to clarify that in the usual
case that list owners take responsibility for managing their lists,
the list should sign the mail that passes through it, and in the
exotic case that the list does not take responsibility and recipients
want to evaluate list mail sender by sender rather than as list mail,
it may in some cases be possible to pass through the incoming
signatures.

In section 10, I do not think the first sentence means what you think
it means.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 04 Nov 2006 06:27:55 -0800

John,

Thanks for the comments.

> It sure does have a lot of informative info, and still needs lots of

Given your ending comment, below, you might be amused that the approach to the 
document has, so far, largely been one of "if in doubt, put it in."

This latest version is the first one to try to do any pruning, albeit 
conservatively.

> they're supposed to answer.

Speaking for myself, I believe the document has multiple targets, all of whom 
are technical.  (I suppose portions of the text could be useful for management 
and even marketing, but it's clear the document is not targeting either of 
them.) So, I'd say developers, administrators, operators and technical writers. 
  Mostly developers .

The -base document does not really contain a "system" description -- ie, DKIM 
signing and validating within a context.  Hence, sections 5 & 6.

Obviously 7, 8 and 9 target developers, administrators and operators.

If you see the document as being problematic for those target readers, please 
elaborate.

> it may in some cases be possible to pass through the incoming

"the usual case" is an interesting choice of language, given that there are no 
DKIM-aware mailing list packages, yet.  (See below, about making predictions.)

Happily, the thrust of your language isn't affected by simply removing the word 
'usual'.

Please explain what you think is "just wrong" with the current language.  It 
will help to understand how your proposed alternative language is an 
improvement.  (I, too, think the section needs more work, but from your brief 
description, above, I am not quite sure what particular problems you see with 
the current text.)

> In section 10, I do not think the first sentence means what you think

Again, speaking strictly for myself, I'd prefer to eliminate all discussion 
about the future.  My experience with IETF documents that attempt to predict the 
future is that they are pretty much always wrong.  More importantly, I'm never 
quite sure what the benefit of the predictions is supposed to be.

On the other hand, explaining what types of extensions the existing system has 
provided for (e.g., multiple query services) can be help readers understand the 
design better.  So my own preference is to have that section discuss something 
like "Extensibility".

d/
-- 

   Dave Crocker

---

From: [email-masked]
Date: Mon, 6 Nov 2006 22:14:14 -0000 (GMT)

> It's been a week.  Has anyone had time to look the document over, enough

Here're some comments from on the plane.

Overall, this seems to be shaping up nicely.

Cheers,
Stephen.

---

From: John Levine <[email-masked]>
Date: 6 Nov 2006 22:58:37 -0000

>#8 Our charter calls for us to help mail list admins to be
>DKIM-friendly. I don't really know what that entails but I don't see
>section 9.3 providing it either. What to do?  E.g. I would have
>thought saying the adding a "[LIST]" preface to the Subject would be
>unfriendly to messages where the Subject field was signed and might
>recommond some other list flagging scheme.

Assuming the overview is intended for people who are not already
familiar with DKIM, we should delete and replace most of this section.

The current wording gives the misleading and unfortunate impression
that if you want to use DKIM with mailing lists, you have to remove
all features from your list software added since about 1987.  If I
were a list admin reading that, my response would be there's no point
in wasting time with DKIM since it doesn't work with the software that
my users and I already use.

Proposed new section 9.3:

A mailing list often provides facilities to its administrator to
manipulate parts of the mail messages that flow through the list.  The
desired goal is that messages flowing through the mailing list will be
verifiable by the recipient as being from the list, or failing that,
as being from the individual list members.

In most cases, the list and/or its mail host should add its own
signature to list mail.  This could be done in the list management
software, in an outgoing MSA or MTA, or both.  List management
software often makes modifications to messages that will break
incoming signatures, such as adding subject tags, adding message
headers or footers, and adding, deleting, or reordering MIME parts.
By adding its own signature after these modifications, the list
provides a valid recognizable signature for list recipients.

In some cases, mailing list software is simple enough that signatures
on incoming messages will still be valid after being remailed by the
list.  It is still preferable that the list sign its mail so that
recipients can distinguish mail sent through the list from mail sent
directly by list members, but in the absence of a list signature, a
recipient may be able to recognize and use the signatures of list
members known to the recipient.

R's,
John

---

From: <[email-masked]>
Date: Mon, 6 Nov 2006 18:19:19 -0500

seconded

-----Original Message-----
From: [email-masked] on behalf of John Levine
Sent: Mon 11/6/2006 5:58 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Re: I-D ACTION: draft-ietf-dkim-overview-02.txt

R's,
John