IMAP/SSL in mutt ================ Compilation ----------- 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 PFX/include/openssl. Usage ----- 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. For example: mailboxes {localhost/ssl}inbox mailboxes {localhost:994/ssl}inbox or mailboxes imaps://localhost/inbox mailboxes imaps://localhost:994/inbox 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 in ~/.rnd. 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. Certificates ------------ 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 automatically accepted. 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. For example: set certificate_file=~/.mutt/certificates Troubleshooting --------------- 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 -port -verify -debug -no_tls1 openssl s_client -host -port -verify -debug -no_ssl2 openssl s_client -host -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. -- Tommi Komulainen Tommi.Komulainen@iki.fi Updated by Jeremy Katz katzj@linuxpower.org