January 7, 2012 at 11:30Get rid of PGP in your mutt mailbox
- Tutorial
In my paranoid view, if possible, all communication by mail and IM should be encrypted. (Not because I have something to hide, but simply because I see no reason to show my messages to my neighbor Petya, regardless of where he works - anywhere, at the provider, or in the secret service.) For mail, this is PGP / GPG , for IM it is OTR. But this encryption is designed to protect messages during transmission over the network, and not on the screw in the mailbox / IM logs. There is no sense on the screw, some troubles are a slow search in messages (if your MUA search works in encrypted letters at all), inability to process the mailbox with simple scripts, etc. If there is a need to encrypt data on your screw, then there are other, more suitable and universal means for this than PGP for some letters.
Since PGP is only required during transmission over the network, it would be an ideal solution to encrypt / decrypt messages at the time of reception / transmission, i.e. using the local POP3 / SMTP relay server. In this case, all mail clients (MUA) would automatically receive “PGP support”, and they would not know anything about PGP, and would work with unencrypted emails. Under Windows there is such a server - GPGrelay . Under * NIX, I could not find an analogue. There is a kuvert utility that can automatically encrypt outgoing mail, but I did not find utilities for decrypting incoming mail.
But the mott motto is not in vain, “All mail clients suck. This one just sucks less. ”- I managed with the help of its flexibility, a small auxiliary script for qmail, and such and such a mother to solve this seemingly banal task.
With this, everything is simple. For encryption of emails sent, as usual, mutt is responsible. Thus, I see / control which messages are encrypted and which are not. And so that in my mailbox there is an unencrypted version of the sent message, just add to ~ / .muttrc:
And here there are difficulties. Mutt has a decrypt-save function that correctly decrypts the message (including with attachments), saves the decrypted message to the specified mailbox, and deletes the encrypted original. (By the way, do not confuse it with decode-save, which does almost the same thing, only worse - it doesn't seem to support attachments at least. Interestingly, by default in mutt decode-save is hung on Esc + s, and the best decrypt-save not assigned to any combination of buttons.) Using it, you can create a hook that will automatically decrypt the message at the time of opening, replacing the encrypted version with the unencrypted one in the current mailbox - add it to ~ / .muttrc: This approach has several features / disadvantages:
instead you write:
For reasons of paranoia, it would be necessary to add to it the removal of possible GPGs: headers from incoming letters (so that no one could send you an unsigned letter from someone else's name, in the headers of which saying that it was supposedly correctly signed). And for compatibility reasons, rename the GPG: header to X-GPG :. But these are trifles. For addgpginfo to work, it is necessary that you have gpg-agent running with the --write-env-file option, and running Xs ($ DISPLAY can be passed to it with a parameter if you don’t have ": 0").
The result looks something like this:
Since PGP is only required during transmission over the network, it would be an ideal solution to encrypt / decrypt messages at the time of reception / transmission, i.e. using the local POP3 / SMTP relay server. In this case, all mail clients (MUA) would automatically receive “PGP support”, and they would not know anything about PGP, and would work with unencrypted emails. Under Windows there is such a server - GPGrelay . Under * NIX, I could not find an analogue. There is a kuvert utility that can automatically encrypt outgoing mail, but I did not find utilities for decrypting incoming mail.
But the mott motto is not in vain, “All mail clients suck. This one just sucks less. ”- I managed with the help of its flexibility, a small auxiliary script for qmail, and such and such a mother to solve this seemingly banal task.
Sending letters
With this, everything is simple. For encryption of emails sent, as usual, mutt is responsible. Thus, I see / control which messages are encrypted and which are not. And so that in my mailbox there is an unencrypted version of the sent message, just add to ~ / .muttrc:
set fcc_clear=yesReceive emails
And here there are difficulties. Mutt has a decrypt-save function that correctly decrypts the message (including with attachments), saves the decrypted message to the specified mailbox, and deletes the encrypted original. (By the way, do not confuse it with decode-save, which does almost the same thing, only worse - it doesn't seem to support attachments at least. Interestingly, by default in mutt decode-save is hung on Esc + s, and the best decrypt-save not assigned to any combination of buttons.) Using it, you can create a hook that will automatically decrypt the message at the time of opening, replacing the encrypted version with the unencrypted one in the current mailbox - add it to ~ / .muttrc: This approach has several features / disadvantages:
message-hook '~h"Content-Type: multipart/encrypted"' 'push \cu^'
- You cannot delete only one encrypted letter, so when you open an encrypted letter, all messages marked for deletion in this mailbox are deleted, which may be an unpleasant surprise in some situations.
- As usual in mutt, at the time of marking the current letter for deletion, it proceeds to the next letter in this mailbox. If this encrypted letter was the only new letter, then everything will work perfectly - the next letter will turn out to be its non-encrypted copy, so when you enter this letter you will see it. If there were several new letters in the mailbox, and all were encrypted, then opening the first one will cause an avalanche of automatic transitions to the next letters with their automatic decryption, but outwardly everything will work as expected - as a result, the letter that you opened will open. But if among the new letters there are encrypted and not encrypted mixed ones, then entering the first encrypted letter you will unexpectedly have the first one not encrypted instead of it.
- Unlike the Windows GPGrelay (which, when decrypting, can optionally add information to the message that it was encrypted / signed), the decrypt-save function does not modify the message in any way. Thus, after the automatic decryption and deletion of the original letter, we won’t be able to find out if it was encrypted and correctly signed.
./Maildir/instead you write:
|addgpginfo qmail-local "$USER" "$HOME" "$LOCAL" "" "nodeliver" "$HOST" "$SENDER" ./Maildir/For reasons of paranoia, it would be necessary to add to it the removal of possible GPGs: headers from incoming letters (so that no one could send you an unsigned letter from someone else's name, in the headers of which saying that it was supposedly correctly signed). And for compatibility reasons, rename the GPG: header to X-GPG :. But these are trifles. For addgpginfo to work, it is necessary that you have gpg-agent running with the --write-env-file option, and running Xs ($ DISPLAY can be passed to it with a parameter if you don’t have ": 0").
The result looks something like this: