Sendmail

---

Sendmail operates as a server to both receive and send mail messages. Sendmail listens for any mail messages received from other hosts and addressed to users on the network hosts it serves. At the same time, Sendmail handles messages users are sending out to remote users, determining what hosts to send them to. You can learn more about Sendmail at www. sendmail.org, including online documentation and current software packages. The Sendmail newsgroup is comp.mail.sendmail. You can also obtain a commercial version from www.sendmail.com.

The domain name server for your network designates the host that runs the Sendmail server. This is your mail host. Messages are sent to this host, whose Sendmail server then sends the message to the appropriate user and its host. In your domain name server configuration file, the mail host entry is specified with an MX entry. To print the mail queue of messages for future delivery, you can use mailq (or sendmail -v -q). This runs Sendmail with instructions to print the mail queue.

The Sendmail software package contains several utilities for managing your Sendmail server. These include mailq, which displays the queue of outgoing messages; mailstats, which shows statistics on mail server use; hoststat, which provides the stats of remote hosts that have connected with the mail server; and praliases, which prints out the mail aliases listed in the /etc/aliases file. Some, like mailq and hoststat, simply invoke Sendmail with certain options. Others, like mailstats and praliases, are separate programs.

Sendmail now maintains all configuration and database files in the /etc/mail directory. Here you will find the Sendmail macro configuration file, sendmail.mc, as well as several database files (see Table 24-2). Many have changed their names with the release of Sendmail 8.10. For example, the help file is now /etc/mail/helpfile instead of /etc/sendmail.ht. Specialized files provide support for certain features such as access, which lets you control access by different hosts and networks to your mail server. virtusertable lets you designate virtual hosts. These files have both text and database versions. The database version ends with the extension .db and is the file actually used by Sendmail. You would make your entries in the text version and then effect the changes by generating a corresponding database version. Database versions are generated using the makemap command with the hash option and a redirection operation for the text and database file. For example, to deny access to a particular host, you would place the appropriate entry for it in the /etc/mail/access file, editing the file using any text word processor. Then, to generate the /etc/mail/access.db version of the access file, you would change to the /etc/mail directory and use the following command:

cd /etc/mail makemap hash access < access

To regenerate all the database files, just use the make command in the /etc/mail directory:

make

Certain files and directories are used to manage the mail received and sent. Incoming mail is usually kept in the /var/spool/mail directory, and outgoing messages are held in the /var/spool/mqueue directory, with subdirectories for different users. Monitoring and error messages are logged in the /var/log/maillog file.

Note 

Red Hat now places the Sendmail configuration file, sendmail.cf, in the /etc/mail directory instead of the /etc directory as it did in previous versions (7.3 and earlier).

Table 24-2: Sendmail Files and Directories

File	Description
/etc/mail/sendmail.cf	Sendmail configuration file.
/etc/mail/sendmail.mc	Sendmail M4 macro configuration file.
/etc/aliases	Sendmail aliases file for mailing lists.
/etc/aliases.db	Sendmail aliases database file generated by the newaliases command using the aliases file.
/etc/mail/access	Sendmail access text file. Access control for screening or relaying messages from different hosts, networks, or users. Used to generate the access.db file.
/etc/mail/access.db	Sendmail access database file. Generated from the access text file.
/etc/mail/local-host-names	Sendmail local hosts file for multiple hosts using the same mail server (formerly sendmail.cw).
/etc/mail/trusted-users	Sendmail trusted users file (formerly sendmail.ct).
/etc/mail/error-header	Sendmail error header file (formerly sendmail.oE).
/etc/mail/helpfile	Sendmail help file (formerly sendmail.ht).
/etc/mail/statistics	Sendmail statistics file (formerly sendmail.st).
/etc/mail/virtusertable	Sendmail virtual user table text file. Maps user virtual domain addresses, allowing virtual domains to be hosted on one system. Make entries in this file and then use it to generate the virtusertable.db file.
/etc/mail/virtusertable.db	Sendmail virtual user table database generated from the virtusertable file.
/etc/mail/mailertable	Sendmail mailer table text file, used to override routing for your domains.
/etc/mail/mailertable.db	Sendmail mailer table database file, generated from the mailertable file.
/etc/mail/userdb	Sendmail user database file.
/etc/mail/domaintable	Sendmail domaintable file, maps a domain name to another domain name.
/etc/mail/domaintable.db	Sendmail domaintable database file, generated from the domaintable file.
/var/spool/mail	Incoming mail.
/var/spool/mqueue	Outgoing mail.
/var/spool/maillog	Mail log file.

