[neomutt-users] Full encryption with neomutt?

Chris Bennett cpb_neomutt at bennettconstruction.us
Thu Dec 30 13:24:17 CET 2021


On Wed, Dec 29, 2021 at 12:43:53PM +0000, moonmaillist at firemail.cc wrote:
> I am using neomutt for a long time, but I couldn't figure out a good way to
> use encryption (only if it is possible or needed).
> 
> The problem is, that neomutt tries to encrypt every email I write and if it
> doesn't find a key, it only gives me the message "No key found", but I can't
> send the email unencrypted (neomutt just blocks me from doing it). If
> encryption is deactivated, I can write emails to everyone, but can't
> activate encryption manually (if I know I own the public key of an
> recipient). In general, I have to close neomutt, change the config and start
> it again to activate encryption for one case.
> 
> The last lines of my gpg.conf look like this:
> ---
> set crypt_use_gpgme=yes
> # set crypt_autosign=yes
> # set crypt_verify_sig=yes
> # set crypt_replysign=yes
> set crypt_replyencrypt=yes
> # set crypt_replysignencrypted=yes
> 
> # uncomment next line to encrypt messages
> # set crypt_autoencrypt = yes
> 
> set pgp_use_gpg_agent = yes
> set pgp_check_gpg_decrypt_status_fd = yes
> # set pgp_check_gpg_decrypt_status_fd = no
> set pgp_auto_decode = yes
> set pgp_self_encrypt = yes
> # no-emit-version
> ---
> 
> My goal would be to hit a button so neomutt will check key-servers to get
> possible keys of the current recipient I am writing to. If a key exists, it
> uses encryption and if not, just show that no encryption is active and let
> me send it unencrypted. The key-server might be an optional step and it
> would be just nice if neomutt could check local keys and if a key is found,
> activate encryption, if not, do not activate it and let me write unencrypted
> mails.
> 
> Thanks a lot for your help in advance.

Having to stop and restart is a bit of a PITA.
There is the issue of emails retaining either the N or O.

I use neomutt -nF "the config file"

I use a very alpha, but very functional perl wrapper that builds full
.neomuttrc type files from PostgreSQL.

I get a list of all of the particular emails I use and choose one from a
list. A temporary and random-ishly named config file is made for each instance and
erased after hitting q or x to leave neomutt back into the wrapper where
the same list is presented again.

This simplifies things greatly and keeps completely unrelated emails from
getting mixed with the many others I use.

I don't see the slightest problem with having two or more different
configurations for any given email address (or a configuration with
several emails controlled by macros, etc.)

My thought would be to restart to encryption when needed to write a new
email with that. Also, threaded emails could be copied to a mailbox
where you could reply just to those with encryption (or without,
depending on how you want to work it out).

If I'm not clear (frequently a problem, sorry):

start wrapper
get list of emails (including two or more configs for the same email)
hit 1 for non-encrypted config
hit q or x to leave it
hit 2 for the encrypted config
hit q or x to leave it
hit q in the wrapper when presented the list of emails to close
up.

Sounds complicated, but it isn't.
I fly through a list of around 20+ emails in seconds.
(Apart from what I do within each one.)
I have a single user that I just use for emails.
This setup could be easily fixed in a hackish way to have more than one
user unable to access other users configs.

Pulling into the database from your existing config files AND any other
files to be sourced, like macros, is a breeze.

Others more knowledgable would have to answer this question:
Could you just suspend the neomutt and wrapper, run the wrapper again
with the other config, do stuff, quit and fg the suspended safely?

If anyone is interested in having a copy of this, let me know.
I need to extend some of the neomuttrc fields, but that part is simple.


I don't know if this is helpful, but it's my way of dealing with many
configurations without a huge mess of written files that are hard to
edit as a group.

-- 
Regards,
Chris Bennett



More information about the neomutt-users mailing list