op.me

早期freebsd实现

.\" Copyright (c) 1983 Eric P. Allman
.\" Copyright (c) 1983, 1993
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)op.me	8.36 (Berkeley) 4/14/94
.\"
.\" eqn op.me | pic | troff -me
.eh 'SMM:08-%''Sendmail Installation and Operation Guide'
.oh 'Sendmail Installation and Operation Guide''SMM:08-%'
.\" SD is lib if sendmail is installed in /usr/lib, sbin if in /usr/sbin
.ds SD sbin
.\" SB is bin if newaliases/mailq are installed in /usr/bin, ucb if in /usr/ucb
.ds SB bin
.nr si 3n
.de $0
.(x
.in \\$3u*3n
.ti -3n
\\$2.  \\$1
.)x
..
.de $C
.(x
.in 0
\\$1 \\$2.  \\$3
.)x
..
.sc
.+c
.(l C
.sz 16
.b SENDMAIL
.sz 12
.sp
.b "INSTALLATION AND OPERATION GUIDE"
.sz 10
.sp
.r
Eric Allman
University of California, Berkeley
Mammoth Project
[e-mail]
.sp
Version 8.36
.sp
For Sendmail Version 8.6
.)l
.sp 2
.pp
.i Sendmail
implements a general purpose internetwork mail routing facility
under the UNIX*
.(f
*UNIX is a trademark of Unix Systems Laboratories.
.)f
operating system.
It is not tied to any one transport protocol \*-
its function may be likened to a crossbar switch,
relaying messages from one domain into another.
In the process,
it can do a limited amount of message header editing
to put the message into a format that is appropriate
for the receiving domain.
All of this is done under the control of a configuration file.
.pp
Due to the requirements of flexibility
for
.i sendmail ,
the configuration file can seem somewhat unapproachable.
However, there are only a few basic configurations
for most sites,
for which standard configuration files have been supplied.
Most other configurations
can be built by adjusting an existing configuration files
incrementally.
.pp
.i Sendmail
is based on
RFC822 (Internet Mail Format Protocol),
RFC821 (Simple Mail Transport Protocol),
RFC1123 (Internet Host Requirements),
and
RFC1425 (SMTP Service Extensions).
However, since
.i sendmail
is designed to work in a wider world,
in many cases it can be configured to exceed these protocols.
These cases are described herein.
.pp
Although
.i sendmail
is intended to run
without the need for monitoring,
it has a number of features
that may be used to monitor or adjust the operation
under unusual circumstances.
These features are described.
.pp
Section one describes how to do a basic
.i sendmail
installation.
Section two
explains the day-to-day information you should know
to maintain your mail system.
If you have a relatively normal site,
these two sections should contain sufficient information
for you to install
.i sendmail
and keep it happy.
Section three
describes some parameters that may be safely tweaked.
Section four
has information regarding the command line arguments.
Section five
contains the nitty-gritty information about the configuration
file.
This section is for masochists
and people who must write their own configuration file.
Section six
describes configuration that can be done at compile time.
Section seven
gives a brief description of differences
in this version of
.i sendmail .
The appendixes give a brief
but detailed explanation of a number of features
not described in the rest of the paper.
.bp 7
.sh 1 "BASIC INSTALLATION"
.pp
There are two basic steps to installing
.i sendmail .
The hard part is to build the configuration table.
This is a file that
.i sendmail
reads when it starts up
that describes the mailers it knows about,
how to parse addresses,
how to rewrite the message header,
and the settings of various options.
Although the configuration table is quite complex,
a configuration can usually be built
by adjusting an existing off-the-shelf configuration.
The second part is actually doing the installation,
i.e., creating the necessary files, etc.
.pp
The remainder of this section will describe the installation of
.i sendmail
assuming you can use one of the existing configurations
and that the standard installation parameters are acceptable.
All pathnames and examples
are given from the root of the
.i sendmail
subtree,
normally
.i /usr/src/usr.\*(SD/sendmail
on 4.4BSD.
.pp
If you are loading this off the tape,
continue with the next section.
If you have a running binary already on your system,
you should probably skip to section 1.2.
.sh 2 "Compiling Sendmail"
.pp
All
.i sendmail
source is in the
.i src
subdirectory.
If you are running on a 4.4BSD system,
compile by typing
.q make .
On other systems, you may have to make some other adjustments.
.sh 3 "Old versions of make"
.pp
If you are not running the new version of
.b make
you will probably have to use
.(b
make \-f Makefile.dist
.)b
This file does not assume several new syntaxes,
including the
.q +=
syntax in macro definition
and the
.q ".include"
syntax.
.sh 3 "Compilation flags"
.pp
.i Sendmail
supports two different formats
for the
.i aliases
database.
These formats are:
.nr ii 1i
.ip NDBM
The ``new DBM'' format,
available on nearly all systems around today.
This was the preferred format prior to 4.4BSD.
It allows such complex things as multiple databases
and closing a currently open database.
.ip NEWDB
The new database package from Berkeley.
If you have this, use it.
It allows
long records,
multiple open databases,
real in-memory caching,
and so forth.
You can define this in conjunction with one of the other two;
if you do,
old databases are read,
but when a new database is created it will be in NEWDB format.
As a nasty hack,
if you have NEWDB, NDBM, and NIS defined,
and if the file
.i /var/yp/Makefile
exists and is readable,
.i sendmail
will create both new and old versions of the alias file
during a
.i newalias
command.
This is required because the Sun NIS/YP system
reads the DBM version of the alias file.
It's ugly as sin,
but it works.
.lp
If neither of these are defined,
.i sendmail
reads the alias file into memory on every invocation.
This can be slow and should be avoided.
.pp
System V based systems can define
SYSTEM5
to make several small adjustments.
This changes the handling of timezones
and uses the much less efficient
.i lockf
call in preference to
.i flock .
These can be specified separately using the compilation flags
SYS5TZ
and
LOCKF
respectively.
.pp
If you don't have the
.i unsetenv
routine in your system library, define the UNSETENV compilation flag.
.pp
You may also have to define the compilation variable LA_TYPE
to describe how your load average is computed.
This and other flags are detailed in section 6.1.
.sh 3 "Compilation and installation"
.pp
After making the local system configuration described above,
You should be able to compile and install the system.
Compilation can be performed using
.q make\**
.(f
\**where you may have to replace
.q make
with
.q "make \-f Makefile.dist"
as appropriate.
.)f
in the
.b sendmail/src
directory.
You may be able to install using
.(b
make install
.)b
This should install the binary in
/usr/\*(SD
and create links from
/usr/\*(SB/newaliases
and
/usr/\*(SB/mailq
to
/usr/\*(SD/sendmail.
On 4.4BSD systems it will also format and install man pages.
.sh 2 "Configuration Files"
.pp
.i Sendmail
cannot operate without a configuration file.
The configuration defines the mail systems understood at this site,
how to access them,
how to forward email to remote mail systems,
and a number of tuning parameters.
This configuration file is detailed
in the later portion of this document.
.pp
The
.i sendmail
configuration can be daunting at first.
The world is complex,
and the mail configuration reflects that.
The distribution includes an m4-based configuration package
that hides a lot of the complexity.
.pp
These configuration files are simpler than old versions
largely because the world has become simpler;
in particular,
text-based host files are officially eliminated,
obviating the need to
.q hide
hosts behind a registered internet gateway.
.pp
These files also assume that most of your neighbors
use domain-based UUCP addressing;
that is,
instead of naming hosts as
.q host!user
they will use
.q host.domain!user .
The configuration files can be customized to work around this,
but it is more complex.
.pp
I haven't tested these yet on an isolated LAN environment
with a single UUCP connection to the outside world.
If you are in such an environment,
please send comments to
[e-mail].
.pp
Our configuration files are processed by
.i m4
to facilitate local customization;
the directory
.i cf
of the
.i sendmail
distribution directory
contains the source files.
This directory contains several subdirectories:
.nr ii 1i
.ip cf
Both site-dependent and site-independent descriptions of hosts.
These can be literal host names
(e.g.,
.q ucbvax.mc )
when the hosts are gateways
or more general descriptions
(such as
.q "tcpproto.mc"
as a general description of an SMTP-connected host
or
.q "uucpproto.mc"
as a general description of a UUCP-connected host).
Files ending
.b \&.mc
(``Master Configuration'')
are the input descriptions;
the output is in the corresponding
.b \&.cf
file.
The general structure of these files is described below.
.ip domain
Site-dependent subdomain descriptions.
These are tied to the way your organization wants to do addressing.
For example,
.b domain/cs.exposed.m4
is our description for hosts in the CS.Berkeley.EDU subdomain
that want their individual hostname to be externally visible;
.b domain/cs.hidden.m4
is the same except that the hostname is hidden
(everything looks like it comes from CS.Berkeley.EDU).
These are referenced using the
.sm DOMAIN
.b m4
macro in the
.b \&.mc
file.
.ip feature
Definitions of specific features that some particular host in your site
might want.
These are referenced using the
.sm FEATURE
.b m4
macro.
An example feature is
use_cw_file
(which tells
.i sendmail
to read an /etc/sendmail.cw file on startup
to find the set of local names).
.ip hack
Local hacks, referenced using the
.sm HACK
.b m4
macro.
Try to avoid these.
The point of having them here is to make it clear that they smell.
.ip m4
Site-independent
.i m4 (1)
include files that have information common to all configuration files.
This can be thought of as a
.q #include
directory.
.ip mailer
Definitions of mailers,
referenced using the
.sm MAILER
.b m4
macro.
Defined mailer types in this distribution are
fax,
local,
smtp,
uucp,
and usenet.
.ip ostype
Definitions describing various operating system environments
(such as the location of support files).
These are referenced using the
.sm OSTYPE
.b m4
macro.
.ip sh
Shell files used by the
.b m4
build process.
You shouldn't have to mess with these.
.ip siteconfig
Local site configuration information,
such as UUCP connectivity.
They normally contain lists of site information, for example:
.(b
SITE(contessa)
SITE(hoptoad)
SITE(nkainc)
SITE(well)
.)b
They are referenced using the SITECONFIG macro:
.(b
SITECONFIG(site.config.file, name_of_site, X)
.)b
where
.i X
is the macro/class name to use.
It can be U
(indicating locally connected hosts)
or one of W, X, or Y
for up to three remote UUCP hubs.
.pp
If you are in a new domain
(e.g., a company),
you will probably want to create a
cf/domain
file for your domain.
This consists primarily of relay definitions:
for example, Berkeley's domain definition
defines relays for
BitNET,
CSNET,
and UUCP.
Of these,
only the UUCP relay is particularly specific
to Berkeley.
All of these are internet-style domain names.
Please check to make certain they are reasonable for your domain.
.pp
Subdomains at Berkeley are also represented in the
cf/domain
directory.
For example,
the domain
cs-exposed
is the Computer Science subdomain with the local hostname shown
to other users;
cs-hidden
makes users appear to be from the CS.Berkeley.EDU subdomain
(with no local host information included).
You will probably have to update this directory
to be appropriate for your domain.
.pp
You will have to use or create
.b \&.mc
files in the
.i cf/cf
subdirectory for your hosts.
This is detailed in the
cf/README
file.
.sh 2 "Details of Installation Files"
.pp
This subsection describes the files that
comprise the
.i sendmail
installation.
.sh 3 "/usr/\*(SD/sendmail"
.pp
The binary for
.i sendmail
is located in /usr/\*(SD\**.
.(f
\**This is usually
/usr/sbin
on 4.4BSD and newer systems;
many systems install it in