On Wed, 2004-02-25 at 09:59 -0800, Justin Mason wrote:
This added because DK hashes the message body, and some mailing list
software (MailMan for example, or this list) modifies the body,
which will cause DK failures.
Mailing lists don't mangle the body _much_ though.
Imagine a scheme where you generate and sign a tuple of
{ <number of original lines>, <cheap rolling checksum>, <hash> }
On verification you take the first N lines of the body, calculate the
checksum. If it doesn't match, you add the next line into the checksum,
and remove the first (that's why it's this type of checksum, so that's
nice and easy). When you get a match on the cheaper checksum, you check
the strong hash. If that fails, keep looking for a checksum match.
In this way you handle crap being added at the beginning and the end of
the mail. You just get to make a local policy decision about how _much_
crap you'll tolerate, that's all.
You can possibly even handle existing mailing lists stripping entire
MIME parts too, if you sign each part separately.
I envisage a scheme where such parts (and important headers like Date:
and Message-Id:) can be signed by any or all of the Sender:, From:, and
Resent-Sender:s, each of whom may have published records which state
that they'll always do this.
Even 'bouncing' (to use the pine/mutt form of the term) of such mail
should be able to survive. The From: and/or Sender: signatures will
still be present; the Resent-Sender: wasn't claiming to have added such
signatures (else they'd have done so).
Slightly more detail, although I don't claim it's yet formulated into a
fully comprehensive and implementable plan, can be seen at
http://lists.infradead.org/pipermail/sender-auth/2004-February/000015.html
--
dwmw2