Aliases and LDAP

With Sendmail 8.10, Sendmail can now support the Lightweight Directory Access Protocol (LDAP). LDAP enables the use of a separate server to manage Sendmail queries about user mail addresses. Instead of maintaining aliases and virtusertable files on different servers, Sendmail uses LDAP support to simply use one centralized LDAP server to locate recipients. Mail addresses are looked up in the LDAP server, instead of having to search several aliases and virtusertable files on different servers. LDAP also provides secure authentication of users, allowing controlled access to mail accounts. The following example enables LDAP support on Sendmail in the sendmail.mc file:

FEATURE('ldap_routing')dnl
LDAPROUTE_DOMAIN('mytrek.com')dnl

Alternatively, Sendmail still supports the use of aliases, for either sent or received mail. It checks an aliases database file called aliases.db that holds alias names and their associated e-mail addresses. This is often used for administrator mail, where mail may be sent to the system's root user and then redirected to the mail address of the actual system administrator. You can also alias host addresses, enabling you to address hosts on your network using only their aliases. Alias entries are kept in the /etc/aliases file. This file consists of one-line alias records associating aliases with user addresses. You can edit this file to add new entries or to change old ones. They are then stored for lookup in the aliases.db file using the command newaliases, which runs Sendmail with instructions to update the aliases.db file.

Aliases allow you to give different names for an e-mail address or collection of e-mail addresses. One of its most useful features is to create a mailing list of users. Mail addresses to an alias will be sent to the user or list of users associated with the alias. An alias entry consists of an alias name terminated by a colon and followed by a username or comma-separated list of users. For example, to alias filmcritic with the user george@rabbit.mytrek.com, you would use the following entry:

filmcritic:   george@rabbit.mytrek.com

To alias singers with the local users aleina and larisa, you would use

singers:     aleina, larisa

You can also use aliases as the target addresses, in which case they will expand to their respective user addresses. For example, the performers alias will expand through the filmcritic and singers aliases to the users george@rabbit.mytrek.com, aleina, and larisa.

performers:     filmcritic, singers

Once you have made your entries in the /etc/mail/aliases file, you need to generate a database version using the newaliases command:

newaliases

Sendmail Configuration

The main Sendmail configuration file is sendmail.cf, located in the /etc directory. This file consists of a sometimes lengthy list of mail definitions that set general options, designate MTAs, and define the address rewrite rules. A series of options set features, such as maximum size of mail messages or the name of host files. The MTAs are those mailers through which Sendmail routes messages. The rewrite rules "rewrite" a mail address to route through the appropriate Internet connections to its destination (these rules can be complex). Check the Sendmail HOW-TO and the online documentation for a detailed explanation.

The sendmail.cf definitions can be complex and confusing. To simplify the configuration process, Sendmail supports the use of macros you can use to generate the sendmail.cf file using the m4 preprocessor (this requires installation of the sendmail-cf package). Macros are placed in the /etc/mail/sendmail.mc file. Here, you can use macros to designate the definitions and features you want for Sendmail, and then the macros are used to generate the appropriate definitions and rewrite rules in the sendmail.cf file. As part of the Sendmail package, several specialized versions of the sendmail.mc file are made available in the /usr/share/sendmail-cf directory. These begin with a system name and have the suffix .mc. On many distributions, a specialized version tailored to your distribution is already installed as your /etc/mail/sendmail.mc file.

Once you configure your sendmail.mc file, you use the following command to generate a sendmail.cf file (be sure first to back up your original sendmail.cf file). You can rename the sendmail.mc file to reflect the specific configuration. You can have as many different .mc files as you want and use them to implement different configurations.

m4 sendmail.mc > /etc/mail/sendmail.cf

You will then need to restart the Sendmail server to make the configuration effective:

service sendmail restart

In the sendmail.mc file, you configure different aspects of Sendmail using either a define command to set the value of Sendmail variables or a Sendmail macro that has already been defined to set a particular Sendmail feature. For example, to assign the PROCMAIL_PATH variable to the directory /usr/bin/procmail, you would use the following:

define('PROCMAIL_MAILER_PATH','/usr/bin/procmail')

Similarly, if there are variables that you do not want defined, you can remove them with the undefine command:

undefine('UUCP_RELAY')

To specify the type of operating system that your Sendmail server is running on, you would use the OSTYPE Sendmail macro. The following example specifies the Linux operating system:

