IMAP/SSL in mutt
If you want to have SSL support in mutt, you need to install OpenSSL
(http://www.openssl.org) libraries and headers before compiling.
OpenSSL versions 0.9.3 through 0.9.6a have been tested.
For SSL support to be enabled, you need to run the ``configure''
script with ``--enable-imap --with-ssl[=PFX]'' parameters. If the
OpenSSL headers and libraries are not in the default system search
paths (usually /usr/include and /usr/lib) you can use the optional PFX
argument to define the root directory of your installation. The
libraries are then expected to be found in PFX/lib and headers in
IMAP/SSL folders can be accessed just like normal IMAP folders, but you
will also have to add '/ssl' before the closing curly brace. Or you can
use IMAP url notation, where the methods is called imaps.
If you get errors about lack of entropy, it means that Mutt was unable
to find a source of random data to initialize SSL library with. Should
this happen, you need to generate the data yourself and save it in a
file pointed by $entropy_file or $RANDFILE (environment) variables or
One way to generate random data would be to run a command which
generates unpredictable output, for example 'ps aluxww' in Linux, and
calculating the MD5-sum from the output and saving it in a file.
** Note: The contents of the file pointed by $RANDFILE environment
** variable (or ~/.rnd if unset) will be overwritten every time Mutt
** is run so don't put anything you can't afford to lose in that file.
The files Mutt will try to use to initialize SSL library with are files
pointed by $entropy_file and $RANDFILE (or ~/.rnd if unset.) If your
OpenSSL is version 0.9.5 or later, the previous files can also be EGD
sockets (see http://www.lothar.com/tech/crypto/ for more information
about Entropy Gathering Daemon) and in addition sockets in the following
places are tried: socket pointed by $EGDSOCKET environment variable,
~/.entropy and /tmp/entropy.
All the files and sockets mentioned above must be owned by the user and
have permissions of 600.
Each time a server is contacted, its certificate is checked against
known valid certificates. When an unknown certificate is encountered,
you are asked to verify it. If you reject the certificate, the
connection will be terminated immediately. If you accept the
certificate, the connection will be established. Accepted certificates
can also be saved so that further connections to the server are
If your organization has several equivalent IMAP-servers, each of them
should have a unique certificate which is signed with a common
certificate. If you want to use all of those servers, you don't need to
save each server certificate on the first connect. Instead, you can get
the signer certificate and save it instead. That way, mutt will
automatically accept all certificates signed with the saved certificate.
System-wide certificates are by default considered trusted when checking
certificates by signer. This allows system administrators to setup
trusted certificates for all users. How to install certificates
system-wide, depends on the OpenSSL installation. Use of system-wide
certificates can be disabled by unsetting $ssl_usesystemcerts variable.
Certificates will be saved in the file specified by $certificate_file
variable. It is empty as default, so if you don't want to verify
certificates each time you connect to a server, you have set this
variable to some reasonable value.
If after doing the above, you are unable to successfully connect, it
is likely that your IMAP server does not support one of the SSL protocols.
There exist three different protocols, TLSv1, SSLv2, and SSLv3. To check
each of these, you use the following:
openssl s_client -host <imap server> -port <port> -verify -debug -no_tls1
openssl s_client -host <imap server> -port <port> -verify -debug -no_ssl2
openssl s_client -host <imap server> -port <port> -verify -debug -no_ssl3
You can also combine the options until you get a successfull connect. Once
you know which options do not work, you can set the variables for non-working
protocols to know. The variables for the protocols are ssl_use_tlsv1,
ssl_use_sslv2, and ssl_use_sslv3.
Updated by Jeremy Katz