Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

9.6. Mail Delivery Agents

As important as it is to run secure Mail Transfer Agent services,
it's only part of your email picture, and it
isn't even the part your end users will interact
with directly. A Mail Delivery Agent (MDA)
allows users to read (or download) email from their mailbox on a
server. IMAP and POP3 are two popular MDA protocols used for Internet
email; webmail interfaces, in fact, usually act
as frontends to IMAP and POP3 servers. Our focus in the remainder of
this chapter will be on the IMAP protocol, which is both newer and
more powerful than POP3. (Much of what follows, however, should to
some extent apply to POP3.) An IMAP-based MDA system has two parts: an IMAP
server, which houses user mailboxes and receives mail from some MTA;
and a group of users running IMAP client software. The three most
popular open source IMAP servers are University of Washington IMAP
(UW IMAP), Cyrus IMAPD from Carnegie Mellon University, and Courier
IMAP from Inter7 Internet Techologies. Popular IMAP client
applications include Netscape/Mozilla Communicator, Microsoft
Outlook, Mutt, Pine, and Apple Mac OS X Mail.

IMAP clients are out of the scope of our purposes here, but
they're relatively easy to configure and use.
Furthermore, most IMAP clients easily interoperate with most IMAP
servers, so there isn't much to explain.

9.6.1. Principles of MDA Security

In practice, good MDA
security requires two things: meaningful authentication, to keep
strangers out, and encryption, to protect both the integrity of
authentication transactions and the confidentiality of your
users' email sessions. In addition, your MDA
software needs to be configured in a way that takes full advantage of
whatever other security features it supports, including running as a
nonpriviliged user, running in a chroot jail, etc. (By now, I hope
these principles are utterly familiar to you!) MDA authentication is usually handled one of several ways:

By authenticating users via the MDA server's
underlying operating system, e.g., requiring each email user to have
a user account on the MDA server.

By authentiating users via a dedicated database of email user
accounts.

By using some sort of centralized authentication service such as LDAP
(see Chapter 7).

MDA encryption can also be implemented a couple of different ways.
Most modern MDA server applications, such as Cyrus IMAP, natively
support encrypted email sessions via the SSL and TLS protocols (see
Chapter 5). Alternatively, since MDA protocols
such as POP3 and IMAP are single TCP port
protocols, an encryption
"wrapper" such as Stunnel (Chapter 5) may be used to transparently add
encryption at the network level, if your MDA server software
doesn't have its own encryption capabilities.

In the remainder of this part of the chapter, I'll
show how to:

Configure Cyrus IMAP to use LDAP to authenticate email users.

Configure Cyrus IMAP to accept only SSL/TLS-encrypted email-retrieval
sessions.

Make the most of Cyrus IMAP's other security
features.

While the mechanics of these three tasks are specific to Cyrus IMAP,
the principles and goals behind them are the same whether you run
Cyrus, Courier IMAP, or an entirely different MDA service.

Note that in these procedures and examples, I'll
assume that you've already got a working LDAP server
and already know how to generate X.509 certificates. For more
information on LDAP and digital certificates, see Chapter 5 and Chapter 7.

9.6.2. Which IMAP Server?

The first choice an email administrator must make in building an
IMAP system is which server to use. What
are the major differences between UW IMAP, Courier IMAP, and Cyrus
IMAP? In brief:

Of the three, UW
IMAP is the least flexible, as it supports only local-user-account
mail-file delivery; each local user's inbox is
stored as a single flat filee.g.,
/var/mail/myusername. This has two
disadvantages: each mail user must also be a system user, and only
one process may write to any given user's inbox at
any given time, potentially resulting in file-locking complications Courier IMAP,
actually part of the Courier Mail Server, was designed to support
qmail's maildir system, whereby
each user has her own mail directory in which messages are stored as
individual files (which is better both from a performance standpoint
and for obviating file-locking problems). Courier can also store mail
in databases (see the next point); recent versions of Courier IMAP
also support LDAP authentication Cyrus IMAP can be
more complicated to set up than UW IMAP or Courier IMAP, mainly due
to the Cyrus SASL authentication libraries on which it depends.
However, it uses its own user and mail databases, both completely
separate from the underlying OS, which allows you to add mail users
without adding system user accounts. Also, the use of databases
rather than flat files to store messages has an obvious performance
benefit.