OSTYPE('linux')

The MAILER macro specifies the mail delivery agents (MDAs) to be used. You may have more than one. Usually, you will need a mail delivery agent such as procmail for delivering mail to hosts on your network. In addition, Sendmail in effect operates as an MDA to receive messages from hosts in its local network, which it will then send out to the larger network.

MAILER(procmail)
MAILER(smtp)

Sendmail also supports an extensive number of features that you need to explicitly turn on. You can do this with the Sendmail FEATURE macro. See Table 24-3 for a list of commonly used Sendmail features. The following example turns on the redirect feature, which is used to inform a sender that a recipient is now at a different address:

FEATURE(redirect)

In addition, you can set certain configuration options. These are variables beginning with the prefix conf that you can set and assign values to using the define command. There are an extensive number of configuration options, most of which you will not need to change. The following example defines the confAUTO_REBUILD configuration option, which will automatically rebuild the aliases database if needed.

define('confAUTO_REBUILD')

Certain macros and types of macros need to be placed in the sendmail.mc file in a particular sequence as shown here. Notice that MAILER is toward the end and OSTYPE at the beginning. Local macro definitions (define) and FEATURE entries follow the OSTYPE and DOMAIN entries.

VERSIONID
OSTYPE
DOMAIN
define
FEATURE
local macro definitions
MAILER
LOCAL_RULE_*
LOCAL_RULESETS

The local macro and configuration option definitions that affect a particular feature need to be entered before the FEATURE entry. For example, the redirect feature uses the aliases file. Any local definition of the aliases file needs to be entered before the redirect feature.

define('ALIAS_FILE','/etc/aliases')
FEATURE(redirect)

You need to be careful how you enter comments into a sendmail.mc file. This file is read as a stream of macros, ignoring all white spaces, including newlines. No special comment characters are looked for. Instead, you have to simulate comment indicators using the dnl or divert commands. The dnl command instructs that all characters following that dnl command up to and including the next newline are to be ignored. If you place a dnl command at the beginning of a text line in the sendmain.mc file, it has the effect of turning that line into a comment, ignoring everything on that line—including its newline. Even empty lines will require a dnl entry to ignore the newline character:

dnl you will have to /etc/mail/sendmail.cf by running this the m4
dnl macro config through preprocessor:
dnl

Alternatively, you can use the divert command. The divert command will ignore all data until another divert command is reached:

divert(-1)
 This is the macro config file used to generate
 the /etc/mail/sendmail.cf file. If you modify the file regenerate
 you will have to regenerate /etc/mail/sendmail.cf by running the m4
 macro
divert(0)

For Sendmail to work at all, it requires only that the OSTYPE and MAILERS macros be defined, along with any needed features and options. A very simple Sendmail file is shown here.

mysendmail.mc

dnl My sendmail.mc file
OSTYPE('linux')
define('PROCMAIL_MAILER_PATH','/usr/bin/procmail')
FEATURE(redirect)
MAILER(procmail)
MAILER(smtp)

A sendmail.mc file usually contains many more entries, particularly for parameters and features. Check the /etc/mail/sendmail.mc file on your Red Hat system to see the standard default entries for Sendmail.

Sendmail Masquerading

For a mail server that is relaying messages from local hosts to the Internet, you may want to masquerade the source of the messages. In large networks that have their own mail servers connected to the Internet, Sendmail masquerading can make messages sent by local hosts appear to be sent by the mail server. Their host address will be replaced by the mail server's address. Returned mail can then be sent to the mail server and held in POP or IMAP server mailboxes that can be later accessed by users on the local hosts. Also, entries in the server's virtual user table could forward mail to corresponding users in local hosts.

Masquerading is often used to mask local hosts with a domain name. Any subdomains can also be masqueraded. This method can be applied to situations where an ISP or your network administrator has assigned your network its own domain name. You can then mask all mail messages as coming from your domain name instead of from particular hosts or from any subdomains you may have. For example, if a network's official domain name is mytrek.com, all messages from the hosts in the mytrek.com network, such as rabbit.mytrek .com and turtle.mytrek.com, could be masqueraded to appear as just coming from mytrek.com. Should the mytrek.com network have a subnetwork whose domain is mybeach.com, any messages from mybeach.com could also be masqueraded as coming from mytrek.com.

