Red Hat [Electronic resources] : The Complete Reference Enterprise Linux Fedora Edition؛ The Complete Reference نسخه متنی

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.

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








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 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:































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 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 .