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