Personally, I've used Cyrus IMAP the most, so
that's the MDA this chapter covers. Refer to the
feature lists on the respective home pages of UW IMAP, Courier IMAP,
and Cyrus IMAP (see Section 9.8,
at the end of this chapter), to decide for yourself which is the best
fit for your environment. If your choice is different than mine, I
still hope some of the concepts in the rest of this chapter (if not
the details) are helpful to you.

9.6.2.1 Getting and installing Cyrus IMAP

As you know, I'm a big fan of binary packages due to
the version-control and patch-management features that modern package
managers (yast, rpm,
apt, etc.) provide. Accordingly, I recommend
that you install Cyrus IMAP from your distribution
of choice's installation media if at all possible.
Besides Cyrus IMAP, you'll also need Cyrus SASL, an
authentication backend on which it depends (SMTP AUTH also uses this,
so you may already have it installed).

In SUSE, the RPMs you'll need are
cyrus-imapd and cyrus-sasl.
In Debian 3.0, you'll need the deb packages
cyrus-common, cyrus-imapd,
libsasl2, and sasl2-bin.
Both SUSE and Debian users, take note: earlier versions of your
respective distributions may have Cyrus-SASL packages based on old
(pre-v2.0) versions of Cyrus SASL. The method of authenticating Cyrus
IMAP against LDAP I'm about to describe depends on
SASL v2.0 or later, however; if your version of your distro of choice
has a pre-2.0 SASL package, you may need to obtain and compile Cyrus
SASL source code (available at http://www.invoca.ch/pub/packages/cyrus-imapd/
(graciously maintained and provided by Simon Matter in Switzerland).

If you've never dealt with source-RPM (SRPM) files
before, don't worry. The command to build a binary
RPM from an SRPM is simply:

rpmbuild --rebuild [--target yourarch] srpm.name.SRPM where srpm.name.SRPM is the name of your
SRPM file and the optional --target parameter
specifies your machine's architecture (i386, i586,
i686, etc.). For example, when I ran this command on my Pentium III
server, I used rpmbuild --rebuild --target i686
cyrus-imapd-2.2.8-1.src.rpm. Note that although the
--target setting is optional, if
you're going to have a large IMAP user database,
optimizing Cyrus IMAP for your CPU type reportedly yields noticeable
speed improvements over the default
"i386" build.

rpmbuild automatically compiles several new
binary RPMs, customized for your local system architecture; these
RPMs are written into /usr/src/redhat/RPMS/ (the
precise subdirectory being whatever you specified after
--target, or i386/ by
default). These RPMS are cyrus-imapd,
cyrus-imapd-murder,
cyrus-imapd-nntp,
cyrus-imapd-utils,
cyrus-imapd-devel, and
perl-Cyrus.

Install them by changing your working directory to
/usr/src/redhat/RPMS/i686 and entering the
command rpm -Uvh cyrus-* perl-Cyrus*.

9.6.3. Configuring SASL

For the remainder
of this part of the chapter, we have two goals: to leverage our
existing LDAP server to authenticate IMAP users and to configure our
Cyrus IMAP server to accept only SSL-encrypted connections from end
users. Anyone who's had to support users who each
have logins across multiple systems can understand the virtues of
centralizing authentication; the value of using LDAP for this should
be obvious.

Since Cyrus IMAP and Cyrus SASL both come from Carnegie Mellon
University, and since the Cyrus team is understandably reluctant to
reinvent the wheel, Cyrus IMAP depends on Cyrus SASL for its
authentication functionality. This may seem confusing:
isn't that what we're about to use
LDAP for? Yes it is, and SASL is indeed redundant insofar as SASL was
designed to use its own user database to
authenticate users.

But besides using its own database, SASL can also be used to
"broker" authentication
transactions with other authentication sources, such as PAM or LDAP.
The simplest way to do this is by configuring
saslauthd, the "SASL
Authentication Daemon," whose behavior is controlled
primarily by the file /etc/saslauthd.conf. Note
however that saslauthd wasn't
introduced until SASL v2.0; if you don't already
have a recent version of SASL installed on your system, see
"Obtaining Cyrus SASL" under
"Sendmail and SMTP AUTH," earlier
in this chapter.

