NeoMutt supports several of optional features which can be enabled or disabled at compile-time by giving the configure script certain arguments. These are listed in the “Optional features” section of the configure --help output.

Which features are enabled or disabled can later be determined from the output of neomutt -v. If a compile option starts with “+” it is enabled and disabled if prefixed with “-”. For example, if NeoMutt was compiled using GnuTLS for encrypted communication instead of OpenSSL, neomutt -v would contain:

-openssl +gnutls

NeoMutt optionally supports the IMAP, POP3 and SMTP protocols which require to access servers using URLs. The canonical syntax for specifying URLs in NeoMutt is (an item enclosed in [] means it is optional and may be omitted):

proto[s]://[username[:password]@]server[:port][/path]

proto is the communication protocol: imap for IMAP, pop for POP3 and smtp for SMTP. If “s” for “secure communication” is appended, NeoMutt will attempt to establish an encrypted communication using SSL or TLS.

Since all protocols supported by NeoMutt support/require authentication, login credentials may be specified in the URL. This has the advantage that multiple IMAP, POP3 or SMTP servers may be specified (which isn't possible using, for example, $imap_user). The username may contain the “@” symbol being used by many mail systems as part of the login name. The special characters “/”( %2F ), “:”( %3A ) and “%”( %25 ) have to be URL-encoded in usernames using the %-notation.

A password can be given, too but is not recommended if the URL is specified in a configuration file on disk.

If no port number is given, NeoMutt will use the system's default for the given protocol (usually consulting /etc/services ).

The optional path is only relevant for IMAP and ignored elsewhere.

pops://host/
imaps://user@host/INBOX/Sent
smtp://user@host:587/

When non-secure URL protocols imap://, pop://, and smtp:// are used, the initial connection to the server will be unencrypted. STARTTLS can be used to negotiate an encrypted connection after the initial unencrypted connection and exchange.

Two configuration variables control NeoMutt's behavior with STARTTLS. $ssl_starttls will initiate STARTTLS if the server advertises support for it. $ssl_force_tls will always try to initiate it, whether the server advertises support or not.

NeoMutt highly recommends setting $ssl_force_tls unless you need to connect to an unencrypted server. It's possible for an attacker to spoof interactions during the initial connection and hide support for STARTTLS. The only way to prevent these attacks is by forcing STARTTLS with the $ssl_force_tls configuration variable.

When connecting through a $tunnel and $tunnel_is_secure is set(the default), NeoMutt will assume the connection to the server through the pipe is already secured. NeoMutt will ignore $ssl_starttls and $ssl_force_tls, behaving as if TLS has already been negotiated.

When $tunnel_is_secure is unset, NeoMutt will respect the values of $ssl_starttls and $ssl_force_tls. It is highly recommended to set $ssl_force_tls in this case, to force STARTTLS negotiation. Note that doing so will prevent connection to an IMAP server configured for preauthentication( PREAUTH ). If you use this configuration, it is recommended to use a secure tunnel.

Polling for new mail is more expensive over POP3 than locally. For this reason the frequency at which NeoMutt will check for mail remotely can be controlled by the $pop_check_interval variable, which defaults to every 60 seconds.

Due to limitations in POP3, this method doesn't allow for some features such as editing messages, changing their flags or even deleting them. However, using Section 8.1, “Header Caching” and Section 8.2, “Body Caching”, NeoMutt simulates the new/old/read flags as well as flagged and replied. NeoMutt applies some logic on top of remote messages but cannot change them so that modifications of flags are lost when messages are downloaded from the POP3 server (either by NeoMutt or other tools).

# A sample configuration file for setting up a remote POP3 mailbox

# If an SMTP password has been set, use this to set the same password for POP3.
set pop_pass=$smtp_pass

# Set the POP3 server and user
set pop_host="pops://user@example.com"

# Use the remote server as the mailbox
set folder=$pop_host
set spool_file=+

Another way to access your POP3 mail is the <fetch-mail> function (default: G). It allows to connect to $pop_host, fetch all your new mail and place it in the local $spool_file. After this point, NeoMutt runs exactly as if the mail had always been local. The <fetch-mail> function will ask whether you want to delete the messages on the remote server, leaving only your local copies.

# A sample configuration file for fetching mail from a POP3 server

# The spool file contains the local copies of your messages. If it doesn't
# exist, initialize it as an empty file.
set spool_file="/home/user/.mailspool"

# The POP3 server and user from which to fetch messages
set pop_host="pops://user@example.com"

As of version 1.2, NeoMutt supports browsing mailboxes on an IMAP server. This is mostly the same as the local file browser, with the following differences:

NeoMutt supports four authentication methods with IMAP servers: SASL, GSSAPI, CRAM-MD5, and LOGIN. There is also support for the pseudo-protocol ANONYMOUS, which allows you to log in to a public IMAP server without having an account. To use ANONYMOUS, simply make your username blank or “anonymous”.

SASL is a special super-authenticator, which selects among several protocols (including GSSAPI, CRAM-MD5, ANONYMOUS, and DIGEST-MD5) the most secure method available on your host and the server. Using some of these methods (including DIGEST-MD5 and possibly GSSAPI), your entire session will be encrypted and invisible to those teeming network snoops. It is the best option if you have it. To use it, you must have the Cyrus SASL library installed on your system and compile NeoMutt with the --with-sasl flag.

NeoMutt will try whichever methods are compiled in and available on the server, in the following order: SASL, ANONYMOUS, GSSAPI, CRAM-MD5, LOGIN.

There are a few variables which control authentication:

NeoMutt provides optional support for caching message headers for the following types of folders: IMAP, POP, Maildir and MH. Header caching greatly speeds up opening large folders because for remote folders, headers usually only need to be downloaded once. For Maildir and MH, reading the headers from a single file is much faster than looking at possibly thousands of single files (since Maildir and MH use one file per message.)

Header caching can be enabled by configuring one of the database backends. One of bdb, gdbm, kyotocabinet, lmdb, qdbm, rocksdb, tdb, tokyocabinet.

If enabled, $header_cache can be used to either point to a file or a directory. If set to point to a file, one database file for all folders will be used (which may result in lower performance), but one file per folder if it points to a directory.

Additionally, $header_cache_backend can be set to specify which backend to use. The list of available backends can be specified at configure time with a set of --with-<backend> options. Currently, the following backends are supported: bdb, gdbm, kyotocabinet, lmdb, qdbm, rocksdb, tdb, tokyocabinet.

Take a look at the benchmark script provided in the following repository: contrib-hcache-benchmark. There you can find a way of finding the storage backend for your needs.

Both cache methods can be combined using the same directory for storage (and for IMAP/POP even provide meaningful file names) which simplifies manual maintenance tasks.

In addition to caching message headers only, NeoMutt can also cache whole message bodies. This results in faster display of messages for POP and IMAP folders because messages usually have to be downloaded only once.

For configuration, the variable $message_cache_dir must point to a directory. There, NeoMutt will create a hierarchy of subdirectories named like the account and mailbox path the cache is for.

For using both, header and body caching, $header_cache and $message_cache_dir can be safely set to the same value.

In a header or body cache directory, NeoMutt creates a directory hierarchy named like: proto:user@hostname where proto is either “pop” or “imap.” Within there, for each folder, NeoMutt stores messages in single files and header caches in files with the “.hcache” extension. All files can be removed as needed if the consumed disk space becomes an issue as NeoMutt will silently fetch missing items again. Pathnames are always stored in UTF-8 encoding.

For Maildir and MH, the header cache files are named after the MD5 checksum of the path.

NeoMutt does not (yet) support maintenance features for header cache database files so that files have to be removed in case they grow too big. It depends on the database library used for header caching whether disk space freed by removing messages is re-used.

For body caches, NeoMutt can keep the local cache in sync with the remote mailbox if the $message_cache_clean variable is set. Cleaning means to remove messages from the cache which are no longer present in the mailbox which only happens when other mail clients or instances of NeoMutt using a different body cache location delete messages (NeoMutt itself removes deleted messages from the cache when syncing a mailbox). As cleaning can take a noticeable amount of time, it should not be set in general but only occasionally.