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.
Choosing a Schema

The schema defines which attributes an entry can have by defining object classes. None of the default schemas that come with OpenLDAP are really suited for entries used exclusively for e-mail mailboxes or forwarding. We are using the schema that Courier provides in its distribution. Another possible schema to look at is the schema distributed with the qmail-LDAP Project. You also can design your own schema, but be aware that you should use OIDs registered with the Internet Assigned Numbers Authority (IANA).

Courier Schema

The courierMailAccount object class, summarized in Table 1, is used for virtual e-mail accounts. The courierMailAlias object class, summarized in Table 2, is used for e-mail addresses that forward to another address.

Table 1. courierMailAccount

Table 2. courierMailAlias

The courierMailAccount object class does not exactly fit our needs. We do not need uidNumber and gidNumber because all mail goes to the vmail account. However, we must put in dummy values as the schema requires them. Note that these values would be meaningful if we were spreading virtual accounts over many UNIX accounts. We require the mailbox attribute, because it is needed to determine the location of the mailbox on the filesystem. The mailbox must end in a slash to indicate that it's a Maildir-style mailbox. The userPassword attribute also is required because all e-mail accounts must have a password in order to be accessed via IMAP or POP. We do not use the other optional attributes.

The courierMailAlias object class is a good fit for our needs. We use only the two required attributes and do not use either of the optional attributes. The maildrop attribute can be another e-mail address or a local account on this machine.

Access Control

OpenLDAP provides many possibilities for access control. By default, the root account has read and write access to all entries in the tree. We would like to delegate some of this administration to individual accounts in each hosted domain so they can do minor changes on their own without access to the root account. This is done by making the postmaster entry an organizationalRole with a roleOccupant attribute for each entry with administration privileges. OpenLDAP can then be configured to allow access only to members of this group.


This section describes how to implement a virtual mail solution. Not every little detail is covered, only what is needed above and beyond the standard installations.

Following is the list of software, with version numbers, with which we tested this configuration:

  • Red Hat Linux 6.2, 7.1, or 7.2

  • Postfix 1.1.x

  • OpenLDAP 2.0.21

  • Courier-IMAP 1.4.1

  • Procmail 3.22

You need to create the vmail account, and then create the ~/vmail/domains/ directory. You also need to create an account and two groups for Postfix as covered in Postfix's INSTALL documentation.

You do not need to follow any special instructions for compiling and installing OpenLDAP, so consult its documentation for instructions. For a production environment, read up on running OpenLDAP as a non-root account, setting up a chroot environment and replication. This article describes how to configure slapd for a single server, create the base tree structure and insert some basic data into the LDAP directory. Figure 2 shows the LDAP tree we set up here.

Configuring slapd

You need to make Courier's schema file available, so copy the file from authlib/authldap.schema in the Courier distribution to /usr/local/etc/openldap/schema/courier.schema. Courier's schema depends on cosine.schema and nis.schema. Add these lines to slapd.conf:

include   /usr/local/etc/openldap/schema/cosine.schema
include   /usr/local/etc/openldap/schema/nis.schema
include   /usr/local/etc/openldap/schema/courier.schema

Next, set up a database definition with the following lines in slapd.conf:

database      ldbm
directory     /usr/local/var/openldap-ldbm
suffix        "dc=myhosting,dc=example"
The database directive specifies the back-end type to use (use LDBM as the back-end database). The directory directive specifies the path to the LDBM database. Make sure the directory specified exists prior to starting slapd and that slapd has read and write permissions on the directory. The suffix directive specifies the root suffix for this database. The next few lines set up the superuser or root account:
rootdn       "cn=Manager,dc=myhosting,dc=example"
rootpw       {SSHA}ra0sD47QP32ASAlaAhF8kgi+8Aflbgr7
The rootdn entry has complete access to the database, which is why the password is stored outside the actual database. The password in rootpw should always be stored in hashed format. Do not store the password in clear text. To convert the clear text password secret to a hashed format, use the slappasswd command:
% slappasswd
New password: secret
Re-enter new password: secret
Take the output from slappasswd, and copy that into slapd.conf, as we did above.

To speed up searches, you should create indexes for commonly searched attributes:

index   objectClass  pres,eq
index   mail,cn      eq,sub

The last part in slapd.conf is the access control. The OpenLDAP FAQ contains good information on how you would set up postmaster as a group ACL.



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

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 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.

amit jain