On Wed, 2004-10-27 at 16:05 -0700, Dave Crocker wrote:
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.
The vast majority of these are just a few lines of addition, if
anything. Or for non-mailing lists, the mail could be resubmitted with
Resent-{From,To,...} headers.
While I agree that the recipient _can_ make an infinite array of
modifications to the original message while still sending it onwards
with the original From: header, I wouldn't agree that the recipient
_does_ explore that infinite array very much.
And in the case of resubmission of modified messages with the same
RFC2821 MAIL FROM address, the number of instances is even fewer.
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.
I don't want to be robust against "some". I want to be robust against
"most". In particular, I want the number of failures to be negligible in
practice, such that it outweighs the benefits of the scheme.
The difference between handling a few lines of addition to a message,
and the signature breaking on normal mailing lists, is a difference
which is going have a _huge_ impact on adoption, IMHO.
This means in practice that we need to either sign based on RFC2821
identities, or handle those few lines of addition which many mailing
lists add.
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.
Compare and contrast: "The reality is that the forwarding host has the
latest responsibility for injecting the message into the transfer
service. The fact that it takes a previous message that was created by
someone else, and yes, even the fact that they retain the reverse-path
does not make the forwarded less responsible for the content.".
I completely disagree with both statements.
If you receive a mail from a mailing list which purports to come from
me, you ought to be able to check for my signature on it. The mailing
list probably doesn't check for the signature anyway, and I don't want
you to be accepting fake mail just because the _list server_ accepted it
and signed it for itself. This is supposed to be an end-to-end scheme,
surely?
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"
I mean the added complexity of using RFC2822 addresses, because I
believe that implies the requirement to handle a small amount of content
mangling.
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.
I don't see the ambiguity. You receive a mail with different Sender:,
From:, and Resent-From: addresses. It's signed by all three, and you
know therefore that it's genuine -- and that the owner of the mailbox
specified in the Resent-From: header didn't just make it all up.
--
dwmw2