On Wed, 2004-12-01 at 15:22, David Woodhouse wrote:
We ought to have senders publish _facts_ about the mail they send, which
can be interpreted by the sender. IIM's message-digest with length
achieves this -- it's up to the recipient to decide whether to accept a
munged mail.
In fact, I'm rapidly coming to the conclusion that we shouldn't bother
trying to make it survive mailing lists. An RFC2822 scheme can
authenticate the most _recent_ RFC2822 source address, be that the From
address, Sender, Resent-From or Resent-Sender. There's no point in
trying to make it survive further than that.
Rather than waging a battle over how robust a signature should be, by
allowing a message-state header that describes the message content to
detect what has been damaged could easily serve two very legitimate
purposes. One being the detection as to what is being damaged within
the message, the other would be to allow a more discerning means for
rejecting a message on the basis of a signature failure. Let the market
decide how this gets used.
Something like- (see: rfc2822 & rfc2045/6/7)
H0 := "RECEIVED"
H1 := "MESSAGE-ID"
H2 := "FROM"
H3 := "REPLY-TO"
H4 := "SUBJECT"
H5 := "DATE"
H6 := "TO"
H7 := "CC"
H8 := "CONTENT-TYPE"
H9 := "CONTENT-TRANSFER-ENCODING"
H10 := "MIME_VERSION"
H11 := "USER-AGENT"
H12 := "CONTENT-DISPOSITION"
H13 := "CONTENT-DESCRIPTION"
H14 := "ENCRYPTED"
H15 := "SENDER"
H16 := "RESENT-FROM"
H17 := "RESENT-SENDER"
H18 := "RESENT-DATE"
H19 := "RESET-TO"
H20 := "IN-REPLY-TO"
H21 := "RESENT-MESSAGE-ID"
H22 := "REFERENCES"
H23 := "CHAN-SIG"
H24 := "MD-VERIFY"
H25 := "PT-VERIFY"
P1 := Data Part 1
P2 := ...
Even something as simple as an Adler-32 and length of the various
headers and fields could look something like...
MSTATE: H0:abd1:201f, H1:8734:0023, H5:AF04:0045, H2:09AF:0024,
H11:0345:0041, X-ACCEPT-LANGUAGE:05AF:0036, H10:8765:001F,
H6:9903:010B, H4:9987:0123, H22:31AC:0098, H20:AFED:01AC,
P1:AFCD:ACDF
This provides an example of the concept for a message state header.
If there is a signature failure, this information should allow an
analysis to determine what changed and where. It does allow an
estimation of the damage done to the message when doing message triage
in deciding what to junk. Whether this latter function should be used
could be a matter of debate, but at least it should provide a useful
diagnostic tool.
-Doug