diff options
Diffstat (limited to 'contrib/sendmail')
| -rw-r--r-- | contrib/sendmail/FREEBSD-upgrade | 49 | ||||
| -rw-r--r-- | contrib/sendmail/cf/m4/nullrelay.m4 | 113 | ||||
| -rw-r--r-- | contrib/sendmail/cf/ostype/gnuhurd.m4 | 20 | ||||
| -rw-r--r-- | contrib/sendmail/contrib/converting.sun.configs | 446 | ||||
| -rw-r--r-- | contrib/sendmail/doc/changes/Makefile | 13 | ||||
| -rw-r--r-- | contrib/sendmail/doc/changes/changes.me | 975 | ||||
| -rw-r--r-- | contrib/sendmail/doc/intro/Makefile | 13 | ||||
| -rw-r--r-- | contrib/sendmail/doc/intro/intro.me | 1456 | ||||
| -rw-r--r-- | contrib/sendmail/doc/usenix/Makefile | 12 | ||||
| -rw-r--r-- | contrib/sendmail/doc/usenix/usenix.me | 1076 | ||||
| -rw-r--r-- | contrib/sendmail/mail.local/pathnames.h | 16 | ||||
| -rw-r--r-- | contrib/sendmail/src/cdefs.h | 123 | ||||
| -rw-r--r-- | contrib/sendmail/src/ldap_map.h | 91 | ||||
| -rw-r--r-- | contrib/sendmail/src/mailstats.h | 34 | ||||
| -rw-r--r-- | contrib/sendmail/src/pathnames.h | 32 | ||||
| -rw-r--r-- | contrib/sendmail/src/safefile.c | 751 | ||||
| -rw-r--r-- | contrib/sendmail/src/sendmail.hf | 124 | ||||
| -rw-r--r-- | contrib/sendmail/src/snprintf.c | 428 | ||||
| -rw-r--r-- | contrib/sendmail/src/useful.h | 58 |
19 files changed, 49 insertions, 5781 deletions
diff --git a/contrib/sendmail/FREEBSD-upgrade b/contrib/sendmail/FREEBSD-upgrade new file mode 100644 index 000000000000..ffcea8962a3c --- /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 b71fd570654c..000000000000 --- 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 a8ed66765e24..000000000000 --- 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 e6a3a9e8bd91..000000000000 --- 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 76eaa3912ee2..000000000000 --- 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 b963396ba49d..000000000000 --- 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 6369a4a0fec8..000000000000 --- 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 03cfa336994d..000000000000 --- 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 d2308cb891bc..000000000000 --- 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 4f88a94f8f24..000000000000 --- 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 ebb919c91ba4..000000000000 --- 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 e586cbfaf7cb..000000000000 --- 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 7d40329e1b5e..000000000000 --- 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 86390b3911a3..000000000000 --- 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 7a06b120652c..000000000000 --- 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 ff94b3d243bf..000000000000 --- 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 0952963b8bd2..000000000000 --- 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 3e07e1b9920f..000000000000 --- 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 a19dd9e0305d..000000000000 --- 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 |