automagically, using an environment variable (yuch, just a touch insecure?) or some other method (a root-owned and executed shell script).
I'm now working on a system (internal to each machine) which checks any mail to be sent for a signature (affixed by a mail front-end or by the user if he prefers to use the raw mail interface). This sig is produced by a key created my the system administrator solely for the purpose of verifying mail authenticity - any user who wants more security is still free to generate a separate key pair for encryption purposes. All that would be required is to sign the cyphertext with the "mail key" after encryption with whatever other key(s) the user wished to use. The mail sig has to be the last signature affixed to the message if it's to be stripped before sending (see below). The problem of key pass phrases is one I hadn't thought of yet. Remember that the "mail key" pair is not intended for any purpose beyond mail authentication. What if the private keys are stored in separate directories with rwx permissions for the individual user only? The keyring could be accessed by a mail program run by that user but not by anyone else (except uid 0), which is as secure as any UNIX system can hope for. Remember that uid 0 made the keys in the first place! The script which adds the sig wouldn't need a unique passphrase to sign with the "mail key". Of course, users' own private keys used for encryption would be protected in whatever manner they see fit, although (as beaten to death in another thread) keeping private keys on public machines is often a risky proposition. Once the system has verified that the mail submitted for transmittal does indeed have a valid sig, the sig could be stripped before sending. This would have absolutely no impact on other systems' mail, because all of the "sig, verify, strip" processes are confined to the user's machine. In fact, the mail recipient wouldn't even know this had occurred, ensuring proper use with remailers. All this system does is provide some reasonable protection for users against mail forgery originating from their own machine. My experiments with port 25 show that a telnet connection from a remote machine to port 25 causes the remote machine's address to appear in the ESMTP headers. However, mail sent from a local connection to port 25 can't be readily distinguished from mail sent via "normal" mail programs (mail, elm, pine, etc.). On the systems I've examined, I can enter a user's login through port 25 and sendmail will affix his real identity from /etc/passwd just as though that user had sent the mail. For instance, a user can forge mail from root on their own machine. I don't know about you, but that's something that concerns me. It's entirely possible that someone impersonating root could send email to a user to change his password as a "system test", giving the bad guy access to someone else's account. Admittedly, this is a pretty benign example, but the potential for real damage is there. It might well be that I'm overly concerned with something that really isn't a problem. However, the more I think about possible acts of "e-terrorism" which can be caused by convincingly forged email, the more concerned I become. If everybody knew how insecure mail really is and afforded it the proper amount of suspicion and distrust, this wouldn't be much of a problem (I don't know anybody who believes that "for a good time, call 555-XXXX" messages written in bathroom stalls were put there by the person who belongs to that phone number). However, I sense that many well meaning but largely uninformed people seem to think that email is secure, private, and inviolable. Given that level of trust, the possible consequences which might flow from convincingly forged email are significant. It's probably easier to fix the mail than attempt to educate the public, although I might well be wrong in that assessment. =D.C. Williams <dcwill@ee.unr.edu>