op.me

来自「<B>Digital的Unix操作系统VAX 4.2源码</B>」· ME 代码 · 共 2,890 行 · 第 1/5 页

.i sendmail
can operate in,
set by the
.q d
configuration option.
These modes
specify how quickly mail will be delivered.
Legal modes are:
.(b
.ta 4n
i	deliver interactively (synchronously)
b	deliver in background (asynchronously)
q	queue only (don't deliver)
.)b
There are tradeoffs.
Mode
.q i
passes the maximum amount of information to the sender,
but is hardly ever necessary.
Mode
.q q
puts the minimum load on your machine,
but means that delivery may be delayed for up to the queue interval.
Mode
.q b
is probably a good compromise.
However, this mode can cause large numbers of processes
if you have a mailer that takes a long time to deliver a message.
.sh 2 "Log Level"
.pp
The level of logging can be set for sendmail.
The default using a standard configuration table is level 9.
The levels are as follows:
.ip 0
No logging.
.ip 1
Major problems only.
.ip 2
Message collections and failed deliveries.
.ip 3
Successful deliveries.
.ip 4
Messages being defered
(due to a host being down, etc.).
.ip 5
Normal message queueups.
.ip 6
Unusual but benign incidents,
e.g.,
trying to process a locked queue file.
.ip 9
Log internal queue id to external message id mappings.
This can be useful for tracing a message
as it travels between several hosts.
.ip 12
Several messages that are basically only of interest
when debugging.
.ip 16
Verbose information regarding the queue.
.sh 2 "File Modes"
.pp
There are a number of files
that may have a number of modes.
The modes depend on what functionality you want
and the level of security you require.
.sh 3 "To suid or not to suid?"
.pp
.i Sendmail
can safely be made
setuid to root.
At the point where it is about to
.i exec \|(2)
a mailer,
it checks to see if the userid is zero;
if so,
it resets the userid and groupid to a default
(set by the
.b u
and
.b g
options).
(This can be overridden
by setting the
.b 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
(using
.i sa \|(8))
to root
rather than to the user sending the mail.
.sh 3 "Temporary file modes"
.pp
The mode of all temporary files that
.i sendmail
creates is determined by the
.q F
option.
Reasonable values for this option are
0600
and
0644.
If the more permissive mode is selected,
it will not be necessary to run
.i sendmail
as root at all
(even when running the queue).
.sh 3 "Should my alias database be writable?"
.pp
At Berkeley
we have the alias database
(/usr/lib/aliases*)
mode 666.
There are some dangers inherent in this approach:
any user can add him-/her-self
to any list,
or can
.q steal
any other user's mail.
However,
we have found users to be basically trustworthy,
and the cost of having a read-only database
greater than the expense of finding and eradicating
the rare nasty person.
.pp
The database that
.i sendmail
actually used
is represented by the two files
.i aliases.dir
and
.i aliases.pag
(both in /usr/lib).
The mode on these files should match the mode
on /usr/lib/aliases.
If
.i aliases
is writable
and the
DBM
files
(\c
.i aliases.dir
and
.i aliases.pag )
are not,
users will be unable to reflect their desired changes
through to the actual database.
However,
if
.i aliases
is read-only
and the DBM files are writable,
a slightly sophisticated user
can arrange to steal mail anyway.
.pp
If your DBM files are not writable by the world
or you do not have auto-rebuild enabled
(with the
.q D
option),
then you must be careful to reconstruct the alias database
each time you change the text version:
.(b
newaliases
.)b
If this step is ignored or forgotten
any intended changes will also be ignored or forgotten.
.sh 1 "THE WHOLE SCOOP ON THE CONFIGURATION FILE"
.pp
This section describes the configuration file
in detail,
including hints on how to write one of your own
if you have to.
.pp
There is one point that should be made clear immediately:
the syntax of the configuration file
is designed to be reasonably easy to parse,
since this is done every time
.i sendmail
starts up,
rather than easy for a human to read or write.
On the
.q "future project"
list is a
configuration-file compiler.
.pp
An overview of the configuration file
is given first,
followed by details of the semantics.
.sh 2 "The Syntax"
.pp
The configuration file is organized as a series of lines,
each of which begins with a single character
defining the semantics for the rest of the line.
Lines beginning with a space or a tab
are continuation lines
(although the semantics are not well defined in many places).
Blank lines and lines beginning with a sharp symbol
(`#')
are comments.
.sh 3 "R and S \*- rewriting rules"
.pp
The core of address parsing
are the rewriting rules.
These are an ordered production system.
.i Sendmail
scans through the set of rewriting rules
looking for a match on the left hand side
(LHS)
of the rule.
When a rule matches,
the address is replaced by the right hand side
(RHS)
of the rule.
.pp
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.
.pp
The syntax of these two commands are:
.(b F
.b S \c
.i n
.)b
Sets the current ruleset being collected to
.i n .
If you begin a ruleset more than once
it deletes the old definition.
.(b F
.b R \c
.i lhs
.i rhs
.i comments
.)b
The
fields must be separated
by at least one tab character;
there may be embedded spaces
in the fields.
The
.i lhs
is a pattern that is applied to the input.
If it matches,
the input is rewritten to the
.i rhs .
The
.i comments
are ignored.
.sh 3 "D \*- define macro"
.pp
Macros are named with a single character.
These may be selected from the entire ASCII set,
but user-defined macros
should be selected from the set of upper case letters only.
Lower case letters
and special symbols
are used internally.
.pp
The syntax for macro definitions is:
.(b F
.b D \c
.i x\|val
.)b
where
.i x
is the name of the macro
and
.i val
is the value it should have.
Macros can be interpolated in most places using the escape sequence
.b $ \c
.i x .
.sh 3 "C and F \*- define classes"
.pp
Classes of words may be defined
to match on the left hand side of rewriting rules.
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 may be given names
from the set of upper case letters.
Lower case letters and special characters
are reserved for system use.
.pp
The syntax is:
.(b F
.b C \c
.i c\|word1
.i word2...
.br
.b F \c
.i c\|file
[
.i format
]
.)b
The first form defines the class
.i c
to match any of the named words.
It is permissible to split them among multiple lines;
for example, the two forms:
.(b
CHmonet ucbmonet
.)b
and
.(b
CHmonet
CHucbmonet
.)b
are equivalent.
The second form
reads the elements of the class
.i c
from the named
.i file ;
the
.i format
is a
.i scanf \|(3)
pattern
that should produce a single string.
.sh 3 "M \*- define mailer"
.pp
Programs and interfaces to mailers
are defined in this line.
The format is:
.(b F
.b M \c
.i name ,
{\c
.i field =\c
.i value \|}*
.)b
where
.i name
is the name of the mailer
(used internally only)
and the
.q field=name
pairs define attributes of the mailer.
Fields are:
.(b
.ta 1i
Path	The pathname of the mailer
Flags	Special flags for this mailer
Sender	A rewriting set for sender addresses
Recipient	A rewriting set 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
.)b
Only the first character of the field name is checked.
.sh 3 "H \*- define header"
.pp
The format of the header lines that sendmail inserts into the message
are defined by the
.b H
line.
The syntax of this line is:
.(b F
.b H [\c
.b ? \c
.i mflags \c
.b ? ]\c
.i hname \c
.b :
.i htemplate
.)b
Continuation lines in this spec
are reflected directly into the outgoing message.
The
.i htemplate
is macro expanded before insertion into the message.
If the
.i 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 one of these headers is in the input
it is reflected to the output
regardless of these flags.
.pp
Some headers have special semantics
that will be described below.
.sh 3 "O \*- set option"
.pp
There are a number of
.q random
options that
can be set from a configuration file.
Options are represented by single characters.
The syntax of this line is:
.(b F
.b O \c
.i o\|value
.)b
This sets option
.i o
to be
.i value .
Depending on the option,
.i value
may be a string, an integer,
a boolean
(with legal values
.q t ,
.q T ,
.q f ,
or
.q F ;
the default is TRUE),
or
a time interval.
.sh 3 "T \*- define trusted users"
.pp
Trusted users
are those users who are permitted
to override the sender address
using the
.b \-f
flag.
These typically are
.q root,
.q uucp,
and
.q network,
but on some users it may be convenient
to extend this list to include other users,
perhaps to support
a separate
UUCP
login for each host.
The syntax of this line is:
.(b F
.b T \c
.i user1
.i user2 ...
.)b
There may be more than one of these lines.
.sh 3 "P \*- precedence definitions"
.pp
Values for the
.q "Precedence:"
field may be defined using the
.b P
control line.
The syntax of this field is:
.(b
\fBP\fP\fIname\fP\fB=\fP\fInum\fP
.)b
When the
.i name
is found in a
.q Precedence:
field,
the message class is set to
.i num .
Higher numbers mean higher precedence.
Numbers less than zero
have the special property
that error messages will not be returned.
The default precedence is zero.
For example,
our list of precedences is:
.(b
Pfirst-class=0
Pspecial-delivery=100
Pjunk=\-100
.)b
.sh 2 "The Semantics"
.pp
This section describes the semantics of the configuration file.
.sh 3 "Special macros, conditionals"
.pp
Macros are interpolated
using the construct
.b $ \c
.i x ,
where
.i x
is the name of the macro to be interpolated.
In particular,
lower case letters are reserved to have
special semantics,
used to pass information in or out of sendmail,
and some special characters are reserved to
provide conditionals, etc.
.pp
The following macros
.i must
be defined to transmit information into
.i sendmail:
.(b
.ta 4n
e	The SMTP entry message
j	The \*(lqofficial\*(rq domain name for this site
l	The format of the UNIX from line
n	The name of the daemon (for error messages)
o	The set of "operators" in addresses
q	default format of sender address
.)b
The
.b $e
macro is printed out when SMTP starts up.
The first word must be the
.b $j
macro.
The
.b $j
macro
should be in RFC821 format.
The
.b $l
and
.b $n
macros can be considered constants
except under terribly unusual circumstances.
The
.b $o
macro consists of a list of characters
which will be considered tokens
and which will separate tokens
when doing parsing.
For example, if
.q r
were in the
.b $o
macro, then the input
.q address
would be scanned as three tokens:
.q add,
.q r,
and
.q ess.
Finally, the
.b $q
macro specifies how an address should appear in a message
when it is defaulted.
For example, on our system these definitions are:
.(b
De$j Sendmail $v ready at $b
DnMAILER-DAEMON
DlFrom $g  $d
Do.:%@!^=/
Dq$g$?x ($x)$.
Dj$H.$D
.)b
An acceptable alternative for the
.b $q
macro is
.q "$?x$x $.<$g>" .
These correspond to the following two formats:
.(b
eric@Berkeley (Eric Allman)
Eric Allman <eric@Berkeley>
.)b
.pp
Some macros are defined by
.i sendmail
for interpolation into argv's for mailers
or for other contexts.
These macros are:
.(b
a	The origination date in Arpanet format