11.3. Mail Transport Agents

11.3.1.1. Purpose and Limitations

It is important to be aware of what Sendmail is and what it can do as opposed to what it is not. In these days of monolithic applications that fulfill multiple roles, Sendmail may seem like the only application needed to run an email server within an organization. Technically, this is true, as Sendmail can spool mail to each users' directory and deliver outbound mail for users. However, most users actually require much more than simple email delivery. They usually want to interact with their email using an MUA, that uses POP or IMAP, to download their messages to their local machine. Or, they may prefer a Web interface to gain access to their mailbox. These other applications can work in conjunction with Sendmail, but they actually exist for different reasons and can operate separately from one another.

It is beyond the scope of this section to go into all that Sendmail should or could be configured to do. With literally hundreds of different options and rule sets, entire volumes have been dedicated to helping explain everything that can be done and how to fix things that go wrong. Refer to the Section 11.6 Additional Resources for a list of Sendmail resources.

This section reviews the files installed with Sendmail by default and reviews basic configuration changes, including how to stop unwanted email (spam) and how to extend Sendmail with the Lightweight Directory Access Protocol (LDAP).

11.3.1.2. The Default Sendmail Installation

The Sendmail executable is /usr/sbin/sendmail.

Sendmail's lengthy and detailed configuration file is /etc/mail/sendmail.cf. Avoid editing the sendmail.cf file directly. Instead, to make configuration changes to Sendmail, edit the /etc/mail/sendmail.mc file, back up the original /etc/mail/sendmail.cf, and then use the included m4 macro processor to create a new /etc/mail/sendmail.cf. More information on configuring Sendmail can be found in Section 11.3.1.3 Common Sendmail Configuration Changes.

Various Sendmail configuration files are installed in the /etc/mail/ directory including:

• access — Specifies which systems can use Sendmail for outbound email.

• domaintable — Specifies domain name mapping.

• local-host-names — Specifies aliases for the host.

• mailertable — Specifies instructions that override routing for particular domains.

• virtusertable — Specifies a domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine.

Several of the configuration files in /etc/mail/, such as access, domaintable, mailertable and virtusertable, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes made to these configurations in their database files, run the command:

makemap hash /etc/mail/<name> < /etc/mail/<name>

Where <name> is replaced with the name of the configuration file to convert.

For example, to have all emails addressed to the example.com domain delivered to <bob@other-example.com>, add the following line to the virtusertable file:

@example.com     bob@other-example.com

To finalize the change, the virtusertable.db file must be updated using the following command as root:

makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable 

This creates a new virtusertable.db file containing the new configuration.

11.3.1.3. Common Sendmail Configuration Changes

When altering the Sendmail configuration file, it is best generate an entirely new /etc/mail/sendmail.cf file instead of editing an existing one.

	Caution
	Before changing the sendmail.cf file, it is a good idea to backup a working version of the file.

To add the desired functionality to Sendmail, edit the /etc/mail/sendmail.mc file. When finished, use the m4 macro processor to generate a new sendmail.cf by executing the m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf command. After creating a new /etc/mail/sendmail.cf file, restart Sendmail to make it take effect. The easiest way to do this is to type the /sbin/service sendmail restart command as root.

By default, the m4 macro processor is installed with Sendmail but is part of the m4 package.

Important

The default sendmail.cf file does not allow Sendmail to accept network connections from any host other than the local computer. To configure Sendmail as a server for other clients, edit /etc/mail/sendmail.mc and change DAEMON_OPTIONS to also listen on network devices or comment out this option all together. Then regenerate /etc/mail/sendmail.cf by running: m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

This configuration should work for most SMTP-only sites. It will not work for UUCP (UNIX to UNIX Copy) sites; you must generate a new sendmail.cf if using UUCP mail transfers.

Consult the /usr/share/sendmail-cf/README file before editing any files in the directories under the /usr/share/sendmail-cf directory, as they can affect the future configuration of /etc/mail/sendmail.cf files.

11.3.1.4. Masquerading

One common Sendmail configuration is to have a single machine act as a mail gateway for all machines on the network. For instance, a company may want to have a machine called mail.bigcorp.com that handles all of their email and assigns a consistent return address to all out going mail.

In this situation, the Sendmail server must masquerade the machine names on the company network so that their return address is user@bigcorp.com instead of user@devel.bigcorp.com.

To do this, add the following lines to /etc/mail/sendmail.mc:

