On Mon, 19 Jan 2004, Keith Moore wrote:
> If it's end-to-end, aka MUA <> sMTA <> rMTA <> MUA signatures are nice
> to have, but as I can trust my rMTA's Received: line about the sending
> MTA
> it is not of much additional information.
it's a moot point. it's much easier to make e2e sigs work than to make
hop-by-hop sigs work.
I don't think it's entirely moot. In the context of traceability it is
another tool worth exploring.
There is significant value in having each MTA add (conceptually as part
of a Received: header) a signature indicating it handled the message.
It does not have to be cumulative (although I would probably include the
signature of the prior hop in my signature calculation) nor does it have
to assert anything other than I handled the message and agree to be
accountable for having relayed it.
For example, this could be really useful for clients who trust their
delivering MTA. More generally it provides the basis for sites to
create reliable whitelists.
> I don't think it is an easy task to find information to add to the
> hash.
offhand:
- subject field (perhaps truncated to XX bytes)
- message body
- source IP address and port
- precise date/time (not the Date header field)
- *maybe* some form of the envelope recipient list
I would include both the Date: in the message and the local Date. I
would also add the Message-ID:.
> Adding the body of the email to the hash is also playing vabanque as
> e.g. mailing lists add trailers to the message and break the hash.
interesting point that. but if the body is the last thing to be
hashed you may be able to recheck the hash at every line boundary.
you might also have the id field include the number of bytes from
the body that are hashed.
All of this is why the object to be hashed needs to be pushed down a
level and treated opaquely by intermediate MTAs.
In the case of the adding of a trailer by mailing lists, the
"correction" is to have the technology add a body part with the trailer
information as opposed to modifying the body part.
Jim