Managing Mailbox Access (211.3)

Managing Mailbox Access (211.3)

Candidates should be aware of Courier email server and be able to install and configure POP and IMAP daemon on a Dovecot server.

Courier

The Courier mail transfer agent (MTA) is an integrated mail/groupware server based on open commodity protocols, such as ESMTP, IMAP, POP3, LDAP, SSL, and HTTP. Courier provides ESMTP, IMAP, POP3, webmail, and mailing list services within a single, consistent framework. Individual components can be enabled or disabled at will. The Courier mail server now implements basic web-based calendaring and scheduling services integrated in the webmail module.

The Courier mail server uses maildirs as its native mail storage format, but it can also deliver mail to legacy mailbox files as well. By default /etc/courier is the sysconfdir. All courier configuration files are stored here. The mail queue can be found at /var/spool/mqueue.

Information about the configuration for Courier can be found at: Courier installation.

Dovecot

Dovecot is an open source IMAP and POP3 email server for Linux/UNIX-like systems, written with security primarily in mind. Dovecot claims that it is an excellent choice for both small and large installations.

The configuration files of Dovecot can be found in /etc/dovecot/conf.d and we need to configure several parameters: authentication, mailbox location, SSL settings and the configuration as POP3 server.

Authentication

Dovecot is capable of using several password database backends like: PAM, BDSAuth, LDAP, passwd, and SQL databases like MySQL, PostgreSQL and SQLite. The most common way is PAM authentication. The PAM configuration is usually located in /etc/pam.d. By default Dovecot uses dovecot as PAM service name.

Here is an example of /etc/pam.d/dovecot:

                                  #%PAM-1.0

                                  @include common-auth
                                  @include common-account
                                  @include common-session

The method used by clients to send the login credentials to the server, is configured via the mechanisms parameter. The simplest authentication mechanism is PLAIN. The client simply sends the password unencrypted to Dovecot. All clients support the PLAIN mechanism, but obviously there's the problem that anyone listening on the network can steal the password. For that reason (and some others) other mechanisms were implemented.

SSL/TLS encryption can be used to secure the PLAIN authentication mechanism, since the password is sent over an encrypted stream. Non-plaintext mechanisms have been designed to be safe to use even without SSL/TLS encryption. Because of how cd /etc/they have been designed, they require access to the plaintext password or their own special hashed version of it. This means that it's impossible to use non-plaintext mechanisms with commonly used DES or MD5 password hashes. With success/failure password databases (e.g. PAM) it's not possible to use non-plaintext mechanisms at all, because they only support verifying a known plaintext password.

Dovecot supports the following non-plaintext mechanisms: CRAM-MD5, DIGEST-MD5, SCRAM-SHA1,SCRAM-SHA-256, APOP, NTLM, GSS-SPNEGO, GSSAPI, RPA, ANONYMOUS, OTP and SKEY, OAUTHBEARER, XOATH2 and EXTERNAL. By default only the PLAIN mechanism is enabled. You can change this by modifying 10-auth.conf:

                                  auth_mechanisms = plain login cram-md5

Mailbox location

Using the mail_location parameter in 10-mail.conf we can configure which mailbox location we want to use:

    mail_location = maildir:~/Maildir

or

    mail_location = mbox:~/mail:INBOX=/var/mail/%u

In this case email is stored in /var/mail/%u where "%u" is converted into the username.

SSL

Before Dovecot can use SSL, the SSL certificates need to be created and Dovecot must be configured to use them.

mkcert.sh Dovecot includes a script /usr/share/dovecot/mkcert.sh to create self-signed SSL certificates:

#!/bin/sh

# Generates a self-signed certificate.
# Edit dovecot-openssl.cnf before running this.

umask 077
OPENSSL=${OPENSSL-openssl}
SSLDIR=${SSLDIR-/etc/ssl}
OPENSSLCONFIG=${OPENSSLCONFIG-dovecot-openssl.cnf}

CERTDIR=/etc/dovecot
KEYDIR=/etc/dovecot/private

CERTFILE=$CERTDIR/dovecot.pem
KEYFILE=$KEYDIR/dovecot.pem

if [ ! -d $CERTDIR ]; then
  echo "$SSLDIR/certs directory doesn't exist"
  exit 1
fi

if [ ! -d $KEYDIR ]; then
  echo "$SSLDIR/private directory doesn't exist"
  exit 1
fi

if [ -f $CERTFILE ]; then
  echo "$CERTFILE already exists, won't overwrite"
  exit 1
fi

if [ -f $KEYFILE ]; then
  echo "$KEYFILE already exists, won't overwrite"
  exit 1
fi

$OPENSSL req -new -x509 -nodes -config $OPENSSLCONFIG -out $CERTFILE -keyout $KEYFILE -days 365 || exit 2
chmod 0600 $KEYFILE
echo
$OPENSSL x509 -subject -fingerprint -noout -in $CERTFILE || exit 2

The important SSL configuration options can be found in the file: 10-ssl.conf. To enable encryption of the data in transit between a client and a Dovecot server the following changes should be made.

    ssl = required

This configuration option requires that the client is using SSL/TLS as transport layer mechanism. Authentication attempts without SSL/TLS will cause authentication failures. Another important configuration option to enable SSL/TLS is the configuration of the SSL/TLS key and the SSL/TLS certificate. The certificates in this example are auto generated by the installation of Dovecot.

    ssl_cert =