> > One thing that I'm not finding in the RFCs, but have read about > in general > > PKI articles, is the use of a signed digest rather than encrypting the > > entire message. > > Yeah, as long as you don't have to attach disclaims, unsubscribe > instructions, or ads on messages, this works.
Ah, but... (my ill thought out 2c coming up) the point of this thread is that the recipient MTA (not the end user) can authenticate the validity of the sender, if the sending MTA has signed the digest you (recipient MTA) can check the message by comparing the sig with the public key stored somewhere trustworthy, and check the message by comparing the digest, thus proving that the sending MTA really did handle the message and it hasn't been spoofed. If you (you're an MTA remember :-) pass the message on you must sign it yourself to validate it along the next hop. What happens is that each step can validate the upstream server to the downstream one, no-one has to work from 1st principles and the message isn't inviolable WRT changes of content or headers. The normal cut and thrust of work-a-day processing. It doesn't affect any user signing of the message, but you do have to trust your upstream server. One thing I'm keen on is the idea that you could accumulate a number of validation schemes, of which this would only be one, and perform a risk assessment on the combined results of more than one check. For instance we might compare the original sender's domain with the MX for the domain, we might ping it, we could perform a relay test, we can ask for certificates from it and check them, we could also check all the received headers against DNS and check each intermediate MTA, and look up the key it signed it's digest with, and we can use the last signed digest to ensure that the MTA we think is sending the message isn't being spoofed. Weighing all of that up we can arrive at a score for the likelyhood that this mail is really from Serge, even though it may fail some tests and pass others. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
