Andrew,
S/MIME is not a common building block in any significant
email program that deals with Internet email.
Except for Outlook and Mozilla based MUAs. That's a lot of
programs.
S/MIME and PGP are supported in a number of popular MUAs.
However as already noted, they have very little support in MTAs.
What is unfortunately more significant is how long those
technologies have been around and how little actual use they get.
By any reasonable measure of Internet scale, their *usage* levels
most definitely qualify as "niche".
This makes their applicability for this (new) requirement a long
way from being obvious.
How much is being handled by DK successfully?
You are asking how much, given that its initial specification has
been available for a few months and has not yet been published,
as opposed to a decade for PGP and 7 years for S/MIME?
The fact is that there are many S/MIME and PGP libraries
I think that the issue has less to do with an existence proof for
software than it does with a demonstration of adequacy in
satisfying Internet-scale market needs.
On the other hand the question "why not use s/mime or pgp?"
strikes me as being of fundamental benefit(!) to the current
effort.
The question forces us to be crystal clear about the core
requirements for satisfying the current problem.
To that end, at this stage, it does not help discussion for me to
say which technology I will "accept" or which technology I will
"refuse". It does not help discussion for *any* of us to utter
that sort of judgment, as if any one of us has a veto. We don't.
What we need is to focus on being very clear about the problem
statement and very clear about the functional, operational and
usability requirements.
If you don't believe in re-use, then perhaps we
should be talking about SMTPng or DNSng or IPv8.
Re-use is wonderful, when it is based on a solution that is
successful and sufficiently applicable.
Well, if you've got data or hard-core experience suggesting
that S/MIME (or PGP) will not work, let's hear it.
When one proposes a solution, the burden of proof rests with the
proposer.
d/