If Mutt is compiled with IMAP, POP3 and/or SMTP support, it can also be compiled with support for SSL or TLS using either OpenSSL or GnuTLS ( by running the configure script with the --enable-ssl=... option for OpenSSL or --enable-gnutls=... for GnuTLS). Mutt can then attempt to encrypt communication with remote servers if these protocols are suffixed with “s” for “secure communication”.

If Mutt is compiled with POP3 support (by running the configure script with the --enable-pop flag), it has the ability to work with mailboxes located on a remote POP3 server and fetch mail for local browsing.

Remote POP3 servers can be accessed using URLs with the pop protocol for unencrypted and pops for encrypted communication, see Section 1.2, “URL Syntax” for details.

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

POP is read-only which doesn't allow for some features like editing messages or changing flags. However, using Section 7.1, “Header Caching” and Section 7.2, “Body Caching” Mutt simulates the new/old/read flags as well as flagged and replied. Mutt 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 POP server (either by Mutt or other tools).

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 $spoolfile. After this point, Mutt runs exactly as if the mail had always been local.

If Mutt was compiled with IMAP support (by running the configure script with the --enable-imap flag), it has the ability to work with folders located on a remote IMAP server.

You can access the remote inbox by selecting the folder by its URL (see Section 1.2, “URL Syntax” for details) using the imap or imaps protocol. Alternatively, a pine-compatible notation is also supported, ie {[username@]imapserver[:port][/ssl]}path/to/folder

Note that not all servers use “/” as the hierarchy separator. Mutt should correctly notice which separator is being used by the server and convert paths accordingly.

When browsing folders on an IMAP server, you can toggle whether to look at only the folders you are subscribed to, or all folders with the toggle-subscribed command. See also the $imap_list_subscribed variable.

Polling for new mail on an IMAP server can cause noticeable delays. So, you'll want to carefully tune the $mail_check and $timeout variables. Reasonable values are:

set mail_check=90
set timeout=15

with relatively good results even over slow modem lines.

Besides supporting traditional mail delivery through a sendmail-compatible program, Mutt supports delivery through SMTP if it was configured and built with --enable-smtp.

If the configuration variable $smtp_url is set, Mutt will contact the given SMTP server to deliver messages; if it is unset, Mutt will use the program specified by $sendmail.

For details on the URL syntax, please see Section 1.2, “URL Syntax”.

The built-in SMTP support supports encryption (the smtps protocol using SSL or TLS) as well as SMTP authentication using SASL. The authentication mechanisms for SASL are specified in $smtp_authenticators defaulting to an empty list which makes Mutt try all available methods from most-secure to least-secure.

Usage:

If you happen to have accounts on multiple IMAP, POP and/or SMTP servers, you may find managing all the authentication settings inconvenient and error-prone. The account-hook command may help. This hook works like folder-hook but is invoked whenever Mutt needs to access a remote mailbox (including inside the folder browser), not just when you open the mailbox. This includes (for example) polling for new mail, storing Fcc messages and saving messages to a folder. As a consequence, account-hook should only be used to set connection-related settings such as passwords or tunnel commands but not settings such as sender address or name (because in general it should be considered unpredictable which account-hook was last used).

Some examples:

account-hook . 'unset imap_user; unset imap_pass; unset tunnel'
account-hook imap://host1/ 'set imap_user=me1 imap_pass=foo'
account-hook imap://host2/ 'set tunnel="ssh host2 /usr/libexec/imapd"'
account-hook smtp://user@host3/ 'set tunnel="ssh host3 /usr/libexec/smtpd"'

To manage multiple accounts with, for example, different values of $record or sender addresses, folder-hook has to be be used together with the mailboxes command.

mailboxes imap://user@host1/INBOX
folder-hook imap://user@host1/ 'set folder=imap://host1/ ; set record=+INBOX/Sent'

mailboxes imap://user@host2/INBOX
folder-hook imap://user@host2/ 'set folder=imap://host2/ ; set record=+INBOX/Sent'

In example Example 6.2, “Managing multiple accounts” the folders are defined using mailboxes so Mutt polls them for new mail. Each folder-hook triggers when one mailbox below each IMAP account is opened and sets $folder to the account's root folder. Next, it sets $record to the INBOX/Sent folder below the newly set $folder. Please notice that the value the “+” mailbox shortcut refers to depends on the current value of $folder and therefore has to be set separatedly per account. Setting other values like $from or $signature is analogous to setting $record.

Mutt contains two types of local caching: (1) the so-called “header caching” and (2) the so-called “body caching” which are both described in this section.

Header caching is optional as it depends on external libraries, body caching is always enabled if Mutt is compiled with POP and/or IMAP support as these use it (body caching requires no external library).

Mutt supports the “Name <user@host>” address syntax for reading and writing messages, the older “user@host (Name)” syntax is only supported when reading messages. The --enable-exact-address switch can be given to configure to build it with write-support for the latter syntax. EXACT_ADDRESS in the output of mutt -v indicates whether it's supported.

You may also have compiled Mutt to co-operate with Mixmaster, an anonymous remailer. Mixmaster permits you to send your messages anonymously using a chain of remailers. Mixmaster support in Mutt is for mixmaster version 2.04 (beta 45 appears to be the latest) and 2.03. It does not support earlier versions or the later so-called version 3 betas, of which the latest appears to be called 2.9b23.

To use it, you'll have to obey certain restrictions. Most important, you cannot use the Cc and Bcc headers. To tell Mutt to use mixmaster, you have to select a remailer chain, using the mix function on the compose menu.

The chain selection screen is divided into two parts. In the (larger) upper part, you get a list of remailers you may use. In the lower part, you see the currently selected chain of remailers.

You can navigate in the chain using the <chain-prev> and <chain-next> functions, which are by default bound to the left and right arrows and to the h and l keys (think vi keyboard bindings). To insert a remailer at the current chain position, use the <insert> function. To append a remailer behind the current chain position, use <select-entry> or <append>. You can also delete entries from the chain, using the corresponding function. Finally, to abandon your changes, leave the menu, or <accept> them, pressing (by default) the Return key.

Note that different remailers do have different capabilities, indicated in the %c entry of the remailer menu lines (see $mix_entry_format). Most important is the “middleman” capability, indicated by a capital “M”: This means that the remailer in question cannot be used as the final element of a chain, but will only forward messages to other mixmaster remailers. For details on the other capabilities, please have a look at the mixmaster documentation.