Before configuring
saslauthd,
you'll need to decide whether to use
saslauthd's built-in LDAP
functionality or instead to point it to PAM and have PAM handle the
LDAP transactions. The former is preferable, since adding PAM to the
mix adds complexity. Also, PAM has a history of memory leaks, which
may require you to restart saslauthd
periodically.

But if your system's saslauthd
doesn't support LDAP and
you're unable to obtain or compile a version that
does, the PAM method is acceptable. As I mentioned earlier in the
chapter, that's the method I use on my SUSE systems.
I'll describe both methods here, beginning with the
"direct" method.

By the way, if you don't know whether your local
saslauthd supports LDAP, enter the command
saslauthd --version to see which features it was
compiled to support.

9.6.3.1 Configuring SASL to use LDAP directly

Step one in configuring saslauthd to perform its
own LDAP queries is to make sure
saslauthd is started with the flag -a
ldap. On Red Hat and Fedora, this is done by editing the
file /etc/sysconfig/saslauthd so that the
parameter MECH is set to ldap;
on SUSE you edit the same file, but the parameter is called
SASLAUTHD_AUTHMECH. On Debian systems, edit the
file /etc/default/saslauthd so that
MECHANISMS is set to ldap.

Step two is to edit /etc/saslauthd.conf, which,
obviously enough, is
saslauthd's configuration file.

Sometimes even after you install cyrus-sasl (and sasl-bin, if applicable) there will be no default or placeholder saslauthd.conf file in /etc/. Don't panic! Just create this file manually.

Example 9-22 shows a sample
saslauthd.conf file.

Example 9-22. Sample /etc/saslauthd.conf

