op.me

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

owner-unix-wizards: unix-wizards-request
unix-wizards-request: 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.
.pp
List owners also cause the envelope sender address to be modified.
The contents of the owner alias are used if they point to a single user,
otherwise the name of the alias itself is used.
For this reason, and to obey Internet conventions,
the
.q owner-
address normally points at the
.q -request
address; this causes messages to go out with the typical Internet convention
of using ``\c
.i list -request''
as the return address.
.sh 2 "User Information Database"
.pp
If you have a version of
.i sendmail
with the user information database
compiled in,
and you have specified one or more databases using the
.b U
option,
the databases will be searched for a
.i user :maildrop
entry.
If found, the mail will be sent to the specified address.
.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.
Note that aliases are fully expanded before forward files are referenced.
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.
.pp
Actually, the configuration file defines a sequence of filenames to check.
By default, this is the user's .forward file,
but can be defined to be more generally using the
.b ForwardPath
option.
If you change this,
you will have to inform your user base of the change;
\&.forward is pretty well incorporated into the collective subconscious.
.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 "Errors-To:"
.pp
If errors occur anywhere during processing,
this header will cause error messages to go to
the listed addresses.
This is intended for mailing lists.
.pp
The Errors-To: header was created in the bad old days
when UUCP didn't understand the distinction between an envelope and a header;
this was a hack to provide what should now be passed
as the envelope sender address.
It should go away.
It is only used if the
.b UseErrorsTo
option is set.
.pp
The Errors-To: header is officially deprecated
and will go away in a future release.
.sh 3 "Apparently-To:"
.pp
RFC 822 requires at least one recipient field
(To:, Cc:, or Bcc: line)
in every message.
If a message comes in with no recipients listed in the message
then
.i sendmail
will adjust the header based on the
.q NoRecipientAction
option.
One of the possible actions is to add an
.q "Apparently-To:"
header line for any recipients it is aware of.
.pp
The Apparently-To: header is non-standard
and is deprecated.
.sh 3 "Precedence"
.pp
The Precedence: header can be used as a crude control of message priority.
It tweaks the sort order in the queue
and can be configured to change the message timeout values.
The precedence of a message also controls how
delivery status notifications (DSNs)
are processed for that message.
.sh 2 "IDENT Protocol Support"
.pp
.i Sendmail
supports the IDENT protocol as defined in RFC 1413.
Note that the RFC states
a client should wait at least 30 seconds for a response.
The default Timeout.ident is 5 seconds
as many sites have adopted the practice of dropping IDENT queries.
This has lead to delays processing mail.
Although this enhances identification
of the author of an email message
by doing a ``call back'' to the originating system to include
the owner of a particular TCP connection
in the audit trail
it is in no sense perfect;
a determined forger can easily spoof the IDENT protocol.
The following description is excerpted from RFC 1413:
.ba +5
.lp
6.  Security Considerations
.lp
The information returned by this protocol is at most as trustworthy
as the host providing it OR the organization operating the host.  For
example, a PC in an open lab has few if any controls on it to prevent
a user from having this protocol return any identifier the user
wants.  Likewise, if the host has been compromised the information
returned may be completely erroneous and misleading.
.lp
The Identification Protocol is not intended as an authorization or
access control protocol.  At best, it provides some additional
auditing information with respect to TCP connections.  At worst, it
can provide misleading, incorrect, or maliciously incorrect
information.
.lp
The use of the information returned by this protocol for other than
auditing is strongly discouraged.  Specifically, using Identification
Protocol information to make access control decisions - either as the
primary method (i.e., no other checks) or as an adjunct to other
methods may result in a weakening of normal host security.
.lp
An Identification server may reveal information about users,
entities, objects or processes which might normally be considered
private.  An Identification server provides service which is a rough
analog of the CallerID services provided by some phone companies and
many of the same privacy considerations and arguments that apply to
the CallerID service apply to Identification.  If you wouldn't run a
"finger" server due to privacy considerations you may not want to run
this protocol.
.ba
.lp
In some cases your system may not work properly with IDENT support
due to a bug in the TCP/IP implementation.
The symptoms will be that for some hosts
the SMTP connection will be closed
almost immediately.
If this is true or if you do not want to use IDENT,
you should set the IDENT timeout to zero;
this will disable the IDENT protocol.
.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 with delivery mode set to
.b i
or
.b b
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.
(See also the MinQueueAge option.)
.pp
RFC 1123 section 5.3.1.1 says that this value should be at least 30 minutes
(although that probably doesn't make sense if you use ``queue-only'' mode).
.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/\*(SD/sendmail \-bd \-q30m
.)b
.pp
An alternative approach is to invoke sendmail from
.i inetd (8)
(use the
.b \-bs
flag to ask sendmail to speak SMTP on its standard input and output).
This works and allows you to wrap
.i sendmail
in a TCP wrapper program,
but may be a bit slower since the configuration file
has to be re-read on every message that comes in.
If you do this, you still need to have a
.i sendmail
running to flush the queue:
.(b
/usr/\*(SD/sendmail \-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/\*(SD/sendmail \-q \-v
.)b
.pp
You can also limit the jobs to those with a particular queue identifier,
sender, or recipient
using one of the queue modifiers.
For example,
.q \-qRberkeley
restricts the queue run to jobs that have the string
.q berkeley
somewhere in one of the recipient addresses.
Similarly,
.q \-qSstring
limits the run to particular senders and
.q \-qIstring
limits it to particular queue identifiers.
.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
and the
.i TRACEFLAGS
file in the sendmail distribution
(they are too dynamic to keep this document up to date).
.sh 2 "Changing the Values of Options"
.pp
Options can be overridden using the
.b \-o
or
.b \-O
command line flags.
For example,
.(b
/usr/\*(SD/sendmail \-oT2m
.)b
sets the
.b T
(timeout) option to two minutes
for this run only;
the equivalent line using the long option name is
.(b
/usr/\*(SD/sendmail -OTimeout.queuereturn=2m
.)b
.pp
Some options have security implications.
Sendmail allows you to set these,
but relinquishes its setuid root permissions thereafter\**.
.(f
\**That is, it sets its effective uid to the real uid;
thus, if you are executing as root,
as from root's crontab file or during system startup
the root permissions will still be honored.
.)f
.sh 2 "Trying a Different Configuration File"
.pp
An alternative configuration file
can be specified using the
.b \-C
flag; for example,
.(b
/usr/\*(SD/sendmail \-Ctest.cf \-oQ/tmp/mqueue
.)b
uses the configuration file
.i test.cf
instead of the default
.i /etc/mail/sendmail.cf.
If the
.b \-C
flag has no value
it defaults to
.i sendmail.cf
in the current directory.
.pp
.i Sendmail
gives up its setuid root permissions
when you use this flag, so it is common to use a publicly writable directory
(such as /tmp)
as the queue directory (QueueDirectory or Q option) while testing.
.sh 2 "Logging Traffic"
.pp
Many SMTP implementations do not fully implement the protocol.
For example, some personal computer based SMTPs
do not understand continuation lines in reply codes.
These can be very hard to trace.
If you suspect such a problem, you can set traffic logging using the
.b \-X
flag.
For example,
.(b
/usr/\*(SD/sendmail \-X /tmp/traffic \-bd
.)b
will log all traffic in the file
.i /tmp/traffic .
.pp
This logs a lot of data very quickly and should
.b NEVER
be used
during normal operations.
After starting up such a daemon,
force the errant implementation to send a message to your host.
All message traffic in and out of
.i sendmail ,
including the incoming SMTP traffic,
will be logged in this file.
.sh 2 "Testing Configuration Files"
.pp
When you build a configuration table,
you can do a certain amount of testing
using the
.q "test mode"
of
.i sendmail .
For example,
you could invoke
.i sendmail
as:
.(b
sendmail \-bt \-Ctest.cf
.)b
which would read the configuration file
.q test.cf
and enter test mode.
In this mode,
you enter lines of the form:
.(b
rwset address
.)b
where
.i rwset
is the rewriting set you want to use
and
.i address
is an address to apply the set to.
Test mode shows you the steps it takes
as it proceeds,
finally showing you the address it ends up with.
You may use a comma separated list of rwsets
for sequential application of rules to an input.
For example:
.(b
3,1,21,4 monet:bollard
.)b
first applies ruleset three to the input
.q monet:bollard.
Ruleset one is then applied to the output of ruleset three,
followed similarly by rulesets twenty-one and four.
.pp
If you need more detail,
you can also use the
.q \-d21
flag to turn on more debugging.
For example,
.(b
sendmail \-bt \-d21.99
.)b
turns on an incredible amount of information;
a single word address
is probably going to print out several pages worth of information.
.pp
You should be warned that internally,
.i sendmail
applies ruleset 3 to all addresses.
In test mode
you will have to do that manually.
For example, older versions allowed you to use
.(b
0 [e-mail]
.)b
This version requires that you use:
.(b
3,0 [e-mail]
.)b
.pp
As of version 8.7,
some other syntaxes are available in test mode:
.bu
\&.D\|x\|value
defines macro
.i x
to have the indicated
.i value .
This is useful when debugging rules that use the
.b $& \c
.i x
syntax.
.bu
\&.C\|c\|value
adds the indicated
.i value
to class
.i c .
.bu
\&.S\|ruleset
dumps the contents of the indicated ruleset.
.bu
\-d\|debug-spec
is equivalent to the command-line flag.
.sh 2 "Persistent Host Status Information"
.pp
When
.b HostStatusDirectory
is enabled,
information about the status of hosts is maintained on disk
and can thus be shared between different instantiations of
.i sendmail .
The status of the last connection with each remote host
may be viewed with the command:
.(b
sendmail \-bh