My replies inline. In a few places I've argued in favour of leaving the
current text as-is, but I'm open to further debate of course.
From: Daniel Black
Sent: Thursday, July 29, 2010 4:21 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org; Murray S. Kucherawy
Subject: draft-ietf-dkim-mailinglists-01 review
After much discussion and editing I think these questions need to be
rebalanced based on content presented.
question 1 - the discussion of this draft covers the "When and how"
an author domain so I think this question should start the same way.
is the message streams suggestion.
question 2&4 aren't really discussed as trade-offs but more "How can a
constucted in DKIM friendly way?" and I think this should be the
I think in some ways it is definitely the question, but taking up a posture of
"How can MLMs fix themselves to work in the DKIM world?" is not the right way
to put it. As I'm sure others will be quick to point out, a lot of the things
MLMs do are entrenched, perhaps reasonably so, and it will take a lot of hard
arguing to convince them to change and for everyone to roll out those changes
and participate, affecting countless users.
The softer approach taken here is to evaluate the impact of not changing and
contrasting it to what things would be like if they did, and let them decide
1.3. Feedback Loops And Other Bi-Lateral Agreements
Add reference to section 6 DKIM Reporting
2.3. Feedback Loop References
(very minor) Better title = "Feedback Loop Formats"?
The 2.x sections are just introducing terminology and references to other
documents where such terminology is discussed rather than discussing the
1.1 and 3.3 duplicate content with respect to what MLM modifications
(minor) is this too much(?)
You're right. 1.1 can just refer to 3.3.
(minor)" There reportedly still exist a few scattered mailing lists in
operation that are actually run manually by a human list manager
I suspect this is true but its relevance to DKIM MLM isn't discussed.
True; I suppose I thought what was said there was enough to evoke people's
imaginations, but I'll make that more explicit.
3.4 Alternatives of Participation and Conformance
Actually on re-reading, Section 3.4 doesn't really fit in with the rest of
Section 3, which just lays out the current story. Thanks for these suggestions.
4.3. Handling Choices at Receivers
I'm not convinced there is a filtering solution described in 4.1 as
You're right; "filtering" there should refer to the sign/don't-sign decision
4.1 discusses. I'll fix that.
5.2 Author-Related Signing
Paragraphs 2 and 3 are related to author stream signing more that
The title of Section 5 is meant to cover a number of sub-issues that come into
play when considering activity to, from or through a participating MLM.
Certainly the author stream is part of that.
While a small section of the paragraph 1 and 5.3 is
relevant to the correlation between domains perhaps ordering and
5.2 DKIM Authentication
current paragraph 1.
merge with 5.3 (except last paragraph)
I agree with the repositioning of the first paragraph, but I think the section
headings are fine.
add follow this with:
5.2.1 DKIM Verification and message streams
substantially the 2&3 paragtraphs from 5.2 with less duplication of the
section 2.4 defination.
I've done some other rearranging in there now. Let me know what you think once
-02 is published.
5.3 Verification Outcomes at MLMs
Last paragraph on Authenticaticated results is a separate topic to the
verification of the message for the MLM purposes. As such I think it
in its own section 5.Z Authenticated Results.
Since the rest of Section 5 is a walk-through of the various steps of the
processing of a signed message as it arrives at and transits an MLM, I think
this text is in the right place.
5.4. Pros and Cons of Signature Removal
Suggest adding references on the numbered points:
1&2 Refer to 5.2 Author-Related Signing (or DKIM Authentication if
3. Refer to 5.Z Authenticated Results
5. Affix a new DKIM signature as per 5.X MLM Signatures
Done, but only for the last one; I think the back-reference to adjacent
sections is a bit redundant.
5.5. DKIM Author Domain Signing Practices
This is essentially a duplication/expansion of 5.1 Subscriptions.
merging these two. A warning could be appended here that rejecting a
subscription based on ADSP=discardable could be overly harsh as the
may only intend to receive email from the list.
Did some reworking of these as well.
5.6 MLM Signatures
A DKIM-aware resending MLM is encouraged to sign the entire message
as it arrived (i.e. the "MLM Input" from Section 3.2), especially
including the original signatures.
I'm not sure of the purpose here. This is going to be adding a
will never pass validation outside the ADMD of the MLM. It also may be
substantially the same (with few parameter diffences aside) as the
signature. So why? Is this solely here to support input/output
You're right, this is incorrect. What should be signed is the MLM Output.
"Operators of non-DKIM-aware MLMs could arrange to submit MLM mail
through an MSA that is DKIM-aware so that its mail will be signed."
While I totally agree with the advice here I suspect this could be
placed in a new section '4.X Wrapping a Non-Participating MLM'. Futher
to this section could be added a set of themes associated with 5.1/5.2.
e.g Messages to list subscription addresses could receive a warning if
contain a ADSP=discardable similar to section 5.X. Message to a MLM
address with a ADSP of discardable could be rejected as per section
I think that's probably a good idea. I've added a "Wrapping..." section at the
end of Section 4.
New section 4.X Wrapping a Non-Participating MLM and 5.WRejection of
Though in controvention of the current advice of treating DKIM-
failures the same as no signature, I dare to propose something
on the assumptions that:
1. MLM are the predominate signature breaking software
2. MLM are rarely chained as this creates a inconsistant subscriber
As such I suspect that a MLM-Input will always receive an DKIM
intact. My dare of a proposal is that a deployment option for a
MLM or a Wrapped Non-Paricipating MLM could be to reject DKIM signature
failures on its input. Thoughts? disagreements? Did I suggest this
so - sorry.
I don't think this is necessarily a bad idea -- indeed, early data from
OpenDKIM suggests this may even be likely -- but I don't know that this
document should recommend or suggest it. It certainly is something an MLM
implementer could decide to do.
On the other hand if the data collected by the WG shows that signature survival
rates are generally pretty high, maybe this isn't such a crazy idea.
5.7. Verification Outcomes at Final Receiving Sites
This isn't particular to participating MLMs and there I think it
single number top level heading. Merge with 5.9. Handling Choices at
on a new top level number.
I think it fits within the overall Section 5 (Participating MLMs) story, so
it's OK where it is.
5.8. Use With FBLs
An "FBL operator" is a receiver?
"Where the FBL" which party of the FBL is this?
Yes, this needs clarification. I'll do so in -02.
8.1. Authentication Results When Relaying
atttempt at filling out this section:
I've used your text in a bit of a simpler form.
Thanks for your feedback! I'll watch for your "MUA Considerations" text.
NOTE WELL: This list operates according to