ldap_servers: ldap://localhost/
ldap_search_base: dc=wiremonkeys,dc=org
ldap_bind_dn: uid=backend,dc=wiremonkeys,dc=org
ldap_bind_pw: password_goes_here ldap_servers specifies a space-delimited list of
LDAP server URIs. In Example 9-22
I've specified a cleartext ldap
connection to the local LDAP process; I could specify the encrypted
ldaps protocol instead of ldap;
specify a remote, fully qualified domain name or IP address instead
of localhost; or both (e.g.,
ldaps://ldap.wiremonkeys.org).

ldap_search_base is the
"base" (shared) part of your
users' Distinguished Names (DNs).
ldap_bind_dn and ldap_bind_pw
are the DN and password you wish saslauthd to
use to connect to your LDAP server. I recommend creating a special
LDAP record for this purpose. Example 9-22 shows a
sample entry for this, where backend is the name
of a special LDAP account with an objectClass of
simpleSecurityObject (Example 9-23).

Example 9-23. LDAP entry for a server account ("ldif" format)

dn: uid=backend,dc=wiremonkeys,dc=org
objectClass: top
objectClass: account
objectClass: simpleSecurityObject
uid: backend
password: password_goes_here Having a dedicated server account in LDAP means, if nothing else,
that in your LDAP logs, you'll be able to
distinguish between LDAP lookups by backend processes or servers, and
end-user-initiated queries (which would be harder here if IMAP used,
for example, your personal LDAP account to do its work). For
still-more granular auditing, you could even use a different LDAP
account for each service that performs LDAP queries, (e.g.,
cyrus, postfix, etc.).

Example 9-22 shows the options I use in my own
/etc/saslauthd.conf file, but they
aren't the only ones available to you. Cyrus SASL is
distributed with a file, LDAP_SASLAUTHD, which
documents these and other saslauthd.conf
options; it's located in the source-code
distribution's saslauthd/
directory, but if you install SASL from a binary package, it will be
placed wherever your distribution puts package documentation (i.e.,
probably some subdirectory of /usr/share/doc/).

After setting its startup behavior and editing its configuration
file, restart saslauthd with the command
/etc/init.d/saslauthd restart.

9.6.3.2 Configuring SASL to use LDAP via PAM

Step one for this method is the same as the other one: tell
saslauthd which authentication mechanism to use
via its -a flag. In this case, however, we want to
specify the pam method (e.g., -a
pam). On Red Hat and Fedora, edit the file
/etc/sysconfig/saslauthd so that the parameter
MECH is set to pam; on SUSE,
edit /etc/sysconfig/saslauthd so that
SASLAUTHD_AUTHMECH is set to
pam. On Debian systems, you need to edit the file
/etc/default/saslauthd so that
MECHANISMS is set to pam.

Step two for the PAM method is not to do
anything with /etc/saslauthd.confyou
don't need to do anything in particular to configure
saslauthd to use PAM, once
you've told it to use PAM in the first place.
Rather, you'll need to tell PAM when to perform LDAP
queries. In this case, we want PAM to do so for IMAP transactions;
therefore the file we need to edit is called
/etc/pam.d/imap. It will need to look like Example 9-24.

Example 9-24. Sample /etc/pam.d/imap

auth required /lib/security/pam_ldap.so
account required /lib/security/pam_ldap.so Finally, step three is to configure your system's
ldap client libraries by editing
/etc/openldap.ldap.conf. This will determine how
PAM conducts its LDAP queries. Example 9-25 shows a
sample /etc/openldap/ldap.conf file for this
purpose.

Example 9-25. Sample /etc/openldap/ldap.conf

uri ldap://localhost/
base dc=wiremonkeys,dc=org
binddn uid=backend,dc=wiremonkeys,dc=org
bindpw password_goes_here
scope sub
pam_login_attribute uid
TLS_REQCERT allow The important items in Example 9-25 are:

uri

Specifies the URI of your LDAP server.

base

Specifies that part of your organization's
Distinguished Names common to your users.

binddn

Specifies the DN of the account you want to perform queries as (see
the previous section and Example 9-23 for a
discussion on "server accounts").

bindpw

Specifies the password associated with the binddn
account.

pam_login_attribute

The LDAP attribute you wish to query against for each user; that is,
the one that corresponds to usernames (uid here).

If you intend to perform encrypted LDAPS or TLS queries, and I do
hope you do, note also TLS_REQCERT: if this is set
to allow, you can perform LDAP queries against an
LDAP server that has a self-signed certificate.

Once you've configured and restarted
saslauthd, you're ready to
configure your IMAP service. As it happens, this is the easy
part!

9.6.3.3 Configuring Cyrus IMAP

Most of Cyrus
IMAP's behavior is controlled by a file named,
predictably, /etc/imapd.conf. Example 9-26 shows a sample imapd.conf
file:

Example 9-26. Sample /etc/imapd.conf

configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus wongfh
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
hashimapspool: true
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN
tls_cert_file: /var/lib/imap/slapd3.pem
tls_key_file: /var/lib/imap/slapd3key.pem
tls_cipher_list: HIGH:MEDIUM:+SSLv2 As you can see, many of the options in
imapd.conf
simply define paths to things Cyrus IMAP needs. I
won't cover these in detail (see the
imapd.conf(5) manpage for complete
documentation), but let's discuss the settings in
Example 9-26 that either set nondefault values or
have important security ramifications.

admins specifies the Cyrus IMAP users who may
administer the IMAP system via the cyradm tool.
By setting sasl_pwcheck_method to
saslauthd, and by having already configured
saslauthd to use LDAP, we've
configured Cyrus IMAP to use LDAP for all
authentication, so even though, for example, the user
cyrus may exist on the local Linux system (i.e.,
in /etc/passwd), cyrus will
also need to have an LDAP entry.

When you run cyradmin and are prompted for
cyrus's password,
you'll provide the password defined for Cyrus in the
database, not cyrus's Linux
password (if indeed the Linux account even has one). In other words,
any account names you specify after admins must
exist in whatever user database is specified by
sasl_pwcheck_method.

When you installed Cyrus IMAP, whether from binary packages or from source code, a new user (cyrus) should have been created and given ownership of most Cyrus IMAP files. As with any other good service daemon, Cyrus IMAP runs as a special nonprivileged user rather than root most of the time.

The three other settings in Example 9-26 that I had
to customize were tls_cert_file,
tls_key_file, and
tls_cipher_list. These are analogous to
OpenLDAP's slapd.conf
parameters TLSCertificateFile,
TLSCertificateKeyFile, and
TLSCipherSuite, respectively, which I mention
because the certificate/key files specified here are the same ones I
used for OpenLDAP on this system.

This is because in my example scenario, I'm running
Cyrus IMAP on the same server I'm running OpenLDAP
on; there's no reason to use different server
certificates and keys for services running on the same machine.
(However, I did copy both files from
/etc/openldap to
/var/lib/imap, to simplify ownership/permissions
management.) If my LDAP service were running on a separate host, I would create a
new TLS certificate/key pair for my LDAP server, using exactly the
same procedure I described earlier (i.e., via the command
openssl req -new -x509 -nodes -out slapdcert.pem -keyout
slapdkey.pem -days 365). Regardless, remember to make both
your certificate file and key file owned by
cyrus, and your key file readable
only by its owner.

Note that if you install Cyrus IMAP from source, it will use default
SSL keys that will fail if an IMAP client attempts to connect using
TLS rather than SSL encryption. Aside from the reliability issue,
it's never, ever a good idea to use
"default" (placeholder)
certificates or keys for anything. Either leverage a server
certificate/key you've already created (if
applicable) or create a new pair, and your IMAP server will be both
more reliable and more secure.

That's it: Cyrus IMAP may now be restarted (e.g.,
/etc/init.d/cyrus-imapd
restart), and users added via
cyradm.

9.6.4. Using cyradm to Administer Cyrus IMAP

Cyrus IMAP comes with a Perl script,
cyradm, which provides the most convenient way
to create and manage user mailboxes. There are several things you
should understand before using cyradm.

First, you should not use any account to run
cyradm with which you also intend to read email.
In other words, you should never use an IMAP administrative account
as an email account. Due to unusual write-access permissions, using
such accounts to read or send email can have strange and negative
effects on your server. As we've seen, Cyrus
administrative accounts are named via the variable
admins in /etc/imapd.conf.

Second, cyradm uses the same authentication
method as the rest of Cyrus IMAP. Earlier, we defined this by setting
/etc/imapd.conf's variable
sasl_pwcheck_method to
saslauthd and by editing
/etc/sysconfig/saslauthd either to use LDAP or,
in the case of SUSE, to use pam (which itself
can be configured to use LDAP for IMAP transactions in the files
/etc/pam.d/imap and
/etc/openldap/ldap.conf). In short,
cyradm will identify and authenticate
administrative users via LDAP, assuming you've
correctly configured LDAP support in Cyrus IMAP as described earlier.

Finally, know that to authenticate, cyradm performs an LDAP
"auth" lookup against your username
and password, using the LDAP attribute uid as the
search criterion. This means that for each user account you wish to
allow to run cyradm, the LDAP record will need
to contain definitions for both uid and
userPassword.

This last point has another important ramification: in your OpenLDAP
server's
/etc/openldap/slapd.conf file,
you'll need to have Access Control List (ACL)
statements granting "auth" access
to the userPassword attribute for whatever LDAP
user your IMAP server (or its saslauthd process)
will use to bind to the LDAP server (i.e., to perform
authentications). LDAP ACL statements are described in the
slapd.conf(5) manpage and in Chapter 7.

cyradm is usually run as an administrative shell
rather than a command per se; when you invoke
cyradm,
supplying your username plus the host you wish to administer, it
prompts you for a password, and on successful authentication it
begins an interactive session with its own commands and help screen.
(Note that cyradm may also be run
noninteractivelysee the cyradm(1) manpage
for information on using cyradm for scripting.) The simplest invocation of cyradm is:

cyradm --user username hostname If you're running cyradm on the
same host Cyrus IMAP is running on, you can use the hostname
localhost. If the server you wish to administer
is a remote host, however, specify its hostname or IP addresss; by
default, cyradm will attempt to connect to it
via TCP port 143. Since Cyrus IMAP uses this port for cleartext
communication, you'll want to use the
--port flag to specify TCP port 993 for
TLS-encrypted communications instead (e.g., --port
993). But personally, I find it simplest in such situations
to connect to my remote IMAP servers with ssh
and then to run cyradm
"locally" (on the remote host via
my ssh session).

Suppose I want to run cyradm locally on my IMAP
server and that my admin account is called
mick_admin. The command would look like Example 9-27.

