Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review
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.s...@internode.on.net] Sent: Thursday, July 29, 2010 4:21 AM To: ietf-dkim@mipassoc.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 24 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 23 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: 12 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
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
-Original Message- From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] Sent: Friday, August 06, 2010 3:11 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request Hi, Murray, Hey Rolf, finally got some time to review the -01 draft. Below are my comments. 3.2: typo: ... a address... should be ...an address... Fixed. 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). So to the end of digesting: you mean something like: The DKIM signatures on the original messages might be invalidated by this process. ? 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). Added. 3.4: ... entire entire... should be ... entire... Fixed. 3.4: ... but this not workable... should be ... but this is not workable... Fixed. 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. 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. 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). Seems reasonable to me; added in Section 1. 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. 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. 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. ... I went with: Use of restrictive domain policies such as [ADSP] discardable presents an additional challenge. After that I think the rest is OK. 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. This stuff has been reworked. Let me know if you still have a concern when -02 comes out. 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. You're right about the misnamed section, but I think that speaks more to what's missing from the section than the bad title.
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
-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
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Jeff Macdonald Sent: Monday, August 09, 2010 7:25 AM To: Hector Santos Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request On Mon, Aug 9, 2010 at 9:17 AM, Hector Santos hsan...@isdg.net wrote: 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. +1 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? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
Dave CROCKER d...@dcrocker.net writes: DKIM and ADSP evaluation are not performed during an SMTP session, unless the session is delayed after the crlf.crlf, and that's not supposed to happen. Anyone using the opendkim sendmail/postfix milter will be doing this checking during the SMTP session. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Straw poll results
Scott Kitterman ietf-d...@kitterman.com writes: There's a difference between claims to be from an MLM and From an MLM. Today there isn't much value in making the claim, so no one bothers. It would be unfortunate if we recommended something that caused List-ID headers to be less useful because people found value in spoofing them. Which is where such tools as SPF and DKIM, and even ADSP discardable, are useful. The MLM could usefully publish '-all' SPF records, DKIM sign all mail passing through it and assert that any mail purporting to be via its lists which is not signed may be discarded. Though for ADSP to help detect spooked List-ID headers, the MLM, rather than the submitter, would have to be considered the Author domain. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
A couple of points before I drop for the night from all these edits. I'll pick it up tomorrow, probably after posting an -02 incorporating the editorial feedback so far. Since Dave suggests a fissioning of this document into two or more, I'll hold off applying his until after that's done and some discussion about it has been had. -Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Monday, August 09, 2010 3:40 PM To: Murray S. Kucherawy; DKIM IETF WG Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request When should an author, or its organization, use DKIM for mail sent to mailing lists? The word should implies an intent to make a normative statement. This conflicts with the stated goal of Informational status. So does the distinction between Normative and Informative references. Either the goal should be BCP (or even Proposed) or perhaps the language for this type of statement needs to be softened to something like Under what circumstances does... My own guess is that this document should target BCP. However on further reading I came to the conclusion that this might be two documents, one BCP per its original goal and one Proposed, defining value-added semantics. See below. 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. This is why I have been avoiding use of the RFC2119 words in this document to date. So I'm inclined to change it to Under what circumstances... as you suggested. 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. What are the tradeoffs regarding having an MLM verify and use DKIM identifiers? This might not need fixing but I found myself asking what it means for an MLM to use DKIM identifiers? Perhaps in an Introduction it's ok to say this without prior setup. Dunno. The document goes into what that means, particularly in terms of verifying signatures inbound to the MLM and then signing mail outbound from the MLM. And it seems to me use DKIM means exactly the same thing as use DKIM identifiers, since the carrying of a verified identifier is precisely the point of applying DKIM. 2.4. Message Streams The concept of streams is discussed in the Deployment doc (RFC 5863): http://tools.ietf.org/html/rfc5863 and the DKIM Wikipedia article: http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail I suggest citing them. We should make sure this doc conforms to their definition of explains its variation. 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? (cf: http://www.theonion.com/articles/wikipedia-celebrates-750-years-of-american-indepen,2007/) There is currently no header field proposed for relaying general list policy details, apart from what [LIST-URLS] already supports. This sort of information is what is commonly included in appended footer text or prepended header text. Rather than anticipating or proposing a new field here for that purpose, the working group recommends List policy details? Huh? 1) I don't really know what that means 2) I'm not sure why this is being mentioned here 3) Any use of the word policy usually works against doing productive work in these groups. Seriously. Show me an IETF policy specification that's been successful. Show me a second one. It's not an effort at talking about any policy stuff in the IETF normative sense. I'm talking about MLM configuration features, which are themselves expressions of the list admin's policies. It's way outside of what I think you're talking about. 4.2. Verification Outcomes at Receivers I think everything said in this section is probably correct, but I am not sure what it is referring to, within the scope of DKIM. What technical actions do Verification Outcomes refer to? Weren't you the one that suggested this title? :-) This is off-topic, but I keep wondering whether there isn't an opportunity for a value-added function in the form of a header-field, which says something like the presence of this header field, when signed by DKIM, means that the contents cited in this header field are asserted to be 'valid'... So, for example: DKIM-Valid: From, Date, Subject, Body could mean
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
On 8/9/2010 11:56 PM, Murray S. Kucherawy wrote: It's pretty universal. wow. I had managed to miss this, particularly given the frequent comments from folk that they wished DKIM could operate at SMTP time. (No doubt, they'd much rather have it be useful before data transfer, rather than after. Still, during SMTP is better than later.) This tidbit probably needs to be touted more. Not sure how. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion
On 8/2/2010 11:34 AM, Steve Atkins wrote: A -1 on ever altering the From: field for any reason other than special requirements of the people running a specific mailing list. A +1 in support of that -1. The view that modifying the From: is helpful has no empirical basis. I'll claim that there is a pretty good theoretical basis for believing it makes things worse, not better. As always, the instant the IETF gets into user interface design, it steps out of its group competence. As a group, we do not have the training in cognitive models, UXE, or the rest of what's needed to work in this space. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
Dave CROCKER wrote: On 8/9/2010 11:56 PM, Murray S. Kucherawy wrote: It's pretty universal. wow. I had managed to miss this, particularly given the frequent comments from folk that they wished DKIM could operate at SMTP time. (No doubt, they'd much rather have it be useful before data transfer, rather than after. Still, during SMTP is better than later.) This tidbit probably needs to be touted more. Not sure how. Probably helps to read a wider range of people comments rather than a selected few. This has been discussed for at least a number of years, here and in IETF-SMTP and it was discussed immensely during the Thread Analysis and the SSP Requirements drafting helping to provide guideline as to when a POLICY was necessary. Keep in mind that DKIM verification is not always required when ADSP is supported making a simple DNS lookup useful at the SMTP Level. For example, the payload is transferred with: From: whoe...@paypal.com DKIM-Signature: d=someother.com before the response is provided, the author domain, paypal.com ADSP lookup shows DKIM=DISCARDABLE. Since the DKIM-signature domain is not paypal.com no need for any DKIM verification at this point because it would be a 100% zero-false positive condition for instant rejection. On the other hand it was a 1st party header: From: whoe...@paypal.com DKIM-Signature: d=paypal.com a valid 1st verification is short-circuits the need for a POLICY lookup as it would be only possible to get a valid 1st party DKIM signature with proper 1st party public keys. As outlined in the SSP requirements, only when the signature failures, can a POLICY lookup come into play. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
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
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
I've trimmed out all the places where we agree, so this one is mercifully short. 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? 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. 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. 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 to which I subscribe), so I might want to keep those separate. Seems awfully convoluted, but again, if that's the thinking, better to say that. PS: If I didn't say so before, thanks for all the work you've put into this. My pleasure! Thanks for the feedback! Thanks again. Looking forward to the next round. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Splitting the mailing list document?
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Tuesday, August 10, 2010 7:06 AM To: DKIM IETF WG Subject: [ietf-dkim] Splitting the mailing list document? c. Best practices for Mailing List Managers If the document has indeed wandered off into this more general area (and I'd have to re-read it to find the parts you're talking about), we should reel it back in. I don't want to maintain a general treatise on how MLMs should behave unless perhaps I manage to enlist some co-authors of major current MLMs to do so. I think the other two are within scope and would probably be fine to include in a single document. The latter two have emerged. Neither is formally within scope of the working group, although b. is a natural addition. Note, however, that it is formal protocol specification work and we need to worry about adoption first - - who needs to adopt it and why do we think they will? Is that really true? The document is informational and is deliberately avoiding being normative about anything. Its posture is intended to convey experience of the industry so far in deploying DKIM and MLMs in tandem, and provide some suggestions of how that co-operation could be improved. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
-Original Message- From: Jeff Macdonald [mailto:macfisher...@gmail.com] Sent: Tuesday, August 10, 2010 8:22 AM To: Murray S. Kucherawy Cc: Hector Santos; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request 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. Doesn't the document already do that, and in several places? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Tuesday, August 10, 2010 7:58 AM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org 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? 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. 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? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Splitting the mailing list document?
On 8/10/2010 9:56 AM, Murray S. Kucherawy wrote: The latter two have emerged. Neither is formally within scope of the working group, although b. is a natural addition. Note, however, that it is formal protocol specification work and we need to worry about adoption first - - who needs to adopt it and why do we think they will? Is that really true? The document is informational and is deliberately avoiding being normative about anything. Its posture is intended to convey experience of the industry so far in deploying DKIM and MLMs in tandem, and provide some suggestions of how that co-operation could be improved. The comment was about b, which specified additional semantics and a set of conventions (that is, a protocol) for achieving it. This is the extra header-field I suggested. The current draft touches this realm, but clearly it's beyond the scope of your current project. Rather, the current effort is prompting us to note some related issues. As for Informational, I'll repeat that the core of your draft -- the part that is entirely withing the direct scope as I understand it -- contains normative language. And I think that's appropriate. But that makes it not Informational, but probably a BCP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
On 8/9/2010 11:27 PM, Murray S. Kucherawy wrote: -Original Message- From: John Levine [mailto:jo...@iecc.com] 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 Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion
Dave CROCKER d...@dcrocker.net wrote: On 8/2/2010 11:34 AM, Steve Atkins wrote: A -1 on ever altering the From: field for any reason other than special requirements of the people running a specific mailing list. A +1 in support of that -1. The view that modifying the From: is helpful has no empirical basis. I'll claim that there is a pretty good theoretical basis for believing it makes things worse, not better. As always, the instant the IETF gets into user interface design, it steps out of its group competence. As a group, we do not have the training in cognitive models, UXE, or the rest of what's needed to work in this space. That seems pretty orthogonal to the discussion so far. Declaring discussion of From off limits because it is also displayed makes me wonder why you thought it was alright for the IETF to take on the work codified in RFC 822 and its descendants? Just because it's displayed doesn't mean any change is driven by UX considerations. I get that you're intent on avoiding anything that might make ADSP deployment less difficult, but please stick to the arguments that make some sense. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] dkim and mailing lists
Should DKIM transit a mailing list? if a message arrives at a list manager the author/sender theoretically should be a pre-qualified by whatever means used to be a member of that list. Any recipient that has subscribed to that list has a reasonable expectation that any message addressed to the list would be interesting. With that in mind all signatures should be discarded, resigned by the dkim aware mailing list then forwarded on as if it is a new mail message. Now whether a dkim aware mailing list should follow adsp practices is worth discussing. thanks, Bill Oxley On Aug 10, 2010, at 10:06 AM, Dave CROCKER wrote: On 8/9/2010 11:53 PM, Murray S. Kucherawy wrote: Since Dave suggests a fissioning of this document into two or more, I'll hold off applying his until after that's done and some discussion about it has been had. I'm a fan of getting the mix and balance of documents right. Extra documents are a hassle, but a single document that mixes agendas is too. I was a bit surprised to make the suggestion that this doc get split. 1. Are there different topics? If so, what are they and which should be pursued? The working groups needs to comment on this. I think I saw 3 different topics, and that there has already been a bit of discussion about this. The topics are: a. Handling DKIM messages transiting a Mailing List Manager b. Trust-based enhancements for Mailing List Managers based on DKIM c. Best practices for Mailing List Managers The first is/was the official goal of the current work. The latter two have emerged. Neither is formally within scope of the working group, although b. is a natural addition. Note, however, that it is formal protocol specification work and we need to worry about adoption first -- who needs to adopt it and why do we think they will? c. is not reasonably in scope; I do not see any way to justify it within this working group, in spite of there having been some good discussion. 2. If a split is appropriate, how should the existing content be divided? I vote for letting Murray handle this. (You're welcome, Murray.) So, the first question is intended to get some working group consensus, before Murray puts in the effort of dividing things up. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] dkim and mailing lists
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Tuesday, August 10, 2010 7:16 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: [ietf-dkim] dkim and mailing lists Should DKIM transit a mailing list? if a message arrives at a list manager the author/sender theoretically should be a pre-qualified by whatever means used to be a member of that list. Any recipient that has subscribed to that list has a reasonable expectation that any message addressed to the list would be interesting. With that in mind all signatures should be discarded, resigned by the dkim aware mailing list then forwarded on as if it is a new mail message. Now whether a dkim aware mailing list should follow adsp practices is worth discussing. Bill, Have you read the draft? A lot of this is already discussed in there. If you have specific feedback about the text that's in there already, that would be really helpful. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-mailinglists-01 review request
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-mailinglists-01 review request
On 8/10/2010 10:52 AM, John R. Levine wrote: In particular, it's not intended to provide long term bullet proof message 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 Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
On Tue, Aug 10, 2010 at 12:59 PM, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: Jeff Macdonald [mailto:macfisher...@gmail.com] Sent: Tuesday, August 10, 2010 8:22 AM To: Murray S. Kucherawy Cc: Hector Santos; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-mailinglists-01 review request
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of John R. Levine Sent: Tuesday, August 10, 2010 10:52 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim- mailinglists-01 review request 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. 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? 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.) 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-mailinglists-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DKIM And Mailing Lists Author(s) : M. Kucherawy Filename: draft-ietf-dkim-mailinglists-02.txt Pages : 27 Date: 2010-08-10 DomainKeys Identified Mail (DKIM) allows an administrative mail domain (ADMD) to assume some responsibility for a message. 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). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-02.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-mailinglists-01 review request
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing list reality check
On Aug 4, 2010, at 9:51 AM, John Levine wrote: I'd like to back up a minute and try to understand better what (if any) problem we're trying to solve here. So here is a straw poll. Assuming you do any sorting of inbound mail at all, how do you treat mail from lists to which you have subscribed? A) Use the From: address (or something that identifies the contributor) as the primary sort criterion B) Use the List-ID: (or something that identifies the list) as the primiary sort criterion C) Something else It is my impression that everyone does B, but maybe I'm wrong. B when I can, or occasionally whatever's in procmail's venerable ^TO macro. However, when talking to average user types, they'll most often: 1. wish they knew how to filter 2. /visually/ filter based on subject tags 3. sort alphabetically by subject 4. create MUA filters based on subject 5. create MUA filters based on To/Cc Perhaps if the List-Id header were visible, they'd consider using that instead. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
On Aug 1, 2010, at 3:43 PM, Murray S. Kucherawy wrote: This makes at least the third time this has been suggested by someone. I believe (though I'm willing to be corrected) that the draft should therefore cover this possibility and either advocate it or explain why it's a bad idea. The latter is acceptable; the material is on-topic, and we're trying to relay implementation advice and experience here, so it can be a cookbook of what to do as well as what not to do. Comments? And if you agree, your rationales in either direction? (I'll take Daniel's text at that link into account.) Weighing in a bit late...I think this approach should be included in the document. It's an entirely reasonable approach with some existing implementations, and it may not be as surprising to end users as it is to those of us who read raw email headers daily before breakfast. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
Comments? And if you agree, your rationales in either direction? (I'll take Daniel's text at that link into account.) Unless I misunderstand, this is a paper proposal that has never been implemented that addresses a quite possibly purely hypothetical problem. There's nothing wrong with unimplemented paper designs, but what you do with them is to write them up in an I-D, ask the IETF to publish it as Experimental (something I'd encourage the WG to do for this one), and once there's at least a modest amount of real life experience, perhaps come back and propose an updated version for standards track. For a good idea of the way this can work, look at the EAI group. It published a variety of Experimental RFCs fof non-ASCII email addresses, and now after they have some experience, they're moving ahead with one that seems to work less badly than the others. It's not the one I'd have expected them to pick, but when I read the messages about their experience, I see why they made the choice they did. I have to say that this particular proposal is currently no more than 1/3 baked, since unless I've missed something, I don't see much effort to work out failure and security models. For example: - Who do you accept forwarded messages from? List subscribers? Anyone? Subscribers and people who sign up on a forward-me pseudo list? - If a forwarded message is rejected or bounces, what do you do? At what point should you stop trying to forward? If you get mail to an address that you don't forward any more do you reject it? Drop it? Something else? - What do you do when someone unsubscribes? When someone bounces off the list? When someone changes his subscription address? (Yes, there are MLMs that let you do that.) - What kind of spam filtering is appropriate for forwarded messages? For returning bounces? Should you try to distinguish between real bounces and spam to bounce addresses ? - Many MUAs collect outgoing addresses into the local address book, so people who really have one address will now appear to have N+1 if they subscribe to N lists. Is that a problem? Why or why not? If it's a problem, what should you do about it? That's all that occurs to me in five minutes, but I'm sure that if you actually try it, you'll find lots more. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] revised draft-otis-dkim-tpa-label-06
For making decisions on the dot, See: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06 ADSP was initially focused on mitigating phishing attacks. Unfortunately, ADSP had a negative impact on informal third-party mail services being used by targeted domains. The stalwart alternative to the ADSP proactive scheme, reputation services, are unable to keep pace with the dynamic environment created by criminals profiting from their deceptive activities. So rather than asking a reputation service about the message source, or asking a vouching service about what the Author Domain should have entered into their ADSP record, why not directly ask the Author Domain about the source. After all, the Author Domain has a vested interest in guiding their recipients in what sources should be accepted even when the Author Domain Signature is no longer valid. The Author Domain is able to indicate whether the source domain is authorized and how the recipient should be able to authenticate this source. All of this information is contained within a simple single DNS transaction. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-mailinglists-01 review request
-Original Message- From: John Levine [mailto:jo...@iecc.com] Sent: Tuesday, August 10, 2010 3:49 PM To: ietf-dkim@mipassoc.org Cc: Murray S. Kucherawy Subject: Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim- mailinglists-01 review request 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? 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
