Subject: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 29 Jul 2010 04:52:46 -0700

The -01 draft was briefly presented in Maastricht.  We'd like to get more review of and feedback about it from people with an ideal in mind of starting a WGLC toward the end of September.

Please take some time to review it and provide comments, even if it's just "I've read it, looks good."  We need to record even that sort of thing as part of the rough consensus record before advancing.

You MUST NOT [RFC2119] use this thread for debating the technical or political points of ADSP.  Please start a different thread for that or any other tangent.  It makes the author's job much harder when trying to locate feedback that needs to be applied.

And thanks to Daniel for the quick feedback!

-MSK

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Daniel Black <[email-masked]>
Date: Thu, 29 Jul 2010 21:20:45 +1000

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.....

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 30 Jul 2010 12:01:16 +0200

On 29/Jul/10 13:52, Murray S. Kucherawy wrote:
> You MUST NOT [RFC2119] use this thread for debating the technical or political points of ADSP.

Right, also because the document does not dig deeply into ADSP matter. 
  In particular, I think most of the issues discussed for 
"discardable" hold unchanged for "all", and some of them even for TPA. 
  I would s/"discardable"/non-default/; for example

   Furthermore, authors whose ADSP is published as "discardable" are
   advised not to send mail to MLMs as it is likely to be rejected by
   ADSP-aware recipients.

would become

   Furthermore, authors whose domains publish a non-default ADSP
   record are advised not to send mail to MLMs as it may be rejected
   or dropped for policy reasons by ADSP-aware recipients.

(My tongue cripples on "non-unknown", but then I'm not an English 
speaker.)

I have another couple of points, since I'm at it.  On 26/Jul/10 14:02, 
you wrote:
>> ----- [5.9]
>> The second paragraph,
>>
>>  Receivers are advised to ignore all unsigned Authentication-Results
>>  header fields.
>>
>> is obviously formally wrong.
> Why?

Because signing isn't but one of the five points that RFC 5451 
proposes for recognizing authentic header fields.  In particular, an 
A-R written by a border MTA upstream of the receiver may be unsigned 
yet trusted.

I think the following paragraph --554 replies-- is much better.  But 
how about grepping /554 .*ADSP/ from the log files? Consider appending 
six words like so:

   SMTP servers doing so are also advised to use appropriate wording
   in the text portion of the reply, possibly using the term "ADSP"
   explicitly.

The final suggestion I have is discussable.  Hence I send it as a 
separate message, according to the spirit of the prohibition quoted 
above.  "Yet another alternative mailing list approach" may deserve 
being mentioned in the I-D, in case the WG find it's worth.