6. Mail Transfer Agents

6.1.1. Ldap support in sendmail

Sendmail has support for ldap since somewhere around version 8.8.x using the map type ldapx.From version 8.10 and up an ldap database type ldap is supported. Please note that the ldap map support is not enabled per default in the RedHat package. Debian versions 2.2 and later do have ldap support in their sendmail, I am told. If you have to compile it yourself, please read the file sendmail/README from the sendmail sources. It contains valuable information about how to compile in the ldap support.

Both the old and the new ldap map type have the ability to look up entries in an ldap database. There is one thing that must be noted however. When a search is being done, only one result should be returned. If more results are found, only the first is used. Additionally, is multiple return values for that result are found, only the first is returned. Let's take a look at the following example ldif file:

dn: cn=mailuser1,ou=mail,dc=company,dc=com objectclass: top objectclass: foo cn: mailuser1 mail: [email protected] mail: [email protected]

If a search is performed with a simple search filter like cn=mailuser1, and the attribute that is asked for is mail, only [email protected], is returned. To get both results, they should we stored in a single-valued attribute with comma-separated values, like this:

mail: [email protected], [email protected]

An email message containing information related to this subject can be found at the LIH home.

6.1.2. System layout.

When ldap maps are available, almost anything can be looked up in an ldap database. What we would like to do is to simplify the configuration of the following setup.

Let's say we have a medium-sized or large network where we recieve for many domains. We have two mailhosts and two or three fallback hosts. This setup will normally have four places where three types of information are stored.

• The mailhosts both need a file , or traditionally sendmail.cw, to store the domains for which they should recieve mail. The fallback hosts keep the same information in the access file, but they use it to list the domains for which they should relay any incoming mail.

• The mailhosts both have a virtusers file, which maps multiple adresses (or entire domains) to a single virtual or local user.

• The mailhosts both have an aliases file, which maps virtual users to one or more mail addresses or local users.

6.1.3. Sendmail configuration file

To understand how this information is read from an ldap database instead of the regular files a little background knowledge of the sendmail.cf file is neccesary. The information we're dealing with here is stored in two different ways. The local-host-names file is read into a class (class w, to be exactly, hence the old extension cw), while the virtusers file is used through a simple map. The aliases file is also a map, but it is defined in a different manner and used internally, instead of being referred to in rules.

When information is retrieved from a ldap database, it always ends up being in a map. This is somewhat problematic with the information stored in the local-host-names file, because this used to be a class. I have been unable to fill the class with the information from the map or something alike. That would be the easy way, but I think it's not possible. (If I'm incorrect about this, please let me know). Therefore, I had to define a new map, and insert rules in the sendmail configuration to make sure that (almost) every time when a value is looked up in the class, the new map is searched for the value too.

For the maps, the change of configuration is easy. A map is normally defined with a name and database type, and some database-specific options, (like the location of the file, for the normally used newdb database types). So for maps, it suffices to change the definition of the map and voila, we're done. Ldap maps have a few more options, some of which can be predefined. They are explained in the following list (largely taken from Booker Bense's document):

PLease note that all ldap options must be double-quoted and must immediately follow the sendmail option. Here is an example:

Kldapexamplemap ldap -h"localhost ldap.myorg.com" -b"ou=mail,dc=myorg,dc=com" -k"(mailstuff)(uid=%s))" -v"mailaddress"

6.1.4. Schema

For this particular setup I have defined a subtree mail in the ldap directory, under which all mail-related information will be stored. I t would have been possible to store some of the user-related mail-information in the ou=Users subtree, but I have specificalle chosen not to do this. When using a separate subtree, all information for sendmail is stored in a single place, and, when having many users, searches may be faster, because not the entire ou=Users subtree needs to be searched, but only the ou=mail subtree.

In this subtree two kinds of records will appear.

