Tài liệu TCP/IP Network Administration- P9 docx

Previous: 10.2 Running sendmail as a Daemon Chapter 10 sendmail Next: 10.4 The sendmail.cf File 10.3 sendmail Aliases It is almost impossible to exaggerate the importance of mail alias

Previous: 9.7 Mail Servers Chapter 9

Configuring Network Servers Next: 10 sendmail

9.8 Summary

This chapter covers several important TCP/IP network services

Network File System (NFS) is the leading TCP/IP file-sharing protocol It allows server systems to

share directories with clients that are then used by the clients as if they were local disk drives NFS

uses trusted hosts and UNIX UIDs and GIDs for authentication and authorization pcnfsd provides

password-based user authentication and NFS-based printer sharing for non-UNIX clients

NFS-based printer sharing is not the only type of printer sharing available on a TCP/IP network It is

also possible to use the Line Printer Daemon (LPD) This software is originally from BSD UNIX but

is widely available The lpd program reads the printer definitions from the printcap file.

Network Information Service (NIS) is a server that distributes several system administrations

databases It allows central control of and automatic distribution of important system configuration information

Bootstrap Protocol provides a wide range of configuration values to its client Each implementation

of BOOTP has a different configuration file and command syntax The CMU BOOTP server stores

configuration parameters in the /etc/bootptab file and uses a syntax very similar to the /etc/printcap

syntax

Dynamic Host Configuration Protocol (DHCP) extends BOOTP to provide the full set of

configuration parameters defined in the Requirements for Internet Hosts RFC It also provides for

dynamic address allocation, which allows a network to make maximum use of a limited set of

addresses

Large networks use distributed boot servers to avoid overloading a single server and to avoid sending boot parameters through IP routers The configuration files on distributed boot servers are kept

synchronized through file transfer, NFS file sharing, or the Remote File Distribution Program (rdist).

Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) servers allow email to be

stored on the mail server until the user is ready to read it In the next chapter, we take a closer look at

configuring an electronic mail system as we explore sendmail.

Previous: 9.7 Mail Servers TCP/IP Network

Administration

Next: 10 sendmail

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

Previous: 9.8 Summary Chapter 10 Next: 10.2 Running

Rewriting the Mail Address

Modifying a sendmail.cf File

program, and it's the one we cover

This entire chapter is devoted to sendmail, and an entire book is easily devoted to the subject [1] In part this is because of email's importance, but it is also because sendmail has a complex configuration

