intro.me

<B>Digital的Unix操作系统VAX 4.2源码</B>

but they only effect the error message \*- the
.q "return to sender"
function is always handled in one of these two ways.
.)f
.sh 2 "Message Header Editing"
.pp
Certain editing of the message header
occurs automatically.
Header lines can be inserted
under control of the configuration file.
Some lines can be merged;
for example,
a
.q From:
line and a
.q Full-name:
line can be merged under certain circumstances.
.sh 2 "Configuration File"
.pp
Almost all configuration information is read at runtime
from an ASCII file,
encoding
macro definitions
(defining the value of macros used internally),
header declarations
(telling sendmail the format of header lines that it will process specially,
i.e., lines that it will add or reformat),
mailer definitions
(giving information such as the location and characteristics
of each mailer),
and address rewriting rules
(a limited production system to rewrite addresses
which is used to parse and rewrite the addresses).
.pp
To improve performance when reading the configuration file,
a memory image can be provided.
This provides a
.q compiled
form of the configuration file.
.sh 1 "USAGE AND IMPLEMENTATION"
.sh 2 "Arguments"
.pp
Arguments may be flags and addresses.
Flags set various processing options.
Following flag arguments,
address arguments may be given,
unless we are running in SMTP mode.
Addresses follow the syntax in RFC822
[Crocker82]
for ARPANET
address formats.
In brief, the format is:
.np
Anything in parentheses is thrown away
(as a comment).
.np
Anything in angle brackets (\c
.q "<\|>" )
is preferred
over anything else.
This rule implements the ARPANET standard that addresses of the form
.(b
user name <machine-address>
.)b
will send to the electronic
.q machine-address
rather than the human
.q "user name."
.np
Double quotes
(\ "\ )
quote phrases;
backslashes quote characters.
Backslashes are more powerful
in that they will cause otherwise equivalent phrases
to compare differently \*- for example,
.i user
and
.i
"user"
.r
are equivalent,
but
.i \euser
is different from either of them.
.pp
Parentheses, angle brackets, and double quotes
must be properly balanced and nested.
The rewriting rules control remaining parsing\**.
.(f
\**Disclaimer: Some special processing is done
after rewriting local names; see below.
.)f
.sh 2 "Mail to Files and Programs"
.pp
Files and programs are legitimate message recipients.
Files provide archival storage of messages,
useful for project administration and history.
Programs are useful as recipients in a variety of situations,
for example,
to maintain a public repository of systems messages
(such as the Berkeley
.i msgs
program,
or the MARS system
[Sattley78]).
.pp
Any address passing through the initial parsing algorithm
as a local address
(i.e, not appearing to be a valid address for another mailer)
is scanned for two special cases.
If prefixed by a vertical bar (\c
.q \^|\^ )
the rest of the address is processed as a shell command.
If the user name begins with a slash mark (\c
.q /\^ )
the name is used as a file name,
instead of a login name.
.pp
Files that have setuid or setgid bits set
but no execute bits set
have those bits honored if
.i sendmail
is running as root.
.sh 2 "Aliasing, Forwarding, Inclusion"
.pp
.i Sendmail
reroutes mail three ways.
Aliasing applies system wide.
Forwarding allows each user to reroute incoming mail
destined for that account.
Inclusion directs
.i sendmail
to read a file for a list of addresses,
and is normally used
in conjunction with aliasing.
.sh 3 "Aliasing"
.pp
Aliasing maps names to address lists using a system-wide file.
This file is indexed to speed access.
Only names that parse as local
are allowed as aliases;
this guarantees a unique key
(since there are no nicknames for the local host).
.sh 3 "Forwarding"
.pp
After aliasing,
recipients that are local and valid
are checked for the existence of a
.q .forward
file in their home directory.
If it exists,
the message is
.i not
sent to that user,
but rather to the list of users in that file.
Often
this list will contain only one address,
and the feature will be used for network mail forwarding.
.pp
Forwarding also permits a user to specify a private incoming mailer.
For example,
forwarding to:
.(b
"\^|\|/usr/local/newmail myname"
.)b
will use a different incoming mailer.
.sh 3 "Inclusion"
.pp
Inclusion is specified in RFC 733 [Crocker77a] syntax:
.(b
:Include: pathname
.)b
An address of this form reads the file specified by
.i pathname
and sends to all users listed in that file.
.pp
The intent is
.i not
to support direct use of this feature,
but rather to use this as a subset of aliasing.
For example,
an alias of the form:
.(b
project: :include:/usr/project/userlist
.)b
is a method of letting a project maintain a mailing list
without interaction with the system administration,
even if the alias file is protected.
.pp
It is not necessary to rebuild the index on the alias database
when a :include: list is changed.
.sh 2 "Message Collection"
.pp
Once all recipient addresses are parsed and verified,
the message is collected.
The message comes in two parts:
a message header and a message body,
separated by a blank line.
.pp
The header is formatted as a series of lines
of the form
.(b
	field-name: field-value
.)b
Field-value can be split across lines by starting the following
lines with a space or a tab.
Some header fields have special internal meaning,
and have appropriate special processing.
Other headers are simply passed through.
Some header fields may be added automatically,
such as time stamps.
.pp
The body is a series of text lines.
It is completely uninterpreted and untouched,
except that lines beginning with a dot
have the dot doubled
when transmitted over an SMTP channel.
This extra dot is stripped by the receiver.
.sh 2 "Message Delivery"
.pp
The send queue is ordered by receiving host
before transmission
to implement message batching.
Each address is marked as it is sent
so rescanning the list is safe.
An argument list is built as the scan proceeds.
Mail to files is detected during the scan of the send list.
The interface to the mailer
is performed using one of the techniques
described in section 2.2.
.pp
After a connection is established,
.i sendmail
makes the per-mailer changes to the header
and sends the result to the mailer.
If any mail is rejected by the mailer,
a flag is set to invoke the return-to-sender function
after all delivery completes.
.sh 2 "Queued Messages"
.pp
If the mailer returns a
.q "temporary failure"
exit status,
the message is queued.
A control file is used to describe 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 salient parameter of the message.
The header of the message is stored
in the control file,
so that the associated data file in the queue
is just the temporary file that was originally collected.
.sh 2 "Configuration"
.pp
Configuration is controlled primarily by a configuration file
read at startup.
.i Sendmail
should not need to be recomplied except
.np
To change operating systems
(V6, V7/32V, 4BSD).
.np
To remove or insert the DBM
(UNIX database)
library.
.np
To change ARPANET reply codes.
.np
To add headers fields requiring special processing.
.lp
Adding mailers or changing parsing
(i.e., rewriting)
or routing information
does not require recompilation.
.pp
If the mail is being sent by a local user,
and the file
.q .mailcf
exists in the sender's home directory,
that file is read as a configuration file
after the system configuration file.
The primary use of this feature is to add header lines.
.pp
The configuration file encodes macro definitions,
header definitions,
mailer definitions,
rewriting rules,
and options.
.sh 3 Macros
.pp
Macros can be used in three ways.
Certain macros transmit
unstructured textual information
into the mail system,
such as the name
.i sendmail
will use to identify itself in error messages.
Other macros transmit information from
.i sendmail
to the configuration file
for use in creating other fields
(such as argument vectors to mailers);
e.g., the name of the sender,
and the host and user
of the recipient.
Other macros are unused internally,
and can be used as shorthand in the configuration file.
.sh 3 "Header declarations"
.pp
Header declarations inform
.i sendmail
of the format of known header lines.
Knowledge of a few header lines
is built into
.i sendmail ,
such as the
.q From:
and
.q Date:
lines.
.pp
Most configured headers
will be automatically inserted
in the outgoing message
if they don't exist in the incoming message.
Certain headers are suppressed by some mailers.
.sh 3 "Mailer declarations"
.pp
Mailer declarations tell
.i sendmail
of the various mailers available to it.
The definition specifies the internal name of the mailer,
the pathname of the program to call,
some flags associated with the mailer,
and an argument vector to be used on the call;
this vector is macro-expanded before use.
.sh 3 "Address rewriting rules"
.pp
The heart of address parsing in
.i sendmail
is a set of rewriting rules.
These are an ordered list of pattern-replacement rules,
(somewhat like a production system,
except that order is critical),
which are applied to each address.
The address is rewritten textually until it is either rewritten
into a special canonical form
(i.e.,
a (mailer, host, user)
3-tuple,
such as {arpanet, usc-isif, postel}
representing the address
.q "postel@usc-isif" ),
or it falls off the end.
When a pattern matches,
the rule is reapplied until it fails.
.pp
The configuration file also supports the editing of addresses
into different formats.
For example,
an address of the form:
.(b
ucsfcgl!tef
.)b
might be mapped into:
.(b
[e-mail]
.)b
to conform to the domain syntax.
Translations can also be done in the other direction.
.sh 3 "Option setting"
.pp
There are several options that can be set
from the configuration file.
These include the pathnames of various support files,
timeouts,
default modes,
etc.
.sh 1 "COMPARISON WITH OTHER MAILERS"
.sh 2 "Delivermail"
.pp
.i Sendmail
is an outgrowth of
.i delivermail .
The primary differences are:
.np
Configuration information is not compiled in.
This change simplifies many of the problems
of moving to other machines.
It also allows easy debugging of new mailers.
.np
Address parsing is more flexible.
For example,
.i delivermail
only supported one gateway to any network,
whereas
.i sendmail
can be sensitive to host names
and reroute to different gateways.
.np
Forwarding and
:include:
features eliminate the requirement that the system alias file
be writable by any user
(or that an update program be written,
or that the system administration make all changes).
.np
.i Sendmail
supports message batching across networks
when a message is being sent to multiple recipients.
.np
A mail queue is provided in
.i sendmail.
Mail that cannot be delivered immediately
but can potentially be delivered later
is stored in this queue for a later retry.
The queue also provides a buffer against system crashes;
after the message has been collected
it may be reliably redelivered
even if the system crashes during the initial delivery.
.np
.i Sendmail
uses the networking support provided by 4.2BSD
to provide a direct interface networks such as the ARPANET
and/or Ethernet
using SMTP (the Simple Mail Transfer Protocol)
over a TCP/IP connection.
.sh 2 "MMDF"
.pp
MMDF
[Crocker79]
spans a wider problem set than
.i sendmail .
For example,
the domain of
MMDF includes a
.q "phone network"
mailer, whereas
.i sendmail
calls on preexisting mailers in most cases.
.pp
MMDF and
.i sendmail
both support aliasing,
customized mailers,
message batching,
automatic forwarding to gateways,
queueing,
and retransmission.
MMDF supports two-stage timeout,
which
.i sendmail
does not support.
.pp
The configuration for MMDF
is compiled into the code\**.
.(f
\**Dynamic configuration tables are currently being considered
for MMDF;
allowing the installer to select either compiled
or dynamic tables.
.)f
.pp
Since MMDF does not consider backwards compatibility
as a design goal,
the address parsing is simpler but much less flexible.