> -----Original Message----- > From: John Levine [mailto:jo...@iecc.com] > Sent: Friday, August 06, 2010 7:21 PM > To: ietf-dkim@mipassoc.org > Cc: Murray S. Kucherawy > Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request > > 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"? > 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. Done. > under Minor body changes: "pose an immediate problem" -> "will probably > cause > any existing signatures not to verify." Broken signatures are > not a > problem. Done. > 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 Done. > after "human list manager" add "who hand-edits messages" (that would be > me) Already changed based on other feedback to: "... whose workings in preparing a message for distribution could include the above or even some other changes." > 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. OK. > 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. OK. > 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. OK. > 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. 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 > 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" Done. > 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." OK. > 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? 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. > 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. Let me know what you think of -02 when it comes out. I think it gives a better treatment. > 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. 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. > 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.) Minus the caps, I've added a note to indicate something about that. > In Section 5,5, add a ref to [ADSP] Appendix B.5 which says not to > send discardable mail to lists. Done. > 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. Done. > In Section 5.7 add to the end "if senders misuse ADSP" or the like. OK. > 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.) OK. > 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. 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 > this. My pleasure! Thanks for the feedback! -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
