Perhaps there exists a way to combine mail trace field with dns
(in part to reduce size of the has hash necessary for email).
The way it could work is that public key is available for verification
from dns (this must include version information allowing company to
use multiple keys at the same time when moving from one to another or
just when its convinient, i.e. when it has multiple servers). This public
key can be used to verify the private verificaion id embedded in the email
as well as parameters of the actual email as it was being processed.
My thinking is that good parameters for hash are RCPT TO and MAIL FROM,
date and message id (unfortunetly RCPT TO can have multiple addresses in
fact it can be very long list with current SMTP standard).
The best would actually be if this could be done as part of "Received"
information where each mail server on the way could add additional
"Received" header and this header would be in such standard format as to
be easily parsed by automated systems, something like:
Received: FROM above.proper.com (above.proper.com [208.184.76.39])
BY sokol.elan.net (8.12.5/8.12.5)
FOR william(_at_)elan(_dot_)net ENVELOPE-FROM
owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org
SENT-ON 200301191237 MESSAGE-ID i0JIT3lQ001354
VERIFY-DSN key-name#mail.imc.org BY-USING algorithm-name
VERIFICATION-ID xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The systems concerned about message origin and its path would then use
the known parameters of the message already included in the received
header (FOR, FROM, MESSAGE-ID) and VERIFICATION-ID and use algorithm
specified (this should perhaps be embedded as part of verification-id)
and check if such verification id could only have been created by somebody
who used private key which corresponds to public key available from
VERIFY-DSN location. I'm however concerned that standard X.509 or similar
algorithms would create and ID that is too long, but 2-4 lines as specified
above is probably ok which gives us up to 256 bytes. Another thing to be
concerned about is how quickly (and how much cpu resources are needed)
when creating such verification ids and when verifiying them.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net