1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
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 and 0.9.4 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.
For example:
mailboxes {localhost/ssl}inbox
mailboxes {localhost:994/ssl}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 somewhere Mutt will find it. Mutt tries to use files
$SslEntropyFile, $RANDFILE (if this environment variable is set) and
~/.rnd in that order as source for random data.
If your OpenSSL is version 0.9.5 or later, you should try EGD, Entropy
Gathering Daemon, from http://www.lothar.com/tech/crypto/ . Mutt will
try to find EGD sockets in the following places, $SslEntropyFile,
$EGDSOCKET (if this environment variable is set), ~/.entropy and
/tmp/entropy. If no socket is found, static files will be tried as
described above.
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 <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.
--
Tommi Komulainen
Tommi.Komulainen@iki.fi
Updated by Jeremy Katz
katzj@linuxpower.org
|
