op.me

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

(it will not even time out!).
.ip n
This file is created when an id is being created.
It is a separate file to insure that no mail can ever be destroyed
due to a race condition.
It should exist for no more than a few milliseconds
at any given time.
.ip q
The queue control file.
This file contains the information necessary to process the job.
.ip t
A temporary file.
These are an image of the
.b qf
file when it is being rebuilt.
It should be renamed to a
.b qf
file very quickly.
.ip x
A transcript file,
existing during the life of a session
showing everything that happens
during that session.
.pp
The
.b qf
file is structured as a series of lines
each beginning with a code letter.
The lines are as follows:
.ip D
The name of the data file.
There may only be one of these lines.
.ip H
A header definition.
There may be any number of these lines.
The order is important:
they represent the order in the final message.
These use the same syntax
as header definitions in the configuration file.
.ip R
A recipient address.
This will normally be completely aliased,
but is actually realiased when the job is processed.
There will be one line
for each recipient.
.ip S
The sender address.
There may only be one of these lines.
.ip T
The job creation time.
This is used to compute when to time out the job.
.ip P
The current message priority.
This is used to order the queue.
Higher numbers mean lower priorities.
The priority increases
as the message sits in the queue.
The initial priority depends on the message class
and the size of the message.
.ip M
A message.
This line is printed by the
.i mailq
command,
and is generally used to store status information.
It can contain any text.
.pp
As an example,
the following is a queue file sent to
.q mckusick@calder
and
.q wnj :
.(b
DdfA13557
Seric
T404261372
P132
Rmckusick@calder
Rwnj
H?D?date: 23-Oct-82 15:49:32-PDT (Sat)
H?F?from: eric (Eric Allman)
H?x?full-name: Eric Allman
Hsubject: this is an example message
Hmessage-id: <[e-mail]>
Hreceived: by UCBARPA.BERKELEY.ARPA (3.227 [10/22/82])
	id A13557; 23-Oct-82 15:49:32-PDT (Sat)
Hphone: [phone]
HTo: mckusick@calder, wnj
.)b
This 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.
.sh 3 "Forcing the queue"
.pp
.i Sendmail
should run the queue automatically
at intervals.
The algorithm is to read and sort the queue,
and then to attempt to process all jobs in order.
When it attempts to run the job,
.i sendmail
first checks to see if the job is locked.
If so, it ignores the job.
.pp
There is no attempt to insure that only one queue processor
exists at any time,
since there is no guarantee that a job cannot take forever
to process.
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 way to resolve this
without violating the protocol.
.pp
In some cases,
you may find that a major host going down
for a couple of days
may create a prohibitively large queue.
This will result in
.i sendmail
spending 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.
.pp
To do this,
it is acceptable to move the entire queue directory:
.(b
cd /usr/spool
mv mqueue omqueue; mkdir mqueue; chmod 777 mqueue
.)b
You should then kill the existing daemon
(since it will still be processing in the old queue directory)
and create a new daemon.
.pp
To run the old mail queue,
run the following command:
.(b
/usr/lib/sendmail \-oQ/usr/spool/omqueue \-q
.)b
The
.b \-oQ
flag specifies an alternate queue directory
and the
.b \-q
flag says to just run every job in the queue.
If you have a tendency toward voyeurism,
you can use the
.b \-v
flag to watch what is going on.
.pp
When the queue is finally emptied,
you can remove the directory:
.(b
rmdir /usr/spool/omqueue
.)b
.sh 2 "The Alias Database"
.pp
The alias database exists in two forms.
One is a text form,
maintained in the file
.i /usr/lib/aliases.
The aliases are of the form
.(b
name: name1, name2, ...
.)b
Only local names may be aliased;
e.g.,
.(b
eric@mit-xx: eric@berkeley
.)b
will not have the desired effect.
Aliases may be continued by starting any continuation lines
with a space or a tab.
Blank lines and lines beginning with a sharp sign
(\c
.q # )
are comments.
.pp
The second form is processed by the
.i dbm \|(3)
library.
This form is in the files
.i /usr/lib/aliases.dir
and
.i /usr/lib/aliases.pag.
This is the form that
.i sendmail
actually uses to resolve aliases.
This technique is used to improve performance.
.sh 3 "Rebuilding the alias database"
.pp
The DBM version of the database
may be rebuilt explicitly by executing the command
.(b
newaliases
.)b
This is equivalent to giving
.i sendmail
the
.b \-bi
flag:
.(b
/usr/lib/sendmail \-bi
.)b
.pp
If the
.q D
option is specified in the configuration,
.i sendmail
will rebuild the alias database automatically
if possible
when it is out of date.
The conditions under which it will do this are:
.np
The DBM version of the database is mode 666.   -or-
.np
.i Sendmail
is running setuid to root.
.lp
Auto-rebuild can be dangerous
on heavily loaded machines
with large alias files;
if it might take more than five minutes
to rebuild the database,
there is a chance that several processes will start the rebuild process
simultaneously.
.sh 3 "Potential problems"
.pp
There are a number of problems that can occur
with the alias database.
They all result from a
.i sendmail
process accessing the DBM version
while it is only partially built.
This can happen under two circumstances:
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.
.pp
Sendmail has two techniques to try to relieve these problems.
First, it ignores interrupts while rebuilding the database;
this avoids the problem of someone aborting the process
leaving a partially rebuilt database.
Second,
at the end of the rebuild
it adds an alias of the form
.(b
@: @
.)b
(which is not normally legal).
Before sendmail will access the database,
it checks to insure that this entry exists\**.
.(f
\**The
.q a
option is required in the configuration
for this action to occur.
This should normally be specified
unless you are running
.i delivermail
in parallel with
.i sendmail.
.)f
It will wait up to five minutes
for this entry to appear,
at which point it will force a rebuild itself\**.
.(f
\**Note:
the
.q D
option must be specified in the configuration file
for this operation to occur.
.)f
.sh 3 "List owners"
.pp
If an error occurs on sending to a certain address,
say
.q \fIx\fP ,
.i sendmail
will look for an alias
of the form
.q owner-\fIx\fP
to receive the errors.
This is typically useful
for a mailing list
where the submitter of the list
has no control over the maintanence of the list itself;
in this case the list maintainer would be the owner of the list.
For example:
.(b
unix-wizards: eric@ucbarpa, wnj@monet, nosuchuser,
	sam@matisse
owner-unix-wizards: eric@ucbarpa
.)b
would cause
.q eric@ucbarpa
to get the error that will occur
when someone sends to
unix-wizards
due to the inclusion of
.q nosuchuser
on the list.
.sh 2 "Per-User Forwarding (.forward Files)"
.pp
As an alternative to the alias database,
any user may put a file with the name
.q .forward
in his or her home directory.
If this file exists,
.i sendmail
redirects mail for that user
to the list of addresses listed in the .forward file.
For example, if the home directory for user
.q mckusick
has a .forward file with contents:
.(b
mckusick@ernie
kirk@calder
.)b
then any mail arriving for
.q mckusick
will be redirected to the specified accounts.
.sh 2 "Special Header Lines"
.pp
Several header lines have special interpretations
defined by the configuration file.
Others have interpretations built into
.i sendmail
that cannot be changed without changing the code.
These builtins are described here.
.sh 3 "Return-Receipt-To:"
.pp
If this header is sent,
a message will be sent to any specified addresses
when the final delivery is complete.
if the mailer has the
.b l
flag (local delivery) set in the mailer descriptor.
.sh 3 "Errors-To:"
.pp
If errors occur anywhere during processing,
this header will cause error messages to go to
the listed addresses
rather than to the sender.
This is intended for mailing lists.
.sh 3 "Apparently-To:"
.pp
If a message comes in with no recipients listed in the message
(in a To:, Cc:, or Bcc: line)
then
.i sendmail
will add an
.q "Apparently-To:"
header line for any recipients it is aware of.
This is not put in as a standard recipient line
to warn any recipients that the list is not complete.
.pp
At least one recipient line is required under RFC 822.
.sh 1 "ARGUMENTS"
.pp
The complete list of arguments to
.i sendmail
is described in detail in Appendix A.
Some important arguments are described here.
.sh 2 "Queue Interval"
.pp
The amount of time between forking a process
to run through the queue
is defined by the
.b \-q
flag.
If you run in mode
.b f
or
.b a
this can be relatively large,
since it will only be relevant
when a host that was down comes back up.
If you run in
.b q
mode
it should be relatively short,
since it defines the maximum amount of time that a message
may sit in the queue.
.sh 2 "Daemon Mode"
.pp
If you allow incoming mail over an IPC connection,
you should have a daemon running.
This should be set by your
.i /etc/rc
file using the
.b \-bd
flag.
The
.b \-bd
flag and the
.b \-q
flag may be combined in one call:
.(b
/usr/lib/sendmail \-bd \-q30m
.)b
.sh 2 "Forcing the Queue"
.pp
In some cases you may find that the queue has gotten clogged for some reason.
You can force a queue run
using the
.b \-q
flag (with no value).
It is entertaining to use the
.b \-v
flag (verbose)
when this is done to watch what happens:
.(b
/usr/lib/sendmail \-q \-v
.)b
.sh 2 "Debugging"
.pp
There are a fairly large number of debug flags
built into
.i sendmail .
Each debug flag has a number and a level,
where higher levels means to print out more information.
The convention is that levels greater than nine are
.q absurd,
i.e.,
they print out so much information that you wouldn't normally
want to see them except for debugging that particular piece of code.
Debug flags are set using the
.b \-d
option;
the syntax is:
.(b
.ta \w'debug-option  'u
debug-flag:	\fB\-d\fP debug-list
debug-list:	debug-option [ , debug-option ]
debug-option:	debug-range [ . debug-level ]
debug-range:	integer | integer \- integer
debug-level:	integer
.)b
where spaces are for reading ease only.
For example,
.(b
\-d12	Set flag 12 to level 1
\-d12.3	Set flag 12 to level 3
\-d3-17	Set flags 3 through 17 to level 1
\-d3-17.4	Set flags 3 through 17 to level 4
.)b
For a complete list of the available debug flags
you will have to look at the code
(they are too dynamic to keep this documentation up to date).
.sh 2 "Trying a Different Configuration File"
.pp
An alternative configuration file
can be specified using the
.b \-C
flag; for example,
.(b
/usr/lib/sendmail \-Ctest.cf
.)b
uses the configuration file
.i test.cf
instead of the default
.i /usr/lib/sendmail.cf.
If the
.b \-C
flag has no value
it defaults to
.i sendmail.cf
in the current directory.
.sh 2 "Changing the Values of Options"
.pp
Options can be overridden using the
.b \-o
flag.
For example,
.(b
/usr/lib/sendmail \-oT2m
.)b
sets the
.b T
(timeout) option to two minutes
for this run only.
.sh 1 "TUNING"
.pp
There are a number of configuration parameters
you may want to change,
depending on the requirements of your site.
Most of these are set
using an option in the configuration file.
For example,
the line
.q OT3d
sets option
.q T
to the value
.q 3d
(three days).
.sh 2 "Timeouts"
.pp
All time intervals are set
using a scaled syntax.
For example,
.q 10m
represents ten minutes, whereas
.q 2h30m
represents two and a half hours.
The full set of scales is:
.(b
.ta 4n
s	seconds
m	minutes
h	hours
d	days
w	weeks
.)b
.sh 3 "Queue interval"
.pp
The argument to the
.b \-q
flag
specifies how often a subdaemon will run the queue.
This is typically set to between five minutes
and one half hour.
.sh 3 "Read timeouts"
.pp
It is possible to time out when reading the standard input
or when reading from a remote SMTP server.
Technically,
this is not acceptable within the published protocols.
However,
it might be appropriate to set it to something large
in certain environments
(such as an hour).
This will reduce the chance of large numbers of idle daemons
piling up on your system.
This timeout is set using the
.b r
option in the configuration file.
.sh 3 "Message timeouts"
.pp
After sitting in the queue for a few days,
a message will time out.
This is to insure that at least the sender is aware
of the inability to send a message.
The timeout is typically set to three days.
This timeout is set using the
.b T
option in the configuration file.
.pp
The time of submission is set in the queue,
rather than the amount of time left until timeout.
As a result, you can flush messages that have been hanging
for a short period
by running the queue
with a short message timeout.
For example,
.(b
/usr/lib/sendmail \-oT1d \-q
.)b
will run the queue
and flush anything that is one day old.
.sh 2 "Delivery Mode"
.pp
There are a number of delivery modes that