The process on this page has been tested with Debian 6 x64.

This tutorial is intended to show you, step by step, the process of setting up a complete mailserver using Gandi hosting.

It will show you how to:

1. Install an LDAP server and the associated client utilities (OpenLDAP)
2. The installation of an electronic messaging server (Postfix)
3. Installation of binaries for SMTP authentication (Cyrus-SASL)
4. The installation of an IMAP and POP3 server (Dovecot)

The tutorial does not cover:

• The installation or management of a webserver (this is another topic)
• SSL security
• Securing an LDAP server and management of its permissions
• Advanced management of email accounts (quotas, etc)

These topics will be addressed in other tutorials.

Installing OpenLDAP isn't complicated; just run the following commands:

To become root:

su - root

apt-get install –y slapd

You will be prompted to create and confirm an LDAP password. Choose a complex password, preferably different from the administrator password of your machine.

Once you've entered and confirmed the password, the installation will continue and should complete on its own.

Once the installation is complete, it is necessary to configure the server a bit. To do this, enter the following command:

dpkg-reconfigure slapd

1. The first screen will prompt you to omit the OpenLDAP server configuration. Select <No.>
2. The second screen prompts you for the domain name for the DNS. It is preferable to use the bare domain (i.e. example.com) as opposed to a subdomain (i.e. ldap.example.com). This will be translated to an LDAP DN (for example, example.com would become dc=example, dc=com). This becomes what is known as your BaseDN, the root of your database.
3. The next screen asks you for the name of the organization. You can enter any string; this becomes associated with the o field of your BaseDN record.
4. Next, enter your LDAP administrator password twice. This will set the password for cn=admin, BaseDN and give cn=admin, BaseDN write access to everything in your LDAP tree. Note: this isn't the same account as the one you set up in the first step. While the account on the first step will have rights to the tree configuration, the administrator in this step has the rights to the domain (sub)tree.
5. The fifth screen prompts you to choose a database backend. Choose HDB.
6. The sixth screen asks if you want the database to be removed when slapd is purged. Choose <No>; this will come in handy if you accidentally uninstall the server (it happens to the best of us).
7. The seventh screen prompts you to move the old database files before creating a new database. Select <Yes>.

Upon submitting the last step, slapd will validate your configuration. If it is invalid, it will prompt you to retry. Make sure the organization is not left empty and the admin passwords match.

• If your input is valid, the following screen will ask if you want to allow the LDAPv2 protocol to be activated. If you want to be able to look consult your directory with old versions of Windows and/or Outlook, which don't support version 3 of the LDAP protocol, you can choose <Yes.. Otherwise, choose <No>.

Good job, you've made it through the initial configuration.

Run this command:

  apt-get ldap-utils

apt-get install -y ldap-utils

First, verify if, when connecting anonymously to the principal branch of your directory, you are able to access its data:

ldapsearch -x -h localhost -b "dc=example,dc=com" -LLL "dc=example" dn

A result like this should then appear:

dn: dc=example,dc=com

This result indicates that an anonymous user has the ability to access this branch of your directory (with some limitations). This is not preferable.

Listing the full contents of cn=config would be too much data to be helpful, so we will use a filter to get only the information we need.

slapd -V

# slapd -V
@(#) $OpenLDAP: slapd 2.4.23 (Jun 15 2011 13:31:57) $
    @incagijs:/home/thijs/debian/p-u/openldap-2.4.23/debian/build/servers/slapd

According to the OpenLDAP documentation, it appears that the entries containing the configuration of a tree are contained in olcDatabaseConfig-type entires, and that the DN (distinct name) of the tree is contained in the olcSuffix attribute. We will therefore display the data of the tree cn=config in applying the corresponding filter.

This command will display information on our tree's configuration (replace gandi101 and fr as appropriate):

ldapsearch -Y EXTERNAL -H ldapi:// -b cn=config "(&(objectClass=olcDatabaseConfig)(olcSuffix=dc=gandi101,dc=fr))"

The above command should produce results like the following:

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope subtree
# filter: (&(objectClass=olcDatabaseConfig)(olcSuffix=dc=gandi101,dc=fr))
# requesting: ALL
#

# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=gandi101,dc=fr
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=gandi101,dc=fr" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=gandi101,dc=fr" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=gandi101,dc=fr
olcRootPW: {SSHA}7j9LqSeTlwiWkODSi8dCpK1AUtfbMy/j
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: cn pres,sub,eq
olcDbIndex: sn pres,sub,eq
olcDbIndex: uid pres,sub,eq
olcDbIndex: displayName pres,sub,eq
olcDbIndex: default sub
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: mail,givenName eq,subinitial
olcDbIndex: dc eq

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

In this entry, we are primarily interested in the three olcAccess attributes and their respective values. In particular:

• to * (on the whole tree)
  • by self write (when your authentication corresponds to a directory entry, you have write permissions on this object)
  • by dn=“cn=admin,dc=gandi101,dc=fr” write (the administrator possesses write permissions on the whole tree)
  • by * read (the world has read access to the tree)

As you can imagine, the last part is what poses a problem (by * read), which can be replaced by by * none.

To do this, we will use another tool in the ldap-utils package: ldapmodify.

nano /etc/ldap/slapd.d/cn\=config/olcDatabase={1}hdb.ldif

/etc/init.d/slapd restart

Run the following command to create our temporary file (again, copy and paste from your own results and not from this tutorial):

cat > changeAccess.ldif << EOF
dn: olcDatabase={1}hdb,cn=config 
changetype: modify
delete: olcAccess
-
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=uncertaindomaine,dc=net" write by * none
-
add: olcAccess
olcAccess: {1}to dn.base="" by * read
-
add: olcAccess
olcAccess: {2}to * by self write by dn="cn=admin,dc=uncertaindomaine,dc=net" write by * none
-
EOF

As you can see, the only change is the replacement of “read by none” at the end of the last attribute.

Once the file is created (which you should double check for content), you can apply the changes in your database:

ldapmodify -c -Y EXTERNAL -H ldapi:/// -f changeAccess.ldif

The result should be similar to this:

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}hdb,cn=config"

