Introduction
Courier is a modular multiprotocol mail server that's designed to strike a
balance between reasonable performance, flexibility and features.
Features
- Can be configured to function as an intermediate mail relay, or as a
mail server that receives mail for multiple domains and makes it
accessible to mail clients, or anything in between.
- Web-based administration and
configuration tool .
- Local mailboxes can be accessed via POP3. Courier includes an
integrated POP3 server.
- Local mailboxes can be accessed via IMAP. Courier includes an
integrated IMAP server.
- A built-in IMAP/POP3 aggregator proxy. It is possible to distribute all
mailboxes between multiple servers. A separate server (or a pool of
servers) accepts connections from IMAP or POP3 clients, then connects to
the right server based on the mailbox the connecting client is logging
into.
- Local mailboxes can be accessed via HTTP. Courier includes an integrated webmail server.
- The webmail server includes a personal event
calendar.
- Uses an efficient maildir format as
its native mail storage format. Some support is provided for legacy mbox
mailboxes.
- Flexible "Sender Policy Framework" support; the ESMTP
HELO
, MAIL FROM
, and the From:
header can be validated using SPF.
- DSN, PIPELINING, and 8BITMIME ESMTP extensions. Courier automatically
converts 8-bit messages to 7-bit encoding, for relaying mail to external
mail gateways.
- STARTTLS ESMTP extension (as well as IMAP/POP3/ESMTP/Webmail over SSL)
in both the client and the server (requires OpenSSL). The ESMTP client
can optionally require that the remote server's X.509 certificate is
signed by a trusted root CA (a default set of root CAs is provided).
- Experimental TLS/SSL enhancements which are designed to implement a
secure mail delivery channel between trusted domains, over an untrusted
network. This is implemented by requiring mail to select domains use
TLS/SSL connections which require the remote server to present an X.509
certificate signed by a private (not a public) certificate authority.
This is pretty much the highest level of security that can be achieved
with today's technologies. This doesn't even require DNSsec. Even if the
DNS cache is poisoned with MX records that divert mail to a rogue relay,
the attacker will not have an X.509 certificate signed by a private CA
(this assumes, of course, that the security of the private CA hasn't been
breached). This work is mostly complete, but still needs a little
testing.
- Message submission protocol (RFC 2476).
- IPv6 support (experimental).
- NOTE: the integrated servers work with maildir-based mailboxes only.
There are many existing POP3, IMAP, and webmail servers that provide
excellent support for mbox-based mailboxes, so there's no reason to
reinvent the wheel. Some popular mbox servers are: Qpopper, UW-IMAP, and NeoMail.
- A faxmail gateway (experimental) that forwards E-mail messages via fax
(requires a compatible class 2 faxmodem). Courier doesn't implement the
actual faxing all by itself, actually. Courier uses additional software
(which must be separately installed), to take care of the low-level
details. The popular mgetty+sendfax package talks
to the faxmodem and handles the actual faxing. Conversion of E-mail
messages to fax pages is done by ghostscript, troff or groff, and the NetPBM library.
Courier glues all of these pieces together in a seamless manner any time
an E-mail message addressed to <phonenumber@fax> is
received. The main textual body of the E-mail message is placed on a
cover page, and any attachments are converted to fax image format and
transmitted after the cover page. At this time, Courier knows how to send
plain text, PDF, and Postscript attachments. GIF, JPEG, and PNG images
can be sent to (one image per page). The additional software packages
that were mentioned previously are usually already included in most Linux
and BSD installations. In most cases no additional software really needs
to be installed in order to get faxmailing up and running.
- Courier includes a mailing list manager, with fully automatic bounce
processing.
- You don't need a full-blown mail server? Courier's IMAP server, webmail
server, and mail filter are available
as independent packages that can be used with other mail servers (as long
as the other mail servers store mail in maildirs). These
sub-packages are assembled from the same source code tree. The only
difference is the top level makefile. Note: the independent builds are
not always in sync with the main Courier build at any given time. They
follow their own schedule, and may include a slightly older, or even more
recent, code base! Over time, however, everything always syncs together
since all builds are assembled from the same source code repository.
- SOCKSv5 support. Courier can punch through a SOCKS firewall to send
outgoing mail. Receiving mail through a SOCKS firewall is not yet
supported. To use SOCKS you need to install Courier's Socks 5 proxy
client library.
- PAM, LDAP, PostgreSQL (beta), or MySQL authentication. LDAP
authentication requires OpenLDAP to be installed. LDAP-based
mail routing is also supported.
- Gateway mail to/from UUCP (if compatible UUCP software is separately
installed).
- Authenticated SMTP.
XVERP
and XEXDATA
ESMTP extensions.
- DNS-based blacklists. Ability to exempt whitelisted IP addresses from
the blacklists.
- Integrated mail filtering. An API is provided for installing arbitrary
external mail filters, and the system administrator can selectively
enable for any mail source (ESMTP, UUCP, locally submitted mail) for
filtering. Two example mail filters are included - one written in C that
uses threads, and a Perl-based filter. The system administrator can also
enable the ability for individual mail recipients to specify their own
mail filtering rules, using a scripting language (implemented by
maildrop
, see below). Mail filtering is implemented as an
integral part of the mail server. Unwanted mail is rejected, and is not
accepted by Courier for delivery (the external mail relay receives the
error, and it becomes the external relay's problem as to what to do with
unwanted junk mail).
- Partial ability to import
sendmail
's aliases file, but not
all aspects of sendmail
's aliasing is supported - like
delivering to programs, for example. Still, most simple
aliases
files should be usable.
- Optional ability to import most of
Qmail
's
.qmail
files (Courier uses an almost 100% compatible local
mail delivery instruction format).
- Most major components of Courier can be installed in non-default
directories, allowing extreme customization for your particular
environment.
- You can set a maximum number of messages to deliver simultaneously to
the same host. This, in fact, is strongly encouraged so that a single
nonfunctioning domain does not take up all available delivery slots. Rate
limiting is implemented in the main scheduler, and applies to any
transport mechanism, not just ESMTP.
- Mailing list administrators can specify a backup relay and have mail
that's not immediately deliverable offloaded to a backup server (this
feature needs testing/feedback).
However, it is also important to note what Courier does not have or will
not support:
.forward
files are partially supported. Courier can import
most basic /etc/aliases
files from sendmail, but sendmail's
.forward
and /etc/aliases
files are simply not
100% compatible with Courier's security model. Most .forward
and /etc/aliases
files should be acceptable, but some may
not.
ETRN
is not, and will never be implemented. It's a hack,
and is functionally incompatible with Courier's internal message
dispatcher. If a mail node does not have constant network connectivity,
there are better ways of arranging for mail transport than ETRN. The
transient mail node should download mail via IMAP, or maybe even UUCP.
- Workarounds for known defects in other mail software. Courier will not
accept mail with raw 8-bit characters in the headers, because they are
illegal. There are well-defined protocols that must be used to encode
8-bit text in mail headers. Non-compliant messages may result in Courier
itself issuing corrupted delivery status notifications, or mishandling
the message in several other ways. Because of that corrupted mail will
simply not be accepted. Neither will Courier deliver mail to domains with
improperly-defined MX records, even though other mail servers ignore the
bad data. Additionally, certain popular IMAP mail clients are known to
not work with Courier's IMAP server, due to an improper IMAP
implementation by the mail client.
- Scripting language for rewriting mail headers. Mail rewriting rules are
hardcoded, and are expected to be sufficient in most cases. If you have
an unusual situation that requires some oddball header rewriting, you'll
have to implement it yourself.
- Support for mbox mailboxes in the POP3, IMAP, and webmail components.
They support maildirs only. There are plenty of existing servers out
there that read mbox mailboxes.
Requirements
- A C++ compiler,
egcs
is recommended. Most of Courier are
written in C, but several major sections are written in C++.
- GNU make. Other
make
s may work, but that's not
guaranteed.
- Either the GDBM or Berkeley DB library must be available. Only certain
versions of Berkeley DB API are supported, because the Berkeley DB API
often changes (tested with 2.4.14 and 1.8.5). GDBM is the recommended
library.
- Perl 5.
- The file system must support FIFOs. At least the file system that
stores the mail queue must be able to support FIFOs. Courier will not
work with AFS.
- Filesystem domain sockets must be available.
- Some optional components have additional dependencies - notably the
additional software required for faxmail support (see above).
Additional information
Here is a somewhat more detailed overview of Courier's less prominent
features:
Upgrade path
Courier can be installed on systems that were previously running sendmail or
Qmail. Please note that Courier will be able to support most major features
of both servers, however Courier is not, and will never be a 100%-compatible
replacement for either sendmail or Qmail. Courier does not implement several
legacy features of either MTA, and there are no plans to implement them in
the future. The key differences are:
A local mail delivery agent, such as procmail
, should be used
for maximum compatibility with sendmail.
Courier expects system mailboxes to be in the users' home directories. If
your system mailboxes are all stored separately, in
/var/spool/mail
or somewhere else, you'll need to use a local
delivery agent such as procmail
.
Courier uses a filesystem lock on mailbox files, Courier does not support
old-fashioned dot-locking. If you need dot-locking, use procmail
or maildrop
(included).
A configuration switch allows Courier to read $HOME/.qmail
files, however Courier's implementation is not 100% identical to Qmail's.
Courier's aliases
file is also used to implement Qmail-style
virtual domains. A simple Perl script can be used to convert Qmail's
control/virtualdomains
into aliases
entries.
Courier supports Maildirs natively.
Courier can use the maildrop
mail filter as a local mail
delivery agent. maildrop
is optional, but, if used, Courier will
take advantage of certain maildrop
-specific features which
optimize local mail delivery.
Mail filters
Courier has hooks for optional, site-defined, mail filters. You'll have to
write them yourself, though. The administrator-defined mail filters can block
the message from being accepted by Courier (if messages comes in via SMTP,
the SMTP server will reject it). Courier can also be configured to pause for
a short period of time before attempting to deliver a message. If the mail
filter detects a slew of duplicate messages coming in, the mail filter can
block all future copies, and manually bounce the handful of copies from the
queue. The system administrator can selectively enable filtering for any
individual mail source (ESMTP, locally submitted mail, UUCP). The system
administrator can also optionally enable recipient-specified mail filters.
With recipient-specified mail filtering enabled, any local mail recipient can
install an arbitrary mail filter to selectively accept or reject mail based
on any criteria.
Currently the mail filtering API is not very well documented, but it's
there.
ESMTP extensions
Courier implements AUTH
, PIPELINING
, DSN
, SIZE
, and
8BITMIME
extensions to SMTP. Courier also includes a reference
implementation of the experimental XVERP
and
XEXDATA
extensions.
Courier is a closed mail relay by default. Courier cannot be accidentally
configured as a completely open relay. A deliberate feat of stupidity is
required for that to happen.
ESMTP BOFH
Courier does not deliver mail to domains with broken MX records. Courier also
refuses to accept any mail with a return address in a domain with broken MX
records.
Courier can automatically blacklist domains whose mail servers reject
delivery status notifications.
Header rewriting
Courier will rewrite headers and MIME-ify messages whenever appropriate.
Header rewriting logic is hardcoded in C, there is no header rewriting
language as in sendmail. An interpreted language imposes a drastic speed
penalty. The rewriting library is fairly simple, and the the standard
rewriting rules will do for most situations.
Courier rejects messages with badly-formed or missing MIME headers.
Courier rejects messages containing 8-bit characters in the headers, or
messages that contain 8-bit content, but do not have the required MIME
headers. Accepting malformed messages of that kind can result in Courier
itself sending mail that violates the relevant RFCs, therefore Courier will
simply reject improperly-formatted messages. There are well-defined RFC
standards that explicitly spell out how mail containing 8-bit content or
8-bit headers should be encoded, and those standards will have to be properly
implemented by anyone that wishes their mail to be accepted.
Modularity
Message scheduling, dispatching, and the actual transport mechanism are
completely modularized. Different message transport mechanisms such as UUCP
can be implemented in a simple plug-in fashion, however some C coding will be
required.
Message scheduling
Courier supports VERPs, multiple recipients per message, and
RFC1894-compliant delivery status notifications.
Load limiting
You can set a maximum number of messages to deliver simultaneously to the
same host. This, in fact, is strongly encouraged so that a single
nonfunctioning domain does not take up all available delivery slots. Rate
limiting is implemented in the main scheduler, and applies to any transport
mechanism, not just ESMTP.
Automatic restarts and garbage cleanup
Courier's scheduling engine restarts itself automatically, on a regular
basis. This helps with memory fragmentation. Courier tries to restart itself
during periods of system inactivity.
Smart organization of the message queue and temporary directories
Courier automatically creates subdirectories when necessary, and deletes them
when they're empty. When there's a sudden peak in the number of messages
added to the queue, directories used to store the messages grow in size to
accomodate the additional entries. On many file systems, once those messages
are deleted, the empty slack space in the directory is not reclaimed, and
actually slows down subsequent directory operations. Courier automatically
removes empty directories, reclaiming the slack space.
Smart installation layout
Courier's configuration script will install Courier into
/usr/lib/courier
by default. Everything will go into several
subdirectories there: the actual binaries, configuration files, the mail
queue, manual pages, and auxiliary support files. Optional configuration
switches allow pretty much every major subdirectory to be relocated anywhere
else. For example, the Red Hat RPM package for Courier relocates the
configuration files to /etc/courier
, the manual pages to
/usr/man
, and the mail queue to
/var/spool/courier
.
Mailing lists
Courier can implement both sendmail and qmail-style address aliases.
De-duping of sendmail-style aliases is automatic. Courier source distribution
also includes a complete mailing list manager.