From 1686d8abf9806a1fff38d74a7eec40c111945c76 Mon Sep 17 00:00:00 2001 From: peter Date: Sat, 2 Dec 1995 20:58:10 +0000 Subject: *GULP* cvs remove the uncomfortably large list of files that are no longer part of sendmail 8.7.2... --- secure/usr.sbin/sendmail/Makefile | 2 +- usr.sbin/sendmail/Makefile | 2 +- usr.sbin/sendmail/cf/cf/Makefile.dist | 85 - usr.sbin/sendmail/cf/cf/alpha.mc | 41 - usr.sbin/sendmail/cf/cf/auspex.mc | 42 - usr.sbin/sendmail/cf/cf/chez.mc | 44 - usr.sbin/sendmail/cf/cf/cogsci.mc | 41 - usr.sbin/sendmail/cf/cf/cs-exposed.mc | 40 - usr.sbin/sendmail/cf/cf/cs-hidden.mc | 40 - usr.sbin/sendmail/cf/cf/hpux-cs-exposed.mc | 41 - usr.sbin/sendmail/cf/cf/hpux-cs-hidden.mc | 41 - usr.sbin/sendmail/cf/cf/knecht.mc | 44 - usr.sbin/sendmail/cf/cf/osf1-cs-exposed.mc | 41 - usr.sbin/sendmail/cf/cf/osf1-cs-hidden.mc | 41 - usr.sbin/sendmail/cf/cf/python.mc | 52 - usr.sbin/sendmail/cf/cf/riscos-cs-exposed.mc | 41 - usr.sbin/sendmail/cf/cf/s2k.mc | 42 - usr.sbin/sendmail/cf/cf/sample.mc | 40 - usr.sbin/sendmail/cf/cf/sleepy.mc | 43 - usr.sbin/sendmail/cf/cf/sunos3.5-cs-exposed.mc | 41 - usr.sbin/sendmail/cf/cf/sunos3.5-cs-hidden.mc | 41 - usr.sbin/sendmail/cf/cf/sunos4.1-cs-exposed.mc | 41 - usr.sbin/sendmail/cf/cf/sunos4.1-cs-hidden.mc | 41 - usr.sbin/sendmail/cf/cf/udb.mc | 41 - usr.sbin/sendmail/cf/cf/ultrix4.1-cs-exposed.mc | 41 - usr.sbin/sendmail/cf/cf/ultrix4.1-cs-hidden.mc | 41 - usr.sbin/sendmail/cf/cf/vangogh.mc | 44 - usr.sbin/sendmail/cf/domain/Berkeley.m4 | 42 - usr.sbin/sendmail/cf/domain/cs.exposed.m4 | 40 - usr.sbin/sendmail/cf/domain/cs.hidden.m4 | 38 - usr.sbin/sendmail/cf/domain/eecs.hidden.m4 | 38 - usr.sbin/sendmail/cf/domain/s2k.m4 | 38 - usr.sbin/sendmail/cf/ostype/hpux.m4 | 44 - usr.sbin/sendmail/cf/ostype/irix.m4 | 41 - usr.sbin/sendmail/cf/ostype/ultrix4.1.m4 | 38 - usr.sbin/sendmail/doc/Makefile | 5 - usr.sbin/sendmail/doc/op/spell.ok | 324 -- usr.sbin/sendmail/doc/rfc/rfc819.txt | 1044 ------ usr.sbin/sendmail/doc/rfc/rfc821.txt | 4050 ----------------------- usr.sbin/sendmail/doc/rfc/rfc822.txt | 2901 ---------------- usr.sbin/sendmail/makemap/Makefile | 2 +- usr.sbin/sendmail/makemap/Makefile.dist | 81 - usr.sbin/sendmail/praliases/Makefile.dist | 81 - usr.sbin/sendmail/src/TODO | 287 -- 44 files changed, 3 insertions(+), 10185 deletions(-) delete mode 100644 usr.sbin/sendmail/cf/cf/Makefile.dist delete mode 100644 usr.sbin/sendmail/cf/cf/alpha.mc delete mode 100644 usr.sbin/sendmail/cf/cf/auspex.mc delete mode 100644 usr.sbin/sendmail/cf/cf/chez.mc delete mode 100644 usr.sbin/sendmail/cf/cf/cogsci.mc delete mode 100644 usr.sbin/sendmail/cf/cf/cs-exposed.mc delete mode 100644 usr.sbin/sendmail/cf/cf/cs-hidden.mc delete mode 100644 usr.sbin/sendmail/cf/cf/hpux-cs-exposed.mc delete mode 100644 usr.sbin/sendmail/cf/cf/hpux-cs-hidden.mc delete mode 100644 usr.sbin/sendmail/cf/cf/knecht.mc delete mode 100644 usr.sbin/sendmail/cf/cf/osf1-cs-exposed.mc delete mode 100644 usr.sbin/sendmail/cf/cf/osf1-cs-hidden.mc delete mode 100644 usr.sbin/sendmail/cf/cf/python.mc delete mode 100644 usr.sbin/sendmail/cf/cf/riscos-cs-exposed.mc delete mode 100644 usr.sbin/sendmail/cf/cf/s2k.mc delete mode 100644 usr.sbin/sendmail/cf/cf/sample.mc delete mode 100644 usr.sbin/sendmail/cf/cf/sleepy.mc delete mode 100644 usr.sbin/sendmail/cf/cf/sunos3.5-cs-exposed.mc delete mode 100644 usr.sbin/sendmail/cf/cf/sunos3.5-cs-hidden.mc delete mode 100644 usr.sbin/sendmail/cf/cf/sunos4.1-cs-exposed.mc delete mode 100644 usr.sbin/sendmail/cf/cf/sunos4.1-cs-hidden.mc delete mode 100644 usr.sbin/sendmail/cf/cf/udb.mc delete mode 100644 usr.sbin/sendmail/cf/cf/ultrix4.1-cs-exposed.mc delete mode 100644 usr.sbin/sendmail/cf/cf/ultrix4.1-cs-hidden.mc delete mode 100644 usr.sbin/sendmail/cf/cf/vangogh.mc delete mode 100644 usr.sbin/sendmail/cf/domain/Berkeley.m4 delete mode 100644 usr.sbin/sendmail/cf/domain/cs.exposed.m4 delete mode 100644 usr.sbin/sendmail/cf/domain/cs.hidden.m4 delete mode 100644 usr.sbin/sendmail/cf/domain/eecs.hidden.m4 delete mode 100644 usr.sbin/sendmail/cf/domain/s2k.m4 delete mode 100644 usr.sbin/sendmail/cf/ostype/hpux.m4 delete mode 100644 usr.sbin/sendmail/cf/ostype/irix.m4 delete mode 100644 usr.sbin/sendmail/cf/ostype/ultrix4.1.m4 delete mode 100644 usr.sbin/sendmail/doc/Makefile delete mode 100644 usr.sbin/sendmail/doc/op/spell.ok delete mode 100644 usr.sbin/sendmail/doc/rfc/rfc819.txt delete mode 100644 usr.sbin/sendmail/doc/rfc/rfc821.txt delete mode 100644 usr.sbin/sendmail/doc/rfc/rfc822.txt delete mode 100644 usr.sbin/sendmail/makemap/Makefile.dist delete mode 100644 usr.sbin/sendmail/praliases/Makefile.dist delete mode 100644 usr.sbin/sendmail/src/TODO diff --git a/secure/usr.sbin/sendmail/Makefile b/secure/usr.sbin/sendmail/Makefile index c5513cd..2dc0b0f 100644 --- a/secure/usr.sbin/sendmail/Makefile +++ b/secure/usr.sbin/sendmail/Makefile @@ -1,7 +1,7 @@ # @(#)Makefile 8.12 (Berkeley) 5/29/95 VER= XX -SUBDIR= src mailstats makemap praliases +SUBDIR= src mailstats makemap praliases cf/cf FTPDIR= mastodon:/disks/barad-dur/ftp/sendmail/. DISTFILES=sendmail.${VER}.tar.Z sendmail.${VER}.tar.gz \ RELEASE_NOTES FAQ KNOWNBUGS diff --git a/usr.sbin/sendmail/Makefile b/usr.sbin/sendmail/Makefile index c5513cd..2dc0b0f 100644 --- a/usr.sbin/sendmail/Makefile +++ b/usr.sbin/sendmail/Makefile @@ -1,7 +1,7 @@ # @(#)Makefile 8.12 (Berkeley) 5/29/95 VER= XX -SUBDIR= src mailstats makemap praliases +SUBDIR= src mailstats makemap praliases cf/cf FTPDIR= mastodon:/disks/barad-dur/ftp/sendmail/. DISTFILES=sendmail.${VER}.tar.Z sendmail.${VER}.tar.gz \ RELEASE_NOTES FAQ KNOWNBUGS diff --git a/usr.sbin/sendmail/cf/cf/Makefile.dist b/usr.sbin/sendmail/cf/cf/Makefile.dist deleted file mode 100644 index 07b62f2..0000000 --- a/usr.sbin/sendmail/cf/cf/Makefile.dist +++ /dev/null @@ -1,85 +0,0 @@ -# -# Makefile for configuration files. -# -# @(#)Makefile.dist 8.1 (Berkeley) 8/25/93 - -M4= m4 -#M4= /usr/src/usr.bin/m4/obj/m4 -CHMOD= chmod -ROMODE= 444 -RM= rm -f - -.SUFFIXES: .mc .cf - -.mc.cf: - $(RM) $@ - $(M4) $*.mc > $@ - $(CHMOD) $(ROMODE) $@ - -ALL= cs-hidden.cf cs-exposed.cf \ - hpux-cs-exposed.cf hpux-cs-hidden.cf \ - sunos3.5-cs-exposed.cf sunos3.5-cs-hidden.cf \ - sunos4.1-cs-exposed.cf sunos4.1-cs-hidden.cf \ - ultrix4.1-cs-exposed.cf ultrix4.1-cs-hidden.cf \ - mail.cs.cf mail.eecs.cf ucbvax.cf vangogh.cf \ - chez.cf knecht.cf cogsci.cf alpha.cf s2k.cf auspex.cf \ - python.cf \ - clientproto.cf tcpproto.cf uucpproto.cf - -all: $(ALL) - -clean cleandir: - $(RM) $(ALL) core - -depend install: - -# this is overkill, but.... -M4FILES=\ - ../domain/Berkeley.m4 \ - ../domain/cs.exposed.m4 \ - ../domain/cs.hidden.m4 \ - ../domain/eecs.hidden.m4 \ - ../domain/s2k.m4 \ - ../feature/allmasquerade.m4 \ - ../feature/always_add_domain.m4 \ - ../feature/bitdomain.m4 \ - ../feature/domaintable.m4 \ - ../feature/mailertable.m4 \ - ../feature/nocanonify.m4 \ - ../feature/nodns.m4 \ - ../feature/notsticky.m4 \ - ../feature/nouucp.m4 \ - ../feature/nullclient.m4 \ - ../feature/redirect.m4 \ - ../feature/use_cw_file.m4 \ - ../feature/uucpdomain.m4 \ - ../hack/cssubdomain.m4 \ - ../m4/cf.m4 \ - ../m4/nullrelay.m4 \ - ../m4/proto.m4 \ - ../m4/version.m4 \ - ../mailer/fax.m4 \ - ../mailer/local.m4 \ - ../mailer/smtp.m4 \ - ../mailer/usenet.m4 \ - ../mailer/uucp.m4 \ - ../ostype/aix3.m4 \ - ../ostype/bsd4.3.m4 \ - ../ostype/bsd4.4.m4 \ - ../ostype/hpux.m4 \ - ../ostype/irix.m4 \ - ../ostype/linux.m4 \ - ../ostype/nextstep.m4 \ - ../ostype/osf1.m4 \ - ../ostype/riscos4.5.m4 \ - ../ostype/solaris2.m4 \ - ../ostype/sunos3.5.m4 \ - ../ostype/sunos4.1.m4 \ - ../ostype/svr4.m4 \ - ../ostype/ultrix4.1.m4 \ - ../siteconfig/uucp.cogsci.m4 \ - ../siteconfig/uucp.old.arpa.m4 \ - ../siteconfig/uucp.ucbarpa.m4 \ - ../siteconfig/uucp.ucbvax.m4 \ - -$(ALL): $(M4FILES) diff --git a/usr.sbin/sendmail/cf/cf/alpha.mc b/usr.sbin/sendmail/cf/cf/alpha.mc deleted file mode 100644 index 026fed1..0000000 --- a/usr.sbin/sendmail/cf/cf/alpha.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)alpha.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(osf1)dnl -DOMAIN(s2k)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/auspex.mc b/usr.sbin/sendmail/cf/cf/auspex.mc deleted file mode 100644 index 961c139..0000000 --- a/usr.sbin/sendmail/cf/cf/auspex.mc +++ /dev/null @@ -1,42 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)auspex.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(sunos4.1)dnl -DOMAIN(cs.hidden)dnl -FEATURE(use_cw_file)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/chez.mc b/usr.sbin/sendmail/cf/cf/chez.mc deleted file mode 100644 index 13f9519..0000000 --- a/usr.sbin/sendmail/cf/cf/chez.mc +++ /dev/null @@ -1,44 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)chez.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(bsd4.4)dnl -DOMAIN(cs.exposed)dnl -define(`LOCAL_RELAY', vangogh.CS.Berkeley.EDU)dnl -define(`MASQUERADE_NAME', vangogh.CS.Berkeley.EDU)dnl -MAILER(local)dnl -MAILER(smtp)dnl -Fw/etc/sendmail.cw diff --git a/usr.sbin/sendmail/cf/cf/cogsci.mc b/usr.sbin/sendmail/cf/cf/cogsci.mc deleted file mode 100644 index 4faa46d..0000000 --- a/usr.sbin/sendmail/cf/cf/cogsci.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)cogsci.mc 8.1 (Berkeley) 6/7/93') -DOMAIN(cs.exposed)dnl -MAILER(smtp)dnl -MAILER(uucp)dnl -SITECONFIG(uucp.cogsci, Ucogsci, U) diff --git a/usr.sbin/sendmail/cf/cf/cs-exposed.mc b/usr.sbin/sendmail/cf/cf/cs-exposed.mc deleted file mode 100644 index 62072b7..0000000 --- a/usr.sbin/sendmail/cf/cf/cs-exposed.mc +++ /dev/null @@ -1,40 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)cs-exposed.mc 8.1 (Berkeley) 6/7/93') -DOMAIN(cs.exposed)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/cs-hidden.mc b/usr.sbin/sendmail/cf/cf/cs-hidden.mc deleted file mode 100644 index 216062c..0000000 --- a/usr.sbin/sendmail/cf/cf/cs-hidden.mc +++ /dev/null @@ -1,40 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)cs-hidden.mc 8.1 (Berkeley) 6/7/93') -DOMAIN(cs.hidden)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/hpux-cs-exposed.mc b/usr.sbin/sendmail/cf/cf/hpux-cs-exposed.mc deleted file mode 100644 index 4f61ffd..0000000 --- a/usr.sbin/sendmail/cf/cf/hpux-cs-exposed.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)hpux-cs-exposed.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(hpux)dnl -DOMAIN(cs.exposed)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/hpux-cs-hidden.mc b/usr.sbin/sendmail/cf/cf/hpux-cs-hidden.mc deleted file mode 100644 index 33cf580..0000000 --- a/usr.sbin/sendmail/cf/cf/hpux-cs-hidden.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)hpux-cs-hidden.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(hpux)dnl -DOMAIN(cs.hidden)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/knecht.mc b/usr.sbin/sendmail/cf/cf/knecht.mc deleted file mode 100644 index 0cd17fa..0000000 --- a/usr.sbin/sendmail/cf/cf/knecht.mc +++ /dev/null @@ -1,44 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)knecht.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(ultrix4.1)dnl -DOMAIN(cs.exposed)dnl -define(`LOCAL_RELAY', CS.Berkeley.EDU)dnl -MAILER(smtp)dnl - -# our local domain -DDCS.Berkeley.EDU diff --git a/usr.sbin/sendmail/cf/cf/osf1-cs-exposed.mc b/usr.sbin/sendmail/cf/cf/osf1-cs-exposed.mc deleted file mode 100644 index eaed6cc..0000000 --- a/usr.sbin/sendmail/cf/cf/osf1-cs-exposed.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)osf1-cs-exposed.mc 8.1 (Berkeley) 10/15/93') -OSTYPE(osf1)dnl -DOMAIN(cs.exposed)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/osf1-cs-hidden.mc b/usr.sbin/sendmail/cf/cf/osf1-cs-hidden.mc deleted file mode 100644 index 2b85ba4..0000000 --- a/usr.sbin/sendmail/cf/cf/osf1-cs-hidden.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)osf1-cs-hidden.mc 8.1 (Berkeley) 10/15/93') -OSTYPE(osf1)dnl -DOMAIN(cs.hidden)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/python.mc b/usr.sbin/sendmail/cf/cf/python.mc deleted file mode 100644 index ac23e61..0000000 --- a/usr.sbin/sendmail/cf/cf/python.mc +++ /dev/null @@ -1,52 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)python.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(bsd4.4)dnl -DOMAIN(cs.exposed)dnl -define(`LOCAL_RELAY', vangogh.CS.Berkeley.EDU)dnl -define(`MASQUERADE_NAME', vangogh.CS.Berkeley.EDU)dnl -MAILER(local)dnl -MAILER(smtp)dnl - -# accept mail sent to the domain head -DDBostic.COM - -LOCAL_RULE_0 -# accept mail sent to the domain head -R< @ $D . > : $* $@ $>7 $1 @here:... -> ... -R$* $=O $* < @ $D . > $@ $>7 $1 $2 $3 ...@here -> ... -R$* < @ $D . > $#local $: $1 user@here -> user diff --git a/usr.sbin/sendmail/cf/cf/riscos-cs-exposed.mc b/usr.sbin/sendmail/cf/cf/riscos-cs-exposed.mc deleted file mode 100644 index a92b770..0000000 --- a/usr.sbin/sendmail/cf/cf/riscos-cs-exposed.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)riscos-cs-exposed.mc 8.1 (Berkeley) 12/1/93') -OSTYPE(riscos4.5)dnl -DOMAIN(cs.exposed)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/s2k.mc b/usr.sbin/sendmail/cf/cf/s2k.mc deleted file mode 100644 index e65fc9f..0000000 --- a/usr.sbin/sendmail/cf/cf/s2k.mc +++ /dev/null @@ -1,42 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)s2k.mc 8.1 (Berkeley) 6/7/93') -OLDSENDMAIL -OSTYPE(ultrix4.1)dnl -DOMAIN(s2k)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/sample.mc b/usr.sbin/sendmail/cf/cf/sample.mc deleted file mode 100644 index 760409d..0000000 --- a/usr.sbin/sendmail/cf/cf/sample.mc +++ /dev/null @@ -1,40 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)sample.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(bsd4.4) -DOMAIN(cs.hidden) -MAILER(smtp) diff --git a/usr.sbin/sendmail/cf/cf/sleepy.mc b/usr.sbin/sendmail/cf/cf/sleepy.mc deleted file mode 100644 index ff6a7cd..0000000 --- a/usr.sbin/sendmail/cf/cf/sleepy.mc +++ /dev/null @@ -1,43 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(@(#)sleepy.mc 8.1 (Berkeley) 6/7/93) -OSTYPE(hpux)dnl -DOMAIN(cs.exposed)dnl -define(`LOCAL_RELAY', diva.Berkeley.EDU)dnl -define(`MASQUERADE_NAME', diva.Berkeley.EDU)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/sunos3.5-cs-exposed.mc b/usr.sbin/sendmail/cf/cf/sunos3.5-cs-exposed.mc deleted file mode 100644 index 46d04d9..0000000 --- a/usr.sbin/sendmail/cf/cf/sunos3.5-cs-exposed.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)sunos3.5-cs-exposed.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(sunos3.5)dnl -DOMAIN(cs.exposed)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/sunos3.5-cs-hidden.mc b/usr.sbin/sendmail/cf/cf/sunos3.5-cs-hidden.mc deleted file mode 100644 index a3d6f20..0000000 --- a/usr.sbin/sendmail/cf/cf/sunos3.5-cs-hidden.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)sunos3.5-cs-hidden.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(sunos3.5)dnl -DOMAIN(cs.hidden)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/sunos4.1-cs-exposed.mc b/usr.sbin/sendmail/cf/cf/sunos4.1-cs-exposed.mc deleted file mode 100644 index 7c94ba5..0000000 --- a/usr.sbin/sendmail/cf/cf/sunos4.1-cs-exposed.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)sunos4.1-cs-exposed.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(sunos4.1)dnl -DOMAIN(cs.exposed)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/sunos4.1-cs-hidden.mc b/usr.sbin/sendmail/cf/cf/sunos4.1-cs-hidden.mc deleted file mode 100644 index 8e1dbb9..0000000 --- a/usr.sbin/sendmail/cf/cf/sunos4.1-cs-hidden.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)sunos4.1-cs-hidden.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(sunos4.1)dnl -DOMAIN(cs.hidden)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/udb.mc b/usr.sbin/sendmail/cf/cf/udb.mc deleted file mode 100644 index 624d2d4..0000000 --- a/usr.sbin/sendmail/cf/cf/udb.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)udb.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(sunos4.1)dnl -DOMAIN(cs.hidden)dnl -MAILER(smtp)dnl -define(`USERDB_FILE', `/home/auspex/a/staff/gnn/UDB/UI')dnl diff --git a/usr.sbin/sendmail/cf/cf/ultrix4.1-cs-exposed.mc b/usr.sbin/sendmail/cf/cf/ultrix4.1-cs-exposed.mc deleted file mode 100644 index 093590f..0000000 --- a/usr.sbin/sendmail/cf/cf/ultrix4.1-cs-exposed.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)ultrix4.1-cs-exposed.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(ultrix4.1)dnl -DOMAIN(cs.exposed)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/ultrix4.1-cs-hidden.mc b/usr.sbin/sendmail/cf/cf/ultrix4.1-cs-hidden.mc deleted file mode 100644 index ea25375..0000000 --- a/usr.sbin/sendmail/cf/cf/ultrix4.1-cs-hidden.mc +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)ultrix4.1-cs-hidden.mc 8.1 (Berkeley) 6/7/93') -OSTYPE(ultrix4.1)dnl -DOMAIN(cs.hidden)dnl -MAILER(local)dnl -MAILER(smtp)dnl diff --git a/usr.sbin/sendmail/cf/cf/vangogh.mc b/usr.sbin/sendmail/cf/cf/vangogh.mc deleted file mode 100644 index 2406364..0000000 --- a/usr.sbin/sendmail/cf/cf/vangogh.mc +++ /dev/null @@ -1,44 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -include(`../m4/cf.m4') -VERSIONID(`@(#)vangogh.mc 8.2 (Berkeley) 1/26/94') -DOMAIN(cs.exposed)dnl -OSTYPE(bsd4.4)dnl -MAILER(local)dnl -MAILER(smtp)dnl -define(`MCI_CACHE_SIZE', 5) -Cw okeeffe.CS.Berkeley.EDU -Cw python.CS.Berkeley.EDU diff --git a/usr.sbin/sendmail/cf/domain/Berkeley.m4 b/usr.sbin/sendmail/cf/domain/Berkeley.m4 deleted file mode 100644 index 4f572d6..0000000 --- a/usr.sbin/sendmail/cf/domain/Berkeley.m4 +++ /dev/null @@ -1,42 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# -divert(0) -VERSIONID(`@(#)Berkeley.m4 8.5 (Berkeley) 2/18/94') -define(`UUCP_RELAY', `ucbvax.Berkeley.EDU')dnl -define(`BITNET_RELAY', `CMSA.Berkeley.EDU')dnl -define(`confFORWARD_PATH', `$z/.forward.$w:$z/.forward')dnl -define(`confCW_FILE', `-o /etc/sendmail.cw')dnl -FEATURE(redirect)dnl -FEATURE(use_cw_file)dnl diff --git a/usr.sbin/sendmail/cf/domain/cs.exposed.m4 b/usr.sbin/sendmail/cf/domain/cs.exposed.m4 deleted file mode 100644 index 43c07be..0000000 --- a/usr.sbin/sendmail/cf/domain/cs.exposed.m4 +++ /dev/null @@ -1,40 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# -divert(0) -VERSIONID(`@(#)cs.exposed.m4 8.1 (Berkeley) 6/7/93') -DOMAIN(Berkeley)dnl -HACK(cssubdomain)dnl -define(`confUSERDB_SPEC', - `/usr/sww/share/lib/users.cs.db,/usr/sww/share/lib/users.eecs.db')dnl diff --git a/usr.sbin/sendmail/cf/domain/cs.hidden.m4 b/usr.sbin/sendmail/cf/domain/cs.hidden.m4 deleted file mode 100644 index 3d9721a..0000000 --- a/usr.sbin/sendmail/cf/domain/cs.hidden.m4 +++ /dev/null @@ -1,38 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# -divert(0) -VERSIONID(`@(#)cs.hidden.m4 8.1 (Berkeley) 6/7/93') -DOMAIN(cs.exposed)dnl -MASQUERADE_AS(CS.Berkeley.EDU)dnl diff --git a/usr.sbin/sendmail/cf/domain/eecs.hidden.m4 b/usr.sbin/sendmail/cf/domain/eecs.hidden.m4 deleted file mode 100644 index bbdc01a..0000000 --- a/usr.sbin/sendmail/cf/domain/eecs.hidden.m4 +++ /dev/null @@ -1,38 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# -divert(0) -VERSIONID(`@(#)eecs.hidden.m4 8.1 (Berkeley) 6/7/93') -DOMAIN(Berkeley)dnl -MASQUERADE_AS(EECS.Berkeley.EDU)dnl diff --git a/usr.sbin/sendmail/cf/domain/s2k.m4 b/usr.sbin/sendmail/cf/domain/s2k.m4 deleted file mode 100644 index 25b931f..0000000 --- a/usr.sbin/sendmail/cf/domain/s2k.m4 +++ /dev/null @@ -1,38 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# -divert(0) -VERSIONID(`@(#)s2k.m4 8.1 (Berkeley) 6/7/93') -DOMAIN(cs.exposed)dnl -MASQUERADE_AS(postgres.Berkeley.EDU)dnl diff --git a/usr.sbin/sendmail/cf/ostype/hpux.m4 b/usr.sbin/sendmail/cf/ostype/hpux.m4 deleted file mode 100644 index 1be21f3..0000000 --- a/usr.sbin/sendmail/cf/ostype/hpux.m4 +++ /dev/null @@ -1,44 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -divert(0) -VERSIONID(`@(#)hpux.m4 8.5 (Berkeley) 1/9/94') - -define(`QUEUE_DIR', /usr/spool/mqueue)dnl -define(`ALIAS_FILE', /usr/lib/aliases)dnl -define(`STATUS_FILE', /usr/lib/sendmail.st)dnl -define(`LOCAL_MAILER_FLAGS', `m')dnl -define(`UUCP_MAILER_ARGS', `uux - -r -a$f -gC $h!rmail ($u)')dnl -define(`confTIME_ZONE', `USE_TZ')dnl diff --git a/usr.sbin/sendmail/cf/ostype/irix.m4 b/usr.sbin/sendmail/cf/ostype/irix.m4 deleted file mode 100644 index 6cd7fc9..0000000 --- a/usr.sbin/sendmail/cf/ostype/irix.m4 +++ /dev/null @@ -1,41 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -divert(0) -VERSIONID(`@(#)irix.m4 8.4 (Berkeley) 2/1/94') -define(`LOCAL_MAILER_FLAGS', Ehm)dnl -define(`QUEUE_DIR', /usr/spool/mqueue)dnl -define(`ALIAS_FILE', /usr/lib/aliases)dnl -define(`STATUS_FILE', /usr/lib/sendmail.st)dnl diff --git a/usr.sbin/sendmail/cf/ostype/ultrix4.1.m4 b/usr.sbin/sendmail/cf/ostype/ultrix4.1.m4 deleted file mode 100644 index 87c4425..0000000 --- a/usr.sbin/sendmail/cf/ostype/ultrix4.1.m4 +++ /dev/null @@ -1,38 +0,0 @@ -divert(-1) -# -# Copyright (c) 1983 Eric P. Allman -# Copyright (c) 1988, 1993 -# The Regents of the University of California. All rights reserved. -# -# 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. -# - -divert(0) -VERSIONID(`@(#)ultrix4.1.m4 8.1 (Berkeley) 6/7/93') -ifdef(`_OLD_SENDMAIL_', `define(`NEED_DOMAIN', `')')dnl diff --git a/usr.sbin/sendmail/doc/Makefile b/usr.sbin/sendmail/doc/Makefile deleted file mode 100644 index fc9dc19..0000000 --- a/usr.sbin/sendmail/doc/Makefile +++ /dev/null @@ -1,5 +0,0 @@ -# @(#)Makefile 8.1 (Berkeley) 6/7/93 - -SUBDIR= op intro usenix - -.include diff --git a/usr.sbin/sendmail/doc/op/spell.ok b/usr.sbin/sendmail/doc/op/spell.ok deleted file mode 100644 index d1cb19e..0000000 --- a/usr.sbin/sendmail/doc/op/spell.ok +++ /dev/null @@ -1,324 +0,0 @@ -AA06698 -AA06703 -AA22757 -AA22777 -AA99999 -ACHECK -ARPANET -AVENRUN -Allman -Arpa -Arpanet -BSD -BSD4.4 -BTree -Bcc -BitNET -CHmonet -CHucbmonet -CNAME -CS.Berkeley.EDU -Cdaemon -Ceric -Cnt -Ctest.cf -DB -DLA -DdfAA13557 -Dj -DlFrom -DnMAILER -Dq -EDU -EOH -EXPN -Eol -Eowner -Eric.Allman -FAX -FSCALE -Fri -GECOS -Guide''SMM:07 -H?F?from -H?P?return -H?x?full -HELO -HTo -HdrInfo -HiTech.COM -Hmessage -Hreceived -Hsubject -INT -IP -IPC -Jul -Kmapname -LAN -LHS -LOCKF -Linelimit -LocalMailer -MATCHGECOS -MAXATOM -MAXHOP -MAXLINE -MAXMAILERS -MAXMXHOSTS -MAXNAME -MAXPRIORITIES -MAXPV -MAXRWSETS -MAXTRUST -MAXUSERENVIRON -MX -Makefile -Makefile.dist -Maxsize -Meta -Mether -Mlocal -MsgSize -NEWDB -NIS -NOOP -NOTUNIX -NoReturn -OJ -OSTYPE -OT3d -PSyserr -Pfirst -Pjunk -Pspecial -QUEUESIZE -RCPT -README -RFC -RFC's -RFC1123 -RFC819 -RFC821 -RFC822 -RHS -Rbostic -Reric -Ruleset -Rulesets -S,D -SETPROCTITLE -SITECONFIG -SMM:07 -SMTP -SUBR -SYS5TZ -SYSTEM5 -Seric -TCP -TSyserr -UCBARPA -UCBARPA:eric -UGLYUUCP -USERDB -Ucbvax -Ultrix3.0 -Usrerr -VRFY -Wildcard -YP -a.CC.Berkeley.EDU -aliases.db -aliases.dir -aliases.pag -args -automounter -av -avenrun -bd -behaviour -bi -bollard -bool -bostic -bp -bt -btree -buf -bufsize -bz -c70:user -calder -canonification -checkcompat -cnt -conf.c -conf.h -contessa -cs -cs.exposed.m4 -cs.hidden.m4 -csam -csam.arpa -cw -daemon.c -db -decvax -default:mailname -delivermail -dev -dir -doc -ef -email -eric -eric:mailname -ernie -errno -fallback -fax -fi -filename -filenames -fo -foo.bar.baz.de -fullname -gateway.HiTech.COM -getla -getloadavg -groupid -hdrinfo -hname -hoptoad -host.domain -hosta -hostb -htemplate -ie -iff -int -ip -lbl -lf -lhs -lib -lnx -localhost -lockf -lp -mail.CS.Berkeley.EDU -mail.cf -maildrop -mailname -mailq -mailstats -mailstats.c -makemap -mammoth.Berkeley.EDU -mammoth.Berkeley.EDU.HiTech.COM -mapclass -maphostname -mapname -matisse -mc -mckusick -meC -mflags -monet -monet:bollard -mqueue -msg -name1 -name2 -nameserver -newalias -nkainc -nosuchuser -num -oM -oQ -oT1d -oT2m -okeeffe.CS.Berkeley.EDU -omqueue -ostype -pUUCP:uunet -pag -pag,dir -pathname -pathnames -pathnames.h -pid -pp -prep.ai.MIT.EDU -prog -q30m -qf -querytype -queueups -rc.local -resolv.conf -rfc819.lpr -rfc822.lpr -rhs -rlsm -ruleset -rulesets -rwset -rwsets -sam -sbin -sendmail.cf -sendmail.cw -sendmail.fc -sendmail.hf -sendmail.st -setupmaps -si -site.config.file -siteconfig -smtp -sp -src -suid -syserr -sysname -tcpproto.mc -test.cf -text1 -text2 -tf -timestamp -timestamps -ucb -ucbarpa -ucblib -ucbmonet -ucbvax -ucbvax.mc -udbspec -user1 -user2 -usera -userb -userc -userid -username -usrerr -uucpproto.mc -uunet -val -vangogh.CS.Berkeley.EDU -vangogh.berkeley.edu -var -vikki -voyeurism -wildcard -wildcards -wnj -word1 -word2 -xf -xxx -xyzvax -yp diff --git a/usr.sbin/sendmail/doc/rfc/rfc819.txt b/usr.sbin/sendmail/doc/rfc/rfc819.txt deleted file mode 100644 index d66f8d9..0000000 --- a/usr.sbin/sendmail/doc/rfc/rfc819.txt +++ /dev/null @@ -1,1044 +0,0 @@ - - -Network Working Group Zaw-Sing Su (SRI) -Request for Comments: 819 Jon Postel (ISI) - August 1982 - - - - The Domain Naming Convention for Internet User Applications - - - - -1. Introduction - - For many years, the naming convention "@" has served the - ARPANET user community for its mail system, and the substring - "" has been used for other applications such as file transfer - (FTP) and terminal access (Telnet). With the advent of network - interconnection, this naming convention needs to be generalized to - accommodate internetworking. A decision has recently been reached to - replace the simple name field, "", by a composite name field, - "" [2]. This note is an attempt to clarify this generalized - naming convention, the Internet Naming Convention, and to explore the - implications of its adoption for Internet name service and user - applications. - - The following example illustrates the changes in naming convention: - - ARPANET Convention: Fred@ISIF - Internet Convention: Fred@F.ISI.ARPA - - The intent is that the Internet names be used to form a - tree-structured administrative dependent, rather than a strictly - topology dependent, hierarchy. The left-to-right string of name - components proceeds from the most specific to the most general, that - is, the root of the tree, the administrative universe, is on the - right. - - The name service for realizing the Internet naming convention is - assumed to be application independent. It is not a part of any - particular application, but rather an independent name service serves - different user applications. - -2. The Structural Model - - The Internet naming convention is based on the domain concept. The - name of a domain consists of a concatenation of one or more . A domain can be considered as a region of jurisdiction for - name assignment and of responsibility for name-to-address - translation. The set of domains forms a hierarchy. - - Using a graph theory representation, this hierarchy may be modeled as - a directed graph. A directed graph consists of a set of nodes and a - - -Su & Postel [Page 1] - - - -RFC 819 August 1982; - - - collection of arcs, where arcs are identified by ordered pairs of - distinct nodes [1]. Each node of the graph represents a domain. An - ordered pair (B, A), an arc from B to A, indicates that B is a - subdomain of domain A, and B is a simple name unique within A. We - will refer to B as a child of A, and A a parent of B. The directed - graph that best describes the naming hierarchy is called an - "in-tree", which is a rooted tree with all arcs directed towards the - root (Figure 1). The root of the tree represents the naming universe, - ancestor of all domains. Endpoints (or leaves) of the tree are the - lowest-level domains. - - U - / | \ - / | \ U -- Naming Universe - ^ ^ ^ I -- Intermediate Domain - | | | E -- Endpoint Domain - I E I - / \ | - ^ ^ ^ - | | | - E E I - / | \ - ^ ^ ^ - | | | - E E E - - Figure 1 - The In-Tree Model for Domain Hierarchy - - The simple name of a child in this model is necessarily unique within - its parent domain. Since the simple name of the child's parent is - unique within the child's grandparent domain, the child can be - uniquely named in its grandparent domain by the concatenation of its - simple name followed by its parent's simple name. - - For example, if the simple name of a child is "C1" then no other - child of the same parent may be named "C1". Further, if the - parent of this child is named "P1", then "P1" is a unique simple - name in the child's grandparent domain. Thus, the concatenation - C1.P1 is unique in C1's grandparent domain. - - Similarly, each element of the hierarchy is uniquely named in the - universe by its complete name, the concatenation of its simple name - and those for the domains along the trail leading to the naming - universe. - - The hierarchical structure of the Internet naming convention supports - decentralization of naming authority and distribution of name service - capability. We assume a naming authority and a name server - - -Su & Postel [Page 2] - - - -RFC 819 August 1982; - - - associated with each domain. In Sections 5 and 6 respectively the - name service and the naming authority are discussed. - - Within an endpoint domain, unique names are assigned to - representing user mailboxes. User mailboxes may be viewed as - children of their respective domains. - - In reality, anomalies may exist violating the in-tree model of naming - hierarchy. Overlapping domains imply multiple parentage, i.e., an - entity of the naming hierarchy being a child of more than one domain. - It is conceivable that ISI can be a member of the ARPA domain as well - as a member of the USC domain (Figure 2). Such a relation - constitutes an anomaly to the rule of one-connectivity between any - two points of a tree. The common child and the sub-tree below it - become descendants of both parent domains. - - U - / | \ - / . \ - . . ARPA - . . | \ - USC | \ - \ | . - \ | . - ISI - - Figure 2 - Anomaly in the In-Tree Model - - Some issues resulting from multiple parentage are addressed in - Appendix B. The general implications of multiple parentage are a - subject for further investigation. - -3. Advantage of Absolute Naming - - Absolute naming implies that the (complete) names are assigned with - respect to a universal reference point. The advantage of absolute - naming is that a name thus assigned can be universally interpreted - with respect to the universal reference point. The Internet naming - convention provides absolute naming with the naming universe as its - universal reference point. - - For relative naming, an entity is named depending upon the position - of the naming entity relative to that of the named entity. A set of - hosts running the "unix" operating system exchange mail using a - method called "uucp". The naming convention employed by uucp is an - example of relative naming. The mail recipient is typically named by - a source route identifying a chain of locally known hosts linking the - - - -Su & Postel [Page 3] - - - -RFC 819 August 1982; - - - sender's host to the recipient's. A destination name can be, for - example, - - "alpha!beta!gamma!john", - - where "alpha" is presumably known to the originating host, "beta" is - known to "alpha", and so on. - - The uucp mail system has demonstrated many of the problems inherent - to relative naming. When the host names are only locally - interpretable, routing optimization becomes impossible. A reply - message may have to traverse the reverse route to the original sender - in order to be forwarded to other parties. - - Furthermore, if a message is forwarded by one of the original - recipients or passed on as the text of another message, the frame of - reference of the relative source route can be completely lost. Such - relative naming schemes have severe problems for many of the uses - that we depend upon in the ARPA Internet community. - -4. Interoperability - - To allow interoperation with a different naming convention, the names - assigned by a foreign naming convention need to be accommodated. - Given the autonomous nature of domains, a foreign naming environment - may be incorporated as a domain anywhere in the hierarchy. Within - the naming universe, the name service for a domain is provided within - that domain. Thus, a foreign naming convention can be independent of - the Internet naming convention. What is implied here is that no - standard convention for naming needs to be imposed to allow - interoperations among heterogeneous naming environments. - - For example: - - There might be a naming convention, say, in the FOO world, - something like "%%". Communications with an - entity in that environment can be achieved from the Internet - community by simply appending ".FOO" on the end of the name in - that foreign convention. - - John%ISI-Tops20-7%California.FOO - - Another example: - - One way of accommodating the "uucp world" described in the last - section is to declare it as a foreign system. Thus, a uucp - name - - "alpha!beta!gamma!john" - - -Su & Postel [Page 4] - - - -RFC 819 August 1982; - - - might be known in the Internet community as - - "alpha!beta!gamma!john.UUCP". - - Communicating with a complex subdomain is another case which can - be treated as interoperation. A complex subdomain is a domain - with complex internal naming structure presumably unknown to the - outside world (or the outside world does not care to be concerned - with its complexity). - - For the mail system application, the names embedded in the message - text are often used by the destination for such purpose as to reply - to the original message. Thus, the embedded names may need to be - converted for the benefit of the name server in the destination - environment. - - Conversion of names on the boundary between heterogeneous naming - environments is a complex subject. The following example illustrates - some of the involved issues. - - For example: - - A message is sent from the Internet community to the FOO - environment. It may bear the "From" and "To" fields as: - - From: Fred@F.ISI.ARPA - To: John%ISI-Tops20-7%California.FOO - - where "FOO" is a domain independent of the Internet naming - environment. The interface on the boundary of the two - environments may be represented by a software module. We may - assume this interface to be an entity of the Internet community - as well as an entity of the FOO community. For the benefit of - the FOO environment, the "From" and "To" fields need to be - modified upon the message's arrival at the boundary. One may - view naming as a separate layer of protocol, and treat - conversion as a protocol translation. The matter is - complicated when the message is sent to more than one - destination within different naming environments; or the - message is destined within an environment not sharing boundary - with the originating naming environment. - - While the general subject concerning conversion is beyond the scope - of this note, a few questions are raised in Appendix D. - - - - - - - -Su & Postel [Page 5] - - - -RFC 819 August 1982; - - -5. Name Service - - Name service is a network service providing name-to-address - translation. Such service may be achieved in a number of ways. For - a simple networking environment, it can be accomplished with a single - central database containing name-to-address correspondence for all - the pertinent network entities, such as hosts. - - In the case of the old ARPANET host names, a central database is - duplicated in each individual host. The originating module of an - application process would query the local name service (e.g., make a - system call) to obtain network address for the destination host. With - the proliferation of networks and an accelerating increase in the - number of hosts participating in networking, the ever growing size, - update frequency, and the dissemination of the central database makes - this approach unmanageable. - - The hierarchical structure of the Internet naming convention supports - decentralization of naming authority and distribution of name service - capability. It readily accommodates growth of the naming universe. - It allows an arbitrary number of hierarchical layers. The addition - of a new domain adds little complexity to an existing Internet - system. - - The name service at each domain is assumed to be provided by one or - more name servers. There are two models for how a name server - completes its work, these might be called "iterative" and - "recursive". - - For an iterative name server there may be two kinds of responses. - The first kind of response is a destination address. The second - kind of response is the address of another name server. If the - response is a destination address, then the query is satisfied. If - the response is the address of another name server, then the query - must be repeated using that name server, and so on until a - destination address is obtained. - - For a recursive name server there is only one kind of response -- - a destination address. This puts an obligation on the name server - to actually make the call on another name server if it can't - answer the query itself. - - It is noted that looping can be avoided since the names presented for - translation can only be of finite concatenation. However, care - should be taken in employing mechanisms such as a pointer to the next - simple name for resolution. - - We believe that some name servers will be recursive, but we don't - believe that all will be. This means that the caller must be - - -Su & Postel [Page 6] - - - -RFC 819 August 1982; - - - prepared for either type of server. Further discussion and examples - of name service is given in Appendix C. - - The basic name service at each domain is the translation of simple - names to addresses for all of its children. However, if only this - basic name service is provided, the use of complete (or fully - qualified) names would be required. Such requirement can be - unreasonable in practice. Thus, we propose the use of partial names - in the context in which their uniqueness is preserved. By - construction, naming uniqueness is preserved within the domain of a - common ancestry. Thus, a partially qualified name is constructed by - omitting from the complete name ancestors common to the communicating - parties. When a partially qualified name leaves its context of - uniqueness it must be additionally qualified. - - The use of partially qualified names places a requirement on the - Internet name service. To satisfy this requirement, the name service - at each domain must be capable of, in addition to the basic service, - resolving simple names for all of its ancestors (including itself) - and their children. In Appendix B, the required distinction among - simple names for such resolution is addressed. - -6. Naming Authority - - Associated with each domain there must be a naming authority to - assign simple names and ensure proper distinction among simple names. - - Note that if the use of partially qualified names is allowed in a - sub-domain, the uniqueness of simple names inside that sub-domain is - insufficient to avoid ambiguity with names outside the subdomain. - Appendix B discusses simple name assignment in a sub-domain that - would allow the use of partially qualified names without ambiguity. - - Administratively, associated with each domain there is a single - person (or office) called the registrar. The registrar of the naming - universe specifies the top-level set of domains and designates a - registrar for each of these domains. The registrar for any given - domain maintains the naming authority for that domain. - -7. Network-Oriented Applications - - For user applications such as file transfer and terminal access, the - remote host needs to be named. To be compatible with ARPANET naming - convention, a host can be treated as an endpoint domain. - - Many operating systems or programming language run-time environments - provide functions or calls (JSYSs, SVCs, UUOs, SYSs, etc.) for - standard services (e.g., time-of-day, account-of-logged-in-user, - convert-number-to-string). It is likely to be very helpful if such a - - -Su & Postel [Page 7] - - - -RFC 819 August 1982; - - - function or call is developed for translating a host name to an - address. Indeed, several systems on the ARPANET already have such - facilities for translating an ARPANET host name into an ARPANET - address based on internal tables. - - We recommend that this provision of a standard function or call for - translating names to addresses be extended to accept names of - Internet convention. This will promote a consistent interface to the - users of programs involving internetwork activities. The standard - facility for translating Internet names to Internet addresses should - include all the mechanisms available on the host, such as checking a - local table or cache of recently checked names, or consulting a name - server via the Internet. - -8. Mail Relaying - - Relaying is a feature adopted by more and more mail systems. - Relaying facilitates, among other things, interoperations between - heterogeneous mail systems. The term "relay" is used to describe the - situation where a message is routed via one or more intermediate - points between the sender and the recipient. The mail relays are - normally specified explicitly as relay points in the instructions for - message delivery. Usually, each of the intermediate relays assume - responsibility for the relayed message [3]. - - A point should be made on the basic difference between mail - relaying and the uucp naming system. The difference is that - although mail relaying with absolute naming can also be considered - as a form of source routing, the names of each intermediate points - and that of the destination are universally interpretable, while - the host names along a source route of the uucp convention is - relative and thus only locally interpretable. - - The Internet naming convention explicitly allows interoperations - among heterogeneous systems. This implies that the originator of a - communication may name a destination which resides in a foreign - system. The probability is that the destination network address may - not be comprehensible to the transport system of the originator. - Thus, an implicit relaying mechanism is called for at the boundary - between the domains. The function of this implicit relay is the same - as the explicit relay. - - - - - - - - - - -Su & Postel [Page 8] - - - -RFC 819 August 1982; - - -9. Implementation - - The Actual Domains - - The initial set of top-level names include: - - ARPA - - This represents the set of organizations involved in the - Internet system through the authority of the U.S. Defense - Advanced Research Projects Agency. This includes all the - research and development hosts on the ARPANET and hosts on - many other nets as well. But note very carefully that the - top-level domain "ARPA" does not map one-to-one with the - ARPANET -- domains are administrative, not topological. - - Transition - - In the transition from the ARPANET naming convention to the - Internet naming convention, a host name may be used as a simple - name for an endpoint domain. Thus, if "USC-ISIF" is an ARPANET - host name, then "USC-ISIF.ARPA" is the name of an Internet domain. - -10. Summary - - A hierarchical naming convention based on the domain concept has been - adopted by the Internet community. It is an absolute naming - convention defined along administrative rather than topological - boundaries. This naming convention is adaptive for interoperations - with other naming conventions. Thus, no standard convention needs to - be imposed for interoperations among heterogeneous naming - environments. - - This Internet naming convention allows distributed name service and - naming authority functions at each domain. We have specified these - functions required at each domain. Also discussed are implications - on network-oriented applications, mail systems, and administrative - aspects of this convention. - - - - - - - - - - - - - -Su & Postel [Page 9] - - - -RFC 819 August 1982; - - -APPENDIX A - - The BNF Specification - - We present here a rather detailed "BNF" definition of the allowed - form for a computer mail "mailbox" composed of a "local-part" and a - "domain" (separated by an at sign). Clearly, the domain can be used - separately in other network-oriented applications. - - ::= "@" - - ::= | - - ::= | - - ::= """ """ - - ::= "\" | "\" | | - - ::= | "\" - - ::= | "." - - ::= |
- - ::= - - ::= | - - ::= | - - ::= | | "-" - -
:: = "#" | "[" "]" - - ::= | - - ::= "." "." "." - - ::= one, two, or three digits representing a decimal integer - value in the range 0 through 255 - - ::= any one of the 52 alphabetic characters A through Z in upper - case and a through z in lower case - - ::= any one of the 128 ASCII characters except or - - ::= any one of the ten digits 0 through 9 - - - -Su & Postel [Page 10] - - - -RFC 819 August 1982; - - - ::= any one of the 128 ASCII characters except CR, LF, quote ("), - or backslash (\) - - ::= any one of the 128 ASCII characters (no exceptions) - - ::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@", - """, and the control characters (ASCII codes 0 through 31 inclusive - and 127) - - Note that the backslash, "\", is a quote character, which is used to - indicate that the next character is to be used literally (instead of - its normal interpretation). For example, "Joe\,Smith" could be used - to indicate a single nine character user field with comma being the - fourth character of the field. - - The simple names that make up a domain may contain both upper and - lower case letters (as well as digits and hyphen), but these names - are not case sensitive. - - Hosts are generally known by names. Sometimes a host is not known to - the translation function and communication is blocked. To bypass - this barrier two forms of addresses are also allowed for host - "names". One form is a decimal integer prefixed by a pound sign, "#". - Another form, called "dotted decimal", is four small decimal integers - separated by dots and enclosed by brackets, e.g., "[123.255.37.2]", - which indicates a 32-bit ARPA Internet Address in four 8-bit fields. - (Of course, these numeric address forms are specific to the Internet, - other forms may have to be provided if this problem arises in other - transport systems.) - - - - - - - - - - - - - - - - - - - - - - -Su & Postel [Page 11] - - - -RFC 819 August 1982; - - -APPENDIX B - - An Aside on the Assignment of Simple Names - - In the following example, there are two naming hierarchies joining at - the naming universe 'U'. One consists of domains (S, R, N, J, P, Q, - B, A); and the other (L, E, F, G, H, D, C, K, B, A). Domain B is - assumed to have multiple parentage as shown. - - U - / \ - / \ - J L - / \ - N E - / \ / \ - R P D F - / \ | \ \ - S Q C (X) G - \ / \ \ - B K H - / - A - - Figure 3 - Illustration of Requirements for the Distinction of Simple Names - - Suppose someone at A tries to initiate communication with destination - H. The fully qualified destination name would be - - H.G.F.E.L.U - - Omitting common ancestors, the partially qualified name for the - destination would be - - H.G.F - - To permit the case of partially qualified names, name server at A - needs to resolve the simple name F, i.e., F needs to be distinct from - all the other simple names in its database. - - To enable the name server of a domain to resolve simple names, a - simple name for a child needs to be assigned distinct from those of - all of its ancestors and their immediate children. However, such - distinction would not be sufficient to allow simple name resolution - at lower-level domains because lower-level domains could have - multiple parentage below the level of this domain. - - In the example above, let us assume that a name is to be assigned - - -Su & Postel [Page 12] - - - -RFC 819 August 1982; - - - to a new domain X by D. To allow name server at D to resolve - simple names, the name for X must be distinct from L, E, D, C, F, - and J. However, allowing A to resolve simple names, X needs to be - also distinct from A, B, K, as well as from Q, P, N, and R. - - The following observations can be made. - - Simple names along parallel trails (distinct trails leading from - one domain to the naming universe) must be distinct, e.g., N must - be distinct from E for B or A to properly resolve simple names. - - No universal uniqueness of simple names is called for, e.g., the - simple name S does not have to be distinct from that of E, F, G, - H, D, C, K, Q, B, or A. - - The lower the level at which a domain occurs, the more immune it - is to the requirement of naming uniqueness. - - To satisfy the required distinction of simple names for proper - resolution at all levels, a naming authority needs to ensure the - simple name to be assigned distinct from those in the name server - databases at the endpoint naming domains within its domain. As an - example, for D to assign a simple name for X, it would need to - consult databases at A and K. It is, however, acceptable to have - simple names under domain A identical with those under K. Failure of - such distinct assignment of simple names by naming authority of one - domain would jeopardize the capability of simple name resolution for - entities within the subtree under that domain. - - - - - - - - - - - - - - - - - - - - - - - -Su & Postel [Page 13] - - - -RFC 819 August 1982; - - -APPENDIX C - - Further Discussion of Name Service and Name Servers - - The name service on a system should appear to the programmer of an - application program simply as a system call or library subroutine. - Within that call or subroutine there may be several types of methods - for resolving the name string into an address. - - First, a local table may be consulted. This table may be a - complete table and may be updated frequently, or it may simply be - a cache of the few latest name to address mappings recently - determined. - - Second, a call may be made to a name server to resolve the string - into a destination address. - - Third, a call may be made to a name server to resolve the string - into a relay address. - - Whenever a name server is called it may be a recursive server or an - interactive server. - - If the server is recursive, the caller won't be able to tell if - the server itself had the information to resolve the query or - called another server recursively (except perhaps for the time it - takes). - - If the server is iterative, the caller must be prepared for either - the answer to its query, or a response indicating that it should - call on a different server. - - It should be noted that the main name service discussed in this memo - is simply a name string to address service. For some applications - there may be other services needed. - - For example, even within the Internet there are several procedures - or protocols for actually transferring mail. One need is to - determine which mail procedures a destination host can use. - Another need is to determine the name of a relay host if the - source and destination hosts do not have a common mail procedure. - These more specialized services must be specific to each - application since the answers may be application dependent, but - the basic name to address translation is application independent. - - - - - - - -Su & Postel [Page 14] - - - -RFC 819 August 1982; - - -APPENDIX D - - Further Discussion of Interoperability and Protocol Translations - - The translation of protocols from one system to another is often - quite difficult. Following are some questions that stem from - considering the translations of addresses between mail systems: - - What is the impact of different addressing environments (i.e., - environments of different address formats)? - - It is noted that the boundary of naming environment may or may not - coincide with the boundary of different mail systems. Should the - conversion of naming be independent of the application system? - - The boundary between different addressing environments may or may - not coincide with that of different naming environments or - application systems. Some generic approach appears to be - necessary. - - If the conversion of naming is to be independent of the - application system, some form of interaction appears necessary - between the interface module of naming conversion with some - application level functions, such as the parsing and modification - of message text. - - To accommodate encryption, conversion may not be desirable at all. - What then can be an alternative to conversion? - - - - - - - - - - - - - - - - - - - - - - - -Su & Postel [Page 15] - - - -RFC 819 August 1982; - - -GLOSSARY - - address - - An address is a numerical identifier for the topological location - of the named entity. - - name - - A name is an alphanumeric identifier associated with the named - entity. For unique identification, a name needs to be unique in - the context in which the name is used. A name can be mapped to an - address. - - complete (fully qualified) name - - A complete name is a concatenation of simple names representing - the hierarchical relation of the named with respect to the naming - universe, that is it is the concatenation of the simple names of - the domain structure tree nodes starting with its own name and - ending with the top level node name. It is a unique name in the - naming universe. - - partially qualified name - - A partially qualified name is an abbreviation of the complete name - omitting simple names of the common ancestors of the communicating - parties. - - simple name - - A simple name is an alphanumeric identifier unique only within its - parent domain. - - domain - - A domain defines a region of jurisdiction for name assignment and - of responsibility for name-to-address translation. - - naming universe - - Naming universe is the ancestor of all network entities. - - naming environment - - A networking environment employing a specific naming convention. - - - - - -Su & Postel [Page 16] - - - -RFC 819 August 1982; - - - name service - - Name service is a network service for name-to-address mapping. - - name server - - A name server is a network mechanism (e.g., a process) realizing - the function of name service. - - naming authority - - Naming authority is an administrative entity having the authority - for assigning simple names and responsibility for resolving naming - conflict. - - parallel relations - - A network entity may have one or more hierarchical relations with - respect to the naming universe. Such multiple relations are - parallel relations to each other. - - multiple parentage - - A network entity has multiple parentage when it is assigned a - simple name by more than one naming domain. - - - - - - - - - - - - - - - - - - - - - - - - - - -Su & Postel [Page 17] - - - -RFC 819 August 1982; - - -REFERENCES - - [1] F. Harary, "Graph Theory", Addison-Wesley, Reading, - Massachusetts, 1969. - - [2] J. Postel, "Computer Mail Meeting Notes", RFC-805, - USC/Information Sciences Institute, 8 February 1982. - - [3] J. Postel, "Simple Mail Transfer Protocol", RFC-821, - USC/Information Sciences Institute, August 1982. - - [4] D. Crocker, "Standard for the Format of ARPA Internet Text - Messages", RFC-822, Department of Electrical Engineering, University - of Delaware, August 1982. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Su & Postel [Page 18] - diff --git a/usr.sbin/sendmail/doc/rfc/rfc821.txt b/usr.sbin/sendmail/doc/rfc/rfc821.txt deleted file mode 100644 index d877b72..0000000 --- a/usr.sbin/sendmail/doc/rfc/rfc821.txt +++ /dev/null @@ -1,4050 +0,0 @@ - - - - RFC 821 - - - - - - SIMPLE MAIL TRANSFER PROTOCOL - - - - Jonathan B. Postel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 1982 - - - - Information Sciences Institute - University of Southern California - 4676 Admiralty Way - Marina del Rey, California 90291 - - (213) 822-1511 - - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - TABLE OF CONTENTS - - 1. INTRODUCTION .................................................. 1 - - 2. THE SMTP MODEL ................................................ 2 - - 3. THE SMTP PROCEDURE ............................................ 4 - - 3.1. Mail ..................................................... 4 - 3.2. Forwarding ............................................... 7 - 3.3. Verifying and Expanding .................................. 8 - 3.4. Sending and Mailing ..................................... 11 - 3.5. Opening and Closing ..................................... 13 - 3.6. Relaying ................................................ 14 - 3.7. Domains ................................................. 17 - 3.8. Changing Roles .......................................... 18 - - 4. THE SMTP SPECIFICATIONS ...................................... 19 - - 4.1. SMTP Commands ........................................... 19 - 4.1.1. Command Semantics ..................................... 19 - 4.1.2. Command Syntax ........................................ 27 - 4.2. SMTP Replies ............................................ 34 - 4.2.1. Reply Codes by Function Group ......................... 35 - 4.2.2. Reply Codes in Numeric Order .......................... 36 - 4.3. Sequencing of Commands and Replies ...................... 37 - 4.4. State Diagrams .......................................... 39 - 4.5. Details ................................................. 41 - 4.5.1. Minimum Implementation ................................ 41 - 4.5.2. Transparency .......................................... 41 - 4.5.3. Sizes ................................................. 42 - - APPENDIX A: TCP ................................................. 44 - APPENDIX B: NCP ................................................. 45 - APPENDIX C: NITS ................................................ 46 - APPENDIX D: X.25 ................................................ 47 - APPENDIX E: Theory of Reply Codes ............................... 48 - APPENDIX F: Scenarios ........................................... 51 - - GLOSSARY ......................................................... 64 - - REFERENCES ....................................................... 67 - - - - -Network Working Group J. Postel -Request for Comments: DRAFT ISI -Replaces: RFC 788, 780, 772 August 1982 - - SIMPLE MAIL TRANSFER PROTOCOL - - -1. INTRODUCTION - - The objective of Simple Mail Transfer Protocol (SMTP) is to transfer - mail reliably and efficiently. - - SMTP is independent of the particular transmission subsystem and - requires only a reliable ordered data stream channel. Appendices A, - B, C, and D describe the use of SMTP with various transport services. - A Glossary provides the definitions of terms as used in this - document. - - An important feature of SMTP is its capability to relay mail across - transport service environments. A transport service provides an - interprocess communication environment (IPCE). An IPCE may cover one - network, several networks, or a subset of a network. It is important - to realize that transport systems (or IPCEs) are not one-to-one with - networks. A process can communicate directly with another process - through any mutually known IPCE. Mail is an application or use of - interprocess communication. Mail can be communicated between - processes in different IPCEs by relaying through a process connected - to two (or more) IPCEs. More specifically, mail can be relayed - between hosts on different transport systems by a host on both - transport systems. - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 1] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -2. THE SMTP MODEL - - The SMTP design is based on the following model of communication: as - the result of a user mail request, the sender-SMTP establishes a - two-way transmission channel to a receiver-SMTP. The receiver-SMTP - may be either the ultimate destination or an intermediate. SMTP - commands are generated by the sender-SMTP and sent to the - receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the - sender-SMTP in response to the commands. - - Once the transmission channel is established, the SMTP-sender sends a - MAIL command indicating the sender of the mail. If the SMTP-receiver - can accept mail it responds with an OK reply. The SMTP-sender then - sends a RCPT command identifying a recipient of the mail. If the - SMTP-receiver can accept mail for that recipient it responds with an - OK reply; if not, it responds with a reply rejecting that recipient - (but not the whole mail transaction). The SMTP-sender and - SMTP-receiver may negotiate several recipients. When the recipients - have been negotiated the SMTP-sender sends the mail data, terminating - with a special sequence. If the SMTP-receiver successfully processes - the mail data it responds with an OK reply. The dialog is purposely - lock-step, one-at-a-time. - - ------------------------------------------------------------- - - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Sender- |Commands/Replies| Receiver-| - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - - - Sender-SMTP Receiver-SMTP - - Model for SMTP Use - - Figure 1 - - ------------------------------------------------------------- - - The SMTP provides mechanisms for the transmission of mail; directly - from the sending user's host to the receiving user's host when the - - - -[Page 2] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - two host are connected to the same transport service, or via one or - more relay SMTP-servers when the source and destination hosts are not - connected to the same transport service. - - To be able to provide the relay capability the SMTP-server must be - supplied with the name of the ultimate destination host as well as - the destination mailbox name. - - The argument to the MAIL command is a reverse-path, which specifies - who the mail is from. The argument to the RCPT command is a - forward-path, which specifies who the mail is to. The forward-path - is a source route, while the reverse-path is a return route (which - may be used to return a message to the sender when an error occurs - with a relayed message). - - When the same message is sent to multiple recipients the SMTP - encourages the transmission of only one copy of the data for all the - recipients at the same destination host. - - The mail commands and replies have a rigid syntax. Replies also have - a numeric code. In the following, examples appear which use actual - commands and replies. The complete lists of commands and replies - appears in Section 4 on specifications. - - Commands and replies are not case sensitive. That is, a command or - reply word may be upper case, lower case, or any mixture of upper and - lower case. Note that this is not true of mailbox user names. For - some hosts the user name is case sensitive, and SMTP implementations - must take case to preserve the case of user names as they appear in - mailbox arguments. Host names are not case sensitive. - - Commands and replies are composed of characters from the ASCII - character set [1]. When the transport service provides an 8-bit byte - (octet) transmission channel, each 7-bit character is transmitted - right justified in an octet with the high order bit cleared to zero. - - When specifying the general form of a command or reply, an argument - (or special symbol) will be denoted by a meta-linguistic variable (or - constant), for example, "" or "". Here the - angle brackets indicate these are meta-linguistic variables. - However, some arguments use the angle brackets literally. For - example, an actual reverse-path is enclosed in angle brackets, i.e., - "" is an instance of (the - angle brackets are actually transmitted in the command or reply). - - - - - -Postel [Page 3] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -3. THE SMTP PROCEDURES - - This section presents the procedures used in SMTP in several parts. - First comes the basic mail procedure defined as a mail transaction. - Following this are descriptions of forwarding mail, verifying mailbox - names and expanding mailing lists, sending to terminals instead of or - in combination with mailboxes, and the opening and closing exchanges. - At the end of this section are comments on relaying, a note on mail - domains, and a discussion of changing roles. Throughout this section - are examples of partial command and reply sequences, several complete - scenarios are presented in Appendix F. - - 3.1. MAIL - - There are three steps to SMTP mail transactions. The transaction - is started with a MAIL command which gives the sender - identification. A series of one or more RCPT commands follows - giving the receiver information. Then a DATA command gives the - mail data. And finally, the end of mail data indicator confirms - the transaction. - - The first step in the procedure is the MAIL command. The - contains the source mailbox. - - MAIL FROM: - - This command tells the SMTP-receiver that a new mail - transaction is starting and to reset all its state tables and - buffers, including any recipients or mail data. It gives the - reverse-path which can be used to report errors. If accepted, - the receiver-SMTP returns a 250 OK reply. - - The can contain more than just a mailbox. The - is a reverse source routing list of hosts and - source mailbox. The first host in the should be - the host sending this command. - - The second step in the procedure is the RCPT command. - - RCPT TO: - - This command gives a forward-path identifying one recipient. - If accepted, the receiver-SMTP returns a 250 OK reply, and - stores the forward-path. If the recipient is unknown the - receiver-SMTP returns a 550 Failure reply. This second step of - the procedure can be repeated any number of times. - - - -[Page 4] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - The can contain more than just a mailbox. The - is a source routing list of hosts and the - destination mailbox. The first host in the - should be the host receiving this command. - - The third step in the procedure is the DATA command. - - DATA - - If accepted, the receiver-SMTP returns a 354 Intermediate reply - and considers all succeeding lines to be the message text. - When the end of text is received and stored the SMTP-receiver - sends a 250 OK reply. - - Since the mail data is sent on the transmission channel the end - of the mail data must be indicated so that the command and - reply dialog can be resumed. SMTP indicates the end of the - mail data by sending a line containing only a period. A - transparency procedure is used to prevent this from interfering - with the user's text (see Section 4.5.2). - - Please note that the mail data includes the memo header - items such as Date, Subject, To, Cc, From [2]. - - The end of mail data indicator also confirms the mail - transaction and tells the receiver-SMTP to now process the - stored recipients and mail data. If accepted, the - receiver-SMTP returns a 250 OK reply. The DATA command should - fail only if the mail transaction was incomplete (for example, - no recipients), or if resources are not available. - - The above procedure is an example of a mail transaction. These - commands must be used only in the order discussed above. - Example 1 (below) illustrates the use of these commands in a mail - transaction. - - - - - - - - - - - - - - -Postel [Page 5] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Example of the SMTP Procedure - - This SMTP example shows mail sent by Smith at host Alpha.ARPA, - to Jones, Green, and Brown at host Beta.ARPA. Here we assume - that host Alpha contacts host Beta directly. - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO: - R: 250 OK - - S: RCPT TO: - R: 550 No such user here - - S: RCPT TO: - R: 250 OK - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - The mail has now been accepted for Jones and Brown. Green did - not have a mailbox at host Beta. - - Example 1 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - -[Page 6] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 3.2. FORWARDING - - There are some cases where the destination information in the - is incorrect, but the receiver-SMTP knows the - correct destination. In such cases, one of the following replies - should be used to allow the sender to contact the correct - destination. - - 251 User not local; will forward to - - This reply indicates that the receiver-SMTP knows the user's - mailbox is on another host and indicates the correct - forward-path to use in the future. Note that either the - host or user or both may be different. The receiver takes - responsibility for delivering the message. - - 551 User not local; please try - - This reply indicates that the receiver-SMTP knows the user's - mailbox is on another host and indicates the correct - forward-path to use. Note that either the host or user or - both may be different. The receiver refuses to accept mail - for this user, and the sender must either redirect the mail - according to the information provided or return an error - response to the originating user. - - Example 2 illustrates the use of these responses. - - ------------------------------------------------------------- - - Example of Forwarding - - Either - - S: RCPT TO: - R: 251 User not local; will forward to - - Or - - S: RCPT TO: - R: 551 User not local; please try - - Example 2 - - ------------------------------------------------------------- - - - - -Postel [Page 7] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 3.3. VERIFYING AND EXPANDING - - SMTP provides as additional features, commands to verify a user - name or expand a mailing list. This is done with the VRFY and - EXPN commands, which have character string arguments. For the - VRFY command, the string is a user name, and the response may - include the full name of the user and must include the mailbox of - the user. For the EXPN command, the string identifies a mailing - list, and the multiline response may include the full name of the - users and must give the mailboxes on the mailing list. - - "User name" is a fuzzy term and used purposely. If a host - implements the VRFY or EXPN commands then at least local mailboxes - must be recognized as "user names". If a host chooses to - recognize other strings as "user names" that is allowed. - - In some hosts the distinction between a mailing list and an alias - for a single mailbox is a bit fuzzy, since a common data structure - may hold both types of entries, and it is possible to have mailing - lists of one mailbox. If a request is made to verify a mailing - list a positive response can be given if on receipt of a message - so addressed it will be delivered to everyone on the list, - otherwise an error should be reported (e.g., "550 That is a - mailing list, not a user"). If a request is made to expand a user - name a positive response can be formed by returning a list - containing one name, or an error can be reported (e.g., "550 That - is a user name, not a mailing list"). - - In the case of a multiline reply (normal for EXPN) exactly one - mailbox is to be specified on each line of the reply. In the case - of an ambiguous request, for example, "VRFY Smith", where there - are two Smith's the response must be "553 User ambiguous". - - The case of verifying a user name is straightforward as shown in - example 3. - - - - - - - - - - - - - - -[Page 8] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Example of Verifying a User Name - - Either - - S: VRFY Smith - R: 250 Fred Smith - - Or - - S: VRFY Smith - R: 251 User not local; will forward to - - Or - - S: VRFY Jones - R: 550 String does not match anything. - - Or - - S: VRFY Jones - R: 551 User not local; please try - - Or - - S: VRFY Gourzenkyinplatz - R: 553 User ambiguous. - - Example 3 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - -Postel [Page 9] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The case of expanding a mailbox list requires a multiline reply as - shown in example 4. - - ------------------------------------------------------------- - - Example of Expanding a Mailing List - - Either - - S: EXPN Example-People - R: 250-Jon Postel - R: 250-Fred Fonebone - R: 250-Sam Q. Smith - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250- - R: 250 - - Or - - S: EXPN Executive-Washroom-List - R: 550 Access Denied to You. - - Example 4 - - ------------------------------------------------------------- - - The character string arguments of the VRFY and EXPN commands - cannot be further restricted due to the variety of implementations - of the user name and mailbox list concepts. On some systems it - may be appropriate for the argument of the EXPN command to be a - file name for a file containing a mailing list, but again there is - a variety of file naming conventions in the Internet. - - The VRFY and EXPN commands are not included in the minimum - implementation (Section 4.5.1), and are not required to work - across relays when they are implemented. - - - - - - - - - - - - - -[Page 10] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 3.4. SENDING AND MAILING - - The main purpose of SMTP is to deliver messages to user's - mailboxes. A very similar service provided by some hosts is to - deliver messages to user's terminals (provided the user is active - on the host). The delivery to the user's mailbox is called - "mailing", the delivery to the user's terminal is called - "sending". Because in many hosts the implementation of sending is - nearly identical to the implementation of mailing these two - functions are combined in SMTP. However the sending commands are - not included in the required minimum implementation - (Section 4.5.1). Users should have the ability to control the - writing of messages on their terminals. Most hosts permit the - users to accept or refuse such messages. - - The following three command are defined to support the sending - options. These are used in the mail transaction instead of the - MAIL command and inform the receiver-SMTP of the special semantics - of this transaction: - - SEND FROM: - - The SEND command requires that the mail data be delivered to - the user's terminal. If the user is not active (or not - accepting terminal messages) on the host a 450 reply may - returned to a RCPT command. The mail transaction is - successful if the message is delivered the terminal. - - SOML FROM: - - The Send Or MaiL command requires that the mail data be - delivered to the user's terminal if the user is active (and - accepting terminal messages) on the host. If the user is - not active (or not accepting terminal messages) then the - mail data is entered into the user's mailbox. The mail - transaction is successful if the message is delivered either - to the terminal or the mailbox. - - SAML FROM: - - The Send And MaiL command requires that the mail data be - delivered to the user's terminal if the user is active (and - accepting terminal messages) on the host. In any case the - mail data is entered into the user's mailbox. The mail - transaction is successful if the message is delivered the - mailbox. - - - -Postel [Page 11] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The same reply codes that are used for the MAIL commands are used - for these commands. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 12] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 3.5. OPENING AND CLOSING - - At the time the transmission channel is opened there is an - exchange to ensure that the hosts are communicating with the hosts - they think they are. - - The following two commands are used in transmission channel - opening and closing: - - HELO - - QUIT - - In the HELO command the host sending the command identifies - itself; the command may be interpreted as saying "Hello, I am - ". - - ------------------------------------------------------------- - - Example of Connection Opening - - R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BBN-UNIX.ARPA - - Example 5 - - ------------------------------------------------------------- - - ------------------------------------------------------------- - - Example of Connection Closing - - S: QUIT - R: 221 BBN-UNIX.ARPA Service closing transmission channel - - Example 6 - - ------------------------------------------------------------- - - - - - - - - - - -Postel [Page 13] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 3.6. RELAYING - - The forward-path may be a source route of the form - "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts. This - form is used to emphasize the distinction between an address and a - route. The mailbox is an absolute address, and the route is - information about how to get there. The two concepts should not - be confused. - - Conceptually the elements of the forward-path are moved to the - reverse-path as the message is relayed from one server-SMTP to - another. The reverse-path is a reverse source route, (i.e., a - source route from the current location of the message to the - originator of the message). When a server-SMTP deletes its - identifier from the forward-path and inserts it into the - reverse-path, it must use the name it is known by in the - environment it is sending into, not the environment the mail came - from, in case the server-SMTP is known by different names in - different environments. - - If when the message arrives at an SMTP the first element of the - forward-path is not the identifier of that SMTP the element is not - deleted from the forward-path and is used to determine the next - SMTP to send the message to. In any case, the SMTP adds its own - identifier to the reverse-path. - - Using source routing the receiver-SMTP receives mail to be relayed - to another server-SMTP The receiver-SMTP may accept or reject the - task of relaying the mail in the same way it accepts or rejects - mail for a local user. The receiver-SMTP transforms the command - arguments by moving its own identifier from the forward-path to - the beginning of the reverse-path. The receiver-SMTP then becomes - a sender-SMTP, establishes a transmission channel to the next SMTP - in the forward-path, and sends it the mail. - - The first host in the reverse-path should be the host sending the - SMTP commands, and the first host in the forward-path should be - the host receiving the SMTP commands. - - Notice that the forward-path and reverse-path appear in the SMTP - commands and replies, but not necessarily in the message. That - is, there is no need for these paths and especially this syntax to - appear in the "To:" , "From:", "CC:", etc. fields of the message - header. - - If a server-SMTP has accepted the task of relaying the mail and - - - -[Page 14] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - later finds that the forward-path is incorrect or that the mail - cannot be delivered for whatever reason, then it must construct an - "undeliverable mail" notification message and send it to the - originator of the undeliverable mail (as indicated by the - reverse-path). - - This notification message must be from the server-SMTP at this - host. Of course, server-SMTPs should not send notification - messages about problems with notification messages. One way to - prevent loops in error reporting is to specify a null reverse-path - in the MAIL command of a notification message. When such a - message is relayed it is permissible to leave the reverse-path - null. A MAIL command with a null reverse-path appears as follows: - - MAIL FROM:<> - - An undeliverable mail notification message is shown in example 7. - This notification is in response to a message originated by JOE at - HOSTW and sent via HOSTX to HOSTY with instructions to relay it on - to HOSTZ. What we see in the example is the transaction between - HOSTY and HOSTX, which is the first step in the return of the - notification message. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 15] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Example Undeliverable Mail Notification Message - - S: MAIL FROM:<> - R: 250 ok - S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA> - R: 250 ok - S: DATA - R: 354 send the mail data, end with . - S: Date: 23 Oct 81 11:22:33 - S: From: SMTP@HOSTY.ARPA - S: To: JOE@HOSTW.ARPA - S: Subject: Mail System Problem - S: - S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost. - S: HOSTZ.ARPA said this: - S: "550 No Such User" - S: . - R: 250 ok - - Example 7 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 16] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 3.7. DOMAINS - - Domains are a recently introduced concept in the ARPA Internet - mail system. The use of domains changes the address space from a - flat global space of simple character string host names to a - hierarchically structured rooted tree of global addresses. The - host name is replaced by a domain and host designator which is a - sequence of domain element strings separated by periods with the - understanding that the domain elements are ordered from the most - specific to the most general. - - For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and - "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers. - - Whenever domain names are used in SMTP only the official names are - used, the use of nicknames or aliases is not allowed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 17] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 3.8. CHANGING ROLES - - The TURN command may be used to reverse the roles of the two - programs communicating over the transmission channel. - - If program-A is currently the sender-SMTP and it sends the TURN - command and receives an ok reply (250) then program-A becomes the - receiver-SMTP. - - If program-B is currently the receiver-SMTP and it receives the - TURN command and sends an ok reply (250) then program-B becomes - the sender-SMTP. - - To refuse to change roles the receiver sends the 502 reply. - - Please note that this command is optional. It would not normally - be used in situations where the transmission channel is TCP. - However, when the cost of establishing the transmission channel is - high, this command may be quite useful. For example, this command - may be useful in supporting be mail exchange using the public - switched telephone system as a transmission channel, especially if - some hosts poll other hosts for mail exchanges. - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 18] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -4. THE SMTP SPECIFICATIONS - - 4.1. SMTP COMMANDS - - 4.1.1. COMMAND SEMANTICS - - The SMTP commands define the mail transfer or the mail system - function requested by the user. SMTP commands are character - strings terminated by . The command codes themselves are - alphabetic characters terminated by if parameters follow - and otherwise. The syntax of mailboxes must conform to - receiver site conventions. The SMTP commands are discussed - below. The SMTP replies are discussed in the Section 4.2. - - A mail transaction involves several data objects which are - communicated as arguments to different commands. The - reverse-path is the argument of the MAIL command, the - forward-path is the argument of the RCPT command, and the mail - data is the argument of the DATA command. These arguments or - data objects must be transmitted and held pending the - confirmation communicated by the end of mail data indication - which finalizes the transaction. The model for this is that - distinct buffers are provided to hold the types of data - objects, that is, there is a reverse-path buffer, a - forward-path buffer, and a mail data buffer. Specific commands - cause information to be appended to a specific buffer, or cause - one or more buffers to be cleared. - - HELLO (HELO) - - This command is used to identify the sender-SMTP to the - receiver-SMTP. The argument field contains the host name of - the sender-SMTP. - - The receiver-SMTP identifies itself to the sender-SMTP in - the connection greeting reply, and in the response to this - command. - - This command and an OK reply to it confirm that both the - sender-SMTP and the receiver-SMTP are in the initial state, - that is, there is no transaction in progress and all state - tables and buffers are cleared. - - - - - - - -Postel [Page 19] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - MAIL (MAIL) - - This command is used to initiate a mail transaction in which - the mail data is delivered to one or more mailboxes. The - argument field contains a reverse-path. - - The reverse-path consists of an optional list of hosts and - the sender mailbox. When the list of hosts is present, it - is a "reverse" source route and indicates that the mail was - relayed through each host on the list (the first host in the - list was the most recent relay). This list is used as a - source route to return non-delivery notices to the sender. - As each relay host adds itself to the beginning of the list, - it must use its name as known in the IPCE to which it is - relaying the mail rather than the IPCE from which the mail - came (if they are different). In some types of error - reporting messages (for example, undeliverable mail - notifications) the reverse-path may be null (see Example 7). - - This command clears the reverse-path buffer, the - forward-path buffer, and the mail data buffer; and inserts - the reverse-path information from this command into the - reverse-path buffer. - - RECIPIENT (RCPT) - - This command is used to identify an individual recipient of - the mail data; multiple recipients are specified by multiple - use of this command. - - The forward-path consists of an optional list of hosts and a - required destination mailbox. When the list of hosts is - present, it is a source route and indicates that the mail - must be relayed to the next host on the list. If the - receiver-SMTP does not implement the relay function it may - user the same reply it would for an unknown local user - (550). - - When mail is relayed, the relay host must remove itself from - the beginning forward-path and put itself at the beginning - of the reverse-path. When mail reaches its ultimate - destination (the forward-path contains only a destination - mailbox), the receiver-SMTP inserts it into the destination - mailbox in accordance with its host mail conventions. - - - - - -[Page 20] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - For example, mail received at relay host A with arguments - - FROM: - TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA> - - will be relayed on to host B with arguments - - FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA> - TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>. - - This command causes its forward-path argument to be appended - to the forward-path buffer. - - DATA (DATA) - - The receiver treats the lines following the command as mail - data from the sender. This command causes the mail data - from this command to be appended to the mail data buffer. - The mail data may contain any of the 128 ASCII character - codes. - - The mail data is terminated by a line containing only a - period, that is the character sequence "." (see - Section 4.5.2 on Transparency). This is the end of mail - data indication. - - The end of mail data indication requires that the receiver - must now process the stored mail transaction information. - This processing consumes the information in the reverse-path - buffer, the forward-path buffer, and the mail data buffer, - and on the completion of this command these buffers are - cleared. If the processing is successful the receiver must - send an OK reply. If the processing fails completely the - receiver must send a failure reply. - - When the receiver-SMTP accepts a message either for relaying - or for final delivery it inserts at the beginning of the - mail data a time stamp line. The time stamp line indicates - the identity of the host that sent the message, and the - identity of the host that received the message (and is - inserting this time stamp), and the date and time the - message was received. Relayed messages will have multiple - time stamp lines. - - When the receiver-SMTP makes the "final delivery" of a - message it inserts at the beginning of the mail data a - - - -Postel [Page 21] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - return path line. The return path line preserves the - information in the from the MAIL command. - Here, final delivery means the message leaves the SMTP - world. Normally, this would mean it has been delivered to - the destination user, but in some cases it may be further - processed and transmitted by another mail system. - - It is possible for the mailbox in the return path be - different from the actual sender's mailbox, for example, - if error responses are to be delivered a special error - handling mailbox rather than the message senders. - - The preceding two paragraphs imply that the final mail data - will begin with a return path line, followed by one or more - time stamp lines. These lines will be followed by the mail - data header and body [2]. See Example 8. - - Special mention is needed of the response and further action - required when the processing following the end of mail data - indication is partially successful. This could arise if - after accepting several recipients and the mail data, the - receiver-SMTP finds that the mail data can be successfully - delivered to some of the recipients, but it cannot be to - others (for example, due to mailbox space allocation - problems). In such a situation, the response to the DATA - command must be an OK reply. But, the receiver-SMTP must - compose and send an "undeliverable mail" notification - message to the originator of the message. Either a single - notification which lists all of the recipients that failed - to get the message, or separate notification messages must - be sent for each failed recipient (see Example 7). All - undeliverable mail notification messages are sent using the - MAIL command (even if they result from processing a SEND, - SOML, or SAML command). - - - - - - - - - - - - - - - -[Page 22] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Example of Return Path and Received Time Stamps - - Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA> - Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST - Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST - Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST - Date: 27 Oct 81 15:01:01 PST - From: JOE@ABC.ARPA - Subject: Improved Mailing System Installed - To: SAM@JKL.ARPA - - This is to inform you that ... - - Example 8 - - ------------------------------------------------------------- - - SEND (SEND) - - This command is used to initiate a mail transaction in which - the mail data is delivered to one or more terminals. The - argument field contains a reverse-path. This command is - successful if the message is delivered to a terminal. - - The reverse-path consists of an optional list of hosts and - the sender mailbox. When the list of hosts is present, it - is a "reverse" source route and indicates that the mail was - relayed through each host on the list (the first host in the - list was the most recent relay). This list is used as a - source route to return non-delivery notices to the sender. - As each relay host adds itself to the beginning of the list, - it must use its name as known in the IPCE to which it is - relaying the mail rather than the IPCE from which the mail - came (if they are different). - - This command clears the reverse-path buffer, the - forward-path buffer, and the mail data buffer; and inserts - the reverse-path information from this command into the - reverse-path buffer. - - SEND OR MAIL (SOML) - - This command is used to initiate a mail transaction in which - the mail data is delivered to one or more terminals or - - - -Postel [Page 23] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - mailboxes. For each recipient the mail data is delivered to - the recipient's terminal if the recipient is active on the - host (and accepting terminal messages), otherwise to the - recipient's mailbox. The argument field contains a - reverse-path. This command is successful if the message is - delivered to a terminal or the mailbox. - - The reverse-path consists of an optional list of hosts and - the sender mailbox. When the list of hosts is present, it - is a "reverse" source route and indicates that the mail was - relayed through each host on the list (the first host in the - list was the most recent relay). This list is used as a - source route to return non-delivery notices to the sender. - As each relay host adds itself to the beginning of the list, - it must use its name as known in the IPCE to which it is - relaying the mail rather than the IPCE from which the mail - came (if they are different). - - This command clears the reverse-path buffer, the - forward-path buffer, and the mail data buffer; and inserts - the reverse-path information from this command into the - reverse-path buffer. - - SEND AND MAIL (SAML) - - This command is used to initiate a mail transaction in which - the mail data is delivered to one or more terminals and - mailboxes. For each recipient the mail data is delivered to - the recipient's terminal if the recipient is active on the - host (and accepting terminal messages), and for all - recipients to the recipient's mailbox. The argument field - contains a reverse-path. This command is successful if the - message is delivered to the mailbox. - - The reverse-path consists of an optional list of hosts and - the sender mailbox. When the list of hosts is present, it - is a "reverse" source route and indicates that the mail was - relayed through each host on the list (the first host in the - list was the most recent relay). This list is used as a - source route to return non-delivery notices to the sender. - As each relay host adds itself to the beginning of the list, - it must use its name as known in the IPCE to which it is - relaying the mail rather than the IPCE from which the mail - came (if they are different). - - This command clears the reverse-path buffer, the - - - -[Page 24] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - forward-path buffer, and the mail data buffer; and inserts - the reverse-path information from this command into the - reverse-path buffer. - - RESET (RSET) - - This command specifies that the current mail transaction is - to be aborted. Any stored sender, recipients, and mail data - must be discarded, and all buffers and state tables cleared. - The receiver must send an OK reply. - - VERIFY (VRFY) - - This command asks the receiver to confirm that the argument - identifies a user. If it is a user name, the full name of - the user (if known) and the fully specified mailbox are - returned. - - This command has no effect on any of the reverse-path - buffer, the forward-path buffer, or the mail data buffer. - - EXPAND (EXPN) - - This command asks the receiver to confirm that the argument - identifies a mailing list, and if so, to return the - membership of that list. The full name of the users (if - known) and the fully specified mailboxes are returned in a - multiline reply. - - This command has no effect on any of the reverse-path - buffer, the forward-path buffer, or the mail data buffer. - - HELP (HELP) - - This command causes the receiver to send helpful information - to the sender of the HELP command. The command may take an - argument (e.g., any command name) and return more specific - information as a response. - - This command has no effect on any of the reverse-path - buffer, the forward-path buffer, or the mail data buffer. - - - - - - - - -Postel [Page 25] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - NOOP (NOOP) - - This command does not affect any parameters or previously - entered commands. It specifies no action other than that - the receiver send an OK reply. - - This command has no effect on any of the reverse-path - buffer, the forward-path buffer, or the mail data buffer. - - QUIT (QUIT) - - This command specifies that the receiver must send an OK - reply, and then close the transmission channel. - - The receiver should not close the transmission channel until - it receives and replies to a QUIT command (even if there was - an error). The sender should not close the transmission - channel until it send a QUIT command and receives the reply - (even if there was an error response to a previous command). - If the connection is closed prematurely the receiver should - act as if a RSET command had been received (canceling any - pending transaction, but not undoing any previously - completed transaction), the sender should act as if the - command or transaction in progress had received a temporary - error (4xx). - - TURN (TURN) - - This command specifies that the receiver must either (1) - send an OK reply and then take on the role of the - sender-SMTP, or (2) send a refusal reply and retain the role - of the receiver-SMTP. - - If program-A is currently the sender-SMTP and it sends the - TURN command and receives an OK reply (250) then program-A - becomes the receiver-SMTP. Program-A is then in the initial - state as if the transmission channel just opened, and it - then sends the 220 service ready greeting. - - If program-B is currently the receiver-SMTP and it receives - the TURN command and sends an OK reply (250) then program-B - becomes the sender-SMTP. Program-B is then in the initial - state as if the transmission channel just opened, and it - then expects to receive the 220 service ready greeting. - - To refuse to change roles the receiver sends the 502 reply. - - - -[Page 26] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - There are restrictions on the order in which these command may - be used. - - The first command in a session must be the HELO command. - The HELO command may be used later in a session as well. If - the HELO command argument is not acceptable a 501 failure - reply must be returned and the receiver-SMTP must stay in - the same state. - - The NOOP, HELP, EXPN, and VRFY commands can be used at any - time during a session. - - The MAIL, SEND, SOML, or SAML commands begin a mail - transaction. Once started a mail transaction consists of - one of the transaction beginning commands, one or more RCPT - commands, and a DATA command, in that order. A mail - transaction may be aborted by the RSET command. There may - be zero or more transactions in a session. - - If the transaction beginning command argument is not - acceptable a 501 failure reply must be returned and the - receiver-SMTP must stay in the same state. If the commands - in a transaction are out of order a 503 failure reply must - be returned and the receiver-SMTP must stay in the same - state. - - The last command in a session must be the QUIT command. The - QUIT command can not be used at any other time in a session. - - 4.1.2. COMMAND SYNTAX - - The commands consist of a command code followed by an argument - field. Command codes are four alphabetic characters. Upper - and lower case alphabetic characters are to be treated - identically. Thus, any of the following may represent the mail - command: - - MAIL Mail mail MaIl mAIl - - This also applies to any symbols representing parameter values, - such as "TO" or "to" for the forward-path. Command codes and - the argument fields are separated by one or more spaces. - However, within the reverse-path and forward-path arguments - case is important. In particular, in some hosts the user - "smith" is different from the user "Smith". - - - - -Postel [Page 27] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The argument field consists of a variable length character - string ending with the character sequence . The receiver - is to take no action until this sequence is received. - - Square brackets denote an optional argument field. If the - option is not taken, the appropriate default is implied. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 28] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - The following are the SMTP commands: - - HELO - - MAIL FROM: - - RCPT TO: - - DATA - - RSET - - SEND FROM: - - SOML FROM: - - SAML FROM: - - VRFY - - EXPN - - HELP [ ] - - NOOP - - QUIT - - TURN - - - - - - - - - - - - - - - - - - - - -Postel [Page 29] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The syntax of the above argument fields (using BNF notation - where applicable) is given below. The "..." notation indicates - that a field may be repeated one or more times. - - ::= - - ::= - - ::= "<" [ ":" ] ">" - - ::= | "," - - ::= "@" - - ::= | "." - - ::= | "#" | "[" "]" - - ::= "@" - - ::= | - - ::= - - ::= | - - ::= | - - ::= | | "-" - - ::= | "." - - ::= | - - ::= """ """ - - ::= "\" | "\" | | - - ::= | "\" - - ::= "." "." "." - - ::= | - - ::= - - - - -[Page 30] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - ::= the carriage return character (ASCII code 13) - - ::= the line feed character (ASCII code 10) - - ::= the space character (ASCII code 32) - - ::= one, two, or three digits representing a decimal - integer value in the range 0 through 255 - - ::= any one of the 52 alphabetic characters A through Z - in upper case and a through z in lower case - - ::= any one of the 128 ASCII characters, but not any - or - - ::= any one of the ten digits 0 through 9 - - ::= any one of the 128 ASCII characters except , - , quote ("), or backslash (\) - - ::= any one of the 128 ASCII characters (no exceptions) - - ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." - | "," | ";" | ":" | "@" """ | the control - characters (ASCII codes 0 through 31 inclusive and - 127) - - Note that the backslash, "\", is a quote character, which is - used to indicate that the next character is to be used - literally (instead of its normal interpretation). For example, - "Joe\,Smith" could be used to indicate a single nine character - user field with comma being the fourth character of the field. - - Hosts are generally known by names which are translated to - addresses in each host. Note that the name elements of domains - are the official names -- no use of nicknames or aliases is - allowed. - - Sometimes a host is not known to the translation function and - communication is blocked. To bypass this barrier two numeric - forms are also allowed for host "names". One form is a decimal - integer prefixed by a pound sign, "#", which indicates the - number is the address of the host. Another form is four small - decimal integers separated by dots and enclosed by brackets, - e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet - Address in four 8-bit fields. - - - -Postel [Page 31] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The time stamp line and the return path line are formally - defined as follows: - - ::= "Return-Path:" - - ::= "Received:" - - ::= ";" - - - ::= "FROM" - - ::= "BY" - - ::= [] [] [] [] - - ::= "VIA" - - ::= "WITH" - - ::= "ID" - - ::= "FOR" - - ::= The standard names for links are registered with - the Network Information Center. - - ::= The standard names for protocols are - registered with the Network Information Center. - - ::=