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.
> -----Original Message----- > From: Daniel Black [mailto:daniel.s...@internode.on.net] > Sent: Thursday, July 29, 2010 4:21 AM > To: ietf-dkim@mipassoc.org; Murray S. Kucherawy > Subject: draft-ietf-dkim-mailinglists-01 review > > 1. Introduction > (moderate importance) > > 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" > related to > an author domain so I think this question should start the same way. > The "how" > is the message streams suggestion. > > question 2&4 aren't really discussed as trade-offs but more "How can a > MLM be > constucted in DKIM friendly way?" and I think this should be the > question. 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 for themselves. > 1.3. Feedback Loops And Other Bi-Lateral Agreements > (minor) > Add reference to section 6 DKIM Reporting Done. > 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 material there. > 1.1 and 3.3 duplicate content with respect to what MLM modifications > occur > (minor) is this too much(?) You're right. 1.1 can just refer to 3.3. > 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 > (moderate importance) > [...] 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 > (moderate imprtance) > > I'm not convinced there is a filtering solution described in 4.1 as > stated. 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 > (moderate importance) > > Paragraphs 2 and 3 are related to author stream signing more that > Participating MLMs. 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 > relableing it > as: > 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 > (moderate) > Last paragraph on Authenticaticated results is a separate topic to the > verification of the message for the MLM purposes. As such I think it > should be > 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 > (minor) > Suggest adding references on the numbered points: > 1&2 Refer to 5.2 Author-Related Signing (or DKIM Authentication if > renamed as > suggested) > 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 > (moderate) > This is essentially a duplication/expansion of 5.1 Subscriptions. > Suggest > merging these two. A warning could be appended here that rejecting a > subscription based on ADSP=discardable could be overly harsh as the > subscriber > may only intend to receive email from the list. Did some reworking of these as well. > 5.6 MLM Signatures > (serious) > " > 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 > signature that > will never pass validation outside the ADMD of the MLM. It also may be > substantially the same (with few parameter diffences aside) as the > original > signature. So why? Is this solely here to support input/output > difference > comparison? You're right, this is incorrect. What should be signed is the MLM Output. > (serious) > "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 > better > placed in a new section '4.X Wrapping a Non-Participating MLM'. Futher > more, > 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 > they > contain a ADSP=discardable similar to section 5.X. Message to a MLM > resending > address with a ADSP of discardable could be rejected as per section > (ref). 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 > DKIM > signature failures > (for discussion) > > Though in controvention of the current advice of treating DKIM- > signature > failures the same as no signature, I dare to propose something > different based > on the assumptions that: > 1. MLM are the predominate signature breaking software > 2. MLM are rarely chained as this creates a inconsistant subscriber > lists [...] > > As such I suspect that a MLM-Input will always receive an DKIM > signature > intact. My dare of a proposal is that a deployment option for a > participating > MLM or a Wrapped Non-Paricipating MLM could be to reject DKIM signature > failures on its input. Thoughts? disagreements? Did I suggest this > before? if > 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 > (serious) > This isn't particular to participating MLMs and there I think it > deserves a > single number top level heading. Merge with 5.9. Handling Choices at > Receivers > 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 > (minor/clarification) > An "FBL operator" is a receiver? Yes. > "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 > (new) > 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. -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
