readme

< linux网络编程工具>>配套源码

# Copyright (c) 1998-2000 Sendmail, Inc. and its suppliers.
#	All rights reserved.
# Copyright (c) 1983, 1995-1997 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988
#	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: README,v 8.263.2.1.2.21 2000/09/27 16:36:26 ca Exp $
#

This directory contains the source files for sendmail(TM).

*********************
!! DO NOT USE MAKE !!  in this directory to compile sendmail --
*********************  instead, use the "Build" script located in
the sendmail directory.  It will build an appropriate Makefile, and
create an appropriate obj.* subdirectory so that multiplatform
support works easily.

	**********************************************************
	**  Read below for more details on building sendmail.	**
	**********************************************************

**************************************************************************
**  IMPORTANT:  Read the appropriate paragraphs in the section on	**
**  ``Operating System and Compile Quirks''.				**
**************************************************************************

For detailed instructions, please read the document ../doc/op/op.me:

	eqn ../doc/op/op.me | pic | ditroff -me

Sendmail is a trademark of Sendmail, Inc.


+-------------------+
| BUILDING SENDMAIL |
+-------------------+

By far, the easiest way to compile sendmail is to use the "Build"
script:

	sh Build

This uses the "uname" command to figure out what architecture you are
on and creates a proper Makefile accordingly.  It also creates a
subdirectory per object format, so that multiarchitecture support is
easy.  In general this should be all you need.  IRIX 6.x users should
read the note below in the OPERATING SYSTEM AND COMPILE QUIRKS section.

If you need to look at other include or library directories, use the
-I or -L flags on the command line, e.g.,

	sh Build -I/usr/sww/include -L/usr/sww/lib

It's also possible to create local site configuration in the file
site.config.m4 (or another file settable with the -f flag).  This
file contains M4 definitions for various compilation values; the
most useful are:

confMAPDEF	-D flags to specify database types to be included
		(see below)
confENVDEF	-D flags to specify other environment information
confINCDIRS	-I flags for finding include files during compilation
confLIBDIRS	-L flags for finding libraries during linking
confLIBS	-l flags for selecting libraries during linking
confLDOPTS	other ld(1) linker options

Others can be found by examining Makefile.m4.  Please read
../devtools/README for more information about the site.config.m4
file.

You can recompile from scratch using the -c flag with the Build
command.  This removes the existing compilation directory for the
current platform and builds a new one.

Porting to a new Unix-based system should be a matter of creating
an appropriate configuration file in the devtools/OS/ directory.



+----------------------+
| DATABASE DEFINITIONS |
+----------------------+

There are several database formats that can be used for the alias files
and for general maps.  When used for alias files they interact in an
attempt to be backward compatible.

The options are:

NEWDB		The new Berkeley DB package.  Some systems (e.g., BSD/OS and
		Digital UNIX 4.0) have some version of this package
		pre-installed.  If your system does not have Berkeley DB
		pre-installed, or the version installed is not version 2.0
		or greater (e.g., is Berkeley DB 1.85 or 1.86), get the
		current version from http://www.sleepycat.com/.  DO NOT
		use a version from any of the University of California,
		Berkeley "Net" or other distributions.  If you are still
		running BSD/386 1.x, you will need to upgrade the included
		Berkeley DB library to a current version.  NEWDB is included
		automatically if the Build script can find a library named
		libdb.a or libdb.so.
NDBM		The older NDBM implementation -- the very old V7 DBM
		implementation is no longer supported.
NIS		Network Information Services.  To use this you must have
		NIS support on your system.
NISPLUS		NIS+ (the revised NIS released with Solaris 2).  You must
		have NIS+ support on your system to use this flag.
HESIOD		Support for Hesiod (from the DEC/Athena distribution).  You
		must already have Hesiod support on your system for this to
		work.  You may be able to get this to work with the MIT/Athena
		version of Hesiod, but that's likely to be a lot of work.
