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. Advanced groupware calendaring services will follow soon.

The Courier mail server's source code should compile on most POSIX-based operating systems based on Linux, and BSD-derived kernels. The Courier mail server should also compile on Solaris and AIX, with some help from Sun's or IBM's freeware add-on tools for their respective operating systems.

The Courier mail server evolved out of several related projects, that merged together (more on that later). The Courier mail server implements SMTP extensions for mailing list management and spam filtering. The Courier mail server can function as an intermediate mail relay, relaying mail between an internal LAN and the Internet, or perform final delivery to mailboxes. The Courier mail server uses maildirs as its native mail storage format, but it can also deliver mail to legacy mailbox files as well. The Courier mail server's configuration is set by plain text files and Perl scripts. Most of The Courier mail server's configuration can now be adjusted from a web browser, using The Courier mail server's web-based administration module.

The Courier mail server can provide mail services for regular operating system accounts. The Courier mail server can also provide mail services for virtual mail accounts, managed by an LDAP, MySQL, or PostgreSQL-based authentication database.

Certain portions of the Courier mail server - the mail filtering engine, the webmail server and the IMAP server - are also available as separate, smaller, packages that can be used with other mail servers.

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.
• On servers with multiple IP addresses, optionally assign a vanity configuration to Courier for each IP address, making each IP address look like a separate, dedicated, mail server instance, for both incoming and outgoing mail. An alternative limited vanity configuration for outgoing mail only, based on the sending mail client's authenticated login, is possible when multiple IP addresses are not available.
• Web-based administration and configuration tool.
• Local mailboxes can be accessed via POP3. The Courier mail server includes an integrated POP3 server.
• Local mailboxes can be accessed via IMAP. The Courier mail server 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. The Courier mail server 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. The Courier mail server 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). The Courier mail server doesn't implement the actual faxing all by itself, actually. The Courier mail server 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. The Courier mail server 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, The Courier mail server 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.
• The Courier mail server includes a mailing list manager, with fully automatic bounce processing.
• You don't need a full-blown mail server? Courier mail server'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 the Courier mail server 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. The Courier mail server 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 the Courier mail server'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 the Courier mail server 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 mail server uses an almost 100% compatible local mail delivery instruction format).
• Most major components of the Courier mail server 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 the Courier mail server does not have or will not support:

• .forward files are partially supported. The Courier mail server can import most basic /etc/aliases files from sendmail, but sendmail's .forward and /etc/aliases files are simply not 100% compatible with the Courier mail server'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 the Courier mail server'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. The Courier mail server 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 the Courier mail server 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 the Courier mail server 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 the Courier mail server'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.