Features of the sendmail Program

The sendmail program provides the following features:

• It supports UNIX System V mail, UNIX version 7 mail, and Internet mail.
• sendmail is reliable. It is designed to correctly deliver every message. No message should ever be completely lost.
• sendmail uses existing software for delivery whenever possible.
• sendmail expands easily to complex environments, including multiple connections to a single network type (like with UUCP or Ethernet). sendmail considers the contents of a name as well as its syntax to determine which mailer to use.
• sendmail uses configuration files to control mail configuration.
• Groups can maintain their own mailing lists. Individuals can specify their own forwarding without modifying the domain-wide alias file (typically located in the domain-wide aliases maintained by NIS or NIS+).
• Each user can specify a custom mailer to process incoming mail, which can provide functions like returning an "I am on vacation" message. See the reference manual page for vacation(1) for more information.
• sendmail minimizes network traffic by batching recipients to a single host where possible, without assistance from the user.

Figure C-1 shows how sendmail interacts with the other programs in the mail system.

Figure C-1 sendmail

The user interacts with a mail-generating and sending program. When the mail is submitted, the mail-generating program calls sendmail, which routes the message to the correct mailer(s). Since some of the senders may be network servers and some of the mailers may be network clients, sendmail may be used as an Internet mail gateway.

Overview of sendmail Functions

The sendmail program is a message router that calls administrator-defined mailer programs to deliver messages. It collects a message from a program, like mail, edits the header of the message as required by the destination mailer, and calls appropriate mailers to do delivery or queueing for network transmission. When mailing to a file, however, sendmail delivers directly. New mailers can be added at minimum cost.

Interfaces to the Outside World

The sendmail program communicates with the outside world in three ways:

• Using the conventional argument vector/exit status
• Using pairs of pipes
• Using SMTP over a TCP connection

Argument Vector/Exit Status

The standard way to communicate with a process is by using the argument vector (command name and arguments). The argument vector sends a list of recipients, and the message body is sent on the standard input. If problems occur, anything that the mailer prints is collected and returned to the sender. After the message is sent, the exit status from the mailer is collected, and a diagnostic is printed, if appropriate.

SMTP Over Pipes

The SMTP protocol can be used to run an interactive lock-step interface with the mailer. A subprocess is still created, but no recipient names are passed to the mailer via the argument list. Instead, they are passed one at a time in commands sent to the processes' standard input. Anything appearing on the standard output must be a standard SMTP reply code.

SMTP Over a TCP Connection

This technique is similar to SMTP over pipes, except that it uses a TCP connection. SMTP over a TCP connection is normally used to connect to a sendmail process on another system. This method is exceptionally flexible because the mailer need not reside on the same machine.

How sendmail Works

When a sender wants to send a message, the sender issues a request to sendmail using one of the three methods described above. sendmail operates as described on the following pages.

Argument Processing and Address Parsing

If sendmail is called by using the argument vector or is connected to over a pipe, the arguments are first scanned and option specifications are processed. Recipient names are then collected, either from the command line or from the SMTP command, and a list of recipients is created. Aliases are expanded at this step, including mailing lists. As much validation as possible of the remote recipient is done at this step; syntax is checked, and local recipients are verified, but detailed checking of host names is deferred until delivery. Forwarding is also performed as the local recipients are verified.

sendmail appends each name to the recipient list after parsing. When a name is aliased or forwarded, the old name is retained in the list, and a flag is set that tells the delivery phase to ignore this recipient. This list is kept free from duplicates, preventing alias loops and duplicate messages from being delivered to the same recipient, as might occur if a person is in two groups.

---

Note - Users may receive duplicate copies of the same message when alias lists contain email addresses using different syntax for the same person. sendmail cannot always match the email addresses as duplicates of one another.

---

Message Collection

sendmail then collects the message. The message must have a header at the beginning. No formatting requirements are imposed on the message body except that they must be lines of text (in other words, binary data is not allowed). The header is stored in memory, and the body of the message is saved in a temporary file.

To simplify the program interface, the message is collected even if no names were valid. The message will be returned with an error.

Message Delivery

For each unique mailer and host in the recipient list, sendmail calls the appropriate mailer. Each mailer invocation sends to all users receiving the message on one host. Mailers that only accept one recipient at a time are handled properly.

The message is sent to the mailer by using one of the same three interfaces used to submit a message to sendmail. Each copy of the message is appended by a customized header. The mailer status code is caught and checked, and a suitable error message is given, as appropriate. The exit code must conform to a system standard, or a generic message (Service unavailable) is given.

Queueing for Retransmission

When the mailer returns a status that shows that it might be able to handle the mail later, sendmail queues the mail and tries again later.

Return to Sender

When errors occur during processing, sendmail returns the message to the sender for retransmission. The letter can be mailed back (when the mail comes from a different site) or written in the dead.letter file in the sender's home directory.

Message Header Editing

Certain editing of the message header occurs automatically. Header lines can be inserted under control of the configuration file. Some lines can be merged; for example, a From: line and a Full-name: line can be merged under certain circumstances.

Configuration File

Almost all configuration information is read at runtime from a text file, that includes macro definitions (the value of macros used internally), header declarations (the format of header lines that are specially processed, and lines that are added or reformatted), mailer definitions (giving information like the location and characteristics of each mailer), and name-rewriting rules (a limited pattern-matching system used to rewrite names).

How sendmail Is Implemented

You can follow flag arguments with recipient name arguments unless you run sendmail in SMTP mode. In brief, the format of recipient names is:

• Anything in parentheses is thrown away (as a comment).

• Anything in angle brackets (<>) is preferred over anything else. This rule implements the Internet standard that sends names of the following form to the electronic system-name rather than the human username:

username <system-name>

