On Wed, 27 Oct 2004 23:46:33 +0100, David Woodhouse wrote:
That would be a scheme which is based on the RFC2821 address, and
hence doesn't _need_ to survive mailing list mangling. I suspect
that there is indeed a place in the world for such a scheme.
1. Mailing lists are merely one of a number of cases in which a
message that has been delivered to its specified recipient -- in this
case the mail list address -- is re-posted for delivery to others. The
original recipient can -- and does -- make an infinite array of
modifications to the original message, so there is no way a signature
can be robust against them all.
2. Once we start trying to be robust against only some, we are playing
a losing game. Even trying to guess all the things mailing lists do
is a losing game.
3. The reality is that the mailing list has the latest responsbility
for injecting the message into the transfer service. The fact that it
takes a previous message that was create by someone else and, yes,
even the fact that they retain the From and Subject and other tidbits
does not make the list processor less responsible for the content.
Getting signing to be done is a case of incremental adoption
throughout the Internet. We should keep the model as simple as we
can. I believe that means that signing should be done by the entity
that last injected into into the transfer service. MTA's are mere
relays, so they do not count. User agents count.
A scheme which accepts the added complexity of using the various
RFC2822 addresses should also be able to support multiple
signatures. It isn't _that_ much more complicated and it's useful.
First, what is the basis for such an assertion? I'm not exactly sure
what you mean about "added complexity of using various addresses" but
more importantly I do not see how that justifies added complexity for
additional features.
Having multiple signatures means having the recipient play with
ambiguities. Ambiguities impede interoperability.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com