xref: /csrg-svn/usr.sbin/sendmail/src/READ_ME (revision 68575)
135062Sbostic# Copyright (c) 1983 Eric P. Allman
248582Sbostic# Copyright (c) 1988 The Regents of the University of California.
333728Sbostic# All rights reserved.
433728Sbostic#
548582Sbostic# %sccs.include.redist.sh%
633728Sbostic#
7*68575Seric#	@(#)READ_ME	8.82 (Berkeley) 03/22/95
833728Sbostic#
948582Sbostic
109881SericThis directory contains the source files for sendmail.
115369Seric
1260565SericFor detailed instructions, please read the document ../doc/op.me:
135369Seric
1460565Seric	eqn ../doc/op.me | pic | ditroff -me
155369Seric
1668543Seric*********************
1768543Seric!! DO NOT USE MAKE !!  to compile sendmail -- instead, use the
1868543Seric*********************  "makesendmail" script located in the src
1968543Sericdirectory.  It will find an appropriate Makefile, and create an
2068543Sericappropriate obj.* subdirectory so that multiplatform support
2168543Sericworks easily.
2268543Seric
2365366SericThe Makefile is for the new (4.4BSD) Berkeley make and uses syntax
2465366Sericthat is not recognized by older makes.  It also has assumptions
2565366Sericabout the 4.4 file system layout built in.  See below for details
2665366Sericabout other Makefiles.
2757418Seric
2868543SericIf you are porting to a new architecture for which there is no existing
2968543SericMakefile, you might start with Makefile.dist.  This works on the old
3068543Serictraditional make, but isn't customized for any particular architecture.
3164501Seric
3268543Seric	**************************************************
3368543Seric	**  Read below for more details of Makefiles.	**
3468543Seric	**************************************************
3557418Seric
3665000Seric**************************************************************************
3765000Seric**  IMPORTANT:  DO NOT USE OPTIMIZATION (``-O'') IF YOU ARE RUNNING	**
3865000Seric**  GCC 2.4.x or 2.5.x.  THERE IS A BUG IN THE GCC OPTIMIZER THAT	**
3965000Seric**  CAUSES SENDMAIL COMPILES TO FAIL MISERABLY.				**
4065000Seric**************************************************************************
4164272Seric
4265000SericJim Wilson of Cygnus believes he has found the problem -- it will
4365000Sericprobably be fixed in GCC 2.5.6 -- but until this is verified, be
4465000Sericvery suspicious of gcc -O.
4564701Seric
46*68575SericThis problem is reported to have been fixed in gcc 2.6.
47*68575Seric
4865000Seric**************************************************************************
4965000Seric**  IMPORTANT:  Read the appropriate paragraphs in the section on	**
5065000Seric**  ``Operating System and Compile Quirks''.				**
5165000Seric**************************************************************************
5264718Seric
5365000Seric
5465366Seric+-----------+
5565366Seric| MAKEFILES |
5665366Seric+-----------+
5765366Seric
5868543SericBy far, the easiest way to compile sendmail is to use the "makesendmail"
5968543Sericscript:
6068543Seric
6168543Seric	sh makesendmail
6268543Seric
6368543SericThis uses the "uname" command to figure out what architecture you are
6468543Sericon and selects a proper Makefile accordingly.  It also creates a
6568543Sericsubdirectory per object format, so that multiarchitecture support is
6668543Sericeasy.  In general this should be all you need.  However, if for some
6768543Sericreason this doesn't work (e.g., NeXT systems don't have the "uname"
6868543Sericcommand) you may have to set up your compile environment by hand.
6968543Seric
7065366SericThe "Makefile"s in these directories are from 4.4 BSD, and hence
7165366Sericreally only work properly if you are on a 4.4 system.  In particular,
7265366Sericthey use new syntax that will not be recognized on old make programs,
7365366Sericand some of them do things like ``.include ../../Makefile.inc'' to
7465366Sericpick up some system defines.  If you are getting sendmail separately,
7565366Sericthese files won't be included in the distribution, as they are
7665366Sericoutside of the sendmail tree.
7765366Seric
7865366SericInstead, you should use one of the other Makefiles, such as
7965366SericMakefile.SunOS for a SunOS system, and so forth.  These should
8065366Sericwork with the version of make that is appropriate for that
8168543Sericsystem.  All other Makefiles are in the "src/Makefiles" subdirectory.
8268543SericThey use the version of make that is native for that system.  These
8368543Sericare the Makefiles that I use, and they have "Berkeley quirks" in them.
8468543SericI can't guarantee that they will work unmodified in your environment.
8568543SericIn particular, Many of them include -I/usr/sww/include/db and
8668543Seric-L/usr/sww/lib -- these are Berkeley's locations in the ``Software
8768543SericWarehouse'' for the new database libraries, described below.  You don't
8868543Serichave to remove these definitions if you don't have these directories,
8968543Sericbut you may have to remove -DNEWDB from the DBMDEF definition.
9065366Seric
9165366SericPlease look for an appropriate Makefile before you start trying to
9265366Sericcompile with Makefile or Makefile.dist.
9365366Seric
9465366SericIf you want to port the new Berkeley make, you can get it from
9565366Sericftp.uu.net in the directory /systems/unix/bsd-sources/usr.bin/make.
9665366SericDiffs and instructions for building this version of make under
9765366SericSunOS 4.1.x are available on ftp.css.itd.umich.edu in
9865366Seric/pub/systems/sun/Net2-make.sun4.diff.Z.  Diffs and instructions
9965366Sericfor building this version of make under IBM AIX 3.2.4 are available
10065366Sericon ftp.uni-stuttgart.de in /sw/src/patches/bsd-make-rus-patches.
10168543SericFor Ultrix, try ftp.vix.com:~ftp/pub/patches/pmake-for-ultrix.Z.
10265366SericPaul Southworth <pauls@umich.edu> published a description of porting
10365366Sericthis make in comp.unix.bsd.
10465366Seric
10565366SericThe complete text of the Makefile.inc that is in the parent of the
10665366Sericsendmail directory is:
10765366Seric
10865366Seric	#	@(#)Makefile.inc	8.1 (Berkeley) 6/6/93
10965366Seric
11065366Seric	BINDIR?=	/usr/sbin
11165366Seric
11265366Seric
11364250Seric+----------------------+
11464250Seric| DATABASE DEFINITIONS |
11564250Seric+----------------------+
11664250Seric
11764250SericThere are several database formats that can be used for the alias files
11864250Sericand for general maps.  When used for alias files they interact in an
11964250Sericattempt to be back compatible.
12064250Seric
12164250SericThe three options are NEWDB (the new Berkeley DB package), NDBM (the
12264250Sericolder DBM implementation -- the very old V7 implementation is no
12364250Sericlonger supported), and NIS (Network Information Services).  Used alone
12464376Sericthese just include the support they indicate.  [If you are using NEWDB,
12568543Sericget the latest version from FTP.CS.Berkeley.EDU in /ucb/4bsd/db.tar.Z
12668543Seric(or db.tar.gz).  DO NOT use the version from the Net2 distribution!
12768543SericHowever, if you are on BSD/386 or 386BSD-based systems, use the one
12868543Sericthat already exists on your system.  You may need to #define OLD_NEWDB
12968543Seric1 to do this.]
13064250Seric
13165910Seric[NOTE WELL: it is CRITICAL that you remove ndbm.o from libdb.a and
13265910Sericndbm.h from the appropriate include directories if you want to get
13365910Sericndbm support.  These files OVERRIDE calls to ndbm routines -- in
13465910Sericparticular, if you leave ndbm.h in, you can find yourself using
13565910Sericthe new db package even if you don't define NEWDB.]
13665910Seric
13764250SericIf NEWDB and NDBM are defined (but not NIS), then sendmail will read
13864250SericNDBM format alias files, but the next time a newaliases is run the
13964250Sericformat will be converted to NEWDB; that format will be used forever
14064250Sericmore.  This is intended as a transition feature.  [Note however that
14164250Sericthe NEWDB library also catches and maps NDBM calls; you will have to
14264250Sericback out this feature to get this to work.  See ``Quirks'' section
14364250Sericbelow for details.]
14464250Seric
14564250SericIf all three are defined, sendmail operates as described above, and also
14664250Sericlooks for the file /var/yp/Makefile.  If it exists, newaliases will
14764250Sericbuild BOTH the NEWDB and NDBM format alias files.  However, it will
14864250Sericonly use the NEWDB file; the NDBM format file is used only by the
14964250SericNIS subsystem.
15064250Seric
15164250SericIf NDBM and NIS are defined (regardless of the definition of NEWDB
15264250Sericor the existance of /var/yp/Makefile), sendmail adds the special
15364250Serictokens "YP_LAST_MODIFIED" and "YP_MASTER_NAME", both of which are
15464250Sericrequired if the NDBM file is to be used as an NIS map.
15564250Seric
15668543SericThere is also preliminary support for NIS+ (-DNISPLUS), Hesiod
15768543Seric(-DHESIOD), and NetInfo (-DNETINFO).  These have not been well
15868543Serictested.
15964250Seric
16068543SericAll of -DNEWDB, -DNDBM, -DNIS, -DNISPLUS, -DHESIOD, and -DNETINFO are
16168543Sericnormally defined in the DBMDEF line in the Makefile.
16264250Seric
16368543Seric
16464035Seric+---------------+
16564035Seric| COMPILE FLAGS |
16664035Seric+---------------+
16764035Seric
16860565SericWhereever possible, I try to make sendmail pull in the correct
16960584Sericcompilation options needed to compile on various environments based on
17060584Sericautomatically defined symbols.  Some machines don't seem to have useful
17160584Sericsymbols availble, requiring the following compilation flags in the
17260584SericMakefile:
17360565Seric
17460565SericSOLARIS		Define this if you are running Solaris 2.0 or higher.
17565000SericSOLARIS_2_3	Define this if you are running Solaris 2.3 or higher.
17665108SericSUNOS403	Define this if you are running SunOS 4.0.3.
17764077SericNeXT		Define this if you are on a NeXT box.  (This one may
17864072Seric		be pre-defined for you.)  There are other hacks you
17964072Seric		have to make -- see below.
18060565Seric_AIX3		Define this if you are IBM AIX 3.x.
18163965SericRISCOS		Define this if you are running RISC/os from MIPS.
18266335SericIRIX		Define this if you are running IRIX from SGI.
18364501Seric_SCO_unix_	Define this if you are on SCO UNIX.
18465095Seric_SCO_unix_4_2	Define this if you are on SCO Open Server 3.2v4.
18568543SericDGUX		Define this if you are on DG/UX 5.4.3 or later
18668543SericDGUX_5_4_2	Define this if you are on DG/UX systems prior to 5.4.3.
18768543SericNonStop_UX_BXX	Define this if you are on a Tandem NonStop-UX release
18868543Seric		Bxx system.
18968543SericIRIX64		Define this if you are on an IRIX64 system.
19060565Seric
19160584SericIf you are a system that sendmail has already been ported to, you
19260584Sericprobably won't have to touch these.  But if you are porting, you may
19363962Serichave to tweak the following compilation flags in conf.h in order to
19463962Sericget it to compile and link properly:
19560565Seric
19665195SericSYSTEM5		Adjust for System V (not necessarily Release 4).
19764035SericSYS5SIGNALS	Use System V signal semantics -- the signal handler
19864035Seric		is automatically dropped when the signal is caught.
19964035Seric		If this is not set, use POSIX/BSD semantics, where the
20064035Seric		signal handler stays in force until an exec or an
20164035Seric		explicit delete.  Implied by SYSTEM5.
20264706SericSYS5SETPGRP	Use System V setpgrp() semantics.  Implied by SYSTEM5.
20364035SericHASFLOCK	Set this if you prefer to use the flock(2) system call
20464035Seric		rather than using fcntl-based locking.  Fcntl locking
20564035Seric		has some semantic gotchas, but many vendor systems
20664035Seric		also interface it to lockd(8) to do NFS-style locking.
20764035Seric		For this reason, this should not be set unless you
20864035Seric		don't have an alternative.
20960565SericHASUNAME	Set if you have the "uname" system call.  Implied by
21060565Seric		SYSTEM5.
21163962SericHASUNSETENV	Define this if your system library has the "unsetenv"
21263962Seric		subroutine.
21360565SericHASSETSID	Define this if you have the setsid(2) system call.  This
21460565Seric		is implied if your system appears to be POSIX compliant.
21560565SericHASINITGROUPS	Define this if you have the initgroups(3) routine.
21663753SericHASSETVBUF	Define this if you have the setvbuf(3) library call.
21763753Seric		If you don't, setlinebuf will be used instead.  This
21863753Seric		defaults on if your compiler defines __STDC__.
21963902SericHASSETREUID	Define this if you have setreuid(2) ***AND*** root can
22063902Seric		use setreuid to change to an arbitrary user.  This second
22163902Seric		condition is not satisfied on AIX 3.x.  You may find that
22263902Seric		your system has setresuid(2), (for example, on HP-UX) in
22363902Seric		which case you will also have to #define setreuid(r, e)
22463902Seric		to be the appropriate call.  Some systems (such as Solaris)
22565000Seric		have a compatibility routine that doesn't work properly,
22665000Seric		but may have "saved user ids" properly implemented so you
22765000Seric		can ``#define setreuid(r, e) seteuid(e)'' and have it work.
22863902Seric		The important thing is that you have a call that will set
22965000Seric		the effective uid independently of the real or saved uid
23065000Seric		and be able to set the effective uid back again when done.
23165000Seric		There's a test program in ../test/t_setreuid.c that will
23265000Seric		try things on your system.  Setting this improves the
23365000Seric		security, since sendmail doesn't have to read .forward
23465000Seric		and :include: files as root.  There are certain attacks
23565000Seric		that may be unpreventable without this call.
23665000SericHASLSTAT	Define this if you have symbolic links (and thus the
23765000Seric		lstat(2) system call).  This improves security.  Unlike
23865000Seric		most other options, this one is on by default, so you
23965000Seric		need to #undef it in conf.h if you don't have symbolic
24065000Seric		links (these days everyone does).
24168543SericHASSETRLIMIT	Define this to 1 if you have the setrlimit(2) syscall.
24268543Seric		You can define it to 0 to force it off.  It is assumed
24368543Seric		if you are running a BSD-like system.
24468543SericHASULIMIT	Define this if you have the ulimit(2) syscall (System V
24568543Seric		style systems).  HASSETRLIMIT overrides, as it is more
24668543Seric		general.
24765206SericNEEDGETOPT	Define this if you need a reimplementation of getopt(3).
24865206Seric		On some systems, getopt does very odd things if called
24965206Seric		to scan the arguments twice.  This flag will ask sendmail
25065206Seric		to compile in a local version of getopt that works
25165206Seric		properly.
25265206SericNEEDSTRTOL	Define this if your standard C library does not define
25365206Seric		strtol(3).  This will compile in a local version.
25465206SericNEEDVPRINTF	Define this if your standard C library does not define
25565206Seric		vprintf(3).  Note that the resulting fake implementation
25665206Seric		is not very elegant and may not even work on some
25765206Seric		architectures.
25866792SericNEEDFSYNC	Define this if your standard C library does not define
25966792Seric		fsync(2).  This will try to simulate the operation using
26066792Seric		fcntl(2); if that is not available it does nothing, which
26166792Seric		isn't great, but at least it compiles and runs.
26265211SericHASGETUSERSHELL	Define this to 1 if you have getusershell(3) in your
26365211Seric		standard C library.  If this is not defined, or is defined
26465211Seric		to be 0, sendmail will scan the /etc/shells file (no
26565211Seric		NIS-style support, defaults to /bin/sh and /bin/csh if
26665211Seric		that file does not exist) to get a list of unrestricted
26765211Seric		user shells.  This is used to determine whether users
26865211Seric		are allowed to forward their mail to a program or a file.
26963937SericGIDSET_T	The type of entries in a gidset passed as the second
27063937Seric		argument to getgroups(2).  Historically this has been an
27163937Seric		int, so this is the default, but some systems (such as
27263937Seric		IRIX) pass it as a gid_t, which is an unsigned short.
27363937Seric		This will make a difference, so it is important to get
27463937Seric		this right!  However, it is only an issue if you have
27563937Seric		group sets.
27663968SericSLEEP_T		The type returned by the system sleep() function.
27763968Seric		Defaults to "unsigned int".  Don't worry about this
27863968Seric		if you don't have compilation problems.
27963974SericARBPTR_T	The type of an arbitrary pointer -- defaults to "void *".
28063974Seric		If you are an very old compiler you may need to define
28163974Seric		this to be "char *".
28260584SericLA_TYPE		The type of load average your kernel supports.  These
28366301Seric		can be one of:
28466301Seric		LA_ZERO (1) -- it always returns the load average as
28566301Seric			"zero" (and does so on all architectures).
28666301Seric		LA_SUBR (4) if you have the getloadavg(3) routine,
28764376Seric		LA_MACH (5) to use MACH-style load averages (calls
28866301Seric			processor_set_info()),
28966301Seric		LA_PROCSTR (7) to read /proc/loadavg and interpret it
29066301Seric			as a string representing a floating-point
29166301Seric			number (Linux-style),
29266301Seric		LA_FLOAT (3) if you read kmem and interpret the value
29366301Seric			as a floating point number,
29466301Seric		LA_INT (2) to interpret as a long integer,
29566301Seric		LA_SHORT (6) to interpret as a short integer.
29666301Seric		These last three have several other parameters that they
29766301Seric		try to divine: the name of your kernel, the name of the
29866301Seric		variable in the kernel to examine, the number of bits of
29966301Seric		precision in a fixed point load average, and so forth.
30066301Seric		In desperation, use LA_ZERO.  The actual code is in
30166301Seric		conf.c -- it can be tweaked if you are brave.
30265752SericSFS_TYPE	Encodes how your kernel can locate the amount of free
30365752Seric		space on a disk partition.  This can be set to SFS_NONE
30465752Seric		(0) if you have no way of getting this information,
30565752Seric		SFS_USTAT (1) if you have the ustat(2) system call,
30665752Seric		SFS_4ARGS (2) if you have a four-argument statfs(2)
30765752Seric		system call (and the include file is <sys/statfs.h>),
30868543Seric		SFS_VFS (3), SFS_MOUNT (4), SFS_STATFS (5) if you have
30968543Seric		the two-argument statfs(2) system call with includes in
31068543Seric		<sys/vfs.h>, <sys/mount.h>, or <sys/statfs.h> respectively,
31168543Seric		or SFS_STATVFS (6) if you have the two-argument statvfs(2)
31268543Seric		call.  The default if nothing is defined is SFS_NONE.
31368543SericSFS_BAVAIL	with SFS_4ARGS hou can also set SFS_BAVAIL to the field name
31468543Seric		in the statfs structure that holds the useful information;
31568543Seric		this defaults to f_bavail.
31668543SericSPT_TYPE	Encodes how your system can display what a process is doing
31768543Seric		on a ps(1) command (SPT stands for Set Process Title).  Can
31868543Seric		be set to:
31968543Seric		SPT_NONE (0) -- Don't try to set the process title at all.
32068543Seric		SPT_REUSEARGV (1) -- Pad out your argv with the information;
32168543Seric			this is the default if none specified.
32268543Seric		SPT_BUILTIN (2) -- The system library has setproctitle.
32368543Seric		SPT_PSTAT (3) -- Use the PSTAT_SETCMD option to pstat(2)
32468543Seric			to set the process title; this is used by HP-UX.
32568543Seric		SPT_PSSTRINGS (4) -- Use the magic PS_STRINGS pointer (4.4BSD).
32668543SericSPT_PADCHAR	Character used to pad the process title; if undefined,
32768543Seric		the space character (0x20) is used.  This is ignored if
32868543Seric		SPT_TYPE != SPT_REUSEARGV
32963962SericERRLIST_PREDEFINED
33063962Seric		If set, assumes that some header file defines sys_errlist.
33163962Seric		This may be needed if you get type conflicts on this
33263962Seric		variable -- otherwise don't worry about it.
33364562SericWAITUNION	The wait(2) routine takes a "union wait" argument instead
33464562Seric		of an integer argument.  This is for compatibility with
33564562Seric		old versions of BSD.
33665000SericSCANF		You can set this to extend the F command to accept a
33765000Seric		scanf string -- this gives you a primitive parser for
33865000Seric		class definitions -- BUT it can make you vulnerable to
33965000Seric		core dumps if the target file is poorly formed.
34065095SericSYSLOG_BUFSIZE	You can define this to be the size of the buffer that
34165095Seric		syslog accepts.  If it is not defined, it assumes a
34265095Seric		1024-byte buffer.  If the buffer is very small (under
34365095Seric		256 bytes) the log message format changes -- each
34465095Seric		e-mail message will log many more messages, since it
34565095Seric		will log each piece of information as a separate line
34665095Seric		in syslog.
34766318SericBROKEN_RES_SEARCH
34866318Seric		On Ultrix (and maybe other systems?) if you use the
34966318Seric		res_search routine with an unknown host name, it returns
35066318Seric		-1 but sets h_errno to 0 instead of HOST_NOT_FOUND.  If
35166318Seric		you set this, sendmail considers 0 to be the same as
35266318Seric		HOST_NOT_FOUND.
35368543SericNAMELISTMASK	If defined, values returned by nlist(3) are masked
35468543Seric		against this value before use -- a common value is
35568543Seric		0x7fffffff to strip off the top bit.
35660565Seric
35764035Seric
35868543Seric
35964035Seric+-----------------------+
36064035Seric| COMPILE-TIME FEATURES |
36164035Seric+-----------------------+
36264035Seric
36360584SericThere are a bunch of features that you can decide to compile in, such
36460584Sericas selecting various database packages and special protocol support.
36560584SericSeveral are assumed based on other compilation flags -- if you want to
36660584Seric"un-assume" something, you probably need to edit conf.h.  Compilation
36760584Sericflags that add support for special features include:
36860565Seric
36960565SericNDBM		Include support for "new" DBM library for aliases and maps.
37064250Seric		Normally defined in the Makefile.
37160565SericNEWDB		Include support for Berkeley "db" package (hash & btree)
37264250Seric		for aliases and maps.  Normally defined in the Makefile.
37366843SericOLD_NEWDB	If non-zero, the version of NEWDB you have is the old
37466843Seric		one that does not include the "fd" call.  This call was
37566843Seric		added in version 1.5 of the Berkeley DB code.  If you
37666843Seric		use -DOLD_NEWDB=0 it forces you to use the new interface.
37760565SericNIS		Define this to get NIS (YP) support for aliases and maps.
37864250Seric		Normally defined in the Makefile.
37960565SericUSERDB		Include support for the User Information Database.  Implied
38064250Seric		by NEWDB in conf.h.
38165000SericIDENTPROTO	Define this as 1 to get IDENT (RFC 1413) protocol support.
38260565Seric		This is assumed unless you are running on Ultrix or
38360565Seric		HP-UX, both of which have a problem in the UDP
38465000Seric		implementation.  You can define it to be 0 to explicitly
38565000Seric		turn off IDENT protocol support.
38660565SericLOG		Set this to get syslog(3) support.  Defined by default
38760584Seric		in conf.h.  You want this if at all possible.
38860565SericNETINET		Set this to get TCP/IP support.  Defined by default
38960584Seric		in conf.h.  You probably want this.
39060565SericNETISO		Define this to get ISO networking support.
39160565SericSMTP		Define this to get the SMTP code.  Implied by NETINET
39260565Seric		or NETISO.
39360565SericNAMED_BIND	Define this to get DNS (name daemon) support, including
39460565Seric		MX support.  The specs you must use this if you run
39560565Seric		SMTP.  Defined by default in conf.h.
39660565SericQUEUE		Define this to get queueing code.  Implied by NETINET
39760584Seric		or NETISO; required by SMTP.  This gives you other good
39860584Seric		stuff -- it should be on.
39960565SericDAEMON		Define this to get general network support.  Implied by
40060584Seric		NETINET or NETISO.  Defined by default in conf.h.  You
40160584Seric		almost certainly want it on.
40260565SericMATCHGECOS	Permit fuzzy matching of user names against the full
40360565Seric		name (GECOS) field in the /etc/passwd file.  This should
40460565Seric		probably be on, since you can disable it from the config
40560584Seric		file if you want to.  Defined by default in conf.h.
40660565Seric
40764035Seric
40865000Seric+---------------------+
40965000Seric| DNS/RESOLVER ISSUES |
41065000Seric+---------------------+
41165000Seric
41265000SericMany systems have old versions of the resolver library.  At a minimum,
41365000Sericyou should be running BIND 4.8.3; older versions may compile, but they
41465000Serichave known bugs that should give you pause.
41565000Seric
41665000SericCommon problems in old versions include "undefined" errors for
41765000Sericdn_skipname.
41865000Seric
41965000SericSome people have had a problem with BIND 4.9; it uses some routines
42065000Sericthat it expects to be externally defined such as strerror().  It may
42165000Serichelp to link with "-l44bsd" to solve this problem.
42265000Seric
42365095Seric!PLEASE! be sure to link with the same version of the resolver as
42465095Sericthe header files you used -- some people have used the 4.9 headers
42565095Sericand linked with BIND 4.8 or vice versa, and it doesn't work.
42665095SericUnfortunately, it doesn't fail in an obvious way -- things just
42765954Sericsubtly don't work.
42865000Seric
42965095Seric
43064035Seric+-------------------------------------+
43164035Seric| OPERATING SYSTEM AND COMPILE QUIRKS |
43264035Seric+-------------------------------------+
43364035Seric
43465095SericGCC 2.5.x problems  *** IMPORTANT ***
43565095Seric	Date: Mon, 29 Nov 93 19:08:44 PST
43665095Seric	From: wilson@cygnus.com (Jim Wilson)
43765095Seric	Message-Id: <9311300308.AA04608@cygnus.com>
43865095Seric	To: kenner@vlsi1.ultra.nyu.edu
43965095Seric	Subject: [cattelan@thebarn.com: gcc 2.5.4-2.5.5 -O bug]
44065095Seric	Cc: cattelan@thebarn.com, rms@gnu.ai.mit.edu, sendmail@cs.berkeley.edu
44165095Seric
44265095Seric	This fixes a problem that occurs when gcc 2.5.5 is used to compile
44365095Seric	sendmail 8.6.4 with optimization on a sparc.
44465095Seric
44565095Seric	Mon Nov 29 19:00:14 1993  Jim Wilson  (wilson@sphagnum.cygnus.com)
44665095Seric
44765095Seric		* reload.c (find_reloads_toplev): Replace obsolete reference to
44865095Seric		BYTE_LOADS_*_EXTEND with LOAD_EXTEND_OP.
44965095Seric
45065095Seric	*** clean-ss-931128/reload.c    Sun Nov 14 16:20:01 1993
45165095Seric	--- ss-931128/reload.c  Mon Nov 29 18:52:55 1993
45265095Seric	*************** find_reloads_toplev (x, opnum, type, ind
45365095Seric	*** 3888,3894 ****
45465095Seric		 force a reload in that case.  So we should not do anything here.  */
45565095Seric
45665095Seric		else if (regno >= FIRST_PSEUDO_REGISTER
45765095Seric	! #if defined(BYTE_LOADS_ZERO_EXTEND) || defined(BYTE_LOADS_SIGN_EXTEND)
45865095Seric		       && (GET_MODE_SIZE (GET_MODE (x))
45965095Seric			   <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))))
46065095Seric	  #endif
46165095Seric	--- 3888,3894 ----
46265095Seric		 force a reload in that case.  So we should not do anything here.  */
46365095Seric
46465095Seric		else if (regno >= FIRST_PSEUDO_REGISTER
46565095Seric	! #ifdef LOAD_EXTEND_OP
46665095Seric		       && (GET_MODE_SIZE (GET_MODE (x))
46765095Seric			   <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))))
46865095Seric	  #endif
46965095Seric
47065095Seric
47164376SericSunOS 4.x (Solaris 1.x)
47264376Seric	You may have to use -lresolv on SunOS.  However, beware that
47364376Seric	this links in a new version of gethostbyname that does not
47464376Seric	understand NIS, so you must have all of your hosts in DNS.
47564035Seric
47664798Seric	Some people have reported problems with the SunOS version of
47764798Seric	-lresolv and/or in.named, and suggest that you get a newer
47864798Seric	version.  The symptoms are delays when you connect to the
47965000Seric	SMTP server on a SunOS machine or having your domain added to
48065000Seric	addresses inappropriately.  There is a version of BIND
48164798Seric	version 4.9 on gatekeeper.DEC.COM in pub/BSD/bind/4.9.
48264798Seric
48364400Seric	There is substantial disagreement about whether you can make
48464400Seric	this work with resolv+, which allows you to specify a search-path
48564400Seric	of services.  Some people report that it works fine, others
48664400Seric	claim it doesn't work at all (including causing sendmail to
48764400Seric	drop core when it tries to do multiple resolv+ lookups for a
48864400Seric	single job).  I haven't tried resolv+, as we use DNS exclusively.
48964400Seric
49064400Seric	Should you want to try resolv+, it is on ftp.uu.net in
49164400Seric	/networking/ip/dns.
49264400Seric
49368543Seric	Apparently getservbyname() can fail under moderate to high
49468543Seric	load under some circumstances.  This will exhibit itself as
49568543Seric	the message ``554 makeconnection: service "smtp" unknown''.
49668543Seric	The problem has been traced to one or more blank lines in
49768543Seric	/etc/services on the NIS server machine.  Delete these
49868543Seric	and it should work.  This info is thanks to Brian Bartholomew
49968543Seric	<bb@math.ufl.edu> of I-Kinetics, Inc.
50068543Seric
50164376SericSolaris 2.x (SunOS 5.x)
50264376Seric	To compile for Solaris, be sure you use -DSOLARIS.
50364376Seric
50466329Seric	To the best of my knowledge, Solaris does not have the
50566329Seric	gethostbyname problem described above.  However, it does
50666329Seric	have another one:
50766329Seric
50864364Seric	From a correspondent:
50964364Seric
51064364Seric	   For solaris 2.2, I have
51164364Seric
51264364Seric		hosts:      files dns
51364364Seric
51464364Seric	   in /etc/nsswitch.conf and /etc/hosts has to have the fully
51564364Seric	   qualified host name. I think "files" has to be before "dns"
51664364Seric	   in /etc/nsswitch.conf during bootup.
51764364Seric
51866329Seric	From another correspondent:
51964376Seric
52066329Seric	   When running sendmail under Solaris, the gethostbyname()
52166329Seric	   hack in conf.c which should perform proper canonicalization
52266329Seric	   of host names could fail.  Result: the host name is not
52366329Seric	   canonicalized despite the hack, and you'll have to define $j
52466329Seric	   and $m in sendmail.cf somewhere.
52566329Seric
52666329Seric	   The reason could be that /etc/nsswitch.conf is improperly
52766329Seric	   configured (at least from sendmail's point of view).  For
52866329Seric	   example, the line
52966329Seric
53066329Seric		hosts:      files nisplus dns
53166329Seric
53266329Seric	   will make gethostbyname() look in /etc/hosts first, then ask
53366329Seric	   nisplus, then dns.  However, if /etc/hosts does not contain
53466329Seric	   the full canonicalized hostname, then no amount of
53566329Seric	   gethostbyname()s will work.
53666329Seric
53766329Seric	   Solution (or rather, a workaround): Ask nisplus first, then
53866329Seric	   dns, then local files:
53966329Seric
54066329Seric		hosts:      nisplus dns [NOTFOUND=return] files
54166329Seric
54264385Seric	The Solaris "syslog" function is apparently limited to something
54364385Seric	about 90 characters because of a kernel limitation.  If you have
54466023Seric	source code, you can probably up this number.  You can get patches
54566023Seric	that fix this problem: the patch ids are:
54664385Seric
54766023Seric		Solaris 2.1	100834
54866023Seric		Solaris 2.2	100999
54966024Seric		Solaris 2.3	101318
55066023Seric
55166023Seric	Be sure you have the appropriate patch installed or you won't
55266023Seric	see system logging.
55366023Seric
55464250SericOSF/1
55565000Seric	If you are compiling on OSF/1 (DEC Alpha), you must use
55665616Seric	-L/usr/shlib (otherwise it core dumps on startup).  You may also
55765000Seric	need -mld to get the nlist() function, although some versions
55865000Seric	apparently don't need this.
55965000Seric
56065000Seric	Also, the enclosed makefile removed /usr/sbin/smtpd; if you need
56165000Seric	it, just create the link to the sendmail binary.
56257977Seric
56366335SericIRIX
56466335Seric	The header files on SGI IRIX are completely prototyped, and as
56566335Seric	a result you can sometimes get some warning messages during
56666335Seric	compilation.  These can be ignored.  There are two errors in
56766335Seric	deliver only if you are using gcc, both of the form ``warning:
56866335Seric	passing arg N of `execve' from incompatible pointer type''.
56966335Seric	Also, if you compile with -DNIS, you will get a complaint
57066335Seric	about a declaration of struct dom_binding in a prototype
57166335Seric	when compiling map.c; this is not important because the
57266335Seric	function being prototyped is not used in that file.
57366335Seric
57468543Seric	In order to compile sendmail you will have had to install
57568543Seric	the developers' option in order to get the necessary include
57668543Seric	files.
57768543Seric
57864250SericNeXT
57964250Seric	If you are compiling on NeXT, you will have to create an empty
58064250Seric	file "unistd.h" and create a file "dirent.h" containing:
58163753Seric
58264250Seric		#include <sys/dir.h>
58364250Seric		#define dirent	direct
58464035Seric
58564250Seric	(The Makefile.NeXT should try to do both of these for you.)
58664077Seric
58764364Seric	Apparently, there is a bug in getservbyname on Nextstep 3.0
58864364Seric	that causes it to fail under some circumstances with the
58964364Seric	message "SYSERR: service "smtp" unknown" logged.  You should
59064364Seric	be able to work around this by including the line:
59164364Seric
59264670Seric		OOPort=25
59364364Seric
59464364Seric	in your .cf file.
59564364Seric
59664376Seric	You may have to use -DNeXT.
59764376Seric
59865000SericBSDI (BSD/386) 1.0, NetBSD 0.9, FreeBSD 1.0
59965000Seric	The "m4" from BSDI won't handle the config files properly.
60065000Seric	I haven't had a chance to test this myself.
60157943Seric
60265000Seric	The M4 shipped in FreeBSD and NetBSD 0.9 don't handle the config
60365000Seric	files properly. One must use either GNU m4 1.1 or the PD-M4
60465000Seric	recently posted in comp.os.386bsd.bugs (and maybe others).
60565000Seric	NetBSD-current includes the PD-M4 (as stated in the NetBSD file
60665000Seric	CHANGES).
60765000Seric
60865000Seric	FreeBSD 1.0 RELEASE has uname(2) now. Use -DUSEUNAME in order to
60965000Seric	use it (look into Makefile.FreeBSD). NetBSD-current may have
61065000Seric	it too but it has not been verified.
61165000Seric
61265000Seric	You cannot port the latest version of the Berkeley db library
61365000Seric	and use it with sendmail without recompiling the world.  This
61465000Seric	is because C library routines use the older version which have
61565000Seric	incompatible header files -- the result is that it can't read
61665000Seric	other system files, such as /etc/passwd, unless you use the
61765000Seric	new db format throughout your system.  You should normally just
61865000Seric	use the version of db supplied in your release.  You may need
61966843Seric	to use -DOLD_NEWDB=1 to make this work -- this turns off some
62065000Seric	new interface calls (for file locking) that are not in older
62165000Seric	versions of db.  You'll get compile errors if you need this
62265000Seric	flag and don't have it set.
62365000Seric
62464364Seric4.3BSD
62564364Seric	If you are running a "virgin" version of 4.3BSD, you'll have
62664364Seric	a very old resolver and be missing some header files.  The
62764364Seric	header files are simple -- create empty versions and everything
62864364Seric	will work fine.  For the resolver you should really port a new
62964364Seric	version (4.8.3 or later) of the resolver; 4.9 is available on
63064364Seric	gatekeeper.DEC.COM in pub/BSD/bind/4.9.  If you are really
63164364Seric	determined to continue to use your old, buggy version (or as
63264364Seric	a shortcut to get sendmail working -- I'm sure you have the
63364364Seric	best intentions to port a modern version of BIND), you can
63464364Seric	copy ../contrib/oldbind.compat.c into src and add
63564364Seric	oldbind.compat.o to OBJADD in the Makefile.
63664364Seric
63764718SericA/UX
63864718Seric	Date: Tue, 12 Oct 1993 18:28:28 -0400 (EDT)
63964718Seric	From: "Eric C. Hagberg" <hagberg@med.cornell.edu>
64064718Seric	Subject: Fix for A/UX ndbm
64164718Seric
64264718Seric	I guess this isn't really a sendmail bug, however, it is something
64364718Seric	that A/UX users should be aware of when compiling sendmail 8.6.
64464718Seric
64564718Seric	Apparently, the calls that sendmail is using to the ndbm routines
64664718Seric	in A/UX 3.0.x contain calls to "broken" routines, in that the
64764718Seric	aliases database will break when it gets "just a little big"
64864718Seric	(sorry I don't have exact numbers here, but it broke somewhere
64964718Seric	around 20-25 aliases for me.), making all aliases non-functional
65064718Seric	after exceeding this point.
65164718Seric
65264718Seric	What I did was to get the gnu-dbm-1.6 package, compile it, and
65364718Seric	then re-compile sendmail with "-lgdbm", "-DNDBM", and using the
65464718Seric	ndbm.h header file that comes with the gnu-package. This makes
65564718Seric	things behave properly.
65664718Seric
65764718Seric	I suppose porting the New Berkeley db package is another route,
65864718Seric	however, I made a quick attempt at it, and found it difficult
65964718Seric	(not easy at least); the gnu-dbm package "configured" and
66064718Seric	compiled easily.
66164718Seric
66268543SericSCO Unix
66368543Seric	From: Thomas Essebier <tom@stallion.oz.au>
66468543Seric	Organisation:  Stallion Technologies Pty Ltd.
66568543Seric
66668543Seric	It will probably help those who are trying to configure sendmail 8.6.9
66768543Seric	to know that if they are on SCO, they had better set
66868543Seric		OI-dnsrch
66968543Seric	or they will core dump as soon as they try to use the resolver.
67068543Seric	ie. although SCO has _res.dnsrch defined, and is kinda BIND 4.8.3, it
67168543Seric	does not inititialise it, nor does it understand 'search' in
67268543Seric	/etc/named.boot.
67368543Seric		- sigh -
67468543Seric
67564718SericDG/UX
67668543Seric	Doug Anderson <dlander@afterlife.ncsc.mil> has successfully run
67768543Seric	V8 on the DG/UX 5.4.2 and 5.4R3.x platforms under heavy usage.
67868543Seric	Originally, the DG /bin/mail program wasn't compatible with
67968543Seric	the V8 sendmail, since the DG /bin/mail requires the environment
68068543Seric	variable "_FORCE_MAIL_LOCAL_=yes" be set.  Version 8.7 now includes
68168543Seric	this in the environment before invoking the local mailer.  Some
68268543Seric	have used procmail to avoid this problem in the past.  It works
68368543Seric	but some have experienced file locking problems with their DG/UX
68468543Seric	ports of procmail.
68564718Seric
68665820SericApollo DomainOS
68765820Seric	If you are compiling on Apollo, you will have to create an empty
68865820Seric	file "unistd.h" and create a file "dirent.h" containing:
68965820Seric
69065820Seric		#include <sys/dir.h>
69165820Seric		#define dirent	direct
69265820Seric
69365820Seric	(The Makefile.DomainOS will attempt to do both of these for you.)
69465820Seric
69565910SericHP-UX 8.00
69665910Seric	Date: Mon, 24 Jan 1994 13:25:45 +0200
69765910Seric	From: Kimmo Suominen <Kimmo.Suominen@lut.fi>
69865910Seric	Subject: 8.6.5 w/ HP-UX 8.00 on s300
69965910Seric
70065910Seric	Just compiled and fought with sendmail 8.6.5 on a HP9000/360 (ie. a
70165910Seric	series 300 machine) running HP-UX 8.00.
70265910Seric
70365910Seric	I was getting segmentation fault when delivering to a local user.
70465910Seric	With debugging I saw it was faulting when doing _free@libc... *sigh*
70565910Seric	It seems the new implementation of malloc on s300 is buggy as of 8.0,
70665910Seric	so I tried out the one in -lmalloc (malloc(3X)).  With that it seems
70765910Seric	to work just dandy.
70865910Seric
70965910Seric	When linking, you will get the following error:
71065910Seric
71165910Seric	ld: multiply defined symbol _freespace in file /usr/lib/libmalloc.a
71265910Seric
71365910Seric	but you can just ignore it.  You might want to add this info to the
71465910Seric	README file for the future...
71565910Seric
71665910SericLinux
71765910Seric	Something broke between versions 0.99.13 and 0.99.14 of Linux:
71865910Seric	the flock() system call gives errors.  If you are running .14,
71965910Seric	you must not use flock.  You can do this with -DHASFLOCK=0.
72065910Seric
72168487Seric	Around the inclusion of bind-4.9.3 & linux libc-4.6.20, the
72268487Seric	initialization of the _res structure changed.  If /etc/hosts.conf
72368487Seric	was configured as "hosts, bind" the resolver code could return
72468487Seric	"Name server failure" errors.  This is supposedly fixed in
72568487Seric	later versions of libc (>= 4.6.29?), and later versions of
72668487Seric	sendmail (> 8.6.10) try to work around the problem.
72768487Seric
72868487Seric	Some older versions (< 4.6.20?) of the libc/include files conflict
72968487Seric	with sendmail's version of cdefs.h.  Deleting sendmail's version
73068487Seric	on those systems should be non-harmful, and new versions don't care.
73168487Seric
73265910SericAIX
73365910Seric	This version of sendmail does not support MB, MG, and MR resource
73465910Seric	records, which are supported by AIX sendmail.
73565910Seric
73666335SericRISC/os
73766335Seric	RISC/os from MIPS is a merged AT&T/Berkeley system.  When you
73866335Seric	compile on that platform you will get duplicate definitions
73966335Seric	on many files.  You can ignore these.
74066335Seric
74165195SericSystem V Release 4 Based Systems
74265195Seric	There is a single Makefile that is intended for all SVR4-based
74365195Seric	systems (called Makefile.SVR4).  It defines __svr4__, which is
74465195Seric	predefined by some compilers.  If your compiler already defines
74565195Seric	this compile variable, you can delete the definition from the
74665195Seric	Makefile.
74765195Seric
74865195Seric	It's been tested on Dell Issue 2.2.
74965195Seric
75065095SericDELL SVR4
75165095Seric	Date:      Mon, 06 Dec 1993 10:42:29 EST
75265095Seric	From: "Kimmo Suominen" <kim@grendel.lut.fi>
75365095Seric	Message-ID: <2d0352f9.lento29@lento29.UUCP>
75465095Seric	To: eric@cs.berkeley.edu
75565166Seric	Cc: sendmail@cs.berkeley.edu
75665095Seric	Subject:   Notes for DELL SVR4
75765095Seric
75865095Seric	Eric,
75965095Seric
76065095Seric	Here are some notes for compiling Sendmail 8.6.4 on DELL SVR4.  I ran
76165095Seric	across these things when helping out some people who contacted me by
76265095Seric	e-mail.
76365095Seric
76465095Seric	1) Use gcc 2.4.5 (or later?).  Dell distributes gcc 2.1 with their
76565095Seric	   Issue 2.2 Unix.  It is too old, and gives you problems with
76665095Seric	   clock.c, because sigset_t won't get defined in <sys/signal.h>.
76765095Seric	   This is due to a problematic protection rule in there, and is
76865095Seric	   fixed with gcc 2.4.5.
76965095Seric
77065095Seric	2) If you don't use the new Berkeley DB (-DNEWDB), then you need
77165095Seric	   to add "-lc -lucb" to the libraries to link with.  This is because
77265095Seric	   the -ldbm distributed by Dell needs the bcopy, bcmp and bzero
77365095Seric	   functions.  It is important that you specify both libraries in
77465095Seric	   the given order to be sure you only get the BSTRING functions
77565095Seric	   from the UCB library (and not the signal routines etc.).
77665095Seric
77765095Seric	3) Don't leave out "-lelf" even if compiling with "-lc -lucb".
77865095Seric	   The UCB library also has another copy of the nlist routines,
77965095Seric	   but we do want the ones from "-lelf".
78065095Seric
78165095Seric	If anyone needs a compiled gcc 2.4.5 and/or a ported DB library, they
78265095Seric	can use anonymous ftp to fetch them from lut.fi in the /kim directory.
78365095Seric	They are copies of what I use on grendel.lut.fi, and offering them
78465095Seric	does not imply that I would also support them.  I have sent the DB
78565095Seric	port for SVR4 back to Keith Bostic for inclusion in the official
78665095Seric	distribution, but I haven't heard anything from him as of today.
78765095Seric
78865095Seric	- gcc-2.4.5-svr4.tar.gz	(gcc 2.4.5 and the corresponding libg++)
78965095Seric	- db-1.72.tar.gz	(with source, objects and a installed copy)
79065095Seric
79165095Seric	Cheers
79265095Seric	+ Kim
79365095Seric	--
79465095Seric	 *  Kimmo.Suominen@lut.fi  *  SysVr4 enthusiast at GRENDEL.LUT.FI  *
79565095Seric	*    KIM@FINFILES.BITNET   *  Postmaster and Hostmaster at LUT.FI   *
79665095Seric	 *    + 358 200 865 718    *  Unix area moderator at NIC.FUNET.FI  *
79765095Seric
79868543SericConvexOS 10.1 and below
79968543Seric	In order to use the name server, you must create the file
80068543Seric	/etc/use_nameserver.  If this file does not exist, the call
80168543Seric	to res_init() will fail and you will have absolutely no
80268543Seric	access to DNS, including MX records.
80365095Seric
80468543SericAmdahl UTS 2.1.5
80568543Seric	In order to get UTS to work, you will have to port BIND 4.9.
80668543Seric	The vendor's BIND is reported to be ``totally inadequate.''
80768543Seric	See sendmail/contrib/AmdahlUTS.patch for the patches necessary
80868543Seric	to get BIND 4.9 compiled for UTS.
80968543Seric
81068543SericUnixWare 2.0
81168543Seric	According to Alexander Kolbasov <sasha@unitech.gamma.ru>,
81268543Seric	the m4 on UnixWare 2.0 (still in Beta) will core dump on the
81368543Seric	config files.  GNU m4 and the m4 from UnixWare 1.x both work.
81468543Seric
81564718SericNon-DNS based sites
81664718Seric	This version of sendmail always tries to connect to the Domain
81764718Seric	Name System (DNS) to resolve names, regardless of the setting
81864718Seric	of the `I' option.  On most systems that are not running DNS,
81964718Seric	this will fail quickly and sendmail will continue, but on some
82064718Seric	systems it has a long timeout.  If you have this problem, you
82164718Seric	will have to recompile without NAMED_BIND.  Some people have
82264718Seric	claimed that they have successfully used "OI+USEVC" to force
82364718Seric	sendmail to use a virtual circuit -- this will always time out
82464718Seric	quickly, but also tells sendmail that a failed connection
82564718Seric	should requeue the message (probably not what you intended).
82664718Seric	A future release of sendmail will correct this problem.
82764718Seric
82864250SericBoth NEWDB and NDBM
82964250Seric	If you use both -DNDBM and -DNEWDB, you must delete the module
83064250Seric	ndbm.o from libdb.a and delete the file "ndbm.h" from the files
83164250Seric	that get installed (that is, use the OLD ndbm.h, not the new
83264250Seric	ndbm.h).  This compatibility module maps ndbm calls into DB
83364250Seric	calls, and breaks things rather badly.
83458709Seric
83564559SericGNU getopt
83664559Seric	I'm told that GNU getopt has a problem in that it gets confused
83764559Seric	by the double call.  Use the version in conf.c instead.
83864250Seric
83966350SericBIND 4.9.2 and Ultrix
84068543Seric	If you are running on Ultrix, be sure you read conf/Info.Ultrix
84168543Seric	in the BIND distribution very carefully -- there is information
84268543Seric	in there that you need to know in order to avoid errors of the
84368543Seric	form:
84464559Seric
84566350Seric		/lib/libc.a(gethostent.o): sethostent: multiply defined
84666350Seric		/lib/libc.a(gethostent.o): endhostent: multiply defined
84766350Seric		/lib/libc.a(gethostent.o): gethostbyname: multiply defined
84866350Seric		/lib/libc.a(gethostent.o): gethostbyaddr: multiply defined
84966350Seric
85066350Seric	during the link stage.
85166350Seric
85266350Seric
85364820Seric+--------------+
85464820Seric| MANUAL PAGES |
85564820Seric+--------------+
85664820Seric
85764820SericThe manual pages have been written against the -mandoc macros
85864820Sericinstead of the -man macros.  The latest version of groff has them
85964820Sericincluded.  You can also get a copy from FTP.UU.NET in directory
86064820Seric/systems/unix/bsd-sources/share/tmac.
86164820Seric
86264820Seric
86365151Seric+-----------------+
86465151Seric| DEBUGGING HOOKS |
86565151Seric+-----------------+
86665151Seric
86765151SericAs of 8.6.5, sendmail daemons will catch a SIGUSR1 signal and log
86865151Sericsome debugging output (logged at LOG_DEBUG severity).  The
86965151Sericinformation dumped is:
87065151Seric
87165151Seric * The value of the $j macro.
87265151Seric * A warning if $j is not in the set $=w.
87365151Seric * A list of the open file descriptors.
87465151Seric * The contents of the connection cache.
87565151Seric * If ruleset 89 is defined, it is evaluated and the results printed.
87665151Seric
87765151SericThis allows you to get information regarding the runtime state of the
87865151Sericdaemon on the fly.  This should not be done too frequently, since
87965151Sericthe process of rewriting may lose memory which will not be recovered.
88065151SericAlso, ruleset 89 may call non-reentrant routines, so there is a small
88165151Sericnon-zero probability that this will cause other problems.  It is
88265151Sericreally only for debugging serious problems.
88365151Seric
88465151SericA typical formulation of ruleset 89 would be:
88565151Seric
88665151Seric	R$*		$@ $>0 some test address
88765151Seric
88865151Seric
88964035Seric+-----------------------------+
89064035Seric| DESCRIPTION OF SOURCE FILES |
89164035Seric+-----------------------------+
89264035Seric
8939881SericThe following list describes the files in this directory:
8945369Seric
89557418SericMakefile	The makefile used here; this version only works with
89657418Seric		the new Berkeley make.
89757418SericMakefile.dist	A trimmed down version of the makefile that works with
89857418Seric		the old make.
8995369SericREAD_ME		This file.
90060565SericTRACEFLAGS	My own personal list of the trace flags -- not guaranteed
90160565Seric		to be particularly up to date.
9025369Sericalias.c		Does name aliasing in all forms.
9039881Sericarpadate.c	A subroutine which creates ARPANET standard dates.
9049881Sericclock.c		Routines to implement real-time oriented functions
9059881Seric		in sendmail -- e.g., timeouts.
9065369Sericcollect.c	The routine that actually reads the mail into a temp
9075369Seric		file.  It also does a certain amount of parsing of
9085369Seric		the header, etc.
9095369Sericconf.c		The configuration file.  This contains information
9105369Seric		that is presumed to be quite static and non-
9115369Seric		controversial, or code compiled in for efficiency
9125369Seric		reasons.  Most of the configuration is in sendmail.cf.
9139881Sericconf.h		Configuration that must be known everywhere.
9145369Sericconvtime.c	A routine to sanely process times.
9159881Sericdaemon.c	Routines to implement daemon mode.  This version is
9169881Seric		specifically for Berkeley 4.1 IPC.
9175369Sericdeliver.c	Routines to deliver mail.
91860565Sericdomain.c	Routines that interface with DNS (the Domain Name
91960565Seric		System).
9205369Sericerr.c		Routines to print error messages.
9219881Sericenvelope.c	Routines to manipulate the envelope structure.
9225369Sericheaders.c	Routines to process message headers.
9235369Sericmacro.c		The macro expander.  This is used internally to
9245369Seric		insert information from the configuration file.
9255369Sericmain.c		The main routine to sendmail.  This file also
9265369Seric		contains some miscellaneous routines.
92760565Sericmap.c		Support for database maps.
92860565Sericmci.c		Routines that handle mail connection information caching.
9299881Sericparseaddr.c	The routines which do address parsing.
9305369Sericqueue.c		Routines to implement message queueing.
9315369Sericreadcf.c	The routine that reads the configuration file and
9325369Seric		translates it to internal form.
9339881Sericrecipient.c	Routines that manipulate the recipient list.
9345369Sericsavemail.c	Routines which save the letter on processing errors.
9355369Sericsendmail.h	Main header file for sendmail.
9365369Sericsrvrsmtp.c	Routines to implement server SMTP.
9375369Sericstab.c		Routines to manage the symbol table.
9385369Sericstats.c		Routines to collect and post the statistics.
9395369Sericsysexits.c	List of error messages associated with error codes
9405369Seric		in sysexits.h.
9419881Serictrace.c		The trace package.  These routines allow setting and
9429881Seric		testing of trace flags with a high granularity.
94360565Sericudb.c		The user database interface module.
9445369Sericusersmtp.c	Routines to implement user SMTP.
9455369Sericutil.c		Some general purpose routines used by sendmail.
94660565Sericversion.c	The version number and information about this
94760565Seric		version of sendmail.  Theoretically, this gets
94860565Seric		modified on every change.
9495369Seric
9505369SericEric Allman
9515369Seric
952*68575Seric(Version 8.82, last update 03/22/95 12:42:42)
953