Timeouts
All time intervals are set using a scaled syntax. For example,
10m
represents ten minutes, whereas 2h30m
represents
two and a half hours. The full set of scales is:
s-
seconds
m-
minutes
h-
hours
d-
days
w-
weeks
Queue interval
The argument to the -q flag specifies how often a sub-daemon
will run the queue. This is typically set to between fifteen minutes
and one hour. RFC1123 section 5.3.1.1 recommends that this be
at least 30 minutes.
Read timeouts
Timeouts all have option names Timeout.suboption.
The recognized suboptions, their default values, and the minimum values
allowed by RFC1123 section 5.3.2 are:
connect-
The time to wait for an SMTP connection to open (the
connect(3sock)
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).
iconnect-
The same as 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.
initial-
The wait for the initial 220 greeting message [5m, 5m].
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.
mail[1]-
The wait for a reply from a MAIL command [10m, 5m].
rcpt[1]-
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.
datainit[1]-
The wait for a reply from a DATA command [5m, 2m].
datablock[1][2]-
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 sendmail which have no guarantee of
promptness.
datafinal[1]-
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 RFC1047.
rset-
The wait for a reply from a RSET command [5m, unspecified].
quit-
The wait for a reply from a QUIT command [2m, unspecified].
misc-
The wait for a reply from miscellaneous (but short) commands such as
NOOP (no-operation) and VERB (go into verbose mode)
[2m, unspecified].
command[1]-
In server SMTP, the time to wait for another command [1h, 5m].
ident[2]-
The timeout waiting for a reply to an IDENT query [30s,
unspecified]. On some systems the default is zero to turn the protocol
off entirely.
fileopen[2]-
The timeout for opening .forward and :include:
files [60s, none].
control[2]-
The timeout for a complete control socket transaction to complete [2m, none].
hoststatus[2]-
How long status information about a host (e.g., host down)
will be cached before it is considered stale [30m, unspecified].
resolver.retrans-
The resolver's retransmission time interval (in seconds)
[varies]. Sets both Timeout.resolver.retrans.first
and Timeout.resolver.retrans.normal.
resolver.retrans.first-
The resolver's retransmission time interval
(in seconds) for the first attempt to
deliver a message [varies].
resolver.retrans.normal-
The resolver's retransmission time interval
(in seconds) for all resolver lookups
except the first delivery attempt [varies].
resolver.retry-
The number of times to retransmit a resolver query.
Sets both Timeout.resolver.retry.first
and Timeout.resolver.retry.normal [varies].
resolver.retry.first-
The number of times to retransmit a resolver query
for the first attempt to deliver a message [varies].
resolver.retry.normal-
The number of times to retransmit a resolver query
for all resolver lookups except the first delivery attempt [varies].
Footnotes:
[1]-
For compatibility with old configuration files, if no suboption is
specified, this timeout is set to the indicated value.
[2]-
This timeout applies to client SMTP.
Many of the RFC1123 minimum values may well be too short.
sendmail was designed to the RFC822 protocols,
which did not specify read timeouts; hence, versions of
sendmail prior to version 8.1 did not guarantee to reply to
messages promptly. In particular, a 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.
NOTE:
This verification includes looking up every address with the name
server; this involves network delays, and can in some cases can be
considerable.
SCO recommends 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.
For example, the lines:
O Timeout.command=25m
O Timeout.datablock=3h
sets the server SMTP command timeout to 25 minutes and the
input data block timeout to three hours.
Message timeouts
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 Timeout.queuereturn and
Timeout.queuewarn options in the configuration file (previously
both were set using the T option).
If the message is submitted using the NOTIFY
SMTP extension, warning messages will only be sent if
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 ``urgent''
(indicating a positive non-zero precedence),
``normal'' (indicating a zero precedence), or
``non-urgent'' (indicating negative precedences).
For example, setting 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
(for example, to bounce messages independent of their time in the queue).
Since these options are global, and since you can not know 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. RFC1123 section 5.3.1.1
says that this parameter should be ``at least 4-5 days''.
The Timeout.queuewarn value can be piggybacked on the
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:
OT5d/4h
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.
© 2000 The Santa Cruz Operation, Inc. All rights reserved.