Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

1 Answer 1

up vote 0 down vote accepted

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.

share|improve this answer
    
Thank you, I have setup the refered script and incoming emails with the target subject will be processed by the script. But the problem is that those emails never arrive at my inbox. I've successfully installed all modules and there are no errors in the logfile. I think the reason is that the script return an array (as noted in the README). What should change in the script to get the plain output as a string which can be delivered to my inbox instead of an array? –  user2626702 Sep 10 '13 at 0:57
    
Iterate over the array and print each item, or simply print(join("",@{$arrayref})). –  tripleee Sep 10 '13 at 4:02
    
With the test snippet cat encrypted_email.eml | ./decrypt.pl the script works fine like expected. But if I put all together in a procmail rule which is also described in the README, the email never arrives at my inbox but the procmail log shows some interesting thing: With normal mails the log is like the following Folder: /var/mail/myuser but with the script the line looks like this Folder: /home/myuser/decrypt.pl. Could there maybe the last problem, that the mail is delivered to the wrong file? And how could I fix it? –  user2626702 Sep 10 '13 at 15:46
    
If your recipe lacks a pipe character, Procmail will use the file as an mbox folder, and append to the end of it. Make sure you use the correct syntax. –  tripleee Sep 10 '13 at 19:19
    
However, you should probably use a filtering recipe instead, i.e. :0fw -- a delivering recipe which fails to actually deliver the message anywhere will cause that message to be lost. –  tripleee Sep 10 '13 at 19:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.