op.me

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

b	The current date in Arpanet format
c	The hop count
d	The date in UNIX (ctime) format
f	The sender (from) address
g	The sender address relative to the recipient
h	The recipient host
i	The queue id
p	Sendmail's pid
r	Protocol used
s	Sender's host name
t	A numeric representation of the current time
u	The recipient user
v	The version number of sendmail
w	The hostname of this site
x	The full name of the sender
y	The id of the sender's tty
z	The home directory of the recipient
.)b
.pp
There are three types of dates that can be used.
The
.b $a
and
.b $b
macros are in Arpanet format;
.b $a
is the time as extracted from the
.q Date:
line of the message
(if there was one),
and
.b $b
is the current date and time
(used for postmarks).
If no
.q Date:
line is found in the incoming message,
.b $a
is set to the current time also.
The
.b $d
macro is equivalent to the
.b $a
macro in UNIX
(ctime)
format.
.pp
The
.b $f
macro is the id of the sender
as originally determined;
when mailing to a specific host
the
.b $g
macro is set to the address of the sender
.ul
relative to the recipient.
For example,
if I send to
.q bollard@matisse
from the machine
.q ucbarpa
the
.b $f
macro will be
.q eric
and the
.b $g
macro will be
.q eric@ucbarpa.
.pp
The
.b $x
macro is set to the full name of the sender.
This can be determined in several ways.
It can be passed as flag to
.i sendmail.
The second choice is the value of the
.q Full-name:
line in the header if it exists,
and the third choice is the comment field
of a
.q From:
line.
If all of these fail,
and if the message is being originated locally,
the full name is looked up in the
.i /etc/passwd
file.
.pp
When sending,
the
.b $h ,
.b $u ,
and
.b $z
macros get set to the host, user, and home directory
(if local)
of the recipient.
The first two are set from the
.b $@
and
.b $:
part of the rewriting rules, respectively.
.pp
The
.b $p
and
.b $t
macros are used to create unique strings
(e.g., for the
.q Message-Id:
field).
The
.b $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
.b $y
macro is set to the id of the terminal of the sender
(if known);
some systems like to put this
in the Unix
.q From
line.
The
.b $v
macro is set to be the version number of
.i sendmail ;
this is normally put in timestamps
and has been proven extremely useful for debugging.
The
.b $w
macro is set to the name of this host
if it can be determined.
The
.b $c
field is set to the
.q "hop count,"
i.e., the number of times this message has been processed.
This can be determined
by the
.b \-h
flag on the command line
or by counting the timestamps in the message.
.pp
The
.b $r
and
.b $s
fields are set to the protocol used to communicate with sendmail
and the sending hostname;
these are not supported in the current version.
.pp
Conditionals can be specified using the syntax:
.(b
$?x text1 $| text2 $.
.)b
This interpolates
.i text1
if the macro
.b $x
is set,
and
.i text2
otherwise.
The
.q else
(\c
.b $| )
clause may be omitted.
.sh 3 "Special classes"
.pp
The class
.b $=w
is set to be the set of all names
this host is known by.
This can be used to delete local hostnames.
.sh 3 "The left hand side"
.pp
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:
.(b
.ta \w'\fB$=\fP\fIx\fP  'u
\fB$*\fP	Match zero or more tokens
\fB$+\fP	Match one or more tokens
\fB$\-\fP	Match exactly one token
\fB$=\fP\fIx\fP	Match any token in class \fIx\fP
\fB$~\fP\fIx\fP	Match any token not in class \fIx\fP
.)b
If any of these match,
they are assigned to the symbol
.b $ \c
.i n
for replacement on the right hand side,
where
.i n
is the index in the LHS.
For example,
if the LHS:
.(b
$\-:$+
.)b
is applied to the input:
.(b
UCBARPA:eric
.)b
the rule will match, and the values passed to the RHS will be:
.(b
.ta 4n
$1	UCBARPA
$2	eric
.)b
.sh 3 "The right hand side"
.pp
When the right 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 are begin with a dollar sign.
Metasymbols are:
.(b
.ta \w'$#mailer  'u
\fB$\fP\fIn\fP	Substitute indefinite token \fIn\fP from LHS
\fB$>\fP\fIn\fP	\*(lqCall\*(rq ruleset \fIn\fP
\fB$#\fP\fImailer\fP	Resolve to \fImailer\fP
\fB$@\fP\fIhost\fP	Specify \fIhost\fP
\fB$:\fP\fIuser\fP	Specify \fIuser\fP
.)b
.pp
The
.b $ \c
.i n
syntax substitutes the corresponding value from a
.b $+ ,
.b $\- ,
.b $* ,
.b $= ,
or
.b $~
match on the LHS.
It may be used anywhere.
.pp
The
.b $> \c
.i n
syntax
causes the remainder of the line to be substituted as usual
and then passed as the argument to ruleset
.i n .
The final value of ruleset
.i n
then becomes
the substitution for this rule.
.pp
The
.b $#
syntax should
.i only
be used in ruleset zero.
It causes evaluation of the ruleset to terminate immediately,
and signals to sendmail that the address has completely resolved.
The complete syntax is:
.(b
\fB$#\fP\fImailer\fP\fB$@\fP\fIhost\fP\fB$:\fP\fIuser\fP
.)b
This specifies the
{mailer, host, user}
3-tuple necessary to direct the mailer.
If the mailer is local
the host part may be omitted.
The
.i mailer
and
.i host
must be a single word,
but the
.i user
may be multi-part.
.pp
A RHS may also be preceeded by a
.b $@
or a
.b $:
to control evaluation.
A
.b $@
prefix causes the ruleset to return with the remainder of the RHS
as the value.
A
.b $:
prefix causes the rule to terminate immediately,
but the ruleset to continue;
this can be used to avoid continued application of a rule.
The prefix is stripped before continuing.
.pp
The
.b $@
and
.b $:
prefixes may preceed a
.b $>
spec;
for example:
.(b
.ta 8n
R$+	$:$>7$1
.)b
matches anything,
passes that to ruleset seven,
and continues;
the
.b $:
is necessary to avoid an infinite loop.
.sh 3 "Semantics of rewriting rule sets"
.pp
There are five rewriting sets
that have specific semantics.
These are related as depicted by figure 2.
.(z
.hl
.ie t .sp 2i
.el \{\
.(c
                    +---+
                 -->| 0 |-->resolved address
                /   +---+
               /            +---+   +---+
              /        ---->| 1 |-->| S |--
       +---+ / +---+  /     +---+   +---+  \e    +---+
addr-->| 3 |-->| D |--                      --->| 4 |-->msg
       +---+   +---+  \e     +---+   +---+  /    +---+
                        --->| 2 |-->| R |--
                            +---+   +---+
.)c

.ce
Figure 2 \*- Rewriting set semantics
.(c
D \*- sender domain addition
S \*- mailer-specific sender rewriting
R \*- mailer-specific recipient rewriting
.)c
.\}
.hl
.)z
.pp
Ruleset three
should turn the address into
.q "canonical form."
This form should have the basic syntax:
.(b
local-part@host-domain-spec
.)b
If no
.q @
sign is specified,
then the
host-domain-spec
.i may
be appended from the
sender address
(if the
.b C
flag is set in the mailer definition
corresponding to the
.i sending
mailer).
Ruleset three
is applied by sendmail
before doing anything with any address.
.pp
Ruleset zero
is applied after ruleset three
to addresses that are going to actually specify recipients.
It must resolve to a
.i "{mailer, host, user}"
triple.
The
.i mailer
must be defined in the mailer definitions
from the configuration file.
The
.i host
is defined into the
.b $h
macro
for use in the argv expansion of the specified mailer.
.pp
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.
.pp
Ruleset four is applied to all addresses
in the message.
It is typically used
to translate internal to external form.
.sh 3 "Mailer flags etc."
.pp
There are a number of flags that may be associated with each mailer,
each identified by a letter of the alphabet.
Many of them are assigned semantics internally.
These are detailed in Appendix C.
Any other flags may be used freely
to conditionally assign headers to messages
destined for particular mailers.
.sh 3 "The \*(lqerror\*(rq mailer"
.pp
The mailer with the special name
.q error
can be used to generate a user error.
The (optional) host field is a numeric exit status to be returned,
and the user field is a message to be printed.
For example, the entry:
.(b
$#error$:Host unknown in this domain
.)b
on the RHS of a rule
will cause the specified error to be generated
if the LHS matches.
This mailer is only functional in ruleset zero.
.sh 2 "Building a Configuration File From Scratch"
.pp
Building a configuration table from scratch is an extremely difficult job.
Fortunately,
it is almost never necessary to do so;
nearly every situation that may come up
may be resolved by changing an existing table.
In any case,
it is critical that you understand what it is that you are trying to do
and come up with a philosophy for the configuration table.
This section is intended to explain what the real purpose
of a configuration table is
and to give you some ideas
for what your philosophy might be.
.sh 3 "What you are trying to do"
.pp
The configuration table has three major purposes.
The first and simplest
is to set up the environment for
.i sendmail .
This involves setting the options,
defining a few critical macros,
etc.
Since these are described in other places,
we will not go into more detail here.
.pp
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.
.i Sendmail
does this in three subphases.
Rulesets one and two
are applied to all sender and recipient addresses respectively.
After this,
you may 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.
.pp
The third purpose
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.
The mailer descriptor describes the interface requirements
of the mailer.
.sh 3 "Philosophy"
.pp
The particular philosophy you choose will depend heavily
on the size and structure of your organization.
I will present a few possible philosophies here.
.pp
One general point applies to all of these philosophies:
it is almost always a mistake
to try to do full name resolution.
For example,
if you are trying to get names of the form
.q user@host
to the Arpanet,
it does not pay to route them to
.q xyzvax!decvax!ucbvax!c70:user@host
since you then depend on several links not under your control.
The best approach to this problem
is to simply forward to
.q xyzvax!user@host
and let xyzvax
worry about it from there.
In summary,
just get the message closer to the destination,
rather than determining the full path.
.sh 4 "Large site, many hosts \*- minimum information"
.pp
Berkeley is an example of a large site,
i.e., more than two or three hosts.
We have decided that the only reasonable philosophy
in our environment
is to designate one host as the guru for our site.
It must be able to resolve any piece of mail it receives.
The other sites should have the minimum amount of information
they can get away with.
In addition,
any information they do have
should be hints rather than solid information.
.pp
For example,
a typical site on our local ether network is
.q monet.
Monet has a list of known ethernet hosts;
if it receives mail for any of them,
it can do direct delivery.
If it receives mail for any unknown host,
it just passes it directly to
.q ucbvax,
our master host.
Ucbvax may determine that the host name is illegal
and reject the message,
or may be able to do delivery.
However, it is important to note that when a new ethernet host is added,
the only host that
.i must
have its tables updated
is ucbvax;
the others
.i may
be updated as convenient,
but this is not critical.
.pp
This picture is slightly muddied
due to network connections that are not actually located
on ucbvax.
For example,
our TCP connection is currently on
.q ucbarpa.
However,
monet
.i "does not"
know about this;
the information is hidden totally between ucbvax and ucbarpa.
Mail going from monet to a TCP host
is transfered via the ethernet
from monet to ucbvax,
then via the ethernet from ucbvax to ucbarpa,
and then is submitted to the Arpanet.
Although this involves some extra hops,
we feel this is an acceptable tradeoff.
.pp
An interesting point is that it would be possible
to update monet
to send TCP mail directly to ucbarpa
if the load got too high;
if monet failed to note a host as a TCP host
it would go via ucbvax as before,
and if monet incorrectly sent a message to ucbarpa
it would still be sent by ucbarpa
to ucbvax as before.
The only problem that can occur is loops,
as if ucbarpa thought that ucbvax had the TCP connection
and vice versa.
For this reason,
updates should
.i always
happen to the master host first.
.pp
This philosophy results as much from the need
to have a single source for the configuration files
(typically built using
.i m4 \|(1)