Howto: LDAP Aliases on Courier

We decided to setup a mail server based entirely around the courier suite of mail applications on debian. This should end the incessant problems we are having with our poorly designed Qmail based mail server, hopefully.

Step 1 was to get user authentication working (via LDAP) against our local Domain Controller/Active Directory box - so far, so good (I’ll be sure to describe that struggle in another post).

Step 2 was getting the Aliases setup, which was a bit more involved.

We installed a local copy of openldap and courier’s ldap plugins using apt-get:

sudo apt-get install slapd courier-ldap

Next, to delete all the example data that came with openldap (NOTE: This will remote the contents of your ldap data folder! If you have anything important in there, back it up first!)

cd /var/lib/ldap/ && sudo rm -rf *.* alock

We’ll go ahead and import the base ldap structure. Referencing some old ldap data, we came up with this dump for the domain ‘example.local’, and stored it in /root/base.ldif :

dn: dc=example,dc=local
objectClass: top
objectClass: dcObject
objectClass: organization
o: example
dc: example
structuralObjectClass: organization

dn: ou=aliases,dc=example,dc=local
objectClass: top
objectClass: organizationalUnit
ou: aliases
structuralObjectClass: organizationalUnit

Great! Let’s load it in the into ldap!

sudo slapadd -vv -f /root/base.ldif

Now, the data is loaded inside of ldap, but all the physical data files are owned by root. Assuming ldap is running as the user ‘openldap’ on your system, let’s chown them:

sudo chown -R openldap: /var/lib/ldap/

Great. Let’s generate an admin password

slappasswd
New password: <hidden>
Re-enter new password: <hidden>
{SSHA}d5+W6qGRDcMbsnIAvYasklajdklaO7N3Kby

Copy that last line, and let’s start editing your openLDAP configuration file, slapd.conf

sudo vi /etc/ldap/slapd.conf

Find the following items, and change them as needed:

suffix      "dc=example,dc=local"
rootdn      "cn=admin,dc=example,dc=local"
rootpw      {SSHA}d5+W6qGRDcMbsnIAvYasklajdklaO7N3Kby
index           mail,objectClass eq

(Note: your ‘rootpw’ should be different from above. Also, look through the rest of the file for any mention of "dc=nodomain" and replace it with "dc=example,dc=local", or whatever your LDAP base is.)

Awesome!

Now, by default Courier bases its mail aliasing on a few different attributes, some of which are nonstandard or undefined. To fix this, we’ll create a quick schema file of our own. On Debian the schema files are stored in /etc/ldap/schema/, so we’ll create a new one named ‘local.schema’:

sudo vi /etc/ldap/schema/local.schema

# Copied and pasted from the 'mail' attributetype,
# with a different OID, Name, and Desc
attributetype ( 0.9.2342.19200300.100.1.3.1
        NAME ( 'maildrop' )
        DESC 'Courier alias, will be used to deliver mail to'
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

# Subclass of inetOrgPerson, with a different
# OID, Name, Desc, and MUST
objectclass     ( 2.16.840.1.113730.3.2.2.1
    NAME 'courierAliasPerson'
        DESC 'Courier mail alias person'
    SUP organizationalPerson
    STRUCTURAL
        MUST (  mail $ maildrop )
        MAY (
                audio $ businessCategory $ carLicense $ departmentNumber $
                displayName $ employeeNumber $ employeeType $ givenName $
                homePhone $ homePostalAddress $ initials $ jpegPhoto $
                labeledURI $  manager $ mobile $ o $ pager $
                photo $ roomNumber $ secretary $ uid $ userCertificate $
                x500uniqueIdentifier $ preferredLanguage $
                userSMIMECertificate $ userPKCS12 )
        )

Save and exit your editor, then add this new schema file near the top of your slapd.conf, underneath the existing schema declarations:

# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
# Our new courier schemas
include         /etc/ldap/schema/local.schema

Let’s go ahead and import 1 alias for testing. If 1 works, they all should work!

cat <<__EOD__ >/tmp/testalias.ldif
objectClass: top
objectClass: courierAliasPerson
cn: bob
sn: bob
mail: bob@example.local
maildrop: my-email-address@gmail.com
__EOD__

sudo slapadd -vv -f /tmp/testalias.ldif
sudo chown -R openldap: /var/lib/ldap/

At this point we are done with the local ldap stuff for now. Let’s mess with courier’s ldap alias config file, stored at /etc/courier/ldapaliasrc . This is what mine ends up looking like, minus all the comments:

LDAP_ALIAS              1
LDAP_SERVER             localhost
LDAP_PORT               389
LDAP_NUMPROCS           5
LDAP_BASEDN             ou=aliases, dc=example, dc=local
LDAP_BINDDN             cn=admin, dc=example, dc=local
LDAP_BINDPW             my_awesome_password
LDAP_TIMEOUT            5
LDAP_MAIL               mail
LDAP_MAILDROP           maildrop

Replace the LDAP_BASEDN, LDAP_BINDDN, and LDAP_BINDPW appropriately. Note, the LDAP_BINDPW is your password in plain text, so make sure this file isn’t world readable!

If you were to start all of your services (slapd, courier-mta, courier-ldap, etc) right now, would it work? NO! Instead, you would get this mysterious error message:

Jul  8 00:56:09 localhost courieresmtpd: error,relay=::ffff:127.0.0.1,
ident=user,from=<testuser@gmail.com>,
to=<bob@example.local>: 400 Service temporarily unavailable.

No details at all. This error message shows up because the ‘courierldapaliasd’ daemon is not running. Let’s fix that, and make sure the service starts up properly in the future.

ln -s /usr/sbin/courierldapaliasd /etc/init.d/
update-rc.d courierldapaliasd defaults
/etc/init.d/courierldapaliasd start

One last thing - if you have been following along, you might notice I didn’t start the other services. Let’s do that too.

/etc/init.d/slapd start
/etc/init.d/courier-mta start
/etc/init.d/courier-ldap start
/etc/init.d/courier-imap start
/etc/init.d/courier-authdaemon start

There we have it. You should be able to send a message to our test user ‘bob@example.local’, and it will forward to the email address you specified. From this point forward you can populate your ldap database with similar entries.

Keep in mind that each courierAliasPerson entry can have a potentially unlimited number of ‘maildrop’ attributes.

Wanna test it? (everything I typed in appears in bold)

examplemail01:~# telnet localhost 25

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 [examplemail01] [UBE Prohibited] Go ahead...
HELO fakehelo

250 examplemail01 Ok.
MAIL FROM: <fakename@gmail.com>

250 Ok.
RCPT TO: <bob@example.local>

250 Ok.
DATA

354 Ok.
Hi!

.

250 Ok. 4872CE5A.00005C7B

My logs show the sweet alias success that I crave.

Jul  7 19:18:08 localhost courierlocal: id=00003F83.4872CE5A.00005C7B,
from=<fakename@gmail.com>,addr=<my-email-address@gmail.com>,
size=187,success: Message delivered.

Hope this saves some time for the rest of you out there