Murray et al.
I've done a second review of this. Most suggestions here relate to making the
document easlier to read colocating like sections and splitting dual themes.
There are a few new bits within for thought.
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.
1.3. Feedback Loops And Other Bi-Lateral Agreements
(minor)
Add reference to section 6 DKIM Reporting
2.3. Feedback Loop References
(very minor) Better title = "Feedback Loop Formats"?
1.1 and 3.3 duplicate content with respect to what MLM modifications occur
(minor) is this too much(?)
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.
3.4 Alternatives of Participation and Conformance
(moderate importance)
I think the correlation between this section's title and its content makes
this hard to read in a particular context. I suspect most content could move
into 5. Participating MLMs. I suggest moving its content as follows:
Paragraph 1 move as a first paragraph in section 5
Paragraph 2 Sentence 1 can be removed as it is covered in section 5.6 MLM
Signatures. The remaing sentences talk about where a sender signs headers that
a MLM will modify. This could be worthy of a new 5.X Header Signature
Incompatibilities subsection describing how a Participating MLM could deal
with this issue. I suspect a MLM response of issuing a warning to the Author
(or marf-dkim-reporting address) would be approprate.
Paragraph 3/4/5, Header/Footer additions, can probably be moved to a new 5.Y
Policy Notices.
4.3. Handling Choices at Receivers
(moderate imprtance)
I'm not convinced there is a filtering solution described in 4.1 as stated. If
there is it probably should be moved and described in this section. There is
also other bits related to receiver considerations so moving there may also be
approprate.
5.2 Author-Related Signing
(moderate importance)
Paragraphs 2 and 3 are related to author stream signing more that
Participating MLMs. 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)
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.
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.
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
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.
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?
(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).
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 i.e.
a subscriber on the second list will receive email however the first list will
not recognise them as a subscriber if they post and; the second list will have
the first list as a subscriber but all the subscribers of the first list will
not be recognised by the second list.
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.
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.
5.8. Use With FBLs
(minor/clarification)
An "FBL operator" is a receiver?
"Where the FBL" which party of the FBL is this?
8.1. Authentication Results When Relaying
(new)
atttempt at filling out this section:
A MLM RFC5322.Authenticated-Results field is generated outside of the receivers
ADMD. As such, by default, they contain all the same security risks described
in section 7.2. of [AUTH-RESULTS]. Eventually a recipient ADMD may choose to
excert some form of reliance in the RFC5322.Authenticated-Results field. At
this point the recipient is suspectiable to this field being forged in order to
bypass the recipient's stronger domain or ADSP based filtering that may be in
place. It is therefore recommended that once a decision to rely on a third
party RFC5322.Authenticated-Results field is made that this field is also
required to be protected by a DKIM signature from the same domain.
The reliance of this field even with the DKIM-Signature protection effectively
makes the MLM server an internal host for the purposes of the risks described
in 7.9 of AUTH-RESULTS.
I may get to a new Annex MUA considerations later.....
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html