Re: [ietf-dkim] Proposed changes to MLM draft
On 08/30/2010 08:03 PM, Murray S. Kucherawy wrote: I'd like some help tackling the next version of the MLM draft. People seem to have varying ideas about what should be removed and perhaps appear in other documents now. I need some consensus on a direction in which to proceed. So can I please get some +1s/-1s on each of the following: (1) Split the document into three documents: A DKIM MLM BCP that discusses signing and verifying in the context of MLMs with no value-add items addressed, a DKIM MLM Informational that discusses possible value-add enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing lists irrespective of DKIM (Dave's proposal); +1, but see my previous message about normative vs informational. (2) Tear out everything having to do with making author signatures survive list relaying, dropping all that text altogether, and instead pointing people at S/MIME or PGP (John's proposal); -1. Removing signatures/traces because a) some domains don't know how to use ADSP and/or b) some assessors don't implement RFC4871 correctly sounds like a bad idea to me. The best the document can do here, is to describe what are the pro's of keeping signatures and what are the pro's of removing them, in an operational environment. (3) Something else (and specify what that might be). AND... If you support any of the above, please take a few minutes to include some pointers to what text you want changed/exported and in what way. Actual diffs would be ideal, but I'll take point-form commentary as well. I'll try to review the -02 version in the next couple of days. AND... If you advocate for a general MLM BCP, this will be a non-WG document (it's outside of our charter) so I'd love to get some MLM operators and developers involved. (Maybe this should take place on ietf-822 or maybe on a new non-WG list; suggestions welcome.) Expressions of interest in that work would be appreciated. I'll approach the APPS ADs about a venue. IMO MLM's need a re-design to bring them in line with today's e-mail technologies, but inevitably this will lead to (new) MUA requirements. As these things only have a small (or no) DKIM component I fully agree to move that work to another list. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed changes to MLM draft
Murray S. Kucherawy wrote: If you advocate for a general MLM BCP, this will be a non-WG document (it's outside of our charter) so I'd love to get some MLM operators and developers involved. (Maybe this should take place on ietf-822 or maybe on a new non-WG list; suggestions welcome.) Expressions of interest in that work would be appreciated. I'll approach the APPS ADs about a venue. The DKIM WG charter includes LIST operations support. 5. Consider issues related to mailing lists, beyond what is already documented. This includes considerations for mailing list software that supports or intends to support DKIM, as well as considerations for DKIM/ADSP deployment in the presence of mailing lists that do not have such support. Include recommendations in the informational documents, or produce a new informational document about mailing-list considerations. Therefore your MLM would be very appropriate. Mr. Crocker says this is a distracting from our current work. Mr. Crocker should be reminded what is out of scope per the charter: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. The on-going changes in the DKIM draft standard documentations and specification semantics all related to reputation has been a major distraction, hindrance and road block in completed chartered goals. -- 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] Proposed changes to MLM draft
On 30/Aug/10 20:03, Murray S. Kucherawy wrote: (1) Split the document into three documents: A DKIM MLM BCP that discusses signing and verifying in the context of MLMs with no value-add items addressed, a DKIM MLM Informational that discusses possible value-add enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing lists irrespective of DKIM (Dave’s proposal); -1, splitting the document should only occur as an author's decision about topics unrelated to one another. If the doc contains any normative text, then it should go for standard track. For clarity, it should be enough to mark which sections of the document are normative and which ones are only informative, as other docs do (for one, http://tools.ietf.org/html/draft-moriarty-post-inch-rid). (2) Tear out everything having to do with making author signatures survive list relaying, dropping all that text altogether, and instead pointing people at S/MIME or PGP (John’s proposal); -1, this topic may need further discussion. Attribution of responsibility for a message destined to _public_ MLMs is particularly delicate, given possible replay attacks and FBLs. While PGP and S/MIME are fine, they imply signers should abstain from signing mail for MLMs. Is that what we want to recommend? Two techniques have been proposed for enabling signers to limit the extent of responsibility they take, joint signatures and From-%- rewriting; did we reach any conclusion about them? Are there more? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed changes to MLM draft
On Tuesday 31 August 2010 04:03:45 Murray S. Kucherawy wrote: I'd like some help tackling the next version of the MLM draft. People seem to have varying ideas about what should be removed and perhaps appear in other documents now. I need some consensus on a direction in which to proceed. So can I please get some +1s/-1s on each of the following: (1) Split the document into three documents: A DKIM MLM BCP that discusses signing and verifying in the context of MLMs with no value-add items addressed, a DKIM MLM Informational that discusses possible value-add enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing lists irrespective of DKIM (Dave's proposal); -1. A single document is good for implementors. (2) Tear out everything having to do with making author signatures survive list relaying, dropping all that text altogether, and instead pointing people at S/MIME or PGP (John's proposal); -1. Surviving signatures seems like a good long term goal. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
On Tuesday 31 August 2010 06:53:59 Jeff Macdonald wrote: On Wed, Aug 25, 2010 at 3:17 PM, J.D. Falk jdfalk-li...@cybernothing.org wrote: So what we SHOULD be arguing about (those of us interested in forward progress) is whether draft-ietf-dkim-mailinglists-02 meets the documentation goal Rolf described above. Nits: existing misspelled below: o What are the tradeoffs regarding having an MLM remove exisitng DKIM signatures prior to re-posting the message? Section 3.3 - last paragraph, the misspelled - before hte message Below are my comments on draft-ietf-dkim-mailinglists-02. I have caught up with the mailing list posts as of today (well, within the last 3 hours or so), but I haven't retained in my head what others have already said. If some of this has discussed already, I apologize. I think we are very close to Rolf's stated goals. Section 1.3 - I'd change bulk mail sender to just sender. I have trouble seeing how any bulk sender would end up sending to a MLM. Section 3.1: author - is it really defined that way in email-arch? That definition would mean an ESP would be considered the author. As an ESP we construct messages from content objects created by our clients. I'm having trouble with the word constructed in that section. Perhaps The agent that actually created the content of the message. I really don't like that either. I'd like to say the agent that authored the message. :) Think in terms of books. signer - Last sentence: A signer may also be same agent as an originator or author. 3.2 MLM Output: why is the MLM considered the author? Shouldn't it be the originator? consuming the author's copy of the message and creating its own. seems a little off to me. I get what it is trying to say, but I think a gentler view would be to view it as a newspaper. Each article has it's own author and the newspaper presents a group of articles along with a other interesting content. So maybe consuming the author's copy of the message and producing a mailing list version of that message. 3.3 Is the reference to John L needed? :) There reportedly still exist a few scattered mailing lists in operation that are actually run manually by a human list manager, whose workings in preparing a message for distribution could include the above or even some other changes. Section 5.7 A signing MLM is advised to add a List-Post: header field (see [LIST-URLS]) using a DNS domain matching what will be used in the d= tag of the DKIM signature it will add to the new message I'd remove this paragraph. I strongly believe that d= needs stands on its own. Anything that promotes the notion of that a class of d= is more or less than another because it matches some other header field or not should be discouraged. I'm in favour of keeping this paragraph. A small bit of advice, like the current -02, provides some hope of a small bit consistancy for those writing receiving agents (e.g. 5.9 / 5.10) that want to do some intelligient processing without adding with complexity. Less (options) is more (value). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Tuesday 10 August 2010 15:29:58 Murray S. Kucherawy wrote: I've done some other rearranging in there now. Let me know what you think once -02 is published. 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: 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. 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
Re: [ietf-dkim] Proposed changes to MLM draft
So many choices, so little time. From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Monday, August 30, 2010 2:04 PM To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] Proposed changes to MLM draft I'd like some help tackling the next version of the MLM draft. People seem to have varying ideas about what should be removed and perhaps appear in other documents now. I need some consensus on a direction in which to proceed. So can I please get some +1s/-1s on each of the following: (1) Split the document into three documents: A DKIM MLM BCP that discusses signing and verifying in the context of MLMs with no value-add items addressed, a DKIM MLM Informational that discusses possible value-add enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing lists irrespective of DKIM (Dave's proposal); -1 Do we need as many documents to describe the tail as we need to describe the dog? (2) Tear out everything having to do with making author signatures survive list relaying, dropping all that text altogether, and instead pointing people at S/MIME or PGP (John's proposal); -1 John's proposal is that we leave MLMs alone to do their thing, but in such a way that it is codified in the working group document. He has inserted himself into this process in a manner similar to what he did to ADSP. If we are seriously going to consider tearing out everything having to do with making author signatures survive list relaying then I think another option should be considered - The working group should drop any attempt to write a document specific to MLMs. Some will operate in a way compatible with DKIM and others will choose not to. S/MIME and PGP are out of scope for the working group. It would be ironic for the DKIM working group to point people somewhere else. It is essentially an acknowledgement that DKIM is a failure in that the working group would be expressing a belief that it is not possible for signatures to survive MLM handling under any circumstances. If it is possible for DKIM signatures to survive then why the opposition to documenting such implementations could it be potential pressure to change and evolve? Darwin was right evolve or die. (3) Something else (and specify what that might be). Drop the effort to write a document specific to MLMs and leave each one to sink or swim on their own decisions AND... If you support any of the above, please take a few minutes to include some pointers to what text you want changed/exported and in what way. Actual diffs would be ideal, but I'll take point-form commentary as well. AND... If you advocate for a general MLM BCP, this will be a non-WG document (it's outside of our charter) so I'd love to get some MLM operators and developers involved. (Maybe this should take place on ietf-822 or maybe on a new non-WG list; suggestions welcome.) Expressions of interest in that work would be appreciated. I'll approach the APPS ADs about a venue. Thanks, -MSK ___ 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] Proposed changes to MLM draft
MH Michael Hammer (5304) wrote: So many choices, so little time. (2) Tear out everything having to do with making author signatures survive list relaying, dropping all that text altogether, and instead pointing people at S/MIME or PGP (John's proposal); -1 John's proposal is that we leave MLMs alone to do their thing, but in such a way that it is codified in the working group document. He has inserted himself into this process in a manner similar to what he did to ADSP. If we are seriously going to consider tearing out everything having to do with making author signatures survive list relaying then I think another option should be considered - The working group should drop any attempt to write a document specific to MLMs. Some will operate in a way compatible with DKIM and others will choose not to. This whole IETF process reminds me of the Devil's Advocate quote for God's greatest goof of all time: Look but don't touch, Touch but don't taste, Taste but don't swallow We allowed informational status documents to alter the draft standards, allowing for out of scope goals to be injected, change the scope of author domain messages, implicitly begin state to ignore draft standards and then needed another informational status document to make the corrections to the informational document and also draft standards. Talking about common sense engineering goofs! The big elephant in the room is unrestricted resigners. The documents, proposed standard and/or informational are in conflict with dealing with that issue. -- 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-02 review
On Aug 30, 2010, at 11:36 PM, Daniel Black wrote: 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.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
J.D. Falk wrote: On Aug 30, 2010, at 11:36 PM, Daniel Black wrote: 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.) 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. -- 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-02 review
On Wednesday 01 September 2010 08:37:36 J.D. Falk wrote: On Aug 30, 2010, at 11:36 PM, Daniel Black wrote: 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. 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 course.) thanks. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
