NeoMutt can be compiled with Autocrypt support by running
configure with the
--autocrypt flag. Autocrypt provides easy to use, passive protection against data collection. Keys are distributed via an
Autocrypt: header added to emails. It does
not
protect against active adversaries, and so should not be considered a substitute for normal encryption via your keyring, using key signing and the web of trust to verify identities. With an understanding of these limitations, Autocrypt still provides an easy way to minimize cleartext emails sent between common correspondents, without having to explicitly exchange keys. More information can be found at
https://autocrypt.org/.
Autocrypt requires support for ECC cryptography, and NeoMutt by default will generate ECC keys. Therefore GnuPG 2.1 or greater is required. Additionally, NeoMutt's Autocrypt implementation uses GPGME and requires at least version 1.8.0.
Account and peer information is stored in a sqlite3 database, and so NeoMutt must be configured with the
--with-sqlite flag when autocrypt is enabled.
It is highly recommended that NeoMutt be configured with
--idn2 (enabled by default) so that Autocrypt can properly deal with international domain names.
While NeoMutt uses GPGME for Autocrypt, normal keyring operations can still be performed via classic mode (i.e. with
$crypt_use_gpgme unset). However, to avoid unnecessary prompts, it is recommended gpg not be configured in
loopback pinentry mode, and that
$pgp_use_gpg_agent remain set (the default).
To enable Autocrypt, set
$autocrypt, and if desired change the value of
$autocrypt_dir in your muttrc. The first time NeoMutt is run after that, you will be prompted to create
$autocrypt_dir. NeoMutt will then automatically create an sqlite3 database and GPG keyring in that directory. Note since these files should be considered private, NeoMutt will create this directory with mode
700. If you create the directory manually, you should do the same.
NeoMutt recommends keeping the
$autocrypt_dir directory set differently from your GnuPG keyring directory (e.g.
~/.gnupg ). Keys are automatically imported into the keyring from
Autocrypt: headers. Compared to standard
“web of trust” keys, Autocrypt keys are somewhat ephemeral, and the autocrypt database is used to track when keys change or fall out of use. Having these keys mixed in with your normal keyring will make it more difficult to use features such as
$crypt_opportunistic_encrypt and Autocrypt at the same time.
The $autocrypt_dir variable is not designed to be changed while NeoMutt is running. The database is created (if necessary) and connected to during startup. Changing the variable can result in a situation where NeoMutt is looking in one place for the database and a different place for the GPG keyring, resulting in strange behavior.
Once the directory, keyring, and database are created, NeoMutt will ask whether you would like to create an account. In order to use Autocrypt, each sending address needs an account. As a convenience you can create an account during the first run. If you would like to add additional accounts later, this can be done via the
<autocrypt-acct-menu> function in the index, by default bound to
A.
Account creation will first ask you for an email address. Next, it will ask whether you want to create a new key or select an existing key. (Note key selection takes place from the $autocrypt_dir keyring, which will normally be empty during first run). Finally, it will ask whether this address should prefer encryption or not. Autocrypt 1.1 allows automatically enabling encryption if both sender and receiver have set “prefer encryption”. Otherwise, you will need to manually enable autocrypt encryption in the compose menu. For more details, see the compose menu section below.
After optionally creating an account, NeoMutt will prompt you to scan mailboxes for Autocrypt headers. This step occurs because header cached messages are not re-scanned for Autocrypt headers. Scanning during this step will temporarily disable the header cache while opening each mailbox. If you wish to do this manually later, you can simulate the same thing by unsetting $header_cache and opening a mailbox.
A final technical note: the first run process takes place between reading the muttrc and opening the initial mailbox. Some muttrc files will push macros to be run after opening the mailbox. To prevent this from interfering with the first run prompts, NeoMutt disables all macros during the first run.
When enabled, Autocrypt will add a line to the compose menu with two fields:
Autocrypt: and
Recommendation:.
The
Autocrypt: field shows whether the message will be encrypted by Autocrypt when sent. It has two values:
Encrypt and
Off.
Encrypt can be enabled using the
<autocrypt-menu> function, by default bound to
o.
The
Recommendation: field shows the output of the Autocrypt recommendation engine. This can have one of five values:
Off means the engine is disabled. This can happen if the From address doesn't have an autocrypt account, or if the account has been manually disabled.
No means one or more recipients are missing an autocrypt key, or the key found is unusable (i.e. expired, revoked, disabled, invalid, or not usable for encryption.)
Discouraged means a key was found for every recipient, but the engine is not confident the message will be decryptable by the recipient. This can happen if the key hasn't been used recently (compared to their last seen email).
It can also happen if the key wasn't seen first-hand from the sender. Autocrypt has a feature where recipient keys can be included in group-encrypted emails. This allows you to reply to a conversation where you don't have a key first-hand from one of the other recipients. However, those keys are not trusted as much as from first-hand emails, so the engine warns you with a
Discouraged status.
Available means a key was found for every recipient, and the engine believes all keys are recent and seen from the recipient first hand. However, either you or one of the recipients chose not to specify
“prefer encryption”.
Yes is the same as
Available, with the addition that you and all recipients have specified
“prefer encryption”. This value will automatically enable encryption, unless you have manually switched it off or enabled regular encryption or signing via the
<pgp-menu>.
As mentioned above the
<autocrypt-menu> function, by default bound to
o, can be used to change the
Encrypt: field value.
(e)ncrypt will toggle encryption on.
(c)lear will toggle encryption off. If either of these are chosen, the field will remain in that state despite what the
Recommendation: field shows. Lastly,
(a)utomatic will set the value based on the recommendation engine's output.
Autocrypt encryption defers to normal encryption or signing. Anything that enables normal encryption or signing will cause autocrypt encryption to turn off. The only exception is when replying to an autocrypt-encrypted email (i.e. an email decrypted from the $autocrypt_dir keyring). Then, if $autocrypt_reply is set , autocrypt mode will be forced on, overriding the settings $crypt_auto_sign, $crypt_auto_encrypt, $crypt_reply_encrypt, $crypt_reply_sign, $crypt_reply_sign_encrypted, and $crypt_opportunistic_encrypt.
When postponing a message, autocrypt will respect $postpone_encrypt, but will use the autocrypt account key to encrypt the message. Be sure to set $postpone_encrypt to ensure postponed messages marked for autocrypt encryption are encrypted.
The Autocrypt Account Menu is available from the index via
<autocrypt-acct-menu>, by default bound to
A. See
Autocrypt Account Menu for the list of functions and their default keybindings.
In this menu, you can create new accounts, delete accounts, toggle an account active/inactive, and toggle the “prefer encryption” flag for an account.
Deleting an account only removes the account from the database. The GPG key is kept, to ensure you still have the ability to read past encrypted emails.
The Autocrypt 1.1 “Setup Message” feature is not available yet, but will be added in the future.
NeoMutt by default partitions Autocrypt from normal keyring encryption/signing. It does this by using a separate GPG keyring (in $autocrypt_dir) and creating a new ECC key in that keyring for accounts. There are good reasons for doing this by default. It keeps random keys found inside email headers out of your normal keyring. ECC keys are compact and better suited for email headers. Autocrypt key selection is completely different from “web of trust” key selection, based on last-seen rules as opposed to trust and validity. It also allows NeoMutt to distinguish Autocrypt encrypted emails from regular encrypted emails, and set the mode appropriately when replying to each type of email.
Still, some users may want to use an existing key from their normal keyring for Autocrypt too. There are two ways this can be accomplished. The
recommended
way is to set
$autocrypt_dir to your normal keyring directory (e.g.
~/.gnupg ). During account creation, choosing
“(s)elect existing GPG key” will then list and allow selecting your existing key for the new account.
An alternative is to copy your key over to the Autocrypt keyring, but there is a severe downside. NeoMutt first tries to decrypt messages using the Autocrypt keyring, and if that fails tries the normal keyring second. This means all encrypted emails to that key will be decrypted, and have signatures verified from, the Autocrypt keyring. Keys signatures and web of trust from your normal keyring will no longer show up in signatures when decrypting.
For that reason, if you want to use an existing key from your normal keyring, it is recommended to just set
$autocrypt_dir to
~/.gnupg. This allows
“web of trust” to show an appropriate signature message for verified messages. Autocrypt header keys will be imported into your keyring, but if you don't want them mixed you should strongly consider using a separate autocrypt key and keyring instead.
Both methods have a couple additional caveats:
Replying to an Autocrypt decrypted message by default forces Autocrypt mode on. By sharing the same key, all replies will then start in Autocrypt mode, even if a message wasn't sent by one of your Autocrypt peers. $autocrypt_reply can be unset to allow manual control of the mode when replying.
When NeoMutt creates an account from a GPG key, it exports the public key, base64 encodes it, and stores that value in the sqlite3 database. The value is then used in the Autocrypt header added to outgoing emails. The ECC keys NeoMutt creates don't change, but if you use external keys that expire, when you resign to extend the expiration you will need to recreate the Autocrypt account using the account menu. Otherwise the Autocrypt header will contain the old expired exported keydata.
