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] Mailing lists and s/mime dkim signatures - mua considerations
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. Section 5.9 I don't really understand why we need this section at all. Perhaps I can buy someone a beer in DC to help me understand it. (ah, B.2 helps, a little) Section 5.10 Why 5.7.2 instead of 5.7.1? There is no expansion going on at the receiver. I don't agree with the last paragraph. I don't see rejects causing more harm than good. Section 5.10 is targeted for receivers. The subscribers of the mailing lists. Since this document is targeted at MLM, how are we expecting subscribers to pay attention to this section? -- Jeff Macdonald Ayer, MA ___ 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 Wed, 25 Aug 2010 00:47:20 +0100, Hector Santos hsan...@isdg.net wrote: Rolf E. Sonneveld wrote: Although DKIM does not specify (as far as I know) what to do with DKIM signatures in inner bodyparts, I think DKIM signatures should never be removed without a good reason. If you believe this, then you have to advocate the removal of the RFC 4871 mandate regarding invalid signatures changing to no-signature status as if it never existed and the message was never signed. Not so. A retained, but now invalidated, signature should have no effect on the behaviour of an assessment engine (well almost so - it might like some assurance that it HAD been signed previously before proceeding to consideration of the trustworthiness of the MLM's signature, but an A-R header would provide that). No, the purpose of retaining that signature is primarily for forensics. Given that it is meaningless for protocol purposes for the reasons you gave, it cannot possibly do any harm. Destroying it would do some minor harm (hindering any forensic investigation). It would also frustrate geeks who might like to reconstruct the original signed message for verification purposes, but they are not the primary custimers of any retention. It is simnply a matter of not destroying potentially useful evidence. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ 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 25-08-10, Hector Santos hsan...@isdg.net wrote:Rolf E. Sonneveld wrote: Although DKIM does not specify (as far as I know) what to do with DKIM signatures in inner bodyparts, I think DKIM signatures should never be removed without a good reason.If you believe this, then you have to advocate the removal of the RFC 4871 mandate regarding invalid signatures changing to no-signature status as if it never existed and the message was never signed.No, absolutely not! It seems you state here that a broken signature is worse than no signature. It isn't. They're to be treated equally. What this means is that if a MLM keeps broken tracings of signatures, the only existing trace signature is the valid one. No, this is not what it means. It's quite simple: ANY verifier can encounter ZERO, ONE or MORE DKIM signatures, some of them can be broken (by MLM's or by other mail agents), some of them can proof to verify correctly. The only conclusion a verifier can make for EACH VALID signature is, that the domain that's in the d= value of THAT signature takes (some) responsibility for that message (in the incarnation of the message of the moment, when that domain signed the message). All other (non-valid) signatures are to be ignored. All others must be ignored.And ANY non-valid signature must be treated as if it were not present in the message at all. The fact that an MLM breaks a signature is not unique for MLMs. Any agent in the path between signer(s) and verifier(s) can break a signature. Let's keep it clear: a broken signature is to be ignored (base DKIM spec). But removing signatures without a good reason is wrong./rolf ___ 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 8/25/10 5:32 AM, Hector Santos wrote: Sonneveld, Rolf wrote: Let's keep it clear: a broken signature is to be ignored (base DKIM spec). But removing signatures without a good reason is wrong. A good reason is to lower the confusion of an unknown assessment world, especially when the LAST SIGNER is taking responsibility and is the presumably the only vounch-able entity but the unknown non-standard reputation filtering engines (RFE) advocates. Agreed. When a mailing list manager (MLM) flattens messages, modifies subject lines, and appends unsubscribe information, the mailing list manager and _not_ the author should be considered to represent the entity introducing the message into the mail stream. As such, broken signatures represent an unnecessary consumption of resources. Mike Thomas advocated use of the -l body length option with header copies to recover most, but not all, signatures using various unknown heuristics. Unfortunately, the -l option can lead to an exploitable situation when a message is accepted because it was signed, but recipients remain unaware of unsigned portions. Since not all signatures can be recovered, this either exposes recipients to possible exploitation, or it creates support issues when messages or portions thereof are dropped when recovery fails. It also seems unrealistic to expect adoption of a message display convention to highlight which portion of the message body was signed by various signatures. Use of the -l parameter should be considered a bad practice that should be deprecated, and too much to ask of MUAs to properly support. What is your reason for keeping a broken signature? Do you have an RFE that can utilize this information? None that I can imagine, beyond the practice advocated by Mike Thomas. -Doug ___ 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
And ANY non-valid signature must be treated as if it were not present in the message at all. The fact that an MLM breaks a signature is not unique for MLMs. Any agent in the path between signer(s) and verifier(s) can break a signature. Let's keep it clear: a broken signature is to be ignored (base DKIM spec). But removing signatures without a good reason is wrong. /rolf ATT1..txt If I have an email message in my possession and wish to send it on for any reason whatsoever I can remove mangle or otherwise any portion of the message for any reason at all. Why should I keep any forensic information before sending the message on? I am taking responsibility for sending my messages, no one else. ___ 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 Aug 24, 2010, at 1:07 PM, MH Michael Hammer (5304) wrote: -Original Message- From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] [ . . . ] We should not change the essentials of DKIM for sake of MLM transparancy; the best we can do is document the status quo of the combination of DKIM and MLMs, its problems and (within the boundaries of the DKIM spec) any hints that can solve or mitigate those problems. I absolutely agree with your last statement. +1 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. ___ 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
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Monday, August 23, 2010 11:06 PM To: Daniel Black Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations DKIM's main purpose is assessment by reputation filtering engines. The most important reputations to assess are the entities that are 'responsible' for message. Dave, Please show us in RFC4871 where it says DKIMs main purpose is assessment by reputation filtering engines. In re-reading 4871 I find the following references: 6.3. Interpret Results/Apply Local Policy It is beyond the scope of this specification to describe what actions a verifier system should make, but an authenticated email presents an opportunity to a receiving system that unauthenticated email cannot. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation. Conversely, unauthenticated email lacks a reliable identifier that can be used to assign trust and reputation. It is reasonable to treat unauthenticated email as lacking any trust and having no positive reputation. Nothing here that begins to imply that the main purpose is assessment by reputation filtering engines. Perhaps this paragraph slightly down the page: Once the signature has been verified, that information MUST be conveyed to higher-level systems (such as explicit allow/whitelists and reputation systems) and/or to the end user. If the message is signed on behalf of any address other than that in the From: header field, the mail system SHOULD take pains to ensure that the actual signing identity is clear to the reader. But again, no verbage that matches your assertion. The modifying clause that begins with such as gives examples but only explicitly states that the information must be conveyed to higher level systems. May be that you are basing your assertion on section 8.5 regarding replay attacks except that begins with Partial solutions in referring to reputation systems, so that can't be it. If we look at additional DKIM related RFCs, the only explicit use of the identifier is found in the ADSP RFC which is certainly not reputation system based but assertion based. But I forget one of the authors of that RFC says don't use it because it is bad, bad, bad. Looking forward to your response and explanation of where we find the main purpose of use in reputation systems in the RFC. Mike ___ 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
Hector Santos: IMO, it is these statements that continues to raise confusion and raise the barrier of industry wide adoption that includes the general population of MTA developers and operators from tiny to small to even large. As a part-time MTA developer I am not confused. The DKIM signature provides a simple piece of trace information (I handled this mail) that is cryptographically bound to some header and body content. The receiver can use this trace information for any purpose that she deems suitable. What seems to confuse some people is that the using part is entirely decoupled from the signing part, and that the signer has no control over what use is made. In my view, this decoupling is beneficial (DKIM as an enabler). For others, this open-ended design is a shortcoming (batteries required). Wietse ___ 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 8/24/2010 6:42 AM, MH Michael Hammer (5304) wrote: Please show us in RFC4871 where it says DKIMs main purpose is assessment by reputation filtering engines. It's a fair question, but answering it encounters three core problems. The first is that 4871 is not a systems specification. It's a component specification. So it might or might not contain language about the way a signature is intended to fit into a larger processing environment. The second is that we've been struggling with finding the right language for describing systems issues about DKIM. Note that we even managed to write a protocol document without defining the protocol's output, which is why we needed an errata document. So we need to be careful about using RFC 4871 outside of the larger context of work done since it was published. As I recall Mark Delany's explanation of the original intent for Domainkeys, it was considered a primary goal to design the system in a way that targeted implementation in the email infrastructure rather than email end systems. The reduced granularity, of having an organization rather than user identifier, was an example of this. It massively reduced administrative overhead. And third, if DKIM has a main purpose for something involving end user processing, where is the detailed specification or guidance that would encourage interoperable use of it? Without that, use becomes idiosyncratic and therefore non-interoperable. (This is a version of the same logic we all debated we had about i=/d=, concerning signer intent and assessor interpretation.) That said, your citation of RFC 4871: 6.3. Interpret Results/Apply Local Policy ... Once the signature has been verified, that information MUST be conveyed to higher-level systems (such as explicit allow/whitelists and reputation systems) and/or to the end user. Is at least nicely in the right arena, IMO. But again, no verbage that matches your assertion. I wasn't aware that my statement was offered as a quotation. I certainly didn't intend it to be. On the other hand... If we look at additional DKIM related RFCs, the only explicit use of the identifier is found in the ADSP RFC... You missed the relevant, related RFCs: Errata, RFC 5672: 8. RFC 4871, Section 2.11, Identity Assessor ... A module that consumes DKIM's mandatory payload, which is the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However, this additional activity is outside the scope of the DKIM signature specification. Overview, RFC 5585, http://dkim.org/specs/rfc5585.html#rfc.section.5: .+-+--++ +---+ . . | | / Check \+ . | +/ Signing \ . | / Practices \..+ . | +---+---+ . . | | . . | V . +++ |+---+ +--+-+ |Reputation/ | || Message | | Local Info | |Accreditation| +---| Filtering | | on Sender | |Info | | Engine| | Practices | +-+ +---+ ++ and: verifying: ... If the signature passes, reputation information is used to assess the signer and that information is passed to the message filtering system. and http://dkim.org/specs/rfc5585.html#rfc.section.5.5 5.5. Assessing ... A popular use of reputation information is as input to a Filtering Engine that decides whether to deliver -- and possibly whether to specially mark -- a message. Filtering Engines have become complex and sophisticated. Deployment, RFC 5863, http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#system: 2.1 A Systems View of Email Trust Assessment ... The recipient then makes handling decisions based on a collection of assessments, of which the DKIM mechanism is only a part. In this model, as shown in Figure 1, validation is an intermediary step, having the sole task of passing a validated Responsible Identifier to the Identity Assessor. ... The Identity Assessor uses this single, provided Identifier for consulting whatever assessment data bases are deemed appropriate by the assessing entity. In turn, output from the Identity Assessor is fed into a Handling Filter engine that considers a range of factors, along with this single output value. and the accompanying figure: http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.figure.1 along with:
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
On 8/23/10 8:05 PM, Dave CROCKER wrote: On 8/21/2010 6:06 PM, Daniel Black wrote: Taking an approach saying we don't care if DKIM survives MLMs is a step in the opposite direction. This is not a proposal I support. Not really, since it was known from the start that survival through an MLM is highly problematic and the steps towards helping survival were known to be quite limited. Requiring survival is a change in DKIM's goals, as well as raising a massive barrier to adoption, given the history of a) challenge in adoption for any infrastructure sequence, and b) resistance by MLM developers and operators. In other words, this line of efforts is seeking to raise the requirements for DKIM. Absent compelling and demonstrated functional need, that makes it at best a distraction and at worst counter-productive for DKIM's main purpose. Agreed. DKIM's main purpose is assessment by reputation filtering engines. The most important reputations to assess are the entities that are 'responsible' for message. Strongly Disagree. The SMTP client represents the most important entity responsible for issuing the message. DKIM was never intended to provide a reputational basis for email acceptance. DKIM does not indicate where a message had been initially sent. It may indicate who initially handled a beginning portion of the message body, but this limitation fails to provide an adequate basis upon which reputations can be based. A primary criteria for assessing unsolicited email is where the message had been sent, especially when content is of little benefit to its recipient. As such, efforts to accept IPv6 email is unlikely to find DKIM a suitable basis. Perhaps soon SMTP can develop an SMTP Auth that combines use of a DKIM key together with a work product of keyassure. Identification of the SMTP client truly represents the entity responsible for issuing undesired messages. After all, the bulk of today's email would be extremely difficult to categorize based upon the possible presence of DKIM signatures. In special cases, where the entirety of users within a domain is trusted, DKIM then provides a method in which a recipient can both accept these messages, and possibly identify suspicious messages that might be attempting to mislead the recipient. Unfortunately, DKIM lacks a suitable policy construct that is better able to assist recipients, even with this small fraction of emails, due to issues related to third-party services. DKIM ensures the authentication status of users on whose behalf a message was signed remains unknown. For a small fraction of the domains, DKIM might offer recipients a basis for sorting messages into trusted and suspicious categories. As such, for the majority of messages, the only reputation upon which acceptance can be based is that of the SMTP client. An MLM creates the message. That the message might look a lot like one sent /to/ it is nice, but it's also confusing. The original author is not, ultimately, responsible for what the MLM chooses to send. Agreed. This affirms the SMTP client represents the important entity for what is being sent. S/MIME already does that, with a suitable pointer. S/MIME was design to protect body content, not an entire message. All of this prompts a repeat of an underlying question: What is the purpose of this exercise and how is it justified within the charter? With respect to MLMs, I thought the focus was on documenting realities and passing through MLMs and to explore issues and opportunities better integrate MLMs into DKIM. That's quite different from trying to alter the core DKIM capability to support survival through MLMs. I'm pretty sure that changing DKIM Core is not within our charter. Agreed. -Doug ___ 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 8/24/2010 11:59 AM, MH Michael Hammer (5304) wrote: Then it would appear that we are substantially in violent agreement. in spite of our best efforts. 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] Mailing lists and s/mime dkim signatures - mua considerations
On Aug 24, 2010, at 10:23 AM, Mark Delany wrote: On Tue, Aug 24, 2010 at 09:45:20AM -0400, Wietse Venema allegedly wrote: Hector Santos: IMO, it is these statements that continues to raise confusion and raise the barrier of industry wide adoption that includes the general population of MTA developers and operators from tiny to small to even large. As a part-time MTA developer I am not confused. The DKIM signature provides a simple piece of trace information (I handled this mail) that is cryptographically bound to some header and body content. Yes. And that the obverse is possible: I didn't handle this mail. I don't see how DKIM can provide the obverse - the obvious way is for a sender to assert that all their mail has a DKIM signature, but that fails when the DKIM signature breaks in transit. Is there a clever trick I'm missing? As Jon Callas is fond of saying, you know a protocol is a success when it's abused in ways you never thought possible. The bi-laterals that others have discussed are a small example of this. Jon got it right: we don't need to know all of what is possible with so general a component as DKIM. My personal motivation, going back some seven years now, was about tools for putting credibility (back) into the email system. Clearly this is far from the only motivation across the population of DKIM developers. Varying motives don't necessarily mean varying tools. DKIM allows you to attach a token to an email. That's such a generally useful thing it's no surprise people are finding a range of uses for it. Cheers, Steve ___ 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
Dave CROCKER wrote: On 8/24/2010 11:59 AM, MH Michael Hammer (5304) wrote: Then it would appear that we are substantially in violent agreement. in spite of our best efforts. may I suggest we stop here for a moment and get back to the original question, which in essence was: should a 1st signer DKIM signature be preserved 'coûte que coûte' when a message is handled by a MLM, or not. To answer this question I'd like to quote the excellent summary of what DKIM is about, posted earlier today by Wietse: The DKIM signature provides a simple piece of trace information (I handled this mail) that is cryptographically bound to some header and body content. The receiver can use this trace information for any purpose that she deems suitable. I think most of us can agree with this summary of what DKIM really is, without all the bells and whistles we often like to attribute to it. Next we add a quote from Dave about what the MLM does: An MLM creates the message. That the message might look a lot like one sent /to/ it is nice, but it's also confusing. The original author is not, ultimately, responsible for what the MLM chooses to send Again, most of us will agree with this, I assume. Now combining the two, and _without focussing on any hypothetical action of a verifier or recipient_, the conclusion must be that the MLM adds its own DKIM-signature, leaving the original DKIM-signature(s) untouched. After all, removing the original DKIM signature would mean removing a piece of trace information provided by the originating domain. And once it's gone, it's gone. Leaving the original DKIM signature untouched is in line with chapter 4 of RFC4871 including par. 4.2 that states: Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. I haven't found any text in the erratum of 4871 / 5672 that obsoletes this text. This means we can treat (regarding this particular aspect) MLMs like any other re-signing agent, no exceptions are required. And yes, this means my opinion changed, I no longer advocate the use of multipart/alternative to preserve the 1st signer DKIM signature, instead it is my opinion now that an MLM should leave it untouched (and not remove it). I have come to this conclusion by looking at what DKIM is, and carefully avoiding looking at what a verifier or recipient might possibly do with the information it provides. We should not change the essentials of DKIM for sake of MLM transparancy; the best we can do is document the status quo of the combination of DKIM and MLMs, its problems and (within the boundaries of the DKIM spec) any hints that can solve or mitigate those problems. /rolf ___ 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
-Original Message- From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] Sent: Tuesday, August 24, 2010 3:31 PM To: dcroc...@bbiw.net Cc: MH Michael Hammer (5304); ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations Dave CROCKER wrote: On 8/24/2010 11:59 AM, MH Michael Hammer (5304) wrote: Then it would appear that we are substantially in violent agreement. in spite of our best efforts. may I suggest we stop here for a moment and get back to the original question, which in essence was: should a 1st signer DKIM signature be preserved 'coûte que coûte' when a message is handled by a MLM, or not. To answer this question I'd like to quote the excellent summary of what DKIM is about, posted earlier today by Wietse: I am somewhat agnostic on the question of preserving DKIM signatures when a message is handled through MLM. Intuitively I would like them preserved and I believe that MLMs can preserve them if they are interested in doing so. If I were running an MLM (I have done so in the past but do not currently do so) I would certainly respect an ADSP=discardable assertion and ensure that I handled messages accordingly (more than one way to skin a cat). As John has pointed out on numerous occasions, it should not be demanded of MLMs that they change their ways to accommodate anything new under the sun (paraphrasing here) because they have been around for as long as they have and done quite nicely thank you very much. Darwin was right. To the extent that ill-intentioned individuals find MLMs (and email accounts posting through MLMs) interesting targets in the future, those MLMs that are unfriendly to email authentication are likely to find themselves at greater risk than those MLMs which are friendly to email authentication. There are varying ways in which an MLM can deal with this issue. I for one wouldn't dream of attempting to dictate to them what they must or must not do. Receivers are not stupid and will respond to such evolving circumstances as they may in the interests of their endusers as well as their own reputation. I for one wouldn't dream of attempting to dictate to them what they must or must not do. In any event, I perceive MLMs as the tail that appears to be wagging the dog. In the context of email authentication, there are so many much more interesting mail streams from my perspective. The DKIM signature provides a simple piece of trace information (I handled this mail) that is cryptographically bound to some header and body content. The receiver can use this trace information for any purpose that she deems suitable. I think most of us can agree with this summary of what DKIM really is, without all the bells and whistles we often like to attribute to it. Next we add a quote from Dave about what the MLM does: An MLM creates the message. That the message might look a lot like one sent /to/ it is nice, but it's also confusing. The original author is not, ultimately, responsible for what the MLM chooses to send Again, most of us will agree with this, I assume. Now combining the two, and _without focussing on any hypothetical action of a verifier or recipient_, the conclusion must be that the MLM adds its own DKIM-signature, leaving the original DKIM-signature(s) untouched. After all, removing the original DKIM signature would mean removing a piece of trace information provided by the originating domain. And once it's gone, it's gone. Leaving the original DKIM signature untouched is in line with chapter 4 of RFC4871 including par. 4.2 that states: Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. I haven't found any text in the erratum of 4871 / 5672 that obsoletes this text. This means we can treat (regarding this particular aspect) MLMs like any other re-signing agent, no exceptions are required. Rolf, you have sidestepped the issue of digests or do you feel this holds true for them as well? And yes, this means my opinion changed, I no longer advocate the use of multipart/alternative to preserve the 1st signer DKIM signature, instead it is my opinion now that an MLM should leave it untouched (and not remove it). I have come to this conclusion by looking at what DKIM is, and carefully avoiding looking at what a verifier or recipient might possibly do with the information it provides. Interesting. We should not change the essentials of DKIM for sake of MLM transparancy; the best we can do is document the status quo of the combination of DKIM and MLMs, its problems and (within the boundaries of the DKIM spec) any hints that can solve or mitigate those problems. I absolutely agree with your last statement. Mike ___ NOTE WELL: This list operates
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
As a part-time MTA developer I am not confused. The DKIM signature provides a simple piece of trace information (I handled this mail) that is cryptographically bound to some header and body content. Yes. And that the obverse is possible: I didn't handle this mail. I don't see how DKIM can provide the obverse - the obvious way is for a sender to assert that all their mail has a DKIM signature, but that fails when the DKIM signature breaks in transit. Is there a clever trick I'm missing? So you're saying it can provide the obverse; you just don't like the failure modes. Perhaps surprisingly, the failure modes are exactly what attracts some folk to DKIM. We also have to be patient. When DK was first discussed, folk said that it was impossible because MTAs routinely made arbitrary changes to the payload, but that's no longer true. Folks also said that the mainstream players would never get on board, but that's no longer true. A fork-lift change was never going to occur overnight so we just have to keep chipping away. Mark. ___ 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 Aug 24, 2010, at 1:30 PM, Mark Delany wrote: As a part-time MTA developer I am not confused. The DKIM signature provides a simple piece of trace information (I handled this mail) that is cryptographically bound to some header and body content. Yes. And that the obverse is possible: I didn't handle this mail. I don't see how DKIM can provide the obverse - the obvious way is for a sender to assert that all their mail has a DKIM signature, but that fails when the DKIM signature breaks in transit. Is there a clever trick I'm missing? So you're saying it can provide the obverse; you just don't like the failure modes. Perhaps surprisingly, the failure modes are exactly what attracts some folk to DKIM. The failure modes of DKIM are all false negatives, which is fine. (Concrete example: I've not seen any suggestion that there has been mail that was signed by paypal.com that wasn't from paypal, and I suspect someone would have mentioned it). The failure mode of anything that's based on the inverse of DKIM are all false positives. While you can assert I didn't handle this mail, that's not an assertion that can be trusted, in general. (Concrete example: I've seen email that paypal.com asserted was not sent by them, based on lack of DKIM signature, which actually was sent by them). I'd be surprised if that failure mode attracted people to DKIM, and I'd be interested to hear more about why it did. I'm pretty sure I didn't handle this mail is a an assertion that you can make in this way, though, and the level of certainty is going to be high enough to be of value in some cases. But it's not quite the same thing as being able to say I didn't handle this mail. We also have to be patient. When DK was first discussed, folk said that it was impossible because MTAs routinely made arbitrary changes to the payload, but that's no longer true. Folks also said that the mainstream players would never get on board, but that's no longer true. A fork-lift change was never going to occur overnight so we just have to keep chipping away. Cheers, Steve ___ 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 Tue, 24 Aug 2010 04:05:38 +0100, Dave CROCKER d...@dcrocker.net wrote: Not really, since it was known from the start that survival through an MLM is highly problematic and the steps towards helping survival were known to be quite limited. Nevertheless, there IS a solution that MLMs can use which will ensure survival through an MLM. Yes, it has a few downsides, but then so do all the other solutions suggested. Someone (the MLM for this particular case) has to evaluate the tradeoffs. If it is likely to be suitable for .some. MLMs, then it ought to be included in Murray's arsenal of possible mitigations. Requiring survival is a change in DKIM's goals, as well as raising a massive barrier to adoption, given the history of a) challenge in adoption for any infrastructure sequence, and b) resistance by MLM developers and operators. Indeed. We will not REQUIRE survival, but some MLMs might like to provide it. A resistant MLM may suddenly find his list is not working as intended, due to discarding of mis-signed messages. We can't force him to drink our water; we cannot even lead him to it; but at least we should point out where it is. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ 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
MH Michael Hammer (5304) wrote: [...] In any event, I perceive MLMs as the tail that appears to be wagging the dog. In the context of email authentication, there are so many much more interesting mail streams from my perspective. +1 The DKIM signature provides a simple piece of trace information (I handled this mail) that is cryptographically bound to some header and body content. The receiver can use this trace information for any purpose that she deems suitable. I think most of us can agree with this summary of what DKIM really is, without all the bells and whistles we often like to attribute to it. Next we add a quote from Dave about what the MLM does: An MLM creates the message. That the message might look a lot like one sent /to/ it is nice, but it's also confusing. The original author is not, ultimately, responsible for what the MLM chooses to send Again, most of us will agree with this, I assume. Now combining the two, and _without focussing on any hypothetical action of a verifier or recipient_, the conclusion must be that the MLM adds its own DKIM-signature, leaving the original DKIM-signature(s) untouched. After all, removing the original DKIM signature would mean removing a piece of trace information provided by the originating domain. And once it's gone, it's gone. Leaving the original DKIM signature untouched is in line with chapter 4 of RFC4871 including par. 4.2 that states: Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. I haven't found any text in the erratum of 4871 / 5672 that obsoletes this text. This means we can treat (regarding this particular aspect) MLMs like any other re-signing agent, no exceptions are required. Rolf, you have sidestepped the issue of digests or do you feel this holds true for them as well? Sidestepping the issue of digest was not intentional, I just forgot to include them in my previous message. Most MLMs these days create digests by concatenating a number of messages, where for each message a subset of header lines + the body are presented. In that situation any DKIM-signatures, which may have been present in the original message(s), are lost. Murray writes in the DKIM and Mailing Lists I-D about the digest type: digesting: A special case of the re-posting MLM is one that sends a single message comprising an aggregation of recent MLM submissons, which might be a message of [MIME] type multipart/digest (see [MIME-TYPES]). This is obviously a new message but it may contain a sequence of original messages that may themselves have been DKIM-signed. If (repeat: if) the logic of my previous message applies (the MLM should leave already present DKIM-signatures untouched) this could lead to the following suggestion/recommendation for MLMs: MLMs should not remove DKIM signatures when assembling digest messages. This can be achieved by using the following rules: a) when digesting the multipart/digest MIME type/subtype should be used, according to RFC2046 and b) for each message that is part of the digest, copy the entire (header+message) into a message/rfc822 part and c) re-sign the message with the MLM DKIM Signature on the outer-level header of the enclosing message As a) will have impact on the recipients of those digest messages, the MLM should insert a 'Table of Contents' of all contained messages before the first message/rfc822 part (a number of MLMs already do this). And, in addition to this, the MLM optionally can add Content-ID's for each message/rfc822 part (if the Content-ID is not already present and not part of the DKIM signature) . The ToC then can link items to the corresponding Content-ID of the enclosed message. If the original DKIM signature refers includes a content-id field, then the MLM must not add a content-id to the header of the message/rfc822 bodypart. Although DKIM does not specify (as far as I know) what to do with DKIM signatures in inner bodyparts, I think DKIM signatures should never be removed without a good reason. /rolf ___ 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
Rolf E. Sonneveld wrote: Although DKIM does not specify (as far as I know) what to do with DKIM signatures in inner bodyparts, I think DKIM signatures should never be removed without a good reason. If you believe this, then you have to advocate the removal of the RFC 4871 mandate regarding invalid signatures changing to no-signature status as if it never existed and the message was never signed. What this means is that if a MLM keeps broken tracings of signatures, the only existing trace signature is the valid one. All others must be ignored. -- 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] Mailing lists and s/mime dkim signatures - mua considerations
Dave, The term Reputation Filtering Engines (RFE) is understood in what it means. Currently proprietary solutions. Absolutely wrong with that. But if you are saying this include policy or more specifically the IETF DKIM Working Group work item RFC 5617, this I don't see a problem in your statement other to remind you RFC 5617 is not about reputation. Certainly a RFE vendor may incorporate RFC 5717 and this should be made public. Maybe it might help to change your usage of Reputation Filtering Engines to a more general concept such as Validation Assignment Engines (VAE). DKIM's main purpose is assessment by Validation Filtering Engines. These VFE include the proposed IETF WG standard such as RFC 5717, which has to mentioned first over anything else, and those seen in practice with SSA (Special Signing Arrangements) and Reputation - both non-standard approaches. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Dave CROCKER wrote: On 8/24/2010 10:43 AM, MH Michael Hammer (5304) wrote: One can assess based on policy rather than reputation. In fact I can think of several companies that popped up recently in this general space (email authentication) to do just that. That sounds as if the primary concern was with my use of the word 'reputation'. Whereas I normally use the word assessment, because it is less loaded with semantic baggage, I chose the much more popular term reputation as the generic label. I'm not happy that's the publicly preferred term, but it is. And the way average folk use it, it covers everything, including policy. So if the real issue is with being more precise and differential, I'm certainly fine with that. Again, please suggest alternative language for the text used. Not just specific vocabulary comments, but replacement sentences. Absolutely. Primary as you used it has a very specific meaning. or are we introducing fuzzy logic to the world of standards development and implementation? As for my use of 'reputation', that's a convenient label that is popularly used to refer to an assessment phase. Reputation is one subset of the possible implementations of assessment. So, indeed, it appears the disconnect was between popular usage and more precise technical usage. At the level my note was working,I meant the former. Perhaps the question should be: If you are that uncomfortable with the language I used, what alternative language would you offer. Having that would allow some best-fit comparison. I am quite comfortable with what Wietse wrote. I was going to respond to his post with a +1 for each of his points. In terms of specifying constraints on a receiver, his language is accurate: DKIM does not constrain usage. However my comment was about intent and the intent of DKIM was to design a replacement for using IP Addresses in anti-spam efforts, which means filtering engines. popular does not equal primary. By some popular measures, it does. Careful for what you ask for. If we are going to reduce this to simply a popularity contest. That's what rough consensus is, in socio-politico terms. I'll assume that it's too early in the day for you to have started drinking, so I'll have to admit to confusion about this exchange. If it's just to take shots at me, while I readily acknowledge my convenience as a target, that's better done offline. If it is for a constructive purpose, such as improving group understanding about DKIM, please suggest superior language. I am content to leave it as email authentication, including DKIM is a useful and good thing. The more that DKIM signing is implemented, the greater the opportunity for receivers/evaluators to do useful things. Whereas I believe the term authentication has proven highly misleading. It's a labeling technology, where the authentication of the label is actually secondary to the presence of the assertion of the label. And the key aspect of that secondary point is that the only thing being authenticated is the label. If reputation floats your boat then knock your socks off. I seem to remember a venerable member of this list floating a proposal that wasn't supposed to compete with reputation. AffiL or something or other. Again, I used 'reputation' as a synonym for 'assessment' and Affil certainly conforms to that. If you want to deride usage of reputation in that way, complain to the bulk of the anti-spam community, not me. requires my acknowledging that I never view my opinion as humble. Aw, I stand corrected. Humble or not your opinions are always interesting and valuable wow. I thought you knew me better than that... Second, you appear to be seeking to enforce a linguistic etiquette for the list that is exceptional. Possibly a good idea, but certainly not well- established. Exceptional? I think not but I'm too busy at
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
Hector Santos wrote: Dave, The term Reputation Filtering Engines (RFE) is understood in what it means. Currently proprietary solutions. Absolutely wrong with that. Sorry, missing word - Absolutely NOTHING wrong with that -- 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] Mailing lists and s/mime dkim signatures - mua considerations
On 8/21/2010 6:06 PM, Daniel Black wrote: Taking an approach saying we don't care if DKIM survives MLMs is a step in the opposite direction. This is not a proposal I support. Not really, since it was known from the start that survival through an MLM is highly problematic and the steps towards helping survival were known to be quite limited. Requiring survival is a change in DKIM's goals, as well as raising a massive barrier to adoption, given the history of a) challenge in adoption for any infrastructure sequence, and b) resistance by MLM developers and operators. In other words, this line of efforts is seeking to raise the requirements for DKIM. Absent compelling and demonstrated functional need, that makes it at best a distraction and at worst counter-productive for DKIM's main purpose. DKIM's main purpose is assessment by reputation filtering engines. The most important reputations to assess are the entities that are 'responsible' for message. An MLM creates the message. That the message might look a lot like one sent /to/ it is nice, but it's also confusing. The original author is not, ultimately, responsible for what the MLM chooses to send. S/MIME already does that, with a suitable pointer. S/MIME was design to protect body content, not an entire message. All of this prompts a repeat of an underlying question: What is the purpose of this exercise and how is it justified within the charter? With respect to MLMs, I thought the focus was on documenting realities and passing through MLMs and to explore issues and opportunities better integrate MLMs into DKIM. That's quite different from trying to alter the core DKIM capability to support survival through MLMs. I'm pretty sure that changing DKIM Core is not within our charter. As for MUA considerations, anyone making claims about what is needed for utility in an MUA needs to cite their sources, providing empirical justification, not merely mathematical logic for why utility ought to be improved. 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] Mailing lists and s/mime dkim signatures - mua considerations
Daniel Black wrote: So I suggest we update the DKIM MLM draft to take out all the stuff about signatures surviving lists, and just say that if it's important for your signature to survive, The DKIM standard has gone a long way to ensure interoperatibility and the ability to survive canonicalisation changes, header field additions and is careful about which header fields are recommended for signing purely based on survivability. Taking an approach saying we don't care if DKIM survives MLMs is a step in the opposite direction. This is not a proposal I support. I know this is background noise, but I have no interest in restoring broken signatures or passing on ones we broke. Aren't people tired of dealing with iffy iffy mail? If so, why contribute to it with even more iffy iffy mail? Maybe we should come up with a new idea called DKIM Amplifiers (DKIM-AMP) whose purpose is to restore the signal strength of DKIM signatures from hop to hop, from resigner to resigner. Maybe we should have a new DKIM-PREDICT, whose purpose it allow the source point to create a PREDICTED PATH header on how mail will travel. DKIM-PREDICT learns by looking at Received lines and sending feedback to the source point, providing tips on the ORCP (OBSERVED RECEIVED COMMON PATH). Maybe we should have a new DKIM-FUZZY, whose purpose is to allow for non TRUE or FALSE conditions or MAYBES, wait, we already have a DKIM-FUZZY framework. :) Seriously, this stuff is really complex - anyone who says this is easy stuff to implement, well Sure it is easy to sign - if you don't care what was there to be begin with. Sure it is also easy to verify - but what is the end result of that? A continuation of iffy iffy mail world with the biggest beneficiaries - the BAD GUYS who will continue to do nothing to remain in a iffy iffy mail world. Again, just background noise. :) -- 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] Mailing lists and s/mime dkim signatures - mua considerations
At a conceptual level how the MUA shows validity information is important going by John's descriptions. In the quick illistration here S/MIME sometimes works and sometimes doesn't. Enhancing the MUA display with DKIM validity information could be an important differenciator for an end user. Based on the copies of the messages that come back here, the signatures are fine (other than the one I didn't sign in the first place) and the failure to show the signature is due to bugs in user MUA's S/MIME code. S/MIME has been around for a decade, and I've been a little surprised to find that the support in MUAs is so buggy once you get beyond the simplest cases. Why would you expect DKIM support to be any better? If this is important, wouldn't it be a lot quicker to file S/MIME bug reports (or for open source, bug fixes) with the MUA maintainers? The DKIM standard has gone a long way to ensure interoperatibility and the ability to survive canonicalisation changes, header field additions and is careful about which header fields are recommended for signing purely based on survivability. Taking an approach saying we don't care if DKIM survives MLMs is a step in the opposite direction. This is not a proposal I support. I'm sorry, this gets the history wrong. We had a lot of arguments about this when we were doing 4871, and I believe you will find that we added l= over substantial opposition under the theory that it would compensate for a significant fraction of MLM modifications. I think we now have found that was overoptimistic. The right thing to do is to deprecate l=, not make more mistakes. S/MIME already does that, with a suitable pointer. Not always. If S/MIME had a wider adoption perhaps DKIM wouldn't be needed. Either way S/MIME hasn't got a wide adoption yet ... Um, every popular MUA for Windows, Mac, Linux, FreeBSD, and so forth, supports S/MIME, including Kmail. I'm still trying to figure out why people who think it's important for list subscribers to verify the identity of contributors aren't using it. It took me about 15 minutes to get Usertrust to generate keys (no charge for individuals) and install them into my three MUAs. R's, John smime.p7s Description: S/MIME Cryptographic Signature ___ 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
John R. Levine wrote: I'm sorry, this gets the history wrong. We had a lot of arguments about this when we were doing 4871, and I believe you will find that we added l= over substantial opposition under the theory that it would compensate for a significant fraction of MLM modifications. I think we now have found that was overoptimistic. The right thing to do is to deprecate l=, not make more mistakes. This is, as usual, shamelessly wrong. We showed that over 90% of mlm signatures could be verified. Real life data, from a large company's mail stream. You have no data other than blatant assertions. Mike ___ 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
Michael Thomas wrote: We showed that over 90% of mlm signatures could be verified. Any insight, breakdown or feel for that 10% failure? Multiple hops for downlinks? More resigners, buggy DKIM verifiers? Was these all DKIM or did it include DKEY? -- 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] Mailing lists and s/mime dkim signatures - mua considerations
On Monday 23 August 2010 02:18:25 you wrote: At a conceptual level how the MUA shows validity information is important going by John's descriptions. In the quick illistration here S/MIME sometimes works and sometimes doesn't. Enhancing the MUA display with DKIM validity information could be an important differenciator for an end user. Based on the copies of the messages that come back here, the signatures are fine (other than the one I didn't sign in the first place) and the failure to show the signature is due to bugs in user MUA's S/MIME code. S/MIME has been around for a decade, and I've been a little surprised to find that the support in MUAs is so buggy once you get beyond the simplest cases. Looking at this list of RFC's required to implement it I'm not surprised (http://tools.ietf.org/wg/smime/). Why would you expect DKIM support to be any better? The DKIM interoperability report boasts how well everyone implemented it and only a few misreadings of the spec needed to be corrected. Alternately processing an Authenticated-Results header of course is a lot easier. If this is important, wouldn't it be a lot quicker to file S/MIME bug reports (or for open source, bug fixes) with the MUA maintainers? Wouldn't it be easy to add DKIM support to a few opensource MLMs and have the option of DKIM-Friendlyness available to all? Same economy of effort and much more relevant to the DKIM WG. The DKIM standard has gone a long way to ensure interoperatibility and the ability to survive canonicalisation changes, header field additions and is careful about which header fields are recommended for signing purely based on survivability. Taking an approach saying we don't care if DKIM survives MLMs is a step in the opposite direction. This is not a proposal I support. I'm sorry, this gets the history wrong. We had a lot of arguments about this when we were doing 4871, and I believe you will find that we added l= over substantial opposition under the theory that it would compensate for a significant fraction of MLM modifications. I think we now have found that was overoptimistic. The right thing to do is to deprecate l=, not make more mistakes. (Answered by Michael) S/MIME already does that, with a suitable pointer. Not always. If S/MIME had a wider adoption perhaps DKIM wouldn't be needed. Either way S/MIME hasn't got a wide adoption yet ... Um, every popular MUA for Windows, Mac, Linux, FreeBSD, and so forth, supports S/MIME, including Kmail. I'm still trying to figure out why people who think it's important for list subscribers to verify the identity of contributors aren't using it. John hasn't listened to the previous explanations and I'm not going to make this working group suffer endless reiterations of the same opinion again - there is far too much of that immature behaviour here already. It took me about 15 minutes to get Usertrust to generate keys (no charge for individuals) and install them into my three MUAs. To correct blatant assertion #2 adoption had to do with the number of users who elect to use the SMIME MUA support which is totally unrelated to how materially easy John, Dick or Harry found to use it. ___ 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
l= over substantial opposition under the theory that it would compensate for a significant fraction of MLM modifications. I think we now have found that was overoptimistic. The right thing to do is to deprecate l=, not make more mistakes. This is, as usual, shamelessly wrong. We showed that over 90% of mlm signatures could be verified. Real life data, from a large company's mail stream. You have no data other than blatant assertions. Hmmn. Unless I have misread previous mail, this verification process involved a variety of heuristics unrelated to RFC 4871 such as replacing the headers with stuff derived from the z= tag and guessing that strings in the subject line might be tags added by the MLM. There's nothing wrong with doing that for your private use, but it's not DKIM. R's, John ___ 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
Date: Fri, 20 Aug 2010 23:27:05 -0400 (EDT) We've had a lot of arguments about the importance of verifying the identity of contributors to mailing lists. If you think that's important, take a look at this message. Even though Mailman has added a subject line tag and a message footer, the S/MIME signature still verifies It was going well until Date: 21 Aug 2010 16:59:08 -0400 when the message of John's failed to verify. So 25% failed. , and your MUA should show a green star or whatever, at least once you've told it to import my S/MIME cert. Mailman automagically wrapped the multipart/signed in multipart/mixed. And the signing cert has both my full e-mail address and my True Name. At a conceptual level how the MUA shows validity information is important going by John's descriptions. In the quick illistration here S/MIME sometimes works and sometimes doesn't. Enhancing the MUA display with DKIM validity information could be an important differenciator for an end user. So I suggest we update the DKIM MLM draft to take out all the stuff about signatures surviving lists, and just say that if it's important for your signature to survive, The DKIM standard has gone a long way to ensure interoperatibility and the ability to survive canonicalisation changes, header field additions and is careful about which header fields are recommended for signing purely based on survivability. Taking an approach saying we don't care if DKIM survives MLMs is a step in the opposite direction. This is not a proposal I support. S/MIME already does that, with a suitable pointer. Not always. If S/MIME had a wider adoption perhaps DKIM wouldn't be needed. Either way S/MIME hasn't got a wide adoption yet so abandoning guidance for DKIM-Friendly lists seems premature especially if the hope in an takeoff in S/MIME adoption after all its years of existance. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
