-----Original Message-----
From: Rolf E. Sonneveld
[mailto:R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl]
Sent: Friday, August 06, 2010 3:11 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
Hi, Murray,
Hey Rolf,
finally got some time to review the -01 draft. Below are my comments.
----
3.2: typo: "... a address..." should be "...an address..."
Fixed.
3.3: in the light of the discussion on message digests, I'd suggest to
add text to this paragraph about MLM's turning multiple messages from
potentially multiple senders/authors into a new message, invalidating
the DKIM signature of the original message(s).
So to the end of "digesting:" you mean something like: "The DKIM signatures on
the original messages might be invalidated by this process." ?
3.3: Just a note on subject tags you may or may not wish to add: some
MLM's offer the choice of appending a postfix (as an alternative to
prepending a prefix).
Added.
3.4: "... entire entire..." should be "... entire..."
Fixed.
3.4: "... but this not workable..." should be "... but this is not
workable..."
Fixed.
3.4: in addition to making the recommendation of sending periodic,
automatic mailings to the list, I would suggest to make the
(implicitely
present) recommendation for an MLM, to not add header- and footer
sections, more explicit.
This section has been removed and merged into various parts of Section 5.
Please let me know if you think the -02 draft (when it comes out) does a better
job of this.
4. (and 5.) I would suggest to add one or two lines to the Introduction
paragraph (par. 1.2 or par 1.4, or add a par. 1.5) to explain that
there
are different types of MLM's and they each are addressed in this
document, in different sections. Something along the lines of:
"In general there are, in relation to DKIM, two categories of MLMs:
participating and non-participating MLMs. As both types have their own
issues, regarding DKIM signed messages that are handled by them, they
are discussed in two different chapters (possibly a link to chapter 4
and 5)."
Seems reasonable to me; added in Section 1.
4.1 I get confused here: you write "the author is advised to be
cautious
when deciding whether or not to sign the message". However, according
to
par. 3.1 the author does not sign a message; that is being done by the
signer. Furthermore, if we change this phrase into "the signer is
advised to be cautious when deciding whether or not to sign the
message"
then the question is: how can a signer (which is by definition not a
human being) know whether the MLM is non-participating. If the signer
is
not a human being, there must be some mechanism by which the signer can
learn from the MLM that is is non-participating, but as the MLM is not
participating, it is difficult to propose a protocol between MLM and
signer to make the signer aware that the MLM is not DKIM aware :-)
The remainder of that paragraph explains things pretty well, but the
first few lines causes some confusion.
Yes, you're right. With some fairly simple wordsmithing, I think we can fix it
by saying the author should not send mail to the list when that mail would be
signed. Thus if signing is within the author's control, the author can just
switch signing off for the list (or better, as the paragraph says, create a
separate stream); otherwise, the author will have to find some other way to
participate, or not participate at all, or take the risk.
4.3 Under [ADSP]. "... Per that specification, when a message is
unsigned or the signature can no longer be verified, the verifier must
discard the message. ...". But this is only true if the author domain
publishes 'discardable'. So I suggest to change this phrase into: "...
Per that specification, when a message is unsigned or the signature can
no longer be verified, the verifier must discard the message in case
the
author domain publishes an ADSP policy of discardable. ..."
I went with:
"Use of restrictive domain policies such as [ADSP] "discardable" presents an
additional challenge." After that I think the rest is OK.
5.1 Section 2: I wonder whether this paragraph is still required, in
the
light of the 'reject policy' described in par. 5.5. After all, why
bother non-posting subscribers with these warnings? As soon as they
start posting, they will get a warning (i.e. a reject) when submitting
their first message and then they can change their policy or post using
another address/(sub)domain. I would suggest to remove this paragraph,
unless I'm overlooking something.
This stuff has been reworked. Let me know if you still have a concern when -02
comes out.
5.4 The title "Pros and Cons of Signature Removal" does not really
cover
the contents of the paragraph. I would suggest "Signature Removal" as
title.
You're right about the misnamed section, but I think that speaks more to what's
missing from the section than the bad title. The posture of the document is
supposed to be a discussion of various implementation choices and their
implications in the DKIM world. Although this does touch on what happens if
you don't remove signatures, it's vague and only in the first paragraph
("unwarranted filter actions"). I've made this more explicit for -02 by
extending the first paragraph to discuss the non-removal case.
5.4 I wonder whether there's any wording required here to describe what
an MLM should do in case of sending a digest. For example, MailMan
supports two types of digest, one of them being the multipart/digest
MIME type, where each message is sent as bodypart inside a mail. Should
the MLM try to verify the DKIM signature of all messages within the
digest and put the A-R for all of them in the header? And remove them
all? Presumably the answer is 'yes', but it won't hurt to describe this
explicitely.
This is an interesting idea. There's nothing saying you couldn't do that. But
it's not clear there's demand for it either. It seems complicated, but also
completely supported by MIME, AUTH-RESULTS and DKIM in case that might somehow
be useful later.
I'm inclined to add a paragraph about it. What do others think?
5.6 At the end of page 18, beginning of page 19: should there not be
explicitely added "o 5322.From field"? As [DKIM] also _requires_ the
From to be used for the header hash.
The list there doesn't include everything that DKIM requires, but only things
the regenerated message should be sure to include that might not be obvious.
RFC5322.From is mandatory per RFC4871.
5.6 Under "Operators of non-DKIM-aware MLMs are advised ...will be
sigend" the following remark: if a non-DKIM-aware MLM send its mail via
an MSA that performs the signing, we run the same risk as having a
DKIM-aware MLM which does not remove the original DKIM signature, don't
we? Another remark about this paragraph: shouldn't this be moved to
chapter 4 (non-DKIM aware MLM's)?
There's a new piece of Section 4 that covers this, suggested by Daniel. You'll
see it in -02.
Thanks for your feedback!
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html