op.me

早期freebsd实现

/usr/lib.
I understand it is in /usr/ucblib
on System V Release 4.
.)f
It should be setuid root.
For security reasons,
/, /usr, and /usr/\*(SD
should be owned by root, mode 755\**.
.(f
\**Some vendors ship them owned by bin;
this creates a security hole that is not actually related to
.i sendmail .
Other important directories that should have restrictive ownerships
and permissions are
/bin, /usr/bin, /etc, /usr/etc, /lib, and /usr/lib.
.)f
.sh 3 "/etc/sendmail.cf"
.pp
This is the configuration file for
.i sendmail .
This is the only non-library file name compiled into
.i sendmail \**.
.(f
\**The system libraries can reference other files;
in particular, system library subroutines that
.i sendmail
calls probably reference
.i /etc/passwd
and
.i /etc/resolv.conf .
.)f
Some older systems install it in
.b /usr/lib/sendmail.cf .
.pp
If you want to move this file,
change
.i src/pathnames.h .
.pp
The configuration file is normally created
using the distribution files described above.
If you have a particularly unusual system configuration
you may need to create a special version.
The format of this file is detailed in later sections
of this document.
.sh 3 "/usr/\*(SB/newaliases"
.pp
The
.i newaliases
command should just be a link to
.i sendmail :
.(b
rm \-f /usr/\*(SB/newaliases
ln \-s /usr/\*(SD/sendmail /usr/\*(SB/newaliases
.)b
This can be installed in whatever search path you prefer
for your system.
.sh 3 "/var/spool/mqueue"
.pp
The directory
.i /var/spool/mqueue
should be created to hold the mail queue.
This directory should be mode 700
and owned by root.
.pp
The actual path of this directory
is defined in the
.b Q
option of the
.i sendmail.cf
file.
.sh 3 "/etc/aliases*"
.pp
The system aliases are held in
.q /etc/aliases .
A sample is given in
.q lib/aliases
which includes some aliases which
.i must
be defined:
.(b
cp lib/aliases /etc/aliases
.i "edit /etc/aliases"
.)b
You should extend this file with any aliases that are apropos to your system.
.pp
Normally
.i sendmail
looks at a version of these files maintained by the
.i dbm \|(3)
or
.i db \|(3)
routines.
These are stored either in
.q /etc/aliases.dir
and
.q /etc/aliases.pag
or
.q /etc/aliases.db
depending on which database package you are using.
These can initially be created as empty files,
but they will have to be initialized promptly.
These should be mode 644:
.(b
cp /dev/null /etc/aliases.dir
cp /dev/null /etc/aliases.pag
chmod 644 /etc/aliases.*
newaliases
.)b
The
.i db
routines preset the mode reasonably,
so this step can be skipped.
The actual path of this file
is defined in the
.b A
option of the
.i sendmail.cf
file.
.sh 3 "/etc/rc"
.pp
It will be necessary to start up the
.i sendmail
daemon when your system reboots.
This daemon performs two functions:
it listens on the SMTP socket for connections
(to receive mail from a remote system)
and it processes the queue periodically
to insure that mail gets delivered when hosts come up.
.pp
Add the following lines to
.q /etc/rc
(or
.q /etc/rc.local
as appropriate)
in the area where it is starting up the daemons:
.(b
if [ \-f /usr/\*(SD/sendmail \-a \-f /etc/sendmail.cf ]; then
	(cd /var/spool/mqueue; rm \-f [lnx]f*)
	/usr/\*(SD/sendmail \-bd \-q30m &
	echo \-n ' sendmail' >/dev/console
fi
.)b
The
.q cd
and
.q rm
commands insure that all lock files have been removed;
extraneous lock files may be left around
if the system goes down in the middle of processing a message.
The line that actually invokes
.i sendmail
has two flags:
.q \-bd
causes it to listen on the SMTP port,
and
.q \-q30m
causes it to run the queue every half hour.
.pp
Some people use a more complex startup script,
removing zero length qf files and df files for which there is no qf file.
For example:
.(b
# remove zero length qf files
for qffile in qf*
do
	if [ \-r $qffile ]
	then
		if [ ! \-s $qffile ]
		then
			echo \-n " <zero: $qffile>" > /dev/console
			rm \-f $qffile
		fi
	fi
done
# rename tf files to be qf if the qf does not exist
for tffile in tf*
do
	qffile=`echo $tffile | sed 's/t/q/'`
	if [ \-r $tffile \-a ! \-f $qffile ]
	then
		echo \-n " <recovering: $tffile>" > /dev/console
		mv $tffile $qffile
	else
		echo \-n " <extra: $tffile>" > /dev/console
		rm \-f $tffile
	fi
done
# remove df files with no corresponding qf files
for dffile in df*
do
	qffile=`echo $dffile | sed 's/d/q/'`
	if [ \-r $dffile \-a ! \-f $qffile ]
	then
		echo \-n " <incomplete: $dffile>" > /dev/console
		mv $dffile `echo $dffile | sed 's/d/D/'`
	fi
done
# announce files that have been saved during disaster recovery
for xffile in [A-Z]f*
do
	echo \-n " <panic: $xffile>" > /dev/console
done
.)b
.pp
If you are not running a version of UNIX
that supports Berkeley TCP/IP,
do not include the
.b \-bd
flag.
.sh 3 "/usr/lib/sendmail.hf"
.pp
This is the help file used by the SMTP
.b HELP
command.
It should be copied from
.q lib/sendmail.hf :
.(b
cp lib/sendmail.hf /usr/lib
.)b
The actual path of this file
is defined in the
.b H
option of the
.i sendmail.cf
file.
.sh 3 "/etc/sendmail.st"
.pp
If you wish to collect statistics
about your mail traffic,
you should create the file
.q /etc/sendmail.st :
.(b
cp /dev/null /etc/sendmail.st
chmod 666 /etc/sendmail.st
.)b
This file does not grow.
It is printed with the program
.q mailstats/mailstats.c.
The actual path of this file
is defined in the
.b S
option of the
.i sendmail.cf
file.
.sh 3 "/usr/\*(SB/newaliases"
.pp
If
.i sendmail
is invoked as
.q newaliases,
it will simulate the
.b \-bi
flag
(i.e., will rebuild the alias database;
see below).
This should be a link to /usr/\*(SD/sendmail.
.sh 3 "/usr/\*(SB/mailq"
.pp
If
.i sendmail
is invoked as
.q mailq,
it will simulate the
.b \-bp
flag
(i.e.,
.i sendmail
will print the contents of the mail queue;
see below).
This should be a link to /usr/\*(SD/sendmail.
.sh 1 "NORMAL OPERATIONS"
.sh 2 "The System Log"
.pp
The system log is supported by the
.i syslogd \|(8)
program.
All messages from
.i sendmail
are logged under the
.sm LOG_MAIL
facility.
.sh 3 "Format"
.pp
Each line in the system log
consists of a timestamp,
the name of the machine that generated it
(for logging from several machines
over the local area network),
the word
.q sendmail: ,
and a message.
.sh 3 "Levels"
.pp
If you have
.i syslogd \|(8)
or an equivalent installed,
you will be able to do logging.
There is a large amount of information that can be logged.
The log is arranged as a succession of levels.
At the lowest level
only extremely strange situations are logged.
At the highest level,
even the most mundane and uninteresting events
are recorded for posterity.
As a convention,
log levels under ten
are considered generally
.q useful;
log levels above 64
are reserved for debugging purposes.
Levels from 11\-64 are reserved for verbose information
that some sites might want.
.pp
A complete description of the log levels
is given in section 4.6.
.sh 2 "The Mail Queue"
.pp
The mail queue should be processed transparently.
However, you may find that manual intervention is sometimes necessary.
For example,
if a major host is down for a period of time
the queue may become clogged.
Although
.i sendmail
ought to recover gracefully when the host comes up,
you may find performance unacceptably bad in the meantime.
.sh 3 "Printing the queue"
.pp
The contents of the queue can be printed
using the
.i mailq
command
(or by specifying the
.b \-bp
flag to
.i sendmail ):
.(b
mailq
.)b
This will produce a listing of the queue id's,
the size of the message,
the date the message entered the queue,
and the sender and recipients.
.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
(however,
.i sendmail
does include heuristics to try to abort jobs
that are taking absurd amounts of time;
technically, this violates RFC 821, but is blessed by RFC 1123).
Due to the locking algorithm,
it is impossible for one job to freeze the entire queue.
However,
an uncooperative recipient host
or a program recipient
that never returns
can accumulate many processes in your system.
Unfortunately,
there is no completely general way to solve this.
.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 /var/spool
mv mqueue omqueue; mkdir mqueue; chmod 700 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/\*(SD/sendmail \-oQ/var/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 /var/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 /etc/aliases.
The aliases are of the form
.(b
name: name1, name2, ...
.)b
Only local names may be aliased;
e.g.,
.(b
[e-mail]: [e-mail]
.)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)
(or
.i db \|(3))
library.
This form is in the files
.i /etc/aliases.dir
and
.i /etc/aliases.pag.
This is the form that
.i sendmail
actually uses to resolve aliases.
This technique is used to improve performance.
.pp
You can also use
.sm NIS -based
alias files.
For example, the specification:
.(b
OA/etc/aliases
OAnis:[e-mail]
.)b
will first search the /etc/aliases file
and then the map named
.q mail.aliases
in
.q my.nis.domain .
Warning: if you build your own
.sm NIS -based
alias files,
be sure to provide the
.b \-l
flag to
.i makedbm (8)
to map upper case letters in the keys to lower case;
otherwise, aliases with upper case letters in their names
won't match incoming addresses.
.pp
Additional flags can be added after the colon
exactly like a
.b K
line \(em for example:
.(b
OAnis:-N [e-mail]
.)b
will search the appropriate NIS map and always include null bytes in the key.
.sh 3 "Rebuilding the alias database"
.pp
The DB or 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/\*(SD/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.
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.
.pp
If you have multiple aliases databases specified,
the
.b \-bi
flag rebuilds all the database types it understands
(for example, it can rebuild dbm databases but not nis databases).
.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