Add a FREEBSD-upgrade file describing what was done for the import

Remove obsolete files after the 8.11.0 import

19 files changed, 49 insertions, 5781 deletions

diff --git a/contrib/sendmail/FREEBSD-upgrade b/contrib/sendmail/FREEBSD-upgrade
new file mode 100644
index 0000000..ffcea89
--- /dev/null
+++ b/contrib/sendmail/FREEBSD-upgrade
@@ -0,0 +1,49 @@
+$FreeBSD$
+
+sendmail 8.11.0
+	originals can be found at: ftp://ftp.sendmail.org/pub/sendmail/
+
+For the import of sendmail, the following files were removed:
+
+	cf/cf/generic-bsd4.4.cf
+	cf/cf/generic-hpux10.cf
+	cf/cf/generic-hpux9.cf
+	cf/cf/generic-linux.cf
+	cf/cf/generic-osf1.cf
+	cf/cf/generic-solaris2.cf
+	cf/cf/generic-sunos4.1.cf
+	cf/cf/generic-ultrix4.cf
+	devtools/*
+	doc/op/op.ps
+	mail.local/mail.local.0
+	mailstats/mailstats.0
+	makemap/makemap.0
+	praliases/praliases.0
+	rmail/rmail.0
+	sendmail/aliases.0
+	sendmail/mailq.0
+	sendmail/newaliases.0
+	sendmail/sendmail.0
+	sendmail/sysexits.h
+	smrsh/smrsh.0
+	vacation/vacation.0
+
+The following directories were renamed:
+
+	sendmail -> src
+
+Imported using:
+
+	cvs import -m 'Import sendmail 8.11.0' \
+		src/contrib/sendmail SENDMAIL v8_11_0
+
+
+To make local changes to sendmail, simply patch and commit to the main
+branch (aka HEAD).  Never make local changes on the vendor (SENDMAIL)
+branch.
+
+All local changes should be submitted to the Sendmail Consortium
+<sendmail@sendmail.org> for inclusion in the next vendor release.
+
+gshapiro@FreeBSD.org
+12-August-2000
diff --git a/contrib/sendmail/cf/m4/nullrelay.m4 b/contrib/sendmail/cf/m4/nullrelay.m4
deleted file mode 100644
index b71fd57..0000000
--- a/contrib/sendmail/cf/m4/nullrelay.m4
+++ /dev/null
@@ -1,113 +0,0 @@
-divert(-1)
-#
-# Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
-# Copyright (c) 1983, 1995 Eric P. Allman.  All rights reserved.
-# Copyright (c) 1988, 1993
-#	The Regents of the University of California.  All rights reserved.
-#
-# By using this file, you agree to the terms and conditions set
-# forth in the LICENSE file which can be found at the top level of
-# the sendmail distribution.
-#
-#
-divert(0)
-
-VERSIONID(`@(#)nullrelay.m4	8.19 (Berkeley) 5/19/1998')
-
-#
-#  This configuration applies only to relay-only hosts.  They send
-#  all mail to a hub without consideration of the address syntax
-#  or semantics, except for adding the hub qualification to the
-#  addresses.
-#
-#	This is based on a prototype done by Bryan Costales of ICSI.
-#
-
-######################################################################
-######################################################################
-#####
-#####			REWRITING RULES
-#####
-######################################################################
-######################################################################
-
-###########################################
-###  Rulset 3 -- Name Canonicalization  ###
-###########################################
-S3
-
-# handle null input
-R$@			$@ <@>
-
-# strip group: syntax (not inside angle brackets!) and trailing semicolon
-R$*			$: $1 <@>			mark addresses
-R$* < $* > $* <@>	$: $1 < $2 > $3			unmark <addr>
-R$* :: $* <@>		$: $1 :: $2			unmark node::addr
-R:`include': $* <@>	$: :`include': $1			unmark :`include':...
-R$* : $* <@>		$: $2				strip colon if marked
-R$* <@>			$: $1				unmark
-R$* ;			   $1				strip trailing semi
-R$* < $* ; >		   $1 < $2 >			bogus bracketed semi
-
-# null input now results from list:; syntax
-R$@			$@ :; <@>
-
-# basic textual canonicalization -- note RFC733 heuristic here
-R$*			$: < $1 >		housekeeping <>
-R$+ < $* >		   < $2 >		strip excess on left
-R< $* > $+		   < $1 >		strip excess on right
-R<>			$@ < @ >		MAIL FROM:<> case
-R< $+ >			$: $1			remove housekeeping <>
-
-ifdef(`_NO_CANONIFY_', `dnl',
-`# eliminate local host if present
-R@ $=w $=: $+		$@ @ $M $2 $3			@thishost ...
-R@ $+			$@ @ $1				@somewhere ...
-
-R$=E @ $=w		$@ $1 @ $2			leave exposed
-R$+ @ $=w		$@ $1 @ $M			...@thishost
-R$+ @ $+		$@ $1 @ $2			...@somewhere
-
-R$=w ! $=E		$@ $2 @ $1			leave exposed
-R$=w ! $+		$@ $2 @ $M			thishost!...
-R$+ ! $+		$@ $1 ! $2 @ $M			somewhere ! ...
-
-R$=E % $=w		$@ $1 @ $2			leave exposed
-R$+ % $=w		$@ $1 @ $M			...%thishost
-R$+ % $+		$@ $1 @ $2			...%somewhere
-
-R$=E			$@ $1 @ $j			leave exposed
-R$+			$@ $1 @ $M			unadorned user')
-
-
-######################################
-###   Ruleset 0 -- Parse Address   ###
-######################################
-
-S0
-
-R$*:;<@>		$#error $@ USAGE $: "List:; syntax illegal for recipient addresses"
-
-# pass everything else to a relay host
-R$*			$#_RELAY_ $@ $H $: $1
-
-
-##################################################
-###  Ruleset 4 -- Final Output Post-rewriting  ###
-##################################################
-S4
-
-R$* <@>			$@				handle <> and list:;
-
-# strip trailing dot off before passing to nullclient relay
-R$* @ $+ .		$1 @ $2
-
-#
-######################################################################
-######################################################################
-#####
-`#####			MAILER DEFINITIONS'
-#####
-######################################################################
-######################################################################
-undivert(7)dnl
diff --git a/contrib/sendmail/cf/ostype/gnuhurd.m4 b/contrib/sendmail/cf/ostype/gnuhurd.m4
deleted file mode 100644
index a8ed667..0000000
--- a/contrib/sendmail/cf/ostype/gnuhurd.m4
+++ /dev/null
@@ -1,20 +0,0 @@
-divert(-1)
-#
-# Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
-# Copyright (c) 1997 Eric P. Allman.  All rights reserved.
-# Copyright (c) 1988, 1993
-#	The Regents of the University of California.  All rights reserved.
-#
-# By using this file, you agree to the terms and conditions set
-# forth in the LICENSE file which can be found at the top level of
-# the sendmail distribution.
-#
-#
-#
-
-divert(0)
-VERSIONID(`@(#)gnuhurd.m4	8.8 (Berkeley) 10/6/1998')
-ifdef(`HELP_FILE',, `define(`HELP_FILE', ifdef(`_USE_ETC_MAIL_', `/etc/mail/helpfile', `/share/misc/sendmail.hf'))')dnl
-ifdef(`STATUS_FILE',, `define(`STATUS_FILE', ifdef(`_USE_ETC_MAIL_', `/etc/mail/statistics', `/var/log/sendmail.st'))')dnl
-ifdef(`LOCAL_MAILER_PATH',, `define(`LOCAL_MAILER_PATH', /libexec/mail.local)')dnl
-define(`confEBINDIR', `/libexec')dnl
diff --git a/contrib/sendmail/contrib/converting.sun.configs b/contrib/sendmail/contrib/converting.sun.configs
deleted file mode 100644
index e6a3a9e..0000000
--- a/contrib/sendmail/contrib/converting.sun.configs
+++ /dev/null
@@ -1,446 +0,0 @@
-
-		     Converting Standard Sun Config
-		      Files to Sendmail Version 8
-
-			      Rick McCarty
-			 Texas Instruments Inc.
-		     Latest Update: 08/25/93 - RJMc
-
-This document details the changes necessary to continue using your
-current SunOS sendmail.cf with sendmail version 8.  In the longer term,
-it is recommended that one move to using an m4 based configuration such
-as those shipped with sendmail, but if you're like me and have made
-enough modifications to your .cf file that you'd rather put that task
-off until later, here's the sum total of my experience to get you to
-version 8 with minimal pain.  I'll cover .cf as well as build issues.
-
-Some background - as many are surely aware, Sun has some "special"
-features in the sendmail they ship ($%x, %y LHS lookup, NIS alias DB
-search, etc.).  (Some of those features can be had in alternative forms
-in IDA sendmail, but v8 has picked up some IDA capabilities as well as
-new ones, making it IMHO a most desirable version to go to.)  What I
-will explain below includes v8 functional "equivalences" to these Sun
-sendmail features.
-
-So with that out of the way, let's begin.
-
-First, some assumptions:
-
-	1) I'm going to assume you've got sendmail version 8.6 or
-	   later in hand - if not, grab it from ftp.cs.berkeley.edu
-	   in the ucb/sendmail directory.  There are bugs in earlier
-	   versions which affect some of the needed functionality.
-
-	2) Second, I'm going to detail this based upon the
-	   "sendmail.main.cf" configuration.  (BTW, if you attempt
-	   to move to using an m4 generated config in the future,
-	   MAIL_HUB is the feature which should provide similar
-	   functionality).
-
-	   In general, the changes will be similar for a subsidiary
-	   file, but since we (my TI group) funnel all non-local mail
-	   through our mailhost, we're not as interested in getting v8
-	   to run on such systems and I haven't tried it.
-
-	3) You're using DNS and sendmail.mx.  If you're not, you ought
-	   to be, even if you're also running it along with NIS (which
-	   we do - except for gethostbyxxx() lookups, which I'll be
-	   talking about later).  I would imagine you could get things
-	   running OK without DNS support, but I haven't tried it myself.
-
-	4) You're not mounting /var/spool/mail from other systems.
-	   I haven't found a v8 feature to guarantee this will work
-	   correctly.  Anyway, in the past, we've tried doing that
-	   here and found it to be a rather "ugly" feature, though
-	   Sun ostensibly supports it ("R" option).  Perhaps v8
-	   will one day have a similar feature, but for now, bottom
-	   line, I would recommend against it.
-
-	5) You're not on Solaris or using NIS+.  I'm on 4.1.3.  I've
-	   looked at Solaris briefly and have noted that things are
-	   pretty much similar there except that they've moved some
-	   things into the /etc/mail directory.  I'd guess the
-	   executables aren't functionally all that different from
-	   what they had before - the configs are roughly the same.
-	   So I'd bet most of what I say in here will apply to
-	   Solaris.
-
-OK, let's configure our sendmail.cf!  I'll just go from the top down...
-
-			  VARIOUS DECLARATIONS
-
-1) For v8, you need to define your .cf as AT LEAST a version level 4
-   configuration.  Add the following line:
-
-	V4
-
-   There are some issues regarding certain predefined macros - $w, $j, and
-   $m.  With a V4 configuration:
-
-	$w is defined to be the hostname, which will usually be fully
-	qualified (i.e. "firefly.add.itg.ti.com").
-
-	$j should have the same value as $w.
-
-	$m will be predefined as the domain portion of $w
-	(ex. "add.itg.ti.com").
-
-   One note about this - if your configuration relies on the "w" macro to
-   be the "simple" hostname (as mine does)...
-
-   If the configuration version is 5 or larger:
-
-	$w is supposed to be the "simple" name (ex. "firefly")
-
-	$j should be the fully qualified name (i.e. "firefly.add.itg.ti.com")
-
-	$m will be predefined as the domain portion of $j
-	(ex. "add.itg.ti.com").
-
-   I have not experimented with the various combinations, so I cannot
-   guarantee you that the above definitions will always come out as
-   expected.  Bottom line:  if your sendmail.cf depends on $w being the
-   simple hostname, test it carefully or define the name explicitly,
-   for example:
-
-	Dwfirefly
-
-2) To replace the Sun's "%y" feature, we must use a hostname mapping
-   feature in v8.  If you want to do similar lookups with v8, you need
-   to define the following map (we'll go over the rules that use this
-   map later):
-
-	Khostlookup host -f -m -a.
-
-   This will define a "lookup only" map that is otherwise the same as
-   sendmail version 8's built-in "host" map (see the "Sendmail
-   Installation and Operation Guide" for details on this map.).
-
-   An important note:  Whether or not these lookups will be done via
-   NIS is a function of what gethostbyxxx() functions you link into
-   your sendmail.  DO NOT redefine your host mapping to use NIS
-   explicitly within sendmail - there can be unexpected behaviour if
-   you do so (if you do any canonicalization in your .cf, you can get
-   incorrect results, for one thing).
-
-   For example, DO NOT TRY:
-
-	Khost nis -f -a. hosts.byname
-
-3) If you're doing reverse alias mapping as done in ruleset 22, instead of:
-
-	DZmail.byaddr
-
-   you'll need to declare the following:
-
-	Kaliasrev nis -f -N mail.byaddr
-
-4) If you are doing any other NIS map lookups, you'll need to define the
-   map as done in the below example.  I have a "mailhosts" map, which I
-   use to distinguish between local and non-local hosts.  Look at the
-   sendmail doc for details on this stuff.
-
-	Kmailhosts nis -f -m -a. mailhosts 
-
-5) You might wish to add the following line to support Errors-To: headers.
-   I don't.
-
-	Ol
-
-6) Comment out/remove the following line:
-
-	OR
-
-   The R option means something different under v8 - check the documentation
-   if you're interested in using it.
-
-7) If you're running NIS and have a separate alias map, BELOW the
-   following line where the alias file is declared:
-
-	OA/etc/aliases
-
-   ADD the following:
-
-	OAnis:mail.aliases
-
-   This will set things up so v8 will look at the local alias DB first,
-   then the NIS map, just as Sun sendmail does.
-
-8) Though you don't have to, I'd suggest changing:
-
-	OT3d
-
-   to use v8's warning feature, which allows a warning message to be
-   sent if a message cannot be delivered within a specified period.
-   I use:
-
-	OT5d/4h
-
-   which says - bounce after 5 days, warn after 4 hours.
-
-9) I set the following option to be explicit about how I want DNS
-    handled:
-
-	OI +DNSRCH +DEFNAMES
-
-10) The following line:
-
-	T root daemon uucp
-
-    may be deleted, though it will be ignored if you leave it around.
-
-11) It would probably be good to change the version macro value (which
-    shows up in "Received:" headers) so no one debugging mail problems
-    gets the wrong idea about what config you're running under.  Look
-    for something like:
-
-	DVSMI-4.1
-
-    Mine, for example is:
-
-	DVADD-HUB-2.1
-
-				RULESETS
-
-1)  In ruleset 3, BELOW this rule:
-
-	# basic textual canonicalization
-	R$*<$+>$*		$2			basic RFC822 parsing
-
-
-I add the following rule to remove a trailing dot in the domain spec so
-it won't interfere with v8 mapping features, etc.  (Having a trailing dot is
-not RFC-compliant anyway.):
-
-	R$+.			$1
-
-2) Because ruleset 5 is special in v8, I rename it to S95 and also change
-   all RHS expressions containing ">5" to use ">95" instead.  In v8,
-   5 is executed against addresses which resolve to the local mailer and
-   are not an alias.  If you don't change S5 to something else, you might
-   get a surprise!
-
-3) If you're doing any lookups via the generalized NIS "$%x/$!x"
-   mechanisms (such as with the mailhost map I referred to earlier) it's
-   done differently under v8.  For example:
-
-	DMmailhosts
-	...
-	R$*<@$%M.uucp>$*	$#ether $@$2 $:$1<@$2>$3
-
-   takes a different map definition and two rules under version 8:
-
-	Kmailhosts nis -f -m -a. mailhosts
-	...
-	R$*<@$+.uucp>$*		$: $1<@$(mailhosts $2 $).uucp>$3
-	R$*<@$+..uucp>$*	$#ether $@$2 $:$1<@$2>$3
-
-4) Sun has a special case of the "$%x" feature for host lookups - "%y" is
-   automagically defined to do an NIS "hosts.byname" search with no other
-   definition, as done in the below example:
-
-	R$*<@$%y.LOCAL>$*	$#ether $@$2 $:$1<@$2>$3
-
-   (Sun does this in more than one place.  But the above syntax is almost
-    identical in each - mostly a case of changing names to protect the
-    innocent.)
-
-   In version 8, the predefined "host" map can be used to do essentially
-   the same thing.  (However, whether or not it does an NIS lookup is
-   a function of what gethostbyxxx() functions are linked in.)
-
-   Recall the map definition I mentioned earlier in the DECLARATIONS
-   section:
-
-	Khostlookup host -f -m -a.
-
-   Here's where we will use it.  It will take two rules:
-
-	R$*<@$+.LOCAL>$*	$: $1<@$(hostlookup $2 $).LOCAL>$3
-	R$*<@$+..LOCAL>$*	$#ether $@$2 $:$1<@$2>$3
-
-   Note that this is almost verbatim the same change as was used in the
-   previous "mailhosts" example.
-
-5) Although Sun's default configs don't do this, because I mentioned
-   canonicalization earlier, it deserves an example, as it's illustrative
-   of the functional difference in the map definitions I discussed before.
-   This stuff is also convered in the "Sendmail Installation and Operation
-   Guide".
-
-   Remember the built-in "host" map definition?  As you'll recall, unlike
-   the "hostlookup" map we defined, "host" will actually CHANGE the
-   hostname in addition to appending a dot.  "hostlookup" only appends a
-   dot if the name is found and doesn't change it otherwise.  Anyway,
-   here's the example:
-
-	R$*<@$+>$*	$: $1<@$(host $2 $)>$3		canonicalize
-	R$*<@$+.>$*	$1<@$2>$3			remove trailing dot
-
-   Using the above, say you had input of:
-
-	joe<@tilde>
-
-	OR
-
-	joe<@[128.247.160.56]>
-
-	Assuming "tilde" or the IP address is found, it might be
-        canonicalized as:
-
-	joe<@tilde.csc.ti.com>
-
-6) As another instance of the NIS lookup feature, with a slightly
-   different twist, Sun implements reverse alias mapping in ruleset 22
-   with the below:
-
-	DZmail.byaddr
-	...
-	R$-<@$->		$:$>3${Z$1@$2$}			invert aliases
-
-   To use this feature under v8, change the above rule a (remember to
-   define the alias map as I showed earlier):
-
-	R$-<@$->		$:$>3$(aliasrev $1@$2 $)	invert aliases
-
-
-			   MAILER DEFINITIONS
-
-1) Where "TCP" is defined in the "P=" and "A=" parameters of mailers, I
-   changed it to "IPC".  Version 8 will accept "TCP", but "IPC" is
-   preferred.
-
-2) On all IPC mailers, I also defined "E=\r\n" and added an "L=1000" as
-   in the below example:
-
-	Mether,	P=[IPC], F=mDFMuCX, S=11, R=21, L=1000, E=\r\n, A=IPC $h
-
-   The "E=\r\n" will save you headaches interoperating with such things as
-   VMS TCP products.
-
-   The "L=1000" is for RFC821 compatibility.  Not strictly necessary.
-
-   I also removed the "s" (strip quotes) mailer flag Sun puts in for
-   these mailers.  Stripping quotes violates protocols, which say
-   clearly that you can't touch the local-part (left hand side of
-   the @) until you are on the delivering host.
-
-NOW.  If I haven't left anything out, you should be able to run through
-your Sun sendmail.cf file and convert it to run under v8.
-
-			      BUILD ISSUES
-
-Some important notes on building v8 on SunOS:
-
-Makefile
-
-The default makefile in the version 8 source (src) directory assumes the
-new Berkeley make.  Unless you want to go to the trouble of building it,
-you can use your regular make, but you need to use a different makefile.
-You can use "Makefile.dist" or "Makefile.SunOS" in the src directory.  I
-made changes to get it to build so it is as compatible as possible with
-the file/directory locations Sun uses.  Here are some relevant sections
-out of my makefile:
-
-	CC=gcc
-
-	# use O=-O (usual) or O=-g (debugging)
-	O=	-O
-
-	# define the database mechanisms available for map & alias lookups:
-	#	-DNDBM -- use new DBM
-	#	-DNEWDB -- use new Berkeley DB
-	#	-DNDBM -DNEWDB -DYPCOMPAT -- use both plus YP compatility
-	#	-DNIS -- include client NIS support
-	# The really old (V7) DBM library is no longer supported.
-	# See README for a description of how these flags interact.
-	#DBMDEF= -DNDBM -DNEWDB
-	DBMDEF=	-DNDBM -DNIS
-
-	# environment definitions (e.g., -D_AIX3)
-	ENVDEF=
-
-	# see also conf.h for additional compilation flags
-
-	# library directories
-	LIBDIRS=-L/usr/local/lib
-
-	# libraries required on your system
-	#LIBS=	-ldb -ldbm
-	LIBS=	-ldbm -lresolv
-
-	# location of sendmail binary (usually /usr/sbin or /usr/lib)
-	BINDIR=	${DESTDIR}/usr/lib
-
-	# location of sendmail.st file (usually /var/log or /usr/lib)
-	STDIR=	${DESTDIR}/etc
-
-	# location of sendmail.hf file (usually /usr/share/misc or /usr/lib)
-	HFDIR=	${DESTDIR}/usr/lib
-
-For the resolver library, you can use the one shipped with Sun if you
-want.  But I'd recommend using another version of the resolver library
-(such as the one with Bind 4.8.3 or 4.9).  Sun's resolver stuff (at
-least with 4.1.x) is quite old - I believe it is of 4.3.1 vintage.  (Do
-you get the impression I don't TRUST what Sun ships with their systems?)
-
-If you want NIS host lookup while maintaining DNS capability, you might
-take a look at resolv+, which has NIS capable gethostbyxxx() functions
-in it.  My recommendation, however, is to avoid doing NIS host lookups
-in sendmail altogether, and to use a "pure" version of the resolver
-library.
-
-There are probably no situations (at least I think so) where it makes
-any sense to link in Sun's NIS gethostbyxxx() functions from libc.
-You could, I guess do it (I haven't tried it) and wind up with a
-sendmail equivalent to the non-mx version Sun ships.  You'd need to
-insure that NAMED_BIND is not defined in the build.  (If you do
-this and have the "-b" DNS passthru option set in NIS, remember that
-while you have some DNS functionality you'll not have any MX support.
-(This, IMO, is what makes this a non-optimal choice.)
-
-		      INSTALLATION/TESTING ISSUES
-
-The sendmail.hf file in the src directory should replace the one currently
-in /usr/lib.  You also might choose to edit it a bit to "localize" what it
-says.
-
-The sendmail executable goes, of course, in /usr/lib in place of the current
-one.  What I did was create a subdirectory in /usr/lib and put all of the
-Sun sendmail stuff in there.  I named the v8 sendmail executable to be
-sendmail.v8.mx and then symbolically linked it to sendmail.
-
-One other thing.  If you use address test mode, keep in mind that
-Version 8 is like IDA in that it does not automatically execute ruleset
-3 first.  So say you're playing around with things testing addresses and
-you're used to things like:
-
-	0 jimbob@good.old.boy.com
-
-under v8 you need to say instead:
-
-	3,0 jimbob@good.old.boy.com
-
-	      INTEROPERABILITY ISSUES YOU MIGHT ENCOUNTER
-
-Be aware that sendmail v8 issues a multi-line SMTP welcome (220)
-response upon a client connection.  Most systems in your network should
-handle it OK, but there are some that choke on it, because whoever wrote
-the clients assumed only a single line.  THIS IS NOT SENDMAIL's FAULT.
-A multi-line 220 response is perfectly valid.  A likely place you'll
-encounter this problem is with non-Un*x SMTP clients.  If you do run
-into it, you should report it to the vendor.
-
-A final note about version 8 - if you follow the above configuration
-scenario, you'll notice it doesn't like to get envelope sender
-addresses it doesn't know how to get back to.  Sun sendmail would take
-anything, even though it might not be able to bounce the message back
-should something happen downstream.  So if another sendmail on a host
-that's not locally known is trying to pump mail through your v8 host,
-the ENVELOPE sender it gives had better be fully qualified.  This is
-a GREAT thing, because it helps clear up problems we've had with not
-being able to get things back to the sender, resulting in an
-overburdened postmaster.
-
-I hope this helps those running Sun sendmail feel more at ease with moving
-on to v8.  It's really worth going to.
diff --git a/contrib/sendmail/doc/changes/Makefile b/contrib/sendmail/doc/changes/Makefile
deleted file mode 100644
index 76eaa39..0000000
--- a/contrib/sendmail/doc/changes/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-#	@(#)Makefile	8.1 (Berkeley) 4/13/1994
-
-DIR=	smm/09.sendmail
-SRCS=	changes.me
-MACROS=	-me
-
-all: changes.ps
-
-changes.ps: ${SRCS}
-	rm -f ${.TARGET}
-	${PIC} ${SRCS} | ${ROFF} > ${.TARGET}
-
-.include <bsd.doc.mk>
diff --git a/contrib/sendmail/doc/changes/changes.me b/contrib/sendmail/doc/changes/changes.me
deleted file mode 100644
index b963396..0000000
--- a/contrib/sendmail/doc/changes/changes.me
+++ /dev/null
@@ -1,975 +0,0 @@
-.\" Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
-.\" Copyright (c) 1994 Eric P. Allman.  All rights reserved.
-.\" Copyright (c) 1988, 1994
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" By using this file, you agree to the terms and conditions set
-.\" forth in the LICENSE file which can be found at the top level of
-.\" the sendmail distribution.
-.\"
-.\"
-.\"	@(#)changes.me	8.7 (Berkeley) 5/19/1998
-.\"
-.\"	ditroff -me -Pxx changes.me
-.eh '%''Changes in Sendmail Version 8'
-.oh 'Changes in Sendmail Version 8''%'
-.nr si 3n
-.if n .ls 2
-.+c
-.(l C
-.sz 14
-Changes in Sendmail Version 8*
-.sz
-.sp
-Eric Allman
-.sp 0.5
-.i
-University of California, Berkeley
-Mammoth Project
-.)l
-.(f
-*An earlier version of this paper was printed in the
-Proceedings of the 1994 AUUG Queensland Summer Technical Conference,
-Gateway Hotel, Brisbane, March 1994.
-.)f
-.sp
-.(l F
-.ce
-ABSTRACT
-.sp \n(psu
-Version 8 of
-.i sendmail
-includes a number of major changes from previous versions.
-This paper gives a very short history of
-.i sendmail ,
-a summary of the major differences between version 5
-(the last publically available version)
-and version 8,
-and some discussion of future directions.
-.)l
-.sp 2
-.pp
-In 1987, the author stopped major work on
-.i sendmail
-due to other time committments,
-only to return to active work in 1991.
-This paper explores why work resumed
-and what changes have been made.
-.pp
-Section 1 gives a short history of
-.i sendmail
-through version 5 and the motivation behind working on version 8.
-Section 2 has
-a rather detailed description of what has changed
-between version 5 and version 8.
-The paper finishes off with some thoughts
-about what still needs to be done.
-.sh 1 "HISTORY"
-.pp
-As discussed elsewhere,
-[Allman83a, Allman83b, Allman&Amos85]
-sendmail has existed in various forms since 1980.
-It was released under the name
-.i delivermail
-in 4BSD and 4.1BSD, and as
-.i sendmail
-in 4.2BSD.
-.\"4.0BSD	delivermail 1.10
-.\"4.1BSD	delivermail 1.10
-.\"4.2BSD	sendmail 4.12
-.\"4.3BSD	sendmail 5.52
-It quickly became the dominant mail system for networked UNIX systems.
-.pp
-Prior the release of 4.3BSD in November 1986,
-the author had left the University for private industry,
-but continued to do some work on
-.i sendmail
-with activity slowly trailing off
-until effectively stopping after February 1987.
-There was minimal support done by many people for several years,
-until July of 1991 when the original author,
-who had returned the University,
-started active work on it again.
-.pp
-There were several reasons for renewed work on
-.i sendmail .
-There was a desire at Berkeley to convert to a subdomained structure
-so that individuals were identified by their subdomain
-rather than by their individual workstation;
-although possible in the old code, there were some problems,
-and the author was the obvious person to address them.
-The Computer Systems Research Group (CSRG),
-the group that produced the Berkeley Software Distributions,
-was working on 4.4BSD,
-and wanted an update to the mail system.
-Bryan Costales was working on a book on
-.i sendmail
-that was being reviewed by the author,
-which encouraged him to make some revisions.
-And the author wanted to try to unify some of the disparate versions of
-.i sendmail
-that had been permitted to proliferate.
-.pp
-During the 1987\-91 fallow period,
-many vendors and outside volunteers
-had produced variants of
-.i sendmail .
-Perhaps the best known is the IDA version
-[IDA87].
-Originally intended to be a new set of configuration files,
-IDA expanded into a fairly large set of patches for the code.
-Originally produced in Sweden,
-IDA development passed to the University of Illinois,
-and was widely used by the fairly large set of people
-who prefer to get and compile their own source code
-rather than use vendor-supplied binaries.
-.pp
-In about the same time frame,
-attempts were made to clean up and extend the Simple Mail Transport Protocol
-(SMTP)
-[RFC821].
-This involved clarifications of some ambiguities in the protocol,
-and correction of some problem areas
-[RFC1123],
-as well as extensions for additional functionality
-(dubbed Extended Simple Mail Transport Protocol, or ESMTP)
-[RFC1425, RFC1426, RFC1427]
-and a richer set of semantics in the body of messages
-(the Multipurpose Internet Mail Extensions, a.k.a. MIME)
-[RFC1521, RFC1344].
-Neither the IDA group nor most vendors
-were modifying
-.i sendmail
-to conform to these new standards.
-It seemed clear that these were ``good things''
-that should be encouraged.
-However, since no one was working on a publically available version of
-.i sendmail
-with these updates,
-they were unlikely to be widely deployed any time in the near future.
-.pp
-There are, of course, other mail transport agents available,
-such as
-.i MMDF
-.\"[ref],
-.i zmailer
-.\"[ref],
-.i smail
-.\"[ref],
-and
-.i PP
-.\"[ref].
-However, none of these seemed to be gaining the prominence of
-.i sendmail ;
-it appeared that most companies would not convert to another
-mail transport agent any time in the forseeable future.
-However, they might be persuaded to convert to a newer version of
-.i sendmail .
-.pp
-All of these convinced the author
-to work on a updated version of
-.i sendmail
-for public distribution.
-.pp
-The new version of
-.i sendmail
-is referred to as version eight (V8).
-Versions six and seven were skipped
-because of an agreement
-that all files in 4.4BSD would be numbered as
-.q 8.1 .
-Rather than have an external version number
-that differed from the file version numbers,
-.i sendmail
-just jumped directly to V8.
-.sh 1 "CHANGES IN VERSION EIGHT"
-.pp
-The following is a summary of the changes between the last commonly
-available version of sendmail from Berkeley (5.67) and the latest
-version (8.6.6).
-.pp
-Many of these are ideas that had been tried in IDA,
-but many of them were generalized in V8.
-.sh 2 "Performance Enhancements"
-.pp
-Instead of closing SMTP connections immediately, open connections are
-cached for possible future use.  There is a limit to the number of
-simultaneous open connections and the idle time of any individual
-connection.
-.pp
-This is of best help during queue processing (since there is the
-potential of many different messages going to one site), although
-it can also help when processing MX records which aren't handled
-by MX Piggybacking.
-.pp
-If two hosts with different names in a single message happen to
-have the same set of MX hosts, they can be sent in the same
-transaction.  Version 8 notices this and tries to batch the messages.
-.pp
-For example, if two sites ``foo.com'' and ``bar.com'' are both
-served by UUNET, they will have the same set of MX hosts and will
-be sent in one transaction.  UUNET will then split the message
-and send it to the two individual hosts.
-.sh 2 "RFC 1123 Changes"
-.pp
-A number of changes have been made to make sendmail ``conditionally
-compliant'' (that is, it satisfies all of the MUST clauses and most
-but not all of the SHOULD clauses in RFC 1123).
-.pp
-The major areas of change are (numbers are RFC 1123 section numbers):
-.nr ii 0.75i
-.ip \(sc5.2.7
-Response to RCPT command is fast.  Previously, sendmail
-expanded all aliases as far as it could \*- this could
-take a very long time, particularly if there were
-name server delays.  Version 8 only checks for the
-existence of an alias and does the expansion later.
-It does still do a DNS lookup if there is an explicit host name
-in the RCPT command,
-but this time is bounded.
-.ip \(sc5.2.8
-Numeric IP addresses are logged in Received: lines.
-This helps tracing spoofed messages.
-.ip \(sc5.2.17
-Self domain literal is properly handled.  Previously,
-if someone sent to user@[1.2.3.4], where 1.2.3.4 is
-your IP address, the mail would probably be rejected
-with a ``configuration error''.
-Version 8 can handle these addresses.
-.ip \(sc5.3.2
-Better control over individual timeouts.  RFC 821 specified
-no timeouts.  Older versions of sendmail had a single
-timeout, typically set to two hours.  Version 8 allows
-the configuration file to set timeouts for various
-SMTP commands individually.
-.ip \(sc5.3.3
-Error messages are sent as From:<>.  This was urged by
-RFC 821 and reiterated by RFC 1123, but older versions
-of sendmail never really did it properly.  Version 8
-does.  However, some systems cannot handle this
-perfectly legal address; if necessary, you can create
-a special mailer that uses the `g' flag to disable this.
-.ip \(sc5.3.3
-Error messages are never sent to <>.  Previously,
-sendmail was happy to send responses-to-responses which
-sometimes resulted in responses-to-responses-to-responses
-which resulted in ....  you get the idea.
-.ip \(sc5.3.3
-Route-addrs (the ugly ``<@hosta,@hostb:user@hostc>''
-syntax) are pruned.  RFC 821 urged the use of this
-bletcherous syntax.  RFC 1123 has seen the light and
-officially deprecates them, further urging that you
-eliminate all but ``user@hostc'' should you receive
-one of these things.  Version 8 is slightly more generous
-than the standards suggest; instead of stripping off all
-the route addressees, it only strips hosts off up to
-the one before the last one known to DNS, thus allowing
-you to have pseudo-hosts such as foo.BITNET.  The `R'
-option will turn this off.
-.lp
-The areas in which sendmail is not ``unconditionally compliant'' are:
-.ip \(sc5.2.6
-Sendmail does do header munging.
-.ip \(sc5.2.10
-Sendmail doesn't always use the exact SMTP message
-text from RFC 821.  This is a rather silly requirement.
-.ip \(sc5.3.1.1
-Sendmail doesn't guarantee only one connect for each
-host on queue runs.  Connection caching gives you most
-of this, but it does not provide a guarantee.
-.ip \(sc5.3.1.1
-Sendmail doesn't always provide an adequate limit
-on concurrency.  That is, there can be several
-independent sendmails running at once.  My feeling
-is that doing an absolute limit would be a mistake
-(it might result in lost mail).  However, if you use
-the XLA contributed software, most of this will be
-guaranteed (but I don't guarantee the guarantee).
-.sh 2 "Extended SMTP Support
-.pp
-Version 8 includes both sending and receiving support for Extended
-SMTP support as defined by RFC 1425 (basic) and RFC 1427 (SIZE);
-and limited support for RFC 1426 (BODY).
-The body support is minimal because the
-.q 8BITMIME
-body type is not currently advertised.
-Although such a body type will be accepted,
-it will not be correctly converted to 7 bits
-if speaking to a non-8-bit-MIME aware SMTP server.
-.pp
-.i Sendmail
-tries to speak ESMTP if you have the `a' flag set
-in the flags for the mailer descriptor,
-or if the other end advertises the fact that it speaks ESMTP.
-This is a non-standard advertisement:
-.i sendmail
-announces
-.q "ESMTP spoken here"
-during the initial connection message,
-and client sendmails search for this message.
-This creates some problems for some PC-based mailers,
-which do not understand two-line greeting messages
-as required by RFC 821.
-.sh 2 "Eight-Bit Clean
-.pp
-Previous versions of sendmail used the 0200 bit for quoting.  This
-version avoids that use.
-However, you can set option `7' to get seven bit stripping
-for compatibility with RFC 821,
-which is a 7-bit protocol.
-This option says ``strip to 7 bits on input''.
-.pp
-Individual mailers can still produce seven bit out put using the
-`7' mailer flag.
-This flag says ``strip to 7 bits on output''.
-.sh 2 "User Database"
-.pp
-The User Database (UDB) is an as-yet experimental attempt to provide
-unified large-site name support.
-We are installing it at Berkeley;
-future versions may show significant modifications.
-Briefly, UDB contains a database that is intended to contain
-all the per-user information for your workgroup,
-such as people's full names, their .plan information,
-their outgoing mail name, and their mail drop.
-.pp
-The user database allows you to map both incoming and outgoing
-addresses, much like IDA.  However, the interface is still
-better with IDA;
-in particular, the alias file with incoming/outgoing marks
-provides better locality of information.
-.sh 2 "Improved BIND Support"
-.pp
-The BIND support, particularly for MX records, had a number of
-annoying ``features'' which have been removed in this release.  In
-particular, these more tightly bind (pun intended) the name server
-to sendmail, so that the name server resolution rules are incorporated
-directly into sendmail.
-.pp
-The major change has been that the $[ ... $] operator didn't fully
-qualify names that were in DNS as A or MX records.  Version 8 does
-this qualification.
-.pp
-This has proven to be an annoyance in Sun shops,
-who often still run without BIND support.
-However, it is really critical that this be supported,
-since MX records are mandatory.
-In SunOS you can choose either MX support or NIS support,
-but not both.
-This is fixed in Solaris,
-and some
-.i sendmail
-support to allow this in SunOS should be forthcoming in a future release.
-.sh 2 "Keyed Files"
-.pp
-Generalized keyed files is an idea taken directly from IDA sendmail
-(albeit with a completely different implementation).
-They can be useful on large sites.
-.pp
-Version 8 includes the following built-in map classes:
-.ip dbm
-Support for the ndbm(3) library.
-.ip hash
-Support for the ``Hash'' type from the new Berkeley db(3) library.
-this library provides substantially better database support
-than ndbm(3),
-including in-memory caching,
-arbitrarily long keys and values,
-and better disk utilization.
-.ip btree
-Support for the ``B-Tree'' type from the new Berkeley db(3) library.
-B-Trees provide better clustering than Hashed files
-if you are fetching lots of records that have similar keys,
-such as searching a dictionary for words beginning with ``detr''.
-.ip nis
-Support for NIS (a.k.a. YP) maps.
-NIS+ is not supported in this version.
-.ip host
-Support for DNS lookups.
-.ip dequote
-A ``pseudo-map'' (that is, once that does not have any external data)
-that allows a configuration file to break apart a quoted string
-in the address.
-This is necessary primarily for DECnet addresses,
-which often have quoted addresses that need to be unwrapped on gateways.
-.sh 2 "Multi-Word Classes & Macros in Classes"
-.pp
-Classes can now be multiple words.  For example,
-.(b
-CShofmann.CS.Berkeley.EDU
-.)b
-allows you to match the entire string ``hofmann.CS.Berkeley.EDU''
-using the single construct ``$=S''.
-.pp
-Class definitions are now allowed to include macros \*- for example:
-.(b
-Cw$k
-.)b
-is legal.
-.sh 2 "IDENT Protocol Support"
-.pp
-The IDENT protocol as defined in RFC 1413 [RFC1413] is supported.
-However, many systems have a TCP/IP bug that renders this useless,
-and the feature must be turned off.
-Roughly, if one of these system receives a
-.q "No route to host"
-message (ICMP message ICMP_UNREACH_HOST) on
-.i any
-connection, all connections to that host are closed.
-Some firewalls return this error if you try to connect
-to the IDENT port,
-so you can't receive email from these hosts on these systems.
-It's possible that if the firewall used a more specific message
-(such as ICMP_UNREACH_PROTOCOL, ICMP_UNREACH_PORT or ICMP_UNREACH_NET_PROHIB)
-it would work, but this hasn't been verified.
-.pp
-IDENT protocol support cannot be used on
-4.3BSD,
-Apollo DomainOS,
-Apple A/UX,
-ConvexOS,
-Data General DG/UX,
-HP-UX,
-Sequent Dynix,
-or
-Ultrix 4.x, x \(<= 3.
-It seems to work on
-4.4BSD,
-IBM AIX 3.x,
-OSF/1,
-SGI IRIX,
-Solaris,
-SunOS,
-and Ultrix 4.4.
-.sh 2 "Separate Envelope/Header Processing
-.pp
-Since the From: line is passed in separately from the envelope
-sender, these have both been made visible; the $g macro is set to
-the envelope sender during processing of mailer argument vectors
-and the header sender during processing of headers.
-.pp
-It is also possible to specify separate per-mailer envelope and
-header processing.  The SenderRWSet and RecipientRWset arguments
-for mailers can be specified as ``envelope/header'' to give different
-rewritings for envelope versus header addresses.
-.sh 2 "Owner-List Propagates to Envelope
-.pp
-When an alias has an associated owner-list name, that alias is used
-to change the envelope sender address.  This will cause downstream
-errors to be returned to that owner.
-.pp
-Some people find this confusing
-because the envelope sender is what appears in the first
-``From_'' line in UNIX messages
-(that is, the line beginning ``From<space>''
-instead of ``From:'';
-the latter is the header from, which
-.i does
-indicate the sender of the message).
-In previous versions,
-.i sendmail
-has tried to avoid changing the envelope sender
-for back compatibility with UNIX convention;
-at this point that back compatibility is creating too many problems,
-and it is necessary to move forward into the 1980s.
-.sh 2 "Command Line Flags"
-.pp
-The
-.b \-B
-flag has been added to pass in body type information.
-.pp
-The
-.b \-p
-flag has been added to pass in protocol information
-that was previously passed in by defining the
-.b $r
-and
-.b $s
-macros.
-.pp
-The
-.b \-X
-flag has been added to allow logging of all protocol in and
-out of sendmail for debugging.
-You can set
-.q "\-X filename"
-and a complete transcript will be logged in that file.
-This gets big fast: the option is only for debugging.
-.pp
-The
-.b \-q
-flag can limit limit a queue run to specific recipients,
-senders, or queue ids using \-qRsubstring, \-qSsubstring, or
-\-qIsubstring respectively.
-.sh 2 "New Configuration Line Types
-.pp
-The `T' (Trusted users) configuration line has been deleted.  It
-will still be accepted but will be ignored.
-.pp
-The `K' line has been added to declare database maps.
-.pp
-The `V' line has been added to declare the configuration version
-level.
-.pp
-The `M' (mailer) line takes a D= field to specify execution
-directory.
-.sh 2 "New and Extended Options"
-.pp
-Several new options have been added, many to support new features,
-others to allow tuning that was previously available only by
-recompiling.  Briefly:
-.nr ii 0.5i
-.ip A
-The alias file specification can now be a list of alias files.
-Also, the configuration can specify a class of file.
-For example, to search the NIS aliases, use
-.q OAnis:mail.aliases .
-.ip b
-Insist on a minimum number of disk blocks.
-.ip C
-Delivery checkpoint interval.  Checkpoint the queue (to avoid
-duplicate deliveries) every C addresses.
-.ip E
-Default error message.  This message (or the contents of the
-indicated file) are prepended to error messages.
-.ip G
-Enable GECOS matching.  If you can't find a local user name
-and this option is enabled, do a sequential scan of the passwd
-file to match against full names.  Previously a compile option.
-.ip h
-Maximum hop count.  Previously this was compiled in.
-.ip I
-This option has been extended to allow setting of resolver parameters.
-.ip j
-Send errors in MIME-encapsulated format.
-.ip J
-Forward file path.  Where to search for .forward files \*- defaults
-to $HOME/.forward.
-.ip k
-Connection cache size.  The total number of connections that will
-be kept open at any time.
-.ip K
-Connection cache lifetime.  The amount of time any connection
-will be permitted to sit idle.
-.ip l
-Enable Errors-To: header.  These headers violate RFC 1123;
-this option is included to provide back compatibility with
-old versions of sendmail.
-.ip O
-Incoming daemon options (e.g., use alternate SMTP port).
-.ip p
-Privacy options.  These can be used to make your SMTP server
-less friendly.
-.ip r
-This option has been extended to allow finer grained control
-over timeouts.
-For example, you can set the timeout for SMTP commands individually.
-.ip R
-Don't prune route-addrs.  Normally, if version 8 sees an address
-like "<@hostA,@hostB:user@hostC>, sendmail will try to strip off
-as much as it can (up to user@hostC) as suggested by RFC 1123.
-This option disables that behaviour.
-.ip T
-The
-.q "Return To Sender"
-timeout has been extended
-to allow specification of a warning message interval,
-typically something on the order of four hours.
-If a message cannot be delivered in that interval,
-a warning message is sent back to the sender
-but the message continues to be tried.
-.ip U
-User database spec.  This is still experimental.
-.ip V
-Fallback ``MX'' host.  This can be thought of as an MX host
-that applies to all addresses that has a very high preference
-value (that is, use it only if everything else fails).
-.ip w
-If set, assume that if you are the best MX host for a host,
-you should send directly to that host.  This is intended
-for compatibility with UIUC sendmail, and may have some
-use on firewalls.
-.ip 7
-Do not run eight bit clean.  Technically, you have to assert
-this option to be RFC 821 compatible.
-.sh 2 "New Mailer Definitions"
-.ip L=
-Set the allowable line length.  In V5, the L mailer flag implied
-a line length limit of 990 characters; this is now settable to
-an arbitrary value.
-.ip F=a
-Try to use ESMTP.  It will fall back to SMTP if the initial
-EHLO packet is rejected.
-.ip F=b
-Ensure a blank line at the end of messages.  Useful on the
-*file* mailer.
-.ip F=c
-Strip all comments from addresses; this should only be used as
-a last resort when dealing with cranky mailers.
-.ip F=g
-Never use the null sender as the envelope sender, even when
-running SMTP.  This violates RFC 1123.
-.ip F=7
-Strip all output to this mailer to 7 bits.
-.ip F=L
-Used to set the line limit to 990 bytes for SMTP compatibility.
-It now does that only if the L= keyletter is not specified.
-This flag is obsolete and should not be used.
-.sh 2 "New or Changed Pre-Defined Macros"
-.ip $k
-UUCP node name from uname(2).
-.ip $m
-Domain part of our full hostname.
-.ip $_
-RFC 1413-provided sender address.
-.ip $w
-Previously was sometimes the full domain name, sometimes
-just the first word.  Now guaranteed to be the first word
-of the domain name (i.e., the host name).
-.ip $j
-Previously had to be defined \*- it is now predefined to be
-the full domain name, if that can be determined.  That is,
-it is equivalent to $w.$m.
-.sh 2 "New and Changed Classes"
-.ip $=k
-Initialized to contain $k.
-.ip $=w
-Now includes
-.q [1.2.3.4]
-(where 1.2.3.4 is your IP address)
-to allow the configuration file to recognize your own IP address.
-.sh 2 "New Rewriting Tokens"
-.pp
-The
-.b $&
-construct has been adopted from IDA to defer macro evaluation.
-Normally, macros in rulesets are bound when the rule is first parsed
-during startup.
-Some macros change during processing and are uninteresting during startup.
-However, that macro can be referenced using
-.q $&x
-to defer the evaulation of
-$x
-until the rule is processed.
-.pp
-The tokens
-.b $(
-and
-.b $)
-have been added to allow specification of map rewriting.
-.pp
-Version 8 allows
-.b $@
-on the Left Hand Side of an `R' line to match
-zero tokens.
-This is intended to be used to match the null input.
-.sh 2 "Bigger Defaults
-.pp
-Version 8 allows up to 100 rulesets instead of 30.  It is recommended
-that rulesets 0\-9 be reserved for sendmail's dedicated use in future
-releases.
-.pp
-The total number of MX records that can be used has been raised to
-20.
-.pp
-The number of queued messages that can be handled at one time has
-been raised from 600 to 1000.
-.sh 2 "Different Default Tuning Parameters
-.pp
-Version 8 has changed the default parameters for tuning queue costs
-to make the number of recipients more important than the size of
-the message (for small messages).  This is reasonable if you are
-connected with reasonably fast links.
-.sh 2 "Auto-Quoting in Addresses
-.pp
-Previously, the ``Full Name <email address>'' syntax would generate
-incorrect protocol output if ``Full Name'' had special characters
-such as dot.  This version puts quotes around such names.
-.sh 2 "Symbolic Names On Error Mailer
-.pp
-Several names have been built in to the $@ portion of the $#error
-mailer.  For example:
-.(b
-$#error $@NOHOST $: Host unknown
-.)b
-Prints the indicated message
-and sets the exit status of
-.i sendmail
-to
-.sm EX_NOHOST .
-.sh 2 "New Built-In Mailers"
-.pp
-Two new mailers, *file* and *include*, are included to define options
-when mailing to a file or a :include: file respectively.  Previously
-these were overloaded on the local mailer.
-.sh 2 "SMTP VRFY Doesn't Expand
-.pp
-Previous versions of sendmail treated VRFY and EXPN the same.  In
-this version, VRFY doesn't expand aliases or follow .forward files.
-.pp
-As an optimization, if you run with your default delivery mode
-being queue-only, the RCPT command will also not chase aliases and
-\&.forward files.
-It will chase them when it processes the queue.
-This speeds up RCPT processing.
-.sh 2 "[IPC] Mailers Allow Multiple Hosts
-.pp
-When an address resolves to a mailer that has ``[IPC]'' as its
-``Path'', the $@ part (host name) can be a colon-separated list of
-hosts instead of a single hostname.  This asks sendmail to search
-the list for the first entry that is available exactly as though
-it were an MX record.  The intent is to route internal traffic
-through internal networks without publishing an MX record to the
-net.  MX expansion is still done on the individual items.
-.sh 2 "Aliases Extended"
-.pp
-The implementation has been merged with maps.  Among other things,
-this supports multiple alias files and NIS-based aliases.  For
-example:
-.(b
-OA/etc/aliases,nis:mail.aliases
-.)b
-will search first the local database
-.q /etc/aliases
-followed by the NIS map
-
-.sh 2 "Portability and Security Enhancements
-.pp
-A number of internal changes have been made to enhance portability.
-.pp
-Several fixes have been made to increase the paranoia factor.
-.pp
-In particular, the permissions required for .forward and :include:
-files have been tightened up considerably.  V5 would pretty much
-read any file it could get to as root, which exposed some security
-holes.  V8 insists that all directories leading up to the .forward
-or :include: file be searchable ("x" permission) by the controlling
-user" (defined below), that the file itself be readable by the
-controlling user, and that .forward files be owned by the user
-who is being forwarded to or root.
-.pp
-The "controlling user" is the user on whose behalf the mail is
-being delivered.  For example, if you mail to "user1" then the
-controlling user for ~user1/.forward and any mailers invoked
-by that .forward file, including :include: files.
-.pp
-Previously, anyone who had a home directory could create a .forward
-could forward to a program.  Now, sendmail checks to make sure
-that they have an "approved shell", that is, a shell listed in
-the /etc/shells file.
-.sh 2 "Miscellaneous Fixes and Enhancements"
-.pp
-A number of small bugs having to do with things like backslash-escaped
-quotes inside of comments have been fixed.
-.pp
-The fixed size limit on header lines
-(such as
-.q To:
-and
-.q Cc: )
-has been eliminated;
-those buffers are dynamically allocated now.
-.pp
-Sendmail writes a /etc/sendmail.pid file with the current process id
-and the current invocation flags.
-.pp
-Two people using the same program (e.g., submit) are considered
-"different" so that duplicate elimination doesn't delete one of
-them.  For example, two people forwarding their email to
-|submit will be treated as two recipients.
-.pp
-The mailstats program prints mailer names and gets the location of
-the sendmail.st file from /etc/sendmail.cf.
-.pp
-Many minor bugs have been fixed, such as handling of backslashes
-inside of quotes.
-.pp
-A hook has been added to allow rewriting of local addresses after
-aliasing.
-.sh 1 "FUTURE WORK"
-.pp
-The previous section describes
-.i sendmail
-as of version 8.6.6.
-There is still much to be done.
-Some high points are described below.
-This list is by no means exhaustive.
-.sh 2 "Full MIME Support"
-.pp
-Currently
-.i sendmail
-only supports seven bit MIME messages.
-Although it can pass eight bit MIME messages,
-it cannot advertise that fact because the standards say
-that the mail agent must be able to do 8- to 7-bit conversion
-to have full 8-bit support.
-This requires far more extensive modification of the message body
-than is currently supported.
-.pp
-The best way to do this would be to support the general concept
-of an external
-``message filter''
-that could do arbitrary modifications of the message.
-This would allow MIME conversion as well as such things as
-automatic encryption of messages sent over external links.
-This is probably an extremely non-trivial change.
-.sh 2 "Service Switch Abstraction"
-.pp
-Most modern systems include some concept of a
-.q "service switch"
-\*- for example, to look up host names you can try
-DNS, NIS, NIS+, text tables, NetInfo,
-or other services in some arbitrary order.
-This is currently very clumsy in
-.i sendmail ,
-with only limited control of the services provided.
-.sh 2 "More Control of Local Addresses"
-.pp
-Currently some addresses are declared as
-.q local
-and are handled specially \*-
-for example, they may have .forward files,
-may be translated into program calls or file deliveries,
-and so forth.
-These should be broken out into separate flags
-to allow the local system administrator
-to have more fine-grained control over operations.
-.sh 2 "More Run-Time Configuration Options"
-.pp
-There are many options that are configured at compile time,
-such as the method of file locking
-and the use of the IDENT protocol
-[RFC1413].
-These should be transfered to run time
-by adding new options.
-.pp
-Similarly, some options are currently overloaded,
-that is, a single option controls more than one thing.
-These should probably be broken out into separate options.
-.pp
-This implies that options will change from single characters
-to words.
-.sh 2 "More Configuration Control Over Errors"
-.pp
-Currently,
-the configuration file can generate an error message during parsing.
-However,
-it cannot tweak other operations,
-such as issuing a warning message to the system postmaster.
-Similarly,
-some errors should not be triggered if they are in aliases
-during an alias file rebuild,
-but should be triggered if that alias is actually used.
-.sh 2 "Long Term Host State"
-.pp
-Currently,
-.i sendmail
-only remembers host status during a single queue run.
-This should be converted to long term status
-stored on disk
-so it can be shared between instantiations of
-.i sendmail .
-Entries will have to be timestamped
-so they can time out.
-This will allow
-.i sendmail
-to implement exponential backoff on queue runs
-on a per-host basis.
-.sh 2 "Connection Control"
-.pp
-Modern networks have different types of connectivity
-than the past.
-In particular, the rising prominence of dialup IP
-has created certain challenges for automated servers.
-It is not uncommon to try to make a connection to a host
-and have it fail, even though if you tried again it would succeed.
-The connection management could be a bit cleverer
-to try to adapt to such situations.
-.sh 2 "Other Caching"
-.pp
-When you do an MX record lookup,
-the name server automatically returns the IP addresses
-of the associated MX servers.
-This information is currently ignored,
-and another query is done to get this information.
-It should be cached to avoid excess name server traffic.
-.sh 1 "REFERENCES"
-.ip [Allman83a]
-.q "Sendmail \*- An Internetwork Mail Router."
-E. Allman.
-In
-.ul
-Unix Programmers's Manual,
-4.2 Berkeley Software Distribution,
-volume 2C.
-August 1983.
-.ip [Allman83b]
-.q "Mail Systems and Addressing in 4.2BSD."
-E. Allman
-In
-.ul
-UNICOM Conference Proceedings.
-San Diego, California.
-January 1983.
-.ip [Allman&Amos85]
-``Sendmail Revisited.''
-E. Allman and M. Amos.
-In
-.ul
-Usenix Summer 1985 Conference Proceedings.
-Portland, Oregon.
-June 1985.
-.ip [IDA87]
-.ul 3
-Electronic Mail Addressing in Theory and Practice
-with the IDA Sendmail Enhancement Kit
-(or The Postmaster's Last Will and Testament).
-Lennart Lo\*:vstrand.
-Department of Computer and Information Science,
-University of Linko\*:ping,
-Sweden,
-Report no. LiTH-IDA-Ex-8715.
-May 1987.
-.ip [RFC821]
-.ul
-Simple Mail Transport Protocol.
-J. Postel.
-August 1982.
-.ip [RFC1123]
-.ul
-Requirements for Internet Hosts \*- Application and Support.
-Internet Engineering Task Force,
-R. Braden, Editor.
-October 1989.
-.ip [RFC1344]
-.ul
-Implications of MIME for Internet Mail Gateways.
-N. Borenstein.
-June 1992.
-.ip [RFC1413]
-.ul
-Identification Protocol.
-M. St. Johns.
-February 1993.
-.ip [RFC1425]
-.ul
-SMTP Service Extensions.
-J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker.
-February 1993.
-.ip [RFC1426]
-.ul
-SMTP Service Extension for 8bit-MIMEtransport.
-J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker.
-February 1993.
-.ip [RFC1427]
-.ul
-SMTP Service Extension for Message Size Declaration.
-J. Klensin, N. Freed, and K. Moore.
-February 1993.
-.ip [RFC1521]
-.ul 3
-MIME (Multipurpose Internet Mail Extensions) Part One:
-Mechanisms for Specifying and Describing
-the Format of Internet Message Bodies.
-N. Borenstein and N. Freed.
-September 1993.
diff --git a/contrib/sendmail/doc/intro/Makefile b/contrib/sendmail/doc/intro/Makefile
deleted file mode 100644
index 6369a4a..0000000
--- a/contrib/sendmail/doc/intro/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-#	@(#)Makefile	8.2 (Berkeley) 2/28/1994
-
-DIR=	smm/09.sendmail
-SRCS=	intro.me
-MACROS=	-me
-
-all: intro.ps
-
-intro.ps: ${SRCS}
-	rm -f ${.TARGET}
-	${PIC} ${SRCS} | ${ROFF} > ${.TARGET}
-
-.include <bsd.doc.mk>
diff --git a/contrib/sendmail/doc/intro/intro.me b/contrib/sendmail/doc/intro/intro.me
deleted file mode 100644
index 03cfa33..0000000
--- a/contrib/sendmail/doc/intro/intro.me
+++ /dev/null
@@ -1,1456 +0,0 @@
-.\" Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
-.\" Copyright (c) 1983 Eric P. Allman.  All rights reserved.
-.\" Copyright (c) 1988, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" By using this file, you agree to the terms and conditions set
-.\" forth in the LICENSE file which can be found at the top level of
-.\" the sendmail distribution.
-.\"
-.\"
-.\"	@(#)intro.me	8.7 (Berkeley) 5/19/1998
-.\"
-.\"	pic -Pxx intro.me | ditroff -me -Pxx
-.eh 'SMM:9-%''SENDMAIL \*- An Internetwork Mail Router'
-.oh 'SENDMAIL \*- An Internetwork Mail Router''SMM:9-%'
-.nr si 3n
-.if n .ls 2
-.+c
-.(l C
-.sz 14
-SENDMAIL \*- An Internetwork Mail Router
-.sz
-.sp
-Eric Allman*
-.sp 0.5
-.i
-University of California, Berkeley
-Mammoth Project
-.)l
-.sp
-.(l F
-.ce
-ABSTRACT
-.sp \n(psu
-Routing mail through a heterogenous internet presents many new
-problems.  Among the worst of these is that of address mapping.
-Historically, this has been handled on an
-.i "ad hoc"
-basis.  However,
-this approach has become unmanageable as internets grow.
-.sp \n(psu
-Sendmail acts a unified "post office" to which all mail can be
-submitted.  Address interpretation is controlled by a production
-system, which can parse both domain-based addressing and old-style
-.i "ad hoc"
-addresses.
-The production system is powerful
-enough to rewrite addresses in the message header to conform to the
-standards of a number of common target networks, including old
-(NCP/RFC733) Arpanet, new (TCP/RFC822) Arpanet, UUCP, and Phonenet.
-Sendmail also implements an SMTP server, message
-queueing, and aliasing.
-.)l
-.sp 2
-.(f
-*A considerable part of this work
-was done while under the employ
-of the INGRES Project
-at the University of California at Berkeley
-and at Britton Lee.
-.)f
-.pp
-.i Sendmail
-implements a general internetwork mail routing facility,
-featuring aliasing and forwarding,
-automatic routing to network gateways,
-and flexible configuration.
-.pp
-In a simple network,
-each node has an address,
-and resources can be identified
-with a host-resource pair;
-in particular,
-the mail system can refer to users
-using a host-username pair.
-Host names and numbers have to be administered by a central authority,
-but usernames can be assigned locally to each host.
-.pp
-In an internet,
-multiple networks with different characterstics
-and managements
-must communicate.
-In particular,
-the syntax and semantics of resource identification change.
-Certain special cases can be handled trivially
-by
-.i "ad hoc"
-techniques,
-such as
-providing network names that appear local to hosts
-on other networks,
-as with the Ethernet at Xerox PARC.
-However,  the general case is extremely complex.
-For example,
-some networks require point-to-point routing,
-which simplifies the database update problem
-since only adjacent hosts must be entered
-into the system tables,
-while others use end-to-end addressing.
-Some networks use a left-associative syntax
-and others use a right-associative syntax,
-causing ambiguity in mixed addresses.
-.pp
-Internet standards seek to eliminate these problems.
-Initially, these proposed expanding the address pairs
-to address triples,
-consisting of
-{network, host, resource}
-triples.
-Network numbers must be universally agreed upon,
-and hosts can be assigned locally
-on each network.
-The user-level presentation was quickly expanded
-to address domains,
-comprised of a local resource identification
-and a hierarchical domain specification
-with a common static root.
-The domain technique
-separates the issue of physical versus logical addressing.
-For example,
-an address of the form
-.q "eric@a.cc.berkeley.arpa"
-describes only the logical
-organization of the address space.
-.pp
-.i Sendmail
-is intended to help bridge the gap
-between the totally
-.i "ad hoc"
-world
-of networks that know nothing of each other
-and the clean, tightly-coupled world
-of unique network numbers.
-It can accept old arbitrary address syntaxes,
-resolving ambiguities using heuristics
-specified by the system administrator,
-as well as domain-based addressing.
-It helps guide the conversion of message formats
-between disparate networks.
-In short,
-.i sendmail
-is designed to assist a graceful transition
-to consistent internetwork addressing schemes.
-.sp
-.pp
-Section 1 discusses the design goals for
-.i sendmail .
-Section 2 gives an overview of the basic functions of the system.
-In section 3,
-details of usage are discussed.
-Section 4 compares
-.i sendmail
-to other internet mail routers,
-and an evaluation of
-.i sendmail
-is given in section 5,
-including future plans.
-.sh 1 "DESIGN GOALS"
-.pp
-Design goals for
-.i sendmail
-include:
-.np
-Compatibility with the existing mail programs,
-including Bell version 6 mail,
-Bell version 7 mail
-[UNIX83],
-Berkeley
-.i Mail
-[Shoens79],
-BerkNet mail
-[Schmidt79],
-and hopefully UUCP mail
-[Nowitz78a, Nowitz78b].
-ARPANET mail
-[Crocker77a, Postel77]
-was also required.
-.np
-Reliability, in the sense of guaranteeing
-that every message is correctly delivered
-or at least brought to the attention of a human
-for correct disposal;
-no message should ever be completely lost.
-This goal was considered essential
-because of the emphasis on mail in our environment.
-It has turned out to be one of the hardest goals to satisfy,
-especially in the face of the many anomalous message formats
-produced by various ARPANET sites.
-For example,
-certain sites generate improperly formated addresses,
-occasionally
-causing error-message loops.
-Some hosts use blanks in names,
-causing problems with
-UNIX mail programs that assume that an address
-is one word.
-The semantics of some fields
-are interpreted slightly differently
-by different sites.
-In summary,
-the obscure features of the ARPANET mail protocol
-really
-.i are
-used and
-are difficult to support,
-but must be supported.
-.np
-Existing software to do actual delivery
-should be used whenever possible.
-This goal derives as much from political and practical considerations
-as technical.
-.np
-Easy expansion to
-fairly complex environments,
-including multiple
-connections to a single network type
-(such as with multiple UUCP or Ether nets
-[Metcalfe76]).
-This goal requires consideration of the contents of an address
-as well as its syntax
-in order to determine which gateway to use.
-For example,
-the ARPANET is bringing up the
-TCP protocol to replace the old NCP protocol.
-No host at Berkeley runs both TCP and NCP,
-so it is necessary to look at the ARPANET host name
-to determine whether to route mail to an NCP gateway
-or a TCP gateway.
-.np
-Configuration should not be compiled into the code.
-A single compiled program should be able to run as is at any site
-(barring such basic changes as the CPU type or the operating system).
-We have found this seemingly unimportant goal
-to be critical in real life.
-Besides the simple problems that occur when any program gets recompiled
-in a different environment,
-many sites like to
-.q fiddle
-with anything that they will be recompiling anyway.
-.np
-.i Sendmail
-must be able to let various groups maintain their own mailing lists,
-and let individuals specify their own forwarding,
-without modifying the system alias file.
-.np
-Each user should be able to specify which mailer to execute
-to process mail being delivered for him.
-This feature allows users who are using specialized mailers
-that use a different format to build their environment
-without changing the system,
-and facilitates specialized functions
-(such as returning an
-.q "I am on vacation"
-message).
-.np
-Network traffic should be minimized
-by batching addresses to a single host where possible,
-without assistance from the user.
-.pp
-These goals motivated the architecture illustrated in figure 1.
-.(z
-.hl
-.ie t \
-\{\
-.ie !"\*(.T"" \
-\{\
-.PS
-boxht = 0.5i
-boxwid = 1.0i
-
-	down
-S:	[
-		right
-	S1:	box "sender1"
-		move
-		box "sender2"
-		move
-	S3:	box "sender3"
-	]
-	arrow
-SM:	box "sendmail" wid 2i ht boxht
-	arrow
-M:	[
-		right
-	M1:	box "mailer1"
-		move
-		box "mailer2"
-		move
-	M3:	box "mailer3"
-	]
-
-	arrow from S.S1.s to 1/2 between SM.nw and SM.n
-	arrow from S.S3.s to 1/2 between SM.n and SM.ne
-
-	arrow from 1/2 between SM.sw and SM.s to M.M1.n
-	arrow from 1/2 between SM.s and SM.se to M.M3.n
-.PE
-.\}
-.el \
-.	sp 18
-.\}
-.el \{\
-.(c
-+---------+   +---------+   +---------+
-| sender1 |   | sender2 |   | sender3 |
-+---------+   +---------+   +---------+
-     |  	   |             |
-     +----------+  +  +----------+
-		|  |  |
-		v  v  v
-            +-------------+
-            |   sendmail  |
-            +-------------+
-		|  |  |
-     +----------+  +  +----------+
-     |  	   |             |
-     v             v             v
-+---------+   +---------+   +---------+
-| mailer1 |   | mailer2 |   | mailer3 |
-+---------+   +---------+   +---------+
-.)c
-.\}
-
-.ce
-Figure 1 \*- Sendmail System Structure.
-.hl
-.)z
-The user interacts with a mail generating and sending program.
-When the mail is created,
-the generator calls
-.i sendmail ,
-which routes the message to the correct mailer(s).
-Since some of the senders may be network servers
-and some of the mailers may be network clients,
-.i sendmail
-may be used as an internet mail gateway.
-.sh 1 "OVERVIEW"
-.sh 2 "System Organization"
-.pp
-.i Sendmail
-neither interfaces with the user
-nor does actual mail delivery.
-Rather,
-it collects a message
-generated by a user interface program (UIP)
-such as Berkeley
-.i Mail ,
-MS
-[Crocker77b],
-or MH
-[Borden79],
-edits the message as required by the destination network,
-and calls appropriate mailers
-to do mail delivery or queueing for network transmission\**.
-.(f
-\**except when mailing to a file,
-when
-.i sendmail
-does the delivery directly.
-.)f
-This discipline allows the insertion of new mailers
-at minimum cost.
-In this sense 
-.i sendmail
-resembles the Message Processing Module (MPM)
-of [Postel79b].
-.sh 2 "Interfaces to the Outside World"
-.pp
-There are three ways
-.i sendmail
-can communicate with the outside world,
-both in receiving and in sending mail.
-These are using the conventional UNIX
-argument vector/return status,
-speaking SMTP over a pair of UNIX pipes,
-and speaking SMTP over an interprocess(or) channel.
-.sh 3 "Argument vector/exit status"
-.pp
-This technique is the standard UNIX method
-for communicating with the process.
-A list of recipients is sent in the argument vector,
-and the message body is sent on the standard input.
-Anything that the mailer prints
-is simply collected and sent back to the sender
-if there were any problems.
-The exit status from the mailer is collected
-after the message is sent,
-and a diagnostic is printed if appropriate.
-.sh 3 "SMTP over pipes"
-.pp
-The SMTP protocol
-[Postel82]
-can be used to run an interactive lock-step interface
-with the mailer.
-A subprocess is still created,
-but no recipient addresses are passed to the mailer
-via the argument list.
-Instead, they are passed one at a time
-in commands sent to the processes standard input.
-Anything appearing on the standard output
-must be a reply code
-in a special format.
-.sh 3 "SMTP over an IPC connection"
-.pp
-This technique is similar to the previous technique,
-except that it uses a 4.2bsd IPC channel
-[UNIX83].
-This method is exceptionally flexible
-in that the mailer need not reside
-on the same machine.
-It is normally used to connect to a sendmail process
-on another machine.
-.sh 2 "Operational Description"
-.pp
-When a sender wants to send a message,
-it issues a request to
-.i sendmail
-using one of the three methods described above.
-.i Sendmail
-operates in two distinct phases.
-In the first phase,
-it collects and stores the message.
-In the second phase,
-message delivery occurs.
-If there were errors during processing
-during the second phase,
-.i sendmail
-creates and returns a new message describing the error
-and/or returns an status code
-telling what went wrong.
-.sh 3 "Argument processing and address parsing"
-.pp
-If
-.i sendmail
-is called using one of the two subprocess techniques,
-the arguments
-are first scanned
-and option specifications are processed.
-Recipient addresses are then collected,
-either from the command line
-or from the SMTP
-RCPT command,
-and a list of recipients is created.
-Aliases are expanded at this step,
-including mailing lists.
-As much validation as possible of the addresses
-is done at this step:
-syntax is checked, and local addresses are verified,
-but detailed checking of host names and addresses
-is deferred until delivery.
-Forwarding is also performed
-as the local addresses are verified.
-.pp
-.i Sendmail
-appends each address
-to the recipient list after parsing.
-When a name is aliased or forwarded,
-the old name is retained in the list,
-and a flag is set that tells the delivery phase
-to ignore this recipient.
-This list is kept free from duplicates,
-preventing alias loops
-and duplicate messages deliverd to the same recipient,
-as might occur if a person is in two groups.
-.sh 3 "Message collection"
-.pp
-.i Sendmail
-then collects the message.
-The message should have a header at the beginning.
-No formatting requirements are imposed on the message
-except that they must be lines of text
-(i.e., binary data is not allowed).
-The header is parsed and stored in memory,
-and the body of the message is saved
-in a temporary file.
-.pp
-To simplify the program interface,
-the message is collected even if no addresses were valid.
-The message will be returned with an error.
-.sh 3 "Message delivery"
-.pp
-For each unique mailer and host in the recipient list,
-.i sendmail
-calls the appropriate mailer.
-Each mailer invocation sends to all users receiving the message on one host.
-Mailers that only accept one recipient at a time
-are handled properly.
-.pp
-The message is sent to the mailer
-using one of the same three interfaces
-used to submit a message to sendmail.
-Each copy of the message is
-prepended by a customized header.
-The mailer status code is caught and checked,
-and a suitable error message given as appropriate.
-The exit code must conform to a system standard
-or a generic message
-(\c
-.q "Service unavailable" )
-is given.
-.sh 3 "Queueing for retransmission"
-.pp
-If the mailer returned an status that
-indicated that it might be able to handle the mail later,
-.i sendmail
-will queue the mail and try again later.
-.sh 3 "Return to sender"
-.pp
-If errors occur during processing,
-.i sendmail
-returns the message to the sender for retransmission.
-The letter can be mailed back
-or written in the file
-.q dead.letter
-in the sender's home directory\**.
-.(f
-\**Obviously, if the site giving the error is not the originating
-site, the only reasonable option is to mail back to the sender.
-Also, there are many more error disposition options,
-but they only effect the error message \*- the
-.q "return to sender"
-function is always handled in one of these two ways.
-.)f
-.sh 2 "Message Header Editing"
-.pp
-Certain editing of the message header
-occurs automatically.
-Header lines can be inserted
-under control of the configuration file.
-Some lines can be merged;
-for example,
-a
-.q From:
-line and a
-.q Full-name:
-line can be merged under certain circumstances.
-.sh 2 "Configuration File"
-.pp
-Almost all configuration information is read at runtime
-from an ASCII file,
-encoding
-macro definitions
-(defining the value of macros used internally),
-header declarations
-(telling sendmail the format of header lines that it will process specially,
-i.e., lines that it will add or reformat),
-mailer definitions
-(giving information such as the location and characteristics
-of each mailer),
-and address rewriting rules
-(a limited production system to rewrite addresses
-which is used to parse and rewrite the addresses).
-.pp
-To improve performance when reading the configuration file,
-a memory image can be provided.
-This provides a
-.q compiled
-form of the configuration file.
-.sh 1 "USAGE AND IMPLEMENTATION"
-.sh 2 "Arguments"
-.pp
-Arguments may be flags and addresses.
-Flags set various processing options.
-Following flag arguments,
-address arguments may be given,
-unless we are running in SMTP mode.
-Addresses follow the syntax in RFC822
-[Crocker82]
-for ARPANET
-address formats.
-In brief, the format is:
-.np
-Anything in parentheses is thrown away
-(as a comment).
-.np
-Anything in angle brackets (\c
-.q "<\|>" )
-is preferred
-over anything else.
-This rule implements the ARPANET standard that addresses of the form
-.(b
-user name <machine-address>
-.)b
-will send to the electronic
-.q machine-address
-rather than the human
-.q "user name."
-.np
-Double quotes
-(\ "\ )
-quote phrases;
-backslashes quote characters.
-Backslashes are more powerful
-in that they will cause otherwise equivalent phrases
-to compare differently \*- for example,
-.i user
-and
-.i
-"user"
-.r
-are equivalent,
-but
-.i \euser
-is different from either of them.
-.pp
-Parentheses, angle brackets, and double quotes
-must be properly balanced and nested.
-The rewriting rules control remaining parsing\**.
-.(f
-\**Disclaimer: Some special processing is done
-after rewriting local names; see below.
-.)f
-.sh 2 "Mail to Files and Programs"
-.pp
-Files and programs are legitimate message recipients.
-Files provide archival storage of messages,
-useful for project administration and history.
-Programs are useful as recipients in a variety of situations,
-for example,
-to maintain a public repository of systems messages
-(such as the Berkeley
-.i msgs
-program,
-or the MARS system
-[Sattley78]).
-.pp
-Any address passing through the initial parsing algorithm
-as a local address
-(i.e, not appearing to be a valid address for another mailer)
-is scanned for two special cases.
-If prefixed by a vertical bar (\c
-.q \^|\^ )
-the rest of the address is processed as a shell command.
-If the user name begins with a slash mark (\c
-.q /\^ )
-the name is used as a file name,
-instead of a login name.
-.pp
-Files that have setuid or setgid bits set
-but no execute bits set
-have those bits honored if
-.i sendmail
-is running as root.
-.sh 2 "Aliasing, Forwarding, Inclusion"
-.pp
-.i Sendmail
-reroutes mail three ways.
-Aliasing applies system wide.
-Forwarding allows each user to reroute incoming mail
-destined for that account.
-Inclusion directs
-.i sendmail
-to read a file for a list of addresses,
-and is normally used
-in conjunction with aliasing.
-.sh 3 "Aliasing"
-.pp
-Aliasing maps names to address lists using a system-wide file.
-This file is indexed to speed access.
-Only names that parse as local
-are allowed as aliases;
-this guarantees a unique key
-(since there are no nicknames for the local host).
-.sh 3 "Forwarding"
-.pp
-After aliasing,
-recipients that are local and valid
-are checked for the existence of a
-.q .forward
-file in their home directory.
-If it exists,
-the message is
-.i not
-sent to that user,
-but rather to the list of users in that file.
-Often
-this list will contain only one address,
-and the feature will be used for network mail forwarding.
-.pp
-Forwarding also permits a user to specify a private incoming mailer.
-For example,
-forwarding to:
-.(b
-"\^|\|/usr/local/newmail myname"
-.)b
-will use a different incoming mailer.
-.sh 3 "Inclusion"
-.pp
-Inclusion is specified in RFC 733 [Crocker77a] syntax:
-.(b
-:Include: pathname
-.)b
-An address of this form reads the file specified by
-.i pathname
-and sends to all users listed in that file.
-.pp
-The intent is
-.i not
-to support direct use of this feature,
-but rather to use this as a subset of aliasing.
-For example,
-an alias of the form:
-.(b
-project: :include:/usr/project/userlist
-.)b
-is a method of letting a project maintain a mailing list
-without interaction with the system administration,
-even if the alias file is protected.
-.pp
-It is not necessary to rebuild the index on the alias database
-when a :include: list is changed.
-.sh 2 "Message Collection"
-.pp
-Once all recipient addresses are parsed and verified,
-the message is collected.
-The message comes in two parts:
-a message header and a message body,
-separated by a blank line.
-.pp
-The header is formatted as a series of lines
-of the form
-.(b
-	field-name: field-value
-.)b
-Field-value can be split across lines by starting the following
-lines with a space or a tab.
-Some header fields have special internal meaning,
-and have appropriate special processing.
-Other headers are simply passed through.
-Some header fields may be added automatically,
-such as time stamps.
-.pp
-The body is a series of text lines.
-It is completely uninterpreted and untouched,
-except that lines beginning with a dot
-have the dot doubled
-when transmitted over an SMTP channel.
-This extra dot is stripped by the receiver.
-.sh 2 "Message Delivery"
-.pp
-The send queue is ordered by receiving host
-before transmission
-to implement message batching.
-Each address is marked as it is sent
-so rescanning the list is safe.
-An argument list is built as the scan proceeds.
-Mail to files is detected during the scan of the send list.
-The interface to the mailer
-is performed using one of the techniques
-described in section 2.2.
-.pp
-After a connection is established,
-.i sendmail
-makes the per-mailer changes to the header
-and sends the result to the mailer.
-If any mail is rejected by the mailer,
-a flag is set to invoke the return-to-sender function
-after all delivery completes.
-.sh 2 "Queued Messages"
-.pp
-If the mailer returns a
-.q "temporary failure"
-exit status,
-the message is queued.
-A control file is used to describe the recipients to be sent to
-and various other parameters.
-This control file is formatted as a series of lines,
-each describing a sender,
-a recipient,
-the time of submission,
-or some other salient parameter of the message.
-The header of the message is stored
-in the control file,
-so that the associated data file in the queue
-is just the temporary file that was originally collected.
-.sh 2 "Configuration"
-.pp
-Configuration is controlled primarily by a configuration file
-read at startup.
-.i Sendmail
-should not need to be recomplied except
-.np
-To change operating systems
-(V6, V7/32V, 4BSD).
-.np
-To remove or insert the DBM
-(UNIX database)
-library.
-.np
-To change ARPANET reply codes.
-.np
-To add headers fields requiring special processing.
-.lp
-Adding mailers or changing parsing
-(i.e., rewriting)
-or routing information
-does not require recompilation.
-.pp
-If the mail is being sent by a local user,
-and the file
-.q .mailcf
-exists in the sender's home directory,
-that file is read as a configuration file
-after the system configuration file.
-The primary use of this feature is to add header lines.
-.pp
-The configuration file encodes macro definitions,
-header definitions,
-mailer definitions,
-rewriting rules,
-and options.
-.sh 3 Macros
-.pp
-Macros can be used in three ways.
-Certain macros transmit
-unstructured textual information
-into the mail system,
-such as the name
-.i sendmail
-will use to identify itself in error messages.
-Other macros transmit information from
-.i sendmail
-to the configuration file
-for use in creating other fields
-(such as argument vectors to mailers);
-e.g., the name of the sender,
-and the host and user
-of the recipient.
-Other macros are unused internally,
-and can be used as shorthand in the configuration file.
-.sh 3 "Header declarations"
-.pp
-Header declarations inform
-.i sendmail
-of the format of known header lines.
-Knowledge of a few header lines
-is built into
-.i sendmail ,
-such as the
-.q From:
-and
-.q Date:
-lines.
-.pp
-Most configured headers
-will be automatically inserted
-in the outgoing message
-if they don't exist in the incoming message.
-Certain headers are suppressed by some mailers.
-.sh 3 "Mailer declarations"
-.pp
-Mailer declarations tell
-.i sendmail
-of the various mailers available to it.
-The definition specifies the internal name of the mailer,
-the pathname of the program to call,
-some flags associated with the mailer,
-and an argument vector to be used on the call;
-this vector is macro-expanded before use.
-.sh 3 "Address rewriting rules"
-.pp
-The heart of address parsing in
-.i sendmail
-is a set of rewriting rules.
-These are an ordered list of pattern-replacement rules,
-(somewhat like a production system,
-except that order is critical),
-which are applied to each address.
-The address is rewritten textually until it is either rewritten
-into a special canonical form
-(i.e.,
-a (mailer, host, user)
-3-tuple,
-such as {arpanet, usc-isif, postel}
-representing the address
-.q "postel@usc-isif" ),
-or it falls off the end.
-When a pattern matches,
-the rule is reapplied until it fails.
-.pp
-The configuration file also supports the editing of addresses
-into different formats.
-For example,
-an address of the form:
-.(b
-ucsfcgl!tef
-.)b
-might be mapped into:
-.(b
-tef@ucsfcgl.UUCP
-.)b
-to conform to the domain syntax.
-Translations can also be done in the other direction.
-.sh 3 "Option setting"
-.pp
-There are several options that can be set
-from the configuration file.
-These include the pathnames of various support files,
-timeouts,
-default modes,
-etc.
-.sh 1 "COMPARISON WITH OTHER MAILERS"
-.sh 2 "Delivermail"
-.pp
-.i Sendmail
-is an outgrowth of
-.i delivermail .
-The primary differences are:
-.np
-Configuration information is not compiled in.
-This change simplifies many of the problems
-of moving to other machines.
-It also allows easy debugging of new mailers.
-.np
-Address parsing is more flexible.
-For example,
-.i delivermail
-only supported one gateway to any network,
-whereas
-.i sendmail
-can be sensitive to host names
-and reroute to different gateways.
-.np
-Forwarding and
-:include:
-features eliminate the requirement that the system alias file
-be writable by any user
-(or that an update program be written,
-or that the system administration make all changes).
-.np
-.i Sendmail
-supports message batching across networks
-when a message is being sent to multiple recipients.
-.np
-A mail queue is provided in
-.i sendmail.
-Mail that cannot be delivered immediately
-but can potentially be delivered later
-is stored in this queue for a later retry.
-The queue also provides a buffer against system crashes;
-after the message has been collected
-it may be reliably redelivered
-even if the system crashes during the initial delivery.
-.np
-.i Sendmail
-uses the networking support provided by 4.2BSD
-to provide a direct interface networks such as the ARPANET
-and/or Ethernet
-using SMTP (the Simple Mail Transfer Protocol)
-over a TCP/IP connection.
-.sh 2 "MMDF"
-.pp
-MMDF
-[Crocker79]
-spans a wider problem set than
-.i sendmail .
-For example,
-the domain of
-MMDF includes a
-.q "phone network"
-mailer, whereas
-.i sendmail
-calls on preexisting mailers in most cases.
-.pp
-MMDF and
-.i sendmail
-both support aliasing,
-customized mailers,
-message batching,
-automatic forwarding to gateways,
-queueing,
-and retransmission.
-MMDF supports two-stage timeout,
-which
-.i sendmail
-does not support.
-.pp
-The configuration for MMDF
-is compiled into the code\**.
-.(f
-\**Dynamic configuration tables are currently being considered
-for MMDF;
-allowing the installer to select either compiled
-or dynamic tables.
-.)f
-.pp
-Since MMDF does not consider backwards compatibility
-as a design goal,
-the address parsing is simpler but much less flexible.
-.pp
-It is somewhat harder to integrate a new channel\**
-.(f
-\**The MMDF equivalent of a
-.i sendmail
-.q mailer.
-.)f
-into MMDF.
-In particular,
-MMDF must know the location and format
-of host tables for all channels,
-and the channel must speak a special protocol.
-This allows MMDF to do additional verification
-(such as verifying host names)
-at submission time.
-.pp
-MMDF strictly separates the submission and delivery phases.
-Although
-.i sendmail
-has the concept of each of these stages,
-they are integrated into one program,
-whereas in MMDF they are split into two programs.
-.sh 2 "Message Processing Module"
-.pp
-The Message Processing Module (MPM)
-discussed by Postel [Postel79b]
-matches
-.i sendmail
-closely in terms of its basic architecture.
-However,
-like MMDF,
-the MPM includes the network interface software
-as part of its domain.
-.pp
-MPM also postulates a duplex channel to the receiver,
-as does MMDF,
-thus allowing simpler handling of errors
-by the mailer
-than is possible in
-.i sendmail .
-When a message queued by
-.i sendmail
-is sent,
-any errors must be returned to the sender
-by the mailer itself.
-Both MPM and MMDF mailers
-can return an immediate error response,
-and a single error processor can create an appropriate response.
-.pp
-MPM prefers passing the message as a structured object,
-with type-length-value tuples\**.
-.(f
-\**This is similar to the NBS standard.
-.)f
-Such a convention requires a much higher degree of cooperation
-between mailers than is required by
-.i sendmail .
-MPM also assumes a universally agreed upon internet name space
-(with each address in the form of a net-host-user tuple),
-which
-.i sendmail
-does not.
-.sh 1 "EVALUATIONS AND FUTURE PLANS"
-.pp
-.i Sendmail
-is designed to work in a nonhomogeneous environment.
-Every attempt is made to avoid imposing unnecessary constraints
-on the underlying mailers.
-This goal has driven much of the design.
-One of the major problems
-has been the lack of a uniform address space,
-as postulated in [Postel79a]
-and [Postel79b].
-.pp
-A nonuniform address space implies that a path will be specified
-in all addresses,
-either explicitly (as part of the address)
-or implicitly
-(as with implied forwarding to gateways).
-This restriction has the unpleasant effect of making replying to messages
-exceedingly difficult,
-since there is no one
-.q address
-for any person,
-but only a way to get there from wherever you are.
-.pp
-Interfacing to mail programs
-that were not initially intended to be applied
-in an internet environment
-has been amazingly successful,
-and has reduced the job to a manageable task.
-.pp
-.i Sendmail
-has knowledge of a few difficult environments
-built in.
-It generates ARPANET FTP/SMTP compatible error messages
-(prepended with three-digit numbers
-[Neigus73, Postel74, Postel82])
-as necessary,
-optionally generates UNIX-style
-.q From
-lines on the front of messages for some mailers,
-and knows how to parse the same lines on input.
-Also,
-error handling has an option customized for BerkNet.
-.pp
-The decision to avoid doing any type of delivery where possible
-(even, or perhaps especially, local delivery)
-has turned out to be a good idea.
-Even with local delivery,
-there are issues of the location of the mailbox,
-the format of the mailbox,
-the locking protocol used,
-etc.,
-that are best decided by other programs.
-One surprisingly major annoyance in many internet mailers
-is that the location and format of local mail is built in.
-The feeling seems to be that local mail is so common
-that it should be efficient.
-This feeling is not born out by
-our experience;
-on the contrary,
-the location and format of mailboxes seems to vary widely
-from system to system.
-.pp
-The ability to automatically generate a response to incoming mail
-(by forwarding mail to a program)
-seems useful
-(\c
-.q "I am on vacation until late August...." )
-but can create problems
-such as forwarding loops
-(two people on vacation whose programs send notes back and forth,
-for instance)
-if these programs are not well written.
-A program could be written to do standard tasks correctly,
-but this would solve the general case.
-.pp
-It might be desirable to implement some form of load limiting.
-I am unaware of any mail system that addresses this problem,
-nor am I aware of any reasonable solution at this time.
-.pp
-The configuration file is currently practically inscrutable;
-considerable convenience could be realized
-with a higher-level format.
-.pp
-It seems clear that common protocols will be changing soon
-to accommodate changing requirements and environments.
-These changes will include modifications to the message header
-(e.g., [NBS80])
-or to the body of the message itself
-(such as for multimedia messages
-[Postel80]).
-Experience indicates that
-these changes should be relatively trivial to integrate
-into the existing system.
-.pp
-In tightly coupled environments,
-it would be nice to have a name server
-such as Grapvine
-[Birrell82]
-integrated into the mail system.
-This would allow a site such as
-.q Berkeley
-to appear as a single host,
-rather than as a collection of hosts,
-and would allow people to move transparently among machines
-without having to change their addresses.
-Such a facility
-would require an automatically updated database
-and some method of resolving conflicts.
-Ideally this would be effective even without
-all hosts being under
-a single management.
-However,
-it is not clear whether this feature
-should be integrated into the
-aliasing facility
-or should be considered a
-.q "value added"
-feature outside
-.i sendmail
-itself.
-.pp
-As a more interesting case,
-the CSNET name server
-[Solomon81]
-provides an facility that goes beyond a single
-tightly-coupled environment.
-Such a facility would normally exist outside of
-.i sendmail
-however.
-.sh 0 "ACKNOWLEDGEMENTS"
-.pp
-Thanks are due to Kurt Shoens for his continual cheerful
-assistance and good advice,
-Bill Joy for pointing me in the correct direction
-(over and over),
-and Mark Horton for more advice,
-prodding,
-and many of the good ideas.
-Kurt and Eric Schmidt are to be credited
-for using
-.i delivermail
-as a server for their programs
-(\c
-.i Mail
-and BerkNet respectively)
-before any sane person should have,
-and making the necessary modifications
-promptly and happily.
-Eric gave me considerable advice about the perils
-of network software which saved me an unknown
-amount of work and grief.
-Mark did the original implementation of the DBM version
-of aliasing, installed the VFORK code,
-wrote the current version of
-.i rmail ,
-and was the person who really convinced me
-to put the work into
-.i delivermail
-to turn it into
-.i sendmail .
-Kurt deserves accolades for using
-.i sendmail
-when I was myself afraid to take the risk;
-how a person can continue to be so enthusiastic
-in the face of so much bitter reality is beyond me.
-.pp
-Kurt,
-Mark,
-Kirk McKusick,
-Marvin Solomon,
-and many others have reviewed this paper,
-giving considerable useful advice.
-.pp
-Special thanks are reserved for Mike Stonebraker at Berkeley
-and Bob Epstein at Britton-Lee,
-who both knowingly allowed me to put so much work into this
-project
-when there were so many other things I really should
-have been working on.
-.+c
-.ce
-REFERENCES
-.nr ii 1.5i
-.ip [Birrell82]
-Birrell, A. D.,
-Levin, R.,
-Needham, R. M.,
-and
-Schroeder, M. D.,
-.q "Grapevine: An Exercise in Distributed Computing."
-In
-.ul
-Comm. A.C.M. 25,
-4,
-April 82.
-.ip [Borden79]
-Borden, S.,
-Gaines, R. S.,
-and
-Shapiro, N. Z.,
-.ul
-The MH Message Handling System: Users' Manual.
-R-2367-PAF.
-Rand Corporation.
-October 1979.
-.ip [Crocker77a]
-Crocker, D. H.,
-Vittal, J. J.,
-Pogran, K. T.,
-and
-Henderson, D. A. Jr.,
-.ul
-Standard for the Format of ARPA Network Text Messages.
-RFC 733,
-NIC 41952.
-In [Feinler78].
-November 1977.
-.ip [Crocker77b]
-Crocker, D. H.,
-.ul
-Framework and Functions of the MS Personal Message System.
-R-2134-ARPA,
-Rand Corporation,
-Santa Monica, California.
-1977.
-.ip [Crocker79]
-Crocker, D. H.,
-Szurkowski, E. S.,
-and
-Farber, D. J.,
-.ul
-An Internetwork Memo Distribution Facility \*- MMDF.
-6th Data Communication Symposium,
-Asilomar.
-November 1979.
-.ip [Crocker82]
-Crocker, D. H.,
-.ul
-Standard for the Format of Arpa Internet Text Messages.
-RFC 822.
-Network Information Center,
-SRI International,
-Menlo Park, California.
-August 1982.
-.ip [Metcalfe76]
-Metcalfe, R.,
-and
-Boggs, D.,
-.q "Ethernet: Distributed Packet Switching for Local Computer Networks" ,
-.ul
-Communications of the ACM 19,
-7.
-July 1976.
-.ip [Feinler78]
-Feinler, E.,
-and
-Postel, J.
-(eds.),
-.ul
-ARPANET Protocol Handbook.
-NIC 7104,
-Network Information Center,
-SRI International,
-Menlo Park, California.
-1978.
-.ip [NBS80]
-National Bureau of Standards,
-.ul
-Specification of a Draft Message Format Standard.
-Report No. ICST/CBOS 80-2.
-October 1980.
-.ip [Neigus73]
-Neigus, N.,
-.ul
-File Transfer Protocol for the ARPA Network.
-RFC 542, NIC 17759.
-In [Feinler78].
-August, 1973.
-.ip [Nowitz78a]
-Nowitz, D. A.,
-and
-Lesk, M. E.,
-.ul
-A Dial-Up Network of UNIX Systems.
-Bell Laboratories.
-In
-UNIX Programmer's Manual, Seventh Edition,
-Volume 2.
-August, 1978.
-.ip [Nowitz78b]
-Nowitz, D. A.,
-.ul
-Uucp Implementation Description.
-Bell Laboratories.
-In
-UNIX Programmer's Manual, Seventh Edition,
-Volume 2.
-October, 1978.
-.ip [Postel74]
-Postel, J.,
-and
-Neigus, N.,
-Revised FTP Reply Codes.
-RFC 640, NIC 30843.
-In [Feinler78].
-June, 1974.
-.ip [Postel77]
-Postel, J.,
-.ul
-Mail Protocol.
-NIC 29588.
-In [Feinler78].
-November 1977.
-.ip [Postel79a]
-Postel, J.,
-.ul
-Internet Message Protocol.
-RFC 753,
-IEN 85.
-Network Information Center,
-SRI International,
-Menlo Park, California.
-March 1979.
-.ip [Postel79b]
-Postel, J. B.,
-.ul
-An Internetwork Message Structure.
-In
-.ul
-Proceedings of the Sixth Data Communications Symposium,
-IEEE.
-New York.
-November 1979.
-.ip [Postel80]
-Postel, J. B.,
-.ul
-A Structured Format for Transmission of Multi-Media Documents.
-RFC 767.
-Network Information Center,
-SRI International,
-Menlo Park, California.
-August 1980.
-.ip [Postel82]
-Postel, J. B.,
-.ul
-Simple Mail Transfer Protocol.
-RFC821
-(obsoleting RFC788).
-Network Information Center,
-SRI International,
-Menlo Park, California.
-August 1982.
-.ip [Schmidt79]
-Schmidt, E.,
-.ul
-An Introduction to the Berkeley Network.
-University of California, Berkeley California.
-1979.
-.ip [Shoens79]
-Shoens, K.,
-.ul
-Mail Reference Manual.
-University of California, Berkeley.
-In UNIX Programmer's Manual,
-Seventh Edition,
-Volume 2C.
-December 1979.
-.ip [Sluizer81]
-Sluizer, S.,
-and
-Postel, J. B.,
-.ul
-Mail Transfer Protocol.
-RFC 780.
-Network Information Center,
-SRI International,
-Menlo Park, California.
-May 1981.
-.ip [Solomon81]
-Solomon, M., Landweber, L., and Neuhengen, D.,
-.q "The Design of the CSNET Name Server."
-CS-DN-2,
-University of Wisconsin, Madison.
-November 1981.
-.ip [Su82]
-Su, Zaw-Sing,
-and
-Postel, Jon,
-.ul
-The Domain Naming Convention for Internet User Applications.
-RFC819.
-Network Information Center,
-SRI International,
-Menlo Park, California.
-August 1982.
-.ip [UNIX83]
-.ul
-The UNIX Programmer's Manual, Seventh Edition,
-Virtual VAX-11 Version,
-Volume 1.
-Bell Laboratories,
-modified by the University of California,
-Berkeley, California.
-March, 1983.
diff --git a/contrib/sendmail/doc/usenix/Makefile b/contrib/sendmail/doc/usenix/Makefile
deleted file mode 100644
index d2308cb..0000000
--- a/contrib/sendmail/doc/usenix/Makefile
+++ /dev/null
@@ -1,12 +0,0 @@
-#	@(#)Makefile	8.2 (Berkeley) 2/28/1994
-
-SRCS=	usenix.me
-MACROS=	-me
-
-all: usenix.ps
-
-usenix.ps: ${SRCS}
-	rm -f ${.TARGET}
-	${PIC} ${SRCS} | ${ROFF} > ${.TARGET}
-
-.include <bsd.doc.mk>
diff --git a/contrib/sendmail/doc/usenix/usenix.me b/contrib/sendmail/doc/usenix/usenix.me
deleted file mode 100644
index 4f88a94..0000000
--- a/contrib/sendmail/doc/usenix/usenix.me
+++ /dev/null
@@ -1,1076 +0,0 @@
-.nr si 3n
-.he 'Mail Systems and Addressing in 4.2bsd''%'
-.fo 'Version 8.2'USENIX \- Jan 83'Last Mod 11/27/1993'
-.if n .ls 2
-.+c
-.(l C
-.sz 14
-Mail Systems and Addressing
-in 4.2bsd
-.sz
-.sp
-Eric Allman*
-.sp 0.5
-.i
-Britton-Lee, Inc.
-1919 Addison Street, Suite 105.
-Berkeley, California 94704.
-.sp 0.5
-.r
-eric@Berkeley.ARPA
-ucbvax!eric
-.)l
-.sp
-.(l F
-.ce
-ABSTRACT
-.sp \n(psu
-Routing mail through a heterogeneous internet presents many new
-problems.
-Among the worst of these is that of address mapping.
-Historically, this has been handled on an ad hoc basis.
-However,
-this approach has become unmanageable as internets grow.
-.sp \n(psu
-Sendmail acts a unified
-.q "post office"
-to which all mail can be
-submitted.
-Address interpretation is controlled by a production
-system,
-which can parse both old and new format addresses.
-The
-new format is
-.q "domain-based,"
-a flexible technique that can
-handle many common situations.
-Sendmail is not intended to perform
-user interface functions.
-.sp \n(psu
-Sendmail will replace delivermail in the Berkeley 4.2 distribution.
-Several major hosts are now or will soon be running sendmail.
-This change will affect any users that route mail through a sendmail
-gateway.
-The changes that will be user visible are emphasized.
-.)l
-.sp 2
-.(f
-*A considerable part of this work
-was done while under the employ
-of the INGRES Project
-at the University of California at Berkeley.
-.)f
-.pp
-The mail system to appear in 4.2bsd
-will contain a number of changes.
-Most of these changes are based on the replacement of
-.i delivermail
-with a new module called
-.i sendmail.
-.i Sendmail
-implements a general internetwork mail routing facility,
-featuring aliasing and forwarding,
-automatic routing to network gateways,
-and flexible configuration.
-Of key interest to the mail system user
-will be the changes in the network addressing structure.
-.pp
-In a simple network,
-each node has an address,
-and resources can be identified
-with a host-resource pair;
-in particular,
-the mail system can refer to users
-using a host-username pair.
-Host names and numbers have to be administered by a central authority,
-but usernames can be assigned locally to each host.
-.pp
-In an internet,
-multiple networks with different characteristics
-and managements
-must communicate.
-In particular,
-the syntax and semantics of resource identification change.
-Certain special cases can be handled trivially
-by
-.i "ad hoc"
-techniques,
-such as
-providing network names that appear local to hosts
-on other networks,
-as with the Ethernet at Xerox PARC.
-However, the general case is extremely complex.
-For example,
-some networks require that the route the message takes
-be explicitly specified by the sender,
-simplifying the database update problem
-since only adjacent hosts must be entered
-into the system tables,
-while others use logical addressing,
-where the sender specifies the location of the recipient
-but not how to get there.
-Some networks use a left-associative syntax
-and others use a right-associative syntax,
-causing ambiguity in mixed addresses.
-.pp
-Internet standards seek to eliminate these problems.
-Initially, these proposed expanding the address pairs
-to address triples,
-consisting of
-{network, host, username}
-triples.
-Network numbers must be universally agreed upon,
-and hosts can be assigned locally
-on each network.
-The user-level presentation was changed
-to address domains,
-comprised of a local resource identification
-and a hierarchical domain specification
-with a common static root.
-The domain technique
-separates the issue of physical versus logical addressing.
-For example,
-an address of the form
-.q "eric@a.cc.berkeley.arpa"
-describes the logical
-organization of the address space
-(user
-.q eric
-on host
-.q a
-in the Computer Center
-at Berkeley)
-but not the physical networks used
-(for example, this could go over different networks
-depending on whether
-.q a
-were on an ethernet
-or a store-and-forward network).
-.pp
-.i Sendmail
-is intended to help bridge the gap
-between the totally
-.i "ad hoc"
-world
-of networks that know nothing of each other
-and the clean, tightly-coupled world
-of unique network numbers.
-It can accept old arbitrary address syntaxes,
-resolving ambiguities using heuristics
-specified by the system administrator,
-as well as domain-based addressing.
-It helps guide the conversion of message formats
-between disparate networks.
-In short,
-.i sendmail
-is designed to assist a graceful transition
-to consistent internetwork addressing schemes.
-.sp
-.pp
-Section 1 defines some of the terms
-frequently left fuzzy
-when working in mail systems.
-Section 2 discusses the design goals for
-.i sendmail .
-In section 3,
-the new address formats
-and basic features of
-.i sendmail
-are described.
-Section 4 discusses some of the special problems
-of the UUCP network.
-The differences between
-.i sendmail
-and
-.i delivermail
-are presented in section 5.
-.sp
-.(l F
-.b DISCLAIMER:
-A number of examples
-in this paper
-use names of actual people
-and organizations.
-This is not intended
-to imply a commitment
-or even an intellectual agreement
-on the part of these people or organizations.
-In particular,
-Bell Telephone Laboratories (BTL),
-Digital Equipment Corporation (DEC),
-Lawrence Berkeley Laboratories (LBL),
-Britton-Lee Incorporated (BLI),
-and the University of California at Berkeley
-are not committed to any of these proposals at this time.
-Much of this paper
-represents no more than
-the personal opinions of the author.
-.)l
-.sh 1 "DEFINITIONS"
-.pp
-There are four basic concepts
-that must be clearly distinguished
-when dealing with mail systems:
-the user (or the user's agent),
-the user's identification,
-the user's address,
-and the route.
-These are distinguished primarily by their position independence.
-.sh 2 "User and Identification"
-.pp
-The user is the being
-(a person or program)
-that is creating or receiving a message.
-An
-.i agent
-is an entity operating on behalf of the user \*-
-such as a secretary who handles my mail.
-or a program that automatically returns a
-message such as
-.q "I am at the UNICOM conference."
-.pp
-The identification is the tag
-that goes along with the particular user.
-This tag is completely independent of location.
-For example,
-my identification is the string
-.q "Eric Allman,"
-and this identification does not change
-whether I am located at U.C. Berkeley,
-at Britton-Lee,
-or at a scientific institute in Austria.
-.pp
-Since the identification is frequently ambiguous
-(e.g., there are two
-.q "Robert Henry" s
-at Berkeley)
-it is common to add other disambiguating information
-that is not strictly part of the identification
-(e.g.,
-Robert
-.q "Code Generator"
-Henry
-versus
-Robert
-.q "System Administrator"
-Henry).
-.sh 2 "Address"
-.pp
-The address specifies a location.
-As I move around,
-my address changes.
-For example,
-my address might change from
-.q eric@Berkeley.ARPA
-to
-.q eric@bli.UUCP
-or
-.q allman@IIASA.Austria
-depending on my current affiliation.
-.pp
-However,
-an address is independent of the location of anyone else.
-That is,
-my address remains the same to everyone who might be sending me mail.
-For example,
-a person at MIT and a person at USC
-could both send to
-.q eric@Berkeley.ARPA
-and have it arrive to the same mailbox.
-.pp
-Ideally a
-.q "white pages"
-service would be provided to map user identifications
-into addresses
-(for example, see
-[Solomon81]).
-Currently this is handled by passing around
-scraps of paper
-or by calling people on the telephone
-to find out their address.
-.sh 2 "Route"
-.pp
-While an address specifies
-.i where
-to find a mailbox,
-a route specifies
-.i how
-to find the mailbox.
-Specifically,
-it specifies a path
-from sender to receiver.
-As such, the route is potentially different
-for every pair of people in the electronic universe.
-.pp
-Normally the route is hidden from the user
-by the software.
-However,
-some networks put the burden of determining the route
-onto the sender.
-Although this simplifies the software,
-it also greatly impairs the usability
-for most users.
-The UUCP network is an example of such a network.
-.sh 1 "DESIGN GOALS"
-.pp
-Design goals for
-.i sendmail \**
-.(f
-\**This section makes no distinction between
-.i delivermail
-and
-.i sendmail.
-.)f
-include:
-.np
-Compatibility with the existing mail programs,
-including Bell version 6 mail,
-Bell version 7 mail,
-Berkeley
-.i Mail
-[Shoens79],
-BerkNet mail
-[Schmidt79],
-and hopefully UUCP mail
-[Nowitz78].
-ARPANET mail
-[Crocker82]
-was also required.
-.np
-Reliability, in the sense of guaranteeing
-that every message is correctly delivered
-or at least brought to the attention of a human
-for correct disposal;
-no message should ever be completely lost.
-This goal was considered essential
-because of the emphasis on mail in our environment.
-It has turned out to be one of the hardest goals to satisfy,
-especially in the face of the many anomalous message formats
-produced by various ARPANET sites.
-For example,
-certain sites generate improperly formated addresses,
-occasionally
-causing error-message loops.
-Some hosts use blanks in names,
-causing problems with
-mail programs that assume that an address
-is one word.
-The semantics of some fields
-are interpreted slightly differently
-by different sites.
-In summary,
-the obscure features of the ARPANET mail protocol
-really
-.i are
-used and
-are difficult to support,
-but must be supported.
-.np
-Existing software to do actual delivery
-should be used whenever possible.
-This goal derives as much from political and practical considerations
-as technical.
-.np
-Easy expansion to
-fairly complex environments,
-including multiple
-connections to a single network type
-(such as with multiple UUCP or Ethernets).
-This goal requires consideration of the contents of an address
-as well as its syntax
-in order to determine which gateway to use.
-.np
-Configuration information should not be compiled into the code.
-A single compiled program should be able to run as is at any site
-(barring such basic changes as the CPU type or the operating system).
-We have found this seemingly unimportant goal
-to be critical in real life.
-Besides the simple problems that occur when any program gets recompiled
-in a different environment,
-many sites like to
-.q fiddle
-with anything that they will be recompiling anyway.
-.np
-.i Sendmail
-must be able to let various groups maintain their own mailing lists,
-and let individuals specify their own forwarding,
-without modifying the system alias file.
-.np
-Each user should be able to specify which mailer to execute
-to process mail being delivered for him.
-This feature allows users who are using specialized mailers
-that use a different format to build their environment
-without changing the system,
-and facilitates specialized functions
-(such as returning an
-.q "I am on vacation"
-message).
-.np
-Network traffic should be minimized
-by batching addresses to a single host where possible,
-without assistance from the user.
-.pp
-These goals motivated the architecture illustrated in figure 1.
-.(z
-.hl
-.ie t \
-.	sp 18
-.el \{\
-.(c
-+---------+   +---------+   +---------+
-| sender1 |   | sender2 |   | sender3 |
-+---------+   +---------+   +---------+
-     |  	   |             |
-     +----------+  +  +----------+
-		|  |  |
-		v  v  v
-            +-------------+
-            |   sendmail  |
-            +-------------+
-		|  |  |
-     +----------+  +  +----------+
-     |  	   |             |
-     v             v             v
-+---------+   +---------+   +---------+
-| mailer1 |   | mailer2 |   | mailer3 |
-+---------+   +---------+   +---------+
-.)c
-.\}
-
-.ce
-Figure 1 \*- Sendmail System Structure.
-.hl
-.)z
-The user interacts with a mail generating and sending program.
-When the mail is created,
-the generator calls
-.i sendmail ,
-which routes the message to the correct mailer(s).
-Since some of the senders may be network servers
-and some of the mailers may be network clients,
-.i sendmail
-may be used as an internet mail gateway.
-.sh 1 "USAGE"
-.sh 2 "Address Formats"
-.pp
-Arguments may be flags or addresses.
-Flags set various processing options.
-Following flag arguments,
-address arguments may be given.
-Addresses follow the syntax in RFC822
-[Crocker82]
-for ARPANET
-address formats.
-In brief, the format is:
-.np
-Anything in parentheses is thrown away
-(as a comment).
-.np
-Anything in angle brackets (\c
-.q "<\|>" )
-is preferred
-over anything else.
-This rule implements the ARPANET standard that addresses of the form
-.(b
-user name <machine-address>
-.)b
-will send to the electronic
-.q machine-address
-rather than the human
-.q "user name."
-.np
-Double quotes
-(\ "\ )
-quote phrases;
-backslashes quote characters.
-Backslashes are more powerful
-in that they will cause otherwise equivalent phrases
-to compare differently \*- for example,
-.i user
-and
-.i
-"user"
-.r
-are equivalent,
-but
-.i \euser
-is different from either of them.
-This might be used
-to avoid normal aliasing
-or duplicate suppression algorithms.
-.pp
-Parentheses, angle brackets, and double quotes
-must be properly balanced and nested.
-The rewriting rules control remaining parsing\**.
-.(f
-\**Disclaimer: Some special processing is done
-after rewriting local names; see below.
-.)f
-.pp
-Although old style addresses are still accepted
-in most cases,
-the preferred address format
-is based on ARPANET-style domain-based addresses
-[Su82a].
-These addresses are based on a hierarchical, logical decomposition
-of the address space.
-The addresses are hierarchical in a sense
-similar to the U.S. postal addresses:
-the messages may first be routed to the correct state,
-with no initial consideration of the city
-or other addressing details.
-The addresses are logical
-in that each step in the hierarchy
-corresponds to a set of
-.q "naming authorities"
-rather than a physical network.
-.pp
-For example,
-the address:
-.(l
-eric@HostA.BigSite.ARPA
-.)l
-would first look up the domain
-BigSite
-in the namespace administrated by
-ARPA.
-A query could then be sent to
-BigSite
-for interpretation of
-HostA.
-Eventually the mail would arrive at
-HostA,
-which would then do final delivery
-to user
-.q eric.
-.sh 2 "Mail to Files and Programs"
-.pp
-Files and programs are legitimate message recipients.
-Files provide archival storage of messages,
-useful for project administration and history.
-Programs are useful as recipients in a variety of situations,
-for example,
-to maintain a public repository of systems messages
-(such as the Berkeley
-.i msgs
-program).
-.pp
-Any address passing through the initial parsing algorithm
-as a local address
-(i.e, not appearing to be a valid address for another mailer)
-is scanned for two special cases.
-If prefixed by a vertical bar (\c
-.q \^|\^ )
-the rest of the address is processed as a shell command.
-If the user name begins with a slash mark (\c
-.q /\^ )
-the name is used as a file name,
-instead of a login name.
-.sh 2 "Aliasing, Forwarding, Inclusion"
-.pp
-.i Sendmail
-reroutes mail three ways.
-Aliasing applies system wide.
-Forwarding allows each user to reroute incoming mail
-destined for that account.
-Inclusion directs
-.i sendmail
-to read a file for a list of addresses,
-and is normally used
-in conjunction with aliasing.
-.sh 3 "Aliasing"
-.pp
-Aliasing maps local addresses to address lists using a system-wide file.
-This file is hashed to speed access.
-Only addresses that parse as local
-are allowed as aliases;
-this guarantees a unique key
-(since there are no nicknames for the local host).
-.sh 3 "Forwarding"
-.pp
-After aliasing,
-if an recipient address specifies a local user
-.i sendmail
-searches for a
-.q .forward
-file in the recipient's home directory.
-If it exists,
-the message is
-.i not
-sent to that user,
-but rather to the list of addresses in that file.
-Often
-this list will contain only one address,
-and the feature will be used for network mail forwarding.
-.pp
-Forwarding also permits a user to specify a private incoming mailer.
-For example,
-forwarding to:
-.(b
-"\^|\|/usr/local/newmail myname"
-.)b
-will use a different incoming mailer.
-.sh 3 "Inclusion"
-.pp
-Inclusion is specified in RFC 733 [Crocker77] syntax:
-.(b
-:Include: pathname
-.)b
-An address of this form reads the file specified by
-.i pathname
-and sends to all users listed in that file.
-.pp
-The intent is
-.i not
-to support direct use of this feature,
-but rather to use this as a subset of aliasing.
-For example,
-an alias of the form:
-.(b
-project: :include:/usr/project/userlist
-.)b
-is a method of letting a project maintain a mailing list
-without interaction with the system administration,
-even if the alias file is protected.
-.pp
-It is not necessary to rebuild the index on the alias database
-when a :include: list is changed.
-.sh 2 "Message Collection"
-.pp
-Once all recipient addresses are parsed and verified,
-the message is collected.
-The message comes in two parts:
-a message header and a message body,
-separated by a blank line.
-The body is an uninterpreted
-sequence of text lines.
-.pp
-The header is formated as a series of lines
-of the form
-.(b
-	field-name: field-value
-.)b
-Field-value can be split across lines by starting the following
-lines with a space or a tab.
-Some header fields have special internal meaning,
-and have appropriate special processing.
-Other headers are simply passed through.
-Some header fields may be added automatically,
-such as time stamps.
-.sh 1 "THE UUCP PROBLEM"
-.pp
-Of particular interest
-is the UUCP network.
-The explicit routing
-used in the UUCP environment
-causes a number of serious problems.
-First,
-giving out an address
-is impossible
-without knowing the address of your potential correspondent.
-This is typically handled
-by specifying the address
-relative to some
-.q "well-known"
-host
-(e.g.,
-ucbvax or decvax).
-Second,
-it is often difficult to compute
-the set of addresses
-to reply to
-without some knowledge
-of the topology of the network.
-Although it may be easy for a human being
-to do this
-under many circumstances,
-a program does not have equally sophisticated heuristics
-built in.
-Third,
-certain addresses will become painfully and unnecessarily long,
-as when a message is routed through many hosts in the USENET.
-And finally,
-certain
-.q "mixed domain"
-addresses
-are impossible to parse unambiguously \*-
-e.g.,
-.(l
-decvax!ucbvax!lbl-h!user@LBL-CSAM
-.)l
-might have many possible resolutions,
-depending on whether the message was first routed
-to decvax
-or to LBL-CSAM.
-.pp
-To solve this problem,
-the UUCP syntax
-would have to be changed to use addresses
-rather than routes.
-For example,
-the address
-.q decvax!ucbvax!eric
-might be expressed as
-.q eric@ucbvax.UUCP
-(with the hop through decvax implied).
-This address would itself be a domain-based address;
-for example,
-an address might be of the form:
-.(l
-mark@d.cbosg.btl.UUCP
-.)l
-Hosts outside of Bell Telephone Laboratories
-would then only need to know
-how to get to a designated BTL relay,
-and the BTL topology
-would only be maintained inside Bell.
-.pp
-There are three major problems
-associated with turning UUCP addresses
-into something reasonable:
-defining the namespace,
-creating and propagating the necessary software,
-and building and maintaining the database.
-.sh 2 "Defining the Namespace"
-.pp
-Putting all UUCP hosts into a flat namespace
-(e.g.,
-.q \&...@host.UUCP )
-is not practical for a number of reasons.
-First,
-with over 1600 sites already,
-and (with the increasing availability of inexpensive microcomputers
-and autodialers)
-several thousand more coming within a few years,
-the database update problem
-is simply intractable
-if the namespace is flat.
-Second,
-there are almost certainly name conflicts today.
-Third,
-as the number of sites grow
-the names become ever less mnemonic.
-.pp
-It seems inevitable
-that there be some sort of naming authority
-for the set of top level names
-in the UUCP domain,
-as unpleasant a possibility
-as that may seem.
-It will simply not be possible
-to have one host resolving all names.
-It may however be possible
-to handle this
-in a fashion similar to that of assigning names of newsgroups
-in USENET.
-However,
-it will be essential to encourage everyone
-to become subdomains of an existing domain
-whenever possible \*-
-even though this will certainly bruise some egos.
-For example,
-if a new host named
-.q blid
-were to be added to the UUCP network,
-it would probably actually be addressed as
-.q d.bli.UUCP
-(i.e.,
-as host
-.q d
-in the pseudo-domain
-.q bli
-rather than as host
-.q blid
-in the UUCP domain).
-.sh 2 "Creating and Propagating the Software"
-.pp
-The software required to implement a consistent namespace
-is relatively trivial.
-Two modules are needed,
-one to handle incoming mail
-and one to handle outgoing mail.
-.pp
-The incoming module
-must be prepared to handle either old or new style addresses.
-New-style addresses
-can be passed through unchanged.
-Old style addresses
-must be turned into new style addresses
-where possible.
-.pp
-The outgoing module
-is slightly trickier.
-It must do a database lookup on the recipient addresses
-(passed on the command line)
-to determine what hosts to send the message to.
-If those hosts do not accept new-style addresses,
-it must transform all addresses in the header of the message
-into old style using the database lookup.
-.pp
-Both of these modules
-are straightforward
-except for the issue of modifying the header.
-It seems prudent to choose one format
-for the message headers.
-For a number of reasons,
-Berkeley has elected to use the ARPANET protocols
-for message formats.
-However,
-this protocol is somewhat difficult to parse.
-.pp
-Propagation is somewhat more difficult.
-There are a large number of hosts
-connected to UUCP
-that will want to run completely standard systems
-(for very good reasons).
-The strategy is not to convert the entire network \*-
-only enough of it it alleviate the problem.
-.sh 2 "Building and Maintaining the Database"
-.pp
-This is by far the most difficult problem.
-A prototype for this database
-already exists,
-but it is maintained by hand
-and does not pretend to be complete.
-.pp
-This problem will be reduced considerably
-if people choose to group their hosts
-into subdomains.
-This would require a global update
-only when a new top level domain
-joined the network.
-A message to a host in a subdomain
-could simply be routed to a known domain gateway
-for further processing.
-For example,
-the address
-.q eric@a.bli.UUCP
-might be routed to the
-.q bli
-gateway
-for redistribution;
-new hosts could be added
-within BLI
-without notifying the rest of the world.
-Of course,
-other hosts
-.i could
-be notified as an efficiency measure.
-.pp
-There may be more than one domain gateway.
-A domain such as BTL,
-for instance,
-might have a dozen gateways to the outside world;
-a non-BTL site
-could choose the closest gateway.
-The only restriction
-would be that all gateways
-maintain a consistent view of the domain
-they represent.
-.sh 2 "Logical Structure"
-.pp
-Logically,
-domains are organized into a tree.
-There need not be a host actually associated
-with each level in the tree \*-
-for example,
-there will be no host associated with the name
-.q UUCP.
-Similarly,
-an organization might group names together for administrative reasons;
-for example,
-the name
-.(l
-CAD.research.BigCorp.UUCP
-.)l
-might not actually have a host representing
-.q research.
-.pp
-However,
-it may frequently be convenient to have a host
-or hosts
-that
-.q represent
-a domain.
-For example,
-if a single host exists that
-represents
-Berkeley,
-then mail from outside Berkeley
-can forward mail to that host
-for further resolution
-without knowing Berkeley's
-(rather volatile)
-topology.
-This is not unlike the operation
-of the telephone network.
-.pp
-This may also be useful
-inside certain large domains.
-For example,
-at Berkeley it may be presumed
-that most hosts know about other hosts
-inside the Berkeley domain.
-But if they process an address
-that is unknown,
-they can pass it
-.q upstairs
-for further examination.
-Thus as new hosts are added
-only one host
-(the domain master)
-.i must
-be updated immediately;
-other hosts can be updated as convenient.
-.pp
-Ideally this name resolution process
-would be performed by a name server
-(e.g., [Su82b])
-to avoid unnecessary copying
-of the message.
-However,
-in a batch network
-such as UUCP
-this could result in unnecessary delays.
-.sh 1 "COMPARISON WITH DELIVERMAIL"
-.pp
-.i Sendmail
-is an outgrowth of
-.i delivermail .
-The primary differences are:
-.np
-Configuration information is not compiled in.
-This change simplifies many of the problems
-of moving to other machines.
-It also allows easy debugging of new mailers.
-.np
-Address parsing is more flexible.
-For example,
-.i delivermail
-only supported one gateway to any network,
-whereas
-.i sendmail
-can be sensitive to host names
-and reroute to different gateways.
-.np
-Forwarding and
-:include:
-features eliminate the requirement that the system alias file
-be writable by any user
-(or that an update program be written,
-or that the system administration make all changes).
-.np
-.i Sendmail
-supports message batching across networks
-when a message is being sent to multiple recipients.
-.np
-A mail queue is provided in
-.i sendmail.
-Mail that cannot be delivered immediately
-but can potentially be delivered later
-is stored in this queue for a later retry.
-The queue also provides a buffer against system crashes;
-after the message has been collected
-it may be reliably redelivered
-even if the system crashes during the initial delivery.
-.np
-.i Sendmail
-uses the networking support provided by 4.2BSD
-to provide a direct interface networks such as the ARPANET
-and/or Ethernet
-using SMTP (the Simple Mail Transfer Protocol)
-over a TCP/IP connection.
-.+c
-.ce
-REFERENCES
-.nr ii 1.5i
-.ip [Crocker77]
-Crocker, D. H.,
-Vittal, J. J.,
-Pogran, K. T.,
-and
-Henderson, D. A. Jr.,
-.ul
-Standard for the Format of ARPA Network Text Messages.
-RFC 733,
-NIC 41952.
-In [Feinler78].
-November 1977.
-.ip [Crocker82]
-Crocker, D. H.,
-.ul
-Standard for the Format of Arpa Internet Text Messages.
-RFC 822.
-Network Information Center,
-SRI International,
-Menlo Park, California.
-August 1982.
-.ip [Feinler78]
-Feinler, E.,
-and
-Postel, J.
-(eds.),
-.ul
-ARPANET Protocol Handbook.
-NIC 7104,
-Network Information Center,
-SRI International,
-Menlo Park, California.
-1978.
-.ip [Nowitz78]
-Nowitz, D. A.,
-and
-Lesk, M. E.,
-.ul
-A Dial-Up Network of UNIX Systems.
-Bell Laboratories.
-In
-UNIX Programmer's Manual, Seventh Edition,
-Volume 2.
-August, 1978.
-.ip [Schmidt79]
-Schmidt, E.,
-.ul
-An Introduction to the Berkeley Network.
-University of California, Berkeley California.
-1979.
-.ip [Shoens79]
-Shoens, K.,
-.ul
-Mail Reference Manual.
-University of California, Berkeley.
-In UNIX Programmer's Manual,
-Seventh Edition,
-Volume 2C.
-December 1979.
-.ip [Solomon81]
-Solomon, M.,
-Landweber, L.,
-and
-Neuhengen, D.,
-.ul
-The Design of the CSNET Name Server.
-CS-DN-2.
-University of Wisconsin,
-Madison.
-October 1981.
-.ip [Su82a]
-Su, Zaw-Sing,
-and
-Postel, Jon,
-.ul
-The Domain Naming Convention for Internet User Applications.
-RFC819.
-Network Information Center,
-SRI International,
-Menlo Park, California.
-August 1982.
-.ip [Su82b]
-Su, Zaw-Sing,
-.ul
-A Distributed System for Internet Name Service.
-RFC830.
-Network Information Center,
-SRI International,
-Menlo Park, California.
-October 1982.
diff --git a/contrib/sendmail/mail.local/pathnames.h b/contrib/sendmail/mail.local/pathnames.h
deleted file mode 100644
index ebb919c..0000000
--- a/contrib/sendmail/mail.local/pathnames.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/*-
- * Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
- * Copyright (c) 1990, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * By using this file, you agree to the terms and conditions set
- * forth in the LICENSE file which can be found at the top level of
- * the sendmail distribution.
- *
- *
- *	@(#)pathnames.h	8.5 (Berkeley) 5/19/1998
- *	$FreeBSD$
- */
-#include <paths.h>
-
-#define _PATH_LOCTMP	"/var/tmp/local.XXXXXX"
diff --git a/contrib/sendmail/src/cdefs.h b/contrib/sendmail/src/cdefs.h
deleted file mode 100644
index e586cbf..0000000
--- a/contrib/sendmail/src/cdefs.h
+++ /dev/null
@@ -1,123 +0,0 @@
-/*
- * Copyright (c) 1991, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * This code is derived from software contributed to Berkeley by
- * Berkeley Software Design, Inc.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- *	@(#)cdefs.h	8.8 (Berkeley) 1/9/95
- */
-
-#ifndef	_CDEFS_H_
-#define	_CDEFS_H_
-
-#if defined(__cplusplus)
-#define	__BEGIN_DECLS	extern "C" {
-#define	__END_DECLS	};
-#else
-#define	__BEGIN_DECLS
-#define	__END_DECLS
-#endif
-
-/*
- * The __CONCAT macro is used to concatenate parts of symbol names, e.g.
- * with "#define OLD(foo) __CONCAT(old,foo)", OLD(foo) produces oldfoo.
- * The __CONCAT macro is a bit tricky -- make sure you don't put spaces
- * in between its arguments.  __CONCAT can also concatenate double-quoted
- * strings produced by the __STRING macro, but this only works with ANSI C.
- */
-#if defined(__STDC__) || defined(__cplusplus)
-#define	__P(protos)	protos		/* full-blown ANSI C */
-#define	__CONCAT(x,y)	x ## y
-#define	__STRING(x)	#x
-
-#define	__const		const		/* define reserved names to standard */
-#define	__signed	signed
-#define	__volatile	volatile
-#if defined(__cplusplus)
-#define	__inline	inline		/* convert to C++ keyword */
-#else
-#ifndef __GNUC__
-#define	__inline			/* delete GCC keyword */
-#endif /* !__GNUC__ */
-#endif /* !__cplusplus */
-
-#else	/* !(__STDC__ || __cplusplus) */
-#define	__P(protos)	()		/* traditional C preprocessor */
-#define	__CONCAT(x,y)	x/**/y
-#define	__STRING(x)	"x"
-
-#ifndef __GNUC__
-#define	__const				/* delete pseudo-ANSI C keywords */
-#define	__inline
-#define	__signed
-#define	__volatile
-/*
- * In non-ANSI C environments, new programs will want ANSI-only C keywords
- * deleted from the program and old programs will want them left alone.
- * When using a compiler other than gcc, programs using the ANSI C keywords
- * const, inline etc. as normal identifiers should define -DNO_ANSI_KEYWORDS.
- * When using "gcc -traditional", we assume that this is the intent; if
- * __GNUC__ is defined but __STDC__ is not, we leave the new keywords alone.
- */
-#ifndef	NO_ANSI_KEYWORDS
-#define	const				/* delete ANSI C keywords */
-#define	inline
-#define	signed
-#define	volatile
-#endif
-#endif	/* !__GNUC__ */
-#endif	/* !(__STDC__ || __cplusplus) */
-
-/*
- * GCC1 and some versions of GCC2 declare dead (non-returning) and
- * pure (no side effects) functions using "volatile" and "const";
- * unfortunately, these then cause warnings under "-ansi -pedantic".
- * GCC2 uses a new, peculiar __attribute__((attrs)) style.  All of
- * these work for GNU C++ (modulo a slight glitch in the C++ grammar
- * in the distribution version of 2.5.5).
- */
-#if !defined(__GNUC__) || __GNUC__ < 2 || \
-	(__GNUC__ == 2 && __GNUC_MINOR__ < 5)
-#define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
-#define	__dead		__volatile
-#define	__pure		__const
-#endif
-#endif
-
-/* Delete pseudo-keywords wherever they are not available or needed. */
-#ifndef __dead
-#define	__dead
-#define	__pure
-#endif
-
-#endif /* !_CDEFS_H_ */
diff --git a/contrib/sendmail/src/ldap_map.h b/contrib/sendmail/src/ldap_map.h
deleted file mode 100644
index 7d40329..0000000
--- a/contrib/sendmail/src/ldap_map.h
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
- *
- * By using this file, you agree to the terms and conditions set
- * forth in the LICENSE file which can be found at the top level of
- * the sendmail distribution.
- *
- */
-
-/*
-**  Support for LDAP.
-**
-**	Contributed by Booker C. Bense <bbense+ldap@stanford.edu>.
-**	Please go to him for support -- since I (Eric) don't run LDAP, I
-**	can't help you at all.
-**
-**	@(#)ldap_map.h	8.12 (Berkeley) 2/2/1999
-*/
-
-#ifndef _LDAP_MAP_H
-#define _LDAP_MAP_H
-
-#include <sys/time.h>
-
-struct ldap_map_struct
-{
-	/* needed for ldap_open */
-	char		*ldaphost;
-	int		ldapport;
-
-	/* Options set in ld struct before ldap_bind_s */
-	int		deref;
-	int		timelimit;
-	int		sizelimit;
-	int		ldap_options;
-
-	/* args for ldap_bind_s */
-	LDAP		*ld;
-	char		*binddn;
-	char		*passwd;
-	int		method;
-
-	/* args for ldap_search_st */
-	char		*base;
-	int		scope;
-	char		*filter;
-	char		*attr[2];
-	int		attrsonly;
-	struct timeval	timeout;
-	LDAPMessage	*res;
-};
-
-typedef struct ldap_map_struct	LDAP_MAP_STRUCT;
-
-#define DEFAULT_LDAP_MAP_PORT		LDAP_PORT
-#define DEFAULT_LDAP_MAP_SCOPE		LDAP_SCOPE_SUBTREE
-#define DEFAULT_LDAP_MAP_BINDDN		NULL
-#define DEFAULT_LDAP_MAP_PASSWD		NULL
-#define DEFAULT_LDAP_MAP_METHOD		LDAP_AUTH_SIMPLE
-#define DEFAULT_LDAP_MAP_TIMELIMIT	5
-#define DEFAULT_LDAP_MAP_DEREF		LDAP_DEREF_NEVER
-#define DEFAULT_LDAP_MAP_SIZELIMIT	0
-#define DEFAULT_LDAP_MAP_ATTRSONLY	0
-#define LDAP_MAP_MAX_FILTER		1024
-#ifdef LDAP_REFERRALS
-# define DEFAULT_LDAP_MAP_LDAP_OPTIONS	LDAP_OPT_REFERRALS
-#else /* LDAP_REFERRALS */
-# define DEFAULT_LDAP_MAP_LDAP_OPTIONS	0
-#endif /* LDAP_REFERRALS */
-
-/*
-**  ldap_init(3) is broken in Umich 3.x and OpenLDAP 1.0/1.1.
-**  Use the lack of LDAP_OPT_SIZELIMIT to detect old API implementations
-**  and assume (falsely) that all old API implementations are broken.
-**  (OpenLDAP 1.2 and later have a working ldap_init(), add -DUSE_LDAP_INIT)
-*/
-
-#if defined(LDAP_OPT_SIZELIMIT) && !defined(USE_LDAP_INIT)
-# define USE_LDAP_INIT	1
-#endif
-
-/*
-**  LDAP_OPT_SIZELIMIT is not defined under Umich 3.x nor OpenLDAP 1.x,
-**  hence ldap_set_option() must not exist.
-*/
-
-#if defined(LDAP_OPT_SIZELIMIT) && !defined(USE_LDAP_SET_OPTION)
-# define USE_LDAP_SET_OPTION	1
-#endif
-
-#endif /* _LDAP_MAP_H */
diff --git a/contrib/sendmail/src/mailstats.h b/contrib/sendmail/src/mailstats.h
deleted file mode 100644
index 86390b3..0000000
--- a/contrib/sendmail/src/mailstats.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
- * Copyright (c) 1983 Eric P. Allman.  All rights reserved.
- * Copyright (c) 1988, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * By using this file, you agree to the terms and conditions set
- * forth in the LICENSE file which can be found at the top level of
- * the sendmail distribution.
- *
- *
- *	@(#)mailstats.h	8.8 (Berkeley) 5/19/1998
- */
-
-#define STAT_VERSION	2
-#define STAT_MAGIC	0x1B1DE
-
-/*
-**  Statistics structure.
-*/
-
-struct statistics
-{
-	int	stat_magic;		/* magic number */
-	int	stat_version;		/* stat file version */
-	time_t	stat_itime;		/* file initialization time */
-	short	stat_size;		/* size of this structure */
-	long	stat_nf[MAXMAILERS];	/* # msgs from each mailer */
-	long	stat_bf[MAXMAILERS];	/* kbytes from each mailer */
-	long	stat_nt[MAXMAILERS];	/* # msgs to each mailer */
-	long	stat_bt[MAXMAILERS];	/* kbytes to each mailer */
-	long	stat_nr[MAXMAILERS];	/* # rejects by each mailer */
-	long	stat_nd[MAXMAILERS];	/* # discards by each mailer */
-};
diff --git a/contrib/sendmail/src/pathnames.h b/contrib/sendmail/src/pathnames.h
deleted file mode 100644
index 7a06b12..0000000
--- a/contrib/sendmail/src/pathnames.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*-
- * Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
- * Copyright (c) 1990, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * By using this file, you agree to the terms and conditions set
- * forth in the LICENSE file which can be found at the top level of
- * the sendmail distribution.
- *
- *
- *	@(#)pathnames.h	8.8 (Berkeley) 5/19/1998
- */
-
-#ifndef _PATH_SENDMAILCF
-# if defined(USE_VENDOR_CF_PATH) && defined(_PATH_VENDOR_CF)
-#  define _PATH_SENDMAILCF	_PATH_VENDOR_CF
-# else
-#  define _PATH_SENDMAILCF	"/etc/sendmail.cf"
-# endif
-#endif
-
-#ifndef _PATH_SENDMAILPID
-# ifdef BSD4_4
-#  define _PATH_SENDMAILPID	"/var/run/sendmail.pid"
-# else
-#  define _PATH_SENDMAILPID	"/etc/sendmail.pid"
-# endif
-#endif
-
-#ifndef _PATH_HOSTS
-# define _PATH_HOSTS		"/etc/hosts"
-#endif
diff --git a/contrib/sendmail/src/safefile.c b/contrib/sendmail/src/safefile.c
deleted file mode 100644
index ff94b3d2..0000000
--- a/contrib/sendmail/src/safefile.c
+++ /dev/null
@@ -1,751 +0,0 @@
-/*
- * Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
- * Copyright (c) 1983, 1995-1997 Eric P. Allman.  All rights reserved.
- * Copyright (c) 1988, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * By using this file, you agree to the terms and conditions set
- * forth in the LICENSE file which can be found at the top level of
- * the sendmail distribution.
- *
- */
-
-#ifndef lint
-static char sccsid[] = "@(#)safefile.c	8.43 (Berkeley) 10/13/1998";
-#endif /* not lint */
-
-# include "sendmail.h"
-/*
-**  SAFEFILE -- return true if a file exists and is safe for a user.
-**
-**	Parameters:
-**		fn -- filename to check.
-**		uid -- user id to compare against.
-**		gid -- group id to compare against.
-**		uname -- user name to compare against (used for group
-**			sets).
-**		flags -- modifiers:
-**			SFF_MUSTOWN -- "uid" must own this file.
-**			SFF_NOSLINK -- file cannot be a symbolic link.
-**		mode -- mode bits that must match.
-**		st -- if set, points to a stat structure that will
-**			get the stat info for the file.
-**
-**	Returns:
-**		0 if fn exists, is owned by uid, and matches mode.
-**		An errno otherwise.  The actual errno is cleared.
-**
-**	Side Effects:
-**		none.
-*/
-
-#include <grp.h>
-
-int
-safefile(fn, uid, gid, uname, flags, mode, st)
-	char *fn;
-	UID_T uid;
-	GID_T gid;
-	char *uname;
-	int flags;
-	int mode;
-	struct stat *st;
-{
-	register char *p;
-	register struct group *gr = NULL;
-	int file_errno = 0;
-	bool checkpath;
-	struct stat stbuf;
-	struct stat fstbuf;
-	char fbuf[MAXPATHLEN + 1];
-
-	if (tTd(44, 4))
-		printf("safefile(%s, uid=%d, gid=%d, flags=%x, mode=%o):\n",
-			fn, (int) uid, (int) gid, flags, mode);
-	errno = 0;
-	if (st == NULL)
-		st = &fstbuf;
-	if (strlen(fn) > sizeof fbuf - 1)
-	{
-		if (tTd(44, 4))
-			printf("\tpathname too long\n");
-		return ENAMETOOLONG;
-	}
-	strcpy(fbuf, fn);
-	fn = fbuf;
-
-	/* ignore SFF_SAFEDIRPATH if we are debugging */
-	if (RealUid != 0 && RunAsUid == RealUid)
-		flags &= ~SFF_SAFEDIRPATH;
-
-	/* first check to see if the file exists at all */
-#ifdef HASLSTAT
-	if ((bitset(SFF_NOSLINK, flags) ? lstat(fn, st)
-					: stat(fn, st)) < 0)
-#else
-	if (stat(fn, st) < 0)
-#endif
-	{
-		file_errno = errno;
-	}
-	else if (bitset(SFF_SETUIDOK, flags) &&
-		 !bitset(S_IXUSR|S_IXGRP|S_IXOTH, st->st_mode) &&
-		 S_ISREG(st->st_mode))
-	{
-		/*
-		**  If final file is setuid, run as the owner of that
-		**  file.  Gotta be careful not to reveal anything too
-		**  soon here!
-		*/
-
-#ifdef SUID_ROOT_FILES_OK
-		if (bitset(S_ISUID, st->st_mode))
-#else
-		if (bitset(S_ISUID, st->st_mode) && st->st_uid != 0 &&
-		    st->st_uid != TrustedUid)
-#endif
-		{
-			uid = st->st_uid;
-			uname = NULL;
-		}
-#ifdef SUID_ROOT_FILES_OK
-		if (bitset(S_ISGID, st->st_mode))
-#else
-		if (bitset(S_ISGID, st->st_mode) && st->st_gid != 0)
-#endif
-			gid = st->st_gid;
-	}
-
-	checkpath = !bitset(SFF_NOPATHCHECK, flags) ||
-		    (uid == 0 && !bitset(SFF_ROOTOK|SFF_OPENASROOT, flags));
-	if (bitset(SFF_NOWLINK, flags) && !bitset(SFF_SAFEDIRPATH, flags))
-	{
-		int ret;
-
-		/* check the directory */
-		p = strrchr(fn, '/');
-		if (p == NULL)
-		{
-			ret = safedirpath(".", uid, gid, uname, flags|SFF_SAFEDIRPATH);
-		}
-		else
-		{
-			*p = '\0';
-			ret = safedirpath(fn, uid, gid, uname, flags|SFF_SAFEDIRPATH);
-			*p = '/';
-		}
-		if (ret == 0)
-		{
-			/* directory is safe */
-			checkpath = FALSE;
-		}
-		else
-		{
-#ifdef HASLSTAT
-			/* Need lstat() information if called stat() before */
-			if (!bitset(SFF_NOSLINK, flags) && lstat(fn, st) < 0)
-			{
-				ret = errno;
-				if (tTd(44, 4))
-					printf("\t%s\n", errstring(ret));
-				return ret;
-			}
-#endif
-			/* directory is writable: disallow links */
-			flags |= SFF_NOLINK;
-		}
-	}
-
-	if (checkpath)
-	{
-		int ret;
-
-		p = strrchr(fn, '/');
-		if (p == NULL)
-		{
-			ret = safedirpath(".", uid, gid, uname, flags);
-		}
-		else
-		{
-			*p = '\0';
-			ret = safedirpath(fn, uid, gid, uname, flags);
-			*p = '/';
-		}
-		if (ret != 0)
-			return ret;
-	}
-
-	/*
-	**  If the target file doesn't exist, check the directory to
-	**  ensure that it is writable by this user.
-	*/
-
-	if (file_errno != 0)
-	{
-		int ret = file_errno;
-		char *dir = fn;
-
-		if (tTd(44, 4))
-			printf("\t%s\n", errstring(ret));
-
-		errno = 0;
-		if (!bitset(SFF_CREAT, flags) || file_errno != ENOENT)
-			return ret;
-
-		/* check to see if legal to create the file */
-		p = strrchr(dir, '/');
-		if (p == NULL)
-			dir = ".";
-		else if (p == dir)
-			dir = "/";
-		else
-			*p = '\0';
-		if (stat(dir, &stbuf) >= 0)
-		{
-			int md = S_IWRITE|S_IEXEC;
-
-			if (stbuf.st_uid == uid)
-				;
-			else if (uid == 0 && stbuf.st_uid == TrustedUid)
-				;
-			else
-			{
-				md >>= 3;
-				if (stbuf.st_gid == gid)
-					;
-#ifndef NO_GROUP_SET
-				else if (uname != NULL && !DontInitGroups &&
-			 		 ((gr != NULL &&
-			 		   gr->gr_gid == stbuf.st_gid) ||
-			  		  (gr = getgrgid(stbuf.st_gid)) != NULL))
-				{
-					register char **gp;
-		
-					for (gp = gr->gr_mem; *gp != NULL; gp++)
-						if (strcmp(*gp, uname) == 0)
-							break;
-					if (*gp == NULL)
-						md >>= 3;
-				}
-#endif
-				else
-					md >>= 3;
-			}
-			if ((stbuf.st_mode & md) != md)
-				errno = EACCES;
-		}
-		ret = errno;
-		if (tTd(44, 4))
-			printf("\t[final dir %s uid %d mode %lo] %s\n",
-				dir, (int) stbuf.st_uid, (u_long) stbuf.st_mode,
-				errstring(ret));
-		if (p != NULL)
-			*p = '/';
-		st->st_mode = ST_MODE_NOFILE;
-		return ret;
-	}
-
-#ifdef S_ISLNK
-	if (bitset(SFF_NOSLINK, flags) && S_ISLNK(st->st_mode))
-	{
-		if (tTd(44, 4))
-			printf("\t[slink mode %lo]\tE_SM_NOSLINK\n",
-				(u_long) st->st_mode);
-		return E_SM_NOSLINK;
-	}
-#endif
-	if (bitset(SFF_REGONLY, flags) && !S_ISREG(st->st_mode))
-	{
-		if (tTd(44, 4))
-			printf("\t[non-reg mode %lo]\tE_SM_REGONLY\n",
-				(u_long) st->st_mode);
-		return E_SM_REGONLY;
-	}
-	if (bitset(SFF_NOGWFILES, flags) &&
-	    bitset(S_IWGRP, st->st_mode))
-	{
-		if (tTd(44, 4))
-			printf("\t[write bits %lo]\tE_SM_GWFILE\n",
-			       (u_long) st->st_mode);
-		return E_SM_GWFILE;
-	}
-	if (bitset(SFF_NOWWFILES, flags) &&
-	    bitset(S_IWOTH, st->st_mode))
-	{
-		if (tTd(44, 4))
-			printf("\t[write bits %lo]\tE_SM_WWFILE\n",
-			       (u_long) st->st_mode);
-		return E_SM_WWFILE;
-	}
-	if (bitset(S_IWUSR|S_IWGRP|S_IWOTH, mode) &&
-	    bitset(S_IXUSR|S_IXGRP|S_IXOTH, st->st_mode))
-	{
-		if (tTd(44, 4))
-			printf("\t[exec bits %lo]\tE_SM_ISEXEC]\n",
-				(u_long) st->st_mode);
-		return E_SM_ISEXEC;
-	}
-	if (bitset(SFF_NOHLINK, flags) && st->st_nlink != 1)
-	{
-		if (tTd(44, 4))
-			printf("\t[link count %d]\tE_SM_NOHLINK\n",
-				(int) st->st_nlink);
-		return E_SM_NOHLINK;
-	}
-
-	if (uid == 0 && bitset(SFF_OPENASROOT, flags))
-		;
-	else if (uid == 0 && !bitset(SFF_ROOTOK, flags))
-		mode >>= 6;
-	else if (st->st_uid == uid)
-		;
-	else if (uid == 0 && st->st_uid == TrustedUid)
-		;
-	else
-	{
-		mode >>= 3;
-		if (st->st_gid == gid)
-			;
-#ifndef NO_GROUP_SET
-		else if (uname != NULL && !DontInitGroups &&
-			 ((gr != NULL && gr->gr_gid == st->st_gid) ||
-			  (gr = getgrgid(st->st_gid)) != NULL))
-		{
-			register char **gp;
-
-			for (gp = gr->gr_mem; *gp != NULL; gp++)
-				if (strcmp(*gp, uname) == 0)
-					break;
-			if (*gp == NULL)
-				mode >>= 3;
-		}
-#endif
-		else
-			mode >>= 3;
-	}
-	if (tTd(44, 4))
-		printf("\t[uid %d, nlink %d, stat %lo, mode %lo] ",
-			(int) st->st_uid, (int) st->st_nlink,
-			(u_long) st->st_mode, (u_long) mode);
-	if ((st->st_uid == uid || st->st_uid == 0 ||
-	     st->st_uid == TrustedUid ||
-	     !bitset(SFF_MUSTOWN, flags)) &&
-	    (st->st_mode & mode) == mode)
-	{
-		if (tTd(44, 4))
-			printf("\tOK\n");
-		return 0;
-	}
-	if (tTd(44, 4))
-		printf("\tEACCES\n");
-	return EACCES;
-}
-/*
-**  SAFEDIRPATH -- check to make sure a path to a directory is safe
-**
-**	Safe means not writable and owned by the right folks.
-**
-**	Parameters:
-**		fn -- filename to check.
-**		uid -- user id to compare against.
-**		gid -- group id to compare against.
-**		uname -- user name to compare against (used for group
-**			sets).
-**		flags -- modifiers:
-**			SFF_ROOTOK -- ok to use root permissions to open.
-**			SFF_SAFEDIRPATH -- writable directories are considered
-**				to be fatal errors.
-**
-**	Returns:
-**		0 -- if the directory path is "safe".
-**		else -- an error number associated with the path.
-*/
-
-int
-safedirpath(fn, uid, gid, uname, flags)
-	char *fn;
-	UID_T uid;
-	GID_T gid;
-	char *uname;
-	int flags;
-{
-	char *p;
-	register struct group *gr = NULL;
-	int ret = 0;
-	int mode = S_IWOTH;
-	struct stat stbuf;
-
-	/* special case root directory */
-	if (*fn == '\0')
-		fn = "/";
-
-	if (tTd(44, 4))
-		printf("safedirpath(%s, uid=%ld, gid=%ld, flags=%x):\n",
-			fn, (long) uid, (long) gid, flags);
-
-	if (!bitset(DBS_GROUPWRITABLEDIRPATHSAFE, DontBlameSendmail))
-		mode |= S_IWGRP;
-
-	p = fn;
-	do
-	{
-		if (*p == '\0')
-			*p = '/';
-		p = strchr(++p, '/');
-		if (p != NULL)
-			*p = '\0';
-		if (stat(fn, &stbuf) < 0)
-		{
-			ret = errno;
-			break;
-		}
-		if ((uid == 0 || bitset(SFF_SAFEDIRPATH, flags)) &&
-		    bitset(mode, stbuf.st_mode))
-		{
-			if (tTd(44, 4))
-				printf("\t[dir %s] mode %lo\n",
-					fn, (u_long) stbuf.st_mode);
-			if (bitset(SFF_SAFEDIRPATH, flags))
-			{
-				if (bitset(S_IWOTH, stbuf.st_mode))
-					ret = E_SM_WWDIR;
-				else
-					ret = E_SM_GWDIR;
-				break;
-			}
-			if (Verbose > 1)
-				message("051 WARNING: %s writable directory %s",
-					bitset(S_IWOTH, stbuf.st_mode)
-					   ? "World"
-					   : "Group",
-					fn);
-		}
-		if (uid == 0 && !bitset(SFF_ROOTOK|SFF_OPENASROOT, flags))
-		{
-			if (bitset(S_IXOTH, stbuf.st_mode))
-				continue;
-			ret = EACCES;
-			break;
-		}
-
-		/*
-		**  Let OS determine access to file if we are not
-		**  running as a privileged user.  This allows ACLs
-		**  to work.
-		*/
-		if (geteuid() != 0)
-			continue;
-
-		if (stbuf.st_uid == uid &&
-		    bitset(S_IXUSR, stbuf.st_mode))
-			continue;
-		if (stbuf.st_gid == gid &&
-		    bitset(S_IXGRP, stbuf.st_mode))
-			continue;
-#ifndef NO_GROUP_SET
-		if (uname != NULL && !DontInitGroups &&
-		    ((gr != NULL && gr->gr_gid == stbuf.st_gid) ||
-		     (gr = getgrgid(stbuf.st_gid)) != NULL))
-		{
-			register char **gp;
-
-			for (gp = gr->gr_mem; gp != NULL && *gp != NULL; gp++)
-				if (strcmp(*gp, uname) == 0)
-					break;
-			if (gp != NULL && *gp != NULL &&
-			    bitset(S_IXGRP, stbuf.st_mode))
-				continue;
-		}
-#endif
-		if (!bitset(S_IXOTH, stbuf.st_mode))
-		{
-			ret = EACCES;
-			break;
-		}
-	} while (p != NULL);
-	if (ret != 0 && tTd(44, 4))
-		printf("\t[dir %s] %s\n", fn, errstring(ret));
-	if (p != NULL)
-		*p = '/';
-	return ret;
-}
-/*
-**  SAFEOPEN -- do a file open with extra checking
-**
-**	Parameters:
-**		fn -- the file name to open.
-**		omode -- the open-style mode flags.
-**		cmode -- the create-style mode flags.
-**		sff -- safefile flags.
-**
-**	Returns:
-**		Same as open.
-*/
-
-#ifndef O_ACCMODE
-# define O_ACCMODE	(O_RDONLY|O_WRONLY|O_RDWR)
-#endif
-
-int
-safeopen(fn, omode, cmode, sff)
-	char *fn;
-	int omode;
-	int cmode;
-	int sff;
-{
-	int rval;
-	int fd;
-	int smode;
-	struct stat stb;
-
-	if (bitset(O_CREAT, omode))
-		sff |= SFF_CREAT;
-	omode &= ~O_CREAT;
-	smode = 0;
-	switch (omode & O_ACCMODE)
-	{
-	  case O_RDONLY:
-		smode = S_IREAD;
-		break;
-
-	  case O_WRONLY:
-		smode = S_IWRITE;
-		break;
-
-	  case O_RDWR:
-		smode = S_IREAD|S_IWRITE;
-		break;
-
-	  default:
-		smode = 0;
-		break;
-	}
-	if (bitset(SFF_OPENASROOT, sff))
-		rval = safefile(fn, RunAsUid, RunAsGid, RunAsUserName,
-				sff, smode, &stb);
-	else
-		rval = safefile(fn, RealUid, RealGid, RealUserName,
-				sff, smode, &stb);
-	if (rval != 0)
-	{
-		errno = rval;
-		return -1;
-	}
-	if (stb.st_mode == ST_MODE_NOFILE && bitset(SFF_CREAT, sff))
-		omode |= O_EXCL|O_CREAT;
-
-	fd = dfopen(fn, omode, cmode, sff);
-	if (fd < 0)
-		return fd;
-	if (filechanged(fn, fd, &stb))
-	{
-		syserr("554 cannot open: file %s changed after open", fn);
-		close(fd);
-		errno = E_SM_FILECHANGE;
-		return -1;
-	}
-	return fd;
-}
-/*
-**  SAFEFOPEN -- do a file open with extra checking
-**
-**	Parameters:
-**		fn -- the file name to open.
-**		omode -- the open-style mode flags.
-**		cmode -- the create-style mode flags.
-**		sff -- safefile flags.
-**
-**	Returns:
-**		Same as fopen.
-*/
-
-FILE *
-safefopen(fn, omode, cmode, sff)
-	char *fn;
-	int omode;
-	int cmode;
-	int sff;
-{
-	int fd;
-	FILE *fp;
-	char *fmode;
-
-	switch (omode & O_ACCMODE)
-	{
-	  case O_RDONLY:
-		fmode = "r";
-		break;
-
-	  case O_WRONLY:
-		if (bitset(O_APPEND, omode))
-			fmode = "a";
-		else
-			fmode = "w";
-		break;
-
-	  case O_RDWR:
-		if (bitset(O_TRUNC, omode))
-			fmode = "w+";
-		else if (bitset(O_APPEND, omode))
-			fmode = "a+";
-		else
-			fmode = "r+";
-		break;
-
-	  default:
-		syserr("safefopen: unknown omode %o", omode);
-		fmode = "x";
-	}
-	fd = safeopen(fn, omode, cmode, sff);
-	if (fd < 0)
-	{
-		if (tTd(44, 10))
-			printf("safefopen: safeopen failed: %s\n",
-				errstring(errno));
-		return NULL;
-	}
-	fp = fdopen(fd, fmode);
-	if (fp != NULL)
-		return fp;
-
-	if (tTd(44, 10))
-	{
-		printf("safefopen: fdopen(%s, %s) failed: omode=%x, sff=%x, err=%s\n",
-			fn, fmode, omode, sff, errstring(errno));
-#ifndef NOT_SENDMAIL
-		dumpfd(fd, TRUE, FALSE);
-#endif
-	}
-	(void) close(fd);
-	return NULL;
-}
-/*
-**  FILECHANGED -- check to see if file changed after being opened
-**
-**	Parameters:
-**		fn -- pathname of file to check.
-**		fd -- file descriptor to check.
-**		stb -- stat structure from before open.
-**
-**	Returns:
-**		TRUE -- if a problem was detected.
-**		FALSE -- if this file is still the same.
-*/
-
-bool
-filechanged(fn, fd, stb)
-	char *fn;
-	int fd;
-	struct stat *stb;
-{
-	struct stat sta;
-
-	if (stb->st_mode == ST_MODE_NOFILE)
-	{
-#if HASLSTAT && BOGUS_O_EXCL
-		/* only necessary if exclusive open follows symbolic links */
-		if (lstat(fn, stb) < 0 || stb->st_nlink != 1)
-			return TRUE;
-#else
-		return FALSE;
-#endif
-	}
-	if (fstat(fd, &sta) < 0)
-		return TRUE;
-
-	if (sta.st_nlink != stb->st_nlink ||
-	    sta.st_dev != stb->st_dev ||
-	    sta.st_ino != stb->st_ino ||
-#if HAS_ST_GEN && 0		/* AFS returns garbage in st_gen */
-	    sta.st_gen != stb->st_gen ||
-#endif
-	    sta.st_uid != stb->st_uid ||
-	    sta.st_gid != stb->st_gid)
-	{
-		if (tTd(44, 8))
-		{
-			printf("File changed after opening:\n");
-			printf(" nlink	= %ld/%ld\n",
-				(long) stb->st_nlink, (long) sta.st_nlink);
-			printf(" dev	= %ld/%ld\n",
-				(long) stb->st_dev, (long) sta.st_dev);
-			if (sizeof sta.st_ino > sizeof (long))
-			{
-				printf(" ino	= %s/", 
-					quad_to_string(stb->st_ino));
-				printf("%s\n",
-					quad_to_string(sta.st_ino));
-			}
-			else
-				printf(" ino	= %lu/%lu\n",
-					(unsigned long) stb->st_ino,
-					(unsigned long) sta.st_ino);
-#if HAS_ST_GEN
-			printf(" gen	= %ld/%ld\n",
-				(long) stb->st_gen, (long) sta.st_gen);
-#endif
-			printf(" uid	= %ld/%ld\n",
-				(long) stb->st_uid, (long) sta.st_uid);
-			printf(" gid	= %ld/%ld\n",
-				(long) stb->st_gid, (long) sta.st_gid);
-		}
-		return TRUE;
-	}
-
-	return FALSE;
-}
-/*
-**  DFOPEN -- determined file open
-**
-**	This routine has the semantics of open, except that it will
-**	keep trying a few times to make this happen.  The idea is that
-**	on very loaded systems, we may run out of resources (inodes,
-**	whatever), so this tries to get around it.
-*/
-
-int
-dfopen(filename, omode, cmode, sff)
-	char *filename;
-	int omode;
-	int cmode;
-	int sff;
-{
-	register int tries;
-	int fd;
-	struct stat st;
-
-	for (tries = 0; tries < 10; tries++)
-	{
-		sleep((unsigned) (10 * tries));
-		errno = 0;
-		fd = open(filename, omode, cmode);
-		if (fd >= 0)
-			break;
-		switch (errno)
-		{
-		  case ENFILE:		/* system file table full */
-		  case EINTR:		/* interrupted syscall */
-#ifdef ETXTBSY
-		  case ETXTBSY:		/* Apollo: net file locked */
-#endif
-			continue;
-		}
-		break;
-	}
-	if (!bitset(SFF_NOLOCK, sff) &&
-	    fd >= 0 &&
-	    fstat(fd, &st) >= 0 &&
-	    S_ISREG(st.st_mode))
-	{
-		int locktype;
-
-		/* lock the file to avoid accidental conflicts */
-		if ((omode & O_ACCMODE) != O_RDONLY)
-			locktype = LOCK_EX;
-		else
-			locktype = LOCK_SH;
-		(void) lockfile(fd, filename, NULL, locktype);
-		errno = 0;
-	}
-	return fd;
-}
diff --git a/contrib/sendmail/src/sendmail.hf b/contrib/sendmail/src/sendmail.hf
deleted file mode 100644
index 0952963..0000000
--- a/contrib/sendmail/src/sendmail.hf
+++ /dev/null
@@ -1,124 +0,0 @@
-cpyr
-cpyr	Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
-cpyr	Copyright (c) 1983, 1995-1997 Eric P. Allman.  All rights reserved.
-cpyr	Copyright (c) 1988, 1993
-cpyr	    The Regents of the University of California.  All rights reserved.
-cpyr	
-cpyr
-cpyr	By using this file, you agree to the terms and conditions set
-cpyr	forth in the LICENSE file which can be found at the top level of
-cpyr	the sendmail distribution.
-cpyr
-cpyr	@(#)sendmail.hf	8.18 (Berkeley) 11/19/1998
-cpyr
-smtp	Topics:
-smtp		HELO	EHLO	MAIL	RCPT	DATA
-smtp		RSET	NOOP	QUIT	HELP	VRFY
-smtp		EXPN	VERB	ETRN	DSN
-smtp	For more info use "HELP <topic>".
-smtp	To report bugs in the implementation send email to
-smtp		sendmail-bugs@sendmail.org.
-smtp	For local information send email to Postmaster at your site.
-help	HELP [ <topic> ]
-help		The HELP command gives help info.
-helo	HELO <hostname>
-helo		Introduce yourself.
-ehlo	EHLO <hostname>
-ehlo		Introduce yourself, and request extended SMTP mode.
-ehlo	Possible replies include:
-ehlo		SEND		Send as mail			[RFC821]
-ehlo		SOML		Send as mail or terminal	[RFC821]
-ehlo		SAML		Send as mail and terminal	[RFC821]
-ehlo		EXPN		Expand the mailing list		[RFC821]
-ehlo		HELP		Supply helpful information	[RFC821]
-ehlo		TURN		Turn the operation around	[RFC821]
-ehlo		8BITMIME	Use 8-bit data			[RFC1652]
-ehlo		SIZE		Message size declaration	[RFC1870]
-ehlo		VERB		Verbose				[Allman]
-ehlo		ONEX		One message transaction only	[Allman]
-ehlo		CHUNKING	Chunking			[RFC1830]
-ehlo		BINARYMIME	Binary MIME			[RFC1830]
-ehlo		PIPELINING	Command Pipelining		[RFC1854]
-ehlo		DSN		Delivery Status Notification	[RFC1891]
-ehlo		ETRN		Remote Message Queue Starting	[RFC1985]
-ehlo		XUSR		Initial (user) submission	[Allman]
-mail	MAIL FROM: <sender> [ <parameters> ]
-mail		Specifies the sender.  Parameters are ESMTP extensions.
-mail		See "HELP DSN" for details.
-rcpt	RCPT TO: <recipient> [ <parameters> ]
-rcpt		Specifies the recipient.  Can be used any number of times.
-rcpt		Parameters are ESMTP extensions.  See "HELP DSN" for details.
-data	DATA
-data		Following text is collected as the message.
-data		End with a single dot.
-rset	RSET
-rset		Resets the system.
-quit	QUIT
-quit		Exit sendmail (SMTP).
-verb	VERB
-verb		Go into verbose mode.  This sends 0xy responses that are
-verb		not RFC821 standard (but should be)  They are recognized
-verb		by humans and other sendmail implementations.
-vrfy	VRFY <recipient>
-vrfy		Verify an address.  If you want to see what it aliases
-vrfy		to, use EXPN instead.
-expn	EXPN <recipient>
-expn		Expand an address.  If the address indicates a mailing
-expn		list, return the contents of that list.
-noop	NOOP
-noop		Do nothing.
-send	SEND FROM: <sender>
-send		replaces the MAIL command, and can be used to send
-send		directly to a users terminal.  Not supported in this
-send		implementation.
-soml	SOML FROM: <sender>
-soml		Send or mail.  If the user is logged in, send directly,
-soml		otherwise mail.  Not supported in this implementation.
-saml	SAML FROM: <sender>
-saml		Send and mail.  Send directly to the user's terminal,
-saml		and also mail a letter.  Not supported in this
-saml		implementation.
-turn	TURN
-turn		Reverses the direction of the connection.  Not currently
-turn		implemented.
-etrn	ETRN [ <hostname> | @<domain> | #<queuename> ]
-etrn		Run the queue for the specified <hostname>, or
-etrn		all hosts within a given <domain>, or a specially-named
-etrn		<queuename> (implementation-specific).
-dsn	MAIL FROM: <sender> [ RET={ FULL | HDRS} ] [ ENVID=<envid> ]
-dsn	RCPT TO: <recipient> [ NOTIFY={NEVER,SUCCESS,FAILURE,DELAY} ]
-dsn	                     [ ORCPT=<recipient> ]
-dsn		SMTP Delivery Status Notifications.
-dsn	Descriptions:
-dsn		RET	Return either the full message or only headers.
-dsn		ENVID	Sender's "envelope identifier" for tracking.
-dsn		NOTIFY	When to send a DSN. Multiple options are OK, comma-
-dsn		        delimited. NEVER must appear by itself.
-dsn		ORCPT	Original recipient.
--bt	Help for test mode:
--bt	?                :this help message.
--bt	.Dmvalue         :define macro `m' to `value'.
--bt	.Ccvalue         :add `value' to class `c'.
--bt	=Sruleset        :dump the contents of the indicated ruleset.
--bt	=M               :display the known mailers.
--bt	-ddebug-spec     :equivalent to the command-line -d debug flag.
--bt	$m               :print the value of macro $m.
--bt	$=c              :print the contents of class $=c.
--bt	/mx host         :returns the MX records for `host'.
--bt	/parse address   :parse address, returning the value of crackaddr, and
--bt	                  the parsed address (same as -bv).
--bt	/try mailer addr :rewrite address into the form it will have when
--bt	                  presented to the indicated mailer.
--bt	/tryflags flags  :set flags used by parsing.  The flags can be `H' for
--bt	                  Header or `E' for Envelope, and `S' for Sender or `R'
--bt	                  for Recipient.  These can be combined, `HR' sets
--bt			  flags for header recipients.
--bt	/canon hostname  :try to canonify hostname.
--bt	/map mapname key :look up `key' in the indicated `mapname'.
--bt	rules addr	 :run the indicated address through the named rules.
--bt			  Rules can be a comma separated list of rules.
-control	Help for smcontrol:
-control	help		This message.
-control	restart		Restart sendmail.
-control	shutdown	Shutdown sendmail.
-control	status		Show sendmail status.
diff --git a/contrib/sendmail/src/snprintf.c b/contrib/sendmail/src/snprintf.c
deleted file mode 100644
index 3e07e1b..0000000
--- a/contrib/sendmail/src/snprintf.c
+++ /dev/null
@@ -1,428 +0,0 @@
-/*
- * Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
- * Copyright (c) 1997 Eric P. Allman.  All rights reserved.
- * Copyright (c) 1988, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * By using this file, you agree to the terms and conditions set
- * forth in the LICENSE file which can be found at the top level of
- * the sendmail distribution.
- *
- */
-
-#ifndef lint
-static char sccsid[] = "@(#)snprintf.c	8.12 (Berkeley) 10/13/1998";
-#endif /* not lint */
-
-#include "sendmail.h"
-
-/*
-**  SNPRINTF, VSNPRINT -- counted versions of printf
-**
-**	These versions have been grabbed off the net.  They have been
-**	cleaned up to compile properly and support for .precision and
-**	%lx has been added.
-*/
-
-/**************************************************************
- * Original:
- * Patrick Powell Tue Apr 11 09:48:21 PDT 1995
- * A bombproof version of doprnt (sm_dopr) included.
- * Sigh.  This sort of thing is always nasty do deal with.  Note that
- * the version here does not include floating point...
- *
- * snprintf() is used instead of sprintf() as it does limit checks
- * for string length.  This covers a nasty loophole.
- *
- * The other functions are there to prevent NULL pointers from
- * causing nast effects.
- **************************************************************/
-
-/*static char _id[] = "$Id: snprintf.c,v 1.2 1995/10/09 11:19:47 roberto Exp $";*/
-void	sm_dopr();
-char	*DoprEnd;
-int	SnprfOverflow;
-
-#if !HASSNPRINTF
-
-/* VARARGS3 */
-int
-# ifdef __STDC__
-snprintf(char *str, size_t count, const char *fmt, ...)
-# else
-snprintf(str, count, fmt, va_alist)
-	char *str;
-	size_t count;
-	const char *fmt;
-	va_dcl
-#endif
-{
-	int len;
-	VA_LOCAL_DECL
-
-	VA_START(fmt);
-	len = vsnprintf(str, count, fmt, ap);
-	VA_END;
-	return len;
-}
-
-
-# ifndef luna2
-int
-vsnprintf(str, count, fmt, args)
-	char *str;
-	size_t count;
-	const char *fmt;
-	va_list args;
-{
-	str[0] = 0;
-	DoprEnd = str + count - 1;
-	SnprfOverflow = 0;
-	sm_dopr( str, fmt, args );
-	if (count > 0)
-		DoprEnd[0] = 0;
-	if (SnprfOverflow && tTd(57, 2))
-		printf("\nvsnprintf overflow, len = %ld, str = %s",
-			(long) count, shortenstring(str, MAXSHORTSTR));
-	return strlen(str);
-}
-
-# endif /* !luna2 */
-#endif /* !HASSNPRINTF */
-
-/*
- * sm_dopr(): poor man's version of doprintf
- */
-
-void fmtstr __P((char *value, int ljust, int len, int zpad, int maxwidth));
-void fmtnum __P((long value, int base, int dosign, int ljust, int len, int zpad));
-void dostr __P(( char * , int ));
-char *output;
-void dopr_outch __P(( int c ));
-int	SyslogErrno;
-
-void
-sm_dopr( buffer, format, args )
-       char *buffer;
-       const char *format;
-       va_list args;
-{
-       int ch;
-       long value;
-       int longflag  = 0;
-       int pointflag = 0;
-       int maxwidth  = 0;
-       char *strvalue;
-       int ljust;
-       int len;
-       int zpad;
-# if !HASSTRERROR && !defined(ERRLIST_PREDEFINED)
-	extern char *sys_errlist[];
-	extern int sys_nerr;
-# endif
-
-
-       output = buffer;
-       while( (ch = *format++) != '\0' ){
-	       switch( ch ){
-	       case '%':
-		       ljust = len = zpad = maxwidth = 0;
-		       longflag = pointflag = 0;
-	       nextch:
-		       ch = *format++;
-		       switch( ch ){
-		       case 0:
-			       dostr( "**end of format**" , 0);
-			       return;
-		       case '-': ljust = 1; goto nextch;
-		       case '0': /* set zero padding if len not set */
-			       if(len==0 && !pointflag) zpad = '0';
-		       case '1': case '2': case '3':
-		       case '4': case '5': case '6':
-		       case '7': case '8': case '9':
-			       if (pointflag)
-				 maxwidth = maxwidth*10 + ch - '0';
-			       else
-				 len = len*10 + ch - '0';
-			       goto nextch;
-		       case '*': 
-			       if (pointflag)
-				 maxwidth = va_arg( args, int );
-			       else
-				 len = va_arg( args, int );
-			       goto nextch;
-		       case '.': pointflag = 1; goto nextch;
-		       case 'l': longflag = 1; goto nextch;
-		       case 'u': case 'U':
-			       /*fmtnum(value,base,dosign,ljust,len,zpad) */
-			       if( longflag ){
-				       value = va_arg( args, long );
-			       } else {
-				       value = va_arg( args, int );
-			       }
-			       fmtnum( value, 10,0, ljust, len, zpad ); break;
-		       case 'o': case 'O':
-			       /*fmtnum(value,base,dosign,ljust,len,zpad) */
-			       if( longflag ){
-				       value = va_arg( args, long );
-			       } else {
-				       value = va_arg( args, int );
-			       }
-			       fmtnum( value, 8,0, ljust, len, zpad ); break;
-		       case 'd': case 'D':
-			       if( longflag ){
-				       value = va_arg( args, long );
-			       } else {
-				       value = va_arg( args, int );
-			       }
-			       fmtnum( value, 10,1, ljust, len, zpad ); break;
-		       case 'x':
-			       if( longflag ){
-				       value = va_arg( args, long );
-			       } else {
-				       value = va_arg( args, int );
-			       }
-			       fmtnum( value, 16,0, ljust, len, zpad ); break;
-		       case 'X':
-			       if( longflag ){
-				       value = va_arg( args, long );
-			       } else {
-				       value = va_arg( args, int );
-			       }
-			       fmtnum( value,-16,0, ljust, len, zpad ); break;
-		       case 's':
-			       strvalue = va_arg( args, char *);
-			       if (maxwidth > 0 || !pointflag) {
-				 if (pointflag && len > maxwidth)
-				   len = maxwidth; /* Adjust padding */
-				 fmtstr( strvalue,ljust,len,zpad, maxwidth);
-			       }
-			       break;
-		       case 'c':
-			       ch = va_arg( args, int );
-			       dopr_outch( ch ); break;
-                       case 'm':
-#if HASSTRERROR
-                               dostr(strerror(SyslogErrno), 0);
-#else
-                               if (SyslogErrno < 0 || SyslogErrno >= sys_nerr) 
-                               {
-                                   dostr("Error ", 0);
-                                   fmtnum(SyslogErrno, 10, 0, 0, 0, 0);
-                               }
-                               else 
-                                   dostr((char *)sys_errlist[SyslogErrno], 0);
-#endif
-			       break;
-
-		       case '%': dopr_outch( ch ); continue;
-		       default:
-			       dostr(  "???????" , 0);
-		       }
-		       break;
-	       default:
-		       dopr_outch( ch );
-		       break;
-	       }
-       }
-       *output = 0;
-}
-
-void
-fmtstr(  value, ljust, len, zpad, maxwidth )
-       char *value;
-       int ljust, len, zpad, maxwidth;
-{
-       int padlen, strlen;     /* amount to pad */
-
-       if( value == 0 ){
-	       value = "<NULL>";
-       }
-       for( strlen = 0; value[strlen]; ++ strlen ); /* strlen */
-       if (strlen > maxwidth && maxwidth)
-	 strlen = maxwidth;
-       padlen = len - strlen;
-       if( padlen < 0 ) padlen = 0;
-       if( ljust ) padlen = -padlen;
-       while( padlen > 0 ) {
-	       dopr_outch( ' ' );
-	       --padlen;
-       }
-       dostr( value, maxwidth );
-       while( padlen < 0 ) {
-	       dopr_outch( ' ' );
-	       ++padlen;
-       }
-}
-
-void
-fmtnum(  value, base, dosign, ljust, len, zpad )
-       long value;
-       int base, dosign, ljust, len, zpad;
-{
-       int signvalue = 0;
-       unsigned long uvalue;
-       char convert[20];
-       int place = 0;
-       int padlen = 0; /* amount to pad */
-       int caps = 0;
-
-       /* DEBUGP(("value 0x%x, base %d, dosign %d, ljust %d, len %d, zpad %d\n",
-	       value, base, dosign, ljust, len, zpad )); */
-       uvalue = value;
-       if( dosign ){
-	       if( value < 0 ) {
-		       signvalue = '-';
-		       uvalue = -value;
-	       }
-       }
-       if( base < 0 ){
-	       caps = 1;
-	       base = -base;
-       }
-       do{
-	       convert[place++] =
-		       (caps? "0123456789ABCDEF":"0123456789abcdef")
-			[uvalue % (unsigned)base  ];
-	       uvalue = (uvalue / (unsigned)base );
-       }while(uvalue);
-       convert[place] = 0;
-       padlen = len - place;
-       if( padlen < 0 ) padlen = 0;
-       if( ljust ) padlen = -padlen;
-       /* DEBUGP(( "str '%s', place %d, sign %c, padlen %d\n",
-	       convert,place,signvalue,padlen)); */
-       if( zpad && padlen > 0 ){
-	       if( signvalue ){
-		       dopr_outch( signvalue );
-		       --padlen;
-		       signvalue = 0;
-	       }
-	       while( padlen > 0 ){
-		       dopr_outch( zpad );
-		       --padlen;
-	       }
-       }
-       while( padlen > 0 ) {
-	       dopr_outch( ' ' );
-	       --padlen;
-       }
-       if( signvalue ) dopr_outch( signvalue );
-       while( place > 0 ) dopr_outch( convert[--place] );
-       while( padlen < 0 ){
-	       dopr_outch( ' ' );
-	       ++padlen;
-       }
-}
-
-void
-dostr( str , cut)
-     char *str;
-     int cut;
-{
-  if (cut) {
-    while(*str && cut-- > 0) dopr_outch(*str++);
-  } else {
-    while(*str) dopr_outch(*str++);
-  }
-}
-
-void
-dopr_outch( c )
-       int c;
-{
-#if 0
-       if( iscntrl(c) && c != '\n' && c != '\t' ){
-	       c = '@' + (c & 0x1F);
-	       if( DoprEnd == 0 || output < DoprEnd )
-		       *output++ = '^';
-       }
-#endif
-       if( DoprEnd == 0 || output < DoprEnd )
-	       *output++ = c;
-       else
-		SnprfOverflow++;
-}
-
-/*
-**  QUAD_TO_STRING -- Convert a quad type to a string.
-**
-**	Convert a quad type to a string.  This must be done
-**	separately as %lld/%qd are not supported by snprint()
-**	and adding support would slow down systems which only
-**	emulate the data type.
-**
-**	Parameters:
-**		value -- number to convert to a string.
-**
-**	Returns:
-**		pointer to a string.
-*/
-
-char *
-quad_to_string(value)
-	QUAD_T value;
-{
-	char *fmtstr;
-	static char buf[64];
-
-	/*
-	**  Use sprintf() instead of snprintf() since snprintf()
-	**  does not support %qu or %llu.  The buffer is large enough
-	**  to hold the string so there is no danger of buffer
-	**  overflow.
-	*/
-
-#if NEED_PERCENTQ
-	fmtstr = "%qu";
-#else
-	fmtstr = "%llu";
-#endif
-	sprintf(buf, fmtstr, value);
-	return buf;
-}
-/*
-**  SHORTENSTRING -- return short version of a string
-**
-**	If the string is already short, just return it.  If it is too
-**	long, return the head and tail of the string.
-**
-**	Parameters:
-**		s -- the string to shorten.
-**		m -- the max length of the string.
-**
-**	Returns:
-**		Either s or a short version of s.
-*/
-
-char *
-shortenstring(s, m)
-	register const char *s;
-	int m;
-{
-	int l;
-	static char buf[MAXSHORTSTR + 1];
-
-	l = strlen(s);
-	if (l < m)
-		return (char *) s;
-	if (m > MAXSHORTSTR)
-		m = MAXSHORTSTR;
-	else if (m < 10)
-	{
-		if (m < 5)
-		{
-			strncpy(buf, s, m);
-			buf[m] = '\0';
-			return buf;
-		}
-		strncpy(buf, s, m - 3);
-		strcpy(buf + m - 3, "...");
-		return buf;
-	}
-	m = (m - 3) / 2;
-	strncpy(buf, s, m);
-	strcpy(buf + m, "...");
-	strcpy(buf + m + 3, s + l - m);
-	return buf;
-}
diff --git a/contrib/sendmail/src/useful.h b/contrib/sendmail/src/useful.h
deleted file mode 100644
index a19dd9e..0000000
--- a/contrib/sendmail/src/useful.h
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
- * Copyright (c) 1995-1997 Eric P. Allman.  All rights reserved.
- * Copyright (c) 1988, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * By using this file, you agree to the terms and conditions set
- * forth in the LICENSE file which can be found at the top level of
- * the sendmail distribution.
- *
- *
- *	@(#)useful.h	8.12 (Berkeley) 5/19/1998
- */
-
-# include <sys/types.h>
-
-/* support for bool type */
-typedef int	bool;
-#ifndef TRUE
-# define TRUE	1
-# define FALSE	0
-#endif
-
-# ifndef NULL
-# define NULL	0
-# endif /* NULL */
-
-/* bit hacking */
-# define bitset(bit, word)	(((word) & (bit)) != 0)
-
-/* some simple functions */
-# ifndef max
-# define max(a, b)	((a) > (b) ? (a) : (b))
-# define min(a, b)	((a) < (b) ? (a) : (b))
-# endif
-
-/* assertions */
-# ifndef NASSERT
-# define ASSERT(expr, msg, parm)\
-	if (!(expr))\
-	{\
-		fprintf(stderr, "assertion botch: %s:%d: ", __FILE__, __LINE__);\
-		fprintf(stderr, msg, parm);\
-	}
-# else /* NASSERT */
-# define ASSERT(expr, msg, parm)
-# endif /* NASSERT */
-
-/* sccs id's */
-# ifndef lint
-#  ifdef __STDC__
-#   define SCCSID(arg)	static char SccsId[] = #arg;
-#  else
-#   define SCCSID(arg)	static char SccsId[] = "arg";
-#  endif
-# else
-#  define SCCSID(arg)
-# endif