Once this is done, check that anonymous access is extended:

ldapsearch -x -c -h localhost -b dc=uncertaindomaine,dc=net

The result should be something like:

# extended LDIF
#
# LDAPv3
# base <dc=uncertaindomaine,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

The “no such object” message indicates that the configuration is correct. The server is saying that there is no such object called uncertaindomaine dc =, dc = net. This is quite logical since the rules prevent anonymous access to this tree.

Let us now try connecting as administrator:

ldapsearch -c -h localhost -b dc=uncertaindomaine,dc=net -D "cn=admin,dc=uncertaindomaine,dc=net" -W

Once you enter the password, you should see something like:

# extended LDIF
#
# LDAPv3
# base <dc=uncertaindomaine,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# uncertaindomaine.net
dn: dc=uncertaindomaine,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: UnCertainDomaine
dc: uncertaindomaine

# admin, uncertaindomaine.net
dn: cn=admin,dc=uncertaindomaine,dc=net
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: passwordHashé

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

We see our results. Thus, we can consider the configuration of our tree as good.

Another configuration change is needed. We will extend the existing schema to accommodate the features of Postfix. While Courier is not going to be used as our PO/IMAP server, we will need to use the same LDAP extensions it offers. This will ensure standards compliance (RFC) and portability of our data.

apt-get install courier-ldap

The first (and last) prompt offers to install the necessary directories for web administration. Since we do not use Courier, you can say no, and just install the minimum.

We will extract the gzip, which contains the schema we want, and copy it to the directory containing the ldap schema.

gunzip /usr/share/doc/courier-authlib-ldap/authldap.schema.gz
cp /usr/share/doc/courier-authlib-ldap/authldap.schema /etc/ldap/schema

We will now see a second method to change the configuration of OpenLDAP, namely, slaptest.

Before we do this however, we need to know what schema is already included in OpenLDAP. To do so, we will go through the base cn = schema, cn = config in our tree, and limit the review to the cn attribute (Common Name) as this is where the entries for the schema are provided. The result should be easy to understand. Also in order to make the schema more understandable, and let you discover more about the ldapsearch command, we will also use the -LLL option. This will allow us to delete comments and Ldif versions. So our command will be:

ldapsearch -Y EXTERNAL -H ldapi:// -b "cn=schema,cn=config" -LLL "(objectClass=*)" cn

The results should look something like:

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=schema,cn=config
cn: schema

dn: cn={0}core,cn=schema,cn=config
cn: {0}core

dn: cn={1}cosine,cn=schema,cn=config
cn: {1}cosine

dn: cn={2}nis,cn=schema,cn=config
cn: {2}nis

dn: cn={3}inetorgperson,cn=schema,cn=config
cn: {3}inetorgperson

Looking at our results, we can conclude that OpenLDAP includes four patterns in this example configuration, namely core, cosine, nis, and inetorgperson. We also need to add the Courier extension that we just added to the directory /etc/ldap/schema

So let's create a file that will include all these schema (those already present, and the additional Courier).

mkdir /tmp/ldapConfig
cat > /tmp/ldapConfig/schemaInclude.conf << EOF
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/authldap.schema
EOF

Now run the slaptest command, which will convert the ldif formatted file so it can be included in our configuration.

But before that we will actually need to edit the file authldap.schema which contains a small error (at least in my version) .

