op.me

早期freebsd实现

command specifying a mailing list
will expand and verify the entire list;
a large list on a slow system
may 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 this failure is rare,
a long timeout is not onerous
and may ultimately help reduce network load.
.pp
For example, the line:
.(b
Orcommand=25m,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 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/\*(SD/sendmail \-oT1d \-q
.)b
will run the queue
and flush anything that is one day old.
.pp
Since this option is global,
and since you can not
.i "a priori"
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.
RFC 1123 section 5.3.1.1 says that this parameter
should be ``at least 4\-5 days''.
.pp
The
.b T
option can also take a second timeout indicating a time after which
a warning message should be sent;
the two timeouts are separated by a slash.
For example, the value
.(b
5d/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 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 Y
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 Y
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 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 y
and
.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 z) + (nrcpt times bold y)
.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 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 Z
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 x
option.
When the load average exceeds the value of the
.b x
option,
the delivery mode is set to
.b q
(queue only)
if the
.i "Queue Factor"
(\c
.b q
option)
divided by the difference in the current load average and the
.b x
option
plus one
exceeds the priority of the message \(em
that is, the message is queued iff:
.EQ
pri > { bold q } over { LA - { bold x } + 1 }
.EN
The
.b q
option defaults to 600000,
so each point of load average is worth 600000
priority points
(as described above).
.pp
For drastic cases,
the
.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
.q 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 background (asynchronously)
q	queue only (don't deliver)
.)b
There are tradeoffs.
Mode
.q i
passes the maximum amount of information to the sender,
but is hardly ever necessary.
Mode
.q q
puts the minimum load on your machine,
but means that delivery may be delayed for up to the queue interval.
Mode
.q b
is probably a good compromise.
However, this mode can cause large numbers of processes
if you have a mailer that takes a long time to deliver a message.
.pp
If you run in mode
.q q
(queue only)
or
.q b
(deliver in background)
.i sendmail
will not expand aliases and follow .forward files
upon initial receipt of the mail.
This speeds up the response to RCPT commands.
.sh 2 "Log Level"
.pp
The level of logging can be set for
.i sendmail .
The default using a standard configuration table is level 9.
The levels are as follows:
.nr ii 0.5i
.ip 0
No logging.
.ip 1
Serious system failures and potential security problems.
.ip 2
Lost communications (network problems) and protocol failures.
.ip 3
Other serious failures.
.ip 4
Minor failures.
.ip 5
Message collection statistics.
.ip 6
Creation of error messages,
VRFY and EXPN commands.
.ip 7
Delivery failures (host or user unknown, etc.).
.ip 8
Successful deliveries.
.ip 9
Messages being deferred
(due to a host being down, etc.).
.ip 10
Database expansion (alias, forward, and userdb lookups).
.ip 15
Automatic alias database rebuilds.
.ip 20
Logs attempts to run locked queue files.
These are not errors,
but can be useful to note if your queue appears to be clogged.
.ip 30
Lost locks (only if using lockf instead of flock).
.lp
Additionally,
values above 64 are reserved for extremely verbose debuggging output.
No normal site would ever set these.
.sh 2 "File Modes"
.pp
There are a number of files
that may have a number of modes.
The modes depend on what functionality you want
and the level of security you require.
.sh 3 "To suid or not to suid?"
.pp
.i Sendmail
can safely be made
setuid to root.
At the point where it is about to
.i exec \|(2)
a mailer,
it checks to see if the userid is zero;
if so,
it resets the userid and groupid to a default
(set by the
.b u
and
.b g
options).
(This can be overridden
by setting the
.b S
flag to the mailer
for mailers that are trusted
and must be called as root.)
However,
this will cause mail processing
to be accounted
(using
.i sa \|(8))
to root
rather than to the user sending the mail.
.sh 3 "Should my alias database be writable?"
.pp
At Berkeley
we have the alias database
(/etc/aliases*)
mode 644.
While this is not as flexible as if the database
were more 666, it avoids potential security problems
with a globally writable database.
.pp
The database that
.i sendmail
actually used
is represented by the two files
.i aliases.dir
and
.i aliases.pag
(both in /etc)
(or
.i aliases.db
if you are running with the new Berkeley database primitives).
The mode on these files should match the mode
on /etc/aliases.
If
.i aliases
is writable
and the
DBM
files
(\c
.i aliases.dir
and
.i aliases.pag )
are not,
users will be unable to reflect their desired changes
through to the actual database.
However,
if
.i aliases
is read-only
and the DBM files are writable,
a slightly sophisticated user
can arrange to steal mail anyway.
.pp
If your DBM files are not writable by the world
or you do not have auto-rebuild enabled
(with the
.q D
option),
then you must be careful to reconstruct the alias database
each time you change the text version:
.(b
newaliases
.)b
If this step is ignored or forgotten
any intended changes will also be ignored or forgotten.
.sh 2 "Connection Caching"
.pp
When processing the queue,
.i sendmail
will try to keep the last few open connections open
to avoid startup and shutdown costs.
This only applies to IPC connections.
.pp
When trying to open a connection
the cache is first searched.
If an open connection is found, it is probed to see if it is still active
by sending a
.sm NOOP
command.
It is not an error if this fails;
instead, the connection is closed and reopened.
.pp
Two parameters control the connection cache.
The
.b k
option defines the number of simultaneous open connections
that will be permitted.
If it is set to zero,
connections will be closed as quickly as possible.
The default is one.
This should be set as appropriate for your system size;
it will limit the amount of system resources that
.i sendmail
will use during queue runs.
.pp
The
.b K
option specifies the maximum time that any cached connection
will be permitted to idle.
When the idle time exceeds this value
the connection is closed.
This number should be small
(under ten minutes)
to prevent you from grabbing too many resources
from other hosts.
The default is five minutes.
.sh 2 "Name Server Access"
.pp
If your system supports the name server,
then the probability is that
.i sendmail
will be using it regardless of how you configure
.i sendmail .
In particular, the system routine
.i gethostbyname (3)
is used to look up host names,
and most vendor versions try some combination of DNS, NIS,
and file lookup in /etc/hosts.
.pp
However, if you do not have a nameserver configured at all,
such as at a UUCP-only site,
.i sendmail
will get a
.q "connection refused"
message when it tries to connect to the name server
(either indirectly by calling
.i gethostbyname
or directly by looking up MX records).
If the
.b I
option is set,
.i sendmail
will interpret this to mean a temporary failure
and will queue the mail for later processing;
otherwise, it ignores the name server data.
If your name server is running properly,
the setting of this option is not relevant;
however, it is important that it be set properly
to make error handling work properly.
.pp
This option also allows you to tweak name server options.
The command line takes a series of flags as documented in
.i resolver (3)
(with the leading
.q RES_
deleted).
Each can be preceded by an optional `+' or `\(mi'.
For example, the line
.(b
OITrue +AAONLY \(miDNSRCH
.)b
turns on the AAONLY (accept authoritative answers only)
and turns off the DNSRCH (search the domain path) options.
Most resolver libraries default DNSRCH, DEFNAMES, and RECURSE
flags on and all others off.
Note the use of the initial ``True'' \*-
this is for compatibility with previous versions of
.i sendmail ,
but is not otherwise necessary.
.pp
Version level 1 configurations
turn DNSRCH and DEFNAMES off when doing delivery lookups,
but leave them on everywhere else.
Version 8 of
.i sendmail
ignores them when doing canonification lookups
(that is, when using $[ ... $]),
and always does the search.
If you don't want to do automatic name extension,
don't call $[ ... $].
.pp
The search rules for $[ ... $] are somewhat different than usual.
If the name (that is, the ``...'')
has at least one dot, it always tries the unmodified name first.
If that fails, it tries the reduced search path,
and lastly tries the unmodified name
(but only for names without a dot,
since names with a dot have already been tried).
This allows names such as
``utc.CS''
to match the site in Czechoslovakia
rather than the site in your local Computer Science department.
It also prefers A and CNAME records over MX records \*-
that is, if it finds an MX record it makes note of it,
but keeps looking.
This way, if you have a wildcard MX record matching your domain,
it will not assume that all names match.
.sh 2 "Moving the Per-User Forward Files"
.pp
Some sites mount each user's home directory
from a local disk on their workstation,
so that local access is fast.
However, the result is that .forward file lookups are slow.
In some cases,
mail can even be delivered on machines inappropriately
because of a file server being down.
The performance can be especially bad if you run the automounter.
.pp
The
.b J
option allows you to set a path of forward files.
For example, the config file line
.(b
OJ/var/forward/$u:$z/.forward
.)b
would first look for a file with the same name as the user's login
in /var/forward;
if that is not found (or is inaccessible)
the file
.q \&.forward
in the user's home directory is searched.
A truly perverse site could also search by sender
by using $r, $s, or $f.
.pp
If you create a directory such as /var/forward,
it should be mode 1777
(that is, the sticky bit should be set).
Users should create the files mode 644.
.sh 2 "Free Space"
.pp
On systems that have the
.i statfs (2)
system call,
you can specify a minimum number of free blocks on the queue filesystem
using the
.b b
option.
If there are fewer than the indicated number of blocks free