Masquerading is turned on with the MASQUERADE_AS command. This takes as its argument the name you want to masquerade your mail as. Normally, the name used is just the domain name, without the mail host. In the following example, the mail is masqueraded as simply mytrek.com. Mail sent from a local host like turtle.mytrek.com will appear to be sent by just mytrek.com:

MASQUERADE_AS('mytrek.com')dnl

You will also have to specify the hosts and domains on your local network that your Sendmail server should masquerade. If you have decided to masquerade all the hosts in your local network, you just need to set the masquerade_entire_domain feature, as in:

FEATURE('masquerade_entire_domain')dnl

If, instead, you want to masquerade particular hosts or your domain has several subdomains that you want masqueraded, you list them in the MASQUERADE_DOMAIN entry. You can list either particular hosts or entire domains. For example, given a local network with the local hosts turtle.mytrek.com and rabbit.mytrek.com, you can list them with the MASQUERADE_DOMAIN to have them masqueraded. The domain they are masqueraded as is specified in the MASQUERADE_AS entry.

MASQUERADE_DOMAIN('turtle.mytrek.com rabbit.mytrek.com')dnl

If you want to masquerade all the hosts in your local network, you can simply list your local network's domain name. If your local network also supports several subdomains, you can list those as well to masquerade them. For example, to masquerade all the hosts in the mybeach.com domain, you would use the following entry:

MASQUERADE_DOMAIN('mytrek.com mybeach.com')dnl

If you have a long list of domains or hosts, or you want to be able to easily change those that should be masqueraded, you can place them in a file to be read by Sendmail. Specify the file with the MASQUERADE_DOMAIN_FILE command:

MASQUERADE_DOMAIN_FILE('mydomains')dnl

If you just want to masquerade all the hosts in your local domain, you use the masquerade_entire_domain feature:

FEATURE(masquerade_entire_domain)dnl

A common configuration for a local network would specify the domain name in the MASQUERADE_AS entry and in the MASQUERADE_DOMAIN entry. Using the example myisp.com for the domain, the entries would look like this:

MASQUERADE_AS('mytrek.com')dnl
FEATURE(masquerade_entire_domain)dnl

If you wanted to masquerade as an ISP's mail domain, you would use the ISP's domain in the MASQUERADE_AS entry as shown here:

MASQUERADE_AS('myisp.com')dnl
MASQUERADE_DOMAIN('mytrek.com')dnl

When mail is received from the outside bearing just the address mytrek.com, your network needs to know what host to send it to. This is the host designated as the mail server for the mytrek.com network. This information is provided by a mail exchange record (MX) in your DNS configuration that will specify that mail sent to mytrek.com will be handled by the mail server—in this case, turtle.mytrek.com:

mytrek.com.  IN    MX     0     turtle.mytrek.com.

You further have to be sure that MX relaying is enabled with the relay_based_on_MX feature:

FEATURE(relay_based_on_MX)dnl

All messages will appear to originate from the mail server's host. For example, if your Sendmail mail server is running on turtle.mytrek.com, mail sent from a local host called rabbit.mytrek.com will appear to have been sent from turtle.mytrek.com.

You can also masquerade recipient addresses, so that mail sent to users on your local host will be sent instead to the masqueraded address. Use the allmasquerade feature to enable recipient masquerading:

FEATURE(allmasquerade)dnl

Configuring Mail Servers and Mail Clients

Sendmail can be used either as a mail server, handling mail for various hosts on a network, or as a mail client, managing mail for local users on a particular host. In a simple network configuration, you would have each host running Sendmail in a client configuration, and one host operating as a mail server, relaying mail for the network hosts. For a local network connected to the Internet, your local hosts would run Sendmail in a client configuration, and your gateway would run Sendmail in a server configuration (though the mail server would not have to necessarily run on the gateway). The mail server would relay messages from the local network hosts out to the Internet. The mail server could also be used to block unwanted access from outside hosts, such as those sending spam mail. A basic client or server Sendmail configuration involves just a few features in the /etc/mail/sendamail.mc file. The default Red Hat configuration installed on your system allows use on a single host, managing messages between users on that host. To enable client and server use, you will need to make changes to the /etc/mail/sendmail.mc file.

Configuring Sendmail for a Simple Network Configuration

Red Hat initially configures Sendmail to work only on the system it is running on, localhost. To use Sendmail to send messages to other hosts on a local network, you need to change and add settings in the sendmail.mc and /etc/mail/access files. A simple network configuration would have Sendmail running on each host, handling both mail sent between users on that host and mail to and from users on other hosts. For each Sendmail server configuration, you would make the changes described in the following section on simple local network configuration.

