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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 1 Aug 2010 15:39:25 -0700

> -----Original Message-----
> From: Alessandro Vesely [mailto:[email-masked]]
> Sent: Friday, July 30, 2010 3:01 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
> 
>   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.)

Any feelings about this from the rest of the working group?  We're possibly in a position to make some editorial remarks here about how "all" and "discardable" should be treated differently, at least by MLMs, if we feel that's prudent.

Personally I'm comfortable with the present text.  I haven't see anyone that treats "all" and "discardable" the same so the danger is limited; OpenDKIM for example merely flags a failed "all" in the RFC5451 field while "discardable" is subject to being bounced or dropped.  But since all of ADSP is at verifier discretion, there's some merit to this idea.  The risk of course is the possibility of later extensions to ADSP that might get created, so maybe changing the advice from being specifically about "discardable" to something more general covering any restrictive policy is better.

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

Ah right, so what it should say is "unsigned externally-applied" instead.  I agree there.

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

I mention "appropriate wording", but suggesting use of the string "ADSP" specifically works for me as well.

Thanks,
-MSK

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

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 07 Aug 2010 00:11:16 +0200

Hi, Murray,

Murray S. Kucherawy wrote:
> 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
>
>

finally got some time to review the -01 draft. Below are my comments.

----

3.2: typo: "... a address..." should be "...an address..."

3.3: in the light of the discussion on message digests, I'd suggest to 
add text to this paragraph about MLM's turning multiple messages from 
potentially multiple senders/authors into a new message, invalidating 
the DKIM signature of the original message(s).

3.3: Just a note on subject tags you may or may not wish to add: some 
MLM's offer the choice of appending a postfix (as an alternative to 
prepending a prefix).

3.4: "... entire entire..." should be "... entire..."

3.4: "... but this not workable..." should be "... but this is not 
workable..."

3.4: in addition to making the recommendation of sending periodic, 
automatic mailings to the list, I would suggest to make the (implicitely 
present) recommendation for an MLM, to not add header- and footer 
sections, more explicit.

4. (and 5.) I would suggest to add one or two lines to the Introduction 
paragraph (par. 1.2 or par 1.4, or add a par. 1.5) to explain that there 
are different types of MLM's and they each are addressed in this 
document, in different sections. Something along the lines of:

"In general there are, in relation to DKIM, two categories of MLMs: 
participating and non-participating MLMs. As both types have their own 
issues, regarding DKIM signed messages that are handled by them, they 
are discussed in two different chapters  (possibly a link to chapter 4 
and 5)."

4.1 I get confused here: you write "the author is advised to be cautious 
when deciding whether or not to sign the message". However, according to 
par. 3.1 the author does not sign a message; that is being done by the 
signer. Furthermore, if we change this phrase into "the signer is 
advised to be cautious when deciding whether or not to sign the message" 
then the question is: how can a signer (which is by definition not a 
human being) know whether the MLM is non-participating. If the signer is 
not a human being, there must be some mechanism by which the signer can 
learn from the MLM that is is non-participating, but as the MLM is not 
participating, it is difficult to propose a protocol between MLM and 
signer to make the signer aware that the MLM is not DKIM aware :-)

The remainder of that paragraph explains things pretty well, but the 
first few lines causes some confusion.

4.3 Under [ADSP]. "... Per that specification, when a message is 
unsigned or the signature can no longer be verified, the verifier must 
discard the message. ...". But this is only true if the author domain 
publishes 'discardable'. So I suggest to change this phrase into: "... 
Per that specification, when a message is unsigned or the signature can 
no longer be verified, the verifier must discard the message in case the 
author domain publishes an ADSP policy of discardable. ..."

5.1 Section 2: I wonder whether this paragraph is still required, in the 
light of the 'reject policy' described in par. 5.5. After all, why 
bother non-posting subscribers with these warnings? As soon as they 
start posting, they will get a warning (i.e. a reject) when submitting 
their first message and then they can change their policy or post using 
another address/(sub)domain. I would suggest to remove this paragraph, 
unless I'm overlooking something.

5.4 The title "Pros and Cons of Signature Removal" does not really cover 
the contents of the paragraph. I would suggest "Signature Removal" as title.

5.4 I wonder whether there's any wording required here to describe what 
an MLM should do in case of sending a digest. For example, MailMan 
supports two types of digest, one of them being the multipart/digest 
MIME type, where each message is sent as bodypart inside a mail. Should 
the MLM try to verify the DKIM signature of all messages within the 
digest and put the A-R for all of them in the header? And remove them 
all? Presumably the answer is 'yes', but it won't hurt to describe this 
explicitely.

5.6 At the end of page 18, beginning of page 19: should there not be 
explicitely added "o 5322.From field"? As [DKIM] also _requires_ the 
 From to be used for the header hash.

