Getting rid of PGP in the mutt mailbox
In my paranoid view, whenever 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 Pete's neighbor, regardless of where he works - anywhere, with the provider, or in the special service.) For mail, this is PGP / GPG for IM it is OTR. But this encryption is designed to protect messages in the process of transmission over the network, and not on the screw in the mailbox / IM logs. There is no use to the screw from it, some troubles - slow search in messages (if in your MUA the search generally works in encrypted letters), inability to process the mailbox with simple scripts, etc. If there is a need to encrypt data on your screw, then for this there are other, more suitable and universal means than PGP for a part of the letters.
Since PGP is required only during transmission over the network, it would be an ideal solution to encrypt / decrypt messages at the time of reception / transmission, i.e. using a local POP3 / SMTP relay server. In this case, all mail clients (MUA) would automatically receive "PGP support", and at the same time they themselves did not know anything about PGP, and worked 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 motto of the mutt is not in vain “All mail clients suck. This one just sucks less. ”I managed with his flexibility, a small auxiliary script for qmail, and such and such a mother to solve this seemingly banal task.
It's all simple. Mutt is responsible for encrypting sent messages, as usual. Thus, I see / control which messages are encrypted and which are not. And in order for an unencrypted version of the sent message to remain in my mailbox, it is enough to add to ~ / .muttrc:
And here there are difficulties. In mutt, there is a decrypt-save function that correctly decrypts a letter (including attachments), saves the decrypted letter to the specified mailbox, and removes the encrypted original. (By the way, do not confuse it with decode-save, which does almost the same thing, only worse - at least it seems that it doesn’t support attachments. Interestingly, by default in mutt decode-save is hung on Esc + s, and the best decrypt-save not assigned to any combination of buttons.) With its help, you can create a hook that will automatically decrypt the message at the time of opening, replacing the encrypted version in the current box with an unencrypted version - add it to ~ / .muttrc:
then you write instead:
For reasons of paranoia, it would be necessary to add the deletion of possible GPGs in it: headers from incoming letters (so that no one could send you an unsigned letter on behalf of someone else’s name, in which he wrote that it was allegedly correctly signed). And for compatibility reasons, rename the GPG header: to X-GPG :. But this is the little things. In order for addgpginfo to work, it is necessary that you have gpg-agent running with the option - write-env-file, and running Xs ($ DISPLAY can be passed to it as a parameter if you don’t have ": 0").
')
The result looks like this:
Since PGP is required only during transmission over the network, it would be an ideal solution to encrypt / decrypt messages at the time of reception / transmission, i.e. using a local POP3 / SMTP relay server. In this case, all mail clients (MUA) would automatically receive "PGP support", and at the same time they themselves did not know anything about PGP, and worked 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 motto of the mutt is not in vain “All mail clients suck. This one just sucks less. ”I managed with his flexibility, a small auxiliary script for qmail, and such and such a mother to solve this seemingly banal task.
Sending letters
It's all simple. Mutt is responsible for encrypting sent messages, as usual. Thus, I see / control which messages are encrypted and which are not. And in order for an unencrypted version of the sent message to remain in my mailbox, it is enough to add to ~ / .muttrc:
set fcc_clear=yesReceive letters
And here there are difficulties. In mutt, there is a decrypt-save function that correctly decrypts a letter (including attachments), saves the decrypted letter to the specified mailbox, and removes the encrypted original. (By the way, do not confuse it with decode-save, which does almost the same thing, only worse - at least it seems that it doesn’t support attachments. Interestingly, by default in mutt decode-save is hung on Esc + s, and the best decrypt-save not assigned to any combination of buttons.) With its help, you can create a hook that will automatically decrypt the message at the time of opening, replacing the encrypted version in the current box with an unencrypted version - add it to ~ / .muttrc:
message-hook '~h"Content-Type: multipart/encrypted"' 'push <decrypt-save>\cu^<Enter><sync-mailbox><Enter>'
This approach has several features / disadvantages:- It is impossible to delete only one encrypted letter, so that at the moment of opening the encrypted letter, all the letters marked for deletion in this box are deleted, which can 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 box. If this encrypted letter was the only new letter, then everything will work perfectly - the next letter will be exactly his unencrypted copy, so that when entering this letter you will see it. If there were several new letters in the box, and all are 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, then entering the first encrypted letter you suddenly instead of it will open the first unencrypted.
- Unlike the Windows GPGrelay (which, when decrypted, can optionally add information to the letter that it was encrypted / signed), the decrypt-save function does not modify the letter in any way. Thus, after automatic decryption and deletion of the original letter, we will not be able to find out if it was encrypted and correctly signed.
./Maildir/then you write instead:
|addgpginfo qmail-local "$USER" "$HOME" "$LOCAL" "" "nodeliver" "$HOST" "$SENDER" ./Maildir/For reasons of paranoia, it would be necessary to add the deletion of possible GPGs in it: headers from incoming letters (so that no one could send you an unsigned letter on behalf of someone else’s name, in which he wrote that it was allegedly correctly signed). And for compatibility reasons, rename the GPG header: to X-GPG :. But this is the little things. In order for addgpginfo to work, it is necessary that you have gpg-agent running with the option - write-env-file, and running Xs ($ DISPLAY can be passed to it as a parameter if you don’t have ": 0").
')
The result looks like this:
Source: https://habr.com/ru/post/135800/
All Articles