For messages sent between hosts on your network, you only need to run the Sendmail server on each, making a few changes to their Sendmail configurations. The Sendmail server on one of your hosts can be configured to handle the task of relaying messages between hosts. Using the network example described earlier, the hosts turtle, rabbit, and lizard will be running their own Sendmail servers. The Sendmail server on the turtle host will be configured to relay messages between all the hosts, itself included.

On each host on your network, edit the /etc/mail/sendmail.mc file and make the following changes. On Red Hat systems, comment out the DAEMON_OPTIONS line in the default sendmail.mc file by placing a dnl word in front of it, as shown here. Removing this feature will allow you to receive messages over your local network. This entry is restricting Sendmail to the localhost (127.0.0.1):

dnl DAEMON_OPTIONS('Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

In the sendmail.mc file located on the host that you want to have handle the relaying of messages, you need to also add the following line:

FEATURE(relay_entire_domain)dnl

Run the m4 operation to install the changed configuration and then restart the server with the service operation, as described earlier.

You can now e-mail messages from one user to another across your network. For example, george@turtle.mytrek.com can now e-mail a message to larisa@rabbit.mytrek.com. The local Sendmail servers will take care of sending and delivering mail both to users within their hosts and those located on other network hosts.

Configuring Sendmail for a Centralized Mail Server

Alternatively, you could set up a central mail server to handle all the mail on your network. Mail clients on various hosts could send their messages to the central mail server, which would then relay them out to the larger network or Internet. Mail could then be received at the central mail server, where clients could later retrieve it. There are several ways to set up a central mail server. One of the simplest is to run a central mail server on your gateway host, and then have null client versions of the Sendmail server running on local hosts. Any mail sent from local hosts would be automatically forwarded to the central mail server. Received mail could only be delivered to the central server, usually to a POP or IMAP server also running on the central server's host. Users could then access the POP server to retrieve their mail.

For a centralized configuration, it would make sense to treat users as having their network domain as their address, rather than separate hosts in their network. So the user cece on rabbit.mytrek.com would use the mail address cece@mytrek.com, not cece@rabbit.mytrek.com. Users could have the same name as those on their respective hosts, but corresponding users would be set up on the gateway host to handle received mail managed by the POP or IMAP servers.

An effective simple mail server would involve several components:

• A central mail server running on the gateway host

• Each client running Sendmail as a null client

• Masquerading all mail to use the domain address only, not host addresses

• A POP or IMAP server running on the gateway host to handle received mail

Configuring a Workstation with Direct ISP Connection

If you are running a Linux system that is not part of a network but does have a direct connection to the Internet through an ISP (Internet service provider), you could simply use the ISP mail servers for sending and receiving mail. Normally, you would have an SMTP mail server for outgoing mail and a POP server for incoming mail. However, you can also configure Sendmail to interface with your ISP.

Be sure to first comment out the DAEMON_OPTIONS option as shown in the previous sections.

Normally, your ISP will provide a mail server that will handle mail for its hosts. To make use of the ISP mail server, you can define it with the SMART_HOST option. Mail will be sent through the ISP mail server. SMART_HOST has the format type:hostname, where type is the kind of mail server used, usually SMTP. The default is relay. Define the SMART_HOST option to use your ISP to send and receive mail:

define ('SMART_HOST', 'smtp:mail.my-isp.com')dnl

The SMART_HOST option is used to indicate a specific remote mail server that you want to have handled the relaying of your network messages. It can be an ISP mail server, as well as any mail server in a larger network.

For a dial-up connection over a modem, you can use various configuration options to control your connection. The confMESSAGE_TIMEOUT option lets you control how long mail can remain on the output queue, letting you keep mail until you are ready to dial in and send it. Setting the confDELIVERY_MODE option to queueonly lets you send mail when you are ready.

The Mailer Table

The mailer table lets you route messages addressed to a specified host or domain to a particular mail server. You can use the mailer table to have mail addressed to a virtual domain routed to the mail server for your network. To reference an entire domain, prefix the domain name with a period. The host to which the mail is routed is prefixed by the mailer used, usually smtp for Sendmail. The following entry will route mail addressed to .mybeach.com to the mail server turtle.mytrek.com:

.mybeach.com       smtp:turtle.mytrek.com

Entries are placed in the /etc/mail/mailertable file. Once you have made your entries, generate the mailertable.db database file with the make command:

make mailertable

Security

For security, Sendmail lets you screen specific messages as well as provide authentication and encryption for Sendmail transmissions. With version 8.11, Sendmail incorporated support for the Secure Sockets Layer (SSL) and the Simple Authentication and Security Layer (SASL). Support for SSL goes by the Sendmail command STARTTLS, which stands for "start transport layer security." SSL provides authentication, encryption, and integrity checks for Sendmail operations (see Chapter 18). OpenSSL must first be installed to allow use of SSL encryption and authentication methods.

The SASL is implemented by the AUTH command and is referred to as SMTP AUTH. SASL provides authentication for mail users and servers. It can make use of already installed Kerberos services to provide authentication.

Sendmail also provides you with the capability of screening out messages from specific domain, host, IP, and user addresses. Rules to perform such screening are kept in the /etc/mail/access file. You can edit this file and add your own rules. A rule consists of an address followed by an action to take. (The actions supported are listed in Table 24-4.) For example, to remove all messages from the myannoyingad.com domain, you would enter:

myannoyingad.com DISCARD

The next example rejects any message from larisa@turtle.mycar.com and sends a notice of the rejection:

larisa@turtle.mycar.com REJECT

You can also specify an error message to return, as shown here:

cecelia@rabbit.mytrek.com    ERROR:"Retired yesterday"

To send an error message to spammers, you could include a message as shown here. The first number is an error code.

cyberspammer.com     ERROR:"550 We don't accept mail from spammers"

An /etc/mail/access file with the previous entries would look like the following:

myannoyingad.com               DISCARD
larisa@turtle.mycar.com    REJECT
cecelia@rabbit.mytrek.com  ERROR:"Retired yesterday"
cyberspammer.com           ERROR:"550 We don't accept mail from spammers"

Sendmail actually reads the access rules from a database file called access.db, also located in the /etc/mail directory. To implement your rules, you have to regenerate the access.db file using the access file. You can do this with the make command using access as the argument, as shown here:

make access

Sendmail then has to be restarted to read the new access.db file.

The use of the access file is enabled in the sendmail.mc file with the access_db feature:

FEATURE('access_db')dnl

The access file will deny mail received from the listed addresses. However, you can also reject any mail sent to them. You can also reject received mail for certain hosts on your network. You do this by enabling the blacklist_recipients option in the sendmail.mc file. This option governs recipients, whereas access normally governs senders. Those addresses listed will not be able to receive any mail. This feature is also used for certain administrative users that should never receive mail, such as nobody (the guest user) or ftp (the FTP user):

FEATURE('blacklist_recipients')dnl

The following example will not allow mail to be sent to cyberspammer.com (a recipient), nor can mail be received for justin@lizard.mytrek.com, secretproject@rabbit.mytrek.com, or mysurfboard.com:

mysurfboard.com                 ERROR:"Domain does not exist"
justin@lizard.mytrek.com        "Moved to Hawaii"
secretproject@rabbit.mytrek.com  REJECT
cyberspammer.com               REJECT

Your distribution version of smb.conf may configure Sendmail to use access_db (as is the case with Red Hat). Access is granted only to users on the local host. If your system is being used as a mail server for a network and you have not enabled the relay_entire_ domain feature, you will need to allow access by other hosts on your network. In the access file, you can place a RELAY rule for your network. The RELAY rule will let other hosts use your mail server to send messages out to other hosts. This is normally done for a gateway host that needs to relay messages from a local network out to the Internet. The following example allows access from the mytrek.com network:

mytrek.com      RELAY

For a specific host, place an entry for it in the access file as shown here:

rabbit.mytrek.com    RELAY

To further secure Sendmail, you should disable the use of VRFY. This option allows remote users to try to verify the existence of a user address. This can be used to guess valid users on your system. This option is disabled with the noverify feature:

FEATURE('noverify')dnl

Another potential security breach is the EXPN option, which expands mailing lists and aliases to their actual addresses. Use the noexpn feature to turn it off:

FEATURE('noexpn')dnl

By default, Sendmail will refuse mail from any domain that cannot be resolved. You can override this restriction with the accept_unresolvable_domains feature. Sendmail will also reject mail whose addresses do not have fully qualified domain names. You can override this feature with accept_unqualified_senders.