and it will take quite awhile for other sending software to
start signing, too. shall we try to compensate for them, too,
Please explain what you mean by 'other sending software'.
I meant it as a generic comment. There are millions of independent
components that will probably adopt this over time. Designing
something that hacks around a subset of them leaves us with a
long-term mechanism that is really only that -- a hack.
Again, what is special about mailing lists is that they are in
series with the message path.
You are conflating two logical layers. One is basic message transfer
from an originator to a recipient. The layer above that involves
human group communication, with quite a wide variety of scenarios.
Mailing lists instantiate only one, simple form of such
communications. We should avoid jerking around the lower-email layers
to handle that one case, no matter how wonderfully popular it is now.
If 'p1' represents the fraction of
messages that are signed, and 'p2' represents the fraction of
mailing lists that re-sign messages. In order to avoid damaging
the reputation of the mailing list, assume it only sends signed
messages when it receives a signed message.
This is really an excellent, additional demonstration of why we need
to view mailing lists as end-points for signing mechanisms:
mailing lists are going to have their own signing policies and we
need to avoid the confusion that will ensue from having multiple
authorities claiming responsibility for the message.
Let's remember that this mechanism is only concerned with basic
transfer across the net, rather than long-term, broad responsibility
for the content.
If we're able to get signed messages to pass through half of the
mailing lists, then this improves to p1*p2+p1*(1-p2)/2, or 12% in
I don't understand the context of this sort of numerical analysis.
How does it relate to the 1billion mail users we currently have and
their own adoption of the mechanism?
By the way, can you cite an example of a similar design and deployment
scheme for upgrading an application on the net?
what is significant about the current thread is the nature of
the analysis that needs to be done, to handle the changes a
mailing list can introduce into a previously-signed message.
internet standards that rely on these kinds of statistical and
case analyses make for complex, problematic implementation and
We are proposing no statistical analysis as part of IIM; you're
You just did it above and in general the discussion has talked about
working with "most" mailing lists. The word "most" is statistical.
making it sound like we're proposing something like Bayesian
I am making it sound like this entire line of effort is a hack to get
around a particular set of transition issues, rather than constituting
a clean mechanism for performing a necessary, core function.
I say "necessary, core function" because the track record of failure
with Internet security mechanisms and the need for working with a
very, very large installed base is normally taken to dictate that a
change be as small and simple as possible.
BTW, what about the canonicalization that is proposed in both IIM
and DK: do you advocate eliminating that as well?
If there were even the slightest chance of getting ANY utility out of
this, then yes I would. However the need for canonicalization -- and
the very serious difficulties with getting a satisfactory algorithm --
should serve as an example of the reason that "adjusting" to wildly
variant application behaviors is a very bad idea when designing an
"complex, probleman implementation and testing" is a code-
phrase for "difficult to adopt and make interoperate on large
anyone with internet-scale testing, deployment and use
experience to the contrary should speak up.
we probably have different experiences in getting successful internet
applications adoption, especially when changing a large installed
Again, disagree with the premise that this is complex. In calling
this problematic, you show that you have already made a judgement.
it is difficult to offer meaningful critical comments of something
without forming some judgements about it.
dcrocker a t ...