Debian – Decrypt incoming pgp mail with procmail

debianpgpprocmail

Currently I have a running Postfix server which delivers incoming mail through procmail. That works fine but now I want to decrypt any incoming mail which is encrypted with pgp automatically. So I have created a procmail rule to trigger gnupg.

This is my current .procmailrc:

:0 fw
* ^Subject: encryptme
| /usr/bin/gpg --decrypt | mail -s "ENCRYPTED: $subject" my@email.com

Now the mail is successfully decrypt and sent to my@email.com but with an empty subject (the mail only shows "ENCRYPTED: ") and with the email address of the server as the sender. And of course the decrypted mail contains parts of the email header.

Content-Type: multipart/mixed; boundary="713bkotRlnRGA7FAhJANoI0IsDpX3ws8N"

--713bkotRlnRGA7FAhJANoI0IsDpX3ws8N
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Just a test.

--713bkotRlnRGA7FAhJANoI0IsDpX3ws8N--

Is there any possibility to decrypt incoming mail this way automatically and "clean" (just the decrypted message) without additional software like GNU Anubis? And what is a good rule for procmail to trigger the program (insted of the subject)?

I hope this information is enough for somebody to help me.

Best Answer

In so many words, gpg --decrypt wants a file, not an email message. An email message typically consists of multiple MIME parts (your example shows a multipart/mixed with just a single body part, but the concept still holds), which are not files. You need to pass just the encrypted payload, not the MIME container, to gpg, or find a wrapper or option which helps gpg parse the MIME wrapper.

Quick googling turned up a simple Perl MIME wrapper which does this:

In case the link goes bad, reinventing the same wheel again should not be a significant challenge; you basically need to identify the MIME part which contains an encrypted payload, decode it (it's probably base64 encoded, unless it uses gpg's own "ASCII armor"), and pass it to gpg. The existence of an encrypted payload is probably a good trigger, but perhaps the wrapper should simply pass through anything which doesn't contain an encrypted payload, and you would feed everything to the wrapper.

Tangentially, there is nothing which defines $subject in Procmail or in your rules. You can do something like this:

:0
* ^Subject:[    ]\/[^   ].*
{ subject=$MATCH }

... where the whitespace between the square brackets should be a space and a tab.

Related Topic