5.6 Under "Operators of non-DKIM-aware MLMs are advised ...will be 
sigend" the following remark: if a non-DKIM-aware MLM send its mail via 
an MSA that performs the signing, we run the same risk as having a 
DKIM-aware MLM which does not remove the original DKIM signature, don't 
we? Another remark about this paragraph: shouldn't this be moved to 
chapter 4 (non-DKIM aware MLM's)?

Regards,
/rolf

---

From: John Levine <[email-masked]>
Date: 7 Aug 2010 02:21:03 -0000

I went through -01 again.

Basically, it's fine.  There's a few places where it says things that
are out of scope of DKIM.  A signature either verifies or it doesn't,
and there's nothing inherently good or bad about that.

RFC 4871 carefully describes the way one verifies a signature, and
that process does't include attempts to guess what alternate form of a
message with a broken signature might have been signed.  (Even Mike
admits it's against the rules when he does that.)  A broken signature
is the same as no signature.

ADSP has some fairly specific advice about when not to use discardable,
which is relevant here.

Hence:

Sec 3.2 2nd pp on page 9: "most direct conflict operationally with DKIM" ->
"widest range of possible interactions with DKIM" or something like that.
I don't see any confict at all.

Sec 3.3 "the addition of some list-specific text to the top or bottom of
the message body." -> "modification of the message body."  Lists do a
lot more than add tag lines, as described in subsequent paragraphs.

under Minor body changes: "pose an immediate problem" -> "will probably cause
      any existing signatures not to verify."  Broken signatures are not a
      problem.

under Major body changes: delete "with little or no hope of
      compensation by either the signer or the verifier."  There's no
      such thing as compensation beyond relaxed canonicanization,
      which isn't relevant here

after "human list manager" add "who hand-edits messages" (that would be me)

next pp starting "In general", change first sentence to: 
   In general, an MLM subscriber cannot expect signatures applied before
   the message was processed by the MLM to be valid.

Sec 3.4 2nd pp: delete sentence starting "The shortest path" Personally, I
    think the shortest path is for the MLM's MTA to sign its outgoing
    mail, but I don't think we have consensus either way, so just take
    it out.

Last pp in 3.4: even if there were a new header, few MUAs would interpret
    it.  Suggest taking out "Rather than ... purpose" since it's not a
    realistic alternative.

Section 4.1: There's no reason not to sign all the mail you send to a list.
    Even if the MLM breaks the signature, the MLM itself can use the
    signature when deciding how to handle the message.  The implication
    in the first paragraph that a broken signature is worse than no
    signature is just wrong according to 4871.  Also, [ADSP] says in
    Appendix B not to send mail to lists from discardable domains.  So
    I suggest replacing the first paragraph with a sentence or two
    encouraging people to sign mail sent to lists the same way they
    sign mail to anyone else.  In the second pp, change "If this is cause
    for concern" to "For domains that publish strict ADSP policies"

Section 4.2: channelling Dave, standards shouldn't suggest heuristics.
    So change the second sentence to something like "Sites whose users
    subscribe to non-participating MLMs should be prepared for
    legitimate mail to arrive with no valid signature, just as it
    always has in the absence of DKIM."

Section 4.3: I'd just delete it.  The second pp is OK, but people using
    DKIM are supposed to know that already, aren't they?

Section 5.1: I'd strengthen it to say that since people aren't
    supposed to send mail to lists from discardable domains in the
    first place, lists should reject it or perhaps (for people who've
    already subscribed so you know it's not spam blowback) drop the message
    and send back a note explaining why.

Section 5.2, second pp: I don't understand the point of creating a
    separate signing domain for mail you send to lists.  Why would the
    reputation of mail that people send to lists be better or worse than
    mail they send anywhere else?  It's the same people, I don't see the
    point of a separate mailstream.  ADSP isn't a good reason, since
    it says not to use discardable for domains with human senders.

    The third pp suggests that you're telling people to separate their
    human mailstream from their transactions and their spam blasts.  If
    that's what you mean, I agree, but I'd encourage you to trim down
    the section and reword it to say so more clearly.

In Section 5.4, either delete it or add a sentence at the front that
   says THE ADVICE IN THIS SECTION IS SOLELY INTENDED TO WORK AROUND
   BRAIN DAMAGE IN FILTERS THAT DO NOT IMPLEMENT DKIM ACCORDING TO THE
   SPECIFICATIONS.

   (Well, adding an A-R header isn't, but removing signatures that
   might be broken sure is.)

In Section 5,5, add a ref to [ADSP] Appendix B.5 which says not to
   send discardable mail to lists.

In Section 5.6, first pp: add a sentence noting that recipient system
   will likely use the MLM's signature to recognize list mail and
   develop a (presumably good) reputation for the list itself.

In Section 5.7 add to the end "if senders misuse ADSP" or the like.

Section 5.9, second pp: change to 
  Receivers are advised to ignore Authentication-Results
   header fields that are not signed by a credible signer.

   (Bad guys can sign fake A-R headers.)

Section 5.9, third pp: if a message fails "discardable" the receiver
   should discard it, not reject it.  This avoids the bouncing off the
   list problem, and you're just following orders -- they said it was
   discardable, after all.

Sections 6, 7, 8, and 9 are flawless.

R's,
John

PS: If I didn't say so before, thanks for all the work you've put into
this.

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Aug 2010 09:17:26 -0400

+1 to John notes here. Afrer reviewing the drafts, I think it hits all 
the key points, but there should be a summary somewhere.

I have one comment though to highlight

>    list problem, and you're just following orders -- they said it was

If the MLM follows the other guidelines which amounts to prohibiting 
restrictive ADSP domains from subscribing and submitting list mail, 
then the MLM would not dependent on remote receivers behaving in a 
SMTP level rejection mode since any rejection at this point would not 
be related to ADSP issue but a typical member delivery issue as it is 
today.

This is important in my view because MTAs direction has been more and 
more toward using dynamic SMTP level rejections.

An MTA that has shifted towards a DATA rejection would now have to 
have DKIM/ADSP exception to issue a false positive acceptance for the 
purpose of discard - that means tricky SOFTWARE/INTEGRATION change.

So if the MLM simply follow the guideline to prohibit strict ADSP 
domain mail from entering its list environment, the downlink 
non-delivery ADSP problems would not be an issue anymore - no 
dependency on how downlinks are behaving and have no control over.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 9 Aug 2010 10:24:41 -0400

On Mon, Aug 9, 2010 at 9:17 AM, Hector Santos <[email-masked]> wrote:
<snip>

> dependency on how downlinks are behaving and have no control over.

+1

-- 
Jeff Macdonald
Ayer, MA

---

From: Douglas Otis <[email-masked]>
Date: Mon, 09 Aug 2010 10:52:23 -0700

+1

IMHO, the ADSP assertion "discardable" where messages are silently 
discarded may come to represent a bad practice.

The draft should not offer this type of guidance.  Preventing 
distribution of these domain's submissions, where the list might damage 
the Author Domain Signature, better retains email's integrity and 
provides a comprehensive solution for the problem this damage might cause.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 22:29:58 -0700

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 [mailto:[email-masked]]
> Sent: Thursday, July 29, 2010 4:21 AM
> To: [email-masked]; 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 22:55:38 -0700

> From: Rolf E. Sonneveld [mailto:[email-masked]]
> Sent: Friday, August 06, 2010 3:11 PM
> To: Murray S. Kucherawy

Hey Rolf,

> 3.2: typo: "... a address..." should be "...an address..."

Fixed.

> the DKIM signature of the original message(s).

So to the end of "digesting:" you mean something like: "The DKIM signatures on the original messages might be invalidated by this process." ?

> MLM's offer the choice of appending a postfix (as an alternative to

Added.

> 3.4: "... entire entire..." should be "... entire..."

Fixed.

> 3.4: "... but this not workable..." should be "... but this is not

Fixed.

> present) recommendation for an MLM, to not add header- and footer

This section has been removed and merged into various parts of Section 5.  Please let me know if you think the -02 draft (when it comes out) does a better job of this.

> are discussed in two different chapters  (possibly a link to chapter 4

Seems reasonable to me; added in Section 1.

> first few lines causes some confusion.

Yes, you're right.  With some fairly simple wordsmithing, I think we can fix it by saying the author should not send mail to the list when that mail would be signed.  Thus if signing is within the author's control, the author can just switch signing off for the list (or better, as the paragraph says, create a separate stream); otherwise, the author will have to find some other way to participate, or not participate at all, or take the risk.

> author domain publishes an ADSP policy of discardable. ..."

I went with:

"Use of restrictive domain policies such as [ADSP] "discardable" presents an additional challenge."  After that I think the rest is OK.

> unless I'm overlooking something.

This stuff has been reworked.  Let me know if you still have a concern when -02 comes out.

> the contents of the paragraph. I would suggest "Signature Removal" as

You're right about the misnamed section, but I think that speaks more to what's missing from the section than the bad title.  The posture of the document is supposed to be a discussion of various implementation choices and their implications in the DKIM world.  Although this does touch on what happens if you don't remove signatures, it's vague and only in the first paragraph ("unwarranted filter actions").  I've made this more explicit for -02 by extending the first paragraph to discuss the non-removal case.

> all? Presumably the answer is 'yes', but it won't hurt to describe this

This is an interesting idea.  There's nothing saying you couldn't do that.  But it's not clear there's demand for it either.  It seems complicated, but also completely supported by MIME, AUTH-RESULTS and DKIM in case that might somehow be useful later.

I'm inclined to add a paragraph about it.  What do others think?

>  From to be used for the header hash.

The list there doesn't include everything that DKIM requires, but only things the regenerated message should be sure to include that might not be obvious.  RFC5322.From is mandatory per RFC4871.

> chapter 4 (non-DKIM aware MLM's)?

There's a new piece of Section 4 that covers this, suggested by Daniel.  You'll see it in -02.

Thanks for your feedback!

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 23:27:22 -0700

> From: John Levine [mailto:[email-masked]]
> Sent: Friday, August 06, 2010 7:21 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy

Well the point is to address the fact that a lot of MLM actions disrupt DKIM signature validation.  Maybe "conflict" is too strong a word, but "interactions" feels too soft as well.  "Friction" feels like the right ballpark, but sounds too negative.  How about "foil", "thwart" or "frustrate"?

Done.

Done.

Done.

> after "human list manager" add "who hand-edits messages" (that would be

Already changed based on other feedback to:

"... whose workings in preparing a message for distribution could include the above or even some other changes."

>    the message was processed by the MLM to be valid.

OK.

>     mail, but I don't think we have consensus either way, so just take

OK.

>     it.  Suggest taking out "Rather than ... purpose" since it's not a

OK.

>     signature is just wrong according to 4871.

The text now reads, based on other feedback:

"If an author knows that the MLM to which a message is being sent is a non-participating resending MLM, the author is advised to be cautious when deciding whether or not to send to the list when that mail would be signed."

This takes the signing decision away from the user, which I think resolves your concern.

But for the sake of discussion: I don't think the broken signature is worse and I know you don't think that, but we've encountered implementations that do.  I think it's reasonable for this document to acknowledge that this (incorrect) choice has been made and exists out there, and sometimes we'll have to deal with it.

The whole point of this draft is to talk about these things about which the general public has little understanding.  There's a lot of collective subconscious out there that has equated "bad signature" to "bad message", and perhaps reasonably so.  I think it's better to discuss it in this quasi-BCP than pretend it's not there and expect everyone to figure it out.

>     Also, [ADSP] says in

Done.

>     always has in the absence of DKIM."

OK.

>     DKIM are supposed to know that already, aren't they?

I think part of the point of this document is to walk people through some of the thought processes even if they're clearly the wrong ones.  And to some degree some of the audience of this draft is people who aren't yet using DKIM, but want to or think they should.

>     and send back a note explaining why.

Let me know what you think of -02 when it comes out.  I think it gives a better treatment.

>     it says not to use discardable for domains with human senders.

I believe the thinking was: This stream of mail from me might get mangled, or associated with traffic over which I have no control (and get munged in with the reputations of people on mailing lists to which I subscribe), so I might want to keep those separate.

>    might be broken sure is.)

Minus the caps, I've added a note to indicate something about that.

Done.

Done.

> In Section 5.7 add to the end "if senders misuse ADSP" or the like.

OK.

>    (Bad guys can sign fake A-R headers.)

OK.

>    list problem, and you're just following orders -- they said it was

I've added a paragraph that specifically discusses "discardable".  The paragraph you cited was meant to talk about "all", where the receiver has more discretion (via ambiguity) about what to do.

> Sections 6, 7, 8, and 9 are flawless.

Excellent!

> PS: If I didn't say so before, thanks for all the work you've put into

My pleasure!  Thanks for the feedback!

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 23:30:28 -0700

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Jeff Macdonald
> Sent: Monday, August 09, 2010 7:25 AM
> To: Hector Santos

I agree.  But I'd also like to cover the case where an MLM elects not to handle ADSP at all, and the receivers have to deal with it.  I think failing to do so leaves a fairly obvious hole.

So I'm not sure what the objection is here.  Is there something you guys want removed or changed?

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 07:42:09 -0700

On 8/9/2010 11:27 PM, Murray S. Kucherawy wrote:
> The whole point of this draft is to talk about these things about which the
> general public has little understanding.  There's a lot of collective
> subconscious out there that has equated "bad signature" to "bad message", and
> perhaps reasonably so.  I think it's better to discuss it in this quasi-BCP
> than pretend it's not there and expect everyone to figure it out.

In reviewing your response to John, I'm thinking that part of the initial 
'orientation' work of the draft -- probably in section 3.1 -- should add to the 
description of the components (origination, MLM, receiver) by documenting the 
different scenarios that will be covered, primarily to indicate that basic types 
of choices or effects created by having an MLM in the sequence.

The goal would be to give the reader a snapshot of each combination, so that 
that will be in there head when they read the details.

I think much of the challenge of this exercise is deciding how to organize 
things, so that readers see the problem space partitioned helpfully and, 
therefore, get useful chunks of guidance.  Otherwise it's all overwhelming.

The following list is much longer than I'd like, but I think each entry is for a 
scenario that is distinctive and significant.  (For reference, I've left some 
combinations off, since they didn't seem compelling to me.)

DKIM:

Broken Broken Signatures:

      Origination DKIM -> Non-participating MLM -> Receiving DKIM

Submission enhancement:

      Origination DKIM -> Participating MLM

List reputation:

                          Participating MLM -> Receiving DKIM

End-to-End DKIM:

      Origination DKIM -> Participating MLM -> Receiving DKIM

Besides a discussion of each of these on their own, the possible relationship 
between Broken Signatures and End-to-End DKIM would be helpful in terms of the 
Origination signature.  I think that, in fact, they produce the same result, 
namely a broken signature.

ADSP:

Broken ADSP:

      Origination DKIM+ADSP -> Non-participating MLM -> Receiving DKIM+ADSP

Submission ADSP:

      Origination DKIM+ADSP -> Non-participating MLM

End-to-End ADSP:

      Origination DKIM+ADSP -> DKIM+ADSP Participating MLM -> Receiving DKIM+ADSP

I don't feel religious about this list.  Anything that works is fine.  The 
combinatorials of this problem space are confusing and I'm simply searching for 
a way to divide into smaller bits that are easier to digest.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 10 Aug 2010 10:58:15 -0400

I've trimmed out all the places where we agree, so this one is mercifully 
short.

> Well the point is to address the fact that a lot of MLM actions disrupt DKIM signature validation.  Maybe "conflict" is too strong a word, but "interactions" feels too soft as well.  "Friction" fee…

Nope.  Those all imply that it's important for recipients to validate
the contributors' signatures, which it's not.  They really do have the
widest range of interactions, the most complex signup processes, the
mst complex techniques for deciding what to accept, and the most
varied modifications to the messages.

> But for the sake of discussion: I don't think the broken signature is worse and I know you don't think that, but we've encountered implementations that do.  I think it's reasonable for this documen…

In general, I think it's better to tell people to fix their bugs than to 
encoourage the rest of the world to work around them.  If the point is 
that you may experience trouble delivering to systems with flawed DKIM 
code that erroneously penalizes broken signatures, why not just say that, 
and make it clear where the fault lies?

> I believe the thinking was: This stream of mail from me might get mangled, or associated with traffic over which I have no control (and get munged in with the reputations of people on mailing lists…

Seems awfully convoluted, but again, if that's the thinking, better to
say that.

> My pleasure!  Thanks for the feedback!

Thanks again.  Looking forward to the next round.

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 10 Aug 2010 11:21:53 -0400

> So I'm not sure what the objection is here.  Is there something you guys want removed or changed?

No objection, just that MLMs MUST take ADSP into consideration.

-- 
Jeff Macdonald
Ayer, MA

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 08:26:05 -0700

> No objection, just that MLMs MUST take ADSP into consideration.

The only entities that MUST take ADSP into consideration are those that choose to.

There is neither the expectation nor the leverage to force adoption.

d/

-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 10 Aug 2010 12:39:43 -0400

> There is neither the expectation nor the leverage to force adoption.

While I don't want to encourage adoption, I'm viewing this from a
"defensive" perspective. The users of the MLM won't care if it is the
Author's fault for using ADSP and their IT group for honouring it. If
they communicate with that individual directly and the messages are
delivered, yet they are not via a MLM, then they are going to believe
it is the MLMs fault.

I just believe if the MLM author is going to the trouble to do
anything with DKIM, it doesn't make sense to ignore ADSP.  After all a
MLM author wants his system to be robust.

Thus I support MLMs rejecting any messages with strong ADSP policy. It
isn't that different than MTAs rejecting connections from MTAs that
don't have rDNS.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 09:44:18 -0700

> MLM author wants his system to be robust.

I was not commenting on whether an MLM "should" adopt ADSP, but that there is no 
way to mandate adoption.

Explain, encourage, cajole and implore all you want, but there is no MUST than 
can be applied to adoption.

Any analysis of the use of a protocol MUST consider scenarios in which it has 
not (yet) been adopted.  That's especially true for multi-step scenarios with a 
poor adoption track record.  Such as MLMs...

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 09:59:10 -0700

> From: Jeff Macdonald [mailto:[email-masked]]
> Sent: Tuesday, August 10, 2010 8:22 AM
> To: Murray S. Kucherawy
> Cc: Hector Santos; [email-masked]

Doesn't the document already do that, and in several places?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 10:07:04 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Tuesday, August 10, 2010 7:58 AM
> To: Murray S. Kucherawy
> Subject: RE: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
> 
> > Well the point is to address the fact that a lot of MLM actions
> > disrupt DKIM signature validation.  Maybe "conflict" is too strong a
> > word, but "interactions" feels too soft as well.  "Friction" feels like
> > the right ballpark, but sounds too negative.  How about "foil",
> > "thwart" or "frustrate"?
> 

I agree with the second part but I'm not sold on the first.  I get the statement that an invalid signature is the same as no signature at all, but a signature that can validate has the potential for saying something useful to someone.  The author/signer elected to apply DKIM to make a statement that it hoped a receiver would find meaningful or useful.  Maybe the receiver would be really happy to get that information.  Thus, any intermediary that interferes with that desire is frustrating someone's attempt to say (or hear) something.

If we don't care about this and MLMs clobbering signatures is just a fact of life, why are we even going through this effort?

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 10:20:15 -0700

On 8/9/2010 11:27 PM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: John Levine [mailto:[email-masked]]
>> Sec 3.2 2nd pp on page 9: "most direct conflict operationally with DKIM"
>> -> "widest range of possible interactions with DKIM" or something like
>> that. I don't see any confict at all.
>
> Well the point is to address the fact that a lot of MLM actions disrupt DKIM
> signature validation.  Maybe "conflict" is too strong a word, but
> "interactions" feels too soft as well.  "Friction" feels like the right
> ballpark, but sounds too negative.  How about "foil", "thwart" or
> "frustrate"?

I'm going to suggest that this sub-thread is pretty silly.

I think the existing wording is exactly correct.  The quibbling about language 
is based on a larger context of considerations than applies to the sentence in 
the draft.

DKIM is a particular service.  An MLM will typically destroy a DKIM signature. 
If destruction doesn't count as "conflict with" then I don't know what does.

The sentence in the draft is actually quite carefully to say "operationally" and 
that is exactly the right description of the problematic effect of MLMs with 
respect to the author-to-reader sequence of a DKIM-signed message.

Leave the sentence alone.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 10 Aug 2010 13:52:11 -0400

> DKIM is a particular service.  An MLM will typically destroy a DKIM 
> signature. If destruction doesn't count as "conflict with" then I don't know 
> what does.

I can live with Murray's language, but I'm seeing what appear to me to be 
some fairly basic disagreements about what DKIM does.

My understanding is that it's intended to combine a modest integrity check 
of messages in transit with a responsible identity.  That's all it does. 
In particular, it's not intended to provide long term bullet proof message 
protection, and (disregarding ADSP) there's no semantics assigned to the 
absence of a valid DKIM signature.

The arguments about the alleged importance of preserving inbound 
signatures are silly for a bunch of reasons.  One is three decades of 
practice in which nobody has worried about recipients verifying the 
identities of list contributors.  (I can't help but note the absence of 
S/MIME or PGP signatures on the mail of people who argue otherwise.) 
Another is the observed consistent practice of sorting and I believe 
filtering based on the characteristics of the list rather than individual 
contributors.

Also, if one believes that we should rewrite MLMs to provide some tortured 
way to pass through signatures, or to cater to misimplementations that 
penalize broken signatures, why stop there?  Many lists are read through 
online reformatters like pipermail.  Should we demand they all get 
rewritten to preserve DKIM signatures?  If not, what's the difference?

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 10:55:36 -0700

On 8/10/2010 10:52 AM, John R. Levine wrote:
> protection

I probably haven't been reading carefully enough (as usual.)

Amidst the current discussions, I missed the postings that seemed to be based on 
this different goal for DKIM.

d/
-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 10 Aug 2010 14:07:52 -0400

> Doesn't the document already do that, and in several places?

Yes. Count me as a supporter of such language staying in the document.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 11:12:48 -0700

> [email-masked]] On Behalf Of John R. Levine
> Sent: Tuesday, August 10, 2010 10:52 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-
> mailinglists-01 review request
> 

I don't think we're disagreeing.  The premise of the draft states simply that DKIM is a mechanism for attaching a (provable) domain name to a message as a means for taking some responsibility for it, and that some common MLM practices interfere with the delivery of that payload.  I don't think there's any express or implied claim in the document that DKIM does more than that.

But what you're saying seems antithetical to most of the document, which goes to some lengths to describe ways that MLMs and DKIM can co-operate better.  So should we not bother?

> S/MIME or PGP signatures on the mail of people who argue otherwise.)

Though I don't claim to be able to predict the future, I can speculate that this could become an important thing as domain reputation gets rolled out.  So it might not matter now, but it could matter soon.

---

From: <[email-masked]>
Date: Tue, 10 Aug 2010 14:26:13 -0400

Having reread the document I go with steps 4&5 on page 15. Most of the wording is fine

---

From: SM <[email-masked]>
Date: Tue, 10 Aug 2010 12:59:23 -0700

At 23:27 09-08-10, Murray S. Kucherawy wrote:
>The whole point of this draft is to talk about these things about 
>which the general public has little understanding.  There's a lot of 
>collective subconscious out there that has equated "bad signature" 
>to "bad message", and perhaps reasonably so.  I think it's better to 
>discuss it in this quasi-BCP than pretend it's not there and expect 
>everyone to figure it out.

Agreed.

I think that more experience is needed before the working group 
delves into a BCP.  There isn't any RFC 2119 terminology in 
draft-ietf-dkim-mailinglists-02.  Even if it had such language, that 
doesn't make it a BCP.

At 23:53 09-08-10, Murray S. Kucherawy wrote:
>Some time ago we discussed this and the consensus seemed to be (to 
>me, at least) to produce an Informational document on our first pass 
>through this process with an eye towards doing a BCP (in the formal 
>IETF sense) afterwards.  I think some people have been calling this 
>a BCP because it generally espouses what we think of as best 
>practices, but that term has some special status meanings in the 
>IETF so perhaps that caused some confusion.

Yes.

>If we have changed our consensus and want to take a run at a full 
>BCP document, I'll happily go through and start using RFC2119 
>language.  Finding ways to avoid using those magic words, even in 
>all-lowercase, can be a little time-consuming.

Yes.  The Abstract Section already says:

   "As the industry has now gained some deployment experience, the goal
    for this document is to explore the use of DKIM for scenarios that
    include intermediaries, such as Mailing List Managers (MLMs)."

>Naturally I'm fine citing RFC5863 and ensuring this document's 
>definitions match the ones found there, but do we really want to 
>cite a Wikipedia article?

No.  It's not a good reference unless we are want to track perceived 
consensus in real-time.

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 10 Aug 2010 22:49:24 -0000

>But what you're saying seems antithetical to most of the document,
>which goes to some lengths to describe ways that MLMs and DKIM can
>co-operate better.  So should we not bother?

Oh no.  (That is. we shouldn't not bother.)  There's plenty of good
stuff in your draft, but on reflection I think the key is for the DKIM
camp to be modest in its claims and goals.  Mailing lists do what they
have done for 30 years, and they're not going to change in any major
way.  To the extent that DKIM can help them do what they're going to
do anyway, it's useful.

The discussion of different kinds of lists is certainly helpful, but
we risk going into the weeds when we start getting into complex 
analyses and advice for scenarios that seem (to me at least) pretty
far fetched.

So, for example, one of the things that lists have always done is send
mail to people who have subscribed and presumably want it.  Signing
the outgoing mail should help receipients recognize the mail they
want, so it makes sense to recommend that.

On the other hand, providing per-contributor reputation clues to
subscribers (beyond what's on the From: line) is something that lists
have never done, so I think it's a poor idea to try to invent ways to
do that.

Does that make sense?

R's,
John

---

From: <[email-masked]>
Date: Tue, 10 Aug 2010 19:08:10 -0400

+1

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 21:54:44 -0700

> Sent: Tuesday, August 10, 2010 3:49 PM

Sure.  I got the impression this was something we should be saying based on earlier conversation about whether the list should sign coupled with whether the list should drop author signatures.  Part of that chatter had to do with combined reputation of the list and the author.  If that's a real concern, then on one hand a list/you can gain from the reputation of the other, but on the other hand you can both suffer because of other traffic on the list.  This seemed to be a logical extension of that discussion.

If we feel that's too much of a leap, I can just remove that paragraph.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Aug 2010 07:27:16 -0700

> If we feel that's too much of a leap, I can just remove that paragraph.
DKIM does not confirm the identity of individuals, only the 
administrative domain of the signer. The recipient would need to trust 
the Authentication-Results header, before any information would be 
meaningful beyond what is known about the list itself, such as whether 
it provides List-ID headers, confirms the email-address of subscribers, 
removes deceptive A-R headers, etc.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Aug 2010 09:49:41 -0700

On 8/10/2010 9:54 PM, Murray S. Kucherawy wrote:
> Sure.  I got the impression this was something we should be saying based on
> earlier conversation about whether the list should sign coupled with whether
> the list should drop author signatures.  Part of that chatter had to do with
> combined reputation of the list and the author.  If that's a real concern,
> then on one hand a list/you can gain from the reputation of the other, but on
> the other hand you can both suffer because of other traffic on the list.
> This seemed to be a logical extension of that discussion.
>

I think that the underlying sentiments of this sub-section are reasonable.  But
I am concerned that it's focus and details are muddled.  Unfortunately I think 
that's because our group sense of the topic is still muddled, rather than 
anything as simple to fix as Murray's writing.  Certainly mine is muddled.

So I can't immediately offer modified text.  The best I can suggest is some
further scrutiny.  To that end:

1.  "unexpected"

     An author usually knows they are sending to an MLM.  While they might not
know the actual recipient list, I would not class it as "unexpected".  Worse, 
I'm not sure this issue is relevant to the underlying concern here.  Or, to the
extent it is, I'm not clear how.  This might warrant explication.

2.  "coupled with other messages"

     This implies that a digest message might affect the reputation associated 
with an author of a message in the digest.  Do we really think this is 
plausible?  How?

3.  "insulate one's reputation from influence by the unknown results"

     This is a hugely substantive topic and frankly scares me.  It seems to be at
the heart of this sub-section but I suspect it is a much, much bigger topic.
For starters, is it realistic to pursue this goal at all?

4.  "authors may be well-advised to create a mail stream specifically used for"

    This raises the very basic question of whether an author can create/define a
mail stream?  If so, how?  If not, then the premise of this advice is defeated. 
  For that matter, since mail streams are defined by signing sub-domains, are we 
sure that that is relevant to this problem?  If the original signature is 
broken, the benefit of having different d= values is lost.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Aug 2010 10:03:05 -0700

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Wednesday, August 11, 2010 9:50 AM
> To: Murray S. Kucherawy

I suspect some of the cause of that is that this sort of work necessarily contains some "forward-looking statements" (to borrow from the financial sector).  As John likes to point out, we've never filtered email based on this criterion in the past x years, but in part that's because we've never been able to do so before.  It's possible this will create a mechanism people will find more useful or accurate.  I don't want to stifle that possibility before anyone even has a chance to try it.

We have at best an educated guess about how different signature patterns on a message, or on a digest of messages, will affect the reputations of the signers.  I'm torn between describing such a guess in an informational document and saying nothing at all, if only to get the readers thinking about it as well.

We've decided the industry wants or needs guidance, so we want to give some.  But the work starts to suffer when the thinking drifts into navel-gazing.  I don't have any problem admitting that I can be guilty of it; I'd rather be thinking about it than not.

Anyhow, this is what reviewers are for.  :-)

-MSK

---

From: Daniel Black <[email-masked]>
Date: Tue, 31 Aug 2010 16:36:16 +1000

> I've done some other rearranging in there now.  Let me know what you think

Section 5 looks a lot better. Well done.

5.3 Subscriptions

(minor) "disallow or" suggest removal

I think disallow is going to far. The subscription to a list doesn't imply an 
intent to post. Depending on the list type of couse this may not be possible.

(previous suggestion by me:
> 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.

how are the stats looking?

> Thanks for your feedback!  I'll watch for your "MUA Considerations" text.

reworked based on feedback:

ANNEX A - MUA Considerations

The main body of this document describes a number of MLM behaviours that break 
DKIM signatures. These behaviours are, in some cases, features required by MLM 
operators to forfill technical, policy or legal requirements. Some of these 
behaviours operate in such a way that breaks DKIM signatures and have 
alternate implementations that will also meet the needs of MLM operators.

Header Footer additions

Header/Footer additions on MLM can include unsubscribe information describing 
to the user how to unsubscriber from a MLM

MLM are recommended by LIST-ID to include a List-Unsubscribe header field. In 
the presence of MUA support this would depreciate the necessity of  
Header/Footer additions for unsubscribe information.

MUAs are recommended to present to the user the List-Unsubscribe header field 
URL in such a way that they can utilize this URL easily to unsubcribe from the 
email list.

Subject Header Modifications

A reasonable number of MLM list subscribers potentially still recognise and 
filter messages based on the subject line. The subject line modification is as 
effective as a List-ID filtering and MLMs are recommended to include this 
header field.

A MUA could implement the following features to reduce the need for signature 
modifications: 
* Display of the List-ID header field is used present the name of the list to 
the user.
* functionality to create a filter based on based on the List-ID header field.

Authenticated Results

[AUTH-RESULTS] describes how a MUA could use the Authenticated-Results header 
field to present DKIM validation information to the user. This is particularly 
important where the presence of broken author domain signatures are present 
and the presence of MLM dkim signatures may be used for alternative 
authenticity or filtering determinations.

A MUA could use the Authenticated-Results header field to:
* Display what authentication was performed by the verifier
* Create a display and filtering options based where on common domains occur 
in list-post header fields and DKIM signatures (recommended in section 5.7) 

The security considerations of AUTH-RESULTS need to be carefully addressed by 
the MUA to prevent deliberate exploitation of user perceived integrity 
information.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 31 Aug 2010 15:37:36 -0700

> ANNEX A - MUA Considerations

Is a draft about mailing lists the right place to make recommendations to MUA developers?  Seems like those should probably be in a separate document.

(This is not to say that I disagree with the recommendations themselves, of course.)

---

From: Hector Santos <[email-masked]>
Date: Tue, 31 Aug 2010 19:14:03 -0400

J.D. Falk wrote:
> Is a draft about mailing lists the right place to make 
> recommendations to MUA developers?  Seems like those should probably 
> be in a separate document.
> 

Ideally, we need another "bible" like the classic RFC 1123:

    Requirements for Internet Hosts -- Application and Support
    http://www.ietf.org/rfc/rfc1123.txt

which put it all together for Internet Hosting systems. RFC 1123 was 
especially helpful for integrated operations and systems.

Too many documents, too many of one altering or updating the other and 
unfortunately sometimes incoherently and inconsistently.

While I personally believe the current documents on the WG table 
should be "fixed" to codify the engineering semantics, if that can't 
happen (and doubt it will),  a document that puts it all together like 
a RFC 1103 for DKIM operations on both the HOST and CLIENT side would 
be very valuable.

---

From: Daniel Black <[email-masked]>
Date: Wed, 1 Sep 2010 09:01:03 +1000

On Wednesday 01 September 2010 08:37:36 J.D. Falk wrote:
> Is a draft about mailing lists the right place to make recommendations to
> MUA developers?  Seems like those should probably be in a separate
> document.

Seems as though the draft is touching on authors, signers and verifiers 
touching on the receiver and their considerations and view of dkim and mailing 
lists would just complete the picture. just my humble opinion.

> (This is not to say that I disagree with the recommendations themselves, of
thanks.