Example 9-27. Running cyradm

bash-$ cyradm -u mick_admin localhost
IMAP Password: **********
localhost>

Note the localhost> prompt after successful
login: I'm now logged in to a
cyradm shell session. To see a complete list of
available commands, all I need to do is type ? or
help. There are 20 commands in all, and each can
be abbreviated (sometimes two different ways); the help screen lists
all versions of each command.

9.6.4.1 Creating mailboxes with cyradm

To create a mailbox, I can use the command
createmailbox, or I can use the abbreviation
create, or even just cm.
Example 9-28 shows just that.

Example 9-28. Creating a new mailbox

localhost> cm user.bwooster
localhost>

This is the very model of Linux command-line efficiency, but note
that the username corresponding to our new mailbox
isn't really user.bwooster;
it's simply bwooster. The
user. prefix must be used for all mailboxes you
create in Cyrus IMAP. Thus, to create a mailbox for the user
bubba, I'd use the command
cm user.bubba; to then create subdirectories of
that mailbox I'd use cm
user.bubba.sent, cm user.bubba.drafts,
etc.

This user. prefix is visible only to Cyrus and to
its administrators. In fact, when our user Bubba connects to the
server with Evolution or some other IMAP client, rather than
user.bubba he'll simply see a
folder named Inbox, even though its
"real" name is
user.bubba. Similarly, sub-mailboxes will appear
as sent drafts and so
forth, below and indented in from Inbox.

Another thing worth noting in Example 9-28 is the
lack of any feedback whatsoever from Cyrus upon successful completion
of our mailbox creation. If you're like me, you may
find this unnerving, so you'll periodically want to
use the listmailbox command, or
lm for short (Example 9-29).

Example 9-29. Listing Cyrus IMAP mailboxes

localhost> lm
user.bwooster (\HasNoChildren) Believe it or not, we've done all we need to do with
Cyrus IMAP itself for our user bwooster to be
able to receive and read his email (assuming there's
an LDAP record with a uid of
bwooster): in Cyrus IMAP, creating a new user
mailbox has the effect of creating that user's IMAP
account. But before I move on to the topic of configuring the Postfix
MTA to deliver email to Cyrus IMAP, a few words about Cyrus IMAP
ACLs.

9.6.5. Cyrus IMAP ACLs (and Deleting Mailboxes)

Each mailbox in a Cyrus IMAP
system can have one or more ACLs associated with it, in which each
ACL defines which actions a given user may perform on the referenced
mailbox or folder. By default, a new mailbox has only one ACL, one
that grants the mailbox's owner full administrative
rights over the mailbox.

Interestingly, you as an administrator have, by default, only
"lookup" and
"administer" rights on the new
mailbox: you can look up the name of the mailbox using the
listmailbox command, and you can set ACLs on it.
But if you need to delete the mailbox, you must first create an ACL
for the mailbox that grants your administrative account
administrative rights. This is a feature, not a bug: it helps prevent
things from getting deleted accidentally.

Continuing our running example, Example 9-30 shows
the commands for removing the mailbox we just created, using our
administrative account mick_admin.

Example 9-30. Deleting a mailbox

bash-$ cyradm -u mick_admin localhost
IMAP Password: **********
localhost> setaclmailbox user.bwooster mick_admin all
localhost> deletemailbox user.bwooster The second command issued in Example 9-30 is of
particular note: it begins with the cyradm
command setaclmailbox, which may also be
abbreviated as sam or
setacl. This is followed by the mailbox in
question (user.bwooster), in turn followed by
the account name to which we wish to grant (or deny)
accessmick_admin in this case. Finally
comes either a group of permission codes or a special string; in
Example 9-30, we have the special string
all which is, obviously, short for
"all permissions." For purposes of
deleting the user.bwooster mailbox, it would
have been sufficient to specify just c, short for
"create or delete mailbox or
sub-mailboxes." Possible ACL permissions are listed in Table 9-2.