In this file, it describes the purpose of CourierMailAccount type by indicating it may contain an attribute of type mailhost. The description of this attribute, which is just above the code, is commented out. We have two options, remove this attribute CourierMailAccount, or uncomment the section describing this attribute. For purely arbitrary reasons, I chose the latter option. I suggest you to edit the file /etc/ldap/schema/authldap.schema, and remove the # in front of the first 4 Commented lines, the ones describing the attribute. Note that the line that starts with Objects lines: 1.3.6 […] should be kept.

Once the file is edited, run the slaptest command:

slaptest -f /tmp/ldapConfig/schemaInclude.conf -F /tmp/ldapConfig

This command should normally send you a success message.

The slaptest command created an entire tree for us in the /tmp/ldapconfig directory. I encourage you to go to the directory containing your schema and check the content:

cd /tmp/ldapConfig/cn=config/cn=schema
ls –l

You'll notice the presence of a file cn = {x] authldap.ldif (where x is a variable integer in my example, it is 4). We will make some changes to this file. Open it with your preferred editor, for example using one of the following two commands:

vi cn={*}authldap.ldif

Or

nano cn={*}authldap.ldif

The first editor (vi) is a very powerful editor, and will be installed by default on any Linux-based machine. As for nano, it is a very intuitive alternative, useful for the uninitiated. It's usually installed by default on Debian and derived distributions (Ubuntu, …). The navigation is very intuitive (arrows) and editing is as well. However, nano show its limits when you have to make complex changes. An example? You will see the following issue:

Line 1 and Line 3, delete the parts {x} (brackets included). In fact, there are numbers that your server will automatically assign in function dependencies, we do not want to comment on that.

On the first line, fill in the path name, adding:

,cn=schema,cn=config

Now go to the end of the file (with vi, type G, with nano keep pressing the down arrow)

We will delete the last seven lines, which our LDAP server will have automatically generated. In VI, just type 7dd.

Save and exit (in vi, type :wq).

Currently, you have your file cn = {x} authldap.ldif, ready to be imported into your LDAP configuration. To do this, run the ldapadd command, whose syntax is similar to ldapsearch and ldapmodify.

ldapadd -Y EXTERNAL -H ldapi:// -f /tmp/ldapConfig/cn=config/cn=schema/cn={4}authldap.ldif

Normally, if all goes well, this command should confirm that an entry has been added. We will check it by running the previous command:

ldapsearch -Y EXTERNAL -H ldapi:// -b "cn=schema,cn=config" -LLL "(objectClass=*)" cn

Normally you should see the authldap schema as output.

Now, we need to remove the packages we installed with courier-ldap, namely:

apt-get purge –y courier-ldap courier-authlib courier-authlib-ldap courier-base courier-doc

Now, before you install Postfix, we will create entries for the email addresses that you want to create initially. We decided to use the following configuration for demonstration purposes:

vargisj@uncertaindomaine.net

vargisj@uncertaindomaine.com

vargisj@uncertaindomaine.org

These three addresses are the same. That is, we want to be able to connect with the login of these three addresses, and have the e-mails they are sent go to the same mailbox. To configure this, we will create three different email accounts, but all with the same directory for storing messages. I could choose to have several mail attribute details per entry (which works fine), the only concern is that for consistency, with a tree deployed, I prefer to have a separate entry for each mail account to expose the list of existing emails.

admin@uncertaindomaine.net

admin@uncertaindomaine.com

This will create a new account for this email address.

all@uncertaindomaine.net

As its name (all) suggests, this email address is used to send an email to everyone in the tree. So when you send an email to all@uncertaindomaine.net, it will send an email to admin@uncertaindomaine.net, vargisj@uncertaindomaine.net (the other two vargisj do not interest us, since a mail to vargisj@uncertaindomaine.net also automatically sends the mail to the other two).

In my main tree, you will notice I created an email tree that will contain everything. Why? Well, because we may have to have other things in our directory. Thus, having an email tree allows us to have better sorting if needed in the future.

There are many options for organizing your tree. In this e-mail tree, I chose to have one entry per field. Some people (take the example of iRedAdmin to name one) store all fields in one tree, and all the email accounts in another. My choice was for convenience of working with the LDAP directory. Eventually, I may want to restrict access to this directory by domain, so that the domain users will have read access to data about users in their own domain. If you do not want to be that permissive, we recommend that you have on one side the list of domains, and the list of emails on the other.

For each domain, I decided to separate the email accounts of mail aliases. This has no use other than for human readability, in that it is easier when you browse the directory to see if it is an alias or a real account.

Note: You will find in my ldif file that for the user's password, the string {SSHA} + cbPM32CCzgLXhxnpSq6W7OJdg7hq ZQD is listed. I recommend you to use this method (it is the password hash of 0000). To generate a hash of the password (so you do not store clear the password of your users), you can use the following command (the second line is what the command returns):

