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