sendmail has several key features:
However, in many cases sendmail can be configured to exceed these protocols, as described in this chapter.
See also:
With sendmail configured and using one of the standard SCO MUAs, whether mail, scomail, scosh mail:
If additional MUAs are added to the system, they may
request mail routing from sendmail by
a new instance of sendmail directly without
going through execmail, or using SMTP
directly to the local host.
Incoming mail
sendmail processes and delivers incoming mail
the same way it processes and delivers
outgoing mail;
the only difference being the source
of the mail.
sendmail receives incoming mail from other hosts
via servers.
The standard sendmail configuration supports
two servers: SMTP and UUCP.
One instance of sendmail, generally invoked by the /etc/rc2.d/P86sendmail script at boot time, runs as the SMTP server by default. This server listens on the SMTP (Simple Mail Transfer Protocol) port for SMTP requests. When it receives a request, the sendmail daemon executes the fork system call to start a new instance of sendmail to process the request.
A standard SCO distribution includes a UUCP mail server called
rmail(ADMN).
This standard program routes incoming mail from UUCP
to sendmail by executing a new instance
of sendmail.
sendmail execution
Each time sendmail starts up, it reads a configuration file
that specifies the operations of that instance of sendmail.
A sendmail configuration file includes:
The user database allows sendmail to rewrite sender and recipient addresses under control of an external database file. It is used to locate the default maildrop at a site, but allow you to override this by sending to a specific host. If the user database is enabled, a local address is looked up in that database after aliasing and before forwarding. For more information on the user database see ``Creating a user information database''.
sendmail options control operations such as whether sendmail delivers mail immediately after processing or queues the mail for delivery when the queue is next processed. Options set in the configuration file can also be overridden by passing options to sendmail as arguments.
Flags determine things such as the interval at which sendmail processes the mail queue and whether to use an alternate configuration file for this instance of sendmail.
These options and flags alter sendmail's processes of address parsing, message collection, and storage. Part of the address parsing process is the rewriting of addresses. Some additional rewriting may also take place during sendmail's delivery phase.
For a complete list of options see ``O--set option''. Command-line flags, different from the options and passed to sendmail as arguments, also influence processing. See the sendmail(ADMN) manual page for a description of these flags.
sendmail looks in two places for its configuration file and uses the highest priority file available. The highest priority is a filename passed as a flag argument to the sendmail daemon. If a filename is passed to sendmail using the -C flag, sendmail reads this file for configuration information and ignores all others.
If the -C flag is not specified on the command line, sendmail reads /usr/lib/sendmail.cf. This is the standard configuration file created by default when initializing sendmail.
sendmail hands off mail by executing a mailer with arguments as defined in the mailer definition in the configuration file.
The mailers in the standard sendmail configuration are:
Recipient addresses are passed to sendmail as arguments or via the SMTP RCPT command depending on the interface to sendmail. Each address is parsed in order to build a recipient list for the message being processed. Parsing involves resolving each address to an internally used form that identifies the mailer to be used. If the mailer identified for any address is the ``local'' mailer, the following additional processing occurs:
When new recipient addresses are appended to the recipient list through special ``local'' mailer address processing, the old name is retained in the list and a flag is set that tells the delivery phase to ignore the old name. In this way the recipient 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.
At this stage, before the message is collected, the address syntax
has been checked and local addresses verified; detailed checking
of host names and host addresses, however, is deferred until
message delivery.
Before sendmail can deliver a message, it must interpret the address. sendmail expects addresses to conform, or be convertible, to a format defined in RFC 822. sendmail passes each recipient address through a set of filters called ``rewriting rules'' to determine whether it understands the address and can deliver to that address via one of its known mailers.
The mailaddr(ADMN) manual page and the following text provide brief overviews of the RFC 822 format.
Parentheses, angle brackets, and double quotes must be properly balanced and nested. The rewriting rules control remaining parsing.
sendmail applies the following special processing to mail intended for the ``local'' mailer:
Aliasing and user information database lookups apply across the entire system. Forwarding allows all users to redirect incoming mail destined for their accounts. Inclusion directs sendmail to read a file for a list of addresses. Inclusion is normally used in conjunction with aliasing.Aliasing expands recipient names into address lists using a system-wide text file that associates a recipient name with a list of addresses. Only names that parse as local are allowed as aliases. This guarantees a unique key. The identity of the alias text file is configured through the sendmail configuration file and is configured to be /usr/lib/mail/aliases by the standard configuration. sendmail indexes this file to speed access. For more information on the alias files see the following:
After aliasing and a user information database lookup, local and valid recipients are checked for the existence of a .forward file in their home directory. If one exists, the message is not sent to that user, but rather to the list of users in that file. Often, this list contains a single address and is used only for network mail forwarding. For example, suppose user dbaker has a .forward file in $HOME with contents:
dbaker@scribe.npr.comThen any mail arriving for dbaker would be directed to dbaker's account on scribe.npr.com.
Forwarding also permits a user to specify a private incoming mailer. For example, this forwarding line defines a different incoming mailer:
"|/usr/local/newmail myname"
The syntax for including a file is:
:include: pathnameWhen sendmail sees an address in this form, it reads the file specified by pathname and sends to all users listed in that file.
The intention is not to support direct use of this feature, but rather to use this as a subset of aliasing. In the following example, use of the ``include'' address format allows a project with the mail alias projectC to maintain a project mailing list without interaction with the system administration, even if the alias file is protected.
projectC: :include:/usr/project/userlistIt is not necessary to rebuild the index on the alias database when a list of this type is changed. All that is needed is to edit the include file to reflect the changes. In this example, the include file is /usr/project/userlist.
Once all recipient addresses are parsed and verified, sendmail collects the message. To simplify the program interface, the message is collected even if no addresses are valid; in this case the message is then returned to the sender with an error.
The message format must conform to RFC 822, which means it must consist of two parts: a message header and a message body, separated by a blank line. Further, RFC 822 requires that the header be in a format shown below. The header is parsed and stored in memory, and the body of the message is saved in a temporary file.
To conform to RFC 822, the header must be a series of lines of the form:
field-name: field-valueA field-value can be split across lines by starting the lines that follow with a space or a tab. Some header fields have special internal meaning, in which case sendmail may perform special processing on them. Other headers are simply passed through. Some header fields, such as time stamps, may be added automatically 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. Additional editing of a header may take place during the delivery phase to customize the header to meet mailer requirements.
No RFC 822 formatting requirements are imposed on the message body, except that they must be lines of text; binary data is not allowed. It is completely uninterpreted and untouched by sendmail, 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. (SMTP uses lines beginning with a dot to signal the end of the message.) The message body is stored in a separate file from the header information.
sendmail can be configured to deliver a message at the time it receives the message (immediate delivery) or to queue the message for delivery when the mail queue is processed. Immediate delivery can be configured to happen synchronously or asynchronously (in the background). This section on message delivery applies to all of the above.
The result of the recipient address parsing is a triple consisting of ``mailer, host, user'' for each recipient. The mailer is one of the defined mailers in the configuration file; host is the destination host; and user is the recipient on that host.
For each unique ``mailer,host'' pairing in the recipient list, sendmail calls the appropriate mailer. sendmail will try to batch deliver the message to all recipients on the same host in one invocation of the receiving mailer. Mailers that only accept one recipient at a time are handled accordingly. After a connection with the mailer is established, sendmail customizes the message header as necessary for correct interpretation by the recipient mailer and sends the result to the mailer.
The receiving mailer status code is caught and checked.
If any mail is rejected by the mailer,
a flag is set to invoke the return-to-sender function
after all delivery completes.
An exit code from the receiving mailer must conform to a
system standard; otherwise, sendmail forwards a
generic message such as Service unavailable to the
originator of the mail.
If the mailer returns a status code indicating that the message should be sent later, sendmail puts the mail on the queue and tries again later.
If errors occur during processing, sendmail returns the message to the sender for retransmission. If the user agent (mail) detects the error, then it is put in the dead.letter file located in the sender's home directory. If a sendmail server is connecting with a sendmail client on another machine, then the user is presumed to have become detached from the transaction, and so the message is mailed back to them.
If the mailer returns a temporary failure
exit status, the message is queued.
A control file for the message describes the recipients to be sent to
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 significant 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 message file that was originally collected.
See
``Viewing the mail queue''
for more information on the mail queue.
sendmail interfaces
There are three ways
sendmail
communicates,
both in receiving and in sending mail.
These are:
For simplicity, the following descriptions of these three methods assume sendmail is sending to a mailer.
Any address passing through the initial parsing algorithm as a local address (not appearing to be a valid address for another mailer) is scanned for two special cases. If prefixed by a vertical bar (``|'') the rest of the address is processed as a shell command. If the user name begins with a slash mark (``/'') the name is used as a file name, instead of a login name.
Files that have setuid or setgid bits set
but no execute bits set
have those bits honored if
sendmail
is running as root.
Standard sendmail configuration
Execute the command mkdev cf
to perform sendmail configuration.
The major tasks of mkdev cf are to:
The default configuration created here supports both UUCP and
Internet style addressing.
The user entered information allows a network administrator to designate a
machine on
the network as
the UUCP gateway machine, which will process
all UUCP requests for the net or subnet.
If an X.400 gateway is specified by the user information,
sendmail also will forward mail that
is addressed in X.400 style to that gateway.
The user information also provides for telling sendmail
to use NIS maps to define mail aliases.
Running mkdev cf
When ready to configure sendmail, enter:
mkdev cf.
A menu with nine items appears. sendmail remembers the user inputs entered the last time mkdev cf was run and displays those entries as the current state/value. The following describes the menu items, including which are mandatory and which are optional.
Do you wish to change anything? [y/n]
If you enter y (yes), it returns you to the main menu. If you enter n (no), it generates the file /usr/lib/sendmail.cf from one through six menu items and from a default configuration source file. If /usr/lib/sendmail.cf already exists, this script saves the old sendmail.cf file as /usr/lib/sendmail.cf-. When finished, it displays that the new file has been installed, it kills the sendmail daemon if one is running, and starts a new daemon. It then returns you to the main menu.
Test sendmail by creating and sending mail messages with mail(C). There are three sources for information about sendmail processing:
Most of these options have defaults appropriate for most sites. However, sites having very high mail loads may find they need to tune them as appropriate for that load. In particular, sites experiencing a large number of small messages, many of which are delivered to many recipients, may find that they need to adjust the parameters dealing with queue priorities.
When making any configuration file changes, see ``Reconfiguring sendmail''.
All options that specify time intervals use a set of predefined units:
eric:maildropThis text file is normally installed in a system directory; for example, it might be called /etc/userdb. To make the database version of the map, enter:
Then reference the database file in the sendmail
configuration file.
For example, include the
following line in the configuration file:
OU/etc/userdb
sendmail adds the .db suffix when doing the database search.
The location of this database is controlled with the UserDatabaseSpec option.
The database is a sorted (BTree-based) structure.
User records are stored with the key:
user-name:field-name
The sorted database format ensures that user records are clustered together. Meta-information is always stored with a leading colon.
Field names define both the syntax and semantics of the value. Currently, the defined fields include:
If you have specified one or more databases using the U option, the databases will be searched for a ``user:maildrop'' entry. If found, the mail will be sent to the specified address.
If the first token passed to the user part of the ``local'' mailer is an at sign, the at sign will be stripped off and the database lookup will be skipped. The intent is that the user database will act as a set of defaults for a cluster (for example, the computer science department of a university); mail sent to a specific machine should ignore these defaults.
When mail is sent, the name of the sender is looked up in the database. If that sender has a mailname record, the value of that record is used as their outgoing name. For example, eric might have a record:
eric:mailname Eric.Allman@CS.Berkeley.EDUThis would cause eric's outgoing mail to be sent as Eric.Allman.
If a ``maildrop'' is found for the sender,
but no corresponding ``mailname'' record exists,
the record ``:default:mailname'' is consulted.
If present, this is the name of a host to override the local host
(for example, CS.Berkeley.EDU).
The effect is that anyone known in the database
gets their outgoing mail stamped as
user@CS.Berkeley.EDU,
but people not listed in the database use the local hostname.
``Creating a user information database''.
Altering read timeouts
It is possible to time out when reading the standard input
or when reading from a remote SMTP server.
These timeouts are set using the Timeout (r)
option in the configuration file.
The option names are all of the form Timeout.suboption.
The recognized suboptions, their default values, and the
minimum values allowed by RFC 1123 section 5.3.2 are:
For compatibility with old configuration files, if no ``suboption'' is specified, all the timeouts marked with + are set to the indicated value.
Many of the RFC 1123 minimum values may well be too short. sendmail was designed to the RFC 822 protocols, which did not specify read timeouts; hence, versions of sendmail prior to 8.1 does not guarantee to reply to messages promptly. In particular, a RCPT command specifying a mailing list will expand and verify the entire list; a large list on a slow system may take more than five minutes. (This verification includes looking up every address with the name server; this involves network delays and can be considerable in some cases.) A one hour timeout is recommended. Because this failure is rare, a long timeout is not onerous and may ultimately help reduce network load.
For example, the following line sets the server SMTP command timeout to 25 minutes and the input data block timeout to three hours:
O Timeout.command=25m O Timeout.datablock=3hOr, using the older short name syntax this option could alternatively be set by the following line:
Orcommand=25m,datablock=3h
If the message is submitted using the NOTIFY SMTP extension, warning messages will only be sent if NOTIFY=DELAY is specified. The queuereturn and queuewarn timeouts can be further qualified with a tag based on the Precedence: field in the message; they must be one of "urgent" (indicating a positive non-zero precedence) "normal" (indicating a zero precedence), or "non-urgent" (indicating negative precedences). For example, setting "Timeout.queuewarn.urgent=1h" sets the warning timeout for urgent messages only to one hour. The default if no precedence is indicated is to set the timeout for all precedences. The value "now" can be used for -O Timeout.queuereturn to return entries immediately during a queue run, (for example, to bounce messages independent of their time in the queue.
Since these options are global, and since you cannot know how long another host outside your domain will be down, a five day timeout is recommended. This allows a recipient to fix the problem even if it occurs at the beginning of a long weekend. RFC 1123 section 5.3.1.1 says that this parameter should be ``at least 4-5 days''.
The Timeout.queuewarn value can be piggybacked on the T option by indicating a time after which a warning message should be sent; the two timeouts are separated by a slash. For example, the line:
OT5d/4hcauses email to fail after five days, but a warning message will be sent after four hours. This should be large enough that the message will have been tried several times.
If the ForkEachJob option is set, sendmail can not
use connection caching.
Altering queue priorities
Every message is assigned a priority when it is first instantiated,
consisting of the message size (in bytes)
offset by the message class
(determined from the Precedence: header)
multiplied by the ``work class factor''
and the number of recipients multiplied by the
``work recipient factor.''
The priority is used to order the queue.
Higher numbers for the priority mean that the message is processed later,
when running the queue.
The message size is included so that large messages are penalized relative to small messages. The message class allows users to send high-priority messages by including a ``Precedence:'' field in their message; the value of this field is looked up in the P lines of the configuration file. Because the number of recipients affects the size of load a message presents to the system, this is also included in the priority.
The recipient and class factors can be set in the configuration file by using the RecipientFactor (y) and ClassFactor (z) options, respectively. They default to 30,000 (for the recipient factor) and 1800 (for the class factor). The initial priority is:
pri = msgsize - (class * ClassFactor) + (nrcpt * RecipientFactor)(Remember, higher values for this parameter actually mean that the job is treated with lower priority.)
The priority of a job can also be adjusted each time it is processed
(that is, each time an attempt is made to deliver it)
using the ``work time factor,''
set by the RetryFactor (Z) option.
This is added to the priority,
so it normally decreases the precedence of the job,
on the grounds that jobs that have failed many times
tend to fail again in the future.
The RetryFactor option defaults to 90,000.
Setting the mail load limit
sendmail
can be asked to queue (but not deliver)
mail if the system load average gets too high
using the QueueLA (x) option.
When the load average exceeds the value of the
QueueLA option, the delivery mode is set to
q (queue only) if the QueueFactor
(q option)
divided by the difference in the current load average and the
QueueLA option plus one
exceeds the priority of the message--that is,
the message is queued if:
pri > QueueFactor divided by (LA-QueueLA+1)
The QueueFactor option defaults to 600,000, so each point of load average is worth 600,000 priority points (as described above).
For drastic cases, the RefuseLA (X)
option defines a load average at which sendmail
will refuse to accept network connections.
Locally generated mail (including incoming UUCP mail)
is still accepted.
Setting the delivery mode
There are a number of delivery modes for
sendmail set by the
DeliveryMode (d) configuration option.
These modes
specify how quickly mail is delivered.
Legal modes are:
If you run in mode ``q,'' ``d,'' or ``b,'' sendmail will not expand aliases and follow .forward files upon initial receipt of the mail. This speeds up the response to RCPT commands.
Mode ``i'' cannot be used by the SMTP server.
Log Levels
The level of logging can be set for sendmail.
The default using a standard configuration table is level 9.
The levels are as follows:
Sendmail is normally installed setuid to root. At the point where it is about to exec(S) a mailer, it checks to see if the userid is zero (root); if so, it resets the userid and groupid to a default (set by the U= equate in the mailer line; if that is not set, the DefaultUser option is used). This can be overridden by setting the S flag to the mailer for mailers that are trusted and must be called as root. However, this will cause mail processing to be accounted to root rather than to the user sending the mail.
If you don't make sendmail setuid to root, it will still run but you lose a lot of functionality and a lot of privacy, since you'll have to make the queue directory world readable. You could also make sendmail setuid to some pseudo-user (for example, create a user called sendmail and make sendmail setuid to that) which will fix the privacy problems but not the functionality issues. It also introduces problems on some operating systems if sendmail needs to give up the setuid special privileges. Also, this isn't a guarantee of security: for example, root occasionally sends mail, and the daemon often runs as root. Note however that sendmail must run as root or the trusted user in order to create the SMTP listener socket.
A middle ground is to make sendmail setuid to root,
but set the RunAsUser option. This causes
sendmail
to become the indicated user as soon as it has done the startup
that requires root privileges (primarily, opening the SMTP socket).
If you use RunAsUser, the queue directory
(normally /var/spool/mqueue)
should be owned by that user, and all files and databases
(including user .forward files, alias files,
:include: files, and external databases)
must be readable by that user.
Also, since sendmail will not be able to change it's uid,
delivery to programs or files will be marked as unsafe,
that is, undeliverable, in .forward, aliases,
and :include: files. Administrators can override this by setting the
DontBlameSendmail option to the setting
NonRootSafeAddr. RunAsUser
is probably best suited for firewall configurations
that don't have regular user logins.
Turning off security checks
sendmail
is very particular about the modes of files that it reads or writes.
For example, by default it will refuse to read most files
that are group writable
on the grounds that they might have been tampered with
by someone other than the owner;
it will even refuse to read files in group writable directories.
If you are certain that your configuration is safe and you want sendmail to avoid these security checks, you can turn off certain checks using the DontBlameSendmail option. This option takes one or more names that disable checks. In the descriptions that follow, unsafe directory means a directory that is writable by anyone other than the owner. The values are:
When trying to open a connection, the cache is first searched. If an open connection is found, it is probed to see if it is still active by sending a RSET command. It is not an error if this fails; instead, the connection is closed and reopened.
Two parameters control the connection cache. The ConnectionCacheSize (k) option defines the number of simultaneous open connections that will be permitted. If it is set to zero, connections will be closed as quickly as possible. The default is one. This should be set as appropriate for your system size; it will limit the amount of system resources that sendmail will use during queue runs. Never set this higher than 4.
The ConnectionCacheTimeout (K)
option specifies the maximum time that any cached connection
will be permitted to idle.
When the idle time exceeds this value
the connection is closed.
This number should be small
(under ten minutes)
to prevent you from grabbing too many resources
from other hosts.
The default is five minutes.
Using sendmail with a name server
If your system is configured to use the Domain Name Service,
then sendmail will use it by default.
Control of host address lookups can also be set using a ``service switch''. sendmail can be configured to use the service switch by setting the hosts service entry in the /etc/mail/service.switch file. sendmail uses only two entries, hosts and aliases, although system routines may use other services, notably the passwd service for user name lookups by getpwname.
However, if you do not have a name server configured at all, such as at a UUCP-only site, sendmail will get a ``connection refused'' message when it tries to connect to the name server (either indirectly by calling gethostbyname or directly by looking up MX records). If the I option is set, sendmail will interpret this to mean a temporary failure and will queue the mail for later processing; otherwise, it ignores the name server data. If your name server is running properly, the setting of this option is not relevant; however, it is important that it be set properly to make error handling work properly.
This option also allows you to modify name server options. The command line takes a series of flags as documented in resolver(SLIB) (with the leading ``RES_'' deleted). Each can be preceded by an optional ``+'' or ``-''. For example, the following line turns on the AAONLY (accept authoritative answers only) and turns off the DNSRCH (search the domain path) options.
OITrue +AAONLY -DNSRCHMost resolver libraries default to DNSRCH, DEFNAMES, and RECURSE flags on and all others off. Note the use of the initial ``True'' - this is for compatibility with previous versions of sendmail, but is not otherwise necessary.
Version level 1 configurations turn DNSRCH and DEFNAMES off when doing delivery lookups, but leave them on everywhere else. Version 8 of sendmail ignores them when doing canonification lookups (that is, when using $[ ... $]), and always does the search. If you do not want to do automatic name extension, do not call $[ ... $].
The search rules for $[ ... $] are somewhat different than usual.
If the name (that is, the ``...'')
has at least one dot, it always tries the unmodified name first.
If that fails, it tries the reduced search path,
and lastly tries the unmodified name
(but only for names without a dot,
because names with a dot have already been tried).
This allows names such as
``utc.CS''
to match the site in Czechoslovakia
rather than the site in your local computer science department.
It also prefers A and CNAME records over MX records -
that is, if it finds an MX record it makes note of it,
but keeps looking.
This way, if you have a wildcard MX record matching your domain,
it will not assume that all names match.
Moving the per-user forward files
Some sites mount each user's home directory
from a local disk on their workstation,
so that local access is fast.
However, the result is that .forward
file lookups are slow.
In some cases,
mail can even be delivered on machines inappropriately
because of a file server being down.
The performance can be especially bad if you run the automount facility.
The ForwardPath (J) option allows you to set a path of forward files. For example, the following configuration file line would first look for a file with the same name as the user's login in /usr/forward; if that is not found (or is inaccessible) the file .forward in the user's home directory is searched.
O ForwardPath=/usr/forward/$u:$z/.forwardA truly perverse site could also search by sender by using $r, $s, or $f.
If you create a directory such as
/usr/forward,
it should be mode 1777
(that is, the sticky bit should be set).
Users should create the files mode 644.
Note that you must use the forwardfileinunsafedirpath and
forwardfileinunsafedirpathsafe flags with the DontBlameSendmail option
to allow forward files in a world writable directory.
This might also be used as a denial of service
attack (users could create forward files for other users);
a better approach might be to create
/var/forward mode 755 and create empty files for each user,
owned by that user, mode 644.
If you do this, you don't have to set the DontBlameSendmail options
indicated above.
Setting mail queue filesystem free space
You can specify a minimum number of free blocks on the queue filesystem
using the MinFreeBlocks (b) option.
If there are fewer than the indicated number of blocks free
on the filesystem on which the queue is mounted,
the SMTP server will reject mail
with the
452 error code.
This invites the SMTP client to try again later.
Beware of setting this option too high;
it can cause rejection of email
when that mail would be processed without difficulty.
Setting maximum message size
To avoid overflowing your system with a large message,
the MaxMessageSize
option can be set to set an absolute limit
on the size of any one message.
This will be advertised in the ESMTP dialogue
and checked during message collection.
Setting privacy flags
The PrivacyOptions (p) option allows you to
set certain ``privacy'' flags.
Many of them do not give you any extra privacy,
rather just insisting that client SMTP servers
use the HELO command before using certain commands
or adding extra headers to indicate possible spoof attacks.
The option takes a series of flag names; the final privacy is the inclusive ``or'' of those flags. For example:
O PrivacyOptions=needmailhelo, noexpnThis insists that the HELO or EHLO command be used before a MAIL command is accepted and disables the EXPN command.
For more information, see
``O--set option''.
Setting ``send to me too'' operation
Beginning with version 8.10, sendmail
includes by default the (envelope) sender in any list expansions.
For example, if ``mary'' sends to a list that contains ``mary''
as one of the members, she will get a copy of the message.
If the MeToo option is set to FALSE
(in the configuration file or via the command line),
this behavior is changed (that is,
the sender is excluded in list expansions).
Reconfiguring sendmail
You can change the sendmail configuration at any time.
How you change the configuration depends on what you want to change.
When sendmail is installed,
a standard configuration file is created
by combining user prompted input
with non-prompted configuration information.
sendmail obtains the non-prompted configuration information
from a default configuration source file,
/usr/lib/sendmail.d/sendmail.src.
If you want to change any of the information for which mkdev cf prompts, the easiest approach is to rerun mkdev cf and respond to the prompts. sendmail remembers the previous responses to these prompts, so you need only make changes. For a description of the information for which mkdev cf prompts, see ``Running mkdev cf''.
If you want to change information for which mkdev cf does not prompt:
Administering sendmail
System administration with sendmail consists of:
sets the T (timeout) option to two minutes
for this run only;
the equivalent line using the long option name is:
sendmail -OTimeout.queuereturn=2m
Some options have security implications.
Sendmail allows you to set these,
but relinquishes its setuid root permissions thereafter.
Trying a Different Configuration File
An alternative configuration file
can be specified using the
-C flag; for example,
sendmail -Ctest.cf -oQ/tmp/mqueue
uses the configuration file test.cf instead of the default /usr/lib/sendmail.cf. If the -C flag has no value it defaults to sendmail.cf in the current directory.
sendmail gives up its setuid root permissions
when you use this flag, so it is common to use a publicly writable directory
(such as /tmp)
as the spool directory (QueueDirectory or Q option) while testing.
Logging traffic
Many SMTP implementations do not fully implement the protocol.
For example, some personal computer based SMTPs
do not understand continuation lines in reply codes.
These can be very hard to trace.
If you suspect such a problem, you can set traffic logging using the
-X
flag.
For example, the following
will log all traffic in the file
/tmp/traffic.
/usr/lib/sendmail -X /tmp/traffic -bd
This logs a lot of data very quickly and should never be used
during normal operations.
After starting up such a daemon,
force the errant implementation to send a message to your host.
All message traffic in and out of
sendmail,
including the incoming SMTP traffic,
will be logged in this file.
Testing configuration files
When you build a configuration table,
you can do a certain amount of testing
using the test mode of
sendmail. For example:
sendmail -bt -Ctest.cf
would read the configuration file
test.cf and enter test mode.
In this mode, you enter lines of the form:
rwset address
where rwset is the rewriting set you want to use and address is an address to apply the set to. Test mode shows you the steps it takes as it proceeds, finally showing you the address it ends up with. You may use a comma separated list of rwsets for sequential application of rules to an input. For example:
3,1,21,4 monet:bollardfirst applies ruleset three to the input monet:bollard. Ruleset one is then applied to the output of ruleset three, followed similarly by rulesets twenty-one and four.
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 an incredible amount of information; a single word address is probably going to print out several pages worth of information.
0 bruce@broadcast.sony.comThis version requires that you use:
3,0 bruce@broadcast.sony.com
As of version 8.7, additional syntaxes are available in test mode:
This information may be flushed with the command:
sendmail -bH
Flushing the information prevents new
sendmail processes from loading it,
but does not prevent existing processes from using the status information
that they already have.
Viewing the system log
The system log appears in the file logged to by the
syslogd(ADM)
utility.
All messages from
sendmail
are logged under the
LOG_MAIL
facility.
Each line in the system log consists of a timestamp,
the name of the machine that generated it (for logging from several
machines over the network), the word ``sendmail,'' and a message.
Log entry format
Each line in the system log
consists of a timestamp,
the name of the machine that generated it
(for logging from several machines
over the local area network),
the word "sendmail:", and a message.
The two most common lines are logged when a message is processed. The first logs the receipt of a message; there will be exactly one of these per message. Some fields may be omitted if they do not contain interesting information. Fields are:
The log level is set with the L configuration option. See
``Log Levels''
for a complete description of log levels.
Dumping state
You can ask
sendmail
to log a dump of the open files
and the connection cache
by sending it a
SIGUSR1
signal.
The results are logged at
LOG_DEBUG
priority.
Viewing the mail queue
The mail queue should be processed transparently.
However, you may find that manual intervention is sometimes necessary.
For example,
if a major host is down for a period of time
the queue may become clogged.
Although
sendmail
ought to recover gracefully when the host comes up,
you may find performance unacceptably bad in the meantime.
The contents of the queue can be printed
using the
mailq
command
(or by specifying the
-bp
flag to
sendmail):
mailq
This produces a listing of the queue identifiers, the size of the message, the date the message entered the queue, and the sender and recipients.
sendmail queue files live in the directory defined by the Q option in the /usr/lib/sendmail.cf file, usually /usr/spool/mqueue. The individual qf, df, and xf files may be stored in separate if they are present in the queue directory.
To use multiple queues, supply a value ending with an asterisk. For example, /var/spool/mqueue/q* will use all of the directories or symbolic links to directories beginning with `q' in /var/spool/mqueue as queue directories. New messages will be randomly placed into one of the queues. Do not change the queue directory structure while sendmail is running.
All queue files have the name xfYMDhmsNPPPPP where YMDhmsNPPPPP is the id for this message and the x is a type. The individual letters in the id are:
The types are:
The qf file is structured as a series of lines, each beginning with a code letter. The lines are as follows:
As an example, the following is a queue file sent to ``eric@mammoth.Berkeley.EDU'' and ``bostic@okeeffe.CS.Berkeley.EDU''. (This example is contrived and probably inaccurate for your environment. Glance over it to get an idea; nothing can replace looking at what your own system generates.)
P835771 T404261372 DdfAAA13557 Seric Eowner-sendmail@vango.CS.Berkeley.EDU Ceric:sendmail@vango.CS.Berkeley.EDU Reric@mammoth.Berkeley.EDU Rbostic@okeeffe.CS.Berkeley.EDU H?P?return-path: <owner-sendmail@vango.CS.Berkeley.EDU> Hreceived: by vango.CS.Berkeley.EDU (5.108/2.7) id AAA06703; Fri, 17 Jul 92 00:28:55 -0700 Hreceived: from mail.CS.Berkeley.EDU by vango.CS.Berkeley.EDU (5.108/2.7) id AAA06698; Fri, 17 Jul 92 00:28:54 -0700 Hreceived: from [128.32.31.21] by mail.CS.Berkeley.EDU (5.96/2.5) id AA22777; Fri, 17 Jul 92 03:29:14 -0400 Hreceived: by foo.bar.baz.de (5.57/Ultrix3.0-C) id AA22757; Fri, 17 Jul 92 09:31:25 GMT H?F?from: eric@foo.bar.baz.de (Eric Allman) H?x?full-name: Eric Allman Hmessage-id: <9207170931.AA22757@foo.bar.baz.de> HTo: sendmail@vango.CS.Berkeley.EDU Hsubject: this is an example messageThis shows the name of the data file, the person who sent the message, the submission time (in seconds since January 1, 1970), the message priority, the message class, the recipients, and the headers for the message.
The amount of time between forking a process to run through the queue is defined by the -q flag. If you run sendmail in delivery mode i or b, this can be relatively large, because it is only relevant when a host that was down comes back up. If you run sendmail in delivery mode q, it should be relatively short, because it defines the amount of time that a message may sit in the queue before sendmail tries to deliver it. The delivery mode is a configuration option. (See also the MinQueueAge option.)
RFC 1123 section 5.3.1.1 says that this value should be at least 30 minutes (although that probably does not make sense if you use ``queue-only'' mode).
The sendmail program should run the queue automatically at intervals. The algorithm is to read and sort the queue, then to attempt to process all jobs in order. When using multiple queues, a separate process will be created to run each of the queues unless the queue run is initiated by a user with the verbose flag. When it attempts to run the job, sendmail first checks to see if the job is locked. If so, it ignores the job.
There is no attempt to ensure that only one queue processor exists at any time, because there is no guarantee that a job cannot take forever to process (however, sendmail does include heuristics to try to abort jobs that are taking absurd amounts of time; technically, this violates RFC 821, but is blessed by RFC 1123). Due to the locking algorithm, it is impossible for one job to freeze the queue. However, an uncooperative recipient host or a program recipient that never returns can accumulate many processes in your system. Unfortunately, there is no completely general way to resolve this.
In some cases, you may find that if a major host goes down for a couple of days, this can create a prohibitively large queue. This situation causes sendmail to spend an inordinate amount of time sorting the queue. This situation can be fixed by moving the queue to a temporary place and creating a new queue. The old queue can be run later, when the offending host returns to service.
To do this,
it is acceptable to move the entire queue directory:
cd /usr/spool
mv mqueue omqueue; mkdir mqueue; chmod 700 mqueue
You should then kill the existing daemon (because it is still processing in the old queue directory) and create a new daemon. To kill the existing daemon and create a new daemon, reboot the system.
To run the old mail queue,
run the following command:
/usr/lib/sendmail -oQ/usr/spool/omqueue -q
The -oQ flag specifies an alternate queue directory, and the -q flag says just to run every job in the queue. Use the -v flag to view what is going on.
When the queue is finally emptied,
you can remove the directory:
rmdir /usr/spool/omqueue
You can also limit the jobs to those with a particular queue identifier,
sender, or recipient
using one of the queue modifiers.
For example, ``-qRberkeley''
restricts the queue run to jobs that have the string
``berkeley''
somewhere in one of the recipient addresses.
Similarly,
-qSsender
limits the run to a particular sender and
-qIidentifier
limits it to a particular queue identifier.
Disk-based connection information
sendmail
stores a large amount of information about each remote system it
has connected to in memory. It is now possible to preserve some
of this information on disk as well, by using the
HostStatusDirectory
option, so that it may be shared between several invocations of
sendmail.
This allows mail to be queued immediately or skipped during a queue run if
there has been a recent failure in connecting to a remote machine.
Additionally enabling SingleThreadDelivery has the added effect of single-threading mail delivery to a destination. This can be quite helpful if the remote machine is running an SMTP server that is easily overloaded or cannot accept more than a single connection at a time, but can cause some messages to be punted to a future queue run. It also applies to all hosts, so setting this because you have one machine on site that runs some software that is easily overrun can cause mail to other hosts to be slowed down. If this option is set, you probably want to set the MinQueueAge option as well and run the queue fairly frequently; this way jobs that are skipped because another sendmail is talking to the same host will be tried again quickly rather than being delayed for a long time.
The disk based host information is stored in a subdirectory of the mqueue directory called .hoststat (controlled by the HostStatusDirectory option). Removing this directory and its subdirectories has an effect similar to the purgestat command and is completely safe. The information in these directories can be perused with the hoststat command, which will indicate the host name, the last access, and the status of that access. An asterisk in the left most column indicates that a sendmail process currently has the host locked for mail delivery.
The disk based connection information is treated the same way as memory based connection information for the purpose of timeouts. By default, information about host failures is valid for 30 minutes. This can be adjusted with the Timeout.hoststatus option.
The connection information stored on disk may be purged at any time
with the purgestat command or by invoking sendmail with the
-bH switch. The connection information may be viewed with the
hoststat command or by invoking sendmail with the -bh
switch.
The service switch
The implementation of certain system services
such as host and user name lookup is controlled by the service switch.
The ServiceSwitchFile option points to the name of a file
that has the service definitions. Each line has the name of a service
and the possible implementations of that service. For example, the file:
hosts dns files nis aliases files nistells sendmail to look for hosts in the Domain Name System first. If the requested host name is not found, it tries local files, and if that fails it tries NIS. Similarly, when looking for aliases it will try the local files first, followed by NIS.
name: name1, name2, ...
Only local names can be aliased.
For example:
eric@prep.ai.MIT.EDU: eric@CS.Berkeley.EDU
This does not have the desired effect. Aliases can be continued by starting any continuation line with a space or a tab, or by putting a backslash directly before the newline. Blank lines and lines beginning with a number sign (``#'') are comments.
The second form is processed by the ndbm(NS) or the Berkeley db library. This form is in the files /usr/lib/mail/aliases.db (if using Berkeley db) or /usr/lib/mail/aliases.dir and /usr/lib/mail/aliases.pag (if using ndbm). This is the form that sendmail actually uses to resolve aliases. This technique improves performance.
The control of search order is actually set by the service switch. Essentially, the entry
O AliasFile=switch:aliasesis always added as the first alias entry; also, the first alias file name without a class (for example, without ``nis:'' on the front) will be used as the name of the file for a ``files'' entry in the aliases switch. For example, if the configuration file contains
O AliasFile=/usr/lib/mail/aliasesand the service switch contains
aliases nis files nisplusthen aliases will first be searched in the NIS database, then in /usr/lib/mail/aliases, then in the NIS+ database.
You can also use NIS-based alias files. For example, the following specification will first search the /usr/lib/mail/aliases file and then the map named mail.aliases in my.nis.domain.
O AliasFile=/usr/lib/mail/aliases O AliasFile=nis:mail.aliases@my.nis.domain
Additional flags can be added after the colon exactly like a K line. For example:
OAnis:-N mail.aliases@my.nis.domainThis will search the appropriate NIS map and always include null bytes in the key.
The hash or dbm version of the database
can be rebuilt explicitly by executing the command:
/usr/bin/newaliases
This is equivalent to giving sendmail the -bi flag:
/usr/lib/sendmail -bi
If the RebuildAliases (old D) option is specified in the configuration, sendmail rebuilds the alias database automatically, if possible, when it is out of date. Auto-rebuild can be dangerous on heavily loaded machines with large alias files; if it might take more than the rebuild timeout (option AliasWait (old a) which is normally five minutes) to rebuild the database, there is a chance that several processes start the rebuild process simultaneously.
If you have multiple aliases databases specified, the -bi flag rebuilds all the database types it understands (for example, it can rebuild db databases but not NIS databases).
There are a number of problems that can occur with the alias database. They all result when a sendmail process accesses the DBM version while it is only partially built. This can happen under two circumstances: either one process accesses the database while another process is rebuilding it, or the process rebuilding the database dies (due to being killed or a system crash) before completing the rebuild.
The sendmail program includes three techniques to try to relieve these problems. First, it ignores interrupts while rebuilding the database; this avoids the problem of someone aborting the process and leaving a partially rebuilt database. Second, it locks the database source file during the rebuild, but this may not work over NFS or if the file is unwritable. Third, at the end of the rebuild it adds an alias of the form:
@: @(Note that this is not normally legal.) Before sendmail accesses the database, it checks to ensure that this entry exists. (The AliasWait option is required in the configuration for this action to occur. This should normally be specified.)
If an error occurs on sending to a certain address, say ``x,'' sendmail looks for an alias of the form ``owner-x'' to receive the errors. This is typically useful for a mailing list where the submitter of the list has no control over the maintenance of the list itself; in this case the list maintainer would be the owner of the list. For example:
mail-wizards: eric@ucbarpa, wnj@monet, nosuchuser, sam@matisse owner-mail-wizards: eric@ucbarpaThis would cause eric@ucbarpa to get the error that occurs when someone sends to mail-wizards, due to the inclusion of nosuchuser on the list.
List owners also cause the envelope sender address to be modified. The contents of the owner alias are used if they point to a single user, otherwise the name of the alias itself is used. For this reason, and to obey Internet conventions, a typical scheme would be:
list: some, set, of, addresses list-request: list-admin-1, list-admin-2, ... owner-list: list-request
To stop and restart sendmail:
Currently, anti-spam features cannot be enabled with the SCOadmin Sendmail Configuration Manager, mkdev cf, or the Internet Manager's mail configuration options. With the exception of check_rcpt, modifications made to /usr/lib/sendmail.cf to enable anti-spam features are not preserved across successive executions of these configuration utilities. Be sure to save your changes to /usr/lib/sendmail.cf so that you can re-enable the anti-spam features should you run one of the sendmail configuration utilities.
Those sending spam mail often try to use an intermediate system in an attempt to hide the source of electronic mail. The check_rcpt ruleset prevents your site from being used as an intermediate site between a sender and a recipient.
To implement check_rcpt:
The class R, defined by entries in the file /usr/lib/mail/antispam/sendmail.cR, allows additional relays not defined in the relays map. You must also have DD and Cw defined for this ruleset to function properly.
The relays file (/usr/lib/mail/antispam/relays), used by the the check_rcpt ruleset, specifies those sites and IP numbers that are allowed to use this site as an intermediate relay.
Add entries to the file using this <Tab>-separated format:
address OKaddress is either the fully-qualified domain name or the IP number of the site that is allowed to use this one as an intermediate relay. The fields must be <Tab>-separated, and the
OK entry is required.
For example, to allow the site bomb20.pdev.sco.com to use this site as an intermediate relay, add the following line to the file:
bomb20.pdev.sco.com OK
This example shows a specific IP number:
10.0.67.15 OK
After adding or deleting entries from this file, rebuild the relays map:
This ruleset prevents mail from being sent from a pre-defined list of fully qualified domain names and/or IP numbers, regardless of recipient.
To implement this feature:
The spammers file (/usr/lib/mail/antispam/spammers), used by the check_relay or check_mail rulesets, identifies systems from which mail will be rejected.
Add entries to the file using this <Tab>-separated format:
address messageaddress is either the fully qualified domain name or the IP number of the site from which this system will refuse mail. message is the error message to be sent back to the sender. For example, to refuse mail from the machines bomb20.pdev.sco.com and the machine at IP address 10.0.67.15, you might add these entries:
bomb20.pdev.sco.com Mail rejected, contact postmaster@mydomain.com 10.0.67.15 Mail rejected, contact postmaster@mydomain.comNote that the error message is only used by check_mail, not check_relay. However, a string must always exist on the right hand side of this file regardless of which ruleset uses it.
After editing this file, rebuild the spammers map:
This ruleset requires that the domain of the sender specified in the "Mail From:" SMTP command resolves to a valid fully-qualified DNS domain name. Additionally, the client making the connection to the local SMTP server is checked against a pre-defined list of fully qualified domain names.
To implement this feature:
Use check_compat to prevent mail from being sent from a pre-defined list of domain names or email addresses to a specified list of recipients. For example, you may use this ruleset for preventing all mail from any user in domain foobar.com from being sent to any user in domain barfoo.com, but still allow mail from users in foobar.com to be sent to users in other domains. This is useful for combating individual spam attacks from individual sites to a specific set of users or domains.
To implement this feature:
The spammers2 file (/usr/lib/mail/antispam/spammers2), used by the check_compat ruleset, specifies those addresses that are to be considered as potential spammers against those addresses in the protected map.
Add entries to the file using this <Tab>-separated format:
address SPAMMERaddress is the user name, system name, or domain name which is considered a source of spam mail. For example, if mail from all users in isendspam.com are to be considered generators of spam mail, enter:
isendspam.com SPAMMERThis will mark as a potential spam attack all mail from all users in the domain isendspam.com, as well as all of its subdomains such as machine1.isendspam.com and machine1.subdom.isendspam.com are all considered possible spam.
To specify an individual user instead, enter their individual addresses:
chris@sendyouspam.com SPAMMERThis marks chris@sendyouspam.com as a potential spam generator, but does not affect mail from other users in sendyouspam.com.
All entries must contain the string SPAMMER
on the right hand side.
After editing this file, rebuild the spammers2 map:
Because you can block whole domains from access to your protected users, you may also exclude valid e-mail addresses. In this case, it is best to target individual addresses in the spammers2 file.
The protected users file (/usr/lib/mail/antispam/protected), used by the check_compat ruleset, specifies those addresses that are to be considered 'protected' from spam attacks by the addresses in the spammers2 map.
Add entries to the file using this <Tab>-separated format:
address PROTECTEDaddress is the user name, system name, IP address, or domain name which is considered protected. For example, if mail to all users in foobar.com are protected, enter the line:
foobar.com PROTECTEDThis will mark as protected all mail to all users in the domain foobar.com, as well as its subdomains such as machine1.foobar.com, and machine1.subdom.foobar.com.
To protect individual users rather than entire domains, enter their individual addresses:
chris PROTECTED chris@foobar.com PROTECTEDThis marks as protected the local user chris and the address chris@foobar.com, but leaves as unprotected all other local users and all other users in the domain foobar.com.
All entries must contain the string PROTECTED
on the right hand side.
After editing this file, rebuild the protected map:
mckee@ernie kirk@calderThen any mail arriving for mckee is redirected to the specified accounts.
Actually, the configuration file defines a sequence of filenames to check.
By default, this is the user's .forward file,
but can be defined to be more files by using the
ForwardPath (J) option. If you change this,
you will have to inform your user base of the change; .forward
is the standard place to define mail redirection.
Special header lines
Several header lines have special interpretations
defined by the configuration file.
Others have interpretations built into
sendmail
that cannot be changed.
These built-ins are described here.
If errors occur anywhere during processing, this header causes error messages to go to the listed addresses rather than to the sender. This is intended for mailing lists.
The ``Errors-To:'' header was created when UUCP did not understand the distinction between an envelope and a header; this was a work-around that provided what should now be passed as the envelope sender address. It should go away. It is only used if the UseErrorsTo (l) option is set.
RFC 822 requires at least one recipient field (To:, Cc:, or Bcc: line) in every message. If a message comes in with no recipients listed in the message then sendmail will adjust the header based on the ``NoRecipientAction'' option. One of the possible actions is to add an ``Apparently-To:'' header line for any recipients it is aware of.
The Apparently-To: header is non-standard and discouraged.
The Precedence: header can be used as a crude control of message priority.
It tweaks the sort order in the queue
and can be configured to change the message timeout values.
The precedence of a message also controls how
delivery status notifications (DSNs)
are processed for that message.
IDENT protocol support
sendmail supports the IDENT protocol
as defined in RFC 1413.
Note that the RFC states
a client should wait at least 30 seconds for a response.
The default Timeout.ident is 5 seconds
as many sites have adopted the practice of dropping IDENT queries.
This has lead to delays processing mail.
Although this enhances identification
of the author of an email message
by doing a ``call back'' to the originating system to include
the owner of a particular TCP/IP connection
in the audit trail
it is in no sense perfect;
a determined forger can easily spoof the IDENT protocol.
The following description is excerpted from RFC 1413:
The Identification Protocol is not intended as an authorization or access control protocol. At best, it provides some additional auditing information with respect to TCP connections. At worst, it can provide misleading, incorrect, or maliciously incorrect information.
The use of the information returned by this protocol for other than auditing is strongly discouraged. Specifically, using Identification Protocol information to make access control decisions - either as the primary method (no other checks) or as an adjunct to other methods may result in a weakening of normal host security.
An Identification server may reveal information about users, entities, objects or processes which might normally be considered private. An Identification server provides service which is a rough analog of the CallerID services provided by some phone companies and many of the same privacy considerations and arguments that apply to the CallerID service apply to Identification. If you wouldn't run a "finger" server due to privacy considerations you may not want to run this protocol.
cp /dev/null /usr/lib/sendmail.st chmod 666 /usr/lib/sendmail.stPrint this file with the command mailstats(ADMN). The actual path of this file is defined in the S option of the sendmail.cf file.
The configuration file has three major purposes:
This section provides an overview of the standard configuration file
built with the mkdev cf script,
provides the specifications for
configuration file lines,
and describes
building a configuration file from scratch.
/usr/lib/sendmail.cf overview
A sendmail 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 number sign
(``#'') are comments.
The following paragraphs in this description of the standard configuration file refer to ``sections'' of the standard configuration file. When viewing the configuration file /usr/lib/sendmail.cf, these sections are differentiated by comments constructed to look like headers by encircling them with number signs (``#'').
The first two sections of the standard configuration file consist of macro definitions. These are lines that begin with the letter ``D''. The defined macros are described in ``D--define macro''.
Macros can be used in three ways. They can transmit unstructured textual information into the mail system. An example of this is the name that sendmail uses to identify itself in error messages; the default, ``MAILER-DAEMON'', is defined like this:
DnMAILER-DAEMONMacros can transmit information from sendmail to the configuration file in creating other fields (such as argument vectors to mailers). Examples are the sender name and the recipient host and user names. Other macros are unused internally. These macros can be used as shorthand in the configuration file.
Other example macros:
DlFrom $g $d Do.:%@!^/[]The first line defines the format of the mail ``From'' line. This definition results in ``From <sender_address> <current_date>''. The second line defines the delimiter characters used in addresses (this defines the delimiters ``.:%@!^/[]'').
The next section in the file consists of options. These are lines that begin with the letter ``O''. There are several options that can be set from the configuration file. These include the pathnames of various support files, timeouts, default modes, and so forth. See ``O--set option'' for a complete list of these options. Because options can also be set as an argument in the invocation of sendmail, some of the most useful are also listed in the sendmail(ADMN) manual page.
Example options:
OA/usr/lib/mail/aliases OT3dThe first line defines the location of the alias file (/usr/lib/mail/aliases in this option setting). The second line defines the timeout interval for undelivered mail (this option definition specifies that undelivered mail is returned after 3 days).
This next section in the file assigns values to mail precedence names. These values are used to compute a priority for a mail message. sendmail uses this priority to order mail messages in the mail queue. See ``Altering queue priorities'' for a description of how precedence values are used.
Example precedence setting:
Pspecial-delivery=100This setting defines a value of 100 for messages that include ``special-delivery'' in the ``Precedence:'' field. (The lower the value, the higher priority given the message.)
This next section in the file contains header declarations that inform sendmail of the format of known header lines. Knowledge of a few header lines is built into sendmail, such as the ``From:'' and ``Date:'' lines. See ``H--define header'' for a description of how headers are declared and ``D--define macro''. for a description of the macros used.
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.
Example header format:
H?D?Date: $a H?F?From: $qThe first line declares a ``Date:'' header and defines its contents to be the origination date in RFC 822 format. The second line declares a ``From:'' header and defines its contents to be the sender's address.
The next several sections of the file are the rewriting rules which sendmail uses to parse addresses. These are lines beginning with the letter ``S'', which names the ruleset to which the following rules belong, and the letter ``R'', which are the rules.
There are multiple rule sets with specific purposes. These purposes are discussed in ``Semantics of rewriting rule sets''.
At the end of the standard configuration file are sections that contain the mailer declarations. These are lines beginning with the letter ``M''. You will see rewriting rule lines between and after the mailer declaration lines. These are for rulesets that customize addresses for specific mailers.
Mailer declarations tell sendmail of the various mailers available to it. A mailer declaration specifies the internal name of the mailer, the pathname of the program to call, some of the flags associated with the mailer, and an argument vector to be used in the call to the mailer. See ``M--define mailer''.
Example mailer declaration:
Mlocal, P=/usr/bin/lmail, F=lsFDMPuhCE, S=10, R=20, A=lmail $u
The core of address parsing is the rewriting rules. These are an ordered list of pattern-replacement rules which are applied to each address. The sendmail command 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 address 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.
The syntax of these two commands is:
The left-hand side of rewriting rules contains a pattern. Normal words are simply matched directly. Metasyntax is introduced using a dollar sign. The metasymbols are:
$* match zero or more tokens $+ match one or more tokens $- match exactly one token $=x match any phrase in class x $~x match any word not in class xIf any of these match, they are assigned to the symbol $n for replacement on the right-hand side (RHS), where n is the index in the LHS. For example, suppose a LHS rule of the following:
$-:$+Further, suppose the following input:
UCBARPA:ericIn this example, the input matches the rule, and the values passed to the RHS are:
Additionally, the LHS can include $@ to match zero tokens. This is not bound to a $n on the RHS and is normally only used when it stands alone in order to match the null input.
When the left-hand side of a rewriting rule matches, the input is deleted and replaced by the right-hand side. Tokens are copied directly from the RHS, unless they begin with a dollar sign. Metasymbols are:
$n substitutes indefinite token n
from LHS
$[name$] canonicalizes name
$(map key $@arguments $:default $)
generalized keyed mapping function
$>n calls ruleset n
$#mailer resolves to mailer
$@host specifies host
$:user specifies user
The $n
syntax substitutes the corresponding value from a
$+,
$-,
$*,
$=,
or
$~
match on the LHS.
It can be used anywhere.
A host name enclosed between
$[ and $]
is looked up using the
gethostbyname(SLIB)
routines and replaced by the canonical name.
(This is actually completely equivalent to:
$(host hostname $)
In particular, a $: default can be used.) For example, $[[128.32.130.2]$] might become vango.CS.Berkeley.EDU, and $[csam$] might become lbl-csam.arpa. sendmail recognizes its numeric IP address without calling the name server and replaces it with its canonical name.
The $( ... $) syntax is a more general form of lookup; it uses a named map instead of an implicit map. If no lookup is found, the indicated default is inserted; if no default is specified and no lookup matches, the value is left unchanged. The arguments are passed to the map for possible use.
The $>n syntax causes the remainder of the line to be substituted as usual and then passed as the argument to ruleset n. The final value of ruleset n then becomes the substitution for this rule. The $> syntax expands everything after the ruleset name to the end of the replacement string and then passes that as the initial input to the ruleset. Recursive calls are allowed. For example:
$>0 $>3 $1expands $1, passes that to ruleset 3, and then passes the result of ruleset 3 to ruleset 0.
The $#
syntax should only be used in ruleset zero or a
subroutine of ruleset zero.
It causes evaluation of the ruleset to terminate immediately,
and it signals to
sendmail
that the address has completely resolved.
The complete syntax is:
$#mailer $@host $:user
This specifies the {mailer, host, user} triple necessary to direct the mailer. If the mailer is local, the host part can be omitted. (You may want to use it for special ``per user'' extensions. For example, at CMU you can send email to ``jgm+foo''; the part after the plus sign is not part of the user name, and is passed to the local mailer for local use.) The mailer must be a single word, but the host and the user can be multi-part. If the mailer is the built-in IPC mailer, the host may be a colon-separated list of hosts that are searched in order for the first working address (exactly like MX records). The user is later rewritten by the mailer-specific envelope rewriting set and assigned to the $u macro. As a special case, if mailer specified has the F=@ flag specified and the first character of the ``$:'' value is ``@'', the ``@'' is stripped off and a flag is set in the address descriptor that causes sendmail not to do ruleset 5 processing.
Normally, a rule that matches is retried, that is, the rule loops until it fails.
A RHS can also be preceded by a
$@
or a
$:
to change this behavior.
A
$@
prefix causes the ruleset to return with the remainder of the RHS
as the value.
A
$:
prefix causes the rule to terminate immediately,
but the ruleset to continue.
This can avoid continued application of a rule.
The prefix is stripped before continuing.
The $@ and $: prefixes can precede a $> specification. For example, the form:
R$+ $: $>7 $1matches anything, passes that to ruleset seven, and continues; the $: is necessary to avoid an infinite loop.
Substitution occurs in the order described; that is, parameters from the LHS are substituted, hostnames are canonicalized, ``subroutines'' are called and, finally, $#, $@, and $: are processed.
There are six rewriting sets that have specific semantics. Five of these are related as depicted in the figure.
Figure 5-1 Rewriting set semantics
Ruleset three should turn the address into ``canonical form.'' This form should have the basic syntax:
local-part@host-domain-specIf no ``@'' sign is specified, then the host-domain-spec can be appended from the sender address (if the C flag is set in the mailer definition corresponding to the sending mailer). Ruleset three is applied by sendmail before doing anything with any address.
Ruleset zero is applied after ruleset three to addresses that are actually going to specify recipients. It must resolve to a {mailer, host, address} 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 argv expansion of the specified mailer.
Rulesets one and two are applied to all sender and recipient addresses, respectively. They are applied before any specification in the mailer definition. They must never resolve.
Ruleset four is applied to all addresses in the message. It is typically used to translate internal to external form.
In addition, ruleset 5 is applied to all local addresses (specifically, those that resolve to a mailer with the F=5 flag set) that do not have aliases. This allows a last minute hook for local names.
A few extra rulesets are defined as ``hooks'' that can be defined to get special features. They are all named rulesets. The ``check_*'' forms all give accept/reject status; falling off the end or returning normally is an accept, and resolving to $#error is a reject. Many of these can also resolve to the special mailer name $#discard; this accepts the message as though it were successful but then discards it without delivery. Note that this mailer can not be chosen as a mailer in ruleset 0.
The check_relay ruleset is called after a connection is accepted by the daemon. It is not called when sendmail is started using the -bs option. It is passed
client.host.name $| client.host.addresswhere $| is a metacharacter separating the two parts. This ruleset can reject connections from various locations.
The check_mail ruleset is passed the user name parameter of the SMTP MAIL command. It can accept or reject the address.
The check_rcpt ruleset is passed the user name parameter of the SMTP RCPT command. It can accept or reject the address.
The check_compat ruleset is passed
sender-address $| recipient-addresswhere $| is a metacharacter separating the addresses. It can accept or reject mail transfer between these two addresses much like the checkcompat() function.
The check_eoh ruleset is passed
number-of-headers $| size-of-headerswhere $| is a metacharacter separating the numbers. These numbers can be used for size comparisons with the arith map. The ruleset is triggered after all of the headers have been read. It can be used to correlate information gathered from those headers using the macro storage map. One possible use is to check for a missing header. For example:
Kstorage macro HMessage-Id: $>CheckMessageIdKeep in mind the Message-Id: header is not a required header and is not a guaranteed spam indicator. This ruleset is an example and should probably not be used in production.SCheckMessageId # Record the presence of the header R$* $: $(storage {MessageIdCheck} $@ OK $) $1 R< $+ @ $+ > $@ OK R$* $#error $: 553 Header Error
Scheck_eoh # Check the macro R$* $: < $&{MessageIdCheck} > # Clear the macro for the next message R$* $: $(storage {MessageIdCheck} $) $1 # Has a Message-Id: header R< $+ > $@ OK # Allow missing Message-Id: from local mail R$* $: < $&{client_name} > R< > $@ OK R< $=w > $@ OK # Otherwise, reject the mail R$* $#error $: 553 Header Error
The check_etrn ruleset is passed the parameter of the SMTP ETRN command. It can accept or reject the command.
The check_expn ruleset is passed the user name parameter of the SMTP EXPN command. It can accept or reject the address.
The check_vrfy ruleset is passed the user name parameter of the SMTP VRFY command. It can accept or reject the command.
The trust_auth ruleset is passed the AUTH= parameter of the SMTP MAIL command. It is used to determine whether this value should be trusted. In order to make this decision, the ruleset may make use of the various ${auth_*} macros. If the ruleset does resolve to the ``error'' mailer the AUTH= parameter is not trusted and hence not passed on to the next relay.
The tls_client ruleset is called when sendmail acts as server, after a STARTTLS command has been issued, and from check_mail. The parameter is the value of ${verify} and STARTTLS or MAIL, respectively. If the ruleset does resolve to the ``error'' mailer, the appropriate error code is returned to the client.
The tls_server ruleset is called when sendmail acts as client after a STARTTLS command (should) have been issued. The parameter is the value of ${verify}. If the ruleset does resolve to the ``error'' mailer, the connection is aborted (treated as non-deliverable with a permanent or temporary error).
Some special processing occurs if the ruleset zero resolves to an IPC mailer (that is, a mailer that has ``[IPC]'' listed as the Path in the M configuration line). The host name passed after ``$@'' has MX expansion performed if not delivering via a named socket; this looks the name up in DNS to find alternate delivery sites.
The host name can also be provided as a dotted quad in square brackets; for example:
[128.32.149.78]This causes direct conversion of the numeric value to a TCP/IP host address.
The host name passed in after the
``$@''
may also be a colon-separated list of hosts.
Each is separately MX expanded and the results are concatenated
to make (essentially) one long MX list.
The intent here is to create
``fake''
MX records that are not published in DNS
for private internal networks.
As a final special case, the host name can be passed in as a text string in square brackets:
[ucbvax.berkeley.edu]This form avoids the MX mapping.
Macros are named with a single character or with a word in {braces}. These can be selected from the entire ASCII set, but user-defined macros should be selected from the set of uppercase letters only. Lowercase letters and special symbols are used internally. Long names beginning with a lower case letter or a punctuation character are reserved for use by sendmail, so user-defined long macro names should begin with an upper case letter.
The syntax for macro definitions is:
Dxval
Here x is the name of the macro and val is the value it should have. Macros are interpolated using the construct $x, where x is the name of the macro to be interpolated. This interpolation is done when the configuration file is read, except in M lines. The special construct $&x can be used in R lines to get deferred interpolation.
Conditionals can be specified using the syntax:
This interpolates text1 if the macro $x is set, and text2 otherwise. The ``else'' ($|) clause can be omitted.
Lowercase macro names are reserved to have
special semantics,
used to pass information in or out of
sendmail;
some special characters are reserved to
provide conditionals; and so on.
Uppercase names (that is, $A through $Z)
are specifically reserved for configuration file authors.
The following macros are defined and/or used internally by sendmail for interpolation into argv's for mailers or for other contexts. The ones marked + are information passed into sendmail, the ones marked ++ are information passed both in and out of sendmail, and the unmarked macros are passed out of sendmail but are not otherwise used internally.
$?x$x <$g>$|$g$.or
$g$?x ($x)$.which correspond to the following two formats:
sendmail properly quotes names that have special characters if the first form is used.
O SmtpGreetingMessage=$?{if_name}${if_name}$|$j$. Sendmail $v/$Z; $b
OK verification succeeded.
NO no cert presented.
FAIL cert presented but could not be
verified, for example, the
signing CA is missing.
NONE STARTTLS has not been performed.
TEMP temporary error occurred.
PROTOCOL some protocol error occurred.
SOFTWARE STARTTLS handshake failed.
The $f macro is the ID of the sender as originally determined; when you are mailing to a specific host, the $g macro is set to the address of the sender relative to the recipient. For example, if eric sends to bollard@matisse.CS.Berkeley.EDU from the machine vango.CS.Berkeley.EDU, the $f macro is ``eric'' and the $g macro is ``eric@vango.CS.Berkeley.EDU''.
The $x macro is set to the full name of the sender. This can be determined in several ways. It can be passed as a flag to sendmail. The second choice is the value of the ``Full-name:'' line in the header if it exists, and the third choice is the comment field of a ``From:'' line. If all of these fail, and if the message is being originated locally, the full name is looked up in the /etc/passwd file.
When sending, the $h, $u, and $z macros are set to the host, user, and home directories (if local) of the recipient. The first two are set from the $@ and $: parts of the rewriting rules, respectively.
The $p and $t macros 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 timestamp line, it can be extremely useful for tracking messages. The $v macro is set to be the version number of sendmail; this is normally put in timestamps and has proved extremely useful for debugging.
The $c macro is set to the ``hop count,'' that is, the number of times this message has been processed. This can be determined by the -h flag on the command line or by counting the timestamps in the message.
The $r and $s macros are set to the protocol used to communicate with sendmail and the sending hostname.
The $_ macro is set to a validated sender host name. If the sender is running an RFC 1413 compliant IDENT server and the receiver has the IDENT protocol turned on, it will include the user name on that host.
The ${client_name}, ${client_addr}, and ${client_port} macros are set to the name, address, and port number of the SMTP client who is invoking sendmail as a server. These can be used in the check_* rulesets (using the $& deferred evaluation form).
Classes of phrases may be defined to match on the left-hand side of rewriting rules, where a ``phrase'' is a sequence of characters that do not contain space characters. For example, a class of all local names for this site might be created so that attempts to send to oneself can be eliminated. These can either be defined directly in the configuration file or read in from another file. Classes are named as a single letter or a word in {braces}. Class names beginning with lower case letters and special characters are reserved for system use. Classes defined in config files may be given names from the set of upper case letters for short names or beginning with an upper case letter for long names.
The syntax is:
Ccphrase1 phrase2...
Fcfile
The first form defines the class c to match any of the named words. It is permissible to split them among multiple lines, for example:
CHmonet ucbmonetThis example is equivalent to the following:
CHmonet CHucbmonetThe ``F'' form reads the elements of the class c from the named file. Each element should be listed on a separate line. To specify an optional file, use ``-o'' between the class name and the file name, for example:
Fc -o /path/to/fileIf the file cannot be used, sendmail will not complain but silently ignore it.
Elements of classes can be accessed in rules using $= or $~. The $~ (match entries not in class) only matches a single word; multi-word entries in the class are ignored in this context.
Some classes have internal meaning to sendmail:
sendmail can be compiled to allow a scanf(S) string on the F line. This lets you do simplistic parsing of text files. For example, to read all the user names in your system /etc/passwd file into a class, use
FL/etc/passwd %[^:]which reads every line up to the first colon.
Programs and interfaces to mailers
are defined in this line.
The format is:
Mname, {field=value}*
Here name is the name of the mailer (used internally only) and the ``field=name'' pairs define attributes of the mailer. Fields are:
Path The pathname of the mailer Flags Special flags for this mailer Sender Rewriting set(s) for sender addresses Recipient Rewriting set(s) for recipient addresses Argv An argument vector to pass to this mailer Eol The end-of-line string for this mailer Maxsize The maximum message length to this mailer maxmessages The maximum message deliveries per connection Linelimit The maximum line length in the message body Directory The working directory for the mailer Userid The default user and group id to run as Nice The nice increment for the mailer Charset The default character set for 8-bit characters Type Type information for DSN diagnostics Wait The maximum time to wait for the mailer / The root directory for the mailerOnly the first character of the field name is checked.
The following flags may be set in the mailer description. Any other flags may be used freely to conditionally assign headers to messages destined for particular mailers.
From: usera@hosta To: userb@hostb, usercbecomes:
From: usera@hosta To: userb@hostb, userc@hosta
Configuration files prior to level 6 assume the `A', `w', `5', `:', `|', `/', and `@' options on the mailer named ``local .''
The mailer with the special name ``error'' can be used to generate a user error. The (optional) host field is an exit status to be returned, and the user field is a message to be printed. The exit status may be numeric or one of the values USAGE, NOUSER, NOHOST, UNAVAILABLE, SOFTWARE, TEMPFAIL, PROTOCOL, or CONFIG to return the corresponding EX_ exit code, or an enhanced error code as described in RFC 1893 (Enhanced Mail System Status Codes). For example, the entry:
$#error $@ NOHOST $: Host unknown in this domainon the RHS of a rule will cause the specified error to be generated and the ``Host unknown'' exit status to be returned if the LHS matches. This mailer is only functional in rulesets 0, 5, or one of the check_* rulesets.
The mailer with the special name discard causes any mail sent to it to be discarded but otherwise treated as though it were successfully delivered. This mailer can not be used in ruleset 0, only in the various address checking rulesets.
The mailer named ``local'' must be defined in every configuration file. This is used to deliver local mail, and is treated specially in several ways. Additionally, three other mailers named ``prog'', ``*file*'', and ``*include*'' may be defined to tune the delivery of messages to programs, files, and :include: lists respectively. They default to:
Mprog, P=/bin/sh, F=lsoDq9, T=DNS/RFC822/X-Unix, A=sh -c $u M*file*, P=[FILE], F=lsDFMPEouq9, T=DNS/RFC822/X-Unix, A=FILE $u M*include*, P=/dev/null, F=su, A=INCLUDE $u
The Sender and Recipient rewriting sets may either be a simple ruleset id or may be two ids separated by a slash; if so, the first rewriting set is applied to envelope addresses and the second is applied to headers.
The Directory is actually a colon-separated path of directories to try. For example, the definition ``D=$z:/'' first tries to execute in the recipient's home directory; if that is not available, it tries to execute in the root of the filesystem. This is intended to be used only on the ``prog'' mailer, because some shells (such as csh) refuse to execute if they cannot read the home directory. Because the queue directory is not normally readable by normal users csh scripts as recipients can fail.
The Userid specifies the default user and group id to run as, overriding the DefaultUser option (q.v.). If the S mailer flag is also specified, this user and group will be set as the effective uid and gid for the process. This may be given as user:group to set both the user and group id; either may be an integer or a symbolic name to be looked up in the passwd and group files respectively. If only a symbolic user name is specified, the group id in the passwd file for that user is used as the group id.
The Charset field is used when converting a message to MIME; this is the character set used in the Content-Type: header. If this is not set, the DefaultCharset option is used, and if that is not set, the value ``unknown-8bit'' is used.
The Type= field sets the type information used in MIME error messages as defined by RFC 1894. It is actually three values separated by slashes: the MTA-type (that is, the description of how hosts are named), the address type (the description of e-mail addresses), and the diagnostic type (the description of error diagnostic codes). Each of these must be a registered value or begin with ``X-.'' The default is ``dns/rfc822/smtp''.
The m= field specifies the maximum number of messages to attempt to deliver on a single SMTP or LMTP connection.
The /= field specifies a new root directory for the mailer. The path is macro expanded and then passed to the ``chroot'' system call. The root directory is changed before the Directory field is consulted or the uid is changed.
The Wait= field specifies the maximum time to wait for the mailer to return after sending all data to it. This applies to mailers that have been forked by sendmail.
The format of the header lines that sendmail
inserts into the message are defined by the
H line.
The syntax of this line is one of the following:
Hhname: htemplate
H[?mflags?]hname: htemplate
H[?${macro}]hname: htemplate
Continuation lines in this spec are reflected directly into the outgoing message. The htemplate is macro-expanded before insertion into the message. If the mflags (surrounded by question marks) are specified, at least one of the specified flags must be stated in the mailer definition for this header to be automatically output. If a ${macro} (surrounded by question marks) is specified, the header will be automatically output if the macro is set. The macro may be set using any of the normal methods, including using the macro storage map in a ruleset. If one of these headers is in the input it is reflected to the output regardless of these flags or macros.
Some headers have special semantics that will be described later.
A secondary syntax allows validation of headers as they are being read.
To enable validation, use:
HHeader:$>Ruleset
HHeader:$>+Ruleset
The indicated Ruleset is called for the specified Header, and can return $#error to reject the message or $#discard to discard the message (as with the other check_ * rulesets). The header is treated as a structured field, that is, comments (in parentheses) are deleted before processing, unless the second form $>+ is used.
For example, the configuration lines:
HMessage-Id: $>CheckMessageIdwould refuse any message that had a Message-Id: header of any of the following forms:SCheckMessageId R< $+ @ $+ > $@ OK R$* $#error $: Illegal Message-Id header
Message-Id: <> Message-Id: some text Message-Id: <legal text@domain> extra crudA default ruleset that is called for headers which don't have a specific ruleset defined for them can be specified by:
or
H*:$>+Ruleset
There are a number of global options that
can be set from a configuration file.
Options are represented by full words;
some are also representable as single characters
for backwards compatibility. The syntax of this line is:
O option=value
This sets option option
to be value. Note that there
must
be a space between the letter `O' and the name of the option.
An older version is:
Oovalue
where the option o is a single character. 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.
The options supported (with the old, one character names in brackets) are:
The default is to try whenever SMTP AUTH is available.
Port Name/number of source port for connection (defaults to any free port) Addr Address mask (defaults INADDR_ANY) Family Address family (defaults to INET) SndBufSize Size of TCP send buffer RcvBufSize Size of TCP receive buffer Modifier Options (flags) for the daemonThe Address mask may be a numeric address in dot notation or a network name. Modifier can be the following character:
If ``h'' is set, the name corresponding to the outgoing interface address (whether chosen via the Connection parameter or the default) is used for the HELO/EHLO command.
Name User-definable name for the daemon (defaults to "Daemon#") Port Name/number of listening port (defaults to "smtp") Addr Address mask (defaults INADDR_ANY) Family Address family (defaults to INET) Listen Size of listen queue (defaults to 10) Modifier Options (flags) for the daemon SndBufSize Size of TCP send buffer RcvBufSize Size of TCP receive bufferThe Name field is used for error messages and logging. The Addr ess mask may be a numeric address in dot notation or a network name. The Family key defaults to INET (IPv4). Modifier can be a sequence (without any delimiters) of the following characters:
a always require authentication b bind to interface through which mail has been received c perform hostname canonification (.cf) f require fully qualified hostname (.cf) u allow unqualified addresses (.cf) C don't perform hostname canonification E disallow ETRN (see RFC 2476)That is, one way to specify a message submission agent (MSA) that always requires authentication is:
The modifiers that are marked with "(.cf)" have only effect in the standard configuration file, in which they are available via ${daemon_flags}. The flags ``c'' and ``C'' can change the default for hostname canonification in the sendmail.cf file. The modifier ``f'' disallows addresses of the form user@host unless they are submitted directly. The flag ``u'' allows unqualified sender addresses. ``b'' forces sendmail to bind to the interface through which the e-mail has been received for the outgoing connection.
i Deliver interactively (synchronously) b Deliver in background (asynchronously) q Just queue the message (deliver during queue run) d Defer delivery and all map lookups (deliver during queue run)Defaults to ``b'' if no option is specified, ``i'' if it is specified but given no argument (that is, ``Od'' is equivalent to ``Odi''). The -v command line flag sets this to i..
Safe is the default. The details of these flags are described above. Use of this option is not recommended.
<@known1,@known2,@known3:user@unknown>sendmail will strip off the ``@known1,@known2'' in order to make the route as direct as possible. However, if the R option is set, this will be disabled, and the mail will be sent to the first address in the route, even if later addresses are known. This may be useful if you are caught behind a firewall.
s Reject undeclared 8-bit data (``strict'')
m Convert undeclared 8-bit data to MIME (``mime'')
p Pass undeclared 8-bit data (``pass'')
In all cases properly declared 8BITMIME data will be converted to 7BIT
as needed.
p Print error messages (default) q No messages, just give exit status m Mail back errors w Write back errors (mail if user not logged in) e Mail back errors and give zero exit stat always
public Allow open access needmailhelo Insist on HELO or EHLO command before MAIL needexpnhelo Insist on HELO or EHLO command before EXPN noexpn Disallow EXPN entirely, implies noverb. needvrfyhelo Insist on HELO or EHLO command before VRFY novrfy Disallow VRFY entirely noetrn Disallow ETRN entirely noverb Disallow VERB entirely restrictmailq Restrict mailq command restrictqrun Restrict -q command line flag noreceipts Don't return success DSNs nobodyreturn Don't return the body of a message with DSNs goaway Disallow essentially all SMTP status queries authwarnings Put X-Authentication-Warning: headers in messagesThe ``goaway'' pseudo-flag sets all flags except ``noreceipts,'' ``restrictmailq,'' ``restrictqrun,'' ``noetrn,'' and ``nobodyreturn .'' If mailq is restricted, only people in the same group as the queue directory can print the queue. If queue runs are restricted, only root and the owner of the queue directory can run the queue. Authentication Warnings add warnings about various conditions that may indicate attempts to spoof the mail system, such as using an non-standard queue directory.
aliases files hosts dns nis files
Values for the ``Precedence:'' field may be defined 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 below zero have the special property that if an error occurs during processing, the body of the message will not be returned; this is expected to be used for ``bulk'' mail such as through mailing lists. The default precedence is zero. An example list of precedences is:
Pfirst-class=0 Pspecial-delivery=100 Plist=-30 Pbulk=-60 Pjunk=-100People writing mailing list exploders are encouraged to use ``Precedence: list''. Older versions of sendmail (which discarded all error returns for negative precedences) did not recognize this name, giving it a default precedence of zero. This allows list maintainers to see error returns on both old and new versions of sendmail.
To provide compatibility with old configuration files, the V line has been added to define some very basic semantics of the configuration file. These are not intended to be long term supports; rather, they describe compatibility features which will probably be removed in future releases.
``Old'' configuration files are defined as version level one.
Version level two files make the following changes:
Version level three files allow # initiated comments on all lines. Exceptions are backslash escaped # marks and the $# syntax.
Version level four configurations are completely equivalent to level three for historical reasons.
Version level five configuration files change the default definition of $w to be just the first component of the hostname.
Version level six configuration files change many of the local processing options (such as aliasing and matching the beginning of the address for `|' characters) to be mailer flags; this allows fine-grained control over the special local processing. Level six configuration files may also use long option names. The ColonOkInAddr option (to allow colons in the local-part of addresses) defaults on for lower numbered configuration files; the configuration file requires some additional intelligence to properly handle the RFC 822 group construct.
Version level seven configuration files used new option names to replace old macros ($e became SmtpGreetingMessage , $l became UnixFromLine , and $o became OperatorChars). Also, prior to version seven, the F=q flag (use 250 instead of 252 return value for SMTP VRFY commands) was assumed.
Version level eight configuration files allow $# on the left hand side of ruleset lines.
Version level nine configuration files allow parentheses in rulesets, that is, they are not treated as comments and hence removed.
The V line may have an optional /vendor to indicate that this configuration file uses modifications specific to a particular vendor. You can use ``/Berkeley'' to emphasize that this configuration file uses the Berkeley dialect of sendmail.
Special maps can be defined using the line:
Kmapname mapclass arguments
The mapname is the handle by which this map is referenced in the rewriting rules. The mapclass is the name of a type of map; these are compiled in to sendmail . The arguments are interpreted depending on the class; typically, there would be a single argument naming the file containing the map.
Maps are referenced using the syntax:
$( map key $@ arguments $: default $)
where either or both of the arguments or default portion may be omitted. The "$@ arguments" may appear more than once. The indicated key and arguments are passed to the appropriate mapping function. If it returns a value, it replaces the input. If it does not return a value and the default is specified, the default replaces the input. Otherwise, the input is unchanged.
The arguments
are passed to the map for arbitrary use.
Most map classes can interpolate these arguments
into their values using the syntax
``%n'' (where n
is a digit)
to indicate the corresponding
argument .
Argument
``%0''
indicates the database key.
For example, the rule
R$- ! $+ $: $(uucp $1 $@ $2 $: %1 @ %0 . UUCP $)
Looks up the UUCP name in a (user defined) UUCP map;
if not found it turns it into
``.UUCP''
form.
The database might contain records like:
decvax %1@%0.DEC.COM
research %1@%0.ATT.COM
Note that default clauses never do this mapping.
The built in map with both name and class
``host''
is the host name canonicalization lookup.
Thus,
the syntax:
$(host hostname$)
is equivalent to:
$[hostname$]
There are many defined classes.
then a lookup against ``seqmap'' first does a lookup in map1. If that is found, it returns immediately. Otherwise, the same key is used for map2.
together with the service switch entry:
aliases nis files
This causes a query against the map ``ali'' to search maps named ``ali.nis'' and ``ali.files'' in that order.
A typical usage is probably something like:
Kdequote dequote
...
R$- $: $(dequote $1 $)
R$- $+ $: $>3 $1 $2
Care must be taken to prevent unexpected results;
for example,
"|someprogram < input > output"
will have quotes stripped, but the result is probably not what you had in mind. Fortunately these cases are rare.
The
-s
flag can include an optional parameter which can be used
to select the substrings in the result of the lookup. For example,
-s1,3,4
Note: to match a $ in a string, $$ must be used. If the pattern contains spaces, they must be replaced with the blank substitution character, unless it is space itself.
Most of these accept as arguments the same optional flags and a filename (or a mapname for NIS; the filename is the root of the database path, so that ``.db'' or some other extension appropriate for the database type will be added to get the actual database name).
Known flags are:
would be treated as though it were the single entry
list: user1, user2, user3
in the presence of the -A flag.
The following additional flags are present in the ldap map only:
The
dbm
map appends the strings
``.pag''
and
``.dir''
to the given filename;
the
hash
and
btree
maps append
``.db .''
For example, the map specification
Kuucp dbm -o -N /etc/mail/uucpmap
specifies an optional map named ``uucp'' of class ``dbm ;'' it always has null bytes at the end of every string, and the data is located in /etc/mail/uucpmap.{dir,pag}.
The program makemap(ADMN) can be used to build any of the three database-oriented maps. It takes the following flags:
New classes can be added in the routine
setupmaps
in file conf.c.
Building a configuration file from scratch
Building a configuration file from scratch is an extremely difficult job.
Fortunately, it is almost never necessary to do so;
nearly every situation that may come up
can be resolved by changing an existing configuration file.
In any case,
it is critical that you understand what you are trying to do
and come up with a design plan for the configuration file.
This section is intended to explain the real purpose
of a configuration file
and to give you some ideas
as to what your design plan might be.
Do not even consider writing your own configuration file without carefully studying RFC 821, RFC 822, and RFC 1123. You should also read RFC 976 if you are doing UUCP exchange.
The configuration file has three major purposes. The first and simplest is to set up the environment for sendmail. This involves setting the options, defining a few critical macros, and so on. Because these are described in other sections, we will not go into more detail here.
The second purpose is to rewrite addresses in the message. This should typically be done in two phases. The first phase maps addresses in any format into a canonical form. This should be done in ruleset three. The second phase maps this canonical form into the syntax appropriate for the receiving mailer.
The sendmail program performs this second phase in the following three subphases: Rulesets one and two are applied to all sender and recipient addresses, respectively. After this, you can specify per-mailer rulesets for both sender and recipient addresses. This allows mailer-specific customization. Finally, ruleset four is applied to do any default conversion to external form.
The third purpose of the configuration file is to map addresses into the actual set of instructions necessary to get the message delivered. Ruleset zero must resolve to the internal form, which is in turn used as a pointer to a mailer descriptor. This describes the interface requirements of the mailer.
The canonical form you use should almost certainly be as specified in the Internet standards documents RFC 819 and RFC 822. These RFCs can be ftp'd from ftp.ds.internic.net.
RFC 822
describes the format of the mail message itself.
The
sendmail
program 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:
< > ( ) " \
Any attempt to use these characters for other than their RFC 822 purpose in addresses is probably doomed to disaster.
RFC 819 describes the specifics of the domain-based addressing. This is touched on in RFC 822 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 need not be physical hosts; the domain is logical rather than physical. For example, atOcelot, one legal host might be a.CC.Ocelot.EDU; reading from right to left, EDU is a top level domain comprising educational institutions, Ocelot is a logical domain name, CC represents the Computer Center, (in this case a strictly logical entity), and ``a'' is a host in the Computer Center.
Beware when reading RFC 819 that there are a number of errors in it.
Once you have decided on a design plan for the new configuration file, it is worth examining existing configuration files to decide whether any of them are close enough for you to use major parts of them as a basis for your own configuration file. Even under the worst of conditions, there should be a large amount of material you can use.
The next step is to build ruleset three. This is the hardest part of the job. Beware of doing too much to the address in this ruleset, because anything you do reflects through to the message. In particular, stripping of local domains is best deferred, as this can leave you with addresses with no domain specifications at all. Because sendmail likes to append the sending domain to addresses with no domain, this can change the semantics of addresses. Also, try to avoid fully qualifying domains in this ruleset. Although technically legal, this can lead to unpleasantly and unnecessarily long addresses reflected into messages. The Ocelot configuration files define ruleset nine to qualify domain names and strip local domains. This is called from ruleset zero to get all addresses into a cleaner form.
Once you have ruleset three finished, the other rulesets should be relatively trivial. If you need hints, examine the supplied configuration files.
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
This reads the configuration file test.cf and enters test mode.
In this mode, you enter lines of the form:
rwset address
Here rwset
is the rewriting set you want to use
and
address
is an address to which to apply the set.
Test mode shows you the steps it takes
as it proceeds,
finally showing you the address with which it ends up.
You may use a comma-separated list of rwsets
for sequential application of rules to an input.
For example:
3,1,21,4 monet:bollard
The first applies ruleset three to the input ``monet:bollard.'' Ruleset one is then applied to the output of ruleset three, followed similarly by rulesets 21 and 4.
If you need more detail,
you can also use the -d21 flag to turn on more debugging.
For example:
sendmail -bt -d21.99
This turns on a huge amount of information. A single-word address probably prints out several pages of information.
You should be warned that internally,
sendmail
applies ruleset 3 to all addresses.
In this version of
sendmail,
you will have to do that manually.
For example, older versions allowed you to use
0 bruce@broadcast.sony.com
This version requires that you use:
3,0 bruce@broadcast.sony.com
To add an outgoing mailer to your mail system, you must define the characteristics of the mailer.
Each mailer must have an internal name. This can be arbitrary, except that the names ``local'' and ``prog'' must be defined.
The pathname of the mailer must be given in the ``P'' field. If this mailer should be accessed via an IPC connection, use the string ``[IPC]'' instead.
The ``F'' field defines the mailer flags. You should 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. If the mailer does not produce many errors, you can just specify ``-f $g'' in the argv template. If the mailer must be called as root, the S flag should be given. This does not reset the user ID before calling the mailer. (sendmail must be running setuid to root for this to work.) If this mailer is local (that is, it performs final delivery rather than another network hop), the l flag should be given. Quote characters (backslashes and " marks) can be stripped from addresses if the s flag is specified. If this is not given, they are passed through. If the mailer is capable of sending to more than one user on the same host in a single transaction, the m flag should be stated. 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, which causes sendmail to defer connection until a queue run. (The ``c'' configuration option must be given for this to be effective.)
An unusual case is the C flag. This flag applies to the mailer that the message is received from, rather than the mailer being sent to; if set, the domain specification of the sender (that is, the @host.domain part) is saved and is appended to any addresses in the message that do not already contain a domain specification. For example:
From: eric@vango.CS.Berkeley.EDU To: wnj@monet.CS.Berkeley.EDU, mckusickA message of this form is modified to:
From: eric@vango.CS.Berkeley.EDU To: wnj@monet.CS.Berkeley.EDU, mckusick@monet.CS.Berkeley.EDUThis happens if and only if the C flag is defined in the mailer resolved to by running eric@vango.CS.Berkeley.EDU through rulesets 3 and 0.
Other mailer flags are described in the section ``M--define mailer''.
The ``S'' and ``R'' fields in the mailer description are per-mailer rewriting sets to be applied to sender and recipient addresses, respectively. These are applied after the sending domain is appended and the general rewriting sets (numbers one and two) are applied, but before the output rewrite (ruleset four) is applied. A typical use is to append the current domain to addresses that do not already have a domain. For example:
From: ericA header of this form might be changed to be:
From: eric@vango.CS.Berkeley.EDUOr to this form, depending on the domain it is being shipped into:
From: ucbvax!ericThese sets can also be used to do special-purpose output rewriting in cooperation with ruleset four.
The ``S'' and ``R'' fields can be specified as two numbers separated by a slash (for example, ``S=10/11''), meaning that all envelope addresses will be processed through ruleset 10 and all header addresses will be processed through ruleset 11. With only one number specified, both envelope and header rewriting sets are set to the indicated ruleset.
The ``E'' field defines the string to use as an end-of-line indication. A string containing only newline is the default. The usual backslash escapes (\r, \n, \f, \b) may be used.
Finally,
an argv template is given as the ``A'' field.
It may have embedded spaces.
If there is no argv with a
$u
macro in it,
sendmail
speaks SMTP
to the mailer.
If the pathname for this mailer is
[IPC],
the argv should be:
IPC $h [ port ]
Here port is the optional port number to connect to.
For example:
Mlocal, P=/usr/bin/lmail, F=lsDFMmnPS S=10, R=20, A=lmail $u
Mether, P=[IPC], F=meC, S=11, R=21, A=IPC $h, M=100000, E=\r\n
These specifications specify a mailer to do local delivery and a mailer for Ethernet delivery. The first is called ``local''; it is located in the file /usr/bin/lmail, does local delivery, quotes should be stripped from addresses, and multiple users can be delivered at once; ruleset 10 should be applied to sender addresses in the message, and ruleset 20 should be applied to recipient addresses. The argv to send to a message is the word ``lmail,'' and words containing the name of the receiving user(s).
The second mailer is called
``ether'';
it should be connected to via an IPC connection;
it can handle multiple users at once;
connections should be deferred;
and any domain from the sender address
should be appended to any receiver name
without a domain.
Sender addresses should be processed by ruleset 11
and recipient addresses by ruleset 21.
There is a 100,000-byte limit on messages passed through this mailer.
For more about sendmail
The following reference manual pages provide additional information about
SCO sendmail:
--------------------------------------------------------------- Manual page Description --------------------------------------------------------------- aliases(SFF) aliases file for sendmail lmail(ADMN) handle local mail delivery from sendmail mailaddr(ADMN) mail addressing description mailstats(ADMN) print statistics collected by sendmail mconnect(ADMN) connect to SMTP mail server socket rmail(ADMN) handle remote mail received by UUCP sendmail(ADMN) sendmail command information sendmail.cf(SFF) sendmail configuration file