slappasswd -s 0000 -h {SSHA}
{SSHA}H8v4t6NnK4/rtR3IMwsCIRAgttkJkGZ+

Here's the reulting ldif file, stored in the / (root) directory, and called addingFirstValues.ldif

#
# Création d'une arborescence mail qui contiendra l'ensemble
#

dn:dc=mail,dc=uncertaindomaine,dc=net
dc: mail
o: mail
objectClass: top
objectClass: dcObject
objectClass: organization


#
# Création des entrées pour les domaines à prendre en charge
# Je créée également, dans chaque domaine, une arborescence
# mailAlias, et une arborescence mailAccount, afin d'avoir un
# meilleur classement
#

dn:dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net
o: uncertaindomainenet
dc: uncertaindomaine.net
description: virtualDomain
userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD
objectClass: top
objectClass: dcObject
objectClass: organization

dn:dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net
dc: mailAccount
o: mailAccount
objectClass: top
objectClass: dcObject
objectClass: organization

dn:dc=mailAlias,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net
dc: mailAlias
o: mailAlias
objectClass: top
objectClass: dcObject
objectClass: organization

dn:dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net
o: uncertaindomainecom
dc: uncertaindomaine.com
description: virtualDomain
userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD
objectClass: top
objectClass: dcObject
objectClass: organization

dn:dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net
dc: mailAccount
o: mailAccount
objectClass: top
objectClass: dcObject
objectClass: organization

dn:dc=mailAlias,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net
dc: mailAlias
o: mailAlias
objectClass: top
objectClass: dcObject
objectClass: organization

dn:dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net
o: uncertaindomaineorg
dc: uncertaindomaine.org
description: virtualDomain
userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD
objectClass: top
objectClass: dcObject
objectClass: organization

dn:dc=mailAccount,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net
dc: mailAccount
o: mailAccount
objectClass: top
objectClass: dcObject
objectClass: organization

dn:dc=mailAlias,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net
dc: mailAlias
o: mailAlias
objectClass: top
objectClass: dcObject
objectClass: organization

#
#Création des comptes mails
#

dn:mail=vargisj@uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net
cn:vargisj@uncertaindomaine.net
mail:vargisj@uncertaindomaine.net
sn: VARGIS
givenName: Julien
displayName: Julien VARGIS
mailbox: uncertaindomaine.net/vargisj/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD

dn:mail=vargisj@uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net
cn:vargisj@uncertaindomaine.com
mail:vargisj@uncertaindomaine.com
sn: VARGIS
givenName: Julien
displayName: Julien VARGIS
mailbox: uncertaindomaine.net/vargisj/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD

dn:mail=vargisj@uncertaindomaine.org,dc=mailAccount,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net
cn:vargisj@uncertaindomaine.org
mail:vargisj@uncertaindomaine.org
sn: VARGIS
givenName: Julien
displayName: Julien VARGIS
mailbox: uncertaindomaine.net/vargisj/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD

dn:mail=admin@uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net
cn:admin@uncertaindomaine.net
mail:admin@uncertaindomaine.net
sn: Administrator
displayName: Administrator
mailbox: uncertaindomaine.net/admin/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD

dn:mail=admin@uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net
cn:admin@uncertaindomaine.com
mail:admin@uncertaindomaine.com
sn: Administrator
displayName: Administrator
mailbox: uncertaindomaine.com/admin/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD

dn:mail=all@uncertaindomaine.net,dc=mailAlias,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net
cn:all@uncertaindomaine.net
mail:all@uncertaindomaine.net
maildrop:admin@uncertaindomaine.net,vargisj@uncertaindomaine.net
sn: Everybody
displayName: Everybody
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAlias

Once you have created your file, you can add it to your directory with the following command:

ldapadd -D "cn=admin,dc=uncertaindomaine,dc=net" -W -h localhost -f /root/addingFirstValues.ldif

If you succeed, the result will look something like this:

adding new entry "dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "dc=mailAlias,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "dc=mailAlias,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "dc=mailAccount,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "dc=mailAlias,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "mail=vargisj@uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "mail=vargisj@uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "mail=vargisj@uncertaindomaine.org,dc=mailAccount,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "mail=admin@uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "mail=admin@uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net"

adding new entry "mail=all@uncertaindomaine.net,dc=mailAlias,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net"

If you hit errors (everyone does, it's ok), you might need to reset to default and try again. Here's a useful command to do that (adjust it to your particular tree):

ldapdelete -D "cn=admin,dc=uncertaindomaine,dc=net" -W -h localhost -v -r "dc=mail,dc=uncertaindomaine,dc=net"

This command will be useful in the sense that it will remove your email tree and all its contents. In fact, if you have errors in your file, and you correct them and then run ldapadd, it will return an error stating that you could not create the entry email, which already exists.

Ok, that's all for now…