> 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.
I don't mind if we find a way for MTAs to sign received fields (or
provide similar functionality in another way). I just hope we can avoid
needing to do this in order to provide sender non-repudiation and
tracing of messagesto their source.
> 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:.
Okay, I can almost make a case for the Date field being a part of the
content (IFF it's generated by the sender's MUA at the time of message
composition). I have a harder time making the case for including
message-id, because the content is (or isn't) spam independent of what
the message-id is, and message-ids do sometimes get changed in transit.
basically I'd like to include as little as we can get away with while
still identifying the content.
> 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.
That would be nice if we could do it, and if I thought we could do it in
a reasonable amount of time, I'd agree with you. But I think it would
be easier to replace the entire mail system with something different
than to change the behavior of so many existing tools that don't treat
an embedded message the same as they treat one that isn't embedded.
Which is another way of saying that even though I think it's a desirable
end-state, this particular approach would take a decade or more to deploy.
And I don't think we can afford to wait that long.