FEATURE(always_add_domain)dnl
FEATURE(`masquerade_entire_domain')
FEATURE(`masquerade_envelope')
FEATURE(`allmasquerade')
MASQUERADE_AS(`bigcorp.com.')
MASQUERADE_DOMAIN(`bigcorp.com.')
MASQUERADE_AS(bigcorp.com)

After generating a new sendmail.cf using m4, this configuration will make all mail from inside the network appear as if it were sent from bigcorp.com.

11.3.1.5. Stopping Spam

Email spam can be defined as unnecessary and unwanted email received by a user who never requested the communication. It is a disruptive, costly, and widespread abuse of Internet communication standards.

Sendmail makes it relatively easy to block new spamming techniques being employed to send junk email. It even blocks many of the more usual spamming methods by default.

For example, forwarding of SMTP messages, also called relaying, has been disabled by default since Sendmail version 8.9. Before this change occurred, Sendmail would direct the mail host (x.org) to accept messages from one party (y.com) and send them to a different party (z.net). Now, however, Sendmail must be configured to permit any domain to relay mail through the server. To configure relay domains, edit the /etc/mail/relay-domains file and restart Sendmail.

However, many times users are bombarded with spam from other servers throughout the Internet. In these instances, Sendmail's access control features available through the /etc/mail/access file can be used to prevent connections from unwanted hosts. The following example illustrates how this file can be used to both block and specifically allow access to the Sendmail server:

badspammer.com       ERROR:550 "Go away and do not spam us anymore"
tux.badspammer.com   OK
10.0                 RELAY

This example states that any email sent from badspammer.com is blocked with a 550 RFC-821 compliant error code, with a message sent back to the spammer. Email sent from the tux.badspammer.com sub-domain, which would be accepted. The last line shows that any email sent from the 10.0.*.* network can be relayed through the mail server.

Because /etc/mail/access.db is a database, use makemap to activate any changes. Do this using the following command as root:

	  
makemap hash /etc/mail/access < /etc/mail/access 

This example only scratches the surface of what Sendmail can do in terms of allowing or blocking access. See the /usr/share/doc/sendmail/README.cf for more information and examples.

Since Sendmail calls the Procmail MDA when delivering mail, it is also possible to use a spam filtering program, such as SpamAssassin to identify and file spam for users. Refer to Section 11.4.2.6 Spam Filters for more about using SpamAssassin.

11.3.1.6. Using Sendmail with LDAP

Using the Lightweight Directory Access Protocol (LDAP) is a very quick and powerful way to find specific information about a particular user from a much larger group. For example, an LDAP server can be used to look up a particular email address from a common corporate directory by the user's last name. In this kind of implementation, LDAP is largely separate from Sendmail, with LDAP storing the hierarchical user information and Sendmail only being given the result of LDAP queries in pre-addressed email messages.

However, Sendmail supports a much greater integration with LDAP, where it uses LDAP to replace separately maintained files, such as aliases and virtusertables, on different mail servers that work together to support a medium- to enterprise-level organization. In short, LDAP abstracts the mail routing level from Sendmail and its separate configuration files to a powerful LDAP cluster that can be leveraged by many different applications.

The current version of Sendmail contains support for LDAP. To extend the Sendmail server using LDAP, first get an LDAP server, such as OpenLDAP, running and properly configured. Then edit the /etc/mail/sendmail.mc to include the following:

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

	Note
	This is only for a very basic configuration of Sendmail with LDAP. Your configuration should differ greatly from this depending on the implementation of LDAP, especially when configuring several Sendmail machines to use a common LDAP server. Consult /usr/share/doc/sendmail/README.cf for detailed LDAP routing configuration instructions and examples.

Next, recreate the /etc/mail/sendmail.cf file by running m4 and restarting Sendmail. See Section 11.3.1.3 Common Sendmail Configuration Changes for instructions on doing this.

For more information on LDAP, see Chapter 13 Lightweight Directory Access Protocol (LDAP).

11.3.2.1. Fetchmail Configuration Options

Although it is possible to pass all necessary options on the command line to check for email on a remote server when executing Fetchmail, using a .fetchmailrc file is much easier. All of the configuration options go in the .fetchmailrc file and it is possible to override them at the time Fetchmail is run by specifying that option on the command line.

A user's .fetchmailrc file is divided into three particular types of configuration options:

• global options — Gives Fetchmail instructions that control the operation of the program or provide settings for every connection that checks for email.

• server options — Specifies necessary information about the server being polled, such as the hostname, as well as preferences for a specific email server, such as the port to check or number of seconds to wait before timing out. These options affect every user option used with that server.

• user options — Contains information, such as username and password, necessary to authenticate and check for email using a particular email server.

Global options appear at the top of the .fetchmailrc file, followed by one or more server options, each of which designate a different email server that Fetchmail should check. User options follow server options for each user account checking that email server. Like server options, multiple user options may be specified for use with a particular server as well as to check multiple email accounts on the same server.

Server options are called into service in the .fetchmailrc file by the use of a special option verb, poll or skip, that precedes any of the server information. The poll action tells Fetchmail to use this server option when it is run, which actually checks it for email using the various user options. Any server options after a skip action, however, are not checked unless this server's hostname is specified when Fetchmail is invoked. The skip option sets up test configurations in .fetchmailrc and only checks that server when specifically desired, without affecting any currently working configurations.

A sample .fetchmailrc file looks like this:

set postmaster "user1"
set bouncemail

poll pop.domain.com proto pop3
     user 'user1' there with password 'secret' is user1 here

poll mail.domain2.com
     user 'user5' there with password 'secret2' is user1 here
     user 'user7' there with password 'secret3' is user1 here

In this example, the global are options set so the user is sent email as a last resort (postmaster option) and all email errors are sent to the postmaster instead of the sender (bouncemail option). The set action tells Fetchmail that this line contains a global option. Then, two email servers are specified, one set to check using POP3, the other for trying various protocols to find one that works. Two users are checked using the second server option, but all email found for any user is sent to user1's mail spool. This allows multiple mailboxes to be checked on multiple servers, while appearing in a single MUA inbox. Each user's specific information begins with the user action.

	Note
	Users are not required to place their password in the .fetchmailrc file. Omitting the with password '<password>' section causes Fetchmail to ask for a password when it is launched.

Fetchmail contains many different global, server, and local options. Many of these options are rarely used or only apply to very specific situations. The fetchmail man page explains each option in detail, but the most common ones are listed here.

11.3.2.2. Global Options

Each global option should be placed on a single line after a set action.

• daemon <seconds> — Specifies daemon-mode, where Fetchmail stays in the background and polls for mail at the interval specified.

• postmaster — Specifies a local user to send mail to in case of delivery problems.

• syslog — Specifies the log file for errors and status messages. By default, this is /var/log/maillog.

11.3.2.3. Server Options

Server options must be placed on their own line in .fetchmailrc after a poll or skip action.

• auth <auth-type> — Specifies the type of authentication to be used. By default, password authentication is used, but some protocols support other types of authentication, including kerberos_v5, kerberos_v4, and ssh. If the any authentication type is used, Fetchmail first tries methods that do not require a password, then methods that mask the password, and finally attempts to send the password unencrypted to authenticate to the server.

• interval <number> — Polls the specified server every <number> of times that it checks for email on all configured servers. This option is generally used for email servers where the user rarely receives messages.

• port <port-number> — Overrides the default port number for a specified protocol.

• proto <protocol> — Specifies a specific protocol, such as pop3 or imap, to check for messages on this server.

• timeout <seconds> — Specifies the interval of server inactivity after which Fetchmail gives up on a connection attempt. If this value is not set, a default of 300 seconds is assumed.

11.3.2.4. User Options

User options may be placed on their own lines beneath a server option or on the same line as the server option. In either case, the defined options must follow the user option (defined below).

• fetchall — Orders Fetchmail to download all messages in the queue, including messages that have already been viewed. By default, Fetchmail only pulls down new messages.

• fetchlimit <number> — Only allows a certain number of messages to be retrieved before stopping.

• flush — Tells Fetchmail to delete all previously viewed messages in the queue before retrieving new messages.

• limit <max-number-bytes> — Specifies that only messages below a particular size may be retrieved. This option is useful with slow network links, when a large message takes too long to download.

• password '<password>' — Specifies the password to be used for this user.

• preconnect "<command>" — Executes the specified command before retrieving messages for this user.

• postconnect "<command>" — Executes the specified command after retrieving messages for this user.

• ssl — Activates SSL encryption.

• user "<username>" — Sets the username used by Fetchmail to retrieve messages. This option should be listed before any other user options.

11.3.2.5. Fetchmail Command Options

Most Fetchmail options that may be used on the command line, when executing the fetchmail command, mirror the .fetchmailrc configuration options. This is done so that Fetchmail may be used with or without a configuration file. Most users will not use these options on the command line, as it is easier to leave them in the .fetchmailrc file to be used whenever Fetchmail is run.

However, there may be times when it is desirable to run the fetchmail command with other options for a particular purpose. It is possible to issue command options to temporarily override a .fetchmailrc setting that is causing an error, as any options specified at the command line override configuration file options.

11.3.2.6. Informational or Debugging Options

Certain options used after the fetchmail command can supply important information.

• --configdump — Displays every possible option based on information from .fetchmailrc and Fetchmail defaults. No email is retrieved for any users when using this option.

• -s — Executes Fetchmail in silent mode, preventing any messages, other than errors, from appearing after the fetchmail command.

• -v — Executes Fetchmail in verbose mode, displaying every communication between Fetchmail and the remote email servers.

• -V — Displays detailed version information, lists its global options, and shows settings to be used with each user, including the email protocol and authentication method. No email is retrieved for any users when using this option.

11.3.2.7. Special Options

These options are occasionally useful for overriding defaults often found in the .fetchmailrc file.

• -a — Tells Fetchmail to download all messages from the remote email server, whether new or previously viewed. By default, Fetchmail only downloads new messages.

• -k — Causes Fetchmail to leave the messages on the remote email server after downloading them. This option overrides the default behavior of deleting messages after downloading them.

• -l <max-number-bytes> — Tells Fetchmail to not download any messages over a particular size and to leave them on the remote email server.

• --quit — Quits the Fetchmail daemon process.

More commands and .fetchmailrc options can be found in the fetchmail man page.