LDAPMAP		Lightweight Directory Access Protocol support.  You will
		have to install the UMich or OpenLDAP
		(http://www.openldap.org/) ldap and lber libraries to use
		this flag.
MAP_REGEX	Regular Expression support.  You will need to use an
		operating system which comes with the POSIX regex()
		routines or install a regexp library such as libregex from
		the Free Software Foundation.
PH_MAP		PH map support.  You will need the qi PH package.
MAP_NSD		nsd map support (IRIX 6.5 and later).

>>>  NOTE WELL for NEWDB support: If you want to get ndbm support, for
>>>  Berkeley DB versions under 2.0, it is CRITICAL that you remove
>>>  ndbm.o from libdb.a before you install it and DO NOT install ndbm.h;
>>>  for Berkeley DB versions 2.0 through 2.3.14, remove dbm.o from libdb.a
>>>  before you install it.  If you don't delete these, there is absolutely
>>>  no point to including -DNDBM, since it will just get you another
>>>  (inferior) API to the same format database.  These files OVERRIDE
>>>  calls to ndbm routines -- in particular, if you leave ndbm.h in,
>>>  you can find yourself using the new db package even if you don't
>>>  define NEWDB.  Berkeley DB versions later than 2.3.14 do not need
>>>  to be modified.  Please also consult the README in the top level
>>>  directory of the sendmail distribution for other important information.
>>>
>>>  Further note: DO NOT remove your existing /usr/include/ndbm.h --
>>>  you need that one.  But do not install an updated ndbm.h in
>>>  /usr/include, /usr/local/include, or anywhere else.

If NEWDB and NDBM are defined (but not NIS), then sendmail will read
NDBM format alias files, but the next time a newaliases is run the
format will be converted to NEWDB; that format will be used forever
more.  This is intended as a transition feature.

If NEWDB, NDBM, and NIS are all defined and the name of the file includes
the string "/yp/", sendmail will rebuild BOTH the NEWDB and NDBM format
alias files.  However, it will only read the NEWDB file; the NDBM format
file is used only by the NIS subsystem.  This is needed because the NIS
maps on an NIS server are built directly from the NDBM files.

If NDBM and NIS are defined (regardless of the definition of NEWDB),
and the filename includes the string "/yp/", sendmail adds the special
tokens "YP_LAST_MODIFIED" and "YP_MASTER_NAME", both of which are
required if the NDBM file is to be used as an NIS map.

All of these flags are normally defined in the DBMDEF line in the
Makefile.

If you define NEWDB or HESIOD you get the User Database (USERDB)
automatically.  Generally you do want to have NEWDB for it to do
anything interesting.  See above for getting the Berkeley DB
package (i.e., NEWDB).  There is no separate "user database"
package -- don't bother searching for it on the net.

Hesiod and LDAP require libraries that may not be installed with your
system.  These are outside of my ability to provide support.  See the
"Quirks" section for more information.

The regex map can be used to see if an address matches a certain regular
expression.  For example, all-numerics local parts are common spam
addresses, so "^[0-9]+$" would match this.  By using such a map in a
check_* rule-set, you can block a certain range of addresses that would
otherwise be considered valid.

+---------------+
| COMPILE FLAGS |
+---------------+

Wherever possible, I try to make sendmail pull in the correct
compilation options needed to compile on various environments based on
automatically defined symbols.  Some machines don't seem to have useful
symbols available, requiring that a compilation flag be defined in
the Makefile; see the devtools/OS subdirectory for the supported
architectures.

If you are a system to which sendmail has already been ported you
should not have to touch the following symbols.  But if you are porting,
you may have to tweak the following compilation flags in conf.h in order
to get it to compile and link properly:

SYSTEM5		Adjust for System V (not necessarily Release 4).
SYS5SIGNALS	Use System V signal semantics -- the signal handler
		is automatically dropped when the signal is caught.
		If this is not set, use POSIX/BSD semantics, where the
		signal handler stays in force until an exec or an
		explicit delete.  Implied by SYSTEM5.
SYS5SETPGRP	Use System V setpgrp() semantics.  Implied by SYSTEM5.
HASFCHMOD	Define this to one if you have the fchmod(2) system call.
		This improves security.
HASFCHOWN	Define this to one if you have the fchown(2) system call.
		This is required for the TrustedUser option.
HASFLOCK	Set this if you prefer to use the flock(2) system call
		rather than using fcntl-based locking.  Fcntl locking
		has some semantic gotchas, but many vendor systems
		also interface it to lockd(8) to do NFS-style locking.
		Unfortunately, may vendors implementations of fcntl locking
		is just plain broken (e.g., locks are never released,
		causing your sendmail to deadlock; when the kernel runs
		out of locks your system crashes).  For this reason, I
		recommend always defining this unless you are absolutely
		certain that your fcntl locking implementation really works.
HASUNAME	Set if you have the "uname" system call.  Implied by
		SYSTEM5.
HASUNSETENV	Define this if your system library has the "unsetenv"
		subroutine.
HASSETSID	Define this if you have the setsid(2) system call.  This
		is implied if your system appears to be POSIX compliant.
HASINITGROUPS	Define this if you have the initgroups(3) routine.
HASSETVBUF	Define this if you have the setvbuf(3) library call.
		If you don't, setlinebuf will be used instead.  This
		defaults on if your compiler defines __STDC__.
HASSETREUID	Define this if you have setreuid(2) ***AND*** root can
		use setreuid to change to an arbitrary user.  This second
		condition is not satisfied on AIX 3.x.  You may find that
		your system has setresuid(2), (for example, on HP-UX) in
		which case you will also have to #define setreuid(r, e)
		to be the appropriate call.  Some systems (such as Solaris)
		have a compatibility routine that doesn't work properly,
		but may have "saved user ids" properly implemented so you
		can ``#define setreuid(r, e) seteuid(e)'' and have it work.
		The important thing is that you have a call that will set
		the effective uid independently of the real or saved uid
		and be able to set the effective uid back again when done.
		There's a test program in ../test/t_setreuid.c that will
		try things on your system.  Setting this improves the
		security, since sendmail doesn't have to read .forward
		and :include: files as root.  There are certain attacks
		that may be unpreventable without this call.
USESETEUID	Define this to 1 if you have a seteuid(2) system call that
		will allow root to set only the effective user id to an
		arbitrary value ***AND*** you have saved user ids.  This is
		preferable to HASSETREUID if these conditions are fulfilled.
		These are the semantics of the to-be-released revision of
		Posix.1.  The test program ../test/t_seteuid.c will try
		this out on your system.  If you define both HASSETREUID
		and USESETEUID, the former is ignored.
HASLSTAT	Define this if you have symbolic links (and thus the
		lstat(2) system call).  This improves security.  Unlike
		most other options, this one is on by default, so you
		need to #undef it in conf.h if you don't have symbolic
		links (these days everyone does).
HASSETRLIMIT	Define this to 1 if you have the setrlimit(2) syscall.
		You can define it to 0 to force it off.  It is assumed
		if you are running a BSD-like system.
HASULIMIT	Define this if you have the ulimit(2) syscall (System V
		style systems).  HASSETRLIMIT overrides, as it is more
		general.
HASWAITPID	Define this if you have the waitpid(2) syscall.
HASGETDTABLESIZE
		Define this if you have the getdtablesize(2) syscall.
HAS_ST_GEN	Define this to 1 if your system has the st_gen field in
		the stat structure (see stat(2)).
HASSRANDOMDEV	Define this if your system has the srandomdev(3) function
		call.
HASURANDOMDEV	Define this if your system has /dev/urandom(4).
HASSTRERROR	Define this if you have the libc strerror(3) function (which
		should be declared in <errno.h>), and it should be used
		instead of sys_errlist.
NEEDGETOPT	Define this if you need a reimplementation of getopt(3).
		On some systems, getopt does very odd things if called
		to scan the arguments twice.  This flag will ask sendmail
		to compile in a local version of getopt that works
		properly.
NEEDSTRTOL	Define this if your standard C library does not define
		strtol(3).  This will compile in a local version.
NEEDVPRINTF	Define this if your standard C library does not define