ACLs are covered in detail in the cyradm(1)
manpage and are explained in Cyrus IMAP's HTML
documentation. I highly recommend that you get into the habit of at
least reviewing, if not always customizing, the ACLs on each mailbox
you create with cyradm. For example, for some
sites it may not be necessary for users to retain the default
permission c; if all sub-mailboxes
(user.whomever.sent,
user.whomever.saved, etc.) are created for them
by you, you may prefer that they not have the ability to create new
ones or to accidentally delete them.

9.6.5.1 Configuring Postfix to deliver mail to Cyrus IMAP

I've described the role of Mail Delivery Agents
(MDAs) as delivering mail to mailboxes. Cyrus IMAP, being an MDA, can
deliver mail, but it must first receive that mail from some Mail
Transport Agent. Since Postfix is my MTA of choice and since
it's available either as the default MTA or as a
Sendmail replacement in most major Linux distributions nowadays,
that's the one I'll cover in detail
here.

Configuring Sendmail to deliver mail to Cyrus IMAP isn't that big a deal; it mainly boils down to enabling and configuring flags for the cyrusv2 mailer in sendmail.mc. Sendmail's own documentation describes how to do this, but if you run into trouble, there are some good hints in the Cyrus IMAP Server Installation FAQ (http://asg.web.cmu.edu/cyrus/imapd/install-FAQl#sendmail).

Does your IMAP server need to reside on your
organization's SMTP relay? It can, but it
needn't: it may make more sense from the standpoints
of security and performance to keep your SMTP relay dedicated to that
purpose and have your IMAP server run its own instance of Postfix (or
Sendmail, etc.) that receives mail from the dedicated SMTP relay
rather than directly from other networks' MTAs. In
either case, we assume the MTA that IMAP receives its mail from is
running on the same host as Cyrus IMAP.

There are three files we need to edit in order to configure Postfix
to transfer mail to Cyrus. First, in
/etc/postfix/main.cf we need to add or uncomment
this line:

mailbox_transport = cyrus The second file we need to edit is
/etc/postfix/master.cf, in which we need to add
or uncomment these two lines:

cyrus unix - n n - - pipe
user=cyrus argv=/usr/libexec/cyrus/deliver -r ${sender} ${user} Actually, the second line may differ on your system; the syntax of
Cyrus's deliver program has
changed over the years. If you installed both Cyrus IMAP and Postfix
from your Linux distribution's current CDs or
download site, the included
/etc/postfix/master.cf file should work without
tweaking. If you installed either Cyrus IMAP or Postfix from source
code, however, you may need to do some tweaking and Googling to get
the second line just right. One key piece of the second line is the
path in argv=/usr/libexec/cyrus/deliver, which
must point to your local system's Cyrus
deliver command.

The third and final Postfix file to edit is
/etc/aliases (you may keep yours in
/etc/postfix/aliases). Unless
you're using LDAP for alias lookups (which I
describe, in general terms, in the sidebar "Postfix
and LDAP"), you'll need to have at
least one entry in aliases for each Cyrus
mailbox, plus any additional aliases used by those mailboxes.

For example, for our sample user Bubba,
/etc/aliases will need the line:

bubba: bubba Simple enough, right? Note that in /etc/aliases
entries we omit the mailbox's user.
prefix. Note also that if your Cyrus (LDAP) usernames
correspond to local system usernames, you don't need
aliases entries for those users, but part of
Cyrus's attraction lies in its not requiring users
to have shell acounts.

If Bubba is our organization's marketing analyst, we
can also add this line to /etc/aliases:

marketing.weasel: bubba After you edit your aliases file,
don't forget to use the
postalias command to generate a new alias
database:

bash-$> postalias hash:/etc/aliases

9.6.5.2 Next steps

That's not all you need to know in order to be a
Cyrus IMAP administrator, but it's hopefully enough
to get you started in building an LDAP-enabled Cyrus IMAP server.
Besides the topics we've covered or touched on here,
you'll probably want to figure out some of the
following:

How to let users change their own (LDAP) passwords.

How to let users use the LDAP server as an address book.

How to securely set up shared IMAP folders.

How to set up a secure webmail interface, such as SquirrelMail, with
Cyrus IMAP. (This is easy: most Linux distributions now include a
SquirrelMail package, and SquirrelMail is one of those rare
applications that "just works.")
See the "Resources" section at the
end of this chapter for pointers to more information.