• Double quotation marks (") quote phrases; backslashes (\) quote characters. Backslashes cause otherwise equivalent phrases to compare differently--for example, user and "use" are equivalent, but \user is different from either of them.

Parentheses, angle brackets, and double quotation marks must be properly balanced and nested. The rewriting rules control the rest of the needed processing.

Mail to Files and Programs

Files and programs are legitimate message recipients. Files provide archival storage of messages, useful for project administration and history. Programs are useful as recipients in a variety of situations, for example, to use mailsort to sort mail, or to have the vacation program respond with an informational message when users are away.

Any name passing through the initial parsing algorithm as a local name is scanned for two special cases:

• If the prefix is a vertical bar (|), the rest of the name is processed as a shell command.
• If the user name begins with a slash (/), the name is used as a file name instead of a login name.

Message Collection

Once all recipient names are parsed and verified, the message is collected. The message comes in two parts: a message header and a message body. The header and the body are separated by a blank line.

The header is formatted as a series of lines in this form:

field-name: field-value

For example, a sample header might be:

From: John Smith <Smith@Podunk.edu>

field-value can be split across lines by starting the subsequent lines with a space or a Tab. Some header fields have special internal meaning, and have appropriate special processing. Other headers are simply passed through. Some header fields, like time stamps, may be added automatically.

The body is a series of text lines. It is completely uninterpreted and untouched, except that lines beginning with a dot have the dot doubled when transmitted over an SMTP channel. This extra dot is stripped by the receiver.

Message Delivery

The send queue is grouped by the receiving host before transmission to implement message batching. An argument list is built as the scan proceeds. Mail being sent to files is detected during the scan of the send list. The interface to the mailer is performed by using one of the techniques described in "Overview of sendmail Functions" on page 359.

After a connection is established, sendmail makes the per-mailer changes to the header and sends the result to the mailer. If any mail is rejected by the mailer, a flag is set to invoke the return-to-sender function after all delivery is complete.

Queued Messages

If the mailer returns a temporary failure exit status, the message is queued. A control file is used to describe the recipients and various other parameters. This control file is formatted as a series of lines, each describing a sender, a recipient, the time of submission, or some other parameter of the

message. The header of the message is stored in the control file so that the associated data file in the queue is just the temporary file that was originally collected.

Configuration Overview

Configuration is controlled primarily by a configuration file read at startup. Adding mailers or changing the name-rewriting or routing information does not require recompiling. The configuration file encodes macro definitions, header definitions, mailer definitions, name-rewriting rules, and options.

Macros

Macros can be used in several ways. Certain macros transmit unstructured textual information into the mail system, like the name that sendmail will use to identify itself in error messages. Other macros are unused internally, and can be used as shorthand in the configuration file.

Header Declarations

Header declarations inform sendmail of the format of known header lines. Knowledge of a few header lines is built into sendmail, like the From: and Date: lines.

Most configured headers are automatically inserted into the outgoing message if they do not exist in the incoming message. Certain headers are suppressed by some mailers.

Mailer Declarations

Mailer declarations specify the internal name of the mailer, some flags associated with the mailer, and an argument vector to be used on the call. This vector is expanded by macro before use.

Name-Rewriting Rules

Name-rewriting rules are the heart of name parsing in sendmail. They are an ordered list of pattern-replacement rules, which are applied to each name. For example, rule set zero determines which mailer to use. sendmail rewrites the message until it is in a form that can be parsed. When a pattern matches, the rule is reapplied until it fails.

The configuration file also supports the editing of names into different formats. For example, a name in this form:

ucsfcgl!tef

might be mapped into:

tef@ucsfcgl.UUCP

to conform to the internal syntax. Translations can also be done in the other direction for particular mailers.

Option Setting

Several options can be set from the configuration file. These include the path names of various support files, timeouts, default modes, and so forth.

Arguments to sendmail

Arguments to sendmail are listed and described in detail in the section "sendmail Command-Line Arguments" on page 409. Some of the important arguments are described in this section.

Queue Interval

The -q flag defines how often sendmail runs the queue. If you run in mode i or b (the default), this time can be relatively long, because it is only relevant when a host that was down comes back up. If, however, you run in q mode,

the time should be relatively short, since the flag defines the maximum amount of time that a message may sit in the queue. Typical queue time is set to between 15 minutes (-q15m) and one hour (-q1h).

Daemon Mode

If you allow incoming mail over a TCP connection, you should have a daemon running. Set the -bd flag in your /etc/rc3.d/S88sendmail file.

You can combine the -bd flag and the -q flag in one call:

# /usr/lib/sendmail -bd -q30m

Debugging

sendmail has many debug flags, which you set using the -d option. Each debug flag has a number and a level, where higher levels mean "print more information." The convention is that you do not need to set levels greater than 9 unless you are debugging that particular piece of code. The syntax for debug flags is:

debug-flag : -d debug-list debug-list : debug-option[,debug-option ] . . . debug-option : debug-range[.debug-level ] debug-range : integer |integer-integer debug-level : integer

For example:

Table C-1

Debugging Flag	Description
-d12	Set flag 12 to level 1
-d12.3	Set flag 12 to level 3
-d3-17	Set flags 3 through 17 to level 1
-d3-17.4	Set flags 3 through 17 to level 4

If you have source code, you can refer to the list of debug flags in the code.

Trying a Different Configuration File

You can specify an alternative configuration file by using the -C flag; for example:

# /usr/lib/sendmail -Ctest.cf

uses the configuration file test.cf instead of the default /etc/mail/sendmail.cf. If you do not define a value for the -C flag, it uses the sendmail.cf file in the current directory.

Tuning Configuration Parameters

You can tune several configuration parameters, depending on the requirements of your site. You can set most of these parameters by using an option in the configuration file. For example, the line OT3d sets option T to the value 3d (three days).

Time Values

All time intervals use a syntax of numbers and letters. For example, 10m is 10 minutes, and 2h30m is two-and-one-half hours.

Table C-2 lists the time symbols.

Table C-2

Code	Description
s	Seconds
m	Minutes
h	Hours
d	Days
w	Weeks

Queue Interval

The argument to the -q flag specifies how often sendmail runs the queue. It is usually set to between 15 minutes (-q15m) and one hour (-q1h).

Read Timeouts

The Or option in the configuration file sets the read timeout. The default read timeout is Or15m. Although it is technically unacceptable within the published protocols, sendmail may time out when reading the standard input or when reading from a remote SMTP server. If your site has problems with read timeouts, set the read timeout to a larger value, like one hour (Or1h), to reduce the chance of several idle daemons piling up on your system.

Message Timeouts

The OT option in the configuration file sets the message timeout. The default message timeout is three days (OT3d). After a message has been in the queue for the message timeout period, the sender is notified that the message could not be delivered.

You can flush messages that have been hanging for a short period by running the queue with a short message timeout. For example:

# /usr/lib/sendmail -oT1d -q

runs the queue and flushes anything that is one day old or older.

Delivery Mode

The Od option in the configuration file sets the delivery mode. The default delivery mode is Odbackground. Delivery modes specify how quickly mail is delivered. Legal modes are shown in Table C-3.

Table C-3

Code	Description
i	Deliver interactively (synchronously)
b	Deliver in background (asynchronously)
q	Queue only (do not deliver)

There are tradeoffs. The interactive mode (i) passes the maximum amount of information to the sender, but it is hardly ever necessary. The queue mode (q) puts the minimum load on your machine, but means that delivery may be delayed for up to the queue interval. The background mode (b), the default, is a good compromise.

Load Limiting

Central mail machines often can be overloaded. The best solution is to dedicate a more powerful machine to handling mail, but the load almost always expands to consume whatever resources are allocated.

The sendmail programs enable you to limit the load. The goal of load limiting is to prevent wasting time during loaded periods by attempting to deliver large messages, messages to many recipients, and messages to sites that have been down for a long time.

Use the Ox and OX options to limit the load caused by sendmail. The default is not to set any load limits if no options are used. Both of these configuration options take an argument that is an integer load average. For example, if you specify Ox4 and OX8, then the x load limiting will be used when the load is above four, and the X load limiting will be used when the load is above eight. When the load is above the value specified in the X option, the SMTP server does not accept connections from the network (locally originated mail and other mail like UUCP are not affected). The x option has a more subtle effect, controlling whether messages are queued for later delivery or delivered

immediately. The general idea is always to deliver "small" messages immediately, and to defer "large" messages for delivery during off-peak periods.

The Oq option specifies the maximum size of a message that is delivered immediately. The "size" of the message includes not only the number of bytes in the message, but also the penalty for a large number of recipients, and for unsuccessful delivery attempts. The penalty per recipient is option value y, by default set to 1000. The penalty per delivery attempt is the option value z, by default set to 9000. The size limit also depends on the current load, so that more and more messages are queued as the load goes higher. If the load is one above the x threshold, then the limit is halved; if the load is two above the threshold, the limit is divided by three, and so on. Note that this limit also applies to messages being delivered when running the queue.

Log Level

You can adjust the level of logging for sendmail. The levels are shown in Table C-4.

Table C-4

Code	Description
0	No logging
1	Major problems only
2	Message collections and failed deliveries
3	Successful deliveries
4	Messages being deferred (due to a host being down, for example.)
5	Normal message "queue ups"
6	Unusual but benign incidents; for example, trying to process a locked queue file
9	(Default) Log internal queue ID to external message ID mappings, which can be useful for tracing a message as it travels between several hosts
12	Messages that are of interest when debugging
16	Verbose information regarding the queue
22	Everything

Refer to the system error logging section in Common Administration Tasks for more information.

File Modes

Certain files may have protections modes that control access. This section describes the modes that you can control from the sendmail.cf file. The modes you use depend on what functionality you want and the level of security you require.

setuid

By default, the sendmail program is executed with the user ID set to 0 (setuid to root) so that it can deliver to programs that might write in a user's home directory. When sendmail is ready to execute a mailer program, sendmail checks to see if the user ID is 0; if so, it resets the user ID and group ID to the values set by the u and g options in the configuration file. The user ID and group ID are both set to 1 (daemon). You can override these values by setting the S flag to the mailer (for mailers that are trusted, and must be called as root). However, mail processing is accounted to root rather than to the user sending the mail.

Temporary File Modes

The OF option sets the mode of all the temporary files that sendmail uses. The default, OF0600. 0600 is appropriate for secure mail, and 0644 is more permissive. If you use the more permissive mode, it is not necessary to run sendmail as root at all (even when running the queue). Users will be able to read mail in the queue.

Should My Alias Database Be Writable?

One approach is to provide the alias database (/etc/mail/aliases*) with mode 666. If you use this approach, users can modify any list. However, you may want to limit the aliases that a user can change by putting them into a file that the user can edit and referencing this file from /etc/mail/aliases. Such references have the following format:

alias-name::include:/filename

sendmail Configuration File

This section describes the configuration file in detail, including hints for writing your own file.

The syntax of the configuration file is reasonably easy to parse, since parsing can be done every time sendmail starts. Unfortunately, this syntax sacrifices readability.

sendmail uses single letters for several different functions:

• Command-line flags
• Configuration options
• Queue file line types
• Configuration file line types
• Mailer field names
• Mailer flags
• Macro names
• Class names

The following sections provide an overview of the configuration file, and details of its semantics.

Purpose of the sendmail Configuration File

The sendmail configuration file has three parts:

• Definition of symbols, classes, options, and parameters
• Definitions of mailers and delivery programs
• Rule sets that determine the rules for rewriting addresses

You define symbols, classes, options, and parameters to set up the environment for sendmail, setting the options and defining a few critical macros.

You define your mailers and delivery programs so that sendmail knows which protocols to use and which delivery programs to interact with.

You define rewriting rules, grouped into rule sets, to transform addresses from one form to another. In general, each rule in a rule set is applied to a particular address. An address might be rewritten several times within a rule set.

There are eight standard rule sets, applied in the order shown in Table C-5.

Table C-5

Rule set	Description
Rule set 3	The first rule set applied. It tries to put the address into the form: local-address@host-domain.
Rule set 0	Determines the destination, and which mailer program to use to send the message. It resolves the destination into a triple (mailer, host, user).
Rule set 1	Rewrites the sender address.
Rule set X	Specifies additional rule sets that enable the sender addresses to do final mailer-specific cleanup. These rule sets have different names for each mailer. S, for example, stands for a generic "sender."
Rule set 2	Rewrites the recipient address.
Rule set R	Specifies additional rule sets that enable the recipient addresses to do final mailer-specific cleanup. These rule sets have different names for each mailer. R, in this example, stands for a generic "sender."
Rule set 4	Rewrites all addresses for the last time, usually from internal to external form.

Rule set 0 must resolve to the internal form, which is in turn used as a pointer to a mailer descriptor. The mailer descriptor describes the interface requirements of the mailer.

Rewriting names in the message is typically done in two phases. The first phase uses rule set 3 to map names in any format into a local-address@host-domain form. The second phase converts map names to the canonical form into the syntax appropriate for the receiving mailer. sendmail rewrites names in three subphases. Rule sets 1 and 2 are applied to all sender and recipient names, respectively. You may specify mailer-specific rule sets in rule set 3 for both sender and recipient names. Finally, rule set 4 is applied to do any conversion to external form.

RFC 822 describes the format of the mail message itself. sendmail follows this RFC closely, to the extent that many of the standards described in this document cannot be changed without changing the code. In particular, the following characters have special interpretations:

< > ( ) " \

---

Caution - Use the RFC 822 special characters < > ( ) " \ only for their designated purposes. Information between parentheses, (), is reserved for comments or personal names. Information between angle brackets, <>, is reserved for local-address@host-domain addresses.

---

A Sample sendmail Configuration File

The following code example shows the default main.cf file. Subsequent sections describe the syntax and semantics used in this file.

Code Example C-1 The Default main.cf File (1 of 10)

############################################################ # # Sendmail configuration file for "MAIN MACHINES" # # You should install this file as /etc/sendmail.cf # if your machine is the main (or only) mail-relaying # machine in your domain. Then edit the file to # customize it for your network configuration. # # @(#)main.mc 1.17 90/01/04 SMI # ### local info Lm maildomain # my official hostname # You have two choices here. If you want the gateway machine to identify # itself as the DOMAIN, use this line: Dj$m # If you want the gateway machine to appear to be INSIDE the domain, use: #Dj$w.$m # Unless you are using sendmail.mx (or have a fully-qualified hostname), use: #Dj$w # major relay mailer - typical choice is "ddn" if you are on the # Defense Data Network (e.g. Arpanet or Milnet) DMsmartuucp # major relay host: use the $M mailer to send mail to other domains

Code Example C-1 The Default main.cf File (Continued) (2 of 10)

DRddn-gateway CRddn-gateway # If you want to pre-load the "mailhosts" then use a line like # FS /usr/lib/mailhosts # and then change all the occurrences of $%y to be $=S instead. # Otherwise, the default is to use the hosts.byname map if NIS # is running (or else the /etc/hosts file if no NIS). # valid top-level domains (default passes ALL unknown domains up) CT arpa com edu gov mil net org CT us de fr jp kr nz il uk no au fi nl se ca ch my dk ar # options that you probably want on a mailhost: # checkpoint the queue after this many recipients OC10 # refuse to send tiny messages to more than these recipients Ob10 ################################################# # # General configuration information # local domain names # # These can now be determined from the domainname system call. # The first component of the NIS domain name is stripped off unless # it begins with a dot or a plus sign. # If your NIS domain is not inside the domain name you would like to have # appear in your mail headers, add a "Dm" line to define your domain name. # The Dm value is what is used in outgoing mail. The Cm values are # accepted in incoming mail. By default Cm is set from Dm, but you might # want to have more than one Cm line to recognize more than one domain # name on incoming mail during a transition. # Example: # DmCS.Podunk.EDU # Cm cs cs.Podunk.EDU # # known hosts in this domain are obtained from gethostbyname() call # Version number of configuration file

Code Example C-1 The Default main.cf File (Continued) (3 of 10)

#ident "@(#)version.m4 1.14 90/06/14 SMI" /* SVr4.0 1.1 */ DVSMI-SVR4 ### Standard macros # name used for error messages DnMailer-Daemon # UNIX header format DlFrom $g $d # delimiter (operator) characters Do.:%@!^=/[] # format of a total name Dq$g$?x ($x)$. # SMTP login message De$j Sendmail $v/$V ready at $b ### Options # Remote mode - send through server if mailbox directory is mounted OR # location of alias file OA/etc/mail/aliases # default delivery mode (deliver in background) Odbackground # rebuild the alias file automagically OD # temporary file mode -- 0600 for secure mail, 0644 for permissive OF0600 # default GID Og1 # location of help file OH/var/lib/sendmail.hf # log level OL9 # default messages to old style Oo # Cc my postmaster on error replies I generate OPPostmaster # queue directory

Code Example C-1 The Default main.cf File (Continued) (4 of 10)

OQ/var/spool/mqueue # read timeout for SMTP protocols Or15m # status file -- none OS/etc/mail/sendmail.st # queue up everything before starting transmission, for safety Os # return queued mail after this long OT3d # default UID Ou1 ### Message precedences Pfirst-class=0 Pspecial-delivery=100 Pjunk=-100 ### Trusted users T root daemon uucp ### Format of headers H?P?Return-Path: <$g> HReceived: $?sfrom $s $.by $j ($v/$V) id $i; $b H?D?Resent-Date: $a H?D?Date: $a H?F?Resent-From: $q H?F?From: $q H?x?Full-Name: $x HSubject: H?M?Resent-Message-Id: <$t.$i@$j> H?M?Message-Id: <$t.$i@$j> HErrors-To: ########################### ### Rewriting Rules ### ########################### #

Code Example C-1 The Default main.cf File (Continued) (5 of 10)

Sender Field Pre-rewriting S1 # None needed. # Recipient Field Pre-rewriting S2 # None needed. # Name Canonicalization # Internal format of names within the rewriting rules is: # anything<@host.domain.domain...>anything # We try to get every kind of name into this format, except for local # names, which have no host part. The reason for the "<>" stuff is # that the relevant host name could be on the front of the name (for # source routing), or on the back (normal form). We enclose the one that # we want to route on in the <>'s to make it easy to find. # S3 # handle "from:<>" special case R$*<>$* $@@ turn into magic token # basic textual canonicalization R$*<$+>$* $2 basic RFC822 parsing # make sure <@a,@b,@c:user@d> syntax is easy to parse -- undone later R@$+,$+:$+ @$1:$2:$3 change all "," to ":" R@$+:$+ $@$>6<@$1>:$2 src route canonical R$+:$*;@$+ $@$1:$2;@$3 list syntax R$+@$+ $:$1<@$2> focus on domain R$+<$+@$+> $1$2<@$3> move gaze right R$+<@$+> $@$>6$1<@$2> already canonical # convert old-style names to domain-based names # All old-style names parse from left to right, without precedence. R$-!$+ $@$>6$2<@$1.uucp> uucphost!user R$-.$+!$+ $@$>6$3<@$1.$2> host.domain!user R$+%$+ $@$>3$1@$2 user%host

Code Example C-1 The Default main.cf File (Continued) (6 of 10)

# Final Output Post-rewriting S4 R$+<@$+.uucp> $2!$1 u@h.uucp => h!u R$+ $: $>9 $1 Clean up addr R$*<$+>$* $1$2$3 defocus # Clean up an name for passing to a mailer # (but leave it focused) S9 R$=w!@ $@$w!$n R@ $@$n handle <> error addr R$*<$*LOCAL>$* $1<$2$m>$3 change local info R<@$+>$*:$+:$+ <@$1>$2,$3:$4 <route-addr> canonical ####################### # Rewriting rules # special local conversions S6 R$*<@$*$=m>$* $1<@$2LOCAL>$4 convert local domain # Local and Program Mailer specification Mlocal, P=/bin/mail, F=flsSDFMmnP, S=10, R=20, A=mail -d $u Mprog, P=/bin/sh, F=lsDFMeuP, S=10, R=20, A=sh -c $u S10 # None needed. S20 # None needed. #ident "@(#)etherm.m4 1.12 90/06/14 SMI" /* SVr4.0 1.1 */ # ############################################################ ##### ##### Ethernet Mailer specification #####

Code Example C-1 The Default main.cf File (Continued) (7 of 10)

##### Messages processed by this configuration are assumed to remain ##### in the same domain. This really has nothing particular to do ##### with Ethernet - the name is historical. Mether, P=[TCP], F=msDFMuCX, S=11, R=21, A=TCP $h S11 R$*<@$+>$* $@$1<@$2>$3 already ok R$+ $@$1<@$w> tack on our hostname S21 # None needed. ########################################################## # General code to convert back to old style UUCP names S5 R$+<@LOCAL> $@ $w!$1 name@LOCAL => sun!name R$+<@$-.LOCAL> $@ $2!$1 u@h.LOCAL => h!u R$+<@$+.uucp> $@ $2!$1 u@h.uucp => h!u R$+<@$*> $@ $2!$1 u@h => h!u # Route-addrs do not work here. Punt til uucp-mail comes up with something. R<@$+>$* $@ @$1$2 just defocus and punt R$*<$*>$* $@ $1$2$3 Defocus strange stuff # UUCP Mailer specification Muucp, P=/usr/bin/uux, F=msDFMhuU, S=13, R=23, A=uux - -r -a$f $h!rmail ($u) # Convert uucp sender (From) field S13 R$+ $:$>5$1 convert to old style R$=w!$+ $2 strip local name R$+ $:$w!$1 stick on real host name # Convert uucp recipient (To, Cc) fields S23 R$+ $:$>5$1 convert to old style #ident "@(#)ddnm.m4 1.5 90/06/14 SMI" /* SVr4.0 1.1 */

Code Example C-1 The Default main.cf File (Continued) (8 of 10)

############################################################ # # DDN Mailer specification # # Send mail on the Defense Data Network # (such as Arpanet or Milnet) Mddn, P=[TCP], F=msDFMuCX, S=22, R=22, A=TCP $h, E=\r\n # map containing the inverse of mail.aliases DZmail.byaddr S22 R$*<@LOCAL>$* $:$1 R$-<@$-> $:$>3${Z$1@$2$} invert aliases R$*<@$+.$*>$* $@$1<@$2.$3>$4 already ok R$+<@$+>$* $@$1<@$2.$m>$3 tack on our domain R$+ $@$1<@$m> tack on our domain # "Smart" UUCP mailer: Uses UUCP transport but domain-style naming Msmartuucp, P=/usr/bin/uux, F=CmsDFMhuU, S=22, R=22, A=uux - -r $h!rmail ($u) ############################################################ # # RULESET ZERO # # This is the ruleset that determines which mailer a name goes to. # Ruleset 30 just calls rulesets 3 then 0. S30 R$* $: $>3 $1 First canonicalize R$* $@ $>0 $1 Then rerun ruleset 0 S0 # On entry, the address has been canonicalized and focused by ruleset 3. # Handle special cases..... R@ $#local $:$n handle <> form

Code Example C-1 The Default main.cf File (Continued) (9 of 10)

# resolve the local hostname to "LOCAL". R$*<$*$=w.LOCAL>$* $1<$2LOCAL>$4 thishost.LOCAL R$*<$*$=w.uucp>$* $1<$2LOCAL>$4 thishost.uucp R$*<$*$=w>$* $1<$2LOCAL>$4 thishost # Mail addressed explicitly to the domain gateway (us) R$*<@LOCAL> $@$>30$1 strip our name, retry R<@LOCAL>:$+ $@$>30$1 retry after route strip # For numeric spec, you can't pass spec on to receiver, since old rcvr's # are not smart enough to know that [x.y.z.a] is their own name. R<@[$+]>:$* $:$>9 <@[$1]>:$2 Clean it up, then... R<@[$+]>:$* $#ether $@[$1] $:$2 numeric internet spec R<@[$+]>,$* $#ether $@[$1] $:$2 numeric internet spec R$*<@[$+]> $#ether $@[$2] $:$1 numeric internet spec # deliver to known ethernet hosts explicitly specified in our domain R$*<@$%y.LOCAL>$* $#ether $@$2 $:$1<@$2>$3 user@host.sun.com # etherhost.uucp is treated as etherhost.$m for now. # This allows them to be addressed from uucp as foo!sun!etherhost!user. R$*<@$%y.uucp>$* $#ether $@$2 $:$1<@$2>$3 user@etherhost.uucp # Explicitly specified names in our domain -- that we've never heard of R$*<@$*.LOCAL>$* $#error $:Never heard of host $2 in domain $m # Clean up addresses for external use -- kills LOCAL, route-addr ,=>: R$* $:$>9 $1 Then continue... # resolve UUCP-style names R<@$-.uucp>:$+ $#uucp $@$1 $:$2 @host.uucp:... R$+<@$-.uucp> $#uucp $@$2 $:$1 user@host.uucp # Pass other valid names up the ladder to our forwarder #R$*<@$*.$=T>$* $#$M $@$R $:$1<@$2.$3>$4 user@domain.known # Replace following with above to only forward "known" top-level domains R$*<@$*.$+>$* $#$M $@$R $:$1<@$2.$3>$4 user@any.domain # if you are on the DDN, then comment-out both of the lines above # and use the following instead:

Code Example C-1 The Default main.cf File (Continued) (10 of 10)

#R$*<@$*.$+>$* $#ddn $@ $2.$3 $:$1<@$2.$3>$4 user@any.domain # All addresses in the rules ABOVE are absolute (fully qualified domains). # Addresses BELOW can be partially qualified. # deliver to known ethernet hosts R$*<@$%y>$* $#ether $@$2 $:$1<@$2>$3 user@etherhost # other non-local names have nowhere to go; return them to sender. R$*<@$+.$->$* $#error $:Unknown domain $3 R$*<@$+>$* $#error $:Never heard of $2 in domain $m R$*@$* $#error $:I don't understand $1@$2 # Local names with % are really not local! R$+%$+ $@$>30$1@$2 turn % => @, retry # everything else is a local name R$+ $#local $:$1 local names

sendmail Configuration File Syntax

The configuration file is organized as a series of lines, each of which begins with a single character defining the semantics for the rest of the line. Lines beginning with a space or a Tab are continuation lines (although the semantics are not well defined in many places). Blank lines and lines beginning with a pound sign (#) are comments.

D and L -- Define Macro

Macros are named with a single character. Although a macro can be defined with any character from the complete ASCII set, use only uppercase letters for macros that you define. However, do not use characters like M, R, L, G and V that are already used by sendmail. Lowercase letters and special symbols are used internally.

There are two ways you can define macros:

• D assigns the value directly specified.

• L assigns the value looked up in the sendmailvars database (either the NIS+ table or /etc/mail/sendmailvars file). The L command is classified as a Sun uncommitted interface.

The syntax for D macro definitions is:

DXval

where X is the name of the macro and val is the value it should have. No spaces are allowed. Macros can be inserted in most places using the escape sequence $X.

Here are examples of D macro definitions from the configuration file:

DRmailhost DmEng.Acme.COM

The variable R is set to contain the value mailhost and the internal variable m is set to contain the value Eng.Acme.COM.

The m macro defines the mail domain. If it is not defined, the naming service domain name is used with the first component stripped off. For example, Ecd.East.Acme.COM becomes East.Acme.COM. An even more flexible way to define the mail domain name is to use an L macro definition, as show below.

The syntax for an L macro definition is:

LXsearch_key

where X is the name of the macro and search_key is looked up in the sendmailvars database. The value found in the entry located by the search key is assigned to X.

Here is an example of an internal L macro definition from the configuration file:

Lmmaildomain

The variable m is set to the value found in the sendmailvars database using maildomain as the search key. If the entry in the sendmailvars database appears as follows:

maildomain Eng.Acme.COM

The value of m becomes Eng.Acme.COM.

---

Note - sendmail uses the sendmailvars entry in the /etc/nsswitch.conf file to determine the order in which to search the NIS+ and /etc/mail sendmailvars tables.

---

C, F, and G--Define Classes

You can define classes of words to match the left-hand side of address rewriting rules. For example, you might create a class of all local names for this site so that you can eliminate attempts to send mail to yourself.

You can give classes names from the set of uppercase letters. Lowercase letters and special characters are reserved for system use.

There are three ways to define classes:

• C assigns the values directly specified.
• F reads in the values from another file or from another command.
• G assigns the values looked up in the sendmailvars database (either the NIS+ table or /etc/mail/sendmailvars file). The G command is classified as a Sun uncommitted interface.

The syntaxes of the different forms of class definition are:

CX word1 word2

FX file [pattern]

FX | command

GXsearch_key

The first form defines the class X to match any of the named words. The second form reads words from the file into the class X, for example, FC /.rhosts. The pattern argument to the FC class is used with scanf to read

from the file; otherwise, the first word from each line is used. The third form executes the given command and reads the elements of the class from standard output of the command. For example:

FC | awk '{print $2}' /etc/hosts

The fourth form reads the elements of the class from the entry in the sendmailvars database pointed to by the search key. For example,

GVuucp-list

gets the definition of class V from the uucp-list entry in the sendmailvars database.

If the entry in the sendmailvars database appears as follows:

uucp-list sunmoon hugo comic

the value of V becomes sunmoon hugo comic.

---

Note - sendmail uses the sendmailvars entry in the /etc/nsswitch.conf file to determine the order in which to search the NIS+ and /etc/mail sendmailvars tables.

---

You could split class definitions among multiple lines. For example, the following:

CHmonet ucbmonet

is equivalent to:

CHmonet CHucbmonet

O-- Set Option

You can set several options (not to be confused with mailer flags or command-line arguments) from a configuration file. Options are also represented by single characters. The syntax of this line is:

Oc value

This sets option c to value. Depending on the option, value may be a string, an integer, a Boolean (with legal values t, T, f, or F--the default is "true''), or a time interval. See the section "sendmail Configuration Options" on page 410 for the list of options.

P-- Precedence Definitions

You can define values for the Precedence: field using the P control line. The syntax of this field is:

Pname=num

When the name is found in a Precedence: field, the message class is set to num. Higher numbers mean higher precedence. Numbers less than zero have the special property that error messages are not returned. The default precedence is 0 (zero). For example:

Pfirst-class=0 Pspecial-delivery=100 Pjunk=-100

T-- Define Trusted Users

Trusted users are those who are permitted to override the sender name by using the -f flag. These typically are root, uucp, daemon, and network. For some sites it may be convenient to extend this list to include other users, perhaps to support a separate UUCP login for each host. The syntax of this line is:

T user . . .

You can use more than one line to define trusted users.

H-- Define Header

The format of the header lines is defined by the H line. The syntax of this line is:

H[c ?c mflagsc ?]c hnamec :c htemplate

Continuation lines in this specification are inserted directly into the outgoing message. The htemplate is macro-expanded before it is inserted into the message. If the expansion is empty, the header line is not included. If the mflags (surrounded by question marks) are specified, at least one of the specified flags must be stated in the mailer definition before this header can be automatically output. If one of these headers is in the input, it is directed to the output regardless of these flags.

Special Header Lines

Several header lines have special interpretations defined by the configuration file. Others have interpretations built into sendmail that cannot be changed without changing the code. These built-in features are described in the following list:

• Return-Receipt-To:

If this header is sent, a message will be sent to any specified names when the delivery is complete. The mailer must have the l flag (local delivery) set in the mailer descriptor.

• Errors-To:

If errors occur anywhere during processing, this header sends error messages to the listed names rather than to the sender. Use this header line for mailing lists.

• To:

If a message comes in with no recipients listed in the message (in a To:, Cc:, or Bcc: line) then sendmail adds an Apparently To: header line for each recipient specified on the sendmail command line.

R and S--Rewriting Rules

Address parsing is done according to the rewriting rules, which is a simple pattern-matching and replacement system. sendmail scans through the set of rewriting rules looking for a match on the left-hand side (LHS) of the rule. When a rule matches, the name is replaced by the right-hand side (RHS) of the rule.

There are several sets of rewriting rules. Some of the rewriting sets are used internally and must have specific semantics. Other rewriting sets do not have specifically assigned semantics, and may be referenced by the mailer definitions or by other rewriting sets.

For example:

Sc n

sets the current rule set being collected to n. If you begin a rule set more than once, the new definition overwrites the old definition.

R is used to define a rule in the rule set. The syntax of the R line is:

Rlhs rhs comments

The lhs is a pattern that is applied to the input. If it matches, the input is rewritten to the rhs. The comments are ignored.

Here is an example of how a rule definition might look:

# handle "from:<>" special case R<> $@@ turn into magic token

The fields must be separated by at least one tab character; you may use embedded spaces in the fields.

M -- Define Mailer

Programs and interfaces to mailers are defined on this line. The format is:

Mc name, c {c field=value}*

where name is the name of the mailer (used in error messages) and the field=value pairs define attributes of the mailer. The fields are shown in Table C-6.

Table C-6

Field	Description
P	The path name of the mailer
F	Special flags for this mailer
S	A rewriting rule set for sender names
R	A rewriting rule set for recipient names
A	An argument vector to pass to this mailer
E	The end-of-line string for this mailer
M	The maximum message length to this mailer
L	The maximum length of the argv for this mailer

Address Rewriting Rules

This section describes the details of rewriting rules and mailer descriptions.

Special Macros, Conditionals

Special macros are referenced with the construct $x, where x is the name of the macro to be matched (LHS) or inserted (RHS). Lowercase letters are reserved for special semantics, and some special characters are reserved to provide conditionals.

The macros shown in Table C-7 must be defined to transmit information into sendmail.

Table C-7 sendmail

Macro	Description
e	The SMTP entry message
$e	Printed out when SMTP starts
j	The official domain name for this site
$j	Should be the first word of the $e macro; $j should be in domain name format
l	The format of the UNIX From line
n	The name of the daemon (for error messages)
o	The set of ''separators'' in names
$o	List of characters that are considered tokens
q	Default format of sender names
$q	Specifies how a sender should appear in a message when it is created

For example:

De$j Sendmail $v ready at $b* DnMAILER-DAEMON DlFrom $g $d Do.:%@!^=/ Dq$g$?x ($x)$.. Dj$H.$D.

You should not need to change any of these macros except under unusual circumstances. For example, you might want to change the banner (*) for security. You might want to change . or . to make several hosts look like one host.

An acceptable alternative for the $q macro is:

$?x$x $.<$g>

These correspond to the following two formats:

doe@Acme.COM (John Doe) John Doe <doe@Acme.COM>

Some macros are defined by sendmail for use in mailer arguments or for other contexts. These macros are shown in Table C-8.

Table C-8 sendmail

Macro	Description
a	Origination date in ARPANET format
b	Current date in ARPANET format
c	Hop count
d	Date in UNIX (ctime) format
f	Sender from name
g	Sender name relative to the recipient
h	Recipient host
i	Queue ID
m	Domain name
p	sendmail process ID
r	Protocol used
s	Sender's host name
t	Numeric representation of the current time
u	Recipient user

Table C-8 sendmail(Continued)

Macro	Description
v	Version number of sendmail
w	Host name of this site
x	Full name of the sender
z	Home directory of the recipient

You can use three types of dates. The $a and $b macros are in ARPANET format; $a is the time as extracted from the Date: line of the message (if there was one), and $b is the current date and time (used for postmarks). If no Date: line is found in the incoming message, $a is also set to the current time. The $d macro is equivalent to the $a macro in UNIX (ctime) format.

The $f macro is the ID of the sender as originally determined; for a message mailed to a specific host, the $g macro is set to the name of the sender relative to the recipient. For example, suppose the sender eric sends a message to bollard@matisse from the machine ucbarpa. The value of $f will be eric and the value of $g will be eric@ucbarpa.

The $x macro is set to the full name of the sender, which can be determined in several ways. It can be passed as a flag to sendmail (from the value of the Full-name: line in the header or use the comment field of a From: line). If the name can't be determined from the Full-name or From lines, and if the message is being originated locally, the full name is looked up in the /etc/passwd file. It can also be read from the name environment variable.

When a message is sent, the $h, $u, and $z macros get set to the host, user, and home directory (if local) of the recipient. The first two are set from the $@ and $: part of the rewriting rules, respectively.

The $p and $t macros are used to create unique strings (for example, for the Message-Id: field). The $i macro is set to the queue ID on this host; if put into the time stamp line, it can be useful for tracking messages. The $v macro is set to be the version number of sendmail; this is normally put in time stamps and is extremely useful for debugging. It can, however, be a security risk. The $w macro is set to the primary name of this host, as given by gethostname(3B) and gethostbyname(3N). The $c field is set to the "hop count"; that is, the number of times this message has been processed, which can be determined by counting the time stamps in the message.

The $r and $s fields are set to the protocol used to communicate with sendmail and the sending host name.

You can specify conditionals by using the syntax:

$?x text1 $| text2 $

This inserts text1 if the macro $x is set, and text2 otherwise. The else (c $|) clause may be omitted.

Special Classes

The class $=w is the set of all names by which this host is known. It can be used to delete local host names. The class $=m is set to the domain name.

Left-Hand Side of Address Rewriting Rules

The left-hand side of rewriting rules contains a pattern. Normal words are matched directly. Dollar signs introduce "metasymbols," which match things other than simple words, like macros or classes. The metasymbols are shown in Table C-9.

Table C-9 sendmail

Symbol	Matches
$*	Zero or more tokens.
$+	One or more tokens.
$-	Exactly one token.
$=x	Any string in class x.
$~x	Any token not in class x.
$%x	Any token in NIS map or NIS+ table $x.
$!x	Any token not in NIS map or NIS+ table $x.
$x	Macro x.

If any of the patterns matches, it is assigned to the symbol $c n for replacement on the right-hand side, where n is the index in the LHS. For example, the LHS rules can be applied to this input:

$-:$+

JUPITER:eric

The rule will match, and the values passed to the RHS will be:

$1  JUPITER
$2  eric

The $%x uses the macro x to specify the name of an NIS map. The special form $%y matches any host name in the hosts.byname map, or in /etc/hosts if not running NIS.

Right-Hand Side of Address Rewriting Rules

When the left-hand side of a rewriting rule matches, the input is replaced by the right-hand side. Tokens are copied directly from the right-hand side, unless they begin with a dollar sign, in which case they are treated as macros and expanded.

Metasymbols for more complicated substitutions are shown in Table C-10.

Table C-10 sendmail

Symbol	Description
$x	Expand macro x.
$n	Substitute indefinite token n from LHS. n is a digit.
$>n	Call rule set n. n is a digit.
$#mailer	Resolve to mailer.
$@host	Specify host.
$:user	Specify user.

Table C-10 sendmail(Continued)

Symbol	Description
$[host$]	Map to primary host name.
${x name$}	Map name through NIS map or NIS+ table $x. If the map name begins with rev, sendmail will reverse the aliases.

The $n (n being a digit) syntax substitutes the corresponding value from a $+, $-, $*, or $=^(R) match on the LHS. It may be used anywhere.

The $> n syntax substitutes the remainder of the line as usual and then passes it to rule set n. The final value of rule set n then becomes the substitution for this rule (like a procedure or function call).

Only use the $# syntax in rule set 0. Evaluation of the rule set stops immediately, and signals are sent to sendmail that the name has completely resolved. The complete syntax is:

$#mailer$@host$:user

This specifies the {mailer, host, user} triple necessary to direct the mailer. More processing may then take place, depending on the mailer. For example, local names are aliased.

A right-hand side may also be preceded by a $@ or a $: to control evaluation. A $@ prefix returns the remainder of the right-hand side as the value. A $: prefix terminates the rule immediately, but the rule set continues. Thus it can be used to limit a rule to one application. Neither prefix affects the result of the right-hand side expansion.

The $@ and $: prefixes can precede a $> spec. For example:

R$+ $:$>7$1

matches anything, passes that to rule set seven, and continues; the $: is necessary to avoid an infinite loop. The $[host]$ syntax replaces the host name with the "official" or primary host name, the one listed first in the

hosts.byname NIS map, or /etc/hosts if not running NIS. It is used to eliminate nicknames for hosts. The ${x name $} syntax replaces the string by the result of the nis_map_name indicated in macro $x.

Semantics of Rewriting Rule Sets

Five rewriting sets have specific semantics, as shown in Figure C-2.

Figure C-2

Rule set 3 is applied by sendmail before sendmail does anything with any name. Rule set 3 should turn the name into a form, with the basic syntax:

local-part@host-domain-spec

If no @ sign is specified, then the host-domain-spec may be appended from the sender name (if the C flag is set in the mailer definition corresponding to the sending mailer).

Rule set 0 is applied after rule set 3 to names that are actually going to specify recipients. It must resolve to a mailer, host, user triple. The mailer must be defined in the mailer definitions from the configuration file. The host is defined into the $h macro for use in the argument expansion of the specified mailer; the user is defined into $u.

Rule set 1 is applied to all From: recipient names, and rule set 2 is applied to all To: and Cc: lines. Then the rule sets specified in the mailer definition line (and R=) are applied. This process is done many times for one message, depending on how many mailers the message is routed to by rule set 0.

Rule set 4 is applied last to all names in the message. It is typically used to translate internal to external form.

error Mailer

You can use the mailer with the special name error in rule set 0 to generate a user error message. The user field is a message to be printed. For example, the entry:

$#error$:Host unknown in this domain

on the RHS of a rule generates the specified error, if the LHS matches.

Semantics of Mailer Descriptions

Each mailer has an internal name. It can be arbitrary, except that the names local and prog must be defined first and second, respectively. Rule set 0 resolves names to this mailer name (and a host and user name).

Give the path name of the mailer in the P field. If this mailer will be accessed by way of a TCP connection, use the string [TCP] instead.

Define the mailer flags in the F field. Specify an f or r flag to pass the name of the sender as a -f or -r flag respectively. These flags are only passed if they were passed to sendmail, so that mailers that give errors under some circumstances can be placated. In some cases, you may be able to specify -f$g

in the argv template. If the mailer must be called as root, and sendmail is running setuid to root, use the S flag; it will not reset the user ID before calling the mailer. If this mailer is local (that is, will perform final delivery rather than another network hop), use the flag. Quoted characters (backslashes and double quotation marks) can be stripped from names if the s flag is specified; if it is not specified, they are passed through. If the mailer is capable of sending to more than one user on the same host in a single transaction, use the m flag. If this flag is on, then the argv template containing $u is repeated for each unique user on a given host. The e flag marks the mailer as being "expensive," and sendmail defers connection until a queue run. Note that the c configuration option must also be set.

The C flag is a useful case. It applies to the mailer from which the message is sent, rather than the mailer where the message is received. If set, the domain specification of the sender (that is, the @host.domain part) is saved and is appended to any names in the message that do not already contain a domain specification. For example, a message in this form:

From: eric@jupiter To: joe@saturn, sam

is modified to:

From: eric@jupiter To: joe@saturn, sam@ganymede

if and only if the C flag is defined in the mailer corresponding to eric@jupiter.

The S and R fields in the mailer description are per-mailer rewriting sets to be applied to sender and recipient names, respectively. These are applied after the sending domain is appended and the general rewriting sets (number one or two) are applied, but before the output rewrite (rule set four) is applied. A typical use is to append the current domain to names that do not already have a domain. For example, a header in this form:

From: eric@host

might be changed to:

From: eric@host.Podunk.EDU

or

From: saturn!eric

depending on the domain into which it is being shipped. These sets can also be used to do special-purpose output rewriting in cooperation with rule set 4.

Table C-11

Field Name	Used To...
E	Define the string to use as an end-of-line indication. A string containing return and newline is the default (if using TCP, otherwise just a newline indicates end-of-line. You can use the print backslash escapes (/r, /n /f, /b).
A	Specify an argument vector template. It may have embedded spaces. The template is macro-expanded before being passed to the mailer. Useful macros include $h, the host name resolved by rule set 0, and $u, the user name (or names) resolved. If there is no argument with a $u macro in it, sendmail uses SMTP to communicate with the mailer. If the path name for this mailer is TCP, use the argument vector: TCP $h [ port ], where port is the optional port number to connect to.
L	Specify the maximum length of the $u macro passed to the mailer. To make UUCP mail more efficient, the L field can be used with the m flag to send mail to multiple recipients with one call to the mailer, while avoiding mailer limitations on argument length. $u always expands to at least one recipient even if that recipient exceeds the L= limit.

For example, the specification:

Mlocal, P=/bin/mail, F=flsSDFMmnP, S=10, R=20, A=mail -d $u Mprog, P=/bin/sh, F=lsDFMeuP, S=10, R=20, A=sh -c $u

specifies a mailer for local delivery and a mailer for Ethernet delivery. The first is called local, is located in the file /bin/mail, takes a -F flag, does local delivery, strips quotes from names, and delivers mail to multiple users at once. It applies rule set 10 to sender names in the message and applies rule set 20 to recipient names. The argument vector to send to a message is the word mail, the word -d, and words containing the name of the receiving user. If a -r flag is inserted, it is between the words mail and -d.

The second mailer is called ether.It is connected via TCP, and can handle multiple users at once. It defers connections, and appends any domain from the sender name to any receiver name without a domain; processes sender names by rule set 11 and recipient names by rule set 21. Messages passed through this mailer have a 100,000-byte limit.

Building a Configuration File

Building a configuration file "from scratch" is a complex task. Fortunately, it is almost never necessary; you can accommodate almost every situation by changing an existing file. In any case, it is critical that you understand what it is that you are trying to do, and to come up with a policy statement for the delivery of mail. This section explains the purpose of a configuration file and gives you some ideas about policies.

Domains and Policies

RFC 1006 describes domain-based naming. RFC 822 touches on this issue as well. Essentially each host is given a name that is a right-to-left dot-qualified pseudo-path from a distinguished root. The elements of the path are organizational entities, not physical networks.

RFC 822 and RFC 976 specify how certain sorts of addresses should be parsed. You can configure sendmail to follow or ignore these rules.

How to Proceed

After you have established a policy, examine the available configuration files to decide if you can use major parts of any of them. Even under the worst of conditions, there is a fair amount of boilerplate information that can be collected safely.

The next step is to build rule set 3, which specifies a rule set for your individual mailers. Building rule set 3 is the hardest part of the job. Here are some guidelines:

• Beware of doing too much to the name in this rule set, since anything you do will be reflected in the message.
• Do not strip local domains in this rule set. Doing so can leave you with names that have no domain specifications at all. sendmail appends the sending domain to names with no domain, which can change the semantics of names.
• Do not provide fully qualified domains in this rule set. Although technically correct, fully qualified domain names can lead to unnecessarily long names reflected into messages. The SunOS configuration files define rule set 9 to qualify domain names and strip local domains. Rule set 9 is called from rule set 0 to get all names into a cleaner form.

After you have rule set 3 finished, the other rule sets should be relatively simple. If you need hints, examine the supplied configuration files.

Testing the Rewriting Rules -- the -bt Flag

When you build a configuration file, you can do a certain amount of testing using the test mode of sendmail. For example, you could invoke sendmail as:

% sendmail -bt -Ctest.cf

which would read the configuration file test.cf and enter test mode. For example:

ADDRESS TEST MODE Enter <ruleset> <name> >

In this mode, you enter lines in this form:

ADDRESS TEST MODE Enter <ruleset> <name> > rwset name

where rwset is the rewriting set you want to use and name is a name to which to apply the set. Test mode shows you the steps it takes as it proceeds, and shows you the final name. You may use a comma-separated list of rwsets for sequential application of rules to an input; rule set three is always applied first. For example:

ADDRESS TEST MODE Enter <ruleset> <name> > 1,21,4 jupiter:smith

First apply rule set 3 to the input monet:bollard. Rule set 1 is then applied to the output of rule set 3, followed similarly by rule sets 21 and 24.

If you need more detail, you can also use the -d21 flag to turn on more debugging. For example:

% sendmail -bt -d21.99

turns on large amount of information; a single word name may result in several pages worth of information.

How sendmail Interacts With a Name Service

Mail domain is a concept used by the standard sendmail.cf file to determine whether mail should be delivered directly or via mailhost. Intra-domain mail is delivered via direct SMTP connection, while inter-domain mail is forwarded to a mailhost.

In a secure network, only a few selected hosts are authorized to generate packets targeted to external destinations. Even if a host has the IP address of the remote host external to the mail domain, this does not guarantee that an SMTP connection can be established. The standard sendmail.cf assumes the following:

• The current host is not authorized to send packets directly to a host outside the mail domain.
• Mailhost is capable of forwarding the mail to an authorized host that can transmit packets directly to an external host. (In fact, mailhost may itself be an authorized host.)

Given these assumptions, it is the responsibility of mailhost to deliver or forward inter-domain mail.

How to Set Up sendmail Requirements for Name Services

sendmail imposes various requirements on a name service. The following section explains these requirements and how to satisfy them. For more information, refer to the in.named(1M), nis+(1), nisaddent(1M), and nsswitch.conf(4) man pages.

1. The mail domain name must be a suffix of the name service domain. For example, if the domain name of name service is "A.B.C.D," then the mail domain name could be one of the following:

• A.B.C.D
• B.C.D
• C.D
• D

When first established, the mail domain name is identical to the name service domain. As the network grows larger, the name service domain is divided into more manageable pieces. However, the mail domain remains undivided to avoid large aliases and longer mail addresses.

• If you are setting NIS as the primary name service, sendmail automatically strips off the first component of the NIS domain name and uses the result as mail domain name. For example, EBS.Admin.Acme.COM becomes Admin.Acme.COM. No special command is needed.

• If you are setting up NIS+ as your Primary name service, a hierarchical name space is required by NIS+. sendmail can look up the mail domain from the NIS+ sendmailvars table, a two column NIS+ table with one key column and one value column. To setup your mail domain, you must add one entry to this table. This entry should have the key column set to the literal string "maildomain" and the value column set to the your mail domain name (for example, "Admin.Acme.COM"). Although NIS+ allows any string in the sendmailvars table, the suffix rule still applies for the mail system to work correctly. You can use nistbladm to add the maildomail entry to the sendmailvars table. For example, nistbleadm -A \

key="maildomain" value=<mail domain> \
sendmailvars.org_dir.<NIS+ domain>. Note that this mail domain
is a suffix of the NIS+ domain.

2. The host table or map in the name service must be set up to support three types of gethostbyname() queries:

   a. "mailhost"

   Many name service configurations satisfy this requirement. Several typical configurations are described below.

   i. NIS with DNS forwarding:

   When the DNS forwarding feature is turned on, queries that NIS cannot resolve are forwarded to DNS.

   ii. NIS+ in conjunction with DNS:

   If your network uses both NIS+ and DNS as the source for the host database, you can put the mailhost entry in either the NIS+ or DNS host table. Make sure that your users list NIS+ and DNS as the source for the host database in the /etc/nsswitch.conf file.

   iii. Using NIS+ or NIS as the only name service:

   If your network uses only one of these name services, you must have a mailhost entry in the NIS host map or the NIS+ hosts table.

   b. full host name (for example, smith.Admin.Acme.COM)

   Many name service configurations satisfy this requirement. Several typical configurations are described below.

   i. NIS with DNS forwarding:

Although NIS does not understand full host name, DNS does. This requirement is satisfied when you follow the regular procedure for setting up NIS and DNS.

ii. NIS+ and DNS:

Both NIS+ and DNS understand full host names. Following the regular NIS+ and DNS set up procedures satisfies this requirement.

iii. Using NIS+ as the only name service:

NIS+ understands the full host name. Following the regular NIS+ satisfies this requirement.

iv. Using NIS as the only name service:

This is a special case. The normal NIS setup does not understand the full host name. Rather than trying to make NIS understand the full host name, turn off this requirement from the sendmail side by editing the sendmail.cf file and replacing all the occurrence of %l with %y. This turns off sendmail's inter-domain mail detection. As long as the target host can be resolved to a IP address, a direct SMTP delivery will be attempted. Make sure that your NIS host map does not contain any host entry that is external to the current mail domain. Otherwise, you will need to further customize the sendmail.cf file.

c. short host name (for example, smith)

sendmail must connect to mailhost to forward external mail. To determine if a mail address is within the current mail domain, gethostbyname() is invoked with the full host name. If the entry is found, the address is considered internal.

NIS, NIS+ DNS all support gethostbyname() with a short host name as an argument, so this requirement automatically is satisfied.

3. Gethostbyname() with full and short host name should yield consistent results. For example, gethostbyname(smith.Admin.Acme.COM) should return the same result as gethostbyname(smith) as long as both functions are called from the mail domain Admin.Acme.COM.

   If you are using DNS in conjunction with NIS or NIS+, for every host entry in the NIS/NIS+ host table, you must have a corresponding host entry in DNS.

If you are using NIS, see Step 2 above for a description of how to turn off gethostbyname() with a full host name.

If you are using NIS+, see Step 4 below.

4. For all name service domains under a common mail domain, gethostbyname() with a short host name should yield the same result. For example, given the mail domain smith.Admin.Acme.COM, gethostbyname(smith) should return the same result calling from either domain EBB.Admin.Acme.COM or ESG.Admin.Acme.COM.

   The mail domain name is usually shorter than the name service domain, giving this requirement special implications to various name services.

• NIS

  All NIS host maps under a common mail domain should have the same set of host entries. For example, the host map in the EBS.Admin.Acme.COM domain should be the same as the host map in the ESG.Admin.Acme.COM. Otherwise, one address may work in one NIS domain but fail in the other NIS domain.

• NIS+

  To satisfy this requirement, you may duplicate the host table as described in the NIS information above, or you may take advantage of the pathing/linking feature in NIS+. There are many ways to use this feature to satisfy this requirement; following is one example of a configuration:

  i. Create an NIS+ table path (or object link) from the host table in the user name service domain to the host table in the mail domain level NIS+ domain.

  ii. Enter all hosts entries in the user name service domain(s) into the mail domain level domain.

  Because you are merging (logical or physically) multiple host tables into one host table, the same host name cannot be reused in the multiple name service domain sharing a common mail domain.

sendmail Command-Line Arguments

Use command-line arguments on the /usr/lib/sendmail command line. These arguments are described in Table C-12.

Table C-12 sendmail

Argument	Description
-r name	Set the sender's name to name. This flag is ignored unless the real user is listed as a trusted user or unless name contains an exclamation point (because of certain restrictions in UUCP).
-f name	This is an obsolete form of -r.
-h cnt	Set the "hop count" to cnt. It sets the number of times this message has been processed by sendmail (to the extent that it is supported by the underlying networks). cnt is incremented during processing, and if it reaches the value of configuration option h, sendmail returns the message with an error.
F name	Set the full name of this user to name.
-n	Do not do aliasing or forwarding.
-t	Read the header for To:, Cc:, and Bcc: lines, and send to everyone listed in those lists. The Bcc: line is deleted before sending. Any names in the argument vector are deleted from the send list.
-bx	Set operation mode to x. Operation modes are: m Deliver mail (default). a Run in ARPANET mode. s Use SMTP on input side. d Run as a daemon. t Run in test mode. v Just verify recipients. i Initialize the alias database. p Print the mail queue. z Freeze the configuration file.

Table C-12 sendmail(Continued)

Argument	Description
-qtime	Try to process the queued-up mail. If the time is given, sendmail repeatedly runs through the queue at the specified interval to deliver queued mail; otherwise, it runs only once.
-Cfile	Use a different configuration file.
-dlevel	Set debugging level.
-oxvalue	Set configuration option x to the specified value.
-M msgid	Run given message ID from the queue.
-R recipient	Run messages for given recipient only from the queue.

These options are described in the next section, "Configuration Options."

You can specify several configuration options as primitive flags. These are the c, e, i, m, T, and v arguments. Also, you can specify the f configuration option as the -s argument.

sendmail Configuration Options

You can set the options shown in Table C-13 using the -o flag on the command line or the O line in the configuration file.

Table C-13 sendmail (1 of 4)

Option	Description
Afile	Use the named file as the alias file instead of /etc/mail/aliases. If no file is specified, use aliases in the current directory.
atime	Wait a set amount of time for an @:@ entry to exist in the alias database before starting up. If it does not appear after that time, rebuild the database.
Bvalue	Blank substitute. Default is the dot (.) character.
bn	Disallow empty messages to more than n recipients.
Cn	Do a check after n recipients.

Table C-13 sendmail(Continued) (2 of 4)

Option	Description
c	If an outgoing mailer is marked as being expensive, do not connect immediately. A queue process must be run to actually send the mail.
D	If set, rebuild the alias database if necessary and possible. If this option is not set, sendmail never rebuilds the alias database unless explicitly requested with -bi.
dx	Deliver in mode x. Legal modes are: i Deliver interactively (synchronously). b Deliver in background (asynchronously). q Queue the message (deliver during queue run)
ex	Dispose of errors using mode x. The values for x are: p Print error messages (default). q No messages, just give exit status. m Mail back errors to sender. w Write back errors (mail if user not logged in). e Mail back errors and always give zero exit status.
Fn	The temporary queue file mode, in octal. Values of 644 and 600 are good choices for n.
f	Save UNIX-style From lines at the front of headers. Normally they are assumed to be redundant and discarded.
gn	Set the default group ID for mailers to run in to n.
Hfile	Specify the help file for SMTP [Postel 82].
h n	Set maximum hop count to n.
i	Ignore dots in incoming messages.
Ln	Set the default log level to n.
Mxvalue	Set the macro x to value. This is intended only for use from the command line.
m	Send to the sender also, even if the sender is in an alias expansion.

Table C-13 sendmail(Continued) (3 of 4)

Option	Description
o	Assume that the headers may be in old format; that is, spaces delimit names. This flag actually turns on an adaptive algorithm: If any recipient name contains a comma, parenthesis, or angle bracket, it is assumed that commas already exist. If this flag is not on, only commas delimit names. Headers are always output with commas between the names.
Pname	Send the header from error messages from the MAILER-DAEMON to this name (which is the local Postmater).
Qdir	Use the named dir as the queue directory.
qlimit	This is the size limit of messages to be queued under heavy load. Default is 10,000 bytes.
Rserver	Remote mode. Deliver through remote SMTP server. The default is location of /var/mail.
rtime	Timeout reads after time interval.
Sfile	Save statistics in the named file.
s	Always initiate the queue file, even if you are going to try immediate delivery. sendmail always initiates the queue file before returning control to the client under any circumstance.
Ttime	Set the queue timeout to time. After this interval, messages that have not been successfully sent are returned to the sender.
un	Set the default user ID for mailers to n. Mailers without the S flag in the mailer definition are run as this user.
v	Run in verbose mode.
Xn	Set the load average value, so that the sendmail daemon refuses incoming SMTP connections when the system is overloaded to reduce system load. The default is 0, which disables this feature.
xn	Set the load average value so that sendmail simply queues mail (regardless of the dx option) to reduce system load. Default is 0, which disables this feature.
Yname	Use the named NIS map for aliases. The default is mail.aliases.

Table C-13 sendmail(Continued) (4 of 4)

Option	Description
yn	Penalize messages with at least this many bytes per recipient.
Zn	Penalize messages with at least this many bytes per delivery attempts.
zn	Penalize messages with this many bytes per class.

Mailer Flags

The flags you can set in the mailer description are described in Table C-14.

Table C-14 sendmail

Flag	Description
C	Append the @domain clause from the sender to any names in the header that do not have an at sign (@) after being rewritten by rule set 3. This flag allows mail with headers with this form: From: usera@local To: userb, userc@remote to be automatically rewritten as: From: usera@local To: userb@local, userc@remote
D	Look for a Date: header line.
E	Escape From lines to be >From (usually specified with U).
e	Avoid connecting to this mailer, which is expensive, normally; any necessary connection occurs during a queue run.
F	Look for a From: header line.
f	Look for an -f from flag, but only if this is a network forward operation (that is, the mailer gives an error if the executing user does not have special permissions).
h	Preserve uppercase in host names for this mailer.
L	Limit the line lengths as specified in RFC 821.
l	Perform final delivery because this mailer is local.
M	Look for a Message-Id: header line.
m	Enable the mailer to send a message to multiple users on the same host in one transaction. When a $u macro occurs in the argv part of the mailer definition, that field is repeated as necessary for all qualifying users. The L= field of the mailer description can be used to limit the total length of the $u expansion.
n	Do not insert a UNIX-style From line on the front of the message.
P	Look for a Return-Path: line.

Table C-14 sendmail(Continued)

Flag	Description
p	Always add local host name to the MAIL From: line of SMTP, even if there already is one.
r	Send a -r flag. Performs the same function as -f.
S	Do not reset the user ID before calling the mailer. This flag would be used in a secure environment where sendmail ran as root. This flag could be used to avoid forged names.
s	Strip quote characters off the name before calling the mailer.
U	Look for UNIX-style From lines with the UUCP-style remote from <host> on the end.
u	Preserve uppercase in user names for this mailer.
X	Use the hidden dot algorithm as specified in RFC 821; basically, any line beginning with a dot will have an extra dot appended (to be stripped at the other end). This flag ensures that lines in the message containing a dot do not terminate the message prematurely.
x	Look for a Full-Name: header line.