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(_dot_)subs(_at_)internode(_dot_)on(_dot_)net]
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
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