2

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.

user2626702
  • 113
  • 2
  • 2
  • 9

1 Answers1

1

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.

tripleee
  • 1,416
  • 3
  • 15
  • 24
  • 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 00:57
  • Iterate over the array and `print` each item, or simply `print(join("",@{$arrayref}))`. – tripleee Sep 10 '13 at 04: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
  • 1
    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
  • I've checked the /var/mail/user file and it seems that procmail attaches the decrypted text at the end of the file without any email header. But what is a ideal procmail rule to decrypt the message and attach it to the mail file with the header so that the email will be delivered normally? – user2626702 Sep 10 '13 at 20:28
  • See above. But also fix the `decrypt.pl` script to pass through message headers and MIME headers. – tripleee Sep 10 '13 at 20:34
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/10543/discussion-between-tripleee-and-user2626702) – tripleee Sep 10 '13 at 20:34