TLS for SMTP is a nice, efficient way to encrypt the channel. However, it offers little or no assurance that your mail will *stay* encrypted all the way to the recipients.It *is* happening, only it's now called STARTTLS (and if certain vendors (Micromumblemumble) didn't make it such a pain to set up certs for their MTAs but simply generated self-signed certs on install and turned it on by default, it'd be happening even more).
Most of us (including me most of the time) are in the position of using their ISPs or Employer's smarthost to relay email to its final destination; in fact, most employers (and many ISPs) actually enforce this, redirecting or blocking port 25 traffic.
If my employer or isp accept TLS traffic from me, but then turn around and send that completely unprotected to my final recipient, I have no way of preventing or even knowing that.
Sendmail's documentation certainly used to warn this was the case - probably still does :)
Agreed. In cases of spoofing, there could of course be an issue - but lets be honest here; when was the last time a mailing list regular *anywhere* lost reputation because someone posted spam or trollishness to the list in their name?How many messages to the Cryptography Mailing List are cryptographically signed?The S/MIME list debated this some time ago, and decided (pretty much unanimously) against it, for two reasosn. Firstly, because it adds huge ugly blobs of base64 crap to each message (and before the ECC fans leap in here, that still adds small ugly blobs of base64 crap to each message). Secondly, because if you get a message from someone you know you'll be able to get a pretty good idea of its authenticity from the content (for example an SSH developer would be unlikely to be advocating SSL in a list posting), and if you get a message from someone you don't know then it's pretty much irrelevant whether it's signed or not. So the consensus was not to sign messages.
I am not saying that doesn't happen - but it is rare, and usually the real poster points out the difference in header data that would indicate that email came from a source other than him.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
