readme

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

		supported on ConvexOS.
SASL		Enables SMTP AUTH (RFC 2554). This requires the Cyrus SASL
		library (ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/).  Please
		install at least version 1.5.13.  See below for further
		information: SASL COMPILATION AND CONFIGURATION.  If your
		SASL library is older than 1.5.10, you have to set this
		to its version number using a simple conversion:  a.b.c
		-> c + b*100 + a*10000, e.g. for 1.5.9 define SASL=10509.
		Note: Using an older version than 1.5.5 of Cyrus SASL is
		not supported. Starting with version 1.5.10, setting SASL=1
		is sufficient. Any value other than 1 (or 0) will be
		compared with the actual version found and if there is a
		mismatch, compilation will fail.
EGD		Define this if your system has EGD installed, see
		http://www.lothar.com/tech/crypto/ . It should be used to
		seed the PRNG for STARTTLS if HASURANDOMDEV is not defined.
STARTTLS	Enables SMTP STARTTLS (RFC 2487). This requires OpenSSL
		(http://www.OpenSSL.org/) and sfio (see below).
		Use OpenSSL 0.9.5a or later (if compatible with this
		version), do not use 0.9.3.
		See STARTTLS COMPILATION AND CONFIGURATION for further
		information.
TLS_NO_RSA	Turn off support for RSA algorithms in STARTTLS.
SFIO		Uses sfio instead of stdio. sfio is available from AT&T
		(http://www.research.att.com/sw/tools/sfio/).  If this
		compile flag is set, confSTDIO_TYPE must be set to portable.
		This compile flag is necessary for STARTTLS; it also
		enables the security layer of SASL.  The sfio include file
		stdio.h must be installed in a subdirectory called sfio,
		i.e., if you install sfio in /usr/local, stdio.h should
		be in /usr/local/include/sfio, and libsfio.a should be in
		/usr/local/lib.  Notice: you may run into problems if
		you use sfio2000 (the body of a message is lost).  Use
		sfio1999 instead.


+---------------------+
| DNS/RESOLVER ISSUES |
+---------------------+

Many systems have old versions of the resolver library.  At a minimum,
you should be running BIND 4.8.3; older versions may compile, but they
have known bugs that should give you pause.

Common problems in old versions include "undefined" errors for
dn_skipname.

Some people have had a problem with BIND 4.9; it uses some routines
that it expects to be externally defined such as strerror().  It may
help to link with "-l44bsd" to solve this problem.  This has apparently
been fixed in later versions of BIND, starting around 4.9.3.  In other
words, if you use 4.9.0 through 4.9.2, you need -l44bsd; for earlier or
later versions, you do not.

!PLEASE! be sure to link with the same version of the resolver as
the header files you used -- some people have used the 4.9 headers
and linked with BIND 4.8 or vice versa, and it doesn't work.
Unfortunately, it doesn't fail in an obvious way -- things just
subtly don't work.

WILDCARD MX RECORDS ARE A BAD IDEA!  The only situation in which they
work reliably is if you have two versions of DNS, one in the real world
which has a wildcard pointing to your firewall, and a completely
different version of the database internally that does not include
wildcard MX records that match your domain.  ANYTHING ELSE WILL GIVE
YOU HEADACHES!


+----------------------------------------+
| STARTTLS COMPILATION AND CONFIGURATION |
+----------------------------------------+

Please read the docs accompanying the OpenSSL library and sfio.
You have to compile and install both libraries before you can compile
sendmail.  See devtools/README how to set the correct compile time
parameters; you should at least set the following variables:

define(`confSTDIO_TYPE', `portable')
APPENDDEF(`confENVDEF', `-DSFIO')
APPENDDEF(`confLIBS', `-lsfio')
APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS')
APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')

Configuration information can be found in doc/op/op.me (required
certificates) and cf/README (how to tell sendmail about certificates).

To perform an initial test, connect to your sendmail daemon
(telnet localhost 25) and issue a EHLO localhost and see whether
250-STARTTLS
is in the response.  If it isn't, run the daemon with
-O LogLevel=14
and try again.  Then take a look at the logfile and see whether
there are any problems listed about permissions (unsafe files)
or the validity of X.509 certificates.

Note: sfio must be used in all libraries with which sendmail exchanges
file pointers. That is, libsmutil must be compiled with sfio, which
is accomplished by the above config parameters. Another example is
PH map support.  This does not apply to the usual libraries, e.g.,
OpenSSL, Berkeley DB, Cyrus SASL.

Further information can be found via:
http://www.sendmail.org/tips/


+------------------------------------+
| SASL COMPILATION AND CONFIGURATION |
+------------------------------------+

Please read the docs accompanying the library (INSTALL and README).
If you use Berkeley DB for Cyrus SASL then you must compile sendmail
with the same version of Berkeley DB.

You have to select and install authentication mechanisms and tell
sendmail where to find the sasl library and the include files (see
devtools/README for the parameters to set). Setup the required
users and passwords as explained in the SASL documentation.  See
also cf/README for authentication related options (esp. DefaultAuthInfo
if you want authentication between MTAs).

To perform an initial test, connect to your sendmail daemon
(telnet localhost 25) and issue a EHLO localhost and see whether
250-AUTH ....
is in the response.  If it isn't, run the daemon with
-O LogLevel=14
and try again.  Then take a look at the logfile and see whether
there are any security related problems listed (unsafe files).

Further information can be found via:
http://www.sendmail.org/tips/


+-------------------------------------+
| OPERATING SYSTEM AND COMPILE QUIRKS |
+-------------------------------------+

GCC problems
	*****************************************************************
	**  IMPORTANT:  DO NOT USE OPTIMIZATION (``-O'') IF YOU ARE    **
	**  RUNNING GCC 2.4.x or 2.5.x.  THERE IS A BUG IN THE GCC     **
	**  OPTIMIZER THAT CAUSES SENDMAIL COMPILES TO FAIL MISERABLY. **
	*****************************************************************

	Jim Wilson of Cygnus believes he has found the problem -- it will
	probably be fixed in GCC 2.5.6 -- but until this is verified, be
	very suspicious of gcc -O.  This problem is reported to have been
	fixed in gcc 2.6.

	A bug in gcc 2.5.5 caused problems compiling sendmail 8.6.5 with
	optimization on a Sparc.  If you are using gcc 2.5.5, youi should
	upgrade to the latest version of gcc.

	Apparently GCC 2.7.0 on the Pentium processor has optimization
	problems.  I recommend against using -O on that architecture.  This
	has been seen on FreeBSD 2.0.5 RELEASE.

	Solaris 2.X users should use version 2.7.2.3 over 2.7.2.

	We have been told there are problems with gcc 2.8.0.  If you are
	using this version, you should upgrade to 2.8.1 or later.

GDBM	GDBM does not work with sendmail 8.8 because the additional
	security checks and file locking cause problems.  Unfortunately,
	gdbm does not provide a compile flag in its version of ndbm.h so
	the code can adapt.  Until the GDBM authors can fix these problems,
	GDBM will not be supported.  Please use Berkeley DB instead.

Configuration file location
	Up to 8.6, sendmail tried to find the sendmail.cf file in the same
	place as the vendors had put it, even when this was obviously
	stupid.  As of 8.7, sendmail ALWAYS looks for /etc/sendmail.cf.
	Beginning with 8.10, sendmail uses /etc/mail/sendmail.cf.
	You can get sendmail to use the stupid vendor .cf location by
	adding -DUSE_VENDOR_CF_PATH during compilation, but this may break
	support programs and scripts that need to find sendmail.cf.  You
	are STRONGLY urged to use symbolic links if you want to use the
	vendor location rather than changing the location in the sendmail
	binary.

	NETINFO systems use NETINFO to determine the location of
	sendmail.cf. The full path to sendmail.cf is stored as the value of
	the "sendmail.cf" property in the "/locations/sendmail"
	subdirectory of NETINFO. Set the value of this property to
	"/etc/mail/sendmail.cf" (without the quotes) to use this new
	default location for Sendmail 8.10.0 and higher.

ControlSocket permissions
	Paraphrased from BIND 8.2.1's README:

	Solaris and other pre-4.4BSD kernels do not respect ownership or
	protections on UNIX-domain sockets.  The short term fix for this is to
	override the default path and put such control sockets into root-
	owned directories which do not permit non-root to r/w/x through them.
	The long term fix is for all kernels to upgrade to 4.4BSD semantics.

SunOS 4.x (Solaris 1.x)
	You may have to use -lresolv on SunOS.  However, beware that
	this links in a new version of gethostbyname that does not
	understand NIS, so you must have all of your hosts in DNS.

	Some people have reported problems with the SunOS version of
	-lresolv and/or in.named, and suggest that you get a newer
	version.  The symptoms are delays when you connect to the
	SMTP server on a SunOS machine or having your domain added to
	addresses inappropriately.  There is a version of BIND
	version 4.9 on gatekeeper.DEC.COM in pub/BSD/bind/4.9.

	There is substantial disagreement about whether you can make
	this work with resolv+, which allows you to specify a search-path
	of services.  Some people report that it works fine, others
	claim it doesn't work at all (including causing sendmail to
	drop core when it tries to do multiple resolv+ lookups for a
	single job).  I haven't tried resolv+, as we use DNS exclusively.

	Should you want to try resolv+, it is on ftp.uu.net in
	/networking/ip/dns.

	Apparently getservbyname() can fail under moderate to high
	load under some circumstances.  This will exhibit itself as
	the message ``554 makeconnection: service "smtp" unknown''.
	The problem has been traced to one or more blank lines in
	/etc/services on the NIS server machine.  Delete these
	and it should work.  This info is thanks to Brian Bartholomew
	<[e-mail]> of I-Kinetics, Inc.

	NOTE: The SunOS 4.X linker uses library paths specified during
	compilation using -L for run-time shared library searches.
	Therefore, it is vital that relative and unsafe directory paths not
	be used when compiling sendmail.

SunOS 4.0.2 (Sun 386i)
	Date: Fri, 25 Aug 1995 11:13:58 +0200 (MET DST)
	From: [e-mail]

	Sendmail 8.7.Beta.12 compiles and runs nearly out of the box with the
	following changes:
	* Don't use /usr/5bin in your PATH, but make /usr/5bin/uname
	  available as "uname" command.
	* Use the defines "-DBSD4_3 -DNAMED_BIND=0" in
	  devtools/OS/SunOS.4.0, which is selected via the "uname" command.
	I recommend to make available the db-library on the system first
	(and change the Makefile to use this library).
	Note that the sendmail.cf and aliases files are found in /etc.

SunOS 4.1.3, 4.1.3_U1
	Sendmail causes crashes on SunOS 4.1.3 and 4.1.3_U1.  According
	to Sun bug number 1077939:

	If an application does a getsockopt() on a SOCK_STREAM (TCP) socket
	after the other side of the connection has sent a TCP RESET for
	the stream, the kernel gets a Bus Trap in the tcp_ctloutput() or
	ip_ctloutput() routine.

	For 4.1.3, this is fixed in patch 100584-08, available on the
	Sunsolve 2.7.1 or later CDs.  For 4.1.3_U1, this was fixed in patch
	101790-01 (SunOS 4.1.3_U1: TCP socket and reset problems), later
	obsoleted by patch 102010-05.

	Sun patch 100584-08 is not currently publicly available on their
	ftp site but a user has reported it can be found at other sites
	using a web search engine.

Solaris 2.x (SunOS 5.x)
	To compile for Solaris, the Makefile built by Build must
	include a SOLARIS definition which reflects the Solaris version
	(i.e. -DSOLARIS=20400 for 2.4 or -DSOLARIS=20501 for 2.5.1).
	If you are using gcc, make sure -I/usr/include is not used (or
	it might complain about TopFrame).  If you are using Sun's cc,
	make sure /opt/SUNWspro/bin/cc is used instead of /usr/ucb/cc
	(or it might complain about tm_zone).

	The Solaris "syslog" function is apparently limited to something
	about 90 characters because of a kernel limitation.  If you have
	source code, you can probably up this number.  You can get patches
	that fix this problem: the patch ids are:

		Solaris 2.1	100834
		Solaris 2.2	100999
		Solaris 2.3	101318

	Be sure you have the appropriate patch installed or you won't
	see system logging.