op.me

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

.\" Copyright (c) 1998-2000 Sendmail, Inc. and its suppliers.
.\"	All rights reserved.
.\" Copyright (c) 1983, 1995 Eric P. Allman.  All rights reserved.
.\" Copyright (c) 1983, 1993
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" By using this file, you agree to the terms and conditions set
.\" forth in the LICENSE file which can be found at the top level of
.\" the sendmail distribution.
.\"
.\"
.\"	$Id: op.me,v 8.317.4.39 2000/09/22 15:01:37 ca Exp $
.\"
.\" 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\u\s-6TM\s0\d
.sz 12
.sp
.b "INSTALLATION AND OPERATION GUIDE"
.(f
.b DISCLAIMER:
This documentation is under modification.
.)f
.sz 10
.sp
.r
Eric Allman
Sendmail, Inc.
[e-mail]
.sp
.de Ve
Version \\$2
..
.Ve $Revision: 8.317.4.39 $
.rm Ve
.sp
For Sendmail Version 8.11
.)l
.(f
Sendmail is a trademark of Sendmail, Inc.
.)f
.sp 2
.pp
.i Sendmail \u\s-2TM\s0\d
implements a general purpose internetwork mail routing facility
under the UNIX\(rg
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 file
incrementally.
.pp
.i Sendmail
is based on
RFC821 (Simple Mail Transport Protocol),
RFC822 (Internet Mail Headers Format),
RFC974 (MX routing),
RFC1123 (Internet Host Requirements),
RFC2045 (MIME),
RFC1869 (SMTP Service Extensions),
RFC1652 (SMTP 8BITMIME Extension),
RFC1870 (SMTP SIZE Extension),
RFC1891 (SMTP Delivery Status Notifications),
RFC1892 (Multipart/Report),
RFC1893 (Mail System Status Codes),
RFC1894 (Delivery Status Notifications),
RFC1985 (SMTP Service Extension for Remote Message Queue Starting),
RFC2033 (Local Message Transmission Protocol),
RFC2034 (SMTP Service Extension for Returning Enhanced Error Codes),
RFC2476 (Message Submission),
RFC2487 (SMTP Service Extension for Secure SMTP over TLS),
and
RFC2554 (SMTP Service Extension for Authentication).
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.
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 .
First, you have to compile and install the binary.
If
.i sendmail
has already been ported to your operating system
that should be simple.
Second, you must build a run-time configuration file.
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 file can be quite complex,
a configuration can usually be built
using an M4-based configuration language.
.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 sendmail
subdirectory.
To compile sendmail,
.q cd
into the
.i sendmail
directory and type
.(b
\&./Build
.)b
This will leave the binary in an appropriately named subdirectory,
e.g.,
obj.BSD-OS.2.1.i386.
It works for multiple object versions
compiled out of the same directory.
.sh 3 "Tweaking the Build Invocation"
.pp
You can give parameters on the
.i Build
command.
In most cases these are only used when the
.i obj.*
directory is first created.
These commands include:
.nr ii 0.5i
.ip "\-L \fIlibdirs\fP"
A list of directories to search for libraries.
.ip "\-I \fIincdirs\fP"
A list of directories to search for include files.
.ip "\-E \fIenvar\fP=\fIvalue\fP"
Set an environment variable to an indicated
.i value
before compiling.
.ip "\-c"
Create a new
.i obj.*
tree before running.
.ip "\-f \fIsiteconfig\fP"
Read the indicated site configuration file.
If this parameter is not specified,
.i Build
includes
.i all
of the files
.i $BUILDTOOLS/Site/site.$oscf.m4
and
.i $BUILDTOOLS/Site/site.config.m4 ,
where $BUILDTOOLS is normally
.i \&../devtools
and $oscf is the same name as used on the
.i obj.*
directory.
See below for a description of the site configuration file.
.ip "\-S"
Skip auto-configuration.
.i Build
will avoid auto-detecting libraries if this is set.
All libraries and map definitions must be specified
in the site configuration file.
.lp
Any other parameters are passed to the
.i make
program.
.sh 3 "Creating a Site Configuration File"
.\"XXX
.pp
(This section is not yet complete.
For now, see the file devtools/README for details.)
See sendmail/README for various compilation flags that can be set.
.sh 3 "Tweaking the Makefile"
.pp
.\" .b "XXX This should all be in the Site Configuration File section."
.i Sendmail
supports two different formats
for the local (on disk) version of databases,
notably the
.i aliases
database.
At least one of these should be defined if at all possible.
.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 Berkeley DB package.
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
.sm NDBM ;
if you do,
old alias 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 alias file name includes the substring
.q /yp/ ,
.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.
There are also several methods for remote database access:
.ip NIS
Sun's Network Information Services (formerly YP).
.ip NISPLUS
Sun's NIS+ services.
.ip NETINFO
NeXT's NetInfo service.
.ip HESIOD
Hesiod service (from Athena).
.lp
Other compilation flags are set in conf.h
and should be predefined for you
unless you are porting to a new environment.
.sh 3 "Compilation and installation"
.pp
After making the local system configuration described above,
You should be able to compile and install the system.
The script
.q Build
is the best approach on most systems:
.(b
\&./Build
.)b
This will use
.i uname (1)
to create a custom Makefile for your environment.
.pp
If you are installing in the standard places,
you should be able to install using
.(b
\&./Build 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 delivery mechanisms 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
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 "generic-solaris2.mc"
as a general description of an SMTP-connected host
running Solaris 2.x.
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.Berkeley.EDU.m4
is our description for hosts in the CS.Berkeley.EDU subdomain.
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/mail/local-host-names 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.
The mailer types that are known in this distribution are
fax,
local,
smtp,
uucp,
and usenet.
For example, to include support for the UUCP-based mailers,
use
.q MAILER(uucp) .
.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 UUCP connectivity information.
This directory has been supplanted by the mailertable feature;
any new configurations should use that feature to do UUCP
(and other) routing.
.pp