Using GnuPG to encrypt automated system email

The root mailbox on most unixes can be an excellent source of various server health information. Unfortunately, sending these messages off-system, while convenient, poses the risk of disclosing sensitive system information. Suppose a system administrator receives an e-mail detailing missing patches on a system that is subsequently forwarded to a Gmail account. That message has not only traversed the Internet unprotected, it sits on Gmail's servers unencrypted. In addition, it may end up on a smartphone or laptop that could be lost or stolen.

The details of an implementation for protecting these messages with GNU Privacy Guard (GPG) is outlined below. GPG provides an easy way to send sensitive data across untrusted networks or to destinations that may have limited security controls. Look for more GPG tips from the DRG in the coming weeks and months!

A quick procmail recipe will empower us to do just that:

SUBJECT=`formail -xSubject:`
:0 c
|formail -I "" | gpg --trust-model always -ear "foo@example.org" | mail -s "$SUBJECT" foo@example.org

In case your procmail skills are a little rusty, let's walk through each line:

  • The first line utilizes the formail binary to extract the subject of the incoming message and assign it to the bash variable SUBJECT.
  • The second line creates a copy of the message that is used later in the recipe.
  • The third line filters on messages that contain "root" in the To: field.
  • The fourth line takes a copy of the message and pipes it through a series of command lines.
    • formail -I "" will give us the message body without any of the original headers. This output is then piped to gpg.
    • gpg then encrypts the message body. We utilize --trust-model always to prevent gpg about prompting for an untrusted public key. The -ear flags encrypt the message, create armored ascii output and utilize the specified e-mail address as the recepient.
    • Finally, the output from gpg is piped to the mail command to send to the remote e-mail address.

When implementing something similar, you'll want to keep a few things in mind.

  • Since the procmail recipe runs as the mailbox user, it is not wise to use the recipe on the root account. In fact, some MTAs will not let you pipe messages to commands that are run as UID 0 (this is the default configuration in exim4). It is best to forward root e-mail to a non-priveleged account for archiving and forwarding purposes. Use your /etc/aliases file to accomplish this.
  • Ensure that you have local mail delivery enabled for your root account and the non-priveleged account that is handling the forwarding otherwise procmail will never see the message to process it.
  • Procmail may not be enabled in your default MTA install. Enabling it should involve uncommenting a line or two in your MTA's configuration file.
  • Finally, it should go without saying, but make sure the non-privelged account that does your forwarding has the proper public key in its keyring. If it doesn't, the procmail recipe will fail silently, leaving you scratching your head and digging through logs.

DRG loves to hear from the community. If you have any feedback, enhancements or fixes, drop us an e-mail or ping us on twitter.

posted at 12:00 am | permanent link

About DRG

Apply to DRG

Host a DRG Distro Pod

Insight & Analysis


Weekend Reads


Security Innovation Grant

Mailing lists

DRG PGP public key

Follow us on Twitter Follow DragonResearch on Twitter

Feedback: dragon@dragonresearchgroup.org