The server side of doing this is easy. The client side (both MUA and user :) may not be.
I suggest doing the encryption at the MTA rather than at the injection. Use the same methods the various anti-virus, anti-spam, et al systems do to interact with your MTA. That may be milters for sendmail or postfix, a content-filter, or something else. Have your filter encrypt each mail which is to be locally delivered to the recipient's public key. This will be agnostic to IMAP, POP or any other delivery mechanism. Then, you have to configure the users' MUAs to support the PK system you chose (s/mime and openpgp are the obvious options) and train your users to enter their secret key's passphrase to read their mail. It would help to have some type of agent or keymanager running, if the MUA doesn't itself have such support, to save the users from having to enter the passphrase for each mail. You might also want to look into a smart card solution, where the key is on the card rather than on the workstation. There are some which have the USB keydrive form factor, but most look like flash card readers. You also can choose to encrypt only locally originated mail. Having the decryption done on the workstation, even if the encryption is done on a server, may not be what you -- or your CEO and CFO -- were envisioning, but it can be done with relative ease. To have the IMAP server do the decryption is also possible. The passphrase for the secret key would have to match the IMAP password, and you'd have to pass it in the clear (as in LOGIN "user" "pass") so that the daemon could use it to access the secret key. And while it may be enough security to cover your stated threat model (simple curiosity), it is only mildly secure, and could lead to future problems were the users to start relying on it to be really secure. (The false sense of security problem.) Hacking dbmail's imapd to support that shouldn't be *too* difficult. But I'd still do the encryption at the MTA. The important thing to keep in mind when ecrypting on the server is that you can't be certain that there isn't a backchannel or other munging which would make it easier to brute-force to resulting cypher text. A classic attack is to reduce the entropy used to create the session key (most pki schemes create a random session key, use that with a symmetric cypher such as AES to encrypt the document, and then encrypt just the session key with the PK algorithm; this is done because RSA et al are *slow* compared to AES et al) which significanly reduces the time and effort required to recover the session key. Again, if your threat model is just to avoid the curious, that isn't a problem. But you have to make sure your management understands that they can't go out and claim their email is secure against threats like corporate or government espionage. Or even disgruntled (ex-)employees. And, finally, you may want to invest in some kind of true random number generator for the server to be sure you don't deplete /dev/random and DOS the incoming mail. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