Note 

If your mail server services several hosts, you will need to enter them in the /etc/mail/local-host-names file.

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 [e-mail], you would use the following entry:

filmcritic:   [e-mail]

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 [e-mail], 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) 

Table 24-3: Sendmail Features

Feature	Description
use_cw_file	Checks for hosts served by the mail server /etc/mail/local-host-names file.
use_ct_file	Reads a list of users from the /etc/trusted-users file. These are trusted users that can change the sender name for their messages.
redirect	Rejects all mail addressed to "address.REDIRECT", providing a forwarding address is placed in the /etc/aliases file.
mailertable	Uses a mailer table file, /etc/mail/mailertable, to override routing for particular domains.
domaintable	Uses a domain table file, /etc/mail/domaintable, to map one domain to another. Useful if you change your domain name.
allmasquerade	Causes recipient addresses to also masquerade as being from the masquerade host.
masquerade_entire_domain	Masquerades all hosts within the domain specified in MASQUERADE_AS.
masquerade_envelope	Masquerades envelope sender and recipient along with headers.
virtusertable	For virtual hosts, maps virtual addresses to real addresses.
nullclient	Turns a Sendmail server into a null client, which simply forwards mail messages to a central mail server for processing.
local_procmail	Uses procmail as the local mailer.
smrsh	Uses the Sendmail Restricted Shell (smrsh) for mailing.
promiscuous_relay	Allows you to relay mail, allowing mail to be received from outside your domain and sent on to hosts outside your domain.
relay_entire_domain	Allows any host in your domain to relay mail (default limits this to hosts in the access database).
relay_hosts_only	Checks for relay permission for particular hosts instead of domains.
accept_unqualified_senders	Allows sender e-mail address to be single usernames instead of just fully qualified names that include domain names.
accept_unresolvable_domains	Allows Sendmail to accept unresolvable domain names. Useful for those users in a local network blocked by a firewall from the full DNS namespace. By default, Sendmail requires domains in addresses to be resolvable with DNS.
access_db	Accepts or rejects mail from domains and hosts in the access database.
blacklist_recipients	Blocks mail to certain users, such as those that should never receive mail—like the users nobody and host.
dnsbl	Rejects hosts in the Realtime Blackhole List. Managed by MAPS (Mail Abuse Prevention System LLC) and designed to limit transport of unwanted mass e-mail. mail-abuse.org.
ldap_routing	Enables LDAP use.

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, [e-mail] can now e-mail a message to [e-mail]. 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 [e-mail], not [e-mail]. 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

Note 

As you will see in Chapter 34, you can define virtual domains for your network. These virtual domains are mapped to one or more real domains by your DNS server. However, you can receive messages with mail addresses for users on your virtual domains. In this case, you need to map these addresses to users on your real domain so that the mail can be delivered to an existing location. This mapping is carried out by the virtual user table called /etc/mail/virtusertable. The virtual user table lets you map mail addresses for virtual domains to users on real domains.

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 [e-mail] and sends a notice of the rejection:

[e-mail] REJECT

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

[e-mail]    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 [e-mail]    REJECT [e-mail]  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:

Table 24-4: Access Actions

Action	Description
OK	Accepts message even if other rules would reject (exception to the rules).
DISCARD	Discards the message completely.
REJECT	Rejects the message, sending a rejection notice to the sender.
RELAY	Relays messages for specified domain.
SMTP-code message	Code and message to be sent to sender.

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 [e-mail], [e-mail], or mysurfboard.com:

mysurfboard.com                 ERROR:"Domain does not exist" [e-mail]        "Moved to Hawaii" [e-mail]  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.

---