Update
While the original post below correctly explains why you might want to use separate encryption and signing keys, it does not do a great job answering the question of why you use subkeys instead of the primary key. The Debian Wiki provides a much more thorough answer.
To summarize, your primary key is your online identity, and your identity and reputation are built up by having other people vouch for that key being yours by signing it themselves. (You might think of it like being your Twitter handle, and your reputation being your Twitter followers, or you might object to that analogy, but I hope it gives you some sense of why you want to protect it.) So, since your primary key is super important and is built up over years, you want to protect it very much. In particular, you do not want to store it on a computer that might get stolen or hacked into; you want to keep your primary key off-line in a safe place.
This, of course, makes your primary key very inconvenient to use. So for day-to-day operations you want to use a key that is not such a big problem to replace if it gets compromised. This is why subkeys were invented.
A subkey is still a public/private key pair and is secure as long as only you have the private key. It is, cryptographically, just as secure as your primary key. The difference is that your reputation is only attached to it by your own signature, the signature from your private key. To use the Twitter analogy, the world trusts that you are your Twitter handle because all your followers say so (I know, it doesn't always really work that way, but analogies are hard!), and then with that trust established you can then much more easily convince the world you own your Instagram handle by just tweeting it and people will believe you because the tweet came from your account, which they trust.
You still want to keep your subkey safe, but now if it is compromised it is not the huge problem it would be if your primary key were compromised (or, in the analogy, someone hijacked your Twitter account). Now you can just revoke the subkey and issue a new one by signing a revocation certificate and a new subkey and posting them both on your public keyring (like tweeting "hey, my Instagram handle changed, don't use the old one, use this one instead"). This makes keeping your subkey on your laptop computer a more acceptable risk than keeping your primary key on it.
TL;DR Subkeys make key management much easier by separating the cryptographic functions of public keys from the trust and identity functions of (primary) public keys.
Original post
If you look into the details of the math of public-key encryption, you will discover that signing and decrypting are actually identical operations. Thus in a naïve implementation it is possible to trick somebody into decrypting a message by asking them to sign it.
Several things are done in practice to guard against this. The most obvious is that you never sign an actual message, instead you sign a secure hash of the message. Less obviously, but just to be extra safe, you use different keys for signing and encrypting. Also, keeping the encryption key separate allows you to keep the other arguably more important and definitely less frequently used keys off-line and more secure. That is the case with the keys you have inspected. By the way the flags mean:
- e = encrypt/decrypt (decrypt a message you received encrypted for you to read)
- s = sign (sign data. For example a file or to send signed e-mail)
- c = certify (sign another key, establishing a trust-relation)
- a = authentication (log in to SSH with a PGP key; this is relatively new usage)
Note that in all cases, "key", means a public & private key pair.
This should not be a problem for your friend if he has everything set up correctly, but setting up everything correctly can be more complex than it should be. So it may be that the best solution is for your friend to generate a new public-key that he uses for both signing and encrypting. Like I said, because the primary defense against attack is to only sign a cryptographically secure hash of a message, it is not a serious weakness to have such a key.
Best Answer
If you use Courier's
maildrop, and you have the full Courier package then you can use thexfiltermailfilter expression and Courier'smimegpgcommand (from thesqwebmailpackage):You can optionally add filtering to include/exclude specific emails, e.g. by sender, subject or those already containing encrypted parts (depending on how robust you want it to be, and how paranoid/cautious you are).
The delivery user must have access to the recipient public key(s), you may need to have a key server or a shared keyring.
LOGNAMEmay need some tweaking, in my preferred configuration it's a full email address rather than just the local part, so the above works for me.mimegpgpreserves the email headers, and encrypts the email part-wise. Each single part becomes a newmultipart/encryptedcontainer, with anapplication/pgp-encryptedstub part and anapplication/octet-streamASCII-armored payload. My email client and GPG plugin have no problems with this, some might however.I have also used
mimedefangto interface withgpg, this allows greater flexibility, but requires some non-trivial code.If you use postfix to deliver directly into a maildir, or you don't use
maildropas an MDA, this won't work for you. You may either set up postfix to usemaildrop, or perhaps do something similar withmimegpgand what ever you do use.