Large-Scale Mail with Postfix, OpenLDAP and Courier

Setting up an SMTP mail server for multiple domains on a single machine with remote access via IMAP.

Although this article provides instructions on setting up an integrated mail server using Postfix, OpenLDAP and Courier-IMAP, it does not discuss how these software components were chosen, which could be a whole article in and of itself. The goal is to set up an SMTP mail server for multiple domains on a single machine with remote access via IMAP. Also, instead of having mail delivered only to people with shell accounts, we want to have IMAP accounts that do not have a corresponding shell account. This gives rise to two classes of accounts: local and virtual. Local accounts are those with shell access. They use their shell user name and password to access IMAP. Virtual accounts have a user name and password that only works for logging in to IMAP. The terms local and virtual are used throughout the rest of the article.

The Big Picture

Figure 1 shows how Postfix, Courier, Procmail and OpenLDAP interact. Local account information is stored in /etc/password, and authentication is handled by pluggable authentication modules (PAM). Virtual account information is stored in an LDAP directory. LDAP provides both account lookup and authentication capabilities. It is possible to avoid an LDAP directory, but it will be more difficult to administer the virtual account information. For example, Postfix and Courier both support virtual accounts using configuration files, but they have different file formats.

Postfix accepts incoming mail from SMTP. It will reject any mail for unknown accounts, both local and virtual. It delivers the mail itself for virtual accounts and uses Procmail as the MDA for local accounts. Courier provides remote access to the mailboxes via the IMAP and POP protocols.

Figure 1. Overall Design

Mailbox Location

A local account's mail is stored in its home directory at ${HOME}/Maildir/ in the Maildir format. It is standard practice for Maildir delivery to go into the account's home directory rather than /var/spool/mail. Both Postfix and Courier work out of the box with this standard behavior.

Unlike local accounts, there is no standard location for virtual accounts' e-mail. We created a single UNIX account, called vmail, that holds the mail for all the virtual accounts. Each virtual domain has a subdirectory within the ~vmail/domains/ directory. For example, if there is an account <john@example.com>, mail would be stored in ~vmail/domains/example.com/john/ in maildir format. You can also spread virtual accounts across multiple UNIX accounts, for example, by creating a UNIX account for each virtual domain.

LDAP Directory Design

There are many possibilities when designing your directory, and not all aspects of this topic are covered here. One useful reference is the iPlanet Deployment Guide (see Resources). This article assumes you are familiar with LDAP concepts and terminology. You should take the time up front to design a tree that matches your specific requirements.

Tree Structure

Figure 2 shows a sample directory tree for a web hosting company. The company's domain name, myhosting.example, was chosen as the root suffix. Postfix and Courier both search the o=hosting,dc=myhosting,dc=example subtree for e-mail information. The o=accounts,dc=myhosting,dc=example subtree shows how you could integrate shell account information for PAM into the same directory, but this is not necessary for setting up e-mail. Each hosted domain gets its own organization beneath the hosting organization. Each e-mail account goes under the domain's subtree. Thus, the distinguished name for the <user2@domain2.example> e-mail address is:

mail=<user2@domain2.example>,o=domain2.example,
 o=hosting,dc=myhosting,dc=example

This is a fairly stable design as accounts will never transfer between domains. The end result is good LDAP design, because moving subtrees can be troublesome in LDAP. The design is also quite flexible because each domain's tree can be tailored, if necessary. Each domain must have a postmaster entry that provides dual functionality. Its primary function is for access control, but it also acts as a forwarding e-mail address. Each domain also must have an abuse alias that forwards mail to the system administrator.

Figure 2. A Sample Directory Tree for a Web-Hosting Company

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What about procmail??

Atrillanes's picture

Have I missed something in your article? Or you have just omitted the part where procmail gets into the picture?

dn of the user objects

Ahmed El Zein's picture

Hi,
Why is the dn of the users mail=user@domain,o=domain,etc? would it not make more sense to have a dn of cn=user,o=domain,etc (like you did for the postmaster)?

The only reason I can think of if to be able to search through the whole tree by email address. wouldn't it be faster to separate user and domain and just search under the o=domain? especially if you have a huge amount of users for each domain?

Re: Large-Scale Mail with Postfix, OpenLDAP and Courier

Anonymous's picture

I don't see a reply to the previous comment. I'm having a similar problem.

Given the format of the cn=postmaster,o=domain1.example..., I suspect that objectClass: organizationalRole needs to be present.

Another question, however, is why are the "mail:" attributes empty? They are required fields and the LDAP server balks at there being no entry there.

Re: Large-Scale Mail with Postfix, OpenLDAP and Courier

Anonymous's picture

Since OpenLDAP 2.2 (I don't know if earlier too) LDAP entities must have "structural" object class. Classes top, CourierMailAccount, CourierMailAlias are "auxiliary" clasess. You should add to each entity "structural" class: domain, organization, organizationalPerson, etc.
So eg.

dn: dc=myhosting, dc=example
objectClass: top

should be

dn: dc=myhosting, dc=example
objectClass: domain
dc: myhosting

You can also change those objectClasses to STRUCTURAL

Darian's picture

...by modifying authldap.schema and replacing "AUXILIARY" with "STRUCTURAL" on the CourierMailAccount, CourierMailAlias, and CourierDomainAlias.

Keep in mind, however, that you can only have one structural objectClass, just in case you plan on hanging e-mail information off of an inetOrgPerson or somesuch.

Re: Large-Scale Mail with Postfix, OpenLDAP and Courier

Anonymous's picture

Hi, I'm trying to follow your example, but I'm having a couple of problems here...

in the first ldif (base.ldif), I had to take out all the first spaces in the lines, and when I try to make an ldapadd I'm getting:

dapadd: update failed: dc=myhosting, dc=example
ldap_add: Object class violation (65)
additional info: no structural object class provided

any suggestions?

Re: Large-Scale Mail with Postfix, OpenLDAP and Courier

Anonymous's picture

This article looks abandoned ... but .. I am having the same problem and really don't know what to do here.

Re: Large-Scale Mail with Postfix, OpenLDAP and Courier

Anonymous's picture

Dear friend

Hi and thanks for the solution provided by you
but do you have any solution for multiple servers running under one domain. with the helpof ldap server database replication.

regds
amit jain
amitldap@hotmail.com

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix