op.me

来自「< linux网络编程工具>>配套源码」· ME 代码 · 共 2,453 行 · 第 1/5 页

.)b
This information may be flushed with the command:
.(b
sendmail \-bH
.)b
Flushing the information prevents new
.i sendmail
processes from loading it,
but does not prevent existing processes from using the status information
that they already have.
.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 "O Timeout.queuereturn=5d"
sets option
.q Timeout.queuereturn
to the value
.q 5d
(five days).
.pp
Most of these options have appropriate defaults for most sites.
However,
sites having very high mail loads may find they need to tune them
as appropriate for their mail 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.
.pp
All versions of
.i sendmail
prior to 8.7
had single character option names.
As of 8.7,
options have long (multi-character names).
Although old short names are still accepted,
most new options do not have short equivalents.
.pp
This section only describes the options you are most likely
to want to tweak;
read section
.\"XREF
5
for more details.
.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 sub-daemon will run the queue.
This is typically set to between fifteen minutes
and one hour.
If not set,
or set to zero,
the queue will not be run automatically.
RFC 1123 section 5.3.1.1 recommends that this be at least 30 minutes.
.sh 3 "Read timeouts"
.pp
Timeouts all have option names
.q Timeout.\fIsuboption\fP .
The recognized
.i suboption s,
their default values, and the minimum values
allowed by RFC 1123 section 5.3.2 are:
.nr ii 1i
.ip connect
The time to wait for an SMTP connection to open
(the
.i connect (2)
system call)
[0, unspecified].
If zero, uses the kernel default.
In no case can this option extend the timeout
longer than the kernel provides, but it can shorten it.
This is to get around kernels that provide an absurdly long connection timeout
(90 minutes in one case).
.ip iconnect
The same as
.i connect,
except it applies only to the initial attempt to connect to a host
for a given message
[0, unspecified].
The concept is that this should be very short (a few seconds);
hosts that are well connected and responsive will thus be serviced immediately.
Hosts that are slow will not hold up other deliveries in the initial
delivery attempt.
.ip initial
The wait for the initial 220 greeting message
[5m, 5m].
.ip helo
The wait for a reply from a HELO or EHLO command
[5m, unspecified].
This may require a host name lookup, so
five minutes is probably a reasonable minimum.
.ip mail\(dg
The wait for a reply from a MAIL command
[10m, 5m].
.ip rcpt\(dg
The wait for a reply from a RCPT command
[1h, 5m].
This should be long
because it could be pointing at a list
that takes a long time to expand
(see below).
.ip datainit\(dg
The wait for a reply from a DATA command
[5m, 2m].
.ip datablock\(dg\(dd
The wait for reading a data block
(that is, the body of the message).
[1h, 3m].
This should be long because it also applies to programs
piping input to
.i sendmail
which have no guarantee of promptness.
.ip datafinal\(dg
The wait for a reply from the dot terminating a message.
[1h, 10m].
If this is shorter than the time actually needed
for the receiver to deliver the message,
duplicates will be generated.
This is discussed in RFC 1047.
.ip rset
The wait for a reply from a RSET command
[5m, unspecified].
.ip quit
The wait for a reply from a QUIT command
[2m, unspecified].
.ip misc
The wait for a reply from miscellaneous (but short) commands
such as NOOP (no-operation) and VERB (go into verbose mode).
[2m, unspecified].
.ip command\(dg\(dd
In server SMTP,
the time to wait for another command.
[1h, 5m].
.ip ident\(dd
The timeout waiting for a reply to an IDENT query
[30s\**, unspecified].
.(f
\**On some systems the default is zero to turn the protocol off entirely.
.)f
.ip fileopen\(dd
The timeout for opening .forward and :include: files [60s, none].
.ip control\(dd
The timeout for a complete control socket transaction to complete [2m, none].
.ip hoststatus\(dd
How long status information about a host
(e.g., host down)
will be cached before it is considered stale
[30m, unspecified].
.ip resolver.retrans
The resolver's
retransmission time interval
(in seconds)
[varies].
Sets both
.i Timeout.resolver.retrans.first
and
.i Timeout.resolver.retrans.normal .
.ip resolver.retrans.first
The resolver's
retransmission time interval
(in seconds)
for the first attempt to
deliver a message
[varies].
.ip resolver.retrans.normal
The resolver's
retransmission time interval
(in seconds)
for all resolver lookups
except the first delivery attempt
[varies].
.ip resolver.retry
The number of times
to retransmit a resolver query.
Sets both
.i Timeout.resolver.retry.first
and
.i Timeout.resolver.retry.normal
[varies].
.ip resolver.retry.first
The number of times
to retransmit a resolver query
for the first attempt
to deliver a message
[varies].
.ip resolver.retry.normal
The number of times
to retransmit a resolver query
for all resolver lookups
 except the first delivery attempt
[varies].
.lp
For compatibility with old configuration files,
if no
.i suboption
is specified,
all the timeouts marked with a dagger (\(dg) are set to the indicated value.
All but those marked with a double dagger (\(dd) apply to client SMTP.
.pp
Many of the RFC 1123 minimum values
may well be too short.
.i Sendmail
was designed to the RFC 822 protocols,
which did not specify read timeouts;
hence, versions of
.i sendmail
prior to version 8.1 did not guarantee to reply to messages promptly.
In particular, a
.q RCPT
command specifying a mailing list
will expand and verify the entire list;
a large list on a slow system
may easily take more than five minutes\**.
.(f
\**This verification includes looking up every address
with the name server;
this involves network delays,
and can in some cases can be considerable.
.)f
I recommend a one hour timeout \*-
since a communications failure during the RCPT phase is rare,
a long timeout is not onerous
and may ultimately help reduce network load
and duplicated messages.
.pp
For example, the lines:
.(b
O Timeout.command=25m
O Timeout.datablock=3h
.)b
sets the server SMTP command timeout to 25 minutes
and the input data block timeout to three hours.
.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 five days.
It is sometimes considered convenient to also send a warning message
if the message is in the queue longer than a few hours
(assuming you normally have good connectivity;
if your messages normally took several hours to send
you wouldn't want to do this because it wouldn't be an unusual event).
These timeouts are set using the
.b Timeout.queuereturn
and
.b Timeout.queuewarn
options in the configuration file
(previously both were set using the
.b T
option).
.pp
If the message is submitted using the
.sm NOTIFY
.sm SMTP
extension,
warning messages will only be sent if
.sm 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
.q urgent
(indicating a positive non-zero precedence)
.q normal
(indicating a zero precedence), or
.q non-urgent
(indicating negative precedences).
For example, setting
.q 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,
e.g., to bounce messages independent of their time in the queue.
.pp
Since these options are global,
and since you can not know
.i "a priori"
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''.
.pp
The
.b Timeout.queuewarn
value can be piggybacked on the
.b 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
.(b
OT5d/4h
.)b
causes 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.
.sh 2 "Forking During Queue Runs"
.pp
By setting the
.b ForkEachJob
(\c
.b Y )
option,
.i sendmail
will fork before each individual message
while running the queue.
This will prevent
.i sendmail
from consuming large amounts of memory,
so it may be useful in memory-poor environments.
However, if the
.b ForkEachJob
option is not set,
.i sendmail
will keep track of hosts that are down during a queue run,
which can improve performance dramatically.
.pp
If the
.b ForkEachJob
option is set,
.i sendmail
can not use connection caching.
.sh 2 "Queue Priorities"
.pp
Every message is assigned a priority when it is first instantiated,
consisting of the message size (in bytes)
offset by the message class
(which is determined from the Precedence: header)
times the
.q "work class factor"
and the number of recipients times the
.q "work recipient factor."
The priority is used to order the queue.
Higher numbers for the priority mean that the message will be processed later
when running the queue.
.pp
The message size is included so that large messages are penalized
relative to small messages.
The message class allows users to send
.q "high priority"
messages by including a
.q Precedence:
field in their message;
the value of this field is looked up in the
.b P
lines of the configuration file.
Since the number of recipients affects the amount of load a message presents
to the system,
this is also included into the priority.
.pp
The recipient and class factors
can be set in the configuration file using the
.b RecipientFactor
(\c
.b y )
and
.b ClassFactor
(\c
.b z )
options respectively.
They default to 30000 (for the recipient factor)
and 1800
(for the class factor).
The initial priority is:
.EQ
pri = msgsize - (class times bold ClassFactor) + (nrcpt times bold RecipientFactor)
.EN
(Remember, higher values for this parameter actually mean
that the job will be treated with lower priority.)
.pp
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
.q "work time factor,"
set by the
.b RetryFactor
(\c
.b 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
will tend to fail again in the future.
The
.b RetryFactor
option defaults to 90000.
.sh 2 "Load Limiting"
.pp
.i Sendmail
can be asked to queue (but not deliver)
mail if the system load average gets too high
using the
.b QueueLA
(\c
.b x )
option.
When the load average exceeds the value of the
.b QueueLA
option,
the delivery mode is set to
.b q
(queue only)
if the
.b QueueFactor
(\c
.b q )
option divided by the difference in the current load average and the
.b QueueLA
option
plus one
exceeds the priority of the message \(em
that is, the message is queued iff:
.EQ
pri > { bold QueueFactor } over { LA - { bold QueueLA } + 1 }
.EN
The
.b QueueFactor
option defaults to 600000,
so each point of load average is worth 600000
priority points
(as described above).
.pp
For drastic cases,
the
.b RefuseLA
(\c
.b X )
option defines a load average at which
.i sendmail
will refuse
to accept network connections.
Locally generated mail
(including incoming UUCP mail)
is still accepted.
.sh 2 "Delivery Mode"
.pp
There are a number of delivery modes that
.i sendmail
can operate in,
set by the
.b DeliveryMode
(\c
.b 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 backgro