[1] See sendmail, by Costales and Allman (O'Reilly & Associates), for a book-length

treatment of sendmail

The variety of programs and protocols used for email complicates configuration and support SMTP sends email over TCP/IP networks Another program sends mail between users on the same system Still another sends mail between systems on UUCP networks Each of these mail systems - SMTP, UUCP, and local mail - has its own delivery program and its own mail addressing scheme All of this can cause confusion for mail users and for system administrators

10.1 sendmail's Function

sendmail eliminates some of the confusion caused by multiple mail delivery programs It does this by routing mail for the user to the proper delivery program based on the email address It accepts mail from a user's mail program, interprets the mail address, rewrites the address into the proper form for the delivery program, and routes the mail to the correct delivery program sendmail insulates the end user from these details If the mail is properly addressed, sendmail will see that it is properly passed

on for delivery Likewise, for incoming mail, sendmail interprets the address and either delivers the mail to a user's mail program or forwards it to another system

Figure 10.1 illustrates sendmail's special role in routing mail between the various mail programs found on UNIX systems

Figure 10.1: Mail is routed through sendmail

In addition to routing mail between user programs and delivery programs, sendmail:

● Receives and delivers SMTP (internet) mail

● Provides system-wide mail aliases, which allow mailing lists

Configuring a system to perform all of these functions properly is a complex task In this chapter we discuss each of these functions, look at how they are configured, and examine ways to simplify the task First, we'll see how sendmail is run to receive SMTP mail Then we'll see how mail aliases are used, and how sendmail is configured to route mail based on the mail's address

Previous: 9.8 Summary TCP/IP Network

Administration

Next: 10.2 Running sendmail as a Daemon

Daemon

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

Previous: 10.1 sendmail's

Function

Chapter 10 sendmail Next: 10.3 sendmail Aliases

10.2 Running sendmail as a Daemon

To receive SMTP mail from the network, run sendmail as a daemon during system startup The sendmail daemon listens to TCP port 25 and processes incoming mail In most cases the code to start sendmail is already in one of your boot scripts If it isn't, add it The following code is from the Slackware Linux

/etc/rc.d/rc.M startup script:

# Start the sendmail daemon:

if [ -x /usr/sbin/sendmail ]; then

echo "Starting sendmail daemon (/usr/sbin/sendmail -bd -q 15m) " /usr/sbin/sendmail -bd -q 15m

fi

First, this code checks for the existence of the sendmail program If the program is found, the code displays

a startup message on the console and runs sendmail with two command-line options One option, the -q

option, tells sendmail how often to process the mail queue In the sample code, the queue is processed every

15 minutes (-q15m), which is a good setting to process the queue frequently Don't set this time too low

Processing the queue too often can cause problems if the queue grows very large, due to a delivery problem

such as a network outage For the average desktop system, every hour (-q1h) or half hour (-q30m) is an

adequate setting.

The other option relates directly to receiving SMTP mail The option (-bd) tells sendmail to run as a daemon

and to listen to TCP port 25 for incoming mail Use this option if you want your system to accept incoming TCP/IP mail.

The Linux example is a simple one Some systems have a more complex startup script Solaris 2.5, which

dedicates the entire /etc/init.d/sendmail script to starting sendmail, is a notable example The mail queue

directory holds mail that has not yet been delivered It is possible that the system went down while the mail queue was being processed Versions of sendmail prior to sendmail V8, such as the version that comes with Solaris 2.5, create lock files when processing the queue Therefore lock files may have been left behind inadvertently and should be removed during the boot Solaris checks for the existence of the mail queue directory and removes any lock files found there If a mail queue directory doesn't exist, it creates one The additional code found in some startup scripts is not required when running sendmail V8 All you really need

is the sendmail command with the -bd option.

Previous: 10.1 sendmail's

Function

TCP/IP Network Administration

Next: 10.3 sendmail Aliases 10.1 sendmail's Function Book Index 10.3 sendmail Aliases

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

Previous: 10.2 Running

sendmail as a Daemon

Chapter 10 sendmail Next: 10.4 The sendmail.cf

File

10.3 sendmail Aliases

It is almost impossible to exaggerate the importance of mail aliases Without them, a sendmail system could not act as a central mail server Mail aliases provide for:

● Alternate names (nicknames) for individual users

● Forwarding of mail to other hosts

alias: recipient[, recipient, ]

alias is the name to which the mail is addressed, and recipient is the name to which the mail is delivered recipient can be a username, the name of another alias, or a full email address

containing both a username and a hostname Including a hostname allows mail to be forwarded to a remote host Additionally, there can be multiple recipients for a single alias Mail addressed to that alias is delivered to all of the recipients, thus creating a mailing list

Aliases that define nicknames for individual users can be used to handle frequently misspelled names

You can also use aliases to deliver mail addressed to special names, such as postmaster or root, to the

real users that do those jobs Aliases can also be used to implement simplified mail addressing,

especially when used in conjunction with MX records [3] This aliases file from almond shows all of

The first two aliases are special names Using these aliases, mail addressed to postmaster is delivered

to the local user clark, and mail addressed to root is delivered to norman.

The second set of aliases is in the form of firstname and lastname The first alias in this group is

rebecca.hunt Mail addressed to rebecca.hunt is forwarded from almond and delivered to

becky@peanut Combine this alias with an MX record that names almond as the mail server for

nuts.com, and mail addressed to rebecca.hunt@nuts.com is delivered to becky@peanut.nuts.com This

type of addressing scheme allows each user to advertise a consistent mailing address that does not change just because the user's account moves to another host Additionally, if a remote user knows

that this firstname.lastname addressing scheme is used at nuts.com, he can address mail to Rebecca Hunt as rebecca.hunt@nuts.com without knowing her real email address.

The last two aliases are for a mailing list The alias admin defines the list itself If mail is sent to

admin, a copy of the mail is sent to each of the recipients (kathy, david, sara, becky, craig, anna, jane,

and christy) Note that the mailing list continues across multiple lines A line that starts with a blank

or a tab is a continuation line

The admin alias is a special form used by sendmail The format of this special alias is

owner-listname where owner-listname is the name of a mailing list The person specified on this alias line is

responsible for the list identified by listname If sendmail has problems delivering mail to any of the recipients in the admin list, an error message is sent to owner-admin The owner-admin alias points to

admin-request as the person responsible for maintaining the mailing list admin Aliases in the form of

listname-request are commonly used for administrative requests, such as subscribing to a list, for

manually maintained mailing lists Notice that we point an alias to another alias, which is perfectly

legal The admin-request alias resolves to craig.

sendmail does not use the aliases file directly The aliases file must first be processed by the

newaliases command newaliases is equivalent to sendmail with the -bi option, which causes

sendmail to build the aliases database newaliases creates the database files that are used by sendmail

when it is searching for aliases Invoke newaliases after updating the aliases file to make sure that

sendmail is able to use the new aliases [4]

[4] If the D option is used (see Appendix E, A sendmail Reference), sendmail

automatically rebuilds the aliases database - even if newaliases is not run.

10.3.1 Personal mail forwarding

In addition to the mail forwarding provided by aliases, sendmail allows individual users to define their own forwarding The user defines her personal forwarding in the forward file in her home directory sendmail checks for this file after using the aliases file and before making final delivery to the user If the forward file exists, sendmail delivers the mail as directed by that file For example, say that user kathy has a forward file in her home directory that contains kathy@podunk.edu The mail that sendmail would normally deliver to the local user kathy is forwarded to kathy's account at

podunk.edu.

Use the forward file for temporary forwarding Modifying aliases and rebuilding the database takes more effort than modifying a forward file, particularly if the forwarding change will be short-lived Additionally, the forward file puts the user in charge of his own mail forwarding.

Mail aliases and mail forwarding are handled by the aliases file and the forward file Everything else about the sendmail configuration is handled in the sendmail.cf file.

Previous: 10.2 Running

sendmail as a Daemon

TCP/IP Network Administration

Next: 10.4 The sendmail.cf File

10.2 Running sendmail as a

Daemon

Book Index 10.4 The sendmail.cf File

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

Previous: 10.3 sendmail

Aliases

Chapter 10 sendmail Next: 10.5 sendmail

Configuration

10.4 The sendmail.cf File

The sendmail configuration file is sendmail.cf [5] It contains most of the sendmail configuration,

including the information required to route mail between the user mail programs and the mail delivery

programs The sendmail.cf file has three main functions:

[5] The default location for the configuration file is the /etc directory, but it is often

placed in other directories, such as /etc/mail and /usr/lib.

● It defines the sendmail environment

● It rewrites addresses into the appropriate syntax for the receiving mailer

● It maps addresses into the instructions necessary to deliver the mail

Several commands are necessary to perform all of these functions Macro definitions and option

commands define the environment Rewrite rules rewrite email addresses Mailer definitions define the instructions necessary to deliver the mail The terse syntax of these commands makes most system

administrators reluctant to read a sendmail.cf file, let alone write one! Fortunately, you can avoid writing your own sendmail.cf file, and we'll show you how.

10.4.1 Locating a Sample sendmail.cf File

There is rarely any good reason to write a sendmail.cf file from scratch Locate an existing file with a

configuration similar to your system's and modify it That's how you configure sendmail, and that's what we discuss in this section

Sample configuration files are delivered with most systems' software Some system administrators use the configuration file that comes with the system and make small modifications to it to handle site-specific configuration requirements We cover this approach to sendmail configuration later in this chapter

Other system administrators prefer to use the latest version of sendmail They download the

sendmail.tar file and use the m4 source files it contains to build a sendmail.cf file The samples that

come with your system are adequate only if you also use the sendmail executable that comes with

your system If you update sendmail, use the m4 source files that are compatible with the updated

version of sendmail.

The tar file can be downloaded via anonymous ftp from ftp.sendmail.org [6] Login and change to the

pub/sendmail directory This displays a list of the available versions of sendmail See Appendix E, for

an example of downloading and installing the sendmail distribution

[6] Even if your UNIX system comes with its own version of sendmail, obtain the tar

file for the useful documentation it contains, e.g., the Sendmail Installation and

Operation Guide, by Eric Allman.

The sendmail cf/cf directory contains several sample configuration files Several of these are generic files preconfigured for different operating systems The cf/cf directory on my system contains generic

configurations for BSD, Solaris, SunOS, HP Unix, Ultrix, OSF1, and Next Step The directory also contains a few prototype files designed to be easily modified and used for other operating systems

We will modify the tcpproto.mc file, which is for systems that have direct TCP/IP network

connections and no direct UUCP connections, to run on our Linux system

10.4.1.1 Building a sendmail.cf with m4 macros

The prototype files that come with the sendmail tar are not "ready to run." They must be edited and then processed by the m4 macro processor to produce the actual configuration files For example, the

tcpproto.mc file contains the following macros:

These macros are not sendmail commands; they are input for the m4 macro processor The few lines

shown above are the important lines in the tcpproto.mc file They are preceded by a section of

comments, not shown here, that is discarded by m4 because it follows a divert(-1) command, which

diverts the output to the "bit bucket." This section of the file begins with a divert(0) command that means these commands should be processed and that the results should be directed to standard output [7]

[7] The dnl option is used to prevent excessive blank lines from appearing in the output

file It affects the appearance, but not the function, of the output file dnl can appear at

the end of any macro command

The VERSIONID macro is used for version control Usually the value passed in the macro call is a version number in RCS (Release Control System) or SCCS (Source Code Control System) format This macro is optional and we just ignore it

The OSTYPE macro defines operating system-specific information for the sendmail.cf file The

cf/ostype directory contains more than 30 pre-defined operating system macro files The OSTYPE

macro is required and the value passed in the OSTYPE macro call must match the name of one of the files in the directory Examples of values are: bsd4.4, solaris2, and linux

The FEATURE macro defines optional features to be included in the sendmail.cf file The nouucp

feature in the sample shown above says that no special UUCP address processing is to be included in

the output file Recall that in the previous section we identified tcpproto.mc as the prototype file for

systems that have no UUCP connections Another prototype file would have different FEATURE values

The prototype file ends with the mailer macros These must be the last macros in the input file The sample shown above specifies the local mailer macro, which adds the local mailer and the prog mailer

to the output, and the smtp mailer macro, which adds mailers for SMTP, Extended SMTP, 8-bit

SMTP and relayed mail All of these mailers are described later in this chapter

To create a sample sendmail.cf for a Linux system from the tcpproto.mc prototype file, copy the

prototype file to a work file Edit the work file by changing the OSTYPE line from unknown to

linux to specify the correct operating system In the example we use sed to change unknown to

linux We store the result in a file we call linux.mc:

# sed 's/unknown/linux/' < tcpproto.mc > linux.mc

Then enter the m4 command:

# m4 /m4/cf.m4 linux.mc > sendmail.cf

The sendmail.cf file output by the m4 command is in the correct format to be read by the sendmail

program [8] In fact, the output file produced above is almost identical to the sample linux.smtp.cf

configuration file delivered with Linux

[8] New syntax and functions in the latest version of the sendmail.cf file may not be

supported by older versions of the sendmail program

OSTYPE is not the only thing in the macro file that can be modified to create a custom configuration There are a large number of configuration options, all of which are explained in Appendix E As an

example we modify a few options to create a custom configuration that converts user@host email addresses originating from our computer into firstname.lastname@domain To do this, we create two new configuration files: a macro file with specific values for the domain that we name nuts.com.m4 and a modified macro control file, linux.mc, that calls the new nuts.com.m4 file.

We create the new macro file nuts.com.m4 and place it in the cf/domain directory The new file

contains the following:

MASQUERADE_AS(nuts.com)

FEATURE(genericstable)

These lines say that we want to hide the real hostname and display the name nuts.com in its place in

outbound email addresses Also, we want to do this on "envelope" addresses as well as message

header addresses The last line says that we will use the generic address conversion database, which converts login usernames to any value we wish We must build the database by creating a text file

with the data we want and processing that file through the makemap command that comes with

Dan.Scribner@nuts.com A small database such as this one can be easily built by hand On a system with a large number of existing user accounts, you may want to automate this process by

extracting the user's login name, and first and last names from the /etc/passwd file The gcos field of the /etc/passwd file often contains the user's real name [9] Once the data is in a text file convert it to a

database with the makemap command The makemap command is included in the sendmail V8 tar file It requires the ndbm library The syntax of the makemap command is:

[9] See Appendix E for a sample script that builds the realnames database from

/etc/passwd.

makemap type name

makemap reads the standard input and writes the database out to a file it creates using the value

provided by name as the filename The type field identifies the database type The most commonly supported database types for sendmail V8 are dbm, btree, and hash [10] All of these types can be

made with the makemap command.

[10] On Sun OS and Solaris systems, NIS maps and NIS+ tables are built with standard

commands that come with those operating systems The syntax for using those maps

within sendmail is different (see Table 10-4) Networking Personal Computers with

TCP/IP, by Craig Hunt (O'Reilly & Associates) provides an example of using a NIS

map inside of sendmail

Assume that the data shown above has been put in a file named realnames The following command

converts that file to a database:

# makemap hash genericstable < realnames

makemap reads the text file and produces a database file called genericstable The database maps

login names to real names, e.g., the key willy returns the value Bill.Wright@nuts.com

Now that we have created the database, we create a new sendmail configuration file to use it All of

the m4 macros related to using the database are in the nuts.com.m4 file We need to include that file in

the configuration To do that, add a DOMAIN(nuts.com) line to the macro control file (linux.mc)

and then process the linux.mc through m4 The following grep command shows what the macros in

the file look like after the change:

# grep '^[A-Z]' linux.mc

Use the prototype mc files as the starting point of your configuration if you install sendmail from the

tar file To use the latest version of sendmail you must build a compatible sendmail.cf file using the m4 macros Don't attempt to use an old sendmail.cf file with a new version of sendmail You'll just

cause yourself grief As you can see from the sample above, m4 configuration files are very short and can be constructed from only a few macros Use m4 to build a fresh configuration every time you

upgrade sendmail

Conversely, you should not use a sendmail.cf file created from the prototype files found in the

sendmail distribution with an old version of sendmail Features in these files require that you run a compatible version of sendmail, which means it is necessary to recompile sendmail to use the new configuration file [11] This is not something every system administrator will choose to do, because some systems don't have the correct libraries; others don't even have a C compiler! If you choose not

to recompile sendmail, you can use the sample sendmail.cf file provided with your system as a starting

point However, if you have major changes planned for your configuration, it is probably easier to

recompile sendmail and build a new configuration with m4 than it is to make major changes directly

to the sendmail.cf.

[11] See Appendix E for information about compiling sendmail

In the next part of this chapter, we use one of the sample sendmail.cf files provided with Linux The specific file we start with is linux.smtp.cf found in the /usr/src/sendmail directory on the Slackware 96

version of Linux All of the things that we discuss in the remainder of the chapter apply equally well

to sendmail.cf files that are produced by m4 The structure of a sendmail.cf file, the commands that it

contains, and the tools used to debug it are universal.

10.4.2 General sendmail.cf Structure

Many sendmail.cf files have more or less the same structure because most are descendants of a few

original files Therefore, the files provided with your system probably are similar to the ones used in our examples Some systems use a different structure, but the functions of the sections described here

will be found somewhere in most sendmail.cf files.

The Linux file, linux.smtp.cf, is our example of sendmail.cf file structure The section labels from the sample file are used here to provide an overview of the sendmail.cf structure These sections will be

described in greater detail when we modify a sample configuration The sections are:

Local Information

Defines the information that is specific to the individual host In the linux.smtp.cf file, Local

Information defines the host name, the names of any mail relay hosts, and the mail domain It also contains the name that sendmail uses to identify itself when it returns error messages, the message that sendmail displays during an SMTP login, and the version number of the

sendmail.cf file (Increase the version number each time you modify the configuration.) This

section is usually customized during configuration

definitions are usually not modified However, the rewrite rules associated with the mailers are sometimes modified to correct a problem or to add a new service.

The section labels in the sample file delivered with your system are probably different from these However, the structure of your sample file is probably similar to the structure discussed above in these ways:

● The information that is customized for each host is probably at the beginning of the file

● Similar types of commands, e.g., option commands, header commands, etc., are usually

grouped together

● The bulk of the file consists of rewrite rules

● The last part of the file probably contains mailer definitions intermixed with the rewrite rules that are associated with the individual mailers

Look at the comments in your sendmail.cf file Sometimes these comments provide valuable insight

into the file structure and the things that are necessary to configure a system

It's important to realize how little of sendmail.cf needs to be modified for a typical system If you pick

the right sample file to work from, you may only need to modify a few lines in the first section From this perspective, sendmail configuration appears to be a trivial task So why are system administrators

intimidated by it? In large part it is because of the difficult syntax of the sendmail.cf configuration

language

Previous: 10.3 sendmail

Aliases

TCP/IP Network Administration

Next: 10.5 sendmail Configuration

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

Previous: 10.4 The

sendmail.cf File

Chapter 10 sendmail Next: 10.6 Rewriting the

Mail Address

10.5 sendmail Configuration

Every time sendmail starts up, it reads sendmail.cf For this reason, the syntax of the sendmail.cf

commands is designed to be easy for sendmail to parse - not necessarily easy for humans to read As a consequence, sendmail commands are very terse, even by UNIX standards

The configuration command is not separated from its variable or value by any spaces This "run

together" format makes the commands hard to read Figure 10.2 illustrates the format of a command In

the figure, a define macro command assigns the value nuts.com to the macro D.

Figure 10.2: A sendmail.cf configuration command

Starting with version 8 of sendmail, variable names are no longer restricted to a single character Long variable names, enclosed in braces, are now acceptable For example, the define macro shown in Figure 10.2 could be written:

D{Domain}nuts.com

However, a quick check of the sendmail.cf delivered with my Linux system shows that not a single long

variable name was used The traditional, short variable names are still the most common This terse syntax can be very hard to decipher, but it helps to remember that the first character on the line is

always the command From this single character you can determine what the command is and therefore its structure Table 10.1 lists the sendmail.cf commands and their syntax.

Table 10.1: sendmail Configuration Commands

Command Syntax Meaning

Version Level Vlevel[/vendor] Specify version level

Define Class Ccword1[ word2] Set class c to word1 word2

Set Option Ooption=value Set option to value

Trusted Users Tuser1[ user2 ] Trusted users are user1 user2

Set Precedence Pname=number Set name to precedence number

Define Mailer Mname, {field=value} Define mailer name

Define Header H[?mflag?]name:format Set header format

Define Rule Rlhs rhs comment Rewrite lhs patterns to rhs format

Key File Kname type [argument] Define database name

The following sections describe each configuration command in more detail

10.5.1 The Version Level Command

The version level command is an optional command not found in all sendmail.cf files You don't add a

V command to the sendmail.cf file or change one if it is already there The V command is inserted into

the configuration file when it is first built from m4 macros or by the vendor.

The level number on the V command line indicates the version level of the configuration syntax V1

is the oldest configuration syntax and V7 is the version supported by sendmail V8.8.5 Every level in between adds some feature extensions The vendor part of the V command identifies if any vendor

specific syntax is supported The default vendor value for the sendmail distribution is "Berkeley"

The V command tells the sendmail executable the level of syntax and commands required to support

this configuration If the sendmail program cannot support the requested commands and syntax, it

displays the following error message:

program that came with the operating system In the example we attempted to read a sendmail.cf that

was created by the m4 macros that came with sendmail 8.8.5 The syntax and functions needed by the

sendmail.cf file are not available in the sendmail program To use this configuration file, we would have

to compile a newer version of the sendmail program See Appendix E for an example of compiling sendmail

[12] See Table 10-4 for Sun-specific syntax.

You will never change the values on a V command You might, however, need to customize some D

commands

10.5.2 The Define Macro Command

The define macro command (D) defines a macro and stores a value in it Once the macro is defined, it is

used to provide the stored value to other sendmail.cf commands and directly to sendmail itself This

allows sendmail configurations to be shared by many systems, simply by modifying a few

system-specific macros

A macro name can be any single ASCII character or, as of sendmail V8, a word enclosed in curly

braces User-created macros use uppercase letters as names sendmail's own internal macros use

lowercase letters and special characters as names This does not mean that you won't be called upon to define a value for a macro with a lowercase name A few of these internal macros are sometimes

defined in the sendmail.cf file Table 10.2 provides a complete list of sendmail's internal macros

Table 10.2: sendmail's Internal Macros

Name Function

a Origination date in RFC 822 format

b Current date in RFC 822 format

d Date in UNIX (ctime) format

f Sender \(lqfrom\(rq address

g Sender address relative to the recipient

h Recipient host

j Fully qualified domain name (host plus domain)

l Format of the UNIX from line

m Name of this domain (domain only)

n Name of the daemon (for error messages)

o Set of "operators" in addresses[13]

u Recipient user

v Version number of sendmail

w Hostname of this site (host only)

x Full name of the sender

z Home directory of the recipient

- Validated sender address

[13] Obsolete in sendmail V8

To retrieve the value stored in a macro, reference it as $x, where x is the macro name Macros are expanded when the sendmail.cf file is read A special syntax, $&x, is used to expand macros when they are referenced The $&x syntax is only used with certain internal macros that change at runtime.

The code below defines the macros R, M, and Q After this code executes, $R returns almond, $M returns nuts.com, and $Q returns almond.nuts.com This sample code defines Q as containing the value

of R ($R), plus a literal dot, plus the value of M ($M).

DRalmond

DMnuts.com

DQ$R.$M

If you customize your sendmail.cf file, it will probably be necessary to modify some macro definitions

The macros that usually require modification define site-specific information, such as hostnames and domain names

10.5.2.1 Conditionals

A macro definition can contain a conditional Here's a conditional:

DX$g$?x ($x)$

The D is the define macro command; X is the macro being defined; and $g says to use the value stored

in macro g But what does "$?x ($x)$." mean? The construct $?x is a conditional It tests whether macro x has a value set If the macro has been set, the text following the conditional is interpreted The

$ construct ends the conditional

Given this, the assignment of macro X is interpreted as follows: X is assigned the value of g; and if x is set, it is also assigned a literal blank, a literal left parenthesis, the value of x, and a literal right

parenthesis

So if g contains chunt@nuts.com and x contains Craig Hunt, X will contain:

chunt@nuts.com (Craig Hunt)

The conditional can be used with an "else" construct, which is $| The full syntax of the conditional is:

10.5.3 The Define Class Command

Two commands, C and F, define sendmail classes A class is similar to an array of values Classes are

used for anything with multiple values that are handled in the same way, such as multiple names for the

local host or a list of uucp hostnames Classes allow sendmail to compare against a list of values,

instead of against a single value Special pattern matching symbols are used with classes The $=

symbol matches any value in a class, and the $~ symbol matches any value not in a class (More on

pattern matching later.)

Like macros, classes usually have single-character names, and user-created classes use uppercase letters for names Class values can be defined on a single line, on multiple lines, or loaded from a file For example, class w is used to define all of the hostnames by which the local host is known To assign class

w the values goober and pea, you can enter the values on a single line:

Cwgoober pea

Or you can enter the values on multiple lines:

Cwgoober

Cwpea

You can also use the F command to load the class values from a file The F command reads a file and

stores the words found there in a class variable For example, to define class w and assign it all of the

strings found in /etc/sendmail.cw, use:

Fw/etc/sendmail.cw

You may need to modify a few class definitions when creating your sendmail.cf file Frequently

information relating to uucp, to alias hostnames, and to special domains for mail routing is defined in class statements If your system has a uucp connection as well as a TCP/IP connection, pay particular

attention to the class definitions But in any case, check the class definitions carefully and make sure they apply to your configuration

Here we grep the Linux sample configuration file for lines beginning with C or F:

This grep shows that linux.smtp.cf defines classes w, P, O, , and E w contains the host's alias

hostnames P holds pseudo-domains used for mail routing O stores operators that cannot be part of a valid username The class (dot) is primarily of interest because it shows that variable names do not have to be alphabetic characters E lists the usernames that should always be associated with the local host's fully qualified domain name, even if simplified email addresses are being used for all other users (More on simplified addresses later.) In our sample file, the variables are all assigned default values

Remember that your system will be different The uppercase letters used for some of these class names mean that they are user-created classes These same class names may be used for other purposes on your

system, and are only presented here as an example Carefully read the comments in your sendmail.cf file

for guidance as to how classes and macros are used in your configuration

The class names that are lowercase letters or special characters are reserved for internal sendmail use All internal classes defined in sendmail versions after 8.8 are shown in Appendix E Most of these can

be ignored Only class w, which defines all of the hostnames the system will accept as its own, is

commonly modified in the sendmail.cf file.

10.5.4 The Set Option Command

The set option commands (O) command is used to define the sendmail environment Use the O

command to set values appropriate for your installation The value assigned to an option is a string, an integer, a Boolean, or a time interval, as appropriate for the individual option All options define values used directly by sendmail

There are no user-created options The meaning of each sendmail option is defined within sendmail itself Appendix E lists the meaning and use of each option, and there are plenty of them

A few sample options from the linux.smtp.cf file are shown below The AliasFile option defines the

name of the sendmail aliases file as /etc/aliases If you want to put the aliases file elsewhere, change

this option The TempFileMode option defines the default file mode as 0600 for temporary files created

by sendmail in /var/spool/mqueue The Timeout.queuereturn option sets the timeout interval for

undeliverable mail, here set to five days (5d) These options show the kind of general configuration

parameters set by the option command.

# location of alias file

O AliasFile=/etc/aliases

# temporary file mode

The old syntax is: Oovalue, where O is the command, o is the single character option name, and value is

the value assigned to the option The options shown in the previous discussion, if written in the old syntax, would be:

# location of alias file

Most of the options defined in a sample file don't require modification People change options settings because they want to change the sendmail environment, not because they have to The options in your configuration file are almost certainly correct for your system

10.5.5 Defining Trusted Users

The T command defines a list of users who are trusted to override the sender address using the mailer -f

flag [14] Normally the trusted users are defined as root, uucp, and daemon Trusted users can be

specified as a list of usernames on a single command line, or on multiple command lines The users

must be valid usernames from the /etc/passwd file

[14] Mailer flags are listed in Appendix E

The most commonly defined trusted users are:

Troot

Tdaemon

Tuucp

Most sites do not need to modify this list

10.5.6 Defining Mail Precedence

Precedence is one of the factors used by sendmail to assign priority to messages entering its queue The

P command defines the message precedence values available to sendmail users The higher the

precedence number, the greater the precedence of the message The default precedence of a message is

0 Negative precedence numbers indicate especially low-priority mail Error messages are not generated for mail with a negative precedence number, making low priorities attractive for mass mailings Some commonly used precedence values are:

To specify the precedence he desires, a user adds a Precedence header to his message He uses the text

name from the P command in the Precedence header to set the specific precedence of the message

Given the precedence definitions shown above, a user who wanted to avoid receiving error messages for

a large mailing could select a message precedence of -60 by including the following header line in his mail:

Precedence: bulk

The five precedence values shown above are probably more than you'll ever need

10.5.7 Defining Mail Headers

The H command defines the format of header lines that sendmail inserts into messages The format of the header command is the H command, optional header flags enclosed in question marks, a header

name, a colon, and a header template The header template is a combination of literals and macros that are included in the header line Macros in the header template are expanded before the header is inserted

in a message The same conditional syntax used in macro definitions can be used in header templates, and it functions in exactly the same way: it allows you to test whether a macro is set and to use another value if it is not set

The header flags often arouse more questions than they merit The function of the flags is very simple The header flags control whether or not the header is inserted into mail bound for a specific mailer If no flags are specified, the header is used for all mailers If a flag is specified, the header is used only for a mailer that has the same flag set in the mailer's definition (Mailer flags are listed in Appendix E.)

Header flags only control header insertion If a header is received in the input, it is passed to the output,

regardless of the flag settings

Some sample header definitions from the linux.smtp.cf sample file are:

H?P?Return-Path: $g

H?D?Date: $a

H?F?From: $?x$x <$g>$|$g$

H?x?Full-Name: $x