1. Entries that hold mappings from the virtuser file and aliases file, for a single virtual user. I have chosen to store both mappings in a single entry, because this clarifies the effect and configuration used. For this I have defined an objectclass inetmailrecipient, and three attributes, mailid, mailacceptinggeneralid and maildrop.

   inetmailrecipient

   This is a classification that tells us the entry is some form of mapping from one or more real mail addresses and/or mail domains to one or more real users.

   mailid

   This describes the mail addresses that this virtual user recieves mail for. Can be in the form of normail addresses, like [email protected], or complete domains like @my2nd.org. Multiple of these attributes may be present, but they should all contain only one value. For each of these id's mail is sent to mailacceptinggeneralid.

   Here you'll put what you used to put at the left side in the virtusers file.

   mailacceptinggeneralid

   Defines a virtual user. This is in fact the link between the virtusers and aliases file. In each entry, one attribute of this type must be present, but no more than one may be present, and the attribute may contain only one value. This can either be a local username, or a virtual user. In the second case, a maildrop attribute must be present, in the first case, it does not.

   Here you'll put what you used to put in the virtusers file, and at the left side in the aliases file.

   maildrop

   Defines the addresses and/or users that mail received for should be delivered to. Only one attribute of this type may be present, but it may contain a comma-separated list of addresses and/or users. If the value of mailacceptinggeneralid is a virtual user, this attribute must be present. If the value is a real user, this entry may be omitted.

   Here you'll put what you used to put at the right side in the aliases file.

   In general, one could say that the mailid and mailacceptinggeneralid together provide the functionality of the virtusers file, and mailacceptinggeneralid and maildrop together provide the functionality of the aliases file.

2. One or more entries that hold the domain names which would normally apear in the sendmail.cw and access files. For this I have defined an objectclass inetmaildomain, and three attributes, maildomain, sendmailislokalkey and sendmailaccesskey.

   inetmaildomain

   This is a classification that tells us the entry lists mail domains which belong to our system, and either should be delivered locally, or be relayed to another host.

   maildomain

   Defines the mail domain. Multiple of these attributes may be presentin a single entry. The value should be the domain without the "@".

   For each of the dmain entries in the local-host-names file, one of these attributes should be present.

   sendmailislocalkey

   This defines a simple key that is used in the sendmail rules to determine if a domain is local. It can be anything really, but is must be the exact string you will use in your sendmail rules. For now I have used <LDAPLOCAL>. One attribute of this type must be present, and no more than one may be present in each entry.

   sendmailaccesskey

   This defines the key that is used in the sendmail rules to determine what action needs t be taken for the specified domain. It can be one of RELAY, OK, REJECT, DISCARD or an error indicator. (For detailed information see the cf/README file from the sendmail sources.)

   Note: PLease note that in this particular setup I will only be using entire domains in the access file. That means that in this case I can use the maildomain attribute for both the information used in the access file and the information used in the local-host-names. If you want a finer control over your access list, you should define a separate entry to hold that information, instead of using the maildomain attribute.

6.1.5. More information.

Here are a few sources of information that might be useful:

• Booker Bense has written a document about the usage of ldap with sendmail 8.9.3. He says it's the wrong place to start when learning about using sendmail and ldap, but it has been of great help to me.

• A short howto about how to setup sendmail with ldap, written by Jason Christopher Radford

• New articles about ldap and sendmail are being published on sendmail.net, written by Michael Donnelly, originating from ldapmap.org, which has also a lot of general interesting ldap-related information.

6.2.1. Support

Postfix has native ldap support. A lot of options in postfix can be configured using maps which can be of various types. One of those types is ldap. For each ldap map a couple of options can be configured. (See Section 6.2.2.)

The process of having postfix look up certain data in an ldap database is pretty straightforward. The most common use (so i think) is to have postfix look up virtual users in the ldap database. Together with the above explaind nss_ldap feature, this allows you to have all your email users in an ldap database. But other things can be configured too, like the domains postfix is allowed to relay mail for, or relay mail from, or for which is should act as a backup mail server.

6.2.2. Configuration

The description of the configuration options is completely taken from LDAP_README in the postfix docs from version 20001217.

6.2.3. Example setup

If you want a virtual domain (say foo.virtualdomain.com) and you want to store email addresses in Ldap for this domain, youwould need the following piece in your main.cf.

virtual_maps = ldap:ldapvirtual ldapvirtual_search_base = ou=mail,o=YourOrg,c=nl ldapvirtual_query_filter = (mailacceptinggeneralid=%s) ldapvirtual_domain = foo.virtualdomain.com ldapvirtual_result_attribute = maildrop ldapvirtual_bind = no ldapvirtual_scope = one

With this setting, if postfix receives mail for a user with a domain part "foo.virtualdomain.com", to do a search in the database for entries that have an attribute mailacceptinggeneralid that matches "[email protected]". If such an entry is found, the values of all available maildrop attributes are returned, and to these values the mail is delivered. If "[email protected]" is not found, another query is performed, that tries to match the catchall user, "@foo.virtualdomain.com". If this is again not found, the message will be bounced.