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*68214Seric# @(#)READ_ME 8.77 (Berkeley) 01/31/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 16*68214Seric********************* 17*68214Seric!! DO NOT USE MAKE !! to compile sendmail -- instead, use the 18*68214Seric********************* "makesendmail" script located in the src 19*68214Sericdirectory. It will find an appropriate Makefile, and create an 20*68214Sericappropriate obj.* subdirectory so that multiplatform support 21*68214Sericworks easily. 2267876Seric 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 2867876SericIf you are porting to a new architecture for which there is no existing 2967876SericMakefile, you might start with Makefile.dist. This works on the old 3067876Serictraditional make, but isn't customized for any particular architecture. 3164501Seric 3267876Seric ************************************************** 3367876Seric ** Read below for more details of Makefiles. ** 3467876Seric ************************************************** 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 4665000Seric************************************************************************** 4765000Seric** IMPORTANT: Read the appropriate paragraphs in the section on ** 4865000Seric** ``Operating System and Compile Quirks''. ** 4965000Seric************************************************************************** 5064718Seric 5165000Seric 5265366Seric+-----------+ 5365366Seric| MAKEFILES | 5465366Seric+-----------+ 5565366Seric 5667876SericBy far, the easiest way to compile sendmail is to use the "makesendmail" 5768148Sericscript: 5868148Seric 5968148Seric sh makesendmail 6068148Seric 6168148SericThis uses the "uname" command to figure out what architecture you are 6268148Sericon and selects a proper Makefile accordingly. It also creates a 6368148Sericsubdirectory per object format, so that multiarchitecture support is 6467876Sericeasy. In general this should be all you need. However, if for some 6567876Sericreason this doesn't work (e.g., NeXT systems don't have the "uname" 6667876Sericcommand) you may have to set up your compile environment by hand. 6767876Seric 6865366SericThe "Makefile"s in these directories are from 4.4 BSD, and hence 6965366Sericreally only work properly if you are on a 4.4 system. In particular, 7065366Sericthey use new syntax that will not be recognized on old make programs, 7165366Sericand some of them do things like ``.include ../../Makefile.inc'' to 7265366Sericpick up some system defines. If you are getting sendmail separately, 7365366Sericthese files won't be included in the distribution, as they are 7465366Sericoutside of the sendmail tree. 7565366Seric 7665366SericInstead, you should use one of the other Makefiles, such as 7765366SericMakefile.SunOS for a SunOS system, and so forth. These should 7865366Sericwork with the version of make that is appropriate for that 7967876Sericsystem. All other Makefiles are in the "src/Makefiles" subdirectory. 8067876SericThey use the version of make that is native for that system. These 8167876Sericare the Makefiles that I use, and they have "Berkeley quirks" in them. 8267876SericI can't guarantee that they will work unmodified in your environment. 8367876SericIn particular, Many of them include -I/usr/sww/include/db and 8467876Seric-L/usr/sww/lib -- these are Berkeley's locations in the ``Software 8567876SericWarehouse'' for the new database libraries, described below. You don't 8667876Serichave to remove these definitions if you don't have these directories, 8767876Sericbut you may have to remove -DNEWDB from the DBMDEF definition. 8865366Seric 8965366SericPlease look for an appropriate Makefile before you start trying to 9065366Sericcompile with Makefile or Makefile.dist. 9165366Seric 9265366SericIf you want to port the new Berkeley make, you can get it from 9365366Sericftp.uu.net in the directory /systems/unix/bsd-sources/usr.bin/make. 9465366SericDiffs and instructions for building this version of make under 9565366SericSunOS 4.1.x are available on ftp.css.itd.umich.edu in 9665366Seric/pub/systems/sun/Net2-make.sun4.diff.Z. Diffs and instructions 9765366Sericfor building this version of make under IBM AIX 3.2.4 are available 9865366Sericon ftp.uni-stuttgart.de in /sw/src/patches/bsd-make-rus-patches. 9967555SericFor Ultrix, try ftp.vix.com:~ftp/pub/patches/pmake-for-ultrix.Z. 10065366SericPaul Southworth <pauls@umich.edu> published a description of porting 10165366Sericthis make in comp.unix.bsd. 10265366Seric 10365366SericThe complete text of the Makefile.inc that is in the parent of the 10465366Sericsendmail directory is: 10565366Seric 10665366Seric # @(#)Makefile.inc 8.1 (Berkeley) 6/6/93 10765366Seric 10865366Seric BINDIR?= /usr/sbin 10965366Seric 11065366Seric 11164250Seric+----------------------+ 11264250Seric| DATABASE DEFINITIONS | 11364250Seric+----------------------+ 11464250Seric 11564250SericThere are several database formats that can be used for the alias files 11664250Sericand for general maps. When used for alias files they interact in an 11764250Sericattempt to be back compatible. 11864250Seric 11964250SericThe three options are NEWDB (the new Berkeley DB package), NDBM (the 12064250Sericolder DBM implementation -- the very old V7 implementation is no 12164250Sericlonger supported), and NIS (Network Information Services). Used alone 12264376Sericthese just include the support they indicate. [If you are using NEWDB, 12367876Sericget the latest version from FTP.CS.Berkeley.EDU in /ucb/4bsd/db.tar.Z 12467876Seric(or db.tar.gz). DO NOT use the version from the Net2 distribution! 12567876SericHowever, if you are on BSD/386 or 386BSD-based systems, use the one 12667876Sericthat already exists on your system. You may need to #define OLD_NEWDB 12767876Seric1 to do this.] 12864250Seric 12965910Seric[NOTE WELL: it is CRITICAL that you remove ndbm.o from libdb.a and 13065910Sericndbm.h from the appropriate include directories if you want to get 13165910Sericndbm support. These files OVERRIDE calls to ndbm routines -- in 13265910Sericparticular, if you leave ndbm.h in, you can find yourself using 13365910Sericthe new db package even if you don't define NEWDB.] 13465910Seric 13564250SericIf NEWDB and NDBM are defined (but not NIS), then sendmail will read 13664250SericNDBM format alias files, but the next time a newaliases is run the 13764250Sericformat will be converted to NEWDB; that format will be used forever 13864250Sericmore. This is intended as a transition feature. [Note however that 13964250Sericthe NEWDB library also catches and maps NDBM calls; you will have to 14064250Sericback out this feature to get this to work. See ``Quirks'' section 14164250Sericbelow for details.] 14264250Seric 14364250SericIf all three are defined, sendmail operates as described above, and also 14464250Sericlooks for the file /var/yp/Makefile. If it exists, newaliases will 14564250Sericbuild BOTH the NEWDB and NDBM format alias files. However, it will 14664250Sericonly use the NEWDB file; the NDBM format file is used only by the 14764250SericNIS subsystem. 14864250Seric 14964250SericIf NDBM and NIS are defined (regardless of the definition of NEWDB 15064250Sericor the existance of /var/yp/Makefile), sendmail adds the special 15164250Serictokens "YP_LAST_MODIFIED" and "YP_MASTER_NAME", both of which are 15264250Sericrequired if the NDBM file is to be used as an NIS map. 15364250Seric 15467876SericThere is also preliminary support for NIS+ (-DNISPLUS), Hesiod 15567876Seric(-DHESIOD), and NetInfo (-DNETINFO). These have not been well 15667876Serictested. 15764250Seric 15867876SericAll of -DNEWDB, -DNDBM, -DNIS, -DNISPLUS, -DHESIOD, and -DNETINFO are 15967876Sericnormally defined in the DBMDEF line in the Makefile. 16064250Seric 16167876Seric 16264035Seric+---------------+ 16364035Seric| COMPILE FLAGS | 16464035Seric+---------------+ 16564035Seric 16660565SericWhereever possible, I try to make sendmail pull in the correct 16760584Sericcompilation options needed to compile on various environments based on 16860584Sericautomatically defined symbols. Some machines don't seem to have useful 16960584Sericsymbols availble, requiring the following compilation flags in the 17060584SericMakefile: 17160565Seric 17260565SericSOLARIS Define this if you are running Solaris 2.0 or higher. 17365000SericSOLARIS_2_3 Define this if you are running Solaris 2.3 or higher. 17465108SericSUNOS403 Define this if you are running SunOS 4.0.3. 17564077SericNeXT Define this if you are on a NeXT box. (This one may 17664072Seric be pre-defined for you.) There are other hacks you 17764072Seric have to make -- see below. 17860565Seric_AIX3 Define this if you are IBM AIX 3.x. 17963965SericRISCOS Define this if you are running RISC/os from MIPS. 18066335SericIRIX Define this if you are running IRIX from SGI. 18164501Seric_SCO_unix_ Define this if you are on SCO UNIX. 18265095Seric_SCO_unix_4_2 Define this if you are on SCO Open Server 3.2v4. 18367427SericDGUX Define this if you are on DG/UX 5.4.3 or later 18467427SericDGUX_5_4_2 Define this if you are on DG/UX systems prior to 5.4.3. 18567434SericNonStop_UX_BXX Define this if you are on a Tandem NonStop-UX release 18667434Seric Bxx system. 18760565Seric 18860584SericIf you are a system that sendmail has already been ported to, you 18960584Sericprobably won't have to touch these. But if you are porting, you may 19063962Serichave to tweak the following compilation flags in conf.h in order to 19163962Sericget it to compile and link properly: 19260565Seric 19365195SericSYSTEM5 Adjust for System V (not necessarily Release 4). 19464035SericSYS5SIGNALS Use System V signal semantics -- the signal handler 19564035Seric is automatically dropped when the signal is caught. 19664035Seric If this is not set, use POSIX/BSD semantics, where the 19764035Seric signal handler stays in force until an exec or an 19864035Seric explicit delete. Implied by SYSTEM5. 19964706SericSYS5SETPGRP Use System V setpgrp() semantics. Implied by SYSTEM5. 20064035SericHASFLOCK Set this if you prefer to use the flock(2) system call 20164035Seric rather than using fcntl-based locking. Fcntl locking 20264035Seric has some semantic gotchas, but many vendor systems 20364035Seric also interface it to lockd(8) to do NFS-style locking. 20464035Seric For this reason, this should not be set unless you 20564035Seric don't have an alternative. 20660565SericHASUNAME Set if you have the "uname" system call. Implied by 20760565Seric SYSTEM5. 20863962SericHASUNSETENV Define this if your system library has the "unsetenv" 20963962Seric subroutine. 21060565SericHASSETSID Define this if you have the setsid(2) system call. This 21160565Seric is implied if your system appears to be POSIX compliant. 21260565SericHASINITGROUPS Define this if you have the initgroups(3) routine. 21363753SericHASSETVBUF Define this if you have the setvbuf(3) library call. 21463753Seric If you don't, setlinebuf will be used instead. This 21563753Seric defaults on if your compiler defines __STDC__. 21663902SericHASSETREUID Define this if you have setreuid(2) ***AND*** root can 21763902Seric use setreuid to change to an arbitrary user. This second 21863902Seric condition is not satisfied on AIX 3.x. You may find that 21963902Seric your system has setresuid(2), (for example, on HP-UX) in 22063902Seric which case you will also have to #define setreuid(r, e) 22163902Seric to be the appropriate call. Some systems (such as Solaris) 22265000Seric have a compatibility routine that doesn't work properly, 22365000Seric but may have "saved user ids" properly implemented so you 22465000Seric can ``#define setreuid(r, e) seteuid(e)'' and have it work. 22563902Seric The important thing is that you have a call that will set 22665000Seric the effective uid independently of the real or saved uid 22765000Seric and be able to set the effective uid back again when done. 22865000Seric There's a test program in ../test/t_setreuid.c that will 22965000Seric try things on your system. Setting this improves the 23065000Seric security, since sendmail doesn't have to read .forward 23165000Seric and :include: files as root. There are certain attacks 23265000Seric that may be unpreventable without this call. 23365000SericHASLSTAT Define this if you have symbolic links (and thus the 23465000Seric lstat(2) system call). This improves security. Unlike 23565000Seric most other options, this one is on by default, so you 23665000Seric need to #undef it in conf.h if you don't have symbolic 23765000Seric links (these days everyone does). 23867430SericHASSETRLIMIT Define this to 1 if you have the setrlimit(2) syscall. 23967430Seric You can define it to 0 to force it off. It is assumed 24067430Seric if you are running a BSD-like system. 24167430SericHASULIMIT Define this if you have the ulimit(2) syscall (System V 24267430Seric style systems). HASSETRLIMIT overrides, as it is more 24367430Seric general. 24465206SericNEEDGETOPT Define this if you need a reimplementation of getopt(3). 24565206Seric On some systems, getopt does very odd things if called 24665206Seric to scan the arguments twice. This flag will ask sendmail 24765206Seric to compile in a local version of getopt that works 24865206Seric properly. 24965206SericNEEDSTRTOL Define this if your standard C library does not define 25065206Seric strtol(3). This will compile in a local version. 25165206SericNEEDVPRINTF Define this if your standard C library does not define 25265206Seric vprintf(3). Note that the resulting fake implementation 25365206Seric is not very elegant and may not even work on some 25465206Seric architectures. 25566792SericNEEDFSYNC Define this if your standard C library does not define 25666792Seric fsync(2). This will try to simulate the operation using 25766792Seric fcntl(2); if that is not available it does nothing, which 25866792Seric isn't great, but at least it compiles and runs. 25965211SericHASGETUSERSHELL Define this to 1 if you have getusershell(3) in your 26065211Seric standard C library. If this is not defined, or is defined 26165211Seric to be 0, sendmail will scan the /etc/shells file (no 26265211Seric NIS-style support, defaults to /bin/sh and /bin/csh if 26365211Seric that file does not exist) to get a list of unrestricted 26465211Seric user shells. This is used to determine whether users 26565211Seric are allowed to forward their mail to a program or a file. 26663937SericGIDSET_T The type of entries in a gidset passed as the second 26763937Seric argument to getgroups(2). Historically this has been an 26863937Seric int, so this is the default, but some systems (such as 26963937Seric IRIX) pass it as a gid_t, which is an unsigned short. 27063937Seric This will make a difference, so it is important to get 27163937Seric this right! However, it is only an issue if you have 27263937Seric group sets. 27363968SericSLEEP_T The type returned by the system sleep() function. 27463968Seric Defaults to "unsigned int". Don't worry about this 27563968Seric if you don't have compilation problems. 27663974SericARBPTR_T The type of an arbitrary pointer -- defaults to "void *". 27763974Seric If you are an very old compiler you may need to define 27863974Seric this to be "char *". 27960584SericLA_TYPE The type of load average your kernel supports. These 28066301Seric can be one of: 28166301Seric LA_ZERO (1) -- it always returns the load average as 28266301Seric "zero" (and does so on all architectures). 28366301Seric LA_SUBR (4) if you have the getloadavg(3) routine, 28464376Seric LA_MACH (5) to use MACH-style load averages (calls 28566301Seric processor_set_info()), 28666301Seric LA_PROCSTR (7) to read /proc/loadavg and interpret it 28766301Seric as a string representing a floating-point 28866301Seric number (Linux-style), 28966301Seric LA_FLOAT (3) if you read kmem and interpret the value 29066301Seric as a floating point number, 29166301Seric LA_INT (2) to interpret as a long integer, 29266301Seric LA_SHORT (6) to interpret as a short integer. 29366301Seric These last three have several other parameters that they 29466301Seric try to divine: the name of your kernel, the name of the 29566301Seric variable in the kernel to examine, the number of bits of 29666301Seric precision in a fixed point load average, and so forth. 29766301Seric In desperation, use LA_ZERO. The actual code is in 29866301Seric conf.c -- it can be tweaked if you are brave. 29965752SericSFS_TYPE Encodes how your kernel can locate the amount of free 30065752Seric space on a disk partition. This can be set to SFS_NONE 30165752Seric (0) if you have no way of getting this information, 30265752Seric SFS_USTAT (1) if you have the ustat(2) system call, 30365752Seric SFS_4ARGS (2) if you have a four-argument statfs(2) 30465752Seric system call (and the include file is <sys/statfs.h>), 30567161Seric SFS_VFS (3), SFS_MOUNT (4), SFS_STATFS (5) if you have 30667161Seric the two-argument statfs(2) system call with includes in 30767161Seric <sys/vfs.h>, <sys/mount.h>, or <sys/statfs.h> respectively, 30867161Seric or SFS_STATVFS (6) if you have the two-argument statvfs(2) 30967161Seric call. The default if nothing is defined is SFS_NONE. 31067770SericSPT_TYPE Encodes how your system can display what a process is doing 31167770Seric on a ps(1) command (SPT stands for Set Process Title). Can 31267770Seric be set to: 31367770Seric SPT_NONE (0) -- Don't try to set the process title at all. 31467770Seric SPT_REUSEARGV (1) -- Pad out your argv with the information; 31567770Seric this is the default if none specified. 31667770Seric SPT_BUILTIN (2) -- The system library has setproctitle. 31767770Seric SPT_PSTAT (3) -- Use the PSTAT_SETCMD option to pstat(2) 31867770Seric to set the process title; this is used by HP-UX. 31967770Seric SPT_PSSTRINGS (4) -- Use the magic PS_STRINGS pointer (4.4BSD). 32067770SericSPT_PADCHAR Character used to pad the process title; if undefined, 32167770Seric the space character (0x20) is used. This is ignored if 32267770Seric SPT_TYPE != SPT_REUSEARGV 32363962SericERRLIST_PREDEFINED 32463962Seric If set, assumes that some header file defines sys_errlist. 32563962Seric This may be needed if you get type conflicts on this 32663962Seric variable -- otherwise don't worry about it. 32764562SericWAITUNION The wait(2) routine takes a "union wait" argument instead 32864562Seric of an integer argument. This is for compatibility with 32964562Seric old versions of BSD. 33065000SericSCANF You can set this to extend the F command to accept a 33165000Seric scanf string -- this gives you a primitive parser for 33265000Seric class definitions -- BUT it can make you vulnerable to 33365000Seric core dumps if the target file is poorly formed. 33465095SericSYSLOG_BUFSIZE You can define this to be the size of the buffer that 33565095Seric syslog accepts. If it is not defined, it assumes a 33665095Seric 1024-byte buffer. If the buffer is very small (under 33765095Seric 256 bytes) the log message format changes -- each 33865095Seric e-mail message will log many more messages, since it 33965095Seric will log each piece of information as a separate line 34065095Seric in syslog. 34166318SericBROKEN_RES_SEARCH 34266318Seric On Ultrix (and maybe other systems?) if you use the 34366318Seric res_search routine with an unknown host name, it returns 34466318Seric -1 but sets h_errno to 0 instead of HOST_NOT_FOUND. If 34566318Seric you set this, sendmail considers 0 to be the same as 34666318Seric HOST_NOT_FOUND. 34767436SericNAMELISTMASK If defined, values returned by nlist(3) are masked 34867436Seric against this value before use -- a common value is 34967436Seric 0x7fffffff to strip off the top bit. 35060565Seric 35164035Seric 35267436Seric 35364035Seric+-----------------------+ 35464035Seric| COMPILE-TIME FEATURES | 35564035Seric+-----------------------+ 35664035Seric 35760584SericThere are a bunch of features that you can decide to compile in, such 35860584Sericas selecting various database packages and special protocol support. 35960584SericSeveral are assumed based on other compilation flags -- if you want to 36060584Seric"un-assume" something, you probably need to edit conf.h. Compilation 36160584Sericflags that add support for special features include: 36260565Seric 36360565SericNDBM Include support for "new" DBM library for aliases and maps. 36464250Seric Normally defined in the Makefile. 36560565SericNEWDB Include support for Berkeley "db" package (hash & btree) 36664250Seric for aliases and maps. Normally defined in the Makefile. 36766843SericOLD_NEWDB If non-zero, the version of NEWDB you have is the old 36866843Seric one that does not include the "fd" call. This call was 36966843Seric added in version 1.5 of the Berkeley DB code. If you 37066843Seric use -DOLD_NEWDB=0 it forces you to use the new interface. 37160565SericNIS Define this to get NIS (YP) support for aliases and maps. 37264250Seric Normally defined in the Makefile. 37360565SericUSERDB Include support for the User Information Database. Implied 37464250Seric by NEWDB in conf.h. 37565000SericIDENTPROTO Define this as 1 to get IDENT (RFC 1413) protocol support. 37660565Seric This is assumed unless you are running on Ultrix or 37760565Seric HP-UX, both of which have a problem in the UDP 37865000Seric implementation. You can define it to be 0 to explicitly 37965000Seric turn off IDENT protocol support. 38060565SericLOG Set this to get syslog(3) support. Defined by default 38160584Seric in conf.h. You want this if at all possible. 38260565SericNETINET Set this to get TCP/IP support. Defined by default 38360584Seric in conf.h. You probably want this. 38460565SericNETISO Define this to get ISO networking support. 38560565SericSMTP Define this to get the SMTP code. Implied by NETINET 38660565Seric or NETISO. 38760565SericNAMED_BIND Define this to get DNS (name daemon) support, including 38860565Seric MX support. The specs you must use this if you run 38960565Seric SMTP. Defined by default in conf.h. 39060565SericQUEUE Define this to get queueing code. Implied by NETINET 39160584Seric or NETISO; required by SMTP. This gives you other good 39260584Seric stuff -- it should be on. 39360565SericDAEMON Define this to get general network support. Implied by 39460584Seric NETINET or NETISO. Defined by default in conf.h. You 39560584Seric almost certainly want it on. 39660565SericMATCHGECOS Permit fuzzy matching of user names against the full 39760565Seric name (GECOS) field in the /etc/passwd file. This should 39860565Seric probably be on, since you can disable it from the config 39960584Seric file if you want to. Defined by default in conf.h. 40060565Seric 40164035Seric 40265000Seric+---------------------+ 40365000Seric| DNS/RESOLVER ISSUES | 40465000Seric+---------------------+ 40565000Seric 40665000SericMany systems have old versions of the resolver library. At a minimum, 40765000Sericyou should be running BIND 4.8.3; older versions may compile, but they 40865000Serichave known bugs that should give you pause. 40965000Seric 41065000SericCommon problems in old versions include "undefined" errors for 41165000Sericdn_skipname. 41265000Seric 41365000SericSome people have had a problem with BIND 4.9; it uses some routines 41465000Sericthat it expects to be externally defined such as strerror(). It may 41565000Serichelp to link with "-l44bsd" to solve this problem. 41665000Seric 41765095Seric!PLEASE! be sure to link with the same version of the resolver as 41865095Sericthe header files you used -- some people have used the 4.9 headers 41965095Sericand linked with BIND 4.8 or vice versa, and it doesn't work. 42065095SericUnfortunately, it doesn't fail in an obvious way -- things just 42165954Sericsubtly don't work. 42265000Seric 42365095Seric 42464035Seric+-------------------------------------+ 42564035Seric| OPERATING SYSTEM AND COMPILE QUIRKS | 42664035Seric+-------------------------------------+ 42764035Seric 42865095SericGCC 2.5.x problems *** IMPORTANT *** 42965095Seric Date: Mon, 29 Nov 93 19:08:44 PST 43065095Seric From: wilson@cygnus.com (Jim Wilson) 43165095Seric Message-Id: <9311300308.AA04608@cygnus.com> 43265095Seric To: kenner@vlsi1.ultra.nyu.edu 43365095Seric Subject: [cattelan@thebarn.com: gcc 2.5.4-2.5.5 -O bug] 43465095Seric Cc: cattelan@thebarn.com, rms@gnu.ai.mit.edu, sendmail@cs.berkeley.edu 43565095Seric 43665095Seric This fixes a problem that occurs when gcc 2.5.5 is used to compile 43765095Seric sendmail 8.6.4 with optimization on a sparc. 43865095Seric 43965095Seric Mon Nov 29 19:00:14 1993 Jim Wilson (wilson@sphagnum.cygnus.com) 44065095Seric 44165095Seric * reload.c (find_reloads_toplev): Replace obsolete reference to 44265095Seric BYTE_LOADS_*_EXTEND with LOAD_EXTEND_OP. 44365095Seric 44465095Seric *** clean-ss-931128/reload.c Sun Nov 14 16:20:01 1993 44565095Seric --- ss-931128/reload.c Mon Nov 29 18:52:55 1993 44665095Seric *************** find_reloads_toplev (x, opnum, type, ind 44765095Seric *** 3888,3894 **** 44865095Seric force a reload in that case. So we should not do anything here. */ 44965095Seric 45065095Seric else if (regno >= FIRST_PSEUDO_REGISTER 45165095Seric ! #if defined(BYTE_LOADS_ZERO_EXTEND) || defined(BYTE_LOADS_SIGN_EXTEND) 45265095Seric && (GET_MODE_SIZE (GET_MODE (x)) 45365095Seric <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))) 45465095Seric #endif 45565095Seric --- 3888,3894 ---- 45665095Seric force a reload in that case. So we should not do anything here. */ 45765095Seric 45865095Seric else if (regno >= FIRST_PSEUDO_REGISTER 45965095Seric ! #ifdef LOAD_EXTEND_OP 46065095Seric && (GET_MODE_SIZE (GET_MODE (x)) 46165095Seric <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))) 46265095Seric #endif 46365095Seric 46465095Seric 46564376SericSunOS 4.x (Solaris 1.x) 46664376Seric You may have to use -lresolv on SunOS. However, beware that 46764376Seric this links in a new version of gethostbyname that does not 46864376Seric understand NIS, so you must have all of your hosts in DNS. 46964035Seric 47064798Seric Some people have reported problems with the SunOS version of 47164798Seric -lresolv and/or in.named, and suggest that you get a newer 47264798Seric version. The symptoms are delays when you connect to the 47365000Seric SMTP server on a SunOS machine or having your domain added to 47465000Seric addresses inappropriately. There is a version of BIND 47564798Seric version 4.9 on gatekeeper.DEC.COM in pub/BSD/bind/4.9. 47664798Seric 47764400Seric There is substantial disagreement about whether you can make 47864400Seric this work with resolv+, which allows you to specify a search-path 47964400Seric of services. Some people report that it works fine, others 48064400Seric claim it doesn't work at all (including causing sendmail to 48164400Seric drop core when it tries to do multiple resolv+ lookups for a 48264400Seric single job). I haven't tried resolv+, as we use DNS exclusively. 48364400Seric 48464400Seric Should you want to try resolv+, it is on ftp.uu.net in 48564400Seric /networking/ip/dns. 48664400Seric 48767161Seric Apparently getservbyname() can fail under moderate to high 48867161Seric load under some circumstances. This will exhibit itself as 48967161Seric the message ``554 makeconnection: service "smtp" unknown''. 49067161Seric The problem has been traced to one or more blank lines in 49167161Seric /etc/services on the NIS server machine. Delete these 49267161Seric and it should work. This info is thanks to Brian Bartholomew 49367161Seric <bb@math.ufl.edu> of I-Kinetics, Inc. 49467161Seric 49564376SericSolaris 2.x (SunOS 5.x) 49664376Seric To compile for Solaris, be sure you use -DSOLARIS. 49764376Seric 49866329Seric To the best of my knowledge, Solaris does not have the 49966329Seric gethostbyname problem described above. However, it does 50066329Seric have another one: 50166329Seric 50264364Seric From a correspondent: 50364364Seric 50464364Seric For solaris 2.2, I have 50564364Seric 50664364Seric hosts: files dns 50764364Seric 50864364Seric in /etc/nsswitch.conf and /etc/hosts has to have the fully 50964364Seric qualified host name. I think "files" has to be before "dns" 51064364Seric in /etc/nsswitch.conf during bootup. 51164364Seric 51266329Seric From another correspondent: 51364376Seric 51466329Seric When running sendmail under Solaris, the gethostbyname() 51566329Seric hack in conf.c which should perform proper canonicalization 51666329Seric of host names could fail. Result: the host name is not 51766329Seric canonicalized despite the hack, and you'll have to define $j 51866329Seric and $m in sendmail.cf somewhere. 51966329Seric 52066329Seric The reason could be that /etc/nsswitch.conf is improperly 52166329Seric configured (at least from sendmail's point of view). For 52266329Seric example, the line 52366329Seric 52466329Seric hosts: files nisplus dns 52566329Seric 52666329Seric will make gethostbyname() look in /etc/hosts first, then ask 52766329Seric nisplus, then dns. However, if /etc/hosts does not contain 52866329Seric the full canonicalized hostname, then no amount of 52966329Seric gethostbyname()s will work. 53066329Seric 53166329Seric Solution (or rather, a workaround): Ask nisplus first, then 53266329Seric dns, then local files: 53366329Seric 53466329Seric hosts: nisplus dns [NOTFOUND=return] files 53566329Seric 53664385Seric The Solaris "syslog" function is apparently limited to something 53764385Seric about 90 characters because of a kernel limitation. If you have 53866023Seric source code, you can probably up this number. You can get patches 53966023Seric that fix this problem: the patch ids are: 54064385Seric 54166023Seric Solaris 2.1 100834 54266023Seric Solaris 2.2 100999 54366024Seric Solaris 2.3 101318 54466023Seric 54566023Seric Be sure you have the appropriate patch installed or you won't 54666023Seric see system logging. 54766023Seric 54864250SericOSF/1 54965000Seric If you are compiling on OSF/1 (DEC Alpha), you must use 55065616Seric -L/usr/shlib (otherwise it core dumps on startup). You may also 55165000Seric need -mld to get the nlist() function, although some versions 55265000Seric apparently don't need this. 55365000Seric 55465000Seric Also, the enclosed makefile removed /usr/sbin/smtpd; if you need 55565000Seric it, just create the link to the sendmail binary. 55657977Seric 55766335SericIRIX 55866335Seric The header files on SGI IRIX are completely prototyped, and as 55966335Seric a result you can sometimes get some warning messages during 56066335Seric compilation. These can be ignored. There are two errors in 56166335Seric deliver only if you are using gcc, both of the form ``warning: 56266335Seric passing arg N of `execve' from incompatible pointer type''. 56366335Seric Also, if you compile with -DNIS, you will get a complaint 56466335Seric about a declaration of struct dom_binding in a prototype 56566335Seric when compiling map.c; this is not important because the 56666335Seric function being prototyped is not used in that file. 56766335Seric 56867674Seric In order to compile sendmail you will have had to install 56967674Seric the developers' option in order to get the necessary include 57067674Seric files. 57167674Seric 57264250SericNeXT 57364250Seric If you are compiling on NeXT, you will have to create an empty 57464250Seric file "unistd.h" and create a file "dirent.h" containing: 57563753Seric 57664250Seric #include <sys/dir.h> 57764250Seric #define dirent direct 57864035Seric 57964250Seric (The Makefile.NeXT should try to do both of these for you.) 58064077Seric 58164364Seric Apparently, there is a bug in getservbyname on Nextstep 3.0 58264364Seric that causes it to fail under some circumstances with the 58364364Seric message "SYSERR: service "smtp" unknown" logged. You should 58464364Seric be able to work around this by including the line: 58564364Seric 58664670Seric OOPort=25 58764364Seric 58864364Seric in your .cf file. 58964364Seric 59064376Seric You may have to use -DNeXT. 59164376Seric 59265000SericBSDI (BSD/386) 1.0, NetBSD 0.9, FreeBSD 1.0 59365000Seric The "m4" from BSDI won't handle the config files properly. 59465000Seric I haven't had a chance to test this myself. 59557943Seric 59665000Seric The M4 shipped in FreeBSD and NetBSD 0.9 don't handle the config 59765000Seric files properly. One must use either GNU m4 1.1 or the PD-M4 59865000Seric recently posted in comp.os.386bsd.bugs (and maybe others). 59965000Seric NetBSD-current includes the PD-M4 (as stated in the NetBSD file 60065000Seric CHANGES). 60165000Seric 60265000Seric FreeBSD 1.0 RELEASE has uname(2) now. Use -DUSEUNAME in order to 60365000Seric use it (look into Makefile.FreeBSD). NetBSD-current may have 60465000Seric it too but it has not been verified. 60565000Seric 60665000Seric You cannot port the latest version of the Berkeley db library 60765000Seric and use it with sendmail without recompiling the world. This 60865000Seric is because C library routines use the older version which have 60965000Seric incompatible header files -- the result is that it can't read 61065000Seric other system files, such as /etc/passwd, unless you use the 61165000Seric new db format throughout your system. You should normally just 61265000Seric use the version of db supplied in your release. You may need 61366843Seric to use -DOLD_NEWDB=1 to make this work -- this turns off some 61465000Seric new interface calls (for file locking) that are not in older 61565000Seric versions of db. You'll get compile errors if you need this 61665000Seric flag and don't have it set. 61765000Seric 61864364Seric4.3BSD 61964364Seric If you are running a "virgin" version of 4.3BSD, you'll have 62064364Seric a very old resolver and be missing some header files. The 62164364Seric header files are simple -- create empty versions and everything 62264364Seric will work fine. For the resolver you should really port a new 62364364Seric version (4.8.3 or later) of the resolver; 4.9 is available on 62464364Seric gatekeeper.DEC.COM in pub/BSD/bind/4.9. If you are really 62564364Seric determined to continue to use your old, buggy version (or as 62664364Seric a shortcut to get sendmail working -- I'm sure you have the 62764364Seric best intentions to port a modern version of BIND), you can 62864364Seric copy ../contrib/oldbind.compat.c into src and add 62964364Seric oldbind.compat.o to OBJADD in the Makefile. 63064364Seric 63164718SericA/UX 63264718Seric Date: Tue, 12 Oct 1993 18:28:28 -0400 (EDT) 63364718Seric From: "Eric C. Hagberg" <hagberg@med.cornell.edu> 63464718Seric Subject: Fix for A/UX ndbm 63564718Seric 63664718Seric I guess this isn't really a sendmail bug, however, it is something 63764718Seric that A/UX users should be aware of when compiling sendmail 8.6. 63864718Seric 63964718Seric Apparently, the calls that sendmail is using to the ndbm routines 64064718Seric in A/UX 3.0.x contain calls to "broken" routines, in that the 64164718Seric aliases database will break when it gets "just a little big" 64264718Seric (sorry I don't have exact numbers here, but it broke somewhere 64364718Seric around 20-25 aliases for me.), making all aliases non-functional 64464718Seric after exceeding this point. 64564718Seric 64664718Seric What I did was to get the gnu-dbm-1.6 package, compile it, and 64764718Seric then re-compile sendmail with "-lgdbm", "-DNDBM", and using the 64864718Seric ndbm.h header file that comes with the gnu-package. This makes 64964718Seric things behave properly. 65064718Seric 65164718Seric I suppose porting the New Berkeley db package is another route, 65264718Seric however, I made a quick attempt at it, and found it difficult 65364718Seric (not easy at least); the gnu-dbm package "configured" and 65464718Seric compiled easily. 65564718Seric 656*68214SericSCO Unix 657*68214Seric From: Thomas Essebier <tom@stallion.oz.au> 658*68214Seric Organisation: Stallion Technologies Pty Ltd. 659*68214Seric 660*68214Seric It will probably help those who are trying to configure sendmail 8.6.9 661*68214Seric to know that if they are on SCO, they had better set 662*68214Seric OI-dnsrch 663*68214Seric or they will core dump as soon as they try to use the resolver. 664*68214Seric ie. although SCO has _res.dnsrch defined, and is kinda BIND 4.8.3, it 665*68214Seric does not inititialise it, nor does it understand 'search' in 666*68214Seric /etc/named.boot. 667*68214Seric - sigh - 668*68214Seric 66964718SericDG/UX 67068067Seric Doug Anderson <dlander@afterlife.ncsc.mil> has successfully run 67168067Seric V8 on the DG/UX 5.4.2 and 5.4R3.x platforms under heavy usage. 67268067Seric Originally, the DG /bin/mail program wasn't compatible with 67368067Seric the V8 sendmail, since the DG /bin/mail requires the environment 67468067Seric variable "_FORCE_MAIL_LOCAL_=yes" be set. Version 8.7 now includes 67568067Seric this in the environment before invoking the local mailer. Some 67668067Seric have used procmail to avoid this problem in the past. It works 67768067Seric but some have experienced file locking problems with their DG/UX 67868067Seric ports of procmail. 67964718Seric 68065820SericApollo DomainOS 68165820Seric If you are compiling on Apollo, you will have to create an empty 68265820Seric file "unistd.h" and create a file "dirent.h" containing: 68365820Seric 68465820Seric #include <sys/dir.h> 68565820Seric #define dirent direct 68665820Seric 68765820Seric (The Makefile.DomainOS will attempt to do both of these for you.) 68865820Seric 68965910SericHP-UX 8.00 69065910Seric Date: Mon, 24 Jan 1994 13:25:45 +0200 69165910Seric From: Kimmo Suominen <Kimmo.Suominen@lut.fi> 69265910Seric Subject: 8.6.5 w/ HP-UX 8.00 on s300 69365910Seric 69465910Seric Just compiled and fought with sendmail 8.6.5 on a HP9000/360 (ie. a 69565910Seric series 300 machine) running HP-UX 8.00. 69665910Seric 69765910Seric I was getting segmentation fault when delivering to a local user. 69865910Seric With debugging I saw it was faulting when doing _free@libc... *sigh* 69965910Seric It seems the new implementation of malloc on s300 is buggy as of 8.0, 70065910Seric so I tried out the one in -lmalloc (malloc(3X)). With that it seems 70165910Seric to work just dandy. 70265910Seric 70365910Seric When linking, you will get the following error: 70465910Seric 70565910Seric ld: multiply defined symbol _freespace in file /usr/lib/libmalloc.a 70665910Seric 70765910Seric but you can just ignore it. You might want to add this info to the 70865910Seric README file for the future... 70965910Seric 71065910SericLinux 71165910Seric Something broke between versions 0.99.13 and 0.99.14 of Linux: 71265910Seric the flock() system call gives errors. If you are running .14, 71365910Seric you must not use flock. You can do this with -DHASFLOCK=0. 71465910Seric 71565910SericAIX 71665910Seric This version of sendmail does not support MB, MG, and MR resource 71765910Seric records, which are supported by AIX sendmail. 71865910Seric 71966335SericRISC/os 72066335Seric RISC/os from MIPS is a merged AT&T/Berkeley system. When you 72166335Seric compile on that platform you will get duplicate definitions 72266335Seric on many files. You can ignore these. 72366335Seric 72465195SericSystem V Release 4 Based Systems 72565195Seric There is a single Makefile that is intended for all SVR4-based 72665195Seric systems (called Makefile.SVR4). It defines __svr4__, which is 72765195Seric predefined by some compilers. If your compiler already defines 72865195Seric this compile variable, you can delete the definition from the 72965195Seric Makefile. 73065195Seric 73165195Seric It's been tested on Dell Issue 2.2. 73265195Seric 73365095SericDELL SVR4 73465095Seric Date: Mon, 06 Dec 1993 10:42:29 EST 73565095Seric From: "Kimmo Suominen" <kim@grendel.lut.fi> 73665095Seric Message-ID: <2d0352f9.lento29@lento29.UUCP> 73765095Seric To: eric@cs.berkeley.edu 73865166Seric Cc: sendmail@cs.berkeley.edu 73965095Seric Subject: Notes for DELL SVR4 74065095Seric 74165095Seric Eric, 74265095Seric 74365095Seric Here are some notes for compiling Sendmail 8.6.4 on DELL SVR4. I ran 74465095Seric across these things when helping out some people who contacted me by 74565095Seric e-mail. 74665095Seric 74765095Seric 1) Use gcc 2.4.5 (or later?). Dell distributes gcc 2.1 with their 74865095Seric Issue 2.2 Unix. It is too old, and gives you problems with 74965095Seric clock.c, because sigset_t won't get defined in <sys/signal.h>. 75065095Seric This is due to a problematic protection rule in there, and is 75165095Seric fixed with gcc 2.4.5. 75265095Seric 75365095Seric 2) If you don't use the new Berkeley DB (-DNEWDB), then you need 75465095Seric to add "-lc -lucb" to the libraries to link with. This is because 75565095Seric the -ldbm distributed by Dell needs the bcopy, bcmp and bzero 75665095Seric functions. It is important that you specify both libraries in 75765095Seric the given order to be sure you only get the BSTRING functions 75865095Seric from the UCB library (and not the signal routines etc.). 75965095Seric 76065095Seric 3) Don't leave out "-lelf" even if compiling with "-lc -lucb". 76165095Seric The UCB library also has another copy of the nlist routines, 76265095Seric but we do want the ones from "-lelf". 76365095Seric 76465095Seric If anyone needs a compiled gcc 2.4.5 and/or a ported DB library, they 76565095Seric can use anonymous ftp to fetch them from lut.fi in the /kim directory. 76665095Seric They are copies of what I use on grendel.lut.fi, and offering them 76765095Seric does not imply that I would also support them. I have sent the DB 76865095Seric port for SVR4 back to Keith Bostic for inclusion in the official 76965095Seric distribution, but I haven't heard anything from him as of today. 77065095Seric 77165095Seric - gcc-2.4.5-svr4.tar.gz (gcc 2.4.5 and the corresponding libg++) 77265095Seric - db-1.72.tar.gz (with source, objects and a installed copy) 77365095Seric 77465095Seric Cheers 77565095Seric + Kim 77665095Seric -- 77765095Seric * Kimmo.Suominen@lut.fi * SysVr4 enthusiast at GRENDEL.LUT.FI * 77865095Seric * KIM@FINFILES.BITNET * Postmaster and Hostmaster at LUT.FI * 77965095Seric * + 358 200 865 718 * Unix area moderator at NIC.FUNET.FI * 78065095Seric 78167267SericConvexOS 10.1 and below 78267267Seric In order to use the name server, you must create the file 78367267Seric /etc/use_nameserver. If this file does not exist, the call 78467267Seric to res_init() will fail and you will have absolutely no 78567267Seric access to DNS, including MX records. 78665095Seric 78768106SericAmdahl UTS 2.1.5 78868106Seric In order to get UTS to work, you will have to port BIND 4.9. 78968106Seric The vendor's BIND is reported to be ``totally inadequate.'' 79068106Seric See sendmail/contrib/AmdahlUTS.patch for the patches necessary 79168106Seric to get BIND 4.9 compiled for UTS. 79268106Seric 79364718SericNon-DNS based sites 79464718Seric This version of sendmail always tries to connect to the Domain 79564718Seric Name System (DNS) to resolve names, regardless of the setting 79664718Seric of the `I' option. On most systems that are not running DNS, 79764718Seric this will fail quickly and sendmail will continue, but on some 79864718Seric systems it has a long timeout. If you have this problem, you 79964718Seric will have to recompile without NAMED_BIND. Some people have 80064718Seric claimed that they have successfully used "OI+USEVC" to force 80164718Seric sendmail to use a virtual circuit -- this will always time out 80264718Seric quickly, but also tells sendmail that a failed connection 80364718Seric should requeue the message (probably not what you intended). 80464718Seric A future release of sendmail will correct this problem. 80564718Seric 80664250SericBoth NEWDB and NDBM 80764250Seric If you use both -DNDBM and -DNEWDB, you must delete the module 80864250Seric ndbm.o from libdb.a and delete the file "ndbm.h" from the files 80964250Seric that get installed (that is, use the OLD ndbm.h, not the new 81064250Seric ndbm.h). This compatibility module maps ndbm calls into DB 81164250Seric calls, and breaks things rather badly. 81258709Seric 81364559SericGNU getopt 81464559Seric I'm told that GNU getopt has a problem in that it gets confused 81564559Seric by the double call. Use the version in conf.c instead. 81664250Seric 81766350SericBIND 4.9.2 and Ultrix 81867206Seric If you are running on Ultrix, be sure you read conf/Info.Ultrix 81967206Seric in the BIND distribution very carefully -- there is information 82067206Seric in there that you need to know in order to avoid errors of the 82167206Seric form: 82264559Seric 82366350Seric /lib/libc.a(gethostent.o): sethostent: multiply defined 82466350Seric /lib/libc.a(gethostent.o): endhostent: multiply defined 82566350Seric /lib/libc.a(gethostent.o): gethostbyname: multiply defined 82666350Seric /lib/libc.a(gethostent.o): gethostbyaddr: multiply defined 82766350Seric 82866350Seric during the link stage. 82966350Seric 83066350Seric 83164820Seric+--------------+ 83264820Seric| MANUAL PAGES | 83364820Seric+--------------+ 83464820Seric 83564820SericThe manual pages have been written against the -mandoc macros 83664820Sericinstead of the -man macros. The latest version of groff has them 83764820Sericincluded. You can also get a copy from FTP.UU.NET in directory 83864820Seric/systems/unix/bsd-sources/share/tmac. 83964820Seric 84064820Seric 84165151Seric+-----------------+ 84265151Seric| DEBUGGING HOOKS | 84365151Seric+-----------------+ 84465151Seric 84565151SericAs of 8.6.5, sendmail daemons will catch a SIGUSR1 signal and log 84665151Sericsome debugging output (logged at LOG_DEBUG severity). The 84765151Sericinformation dumped is: 84865151Seric 84965151Seric * The value of the $j macro. 85065151Seric * A warning if $j is not in the set $=w. 85165151Seric * A list of the open file descriptors. 85265151Seric * The contents of the connection cache. 85365151Seric * If ruleset 89 is defined, it is evaluated and the results printed. 85465151Seric 85565151SericThis allows you to get information regarding the runtime state of the 85665151Sericdaemon on the fly. This should not be done too frequently, since 85765151Sericthe process of rewriting may lose memory which will not be recovered. 85865151SericAlso, ruleset 89 may call non-reentrant routines, so there is a small 85965151Sericnon-zero probability that this will cause other problems. It is 86065151Sericreally only for debugging serious problems. 86165151Seric 86265151SericA typical formulation of ruleset 89 would be: 86365151Seric 86465151Seric R$* $@ $>0 some test address 86565151Seric 86665151Seric 86764035Seric+-----------------------------+ 86864035Seric| DESCRIPTION OF SOURCE FILES | 86964035Seric+-----------------------------+ 87064035Seric 8719881SericThe following list describes the files in this directory: 8725369Seric 87357418SericMakefile The makefile used here; this version only works with 87457418Seric the new Berkeley make. 87557418SericMakefile.dist A trimmed down version of the makefile that works with 87657418Seric the old make. 8775369SericREAD_ME This file. 87860565SericTRACEFLAGS My own personal list of the trace flags -- not guaranteed 87960565Seric to be particularly up to date. 8805369Sericalias.c Does name aliasing in all forms. 8819881Sericarpadate.c A subroutine which creates ARPANET standard dates. 8829881Sericclock.c Routines to implement real-time oriented functions 8839881Seric in sendmail -- e.g., timeouts. 8845369Sericcollect.c The routine that actually reads the mail into a temp 8855369Seric file. It also does a certain amount of parsing of 8865369Seric the header, etc. 8875369Sericconf.c The configuration file. This contains information 8885369Seric that is presumed to be quite static and non- 8895369Seric controversial, or code compiled in for efficiency 8905369Seric reasons. Most of the configuration is in sendmail.cf. 8919881Sericconf.h Configuration that must be known everywhere. 8925369Sericconvtime.c A routine to sanely process times. 8939881Sericdaemon.c Routines to implement daemon mode. This version is 8949881Seric specifically for Berkeley 4.1 IPC. 8955369Sericdeliver.c Routines to deliver mail. 89660565Sericdomain.c Routines that interface with DNS (the Domain Name 89760565Seric System). 8985369Sericerr.c Routines to print error messages. 8999881Sericenvelope.c Routines to manipulate the envelope structure. 9005369Sericheaders.c Routines to process message headers. 9015369Sericmacro.c The macro expander. This is used internally to 9025369Seric insert information from the configuration file. 9035369Sericmain.c The main routine to sendmail. This file also 9045369Seric contains some miscellaneous routines. 90560565Sericmap.c Support for database maps. 90660565Sericmci.c Routines that handle mail connection information caching. 9079881Sericparseaddr.c The routines which do address parsing. 9085369Sericqueue.c Routines to implement message queueing. 9095369Sericreadcf.c The routine that reads the configuration file and 9105369Seric translates it to internal form. 9119881Sericrecipient.c Routines that manipulate the recipient list. 9125369Sericsavemail.c Routines which save the letter on processing errors. 9135369Sericsendmail.h Main header file for sendmail. 9145369Sericsrvrsmtp.c Routines to implement server SMTP. 9155369Sericstab.c Routines to manage the symbol table. 9165369Sericstats.c Routines to collect and post the statistics. 9175369Sericsysexits.c List of error messages associated with error codes 9185369Seric in sysexits.h. 9199881Serictrace.c The trace package. These routines allow setting and 9209881Seric testing of trace flags with a high granularity. 92160565Sericudb.c The user database interface module. 9225369Sericusersmtp.c Routines to implement user SMTP. 9235369Sericutil.c Some general purpose routines used by sendmail. 92460565Sericversion.c The version number and information about this 92560565Seric version of sendmail. Theoretically, this gets 92660565Seric modified on every change. 9275369Seric 9285369SericEric Allman 9295369Seric 930*68214Seric(Version 8.77, last update 01/31/95 08:07:21) 931