diff options
| author | peter <peter@FreeBSD.org> | 1995-12-02 20:58:10 +0000 |
|---|---|---|
| committer | peter <peter@FreeBSD.org> | 1995-12-02 20:58:10 +0000 |
| commit | 1686d8abf9806a1fff38d74a7eec40c111945c76 (patch) | |
| tree | e8be6b6067dfde2b435bbf244347a09291513782 | |
| parent | 945b001c36df6c5fd91850c2b1a7369de4777555 (diff) | |
| download | FreeBSD-src-1686d8abf9806a1fff38d74a7eec40c111945c76.zip FreeBSD-src-1686d8abf9806a1fff38d74a7eec40c111945c76.tar.gz | |
*GULP* cvs remove the uncomfortably large list of files that are no longer
part of sendmail 8.7.2...
44 files changed, 3 insertions, 10185 deletions
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 <bsd.subdir.mk> 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 "<user>@<host>" has served the - ARPANET user community for its mail system, and the substring - "<host>" 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, "<host>", by a composite name field, - "<domain>" [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 <simple - names>. 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 <user> - 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 "<user>%<host>%<area>". 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. - - <mailbox> ::= <local-part> "@" <domain> - - <local-part> ::= <string> | <quoted-string> - - <string> ::= <char> | <char> <string> - - <quoted-string> ::= """ <qtext> """ - - <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext> - - <char> ::= <c> | "\" <x> - - <domain> ::= <naming-domain> | <naming-domain> "." <domain> - - <naming-domain> ::= <simple-name> | <address> - - <simple-name> ::= <a> <ldh-str> <let-dig> - - <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> - - <let-dig> ::= <a> | <d> - - <let-dig-hyp> ::= <a> | <d> | "-" - - <address> :: = "#" <number> | "[" <dotnum> "]" - - <number> ::= <d> | <d> <number> - - <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> - - <snum> ::= one, two, or three digits representing a decimal integer - value in the range 0 through 255 - - <a> ::= any one of the 52 alphabetic characters A through Z in upper - case and a through z in lower case - - <c> ::= any one of the 128 ASCII characters except <s> or <SP> - - <d> ::= any one of the ten digits 0 through 9 - - - -Su & Postel [Page 10] - - - -RFC 819 August 1982; - - - <q> ::= any one of the 128 ASCII characters except CR, LF, quote ("), - or backslash (\) - - <x> ::= any one of the 128 ASCII characters (no exceptions) - - <s> ::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@", - """, 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, "<string>" or "<reverse-path>". 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., - "<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (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 - <reverse-path> contains the source mailbox. - - MAIL <SP> FROM:<reverse-path> <CRLF> - - 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 <reverse-path> can contain more than just a mailbox. The - <reverse-path> is a reverse source routing list of hosts and - source mailbox. The first host in the <reverse-path> should be - the host sending this command. - - The second step in the procedure is the RCPT command. - - RCPT <SP> TO:<forward-path> <CRLF> - - 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 <forward-path> can contain more than just a mailbox. The - <forward-path> is a source routing list of hosts and the - destination mailbox. The first host in the <forward-path> - should be the host receiving this command. - - The third step in the procedure is the DATA command. - - DATA <CRLF> - - 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:<Smith@Alpha.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@Beta.ARPA> - R: 250 OK - - S: RCPT TO:<Green@Beta.ARPA> - R: 550 No such user here - - S: RCPT TO:<Brown@Beta.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: <CRLF>.<CRLF> - 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 - <forward-path> 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 <forward-path> - - 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 <forward-path> - - 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:<Postel@USC-ISI.ARPA> - R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA> - - Or - - S: RCPT TO:<Paul@USC-ISIB.ARPA> - R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA> - - 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 <Smith@USC-ISIF.ARPA> - - Or - - S: VRFY Smith - R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA> - - Or - - S: VRFY Jones - R: 550 String does not match anything. - - Or - - S: VRFY Jones - R: 551 User not local; please try <Jones@USC-ISIQ.ARPA> - - 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 <Postel@USC-ISIF.ARPA> - R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA> - R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<joe@foo-unix.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - 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 <SP> FROM:<reverse-path> <CRLF> - - 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 <SP> FROM:<reverse-path> <CRLF> - - 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 <SP> FROM:<reverse-path> <CRLF> - - 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 <SP> <domain> <CRLF> - - QUIT <CRLF> - - In the HELO command the host sending the command identifies - itself; the command may be interpreted as saying "Hello, I am - <domain>". - - ------------------------------------------------------------- - - 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 <CRLF>. The command codes themselves are - alphabetic characters terminated by <SP> if parameters follow - and <CRLF> 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:<USERX@HOSTY.ARPA> - 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 "<CRLF>.<CRLF>" (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 <reverse-path> 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 <CRLF>. 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 <SP> <domain> <CRLF> - - MAIL <SP> FROM:<reverse-path> <CRLF> - - RCPT <SP> TO:<forward-path> <CRLF> - - DATA <CRLF> - - RSET <CRLF> - - SEND <SP> FROM:<reverse-path> <CRLF> - - SOML <SP> FROM:<reverse-path> <CRLF> - - SAML <SP> FROM:<reverse-path> <CRLF> - - VRFY <SP> <string> <CRLF> - - EXPN <SP> <string> <CRLF> - - HELP [<SP> <string>] <CRLF> - - NOOP <CRLF> - - QUIT <CRLF> - - TURN <CRLF> - - - - - - - - - - - - - - - - - - - - -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. - - <reverse-path> ::= <path> - - <forward-path> ::= <path> - - <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">" - - <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l> - - <at-domain> ::= "@" <domain> - - <domain> ::= <element> | <element> "." <domain> - - <element> ::= <name> | "#" <number> | "[" <dotnum> "]" - - <mailbox> ::= <local-part> "@" <domain> - - <local-part> ::= <dot-string> | <quoted-string> - - <name> ::= <a> <ldh-str> <let-dig> - - <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> - - <let-dig> ::= <a> | <d> - - <let-dig-hyp> ::= <a> | <d> | "-" - - <dot-string> ::= <string> | <string> "." <dot-string> - - <string> ::= <char> | <char> <string> - - <quoted-string> ::= """ <qtext> """ - - <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext> - - <char> ::= <c> | "\" <x> - - <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> - - <number> ::= <d> | <d> <number> - - <CRLF> ::= <CR> <LF> - - - - -[Page 30] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - <CR> ::= the carriage return character (ASCII code 13) - - <LF> ::= the line feed character (ASCII code 10) - - <SP> ::= the space character (ASCII code 32) - - <snum> ::= one, two, or three digits representing a decimal - integer value in the range 0 through 255 - - <a> ::= any one of the 52 alphabetic characters A through Z - in upper case and a through z in lower case - - <c> ::= any one of the 128 ASCII characters, but not any - <special> or <SP> - - <d> ::= any one of the ten digits 0 through 9 - - <q> ::= any one of the 128 ASCII characters except <CR>, - <LF>, quote ("), or backslash (\) - - <x> ::= any one of the 128 ASCII characters (no exceptions) - - <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." - | "," | ";" | ":" | "@" """ | 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-line> ::= "Return-Path:" <SP><reverse-path><CRLF> - - <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF> - - <stamp> ::= <from-domain> <by-domain> <opt-info> ";" - <daytime> - - <from-domain> ::= "FROM" <SP> <domain> <SP> - - <by-domain> ::= "BY" <SP> <domain> <SP> - - <opt-info> ::= [<via>] [<with>] [<id>] [<for>] - - <via> ::= "VIA" <SP> <link> <SP> - - <with> ::= "WITH" <SP> <protocol> <SP> - - <id> ::= "ID" <SP> <string> <SP> - - <for> ::= "FOR" <SP> <path> <SP> - - <link> ::= The standard names for links are registered with - the Network Information Center. - - <protocol> ::= The standard names for protocols are - registered with the Network Information Center. - - <daytime> ::= <SP> <date> <SP> <time> - - <date> ::= <dd> <SP> <mon> <SP> <yy> - - <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone> - - <dd> ::= the one or two decimal integer day of the month in - the range 1 to 31. - - <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | - "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" - - <yy> ::= the two decimal integer year of the century in the - range 00 to 99. - - - - - -[Page 32] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - <hh> ::= the two decimal integer hour of the day in the - range 00 to 24. - - <mm> ::= the two decimal integer minute of the hour in the - range 00 to 59. - - <ss> ::= the two decimal integer second of the minute in the - range 00 to 59. - - <zone> ::= "UT" for Universal Time (the default) or other - time zone designator (as in [2]). - - - - ------------------------------------------------------------- - - Return Path Example - - Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA> - - Example 9 - - ------------------------------------------------------------- - - ------------------------------------------------------------- - - Time Stamp Line Example - - Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT - - Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25 - id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT - - Example 10 - - ------------------------------------------------------------- - - - - - - - - - - - - - -Postel [Page 33] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 4.2. SMTP REPLIES - - Replies to SMTP commands are devised to ensure the synchronization - of requests and actions in the process of mail transfer, and to - guarantee that the sender-SMTP always knows the state of the - receiver-SMTP. Every command must generate exactly one reply. - - The details of the command-reply sequence are made explicit in - Section 5.3 on Sequencing and Section 5.4 State Diagrams. - - An SMTP reply consists of a three digit number (transmitted as - three alphanumeric characters) followed by some text. The number - is intended for use by automata to determine what state to enter - next; the text is meant for the human user. It is intended that - the three digits contain enough encoded information that the - sender-SMTP need not examine the text and may either discard it or - pass it on to the user, as appropriate. In particular, the text - may be receiver-dependent and context dependent, so there are - likely to be varying texts for each reply code. A discussion of - the theory of reply codes is given in Appendix E. Formally, a - reply is defined to be the sequence: a three-digit code, <SP>, - one line of text, and <CRLF>, or a multiline reply (as defined in - Appendix E). Only the EXPN and HELP commands are expected to - result in multiline replies in normal circumstances, however - multiline replies are allowed for any command. - - - - - - - - - - - - - - - - - - - - - - - - -[Page 34] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.2.1. REPLY CODES BY FUNCTION GROUPS - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access] - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed - - - - - - - - - - - - - -Postel [Page 35] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 4.2.2. NUMERIC ORDER LIST OF REPLY CODES - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - - 354 Start mail input; end with <CRLF>.<CRLF> - - 421 <domain> Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access] - 551 User not local; please try <forward-path> - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 554 Transaction failed - - - - - - - - - - - - - -[Page 36] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.3. SEQUENCING OF COMMANDS AND REPLIES - - The communication between the sender and receiver is intended to - be an alternating dialogue, controlled by the sender. As such, - the sender issues a command and the receiver responds with a - reply. The sender must wait for this response before sending - further commands. - - One important reply is the connection greeting. Normally, a - receiver will send a 220 "Service ready" reply when the connection - is completed. The sender should wait for this greeting message - before sending any commands. - - Note: all the greeting type replies have the official name of - the server host as the first word following the reply code. - - For example, - - 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF> - - The table below lists alternative success and failure replies for - each command. These must be strictly adhered to; a receiver may - substitute text in the replies, but the meaning and action implied - by the code numbers and by the specific command reply sequence - cannot be altered. - - COMMAND-REPLY SEQUENCES - - Each command is listed with its possible replies. The prefixes - used before the possible replies are "P" for preliminary (not - used in SMTP), "I" for intermediate, "S" for success, "F" for - failure, and "E" for error. The 421 reply (service not - available, closing transmission channel) may be given to any - command if the SMTP-receiver knows it must shut down. This - listing forms the basis for the State Diagrams in Section 4.4. - - CONNECTION ESTABLISHMENT - S: 220 - F: 421 - HELO - S: 250 - E: 500, 501, 504, 421 - MAIL - S: 250 - F: 552, 451, 452 - E: 500, 501, 421 - - - -Postel [Page 37] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - RCPT - S: 250, 251 - F: 550, 551, 552, 553, 450, 451, 452 - E: 500, 501, 503, 421 - DATA - I: 354 -> data -> S: 250 - F: 552, 554, 451, 452 - F: 451, 554 - E: 500, 501, 503, 421 - RSET - S: 250 - E: 500, 501, 504, 421 - SEND - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - SOML - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - SAML - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - VRFY - S: 250, 251 - F: 550, 551, 553 - E: 500, 501, 502, 504, 421 - EXPN - S: 250 - F: 550 - E: 500, 501, 502, 504, 421 - HELP - S: 211, 214 - E: 500, 501, 502, 504, 421 - NOOP - S: 250 - E: 500, 421 - QUIT - S: 221 - E: 500 - TURN - S: 250 - F: 502 - E: 500, 503 - - - - -[Page 38] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.4. STATE DIAGRAMS - - Following are state diagrams for a simple-minded SMTP - implementation. Only the first digit of the reply codes is used. - There is one state diagram for each group of SMTP commands. The - command groupings were determined by constructing a model for each - command and then collecting together the commands with - structurally identical models. - - For each command there are three possible outcomes: "success" - (S), "failure" (F), and "error" (E). In the state diagrams below - we use the symbol B for "begin", and the symbol W for "wait for - reply". - - First, the diagram that represents most of the SMTP commands: - - - 1,3 +---+ - ----------->| E | - | +---+ - | - +---+ cmd +---+ 2 +---+ - | B |---------->| W |---------->| S | - +---+ +---+ +---+ - | - | 4,5 +---+ - ----------->| F | - +---+ - - - This diagram models the commands: - - HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, - NOOP, QUIT, TURN. - - - - - - - - - - - - - - - -Postel [Page 39] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - A more complex diagram models the DATA command: - - - +---+ DATA +---+ 1,2 +---+ - | B |---------->| W |-------------------->| E | - +---+ +---+ ------------>+---+ - 3| |4,5 | - | | | - -------------- ----- | - | | | +---+ - | ---------- -------->| S | - | | | | +---+ - | | ------------ - | | | | - V 1,3| |2 | - +---+ data +---+ --------------->+---+ - | |---------->| W | | F | - +---+ +---+-------------------->+---+ - 4,5 - - - Note that the "data" here is a series of lines sent from the - sender to the receiver with no response expected until the last - line is sent. - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 40] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.5. DETAILS - - 4.5.1. MINIMUM IMPLEMENTATION - - In order to make SMTP workable, the following minimum - implementation is required for all receivers: - - COMMANDS -- HELO - MAIL - RCPT - DATA - RSET - NOOP - QUIT - - 4.5.2. TRANSPARENCY - - Without some provision for data transparency the character - sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent - by the user. In general, users are not aware of such - "forbidden" sequences. To allow all user composed text to be - transmitted transparently the following procedures are used. - - 1. Before sending a line of mail text the sender-SMTP checks - the first character of the line. If it is a period, one - additional period is inserted at the beginning of the line. - - 2. When a line of mail text is received by the receiver-SMTP - it checks the line. If the line is composed of a single - period it is the end of mail. If the first character is a - period and there are other characters on the line, the first - character is deleted. - - The mail data may contain any of the 128 ASCII characters. All - characters are to be delivered to the recipient's mailbox - including format effectors and other control characters. If - the transmission channel provides an 8-bit byte (octets) data - stream, the 7-bit ASCII codes are transmitted right justified - in the octets with the high order bits cleared to zero. - - In some systems it may be necessary to transform the data as - it is received and stored. This may be necessary for hosts - that use a different character set than ASCII as their local - character set, or that store data in records rather than - - - - - -Postel [Page 41] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - strings. If such transforms are necessary, they must be - reversible -- especially if such transforms are applied to - mail being relayed. - - 4.5.3. SIZES - - There are several objects that have required minimum maximum - sizes. That is, every implementation must be able to receive - objects of at least these sizes, but must not send objects - larger than these sizes. - - - **************************************************** - * * - * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * - * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * - * OF THESE OBJECTS SHOULD BE USED. * - * * - **************************************************** - - user - - The maximum total length of a user name is 64 characters. - - domain - - The maximum total length of a domain name or number is 64 - characters. - - path - - The maximum total length of a reverse-path or - forward-path is 256 characters (including the punctuation - and element separators). - - command line - - The maximum total length of a command line including the - command word and the <CRLF> is 512 characters. - - reply line - - The maximum total length of a reply line including the - reply code and the <CRLF> is 512 characters. - - - - - -[Page 42] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - text line - - The maximum total length of a text line including the - <CRLF> is 1000 characters (but not counting the leading - dot duplicated for transparency). - - recipients buffer - - The maximum total number of recipients that must be - buffered is 100 recipients. - - - **************************************************** - * * - * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * - * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * - * OF THESE OBJECTS SHOULD BE USED. * - * * - **************************************************** - - Errors due to exceeding these limits may be reported by using - the reply codes, for example: - - 500 Line too long. - - 501 Path too long - - 552 Too many recipients. - - 552 Too much mail data. - - - - - - - - - - - - - - - - - - - -Postel [Page 43] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -APPENDIX A - - TCP Transport service - - The Transmission Control Protocol [3] is used in the ARPA - Internet, and in any network following the US DoD standards for - internetwork protocols. - - Connection Establishment - - The SMTP transmission channel is a TCP connection established - between the sender process port U and the receiver process port - L. This single full duplex connection is used as the - transmission channel. This protocol is assigned the service - port 25 (31 octal), that is L=25. - - Data Transfer - - The TCP connection supports the transmission of 8-bit bytes. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 44] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -APPENDIX B - - NCP Transport service - - The ARPANET Host-to-Host Protocol [4] (implemented by the Network - Control Program) may be used in the ARPANET. - - Connection Establishment - - The SMTP transmission channel is established via NCP between - the sender process socket U and receiver process socket L. The - Initial Connection Protocol [5] is followed resulting in a pair - of simplex connections. This pair of connections is used as - the transmission channel. This protocol is assigned the - contact socket 25 (31 octal), that is L=25. - - Data Transfer - - The NCP data connections are established in 8-bit byte mode. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 45] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -APPENDIX C - - NITS - - The Network Independent Transport Service [6] may be used. - - Connection Establishment - - The SMTP transmission channel is established via NITS between - the sender process and receiver process. The sender process - executes the CONNECT primitive, and the waiting receiver - process executes the ACCEPT primitive. - - Data Transfer - - The NITS connection supports the transmission of 8-bit bytes. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 46] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -APPENDIX D - - X.25 Transport service - - It may be possible to use the X.25 service [7] as provided by the - Public Data Networks directly, however, it is suggested that a - reliable end-to-end protocol such as TCP be used on top of X.25 - connections. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 47] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -APPENDIX E - - Theory of Reply Codes - - The three digits of the reply each have a special significance. - The first digit denotes whether the response is good, bad or - incomplete. An unsophisticated sender-SMTP will be able to - determine its next action (proceed as planned, redo, retrench, - etc.) by simply examining this first digit. A sender-SMTP that - wants to know approximately what kind of error occurred (e.g., - mail system error, command syntax error) may examine the second - digit, reserving the third digit for the finest gradation of - information. - - There are five values for the first digit of the reply code: - - 1yz Positive Preliminary reply - - The command has been accepted, but the requested action - is being held in abeyance, pending confirmation of the - information in this reply. The sender-SMTP should send - another command specifying whether to continue or abort - the action. - - [Note: SMTP does not have any commands that allow this - type of reply, and so does not have the continue or - abort commands.] - - 2yz Positive Completion reply - - The requested action has been successfully completed. A - new request may be initiated. - - 3yz Positive Intermediate reply - - The command has been accepted, but the requested action - is being held in abeyance, pending receipt of further - information. The sender-SMTP should send another command - specifying this information. This reply is used in - command sequence groups. - - 4yz Transient Negative Completion reply - - The command was not accepted and the requested action did - not occur. However, the error condition is temporary and - the action may be requested again. The sender should - - - -[Page 48] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - return to the beginning of the command sequence (if any). - It is difficult to assign a meaning to "transient" when - two different sites (receiver- and sender- SMTPs) must - agree on the interpretation. Each reply in this category - might have a different time value, but the sender-SMTP is - encouraged to try again. A rule of thumb to determine if - a reply fits into the 4yz or the 5yz category (see below) - is that replies are 4yz if they can be repeated without - any change in command form or in properties of the sender - or receiver. (E.g., the command is repeated identically - and the receiver does not put up a new implementation.) - - 5yz Permanent Negative Completion reply - - The command was not accepted and the requested action did - not occur. The sender-SMTP is discouraged from repeating - the exact request (in the same sequence). Even some - "permanent" error conditions can be corrected, so the - human user may want to direct the sender-SMTP to - reinitiate the command sequence by direct action at some - point in the future (e.g., after the spelling has been - changed, or the user has altered the account status). - - The second digit encodes responses in specific categories: - - x0z Syntax -- These replies refer to syntax errors, - syntactically correct commands that don't fit any - functional category, and unimplemented or superfluous - commands. - - x1z Information -- These are replies to requests for - information, such as status or help. - - x2z Connections -- These are replies referring to the - transmission channel. - - x3z Unspecified as yet. - - x4z Unspecified as yet. - - x5z Mail system -- These replies indicate the status of - the receiver mail system vis-a-vis the requested - transfer or other mail system action. - - The third digit gives a finer gradation of meaning in each - category specified by the second digit. The list of replies - - - -Postel [Page 49] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - illustrates this. Each reply text is recommended rather than - mandatory, and may even change according to the command with - which it is associated. On the other hand, the reply codes - must strictly follow the specifications in this section. - Receiver implementations should not invent new codes for - slightly different situations from the ones described here, but - rather adapt codes already defined. - - For example, a command such as NOOP whose successful execution - does not offer the sender-SMTP any new information will return - a 250 reply. The response is 502 when the command requests an - unimplemented non-site-specific action. A refinement of that - is the 504 reply for a command that is implemented, but that - requests an unimplemented parameter. - - The reply text may be longer than a single line; in these cases - the complete text must be marked so the sender-SMTP knows when it - can stop reading the reply. This requires a special format to - indicate a multiple line reply. - - The format for multiline replies requires that every line, - except the last, begin with the reply code, followed - immediately by a hyphen, "-" (also known as minus), followed by - text. The last line will begin with the reply code, followed - immediately by <SP>, optionally some text, and <CRLF>. - - For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - - In many cases the sender-SMTP then simply needs to search for - the reply code followed by <SP> at the beginning of a line, and - ignore all preceding lines. In a few cases, there is important - data for the sender in the reply "text". The sender will know - these cases from the current context. - - - - - - - - - - - - -[Page 50] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -APPENDIX F - - Scenarios - - This section presents complete scenarios of several types of SMTP - sessions. - - A Typical SMTP Transaction Scenario - - This SMTP example shows mail sent by Smith at host USC-ISIF, to - Jones, Green, and Brown at host BBN-UNIX. Here we assume that - host USC-ISIF contacts host BBN-UNIX directly. The mail is - accepted for Jones and Brown. Green does not have a mailbox at - host BBN-UNIX. - - ------------------------------------------------------------- - - R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BBN-UNIX.ARPA - - S: MAIL FROM:<Smith@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@BBN-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<Green@BBN-UNIX.ARPA> - R: 550 No such user here - - S: RCPT TO:<Brown@BBN-UNIX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BBN-UNIX.ARPA Service closing transmission channel - - Scenario 1 - - ------------------------------------------------------------- - - - -Postel [Page 51] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Aborted SMTP Transaction Scenario - - ------------------------------------------------------------- - - R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready - S: HELO ISI-VAXA.ARPA - R: 250 MIT-Multics.ARPA - - S: MAIL FROM:<Smith@ISI-VAXA.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@MIT-Multics.ARPA> - R: 250 OK - - S: RCPT TO:<Green@MIT-Multics.ARPA> - R: 550 No such user here - - S: RSET - R: 250 OK - - S: QUIT - R: 221 MIT-Multics.ARPA Service closing transmission channel - - Scenario 2 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - - - - - -[Page 52] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Relayed Mail Scenario - - ------------------------------------------------------------- - - Step 1 -- Source Host to Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-AI.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM:<JQP@MIT-AI.ARPA> - R: 250 OK - - S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public <JQP@MIT-AI.ARPA> - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - - - - - - - - - - - - - - - - -Postel [Page 53] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Step 2 -- Relay Host to Destination Host - - R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIE.ARPA - R: 250 BBN-VAX.ARPA - - S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@BBN-VAX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; - 2 Nov 81 22:40:10 UT - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public <JQP@MIT-AI.ARPA> - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 3 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - -[Page 54] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Verifying and Sending Scenario - - ------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> - - S: SEND FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 4 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - -Postel [Page 55] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Sending and Mailing Scenarios - - First the user's name is verified, then an attempt is made to - send to the user's terminal. When that fails, the messages is - mailed to the user's mailbox. - - ------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> - - S: SEND FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 450 User not active now - - S: RSET - R: 250 OK - - S: MAIL FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 5 - - ------------------------------------------------------------- - - - - - - -[Page 56] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Doing the preceding scenario more efficiently. - - ------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> - - S: SOML FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 250 User not active now, so will do mail. - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 6 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - -Postel [Page 57] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Mailing List Scenario - - First each of two mailing lists are expanded in separate sessions - with different hosts. Then the message is sent to everyone that - appeared on either list (but no duplicates) via a relay host. - - ------------------------------------------------------------- - - Step 1 -- Expanding the First List - - R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-AI.ARPA - - S: EXPN Example-People - R: 250-<ABC@MIT-MC.ARPA> - R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA> - R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<joe@foo-unix.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - S: QUIT - R: 221 MIT-AI.ARPA Service closing transmission channel - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 58] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Step 2 -- Expanding the Second List - - R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-MC.ARPA - - S: EXPN Interested-Parties - R: 250-Al Calico <ABC@MIT-MC.ARPA> - R: 250-<XYZ@MIT-AI.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<fred@BBN-UNIX.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - S: QUIT - R: 221 MIT-MC.ARPA Service closing transmission channel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 59] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Step 3 -- Mailing to All via a Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM:<Account.Person@SU-SCORE.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> - R: 250 OK - S: RCPT - TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 7 - - ------------------------------------------------------------- - - - - - - - - - - - - -[Page 60] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Forwarding Scenarios - - ------------------------------------------------------------- - - R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready - S: HELO LBL-UNIX.ARPA - R: 250 USC-ISIF.ARPA - - S: MAIL FROM:<mo@LBL-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<fred@USC-ISIF.ARPA> - R: 251 User not local; will forward to <Jones@USC-ISI.ARPA> - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIF.ARPA Service closing transmission channel - - Scenario 8 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 61] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Step 1 -- Trying the Mailbox at the First Host - - R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready - S: HELO LBL-UNIX.ARPA - R: 250 USC-ISIF.ARPA - - S: MAIL FROM:<mo@LBL-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<fred@USC-ISIF.ARPA> - R: 251 User not local; will forward to <Jones@USC-ISI.ARPA> - - S: RSET - R: 250 OK - - S: QUIT - R: 221 USC-ISIF.ARPA Service closing transmission channel - - Step 2 -- Delivering the Mail at the Second Host - - R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready - S: HELO LBL-UNIX.ARPA - R: 250 USC-ISI.ARPA - - S: MAIL FROM:<mo@LBL-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@USC-ISI.ARPA> - R: OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISI.ARPA Service closing transmission channel - - Scenario 9 - - ------------------------------------------------------------- - - - - -[Page 62] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Too Many Recipients Scenario - - ------------------------------------------------------------- - - R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BERKELEY.ARPA - - S: MAIL FROM:<Postel@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<fabry@BERKELEY.ARPA> - R: 250 OK - - S: RCPT TO:<eric@BERKELEY.ARPA> - R: 552 Recipient storage full, try again in another transaction - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: MAIL FROM:<Postel@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<eric@BERKELEY.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BERKELEY.ARPA Service closing transmission channel - - Scenario 10 - - ------------------------------------------------------------- - - Note that a real implementation must handle many recipients as - specified in Section 4.5.3. - - - -Postel [Page 63] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -GLOSSARY - - ASCII - - American Standard Code for Information Interchange [1]. - - command - - A request for a mail service action sent by the sender-SMTP to the - receiver-SMTP. - - domain - - The hierarchially structured global character string address of a - host computer in the mail system. - - end of mail data indication - - A special sequence of characters that indicates the end of the - mail data. In particular, the five characters carriage return, - line feed, period, carriage return, line feed, in that order. - - host - - A computer in the internetwork environment on which mailboxes or - SMTP processes reside. - - line - - A a sequence of ASCII characters ending with a <CRLF>. - - mail data - - A sequence of ASCII characters of arbitrary length, which conforms - to the standard set in the Standard for the Format of ARPA - Internet Text Messages (RFC 822 [2]). - - mailbox - - A character string (address) which identifies a user to whom mail - is to be sent. Mailbox normally consists of the host and user - specifications. The standard mailbox naming convention is defined - to be "user@domain". Additionally, the "container" in which mail - is stored. - - - - - -[Page 64] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - receiver-SMTP process - - A process which transfers mail in cooperation with a sender-SMTP - process. It waits for a connection to be established via the - transport service. It receives SMTP commands from the - sender-SMTP, sends replies, and performs the specified operations. - - reply - - A reply is an acknowledgment (positive or negative) sent from - receiver to sender via the transmission channel in response to a - command. The general form of a reply is a completion code - (including error codes) followed by a text string. The codes are - for use by programs and the text is usually intended for human - users. - - sender-SMTP process - - A process which transfers mail in cooperation with a receiver-SMTP - process. A local language may be used in the user interface - command/reply dialogue. The sender-SMTP initiates the transport - service connection. It initiates SMTP commands, receives replies, - and governs the transfer of mail. - - session - - The set of exchanges that occur while the transmission channel is - open. - - transaction - - The set of exchanges required for one message to be transmitted - for one or more recipients. - - transmission channel - - A full-duplex communication path between a sender-SMTP and a - receiver-SMTP for the exchange of commands, replies, and mail - text. - - transport service - - Any reliable stream-oriented data communication services. For - example, NCP, TCP, NITS. - - - - - -Postel [Page 65] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - user - - A human being (or a process on behalf of a human being) wishing to - obtain mail transfer service. In addition, a recipient of - computer mail. - - word - - A sequence of printing characters. - - <CRLF> - - The characters carriage return and line feed (in that order). - - <SP> - - The space character. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 66] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -REFERENCES - - [1] ASCII - - ASCII, "USA Code for Information Interchange", United States of - America Standards Institute, X3.4, 1968. Also in: Feinler, E. - and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for - the Defense Communications Agency by SRI International, Menlo - Park, California, Revised January 1978. - - [2] RFC 822 - - Crocker, D., "Standard for the Format of ARPA Internet Text - Messages," RFC 822, Department of Electrical Engineering, - University of Delaware, August 1982. - - [3] TCP - - Postel, J., ed., "Transmission Control Protocol - DARPA Internet - Program Protocol Specification", RFC 793, USC/Information Sciences - Institute, NTIS AD Number A111091, September 1981. Also in: - Feinler, E. and J. Postel, eds., "Internet Protocol Transition - Workbook", SRI International, Menlo Park, California, March 1982. - - [4] NCP - - McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, - January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET - Protocol Handbook", NIC 7104, for the Defense Communications - Agency by SRI International, Menlo Park, California, Revised - January 1978. - - [5] Initial Connection Protocol - - Postel, J., "Official Initial Connection Protocol", NIC 7101, - 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET - Protocol Handbook", NIC 7104, for the Defense Communications - Agency by SRI International, Menlo Park, California, Revised - January 1978. - - [6] NITS - - PSS/SG3, "A Network Independent Transport Service", Study Group 3, - The Post Office PSS Users Group, February 1980. Available from - the DCPU, National Physical Laboratory, Teddington, UK. - - - - -Postel [Page 67] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - [7] X.25 - - CCITT, "Recommendation X.25 - Interface Between Data Terminal - Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for - Terminals Operating in the Packet Mode on Public Data Networks," - CCITT Orange Book, Vol. VIII.2, International Telephone and - Telegraph Consultative Committee, Geneva, 1976. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 68] Postel - diff --git a/usr.sbin/sendmail/doc/rfc/rfc822.txt b/usr.sbin/sendmail/doc/rfc/rfc822.txt deleted file mode 100644 index 35b09a3..0000000 --- a/usr.sbin/sendmail/doc/rfc/rfc822.txt +++ /dev/null @@ -1,2901 +0,0 @@ - - - - - - - RFC # 822 - - Obsoletes: RFC #733 (NIC #41952) - - - - - - - - - - - - - STANDARD FOR THE FORMAT OF - - ARPA INTERNET TEXT MESSAGES - - - - - - - August 13, 1982 - - - - - - - Revised by - - David H. Crocker - - - Dept. of Electrical Engineering - University of Delaware, Newark, DE 19711 - Network: DCrocker @ UDel-Relay - - - - - - - - - - - - - - - - Standard for ARPA Internet Text Messages - - - TABLE OF CONTENTS - - - PREFACE .................................................... ii - - 1. INTRODUCTION ........................................... 1 - - 1.1. Scope ............................................ 1 - 1.2. Communication Framework .......................... 2 - - 2. NOTATIONAL CONVENTIONS ................................. 3 - - 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 - - 3.1. General Description .............................. 5 - 3.2. Header Field Definitions ......................... 9 - 3.3. Lexical Tokens ................................... 10 - 3.4. Clarifications ................................... 11 - - 4. MESSAGE SPECIFICATION .................................. 17 - - 4.1. Syntax ........................................... 17 - 4.2. Forwarding ....................................... 19 - 4.3. Trace Fields ..................................... 20 - 4.4. Originator Fields ................................ 21 - 4.5. Receiver Fields .................................. 23 - 4.6. Reference Fields ................................. 23 - 4.7. Other Fields ..................................... 24 - - 5. DATE AND TIME SPECIFICATION ............................ 26 - - 5.1. Syntax ........................................... 26 - 5.2. Semantics ........................................ 26 - - 6. ADDRESS SPECIFICATION .................................. 27 - - 6.1. Syntax ........................................... 27 - 6.2. Semantics ........................................ 27 - 6.3. Reserved Address ................................. 33 - - 7. BIBLIOGRAPHY ........................................... 34 - - - APPENDIX - - A. EXAMPLES ............................................... 36 - B. SIMPLE FIELD PARSING ................................... 40 - C. DIFFERENCES FROM RFC #733 .............................. 41 - D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 - - - August 13, 1982 - i - RFC #822 - - - - - Standard for ARPA Internet Text Messages - - - PREFACE - - - By 1977, the Arpanet employed several informal standards for - the text messages (mail) sent among its host computers. It was - felt necessary to codify these practices and provide for those - features that seemed imminent. The result of that effort was - Request for Comments (RFC) #733, "Standard for the Format of ARPA - Network Text Message", by Crocker, Vittal, Pogran, and Henderson. - The specification attempted to avoid major changes in existing - software, while permitting several new features. - - This document revises the specifications in RFC #733, in - order to serve the needs of the larger and more complex ARPA - Internet. Some of RFC #733's features failed to gain adequate - acceptance. In order to simplify the standard and the software - that follows it, these features have been removed. A different - addressing scheme is used, to handle the case of inter-network - mail; and the concept of re-transmission has been introduced. - - This specification is intended for use in the ARPA Internet. - However, an attempt has been made to free it of any dependence on - that environment, so that it can be applied to other network text - message systems. - - The specification of RFC #733 took place over the course of - one year, using the ARPANET mail environment, itself, to provide - an on-going forum for discussing the capabilities to be included. - More than twenty individuals, from across the country, partici- - pated in the original discussion. The development of this - revised specification has, similarly, utilized network mail-based - group discussion. Both specification efforts greatly benefited - from the comments and ideas of the participants. - - The syntax of the standard, in RFC #733, was originally - specified in the Backus-Naur Form (BNF) meta-language. Ken L. - Harrenstien, of SRI International, was responsible for re-coding - the BNF into an augmented BNF that makes the representation - smaller and easier to understand. - - - - - - - - - - - - - August 13, 1982 - ii - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 1. INTRODUCTION - - 1.1. SCOPE - - This standard specifies a syntax for text messages that are - sent among computer users, within the framework of "electronic - mail". The standard supersedes the one specified in ARPANET - Request for Comments #733, "Standard for the Format of ARPA Net- - work Text Messages". - - In this context, messages are viewed as having an envelope - and contents. The envelope contains whatever information is - needed to accomplish transmission and delivery. The contents - compose the object to be delivered to the recipient. This stan- - dard applies only to the format and some of the semantics of mes- - sage contents. It contains no specification of the information - in the envelope. - - However, some message systems may use information from the - contents to create the envelope. It is intended that this stan- - dard facilitate the acquisition of such information by programs. - - Some message systems may store messages in formats that - differ from the one specified in this standard. This specifica- - tion is intended strictly as a definition of what message content - format is to be passed BETWEEN hosts. - - Note: This standard is NOT intended to dictate the internal for- - mats used by sites, the specific message system features - that they are expected to support, or any of the charac- - teristics of user interface programs that create or read - messages. - - A distinction should be made between what the specification - REQUIRES and what it ALLOWS. Messages can be made complex and - rich with formally-structured components of information or can be - kept small and simple, with a minimum of such information. Also, - the standard simplifies the interpretation of differing visual - formats in messages; only the visual aspect of a message is - affected and not the interpretation of information within it. - Implementors may choose to retain such visual distinctions. - - The formal definition is divided into four levels. The bot- - tom level describes the meta-notation used in this document. The - second level describes basic lexical analyzers that feed tokens - to higher-level parsers. Next is an overall specification for - messages; it permits distinguishing individual fields. Finally, - there is definition of the contents of several structured fields. - - - - August 13, 1982 - 1 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 1.2. COMMUNICATION FRAMEWORK - - Messages consist of lines of text. No special provisions - are made for encoding drawings, facsimile, speech, or structured - text. No significant consideration has been given to questions - of data compression or to transmission and storage efficiency, - and the standard tends to be free with the number of bits con- - sumed. For example, field names are specified as free text, - rather than special terse codes. - - A general "memo" framework is used. That is, a message con- - sists of some information in a rigid format, followed by the main - part of the message, with a format that is not specified in this - document. The syntax of several fields of the rigidly-formated - ("headers") section is defined in this specification; some of - these fields must be included in all messages. - - The syntax that distinguishes between header fields is - specified separately from the internal syntax for particular - fields. This separation is intended to allow simple parsers to - operate on the general structure of messages, without concern for - the detailed structure of individual header fields. Appendix B - is provided to facilitate construction of these parsers. - - In addition to the fields specified in this document, it is - expected that other fields will gain common use. As necessary, - the specifications for these "extension-fields" will be published - through the same mechanism used to publish this document. Users - may also wish to extend the set of fields that they use - privately. Such "user-defined fields" are permitted. - - The framework severely constrains document tone and appear- - ance and is primarily useful for most intra-organization communi- - cations and well-structured inter-organization communication. - It also can be used for some types of inter-process communica- - tion, such as simple file transfer and remote job entry. A more - robust framework might allow for multi-font, multi-color, multi- - dimension encoding of information. A less robust one, as is - present in most single-machine message systems, would more - severely constrain the ability to add fields and the decision to - include specific fields. In contrast with paper-based communica- - tion, it is interesting to note that the RECEIVER of a message - can exercise an extraordinary amount of control over the - message's appearance. The amount of actual control available to - message receivers is contingent upon the capabilities of their - individual message systems. - - - - - - August 13, 1982 - 2 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 2. NOTATIONAL CONVENTIONS - - This specification uses an augmented Backus-Naur Form (BNF) - notation. The differences from standard BNF involve naming rules - and indicating repetition and "local" alternatives. - - 2.1. RULE NAMING - - Angle brackets ("<", ">") are not used, in general. The - name of a rule is simply the name itself, rather than "<name>". - Quotation-marks enclose literal text (which may be upper and/or - lower case). Certain basic rules are in uppercase, such as - SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in - rule definitions, and in the rest of this document, whenever - their presence will facilitate discerning the use of rule names. - - 2.2. RULE1 / RULE2: ALTERNATIVES - - Elements separated by slash ("/") are alternatives. There- - fore "foo / bar" will accept foo or bar. - - 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES - - Elements enclosed in parentheses are treated as a single - element. Thus, "(elem (foo / bar) elem)" allows the token - sequences "elem foo elem" and "elem bar elem". - - 2.4. *RULE: REPETITION - - The character "*" preceding an element indicates repetition. - The full form is: - - <l>*<m>element - - indicating at least <l> and at most <m> occurrences of element. - Default values are 0 and infinity so that "*(element)" allows any - number, including zero; "1*element" requires at least one; and - "1*2element" allows one or two. - - 2.5. [RULE]: OPTIONAL - - Square brackets enclose optional elements; "[foo bar]" is - equivalent to "*1(foo bar)". - - 2.6. NRULE: SPECIFIC REPETITION - - "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, - exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit - number, and 3ALPHA is a string of three alphabetic characters. - - - August 13, 1982 - 3 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 2.7. #RULE: LISTS - - A construct "#" is defined, similar to "*", as follows: - - <l>#<m>element - - indicating at least <l> and at most <m> elements, each separated - by one or more commas (","). This makes the usual form of lists - very easy; a rule such as '(element *("," element))' can be shown - as "1#element". Wherever this construct is used, null elements - are allowed, but do not contribute to the count of elements - present. That is, "(element),,(element)" is permitted, but - counts as only two elements. Therefore, where at least one ele- - ment is required, at least one non-null element must be present. - Default values are 0 and infinity so that "#(element)" allows any - number, including zero; "1#element" requires at least one; and - "1#2element" allows one or two. - - 2.8. ; COMMENTS - - A semi-colon, set off some distance to the right of rule - text, starts a comment that continues to the end of line. This - is a simple way of including useful notes in parallel with the - specifications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 4 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3. LEXICAL ANALYSIS OF MESSAGES - - 3.1. GENERAL DESCRIPTION - - A message consists of header fields and, optionally, a body. - The body is simply a sequence of lines containing ASCII charac- - ters. It is separated from the headers by a null line (i.e., a - line with nothing preceding the CRLF). - - 3.1.1. LONG HEADER FIELDS - - Each header field can be viewed as a single, logical line of - ASCII characters, comprising a field-name and a field-body. - For convenience, the field-body portion of this conceptual - entity can be split into a multiple-line representation; this - is called "folding". The general rule is that wherever there - may be linear-white-space (NOT simply LWSP-chars), a CRLF - immediately followed by AT LEAST one LWSP-char may instead be - inserted. Thus, the single line - - To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN - - can be represented as: - - To: "Joe & J. Harvey" <ddd @ Org>, - JJV@BBN - - and - - To: "Joe & J. Harvey" - <ddd@ Org>, JJV - @BBN - - and - - To: "Joe & - J. Harvey" <ddd @ Org>, JJV @ BBN - - The process of moving from this folded multiple-line - representation of a header field to its single line represen- - tation is called "unfolding". Unfolding is accomplished by - regarding CRLF immediately followed by a LWSP-char as - equivalent to the LWSP-char. - - Note: While the standard permits folding wherever linear- - white-space is permitted, it is recommended that struc- - tured fields, such as those containing addresses, limit - folding to higher-level syntactic breaks. For address - fields, it is recommended that such folding occur - - - August 13, 1982 - 5 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - between addresses, after the separating comma. - - 3.1.2. STRUCTURE OF HEADER FIELDS - - Once a field has been unfolded, it may be viewed as being com- - posed of a field-name followed by a colon (":"), followed by a - field-body, and terminated by a carriage-return/line-feed. - The field-name must be composed of printable ASCII characters - (i.e., characters that have values between 33. and 126., - decimal, except colon). The field-body may be composed of any - ASCII characters, except CR or LF. (While CR and/or LF may be - present in the actual text, they are removed by the action of - unfolding the field.) - - Certain field-bodies of headers may be interpreted according - to an internal syntax that some systems may wish to parse. - These fields are called "structured fields". Examples - include fields containing dates and addresses. Other fields, - such as "Subject" and "Comments", are regarded simply as - strings of text. - - Note: Any field which has a field-body that is defined as - other than simply <text> is to be treated as a struc- - tured field. - - Field-names, unstructured field bodies and structured - field bodies each are scanned by their own, independent - "lexical" analyzers. - - 3.1.3. UNSTRUCTURED FIELD BODIES - - For some fields, such as "Subject" and "Comments", no struc- - turing is assumed, and they are treated simply as <text>s, as - in the message body. Rules of folding apply to these fields, - so that such field bodies which occupy several lines must - therefore have the second and successive lines indented by at - least one LWSP-char. - - 3.1.4. STRUCTURED FIELD BODIES - - To aid in the creation and reading of structured fields, the - free insertion of linear-white-space (which permits folding - by inclusion of CRLFs) is allowed between lexical tokens. - Rather than obscuring the syntax specifications for these - structured fields with explicit syntax for this linear-white- - space, the existence of another "lexical" analyzer is assumed. - This analyzer does not apply for unstructured field bodies - that are simply strings of text, as described above. The - analyzer provides an interpretation of the unfolded text - - - August 13, 1982 - 6 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - composing the body of the field as a sequence of lexical sym- - bols. - - These symbols are: - - - individual special characters - - quoted-strings - - domain-literals - - comments - - atoms - - The first four of these symbols are self-delimiting. Atoms - are not; they are delimited by the self-delimiting symbols and - by linear-white-space. For the purposes of regenerating - sequences of atoms and quoted-strings, exactly one SPACE is - assumed to exist, and should be used, between them. (Also, in - the "Clarifications" section on "White Space", below, note the - rules about treatment of multiple contiguous LWSP-chars.) - - So, for example, the folded body of an address field - - ":sysmail"@ Some-Group. Some-Org, - Muhammed.(I am the greatest) Ali @(the)Vegas.WBA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 7 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - is analyzed into the following lexical symbols and types: - - :sysmail quoted string - @ special - Some-Group atom - . special - Some-Org atom - , special - Muhammed atom - . special - (I am the greatest) comment - Ali atom - @ atom - (the) comment - Vegas atom - . special - WBA atom - - The canonical representations for the data in these addresses - are the following strings: - - ":sysmail"@Some-Group.Some-Org - - and - - Muhammed.Ali@Vegas.WBA - - Note: For purposes of display, and when passing such struc- - tured information to other systems, such as mail proto- - col services, there must be NO linear-white-space - between <word>s that are separated by period (".") or - at-sign ("@") and exactly one SPACE between all other - <word>s. Also, headers should be in a folded form. - - - - - - - - - - - - - - - - - - - August 13, 1982 - 8 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.2. HEADER FIELD DEFINITIONS - - These rules show a field meta-syntax, without regard for the - particular type or internal syntax. Their purpose is to permit - detection of fields; also, they present to higher-level parsers - an image of each field as fitting on one line. - - field = field-name ":" [ field-body ] CRLF - - field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> - - field-body = field-body-contents - [CRLF LWSP-char field-body] - - field-body-contents = - <the ASCII characters making up the field-body, as - defined in the following sections, and consisting - of combinations of atom, quoted-string, and - specials tokens, or else consisting of texts> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 9 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.3. LEXICAL TOKENS - - The following rules are used to define an underlying lexical - analyzer, which feeds tokens to higher level parsers. See the - ANSI references, in the Bibliography. - - ; ( Octal, Decimal.) - CHAR = <any ASCII character> ; ( 0-177, 0.-127.) - ALPHA = <any ASCII alphabetic character> - ; (101-132, 65.- 90.) - ; (141-172, 97.-122.) - DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.) - CTL = <any ASCII control ; ( 0- 37, 0.- 31.) - character and DEL> ; ( 177, 127.) - CR = <ASCII CR, carriage return> ; ( 15, 13.) - LF = <ASCII LF, linefeed> ; ( 12, 10.) - SPACE = <ASCII SP, space> ; ( 40, 32.) - HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.) - <"> = <ASCII quote mark> ; ( 42, 34.) - CRLF = CR LF - - LWSP-char = SPACE / HTAB ; semantics = SPACE - - linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE - ; CRLF => folding - - specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- - / "," / ";" / ":" / "\" / <"> ; string, to use - / "." / "[" / "]" ; within a word. - - delimiters = specials / linear-white-space / comment - - text = <any CHAR, including bare ; => atoms, specials, - CR & bare LF, but NOT ; comments and - including CRLF> ; quoted-strings are - ; NOT recognized. - - atom = 1*<any CHAR except specials, SPACE and CTLs> - - quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or - ; quoted chars. - - qtext = <any CHAR excepting <">, ; => may be folded - "\" & CR, and including - linear-white-space> - - domain-literal = "[" *(dtext / quoted-pair) "]" - - - - - August 13, 1982 - 10 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - dtext = <any CHAR excluding "[", ; => may be folded - "]", "\" & CR, & including - linear-white-space> - - comment = "(" *(ctext / quoted-pair / comment) ")" - - ctext = <any CHAR excluding "(", ; => may be folded - ")", "\" & CR, & including - linear-white-space> - - quoted-pair = "\" CHAR ; may quote any char - - phrase = 1*word ; Sequence of words - - word = atom / quoted-string - - - 3.4. CLARIFICATIONS - - 3.4.1. QUOTING - - Some characters are reserved for special interpretation, such - as delimiting lexical tokens. To permit use of these charac- - ters as uninterpreted data, a quoting mechanism is provided. - To quote a character, precede it with a backslash ("\"). - - This mechanism is not fully general. Characters may be quoted - only within a subset of the lexical constructs. In particu- - lar, quoting is limited to use within: - - - quoted-string - - domain-literal - - comment - - Within these constructs, quoting is REQUIRED for CR and "\" - and for the character(s) that delimit the token (e.g., "(" and - ")" for a comment). However, quoting is PERMITTED for any - character. - - Note: In particular, quoting is NOT permitted within atoms. - For example when the local-part of an addr-spec must - contain a special character, a quoted string must be - used. Therefore, a specification such as: - - Full\ Name@Domain - - is not legal and must be specified as: - - "Full Name"@Domain - - - August 13, 1982 - 11 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.4.2. WHITE SPACE - - Note: In structured field bodies, multiple linear space ASCII - characters (namely HTABs and SPACEs) are treated as - single spaces and may freely surround any symbol. In - all header fields, the only place in which at least one - LWSP-char is REQUIRED is at the beginning of continua- - tion lines in a folded field. - - When passing text to processes that do not interpret text - according to this standard (e.g., mail protocol servers), then - NO linear-white-space characters should occur between a period - (".") or at-sign ("@") and a <word>. Exactly ONE SPACE should - be used in place of arbitrary linear-white-space and comment - sequences. - - Note: Within systems conforming to this standard, wherever a - member of the list of delimiters is allowed, LWSP-chars - may also occur before and/or after it. - - Writers of mail-sending (i.e., header-generating) programs - should realize that there is no network-wide definition of the - effect of ASCII HT (horizontal-tab) characters on the appear- - ance of text at another network host; therefore, the use of - tabs in message headers, though permitted, is discouraged. - - 3.4.3. COMMENTS - - A comment is a set of ASCII characters, which is enclosed in - matching parentheses and which is not within a quoted-string - The comment construct permits message originators to add text - which will be useful for human readers, but which will be - ignored by the formal semantics. Comments should be retained - while the message is subject to interpretation according to - this standard. However, comments must NOT be included in - other cases, such as during protocol exchanges with mail - servers. - - Comments nest, so that if an unquoted left parenthesis occurs - in a comment string, there must also be a matching right - parenthesis. When a comment acts as the delimiter between a - sequence of two lexical symbols, such as two atoms, it is lex- - ically equivalent with a single SPACE, for the purposes of - regenerating the sequence, such as when passing the sequence - onto a mail protocol server. Comments are detected as such - only within field-bodies of structured fields. - - If a comment is to be "folded" onto multiple lines, then the - syntax for folding must be adhered to. (See the "Lexical - - - August 13, 1982 - 12 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Analysis of Messages" section on "Folding Long Header Fields" - above, and the section on "Case Independence" below.) Note - that the official semantics therefore do not "see" any - unquoted CRLFs that are in comments, although particular pars- - ing programs may wish to note their presence. For these pro- - grams, it would be reasonable to interpret a "CRLF LWSP-char" - as being a CRLF that is part of the comment; i.e., the CRLF is - kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a - backslash followed by a CR followed by a LF) still must be - followed by at least one LWSP-char. - - 3.4.4. DELIMITING AND QUOTING CHARACTERS - - The quote character (backslash) and characters that delimit - syntactic units are not, generally, to be taken as data that - are part of the delimited or quoted unit(s). In particular, - the quotation-marks that define a quoted-string, the - parentheses that define a comment and the backslash that - quotes a following character are NOT part of the quoted- - string, comment or quoted character. A quotation-mark that is - to be part of a quoted-string, a parenthesis that is to be - part of a comment and a backslash that is to be part of either - must each be preceded by the quote-character backslash ("\"). - Note that the syntax allows any character to be quoted within - a quoted-string or comment; however only certain characters - MUST be quoted to be included as data. These characters are - the ones that are not part of the alternate text group (i.e., - ctext or qtext). - - The one exception to this rule is that a single SPACE is - assumed to exist between contiguous words in a phrase, and - this interpretation is independent of the actual number of - LWSP-chars that the creator places between the words. To - include more than one SPACE, the creator must make the LWSP- - chars be part of a quoted-string. - - Quotation marks that delimit a quoted string and backslashes - that quote the following character should NOT accompany the - quoted-string when the string is passed to processes that do - not interpret data according to this specification (e.g., mail - protocol servers). - - 3.4.5. QUOTED-STRINGS - - Where permitted (i.e., in words in structured fields) quoted- - strings are treated as a single symbol. That is, a quoted- - string is equivalent to an atom, syntactically. If a quoted- - string is to be "folded" onto multiple lines, then the syntax - for folding must be adhered to. (See the "Lexical Analysis of - - - August 13, 1982 - 13 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Messages" section on "Folding Long Header Fields" above, and - the section on "Case Independence" below.) Therefore, the - official semantics do not "see" any bare CRLFs that are in - quoted-strings; however particular parsing programs may wish - to note their presence. For such programs, it would be rea- - sonable to interpret a "CRLF LWSP-char" as being a CRLF which - is part of the quoted-string; i.e., the CRLF is kept and the - LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- - lowed by a CR followed by a LF) are also subject to rules of - folding, but the presence of the quoting character (backslash) - explicitly indicates that the CRLF is data to the quoted - string. Stripping off the first following LWSP-char is also - appropriate when parsing quoted CRLFs. - - 3.4.6. BRACKETING CHARACTERS - - There is one type of bracket which must occur in matched pairs - and may have pairs nested within each other: - - o Parentheses ("(" and ")") are used to indicate com- - ments. - - There are three types of brackets which must occur in matched - pairs, and which may NOT be nested: - - o Colon/semi-colon (":" and ";") are used in address - specifications to indicate that the included list of - addresses are to be treated as a group. - - o Angle brackets ("<" and ">") are generally used to - indicate the presence of a one machine-usable refer- - ence (e.g., delimiting mailboxes), possibly including - source-routing to the machine. - - o Square brackets ("[" and "]") are used to indicate the - presence of a domain-literal, which the appropriate - name-domain is to use directly, bypassing normal - name-resolution mechanisms. - - 3.4.7. CASE INDEPENDENCE - - Except as noted, alphabetic strings may be represented in any - combination of upper and lower case. The only syntactic units - - - - - - - - - August 13, 1982 - 14 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - which requires preservation of case information are: - - - text - - qtext - - dtext - - ctext - - quoted-pair - - local-part, except "Postmaster" - - When matching any other syntactic unit, case is to be ignored. - For example, the field-names "From", "FROM", "from", and even - "FroM" are semantically equal and should all be treated ident- - ically. - - When generating these units, any mix of upper and lower case - alphabetic characters may be used. The case shown in this - specification is suggested for message-creating processes. - - Note: The reserved local-part address unit, "Postmaster", is - an exception. When the value "Postmaster" is being - interpreted, it must be accepted in any mixture of - case, including "POSTMASTER", and "postmaster". - - 3.4.8. FOLDING LONG HEADER FIELDS - - Each header field may be represented on exactly one line con- - sisting of the name of the field and its body, and terminated - by a CRLF; this is what the parser sees. For readability, the - field-body portion of long header fields may be "folded" onto - multiple lines of the actual field. "Long" is commonly inter- - preted to mean greater than 65 or 72 characters. The former - length serves as a limit, when the message is to be viewed on - most simple terminals which use simple display software; how- - ever, the limit is not imposed by this standard. - - Note: Some display software often can selectively fold lines, - to suit the display terminal. In such cases, sender- - provided folding can interfere with the display - software. - - 3.4.9. BACKSPACE CHARACTERS - - ASCII BS characters (Backspace, decimal 8) may be included in - texts and quoted-strings to effect overstriking. However, any - use of backspaces which effects an overstrike to the left of - the beginning of the text or quoted-string is prohibited. - - - - - - August 13, 1982 - 15 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS - - During transmission through heterogeneous networks, it may be - necessary to force data to conform to a network's local con- - ventions. For example, it may be required that a CR be fol- - lowed either by LF, making a CRLF, or by <null>, if the CR is - to stand alone). Such transformations are reversed, when the - message exits that network. - - When crossing network boundaries, the message should be - treated as passing through two modules. It will enter the - first module containing whatever network-specific transforma- - tions that were necessary to permit migration through the - "current" network. It then passes through the modules: - - o Transformation Reversal - - The "current" network's idiosyncracies are removed and - the message is returned to the canonical form speci- - fied in this standard. - - o Transformation - - The "next" network's local idiosyncracies are imposed - on the message. - - ------------------ - From ==> | Remove Net-A | - Net-A | idiosyncracies | - ------------------ - || - \/ - Conformance - with standard - || - \/ - ------------------ - | Impose Net-B | ==> To - | idiosyncracies | Net-B - ------------------ - - - - - - - - - - - - August 13, 1982 - 16 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 4. MESSAGE SPECIFICATION - - 4.1. SYNTAX - - Note: Due to an artifact of the notational conventions, the syn- - tax indicates that, when present, some fields, must be in - a particular order. Header fields are NOT required to - occur in any particular order, except that the message - body must occur AFTER the headers. It is recommended - that, if present, headers be sent in the order "Return- - Path", "Received", "Date", "From", "Subject", "Sender", - "To", "cc", etc. - - This specification permits multiple occurrences of most - fields. Except as noted, their interpretation is not - specified here, and their use is discouraged. - - The following syntax for the bodies of various fields should - be thought of as describing each field body as a single long - string (or line). The "Lexical Analysis of Message" section on - "Long Header Fields", above, indicates how such long strings can - be represented on more than one line in the actual transmitted - message. - - message = fields *( CRLF *text ) ; Everything after - ; first null line - ; is message body - - fields = dates ; Creation time, - source ; author id & one - 1*destination ; address required - *optional-field ; others optional - - source = [ trace ] ; net traversals - originator ; original mail - [ resent ] ; forwarded - - trace = return ; path to sender - 1*received ; receipt tags - - return = "Return-path" ":" route-addr ; return address - - received = "Received" ":" ; one per relay - ["from" domain] ; sending host - ["by" domain] ; receiving host - ["via" atom] ; physical path - *("with" atom) ; link/mail protocol - ["id" msg-id] ; receiver msg id - ["for" addr-spec] ; initial form - - - August 13, 1982 - 17 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - ";" date-time ; time received - - originator = authentic ; authenticated addr - [ "Reply-To" ":" 1#address] ) - - authentic = "From" ":" mailbox ; Single author - / ( "Sender" ":" mailbox ; Actual submittor - "From" ":" 1#mailbox) ; Multiple authors - ; or not sender - - resent = resent-authentic - [ "Resent-Reply-To" ":" 1#address] ) - - resent-authentic = - = "Resent-From" ":" mailbox - / ( "Resent-Sender" ":" mailbox - "Resent-From" ":" 1#mailbox ) - - dates = orig-date ; Original - [ resent-date ] ; Forwarded - - orig-date = "Date" ":" date-time - - resent-date = "Resent-Date" ":" date-time - - destination = "To" ":" 1#address ; Primary - / "Resent-To" ":" 1#address - / "cc" ":" 1#address ; Secondary - / "Resent-cc" ":" 1#address - / "bcc" ":" #address ; Blind carbon - / "Resent-bcc" ":" #address - - optional-field = - / "Message-ID" ":" msg-id - / "Resent-Message-ID" ":" msg-id - / "In-Reply-To" ":" *(phrase / msg-id) - / "References" ":" *(phrase / msg-id) - / "Keywords" ":" #phrase - / "Subject" ":" *text - / "Comments" ":" *text - / "Encrypted" ":" 1#2word - / extension-field ; To be defined - / user-defined-field ; May be pre-empted - - msg-id = "<" addr-spec ">" ; Unique message id - - - - - - - August 13, 1982 - 18 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - extension-field = - <Any field which is defined in a document - published as a formal extension to this - specification; none will have names beginning - with the string "X-"> - - user-defined-field = - <Any field which has not been defined - in this specification or published as an - extension to this specification; names for - such fields must be unique and may be - pre-empted by published extensions> - - 4.2. FORWARDING - - Some systems permit mail recipients to forward a message, - retaining the original headers, by adding some new fields. This - standard supports such a service, through the "Resent-" prefix to - field names. - - Whenever the string "Resent-" begins a field name, the field - has the same semantics as a field whose name does not have the - prefix. However, the message is assumed to have been forwarded - by an original recipient who attached the "Resent-" field. This - new field is treated as being more recent than the equivalent, - original field. For example, the "Resent-From", indicates the - person that forwarded the message, whereas the "From" field indi- - cates the original author. - - Use of such precedence information depends upon partici- - pants' communication needs. For example, this standard does not - dictate when a "Resent-From:" address should receive replies, in - lieu of sending them to the "From:" address. - - Note: In general, the "Resent-" fields should be treated as con- - taining a set of information that is independent of the - set of original fields. Information for one set should - not automatically be taken from the other. The interpre- - tation of multiple "Resent-" fields, of the same type, is - undefined. - - In the remainder of this specification, occurrence of legal - "Resent-" fields are treated identically with the occurrence of - - - - - - - - - August 13, 1982 - 19 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - fields whose names do not contain this prefix. - - 4.3. TRACE FIELDS - - Trace information is used to provide an audit trail of mes- - sage handling. In addition, it indicates a route back to the - sender of the message. - - The list of known "via" and "with" values are registered - with the Network Information Center, SRI International, Menlo - Park, California. - - 4.3.1. RETURN-PATH - - This field is added by the final transport system that - delivers the message to its recipient. The field is intended - to contain definitive information about the address and route - back to the message's originator. - - Note: The "Reply-To" field is added by the originator and - serves to direct replies, whereas the "Return-Path" - field is used to identify a path back to the origina- - tor. - - While the syntax indicates that a route specification is - optional, every attempt should be made to provide that infor- - mation in this field. - - 4.3.2. RECEIVED - - A copy of this field is added by each transport service that - relays the message. The information in the field can be quite - useful for tracing transport problems. - - The names of the sending and receiving hosts and time-of- - receipt may be specified. The "via" parameter may be used, to - indicate what physical mechanism the message was sent over, - such as Arpanet or Phonenet, and the "with" parameter may be - used to indicate the mail-, or connection-, level protocol - that was used, such as the SMTP mail protocol, or X.25 tran- - sport protocol. - - Note: Several "with" parameters may be included, to fully - specify the set of protocols that were used. - - Some transport services queue mail; the internal message iden- - tifier that is assigned to the message may be noted, using the - "id" parameter. When the sending host uses a destination - address specification that the receiving host reinterprets, by - - - August 13, 1982 - 20 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - expansion or transformation, the receiving host may wish to - record the original specification, using the "for" parameter. - For example, when a copy of mail is sent to the member of a - distribution list, this parameter may be used to record the - original address that was used to specify the list. - - 4.4. ORIGINATOR FIELDS - - The standard allows only a subset of the combinations possi- - ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, - and Resent-Reply-To fields. The limitation is intentional. - - 4.4.1. FROM / RESENT-FROM - - This field contains the identity of the person(s) who wished - this message to be sent. The message-creation process should - default this field to be a single, authenticated machine - address, indicating the AGENT (person, system or process) - entering the message. If this is not done, the "Sender" field - MUST be present. If the "From" field IS defaulted this way, - the "Sender" field is optional and is redundant with the - "From" field. In all cases, addresses in the "From" field - must be machine-usable (addr-specs) and may not contain named - lists (groups). - - 4.4.2. SENDER / RESENT-SENDER - - This field contains the authenticated identity of the AGENT - (person, system or process) that sends the message. It is - intended for use when the sender is not the author of the mes- - sage, or to indicate who among a group of authors actually - sent the message. If the contents of the "Sender" field would - be completely redundant with the "From" field, then the - "Sender" field need not be present and its use is discouraged - (though still legal). In particular, the "Sender" field MUST - be present if it is NOT the same as the "From" Field. - - The Sender mailbox specification includes a word sequence - which must correspond to a specific agent (i.e., a human user - or a computer program) rather than a standard address. This - indicates the expectation that the field will identify the - single AGENT (person, system, or process) responsible for - sending the mail and not simply include the name of a mailbox - from which the mail was sent. For example in the case of a - shared login name, the name, by itself, would not be adequate. - The local-part address unit, which refers to this agent, is - expected to be a computer system term, and not (for example) a - generalized person reference which can be used outside the - network text message context. - - - August 13, 1982 - 21 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Since the critical function served by the "Sender" field is - identification of the agent responsible for sending mail and - since computer programs cannot be held accountable for their - behavior, it is strongly recommended that when a computer pro- - gram generates a message, the HUMAN who is responsible for - that program be referenced as part of the "Sender" field mail- - box specification. - - 4.4.3. REPLY-TO / RESENT-REPLY-TO - - This field provides a general mechanism for indicating any - mailbox(es) to which responses are to be sent. Three typical - uses for this feature can be distinguished. In the first - case, the author(s) may not have regular machine-based mail- - boxes and therefore wish(es) to indicate an alternate machine - address. In the second case, an author may wish additional - persons to be made aware of, or responsible for, replies. A - somewhat different use may be of some help to "text message - teleconferencing" groups equipped with automatic distribution - services: include the address of that service in the "Reply- - To" field of all messages submitted to the teleconference; - then participants can "reply" to conference submissions to - guarantee the correct distribution of any submission of their - own. - - Note: The "Return-Path" field is added by the mail transport - service, at the time of final deliver. It is intended - to identify a path back to the orginator of the mes- - sage. The "Reply-To" field is added by the message - originator and is intended to direct replies. - - 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO - - For systems which automatically generate address lists for - replies to messages, the following recommendations are made: - - o The "Sender" field mailbox should be sent notices of - any problems in transport or delivery of the original - messages. If there is no "Sender" field, then the - "From" field mailbox should be used. - - o The "Sender" field mailbox should NEVER be used - automatically, in a recipient's reply message. - - o If the "Reply-To" field exists, then the reply should - go to the addresses indicated in that field and not to - the address(es) indicated in the "From" field. - - - - - August 13, 1982 - 22 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - o If there is a "From" field, but no "Reply-To" field, - the reply should be sent to the address(es) indicated - in the "From" field. - - Sometimes, a recipient may actually wish to communicate with - the person that initiated the message transfer. In such - cases, it is reasonable to use the "Sender" address. - - This recommendation is intended only for automated use of - originator-fields and is not intended to suggest that replies - may not also be sent to other recipients of messages. It is - up to the respective mail-handling programs to decide what - additional facilities will be provided. - - Examples are provided in Appendix A. - - 4.5. RECEIVER FIELDS - - 4.5.1. TO / RESENT-TO - - This field contains the identity of the primary recipients of - the message. - - 4.5.2. CC / RESENT-CC - - This field contains the identity of the secondary (informa- - tional) recipients of the message. - - 4.5.3. BCC / RESENT-BCC - - This field contains the identity of additional recipients of - the message. The contents of this field are not included in - copies of the message sent to the primary and secondary reci- - pients. Some systems may choose to include the text of the - "Bcc" field only in the author(s)'s copy, while others may - also include it in the text sent to all those indicated in the - "Bcc" list. - - 4.6. REFERENCE FIELDS - - 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID - - This field contains a unique identifier (the local-part - address unit) which refers to THIS version of THIS message. - The uniqueness of the message identifier is guaranteed by the - host which generates it. This identifier is intended to be - machine readable and not necessarily meaningful to humans. A - message identifier pertains to exactly one instantiation of a - particular message; subsequent revisions to the message should - - - August 13, 1982 - 23 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - each receive new message identifiers. - - 4.6.2. IN-REPLY-TO - - The contents of this field identify previous correspon- - dence which this message answers. Note that if message iden- - tifiers are used in this field, they must use the msg-id - specification format. - - 4.6.3. REFERENCES - - The contents of this field identify other correspondence - which this message references. Note that if message identif- - iers are used, they must use the msg-id specification format. - - 4.6.4. KEYWORDS - - This field contains keywords or phrases, separated by - commas. - - 4.7. OTHER FIELDS - - 4.7.1. SUBJECT - - This is intended to provide a summary, or indicate the - nature, of the message. - - 4.7.2. COMMENTS - - Permits adding text comments onto the message without - disturbing the contents of the message's body. - - 4.7.3. ENCRYPTED - - Sometimes, data encryption is used to increase the - privacy of message contents. If the body of a message has - been encrypted, to keep its contents private, the "Encrypted" - field can be used to note the fact and to indicate the nature - of the encryption. The first <word> parameter indicates the - software used to encrypt the body, and the second, optional - <word> is intended to aid the recipient in selecting the - proper decryption key. This code word may be viewed as an - index to a table of keys held by the recipient. - - Note: Unfortunately, headers must contain envelope, as well - as contents, information. Consequently, it is neces- - sary that they remain unencrypted, so that mail tran- - sport services may access them. Since names, - addresses, and "Subject" field contents may contain - - - August 13, 1982 - 24 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - sensitive information, this requirement limits total - message privacy. - - Names of encryption software are registered with the Net- - work Information Center, SRI International, Menlo Park, Cali- - fornia. - - 4.7.4. EXTENSION-FIELD - - A limited number of common fields have been defined in - this document. As network mail requirements dictate, addi- - tional fields may be standardized. To provide user-defined - fields with a measure of safety, in name selection, such - extension-fields will never have names that begin with the - string "X-". - - Names of Extension-fields are registered with the Network - Information Center, SRI International, Menlo Park, California. - - 4.7.5. USER-DEFINED-FIELD - - Individual users of network mail are free to define and - use additional header fields. Such fields must have names - which are not already used in the current specification or in - any definitions of extension-fields, and the overall syntax of - these user-defined-fields must conform to this specification's - rules for delimiting and folding fields. Due to the - extension-field publishing process, the name of a user- - defined-field may be pre-empted - - Note: The prefatory string "X-" will never be used in the - names of Extension-fields. This provides user-defined - fields with a protected set of names. - - - - - - - - - - - - - - - - - - - August 13, 1982 - 25 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 5. DATE AND TIME SPECIFICATION - - 5.1. SYNTAX - - date-time = [ day "," ] date time ; dd mm yy - ; hh:mm:ss zzz - - day = "Mon" / "Tue" / "Wed" / "Thu" - / "Fri" / "Sat" / "Sun" - - date = 1*2DIGIT month 2DIGIT ; day month year - ; e.g. 20 Jun 82 - - month = "Jan" / "Feb" / "Mar" / "Apr" - / "May" / "Jun" / "Jul" / "Aug" - / "Sep" / "Oct" / "Nov" / "Dec" - - time = hour zone ; ANSI and Military - - hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] - ; 00:00:00 - 23:59:59 - - zone = "UT" / "GMT" ; Universal Time - ; North American : UT - / "EST" / "EDT" ; Eastern: - 5/ - 4 - / "CST" / "CDT" ; Central: - 6/ - 5 - / "MST" / "MDT" ; Mountain: - 7/ - 6 - / "PST" / "PDT" ; Pacific: - 8/ - 7 - / 1ALPHA ; Military: Z = UT; - ; A:-1; (J not used) - ; M:-12; N:+1; Y:+12 - / ( ("+" / "-") 4DIGIT ) ; Local differential - ; hours+min. (HHMM) - - 5.2. SEMANTICS - - If included, day-of-week must be the day implied by the date - specification. - - Time zone may be indicated in several ways. "UT" is Univer- - sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- - mitted as a reference to Universal Time. The military standard - uses a single character for each zone. "Z" is Universal Time. - "A" indicates one hour earlier, and "M" indicates 12 hours ear- - lier; "N" is one hour later, and "Y" is 12 hours later. The - letter "J" is not used. The other remaining two forms are taken - from ANSI standard X3.51-1975. One allows explicit indication of - the amount of offset from UT; the other uses common 3-character - strings for indicating time zones in North America. - - - August 13, 1982 - 26 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 6. ADDRESS SPECIFICATION - - 6.1. SYNTAX - - address = mailbox ; one addressee - / group ; named list - - group = phrase ":" [#mailbox] ";" - - mailbox = addr-spec ; simple address - / phrase route-addr ; name & addr-spec - - route-addr = "<" [route] addr-spec ">" - - route = 1#("@" domain) ":" ; path-relative - - addr-spec = local-part "@" domain ; global address - - local-part = word *("." word) ; uninterpreted - ; case-preserved - - domain = sub-domain *("." sub-domain) - - sub-domain = domain-ref / domain-literal - - domain-ref = atom ; symbolic reference - - 6.2. SEMANTICS - - A mailbox receives mail. It is a conceptual entity which - does not necessarily pertain to file storage. For example, some - sites may choose to print mail on their line printer and deliver - the output to the addressee's desk. - - A mailbox specification comprises a person, system or pro- - cess name reference, a domain-dependent string, and a name-domain - reference. The name reference is optional and is usually used to - indicate the human name of a recipient. The name-domain refer- - ence specifies a sequence of sub-domains. The domain-dependent - string is uninterpreted, except by the final sub-domain; the rest - of the mail service merely transmits it as a literal string. - - 6.2.1. DOMAINS - - A name-domain is a set of registered (mail) names. A name- - domain specification resolves to a subordinate name-domain - specification or to a terminal domain-dependent string. - Hence, domain specification is extensible, permitting any - number of registration levels. - - - August 13, 1982 - 27 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Name-domains model a global, logical, hierarchical addressing - scheme. The model is logical, in that an address specifica- - tion is related to name registration and is not necessarily - tied to transmission path. The model's hierarchy is a - directed graph, called an in-tree, such that there is a single - path from the root of the tree to any node in the hierarchy. - If more than one path actually exists, they are considered to - be different addresses. - - The root node is common to all addresses; consequently, it is - not referenced. Its children constitute "top-level" name- - domains. Usually, a service has access to its own full domain - specification and to the names of all top-level name-domains. - - The "top" of the domain addressing hierarchy -- a child of the - root -- is indicated by the right-most field, in a domain - specification. Its child is specified to the left, its child - to the left, and so on. - - Some groups provide formal registration services; these con- - stitute name-domains that are independent logically of - specific machines. In addition, networks and machines impli- - citly compose name-domains, since their membership usually is - registered in name tables. - - In the case of formal registration, an organization implements - a (distributed) data base which provides an address-to-route - mapping service for addresses of the form: - - person@registry.organization - - Note that "organization" is a logical entity, separate from - any particular communication network. - - A mechanism for accessing "organization" is universally avail- - able. That mechanism, in turn, seeks an instantiation of the - registry; its location is not indicated in the address specif- - ication. It is assumed that the system which operates under - the name "organization" knows how to find a subordinate regis- - try. The registry will then use the "person" string to deter- - mine where to send the mail specification. - - The latter, network-oriented case permits simple, direct, - attachment-related address specification, such as: - - user@host.network - - Once the network is accessed, it is expected that a message - will go directly to the host and that the host will resolve - - - August 13, 1982 - 28 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - the user name, placing the message in the user's mailbox. - - 6.2.2. ABBREVIATED DOMAIN SPECIFICATION - - Since any number of levels is possible within the domain - hierarchy, specification of a fully qualified address can - become inconvenient. This standard permits abbreviated domain - specification, in a special case: - - For the address of the sender, call the left-most - sub-domain Level N. In a header address, if all of - the sub-domains above (i.e., to the right of) Level N - are the same as those of the sender, then they do not - have to appear in the specification. Otherwise, the - address must be fully qualified. - - This feature is subject to approval by local sub- - domains. Individual sub-domains may require their - member systems, which originate mail, to provide full - domain specification only. When permitted, abbrevia- - tions may be present only while the message stays - within the sub-domain of the sender. - - Use of this mechanism requires the sender's sub-domain - to reserve the names of all top-level domains, so that - full specifications can be distinguished from abbrevi- - ated specifications. - - For example, if a sender's address is: - - sender@registry-A.registry-1.organization-X - - and one recipient's address is: - - recipient@registry-B.registry-1.organization-X - - and another's is: - - recipient@registry-C.registry-2.organization-X - - then ".registry-1.organization-X" need not be specified in the - the message, but "registry-C.registry-2" DOES have to be - specified. That is, the first two addresses may be abbrevi- - ated, but the third address must be fully specified. - - When a message crosses a domain boundary, all addresses must - be specified in the full format, ending with the top-level - name-domain in the right-most field. It is the responsibility - of mail forwarding services to ensure that addresses conform - - - August 13, 1982 - 29 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - with this requirement. In the case of abbreviated addresses, - the relaying service must make the necessary expansions. It - should be noted that it often is difficult for such a service - to locate all occurrences of address abbreviations. For exam- - ple, it will not be possible to find such abbreviations within - the body of the message. The "Return-Path" field can aid - recipients in recovering from these errors. - - Note: When passing any portion of an addr-spec onto a process - which does not interpret data according to this stan- - dard (e.g., mail protocol servers). There must be NO - LWSP-chars preceding or following the at-sign or any - delimiting period ("."), such as shown in the above - examples, and only ONE SPACE between contiguous - <word>s. - - 6.2.3. DOMAIN TERMS - - A domain-ref must be THE official name of a registry, network, - or host. It is a symbolic reference, within a name sub- - domain. At times, it is necessary to bypass standard mechan- - isms for resolving such references, using more primitive - information, such as a network host address rather than its - associated host name. - - To permit such references, this standard provides the domain- - literal construct. Its contents must conform with the needs - of the sub-domain in which it is interpreted. - - Domain-literals which refer to domains within the ARPA Inter- - net specify 32-bit Internet addresses, in four 8-bit fields - noted in decimal, as described in Request for Comments #820, - "Assigned Numbers." For example: - - [10.0.3.19] - - Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It - is permitted only as a means of bypassing temporary - system limitations, such as name tables which are not - complete. - - The names of "top-level" domains, and the names of domains - under in the ARPA Internet, are registered with the Network - Information Center, SRI International, Menlo Park, California. - - 6.2.4. DOMAIN-DEPENDENT LOCAL STRING - - The local-part of an addr-spec in a mailbox specification - (i.e., the host's name for the mailbox) is understood to be - - - August 13, 1982 - 30 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - whatever the receiving mail protocol server allows. For exam- - ple, some systems do not understand mailbox references of the - form "P. D. Q. Bach", but others do. - - This specification treats periods (".") as lexical separators. - Hence, their presence in local-parts which are not quoted- - strings, is detected. However, such occurrences carry NO - semantics. That is, if a local-part has periods within it, an - address parser will divide the local-part into several tokens, - but the sequence of tokens will be treated as one uninter- - preted unit. The sequence will be re-assembled, when the - address is passed outside of the system such as to a mail pro- - tocol service. - - For example, the address: - - First.Last@Registry.Org - - is legal and does not require the local-part to be surrounded - with quotation-marks. (However, "First Last" DOES require - quoting.) The local-part of the address, when passed outside - of the mail system, within the Registry.Org domain, is - "First.Last", again without quotation marks. - - 6.2.5. BALANCING LOCAL-PART AND DOMAIN - - In some cases, the boundary between local-part and domain can - be flexible. The local-part may be a simple string, which is - used for the final determination of the recipient's mailbox. - All other levels of reference are, therefore, part of the - domain. - - For some systems, in the case of abbreviated reference to the - local and subordinate sub-domains, it may be possible to - specify only one reference within the domain part and place - the other, subordinate name-domain references within the - local-part. This would appear as: - - mailbox.sub1.sub2@this-domain - - Such a specification would be acceptable to address parsers - which conform to RFC #733, but do not support this newer - Internet standard. While contrary to the intent of this stan- - dard, the form is legal. - - Also, some sub-domains have a specification syntax which does - not conform to this standard. For example: - - sub-net.mailbox@sub-domain.domain - - - August 13, 1982 - 31 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - uses a different parsing sequence for local-part than for - domain. - - Note: As a rule, the domain specification should contain - fields which are encoded according to the syntax of - this standard and which contain generally-standardized - information. The local-part specification should con- - tain only that portion of the address which deviates - from the form or intention of the domain field. - - 6.2.6. MULTIPLE MAILBOXES - - An individual may have several mailboxes and wish to receive - mail at whatever mailbox is convenient for the sender to - access. This standard does not provide a means of specifying - "any member of" a list of mailboxes. - - A set of individuals may wish to receive mail as a single unit - (i.e., a distribution list). The <group> construct permits - specification of such a list. Recipient mailboxes are speci- - fied within the bracketed part (":" - ";"). A copy of the - transmitted message is to be sent to each mailbox listed. - This standard does not permit recursive specification of - groups within groups. - - While a list must be named, it is not required that the con- - tents of the list be included. In this case, the <address> - serves only as an indication of group distribution and would - appear in the form: - - name:; - - Some mail services may provide a group-list distribution - facility, accepting a single mailbox reference, expanding it - to the full distribution list, and relaying the mail to the - list's members. This standard provides no additional syntax - for indicating such a service. Using the <group> address - alternative, while listing one mailbox in it, can mean either - that the mailbox reference will be expanded to a list or that - there is a group with one member. - - 6.2.7. EXPLICIT PATH SPECIFICATION - - At times, a message originator may wish to indicate the - transmission path that a message should follow. This is - called source routing. The normal addressing scheme, used in - an addr-spec, is carefully separated from such information; - the <route> portion of a route-addr is provided for such occa- - sions. It specifies the sequence of hosts and/or transmission - - - August 13, 1982 - 32 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - services that are to be traversed. Both domain-refs and - domain-literals may be used. - - Note: The use of source routing is discouraged. Unless the - sender has special need of path restriction, the choice - of transmission route should be left to the mail tran- - sport service. - - 6.3. RESERVED ADDRESS - - It often is necessary to send mail to a site, without know- - ing any of its valid addresses. For example, there may be mail - system dysfunctions, or a user may wish to find out a person's - correct address, at that site. - - This standard specifies a single, reserved mailbox address - (local-part) which is to be valid at each site. Mail sent to - that address is to be routed to a person responsible for the - site's mail system or to a person with responsibility for general - site operation. The name of the reserved local-part address is: - - Postmaster - - so that "Postmaster@domain" is required to be valid. - - Note: This reserved local-part must be matched without sensi- - tivity to alphabetic case, so that "POSTMASTER", "postmas- - ter", and even "poStmASteR" is to be accepted. - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 33 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 7. BIBLIOGRAPHY - - - ANSI. "USA Standard Code for Information Interchange," X3.4. - American National Standards Institute: New York (1968). Also - in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- - book", NIC 7104. - - ANSI. "Representations of Universal Time, Local Time Differen- - tials, and United States Time Zone References for Information - Interchange," X3.51-1975. American National Standards Insti- - tute: New York (1975). - - Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. - 1979). - - Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- - ford and Appleton Laboratory: Didcot, England. - - Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. - "Standardizing Network Mail Headers," ARPANET Request for - Comments No. 561, Network Information Center No. 18516; SRI - International: Menlo Park (September 1973). - - Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. - "Grapevine: An Exercise in Distributed Computing," Communica- - tions of the ACM 25, 4 (April 1982), 260-274. - - Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. - "Standard for the Format of ARPA Network Text Message," - ARPANET Request for Comments No. 733, Network Information - Center No. 41952. SRI International: Menlo Park (November - 1977). - - Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- - work Information Center No. 7104 (NTIS AD A003890). SRI - International: Menlo Park (April 1976). - - Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. - (1969). - - Levin, R. and Schroeder, M. "Transport of Electronic Messages - through a Network," TeleInformatics 79, pp. 29-33. North - Holland (1979). Also as Xerox Palo Alto Research Center - Technical Report CSL-79-4. - - Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," - ARPANET Request for Comments, No. 680, Network Information - Center No. 32116. SRI International: Menlo Park (1975). - - - August 13, 1982 - 34 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - NBS. "Specification of Message Format for Computer Based Message - Systems, Recommended Federal Information Processing Standard." - National Bureau of Standards: Gaithersburg, Maryland - (October 1981). - - NIC. Internet Protocol Transition Workbook. Network Information - Center, SRI-International, Menlo Park, California (March - 1982). - - Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized - Agent for Locating Named Objects in a Distributed Environ- - ment," OPD-T8103. Xerox Office Products Division: Palo Alto, - CA. (October 1981). - - Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, - No. 820. SRI International: Menlo Park (August 1982). - - Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request - for Comments, No. 821. SRI International: Menlo Park (August - 1982). - - Shoch, J.F. "Internetwork naming, addressing and routing," in - Proc. 17th IEEE Computer Society International Conference, pp. - 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. - - Su, Z. and Postel, J. "The Domain Naming Convention for Internet - User Applications," ARPANET Request for Comments, No. 819. - SRI International: Menlo Park (August 1982). - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 35 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - APPENDIX - - - A. EXAMPLES - - A.1. ADDRESSES - - A.1.1. Alfred Neuman <Neuman@BBN-TENEXA> - - A.1.2. Neuman@BBN-TENEXA - - These two "Alfred Neuman" examples have identical seman- - tics, as far as the operation of the local host's mail sending - (distribution) program (also sometimes called its "mailer") - and the remote host's mail protocol server are concerned. In - the first example, the "Alfred Neuman" is ignored by the - mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- - pient. The second example contains no superfluous informa- - tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- - pient. - - Note: When the message crosses name-domain boundaries, then - these specifications must be changed, so as to indicate - the remainder of the hierarchy, starting with the top - level. - - A.1.3. "George, Ted" <Shared@Group.Arpanet> - - This form might be used to indicate that a single mailbox - is shared by several users. The quoted string is ignored by - the originating host's mailer, because "Shared@Group.Arpanet" - completely specifies the destination mailbox. - - A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US - - The "(the Stilt)" is a comment, which is NOT included in - the destination mailbox address handed to the originating - system's mailer. The local-part of the address is the string - "Wilt.Chamberlain", with NO space between the first and second - words. - - A.1.5. Address Lists - - Gourmets: Pompous Person <WhoZiWhatZit@Cordon-Bleu>, - Childs@WGBH.Boston, Galloping Gourmet@ - ANT.Down-Under (Australian National Television), - Cheapie@Discount-Liquors;, - Cruisers: Port@Portugal, Jones@SEA;, - Another@Somewhere.SomeOrg - - - August 13, 1982 - 36 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - This group list example points out the use of comments and the - mixing of addresses and groups. - - A.2. ORIGINATOR ITEMS - - A.2.1. Author-sent - - George Jones logs into his host as "Jones". He sends - mail himself. - - From: Jones@Group.Org - - or - - From: George Jones <Jones@Group.Org> - - A.2.2. Secretary-sent - - George Jones logs in as Jones on his host. His secre- - tary, who logs in as Secy sends mail for him. Replies to the - mail should go to George. - - From: George Jones <Jones@Group> - Sender: Secy@Other-Group - - A.2.3. Secretary-sent, for user of shared directory - - George Jones' secretary sends mail for George. Replies - should go to George. - - From: George Jones<Shared@Group.Org> - Sender: Secy@Other-Group - - Note that there need not be a space between "Jones" and the - "<", but adding a space enhances readability (as is the case - in other examples. - - A.2.4. Committee activity, with one author - - George is a member of a committee. He wishes to have any - replies to his message go to all committee members. - - From: George Jones <Jones@Host.Net> - Sender: Jones@Host - Reply-To: The Committee: Jones@Host.Net, - Smith@Other.Org, - Doe@Somewhere-Else; - - Note that if George had not included himself in the - - - August 13, 1982 - 37 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - enumeration of The Committee, he would not have gotten an - implicit reply; the presence of the "Reply-to" field SUPER- - SEDES the sending of a reply to the person named in the "From" - field. - - A.2.5. Secretary acting as full agent of author - - George Jones asks his secretary (Secy@Host) to send a - message for him in his capacity as Group. He wants his secre- - tary to handle all replies. - - From: George Jones <Group@Host> - Sender: Secy@Host - Reply-To: Secy@Host - - A.2.6. Agent for user without online mailbox - - A friend of George's, Sarah, is visiting. George's - secretary sends some mail to a friend of Sarah in computer- - land. Replies should go to George, whose mailbox is Jones at - Registry. - - From: Sarah Friendly <Secy@Registry> - Sender: Secy-Name <Secy@Registry> - Reply-To: Jones@Registry. - - A.2.7. Agent for member of a committee - - George's secretary sends out a message which was authored - jointly by all the members of a committee. Note that the name - of the committee cannot be specified, since <group> names are - not permitted in the From field. - - From: Jones@Host, - Smith@Other-Host, - Doe@Somewhere-Else - Sender: Secy@SHost - - - - - - - - - - - - - - - August 13, 1982 - 38 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - A.3. COMPLETE HEADERS - - A.3.1. Minimum required - - Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT - From: Jones@Registry.Org or From: Jones@Registry.Org - Bcc: To: Smith@Registry.Org - - Note that the "Bcc" field may be empty, while the "To" field - is required to have at least one address. - - A.3.2. Using some of the additional fields - - Date: 26 Aug 76 1430 EDT - From: George Jones<Group@Host> - Sender: Secy@SHOST - To: "Al Neuman"@Mad-Host, - Sam.Irving@Other-Host - Message-ID: <some.string@SHOST> - - A.3.3. About as complex as you're going to get - - Date : 27 Aug 76 0932 PDT - From : Ken Davis <KDavis@This-Host.This-net> - Subject : Re: The Syntax in the RFC - Sender : KSecy@Other-Host - Reply-To : Sam.Irving@Reg.Organization - To : George Jones <Group@Some-Reg.An-Org>, - Al.Neuman@MAD.Publisher - cc : Important folk: - Tom Softwood <Balsa@Tree.Root>, - "Sam Irving"@Other-Host;, - Standard Distribution: - /main/davis/people/standard@Other-Host, - "<Jones>standard.dist.3"@Tops-20-Host>; - Comment : Sam is away on business. He asked me to handle - his mail for him. He'll be able to provide a - more accurate explanation when he returns - next week. - In-Reply-To: <some.string@DBM.Group>, George's message - X-Special-action: This is a sample of user-defined field- - names. There could also be a field-name - "Special-action", but its name might later be - preempted - Message-ID: <4231.629.XYzi-What@Other-Host> - - - - - - - August 13, 1982 - 39 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - B. SIMPLE FIELD PARSING - - Some mail-reading software systems may wish to perform only - minimal processing, ignoring the internal syntax of structured - field-bodies and treating them the same as unstructured-field- - bodies. Such software will need only to distinguish: - - o Header fields from the message body, - - o Beginnings of fields from lines which continue fields, - - o Field-names from field-contents. - - The abbreviated set of syntactic rules which follows will - suffice for this purpose. It describes a limited view of mes- - sages and is a subset of the syntactic rules provided in the main - part of this specification. One small exception is that the con- - tents of field-bodies consist only of text: - - B.1. SYNTAX - - - message = *field *(CRLF *text) - - field = field-name ":" [field-body] CRLF - - field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> - - field-body = *text [CRLF LWSP-char field-body] - - - B.2. SEMANTICS - - Headers occur before the message body and are terminated by - a null line (i.e., two contiguous CRLFs). - - A line which continues a header field begins with a SPACE or - HTAB character, while a line beginning a field starts with a - printable character which is not a colon. - - A field-name consists of one or more printable characters - (excluding colon, space, and control-characters). A field-name - MUST be contained on one line. Upper and lower case are not dis- - tinguished when comparing field-names. - - - - - - - - August 13, 1982 - 40 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - C. DIFFERENCES FROM RFC #733 - - The following summarizes the differences between this stan- - dard and the one specified in Arpanet Request for Comments #733, - "Standard for the Format of ARPA Network Text Messages". The - differences are listed in the order of their occurrence in the - current specification. - - C.1. FIELD DEFINITIONS - - C.1.1. FIELD NAMES - - These now must be a sequence of printable characters. They - may not contain any LWSP-chars. - - C.2. LEXICAL TOKENS - - C.2.1. SPECIALS - - The characters period ("."), left-square bracket ("["), and - right-square bracket ("]") have been added. For presentation - purposes, and when passing a specification to a system that - does not conform to this standard, periods are to be contigu- - ous with their surrounding lexical tokens. No linear-white- - space is permitted between them. The presence of one LWSP- - char between other tokens is still directed. - - C.2.2. ATOM - - Atoms may not contain SPACE. - - C.2.3. SPECIAL TEXT - - ctext and qtext have had backslash ("\") added to the list of - prohibited characters. - - C.2.4. DOMAINS - - The lexical tokens <domain-literal> and <dtext> have been - added. - - C.3. MESSAGE SPECIFICATION - - C.3.1. TRACE - - The "Return-path:" and "Received:" fields have been specified. - - - - - - August 13, 1982 - 41 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - C.3.2. FROM - - The "From" field must contain machine-usable addresses (addr- - spec). Multiple addresses may be specified, but named-lists - (groups) may not. - - C.3.3. RESENT - - The meta-construct of prefacing field names with the string - "Resent-" has been added, to indicate that a message has been - forwarded by an intermediate recipient. - - C.3.4. DESTINATION - - A message must contain at least one destination address field. - "To" and "CC" are required to contain at least one address. - - C.3.5. IN-REPLY-TO - - The field-body is no longer a comma-separated list, although a - sequence is still permitted. - - C.3.6. REFERENCE - - The field-body is no longer a comma-separated list, although a - sequence is still permitted. - - C.3.7. ENCRYPTED - - A field has been specified that permits senders to indicate - that the body of a message has been encrypted. - - C.3.8. EXTENSION-FIELD - - Extension fields are prohibited from beginning with the char- - acters "X-". - - C.4. DATE AND TIME SPECIFICATION - - C.4.1. SIMPLIFICATION - - Fewer optional forms are permitted and the list of three- - letter time zones has been shortened. - - C.5. ADDRESS SPECIFICATION - - - - - - - August 13, 1982 - 42 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - C.5.1. ADDRESS - - The use of quoted-string, and the ":"-atom-":" construct, have - been removed. An address now is either a single mailbox - reference or is a named list of addresses. The latter indi- - cates a group distribution. - - C.5.2. GROUPS - - Group lists are now required to to have a name. Group lists - may not be nested. - - C.5.3. MAILBOX - - A mailbox specification may indicate a person's name, as - before. Such a named list no longer may specify multiple - mailboxes and may not be nested. - - C.5.4. ROUTE ADDRESSING - - Addresses now are taken to be absolute, global specifications, - independent of transmission paths. The <route> construct has - been provided, to permit explicit specification of transmis- - sion path. RFC #733's use of multiple at-signs ("@") was - intended as a general syntax for indicating routing and/or - hierarchical addressing. The current standard separates these - specifications and only one at-sign is permitted. - - C.5.5. AT-SIGN - - The string " at " no longer is used as an address delimiter. - Only at-sign ("@") serves the function. - - C.5.6. DOMAINS - - Hierarchical, logical name-domains have been added. - - C.6. RESERVED ADDRESS - - The local-part "Postmaster" has been reserved, so that users can - be guaranteed at least one valid address at a site. - - - - - - - - - - - August 13, 1982 - 43 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - D. ALPHABETICAL LISTING OF SYNTAX RULES - - address = mailbox ; one addressee - / group ; named list - addr-spec = local-part "@" domain ; global address - ALPHA = <any ASCII alphabetic character> - ; (101-132, 65.- 90.) - ; (141-172, 97.-122.) - atom = 1*<any CHAR except specials, SPACE and CTLs> - authentic = "From" ":" mailbox ; Single author - / ( "Sender" ":" mailbox ; Actual submittor - "From" ":" 1#mailbox) ; Multiple authors - ; or not sender - CHAR = <any ASCII character> ; ( 0-177, 0.-127.) - comment = "(" *(ctext / quoted-pair / comment) ")" - CR = <ASCII CR, carriage return> ; ( 15, 13.) - CRLF = CR LF - ctext = <any CHAR excluding "(", ; => may be folded - ")", "\" & CR, & including - linear-white-space> - CTL = <any ASCII control ; ( 0- 37, 0.- 31.) - character and DEL> ; ( 177, 127.) - date = 1*2DIGIT month 2DIGIT ; day month year - ; e.g. 20 Jun 82 - dates = orig-date ; Original - [ resent-date ] ; Forwarded - date-time = [ day "," ] date time ; dd mm yy - ; hh:mm:ss zzz - day = "Mon" / "Tue" / "Wed" / "Thu" - / "Fri" / "Sat" / "Sun" - delimiters = specials / linear-white-space / comment - destination = "To" ":" 1#address ; Primary - / "Resent-To" ":" 1#address - / "cc" ":" 1#address ; Secondary - / "Resent-cc" ":" 1#address - / "bcc" ":" #address ; Blind carbon - / "Resent-bcc" ":" #address - DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.) - domain = sub-domain *("." sub-domain) - domain-literal = "[" *(dtext / quoted-pair) "]" - domain-ref = atom ; symbolic reference - dtext = <any CHAR excluding "[", ; => may be folded - "]", "\" & CR, & including - linear-white-space> - extension-field = - <Any field which is defined in a document - published as a formal extension to this - specification; none will have names beginning - with the string "X-"> - - - August 13, 1982 - 44 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - field = field-name ":" [ field-body ] CRLF - fields = dates ; Creation time, - source ; author id & one - 1*destination ; address required - *optional-field ; others optional - field-body = field-body-contents - [CRLF LWSP-char field-body] - field-body-contents = - <the ASCII characters making up the field-body, as - defined in the following sections, and consisting - of combinations of atom, quoted-string, and - specials tokens, or else consisting of texts> - field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> - group = phrase ":" [#mailbox] ";" - hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] - ; 00:00:00 - 23:59:59 - HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.) - LF = <ASCII LF, linefeed> ; ( 12, 10.) - linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE - ; CRLF => folding - local-part = word *("." word) ; uninterpreted - ; case-preserved - LWSP-char = SPACE / HTAB ; semantics = SPACE - mailbox = addr-spec ; simple address - / phrase route-addr ; name & addr-spec - message = fields *( CRLF *text ) ; Everything after - ; first null line - ; is message body - month = "Jan" / "Feb" / "Mar" / "Apr" - / "May" / "Jun" / "Jul" / "Aug" - / "Sep" / "Oct" / "Nov" / "Dec" - msg-id = "<" addr-spec ">" ; Unique message id - optional-field = - / "Message-ID" ":" msg-id - / "Resent-Message-ID" ":" msg-id - / "In-Reply-To" ":" *(phrase / msg-id) - / "References" ":" *(phrase / msg-id) - / "Keywords" ":" #phrase - / "Subject" ":" *text - / "Comments" ":" *text - / "Encrypted" ":" 1#2word - / extension-field ; To be defined - / user-defined-field ; May be pre-empted - orig-date = "Date" ":" date-time - originator = authentic ; authenticated addr - [ "Reply-To" ":" 1#address] ) - phrase = 1*word ; Sequence of words - - - - - August 13, 1982 - 45 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - qtext = <any CHAR excepting <">, ; => may be folded - "\" & CR, and including - linear-white-space> - quoted-pair = "\" CHAR ; may quote any char - quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or - ; quoted chars. - received = "Received" ":" ; one per relay - ["from" domain] ; sending host - ["by" domain] ; receiving host - ["via" atom] ; physical path - *("with" atom) ; link/mail protocol - ["id" msg-id] ; receiver msg id - ["for" addr-spec] ; initial form - ";" date-time ; time received - - resent = resent-authentic - [ "Resent-Reply-To" ":" 1#address] ) - resent-authentic = - = "Resent-From" ":" mailbox - / ( "Resent-Sender" ":" mailbox - "Resent-From" ":" 1#mailbox ) - resent-date = "Resent-Date" ":" date-time - return = "Return-path" ":" route-addr ; return address - route = 1#("@" domain) ":" ; path-relative - route-addr = "<" [route] addr-spec ">" - source = [ trace ] ; net traversals - originator ; original mail - [ resent ] ; forwarded - SPACE = <ASCII SP, space> ; ( 40, 32.) - specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- - / "," / ";" / ":" / "\" / <"> ; string, to use - / "." / "[" / "]" ; within a word. - sub-domain = domain-ref / domain-literal - text = <any CHAR, including bare ; => atoms, specials, - CR & bare LF, but NOT ; comments and - including CRLF> ; quoted-strings are - ; NOT recognized. - time = hour zone ; ANSI and Military - trace = return ; path to sender - 1*received ; receipt tags - user-defined-field = - <Any field which has not been defined - in this specification or published as an - extension to this specification; names for - such fields must be unique and may be - pre-empted by published extensions> - word = atom / quoted-string - - - - - August 13, 1982 - 46 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - zone = "UT" / "GMT" ; Universal Time - ; North American : UT - / "EST" / "EDT" ; Eastern: - 5/ - 4 - / "CST" / "CDT" ; Central: - 6/ - 5 - / "MST" / "MDT" ; Mountain: - 7/ - 6 - / "PST" / "PDT" ; Pacific: - 8/ - 7 - / 1ALPHA ; Military: Z = UT; - <"> = <ASCII quote mark> ; ( 42, 34.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 47 - RFC #822 - diff --git a/usr.sbin/sendmail/makemap/Makefile b/usr.sbin/sendmail/makemap/Makefile index c4ac74e..1cc9b59 100644 --- a/usr.sbin/sendmail/makemap/Makefile +++ b/usr.sbin/sendmail/makemap/Makefile @@ -2,7 +2,7 @@ PROG= makemap MAN8= makemap.8 -CFLAGS+=-I${.CURDIR}/../src -DNDBM -DNEWDB +CFLAGS+=-I${.CURDIR}/../src -DNEWDB .include "../../Makefile.inc" .include <bsd.prog.mk> diff --git a/usr.sbin/sendmail/makemap/Makefile.dist b/usr.sbin/sendmail/makemap/Makefile.dist deleted file mode 100644 index 3e7817a..0000000 --- a/usr.sbin/sendmail/makemap/Makefile.dist +++ /dev/null @@ -1,81 +0,0 @@ -# -# This Makefile is designed to work on the old "make" program. It does -# not use the obj subdirectory. It also does not install documentation -# automatically -- think of it as a quick start for sites that have the -# old make program (I recommend that you get and port the new make if you -# are going to be doing any signficant work on sendmail). -# -# @(#)Makefile.dist 8.2 (Berkeley) 11/27/93 -# - -# use O=-O (usual) or O=-g (debugging) -O= -O - -# location of sendmail source directory -SRCDIR= ../src - -# define the database mechanisms available for map & alias lookups: -# -DNDBM -- use new DBM -# -DNEWDB -- use new Berkeley DB -# The really old (V7) DBM library is no longer supported. -# -DBMDEF= -DNDBM -DNEWDB - -# environment definitions (e.g., -D_AIX3) -ENVDEF= - -# see also conf.h for additional compilation flags - -# include directories -INCDIRS=-I${SRCDIR} -I/usr/sww/include/db - -# loader options -LDOPTS= - -# library directories -LIBDIRS=-L/usr/sww/lib - -# libraries required on your system -LIBS= -ldb -ldbm - -# location of makemap binary (usually /usr/sbin or /usr/etc) -BINDIR= ${DESTDIR}/usr/sbin - -# additional .o files needed -OBJADD= - -################### end of user configuration flags ###################### - -CFLAGS= -I. $O ${INCDIRS} ${DBMDEF} ${ENVDEF} - -OBJS= makemap.o ${OBJADD} - -LINKS= ${DESTDIR}/usr/ucb/newaliases ${DESTDIR}/usr/ucb/mailq -BINOWN= bin -BINGRP= bin -BINMODE=555 - -ALL= makemap makemap.0 - -all: ${ALL} - -makemap: ${BEFORE} ${OBJS} - ${CC} -o makemap ${LDOPTS} ${OBJS} ${LIBDIRS} ${LIBS} - -makemap.0: makemap.8 - nroff -h -mandoc makemap.8 > makemap.0 - -install: install-makemap install-docs - -install-makemap: makemap - install -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} makemap ${BINDIR} - -# doesn't actually install them -- you may want to install pre-nroff versions -install-docs: makemap.0 - -clean: - rm -f ${OBJS} makemap makemap.0 - -# dependencies -# gross overkill, and yet still not quite enough.... -${OBJS}: ${SRCDIR}/conf.h diff --git a/usr.sbin/sendmail/praliases/Makefile.dist b/usr.sbin/sendmail/praliases/Makefile.dist deleted file mode 100644 index a7b07f4..0000000 --- a/usr.sbin/sendmail/praliases/Makefile.dist +++ /dev/null @@ -1,81 +0,0 @@ -# -# This Makefile is designed to work on the old "make" program. It does -# not use the obj subdirectory. It also does not install documentation -# automatically -- think of it as a quick start for sites that have the -# old make program (I recommend that you get and port the new make if you -# are going to be doing any signficant work on sendmail). -# -# @(#)Makefile.dist 8.1 (Berkeley) 11/27/93 -# - -# use O=-O (usual) or O=-g (debugging) -O= -O - -# location of sendmail source directory -SRCDIR= ../src - -# define the database mechanisms available for map & alias lookups: -# -DNDBM -- use new DBM -# -DNEWDB -- use new Berkeley DB -# The really old (V7) DBM library is no longer supported. -# -DBMDEF= -DNDBM -DNEWDB - -# environment definitions (e.g., -D_AIX3) -ENVDEF= - -# see also conf.h for additional compilation flags - -# include directories -INCDIRS=-I${SRCDIR} -I/usr/sww/include/db - -# loader options -LDOPTS= - -# library directories -LIBDIRS=-L/usr/sww/lib - -# libraries required on your system -LIBS= -ldb -ldbm - -# location of praliases binary (usually /usr/sbin or /usr/etc) -BINDIR= ${DESTDIR}/usr/sbin - -# additional .o files needed -OBJADD= - -################### end of user configuration flags ###################### - -CFLAGS= -I. $O ${INCDIRS} ${DBMDEF} ${ENVDEF} - -OBJS= praliases.o ${OBJADD} - -LINKS= ${DESTDIR}/usr/ucb/newaliases ${DESTDIR}/usr/ucb/mailq -BINOWN= bin -BINGRP= bin -BINMODE=555 - -ALL= praliases praliases.0 - -all: ${ALL} - -praliases: ${BEFORE} ${OBJS} - ${CC} -o praliases ${LDOPTS} ${OBJS} ${LIBDIRS} ${LIBS} - -praliases.0: praliases.8 - nroff -h -mandoc praliases.8 > praliases.0 - -install: install-praliases install-docs - -install-praliases: praliases - install -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} praliases ${BINDIR} - -# doesn't actually install them -- you may want to install pre-nroff versions -install-docs: praliases.0 - -clean: - rm -f ${OBJS} praliases praliases.0 - -# dependencies -# gross overkill, and yet still not quite enough.... -${OBJS}: ${SRCDIR}/conf.h diff --git a/usr.sbin/sendmail/src/TODO b/usr.sbin/sendmail/src/TODO deleted file mode 100644 index 80d35d0..0000000 --- a/usr.sbin/sendmail/src/TODO +++ /dev/null @@ -1,287 +0,0 @@ -(Version 8.22 of 3/12/94) - -Key: - X -- extension (user visible change) - B -- bug fix - S -- security fix - E -- enhancement to existing algorithm - - -X **** 8 -> 7 bit MIME conversion. - -E **** Change NoReturn to be an envelope flag. [8.7] - -X **** Add M_NOLOOPBACKCHK (k) mailer flag to turn off check of name in - HELO command. [8.8] - -X **** Merge Sun changes. [8.7] - -X **** Macro giving size of the message in bytes. - -X **** Create a "service switch" abstraction that will interface with - Sun NSS, Ultrix /etc/svc.conf, etc. This will allow you to - turn off DNS entirely, a la ``OIoff''. [8.7] - -X **** Should have new mailer flags to override LocalMailer stuff: - - M_ALIASABLE (A) -- can use as the LHS of an alias. - - M_HASPWENT (w) -- should have a /etc/passwd entry. If not found - there, implies user unknown. Also implies .forward and UDB - searching, search for |, /, and :include:, etc.). - - Actually, UDB searching and |, /, and :include: mapping should - probably be on another flag. (Cannot be 'l' for back compat - reasons.) - - Need for $@host part of triple and Return-Receipt-To: processing - should also be split apart. - [8.8] - -X **** Mailer flag to enable/disable surrounding route-addrs with - angle brackets in setsender(). UUCP cleanup scripts treat - these as file redirection. - -X **** Mailer flag to override MX lookups. - -E **** Fix parseaddr to return a dummy mailer with QBADADDR set for - all cases except null input; change calls to be more sceptical - about the return value, checking this bit instead of just - checking for == NULL. (Eric Wassenaar) [8.7] - -X **** Run time configurable locking -- e.g., compile in HASFLOCK and - HASLOCKF, and then choose at runtime between these. - -B **** Aliases with .REDIRECT fail during newaliases if the "n" flag - is given. Problem is, sometimes you want them to, sometimes - you don't. Perhaps two flavors of "error" mailer? - -B **** Calls to gethostbyname with a trailing dot fail if you are - not running DNS. - -E **** Move delivery forking from sendenvelope to sendall so that - the connection cache works between split envelopes, and to - avoid a flurry of processes should you be sending to lots of - sub-lists. - -X **** Add uucp-bang mailer that strips off any domain name from - the envelope recipient address first; this is for use in - mailer table entries. - -X **** "quote" map (inverse of dequote). Lets you turn node::user - into "node::user"@DECNET.gateway - -X **** Named rulesets. - -? **** Should $( [1.2.3.4] $) convert the address to a name? - -E **** Change collect() handling to use high level timeouts instead - of per-line timeouts -- the current mechanism is swamping - the machine with system calls. (Look at KJS code.) - -E *** Long term host status -- store host status on disk for sharing - between runs. - -X *** Extend I option to allow setting of retry and timeout values. - drl@vuse.vanderbilt.edu (David R. Linn). - -X *** Total connection cache lifespan timeout -- a way to give a - timeout on connections regardless of whether they are active - or not. For single threaded servers such as Microsoft SMTP - gateway. Douglas Anderson <dlander@afterlife.ncsc.mil>. - -X *** Mailer flag that does a "ping" equivalent -- if it fails, wait - 30 seconds and try again (for dialup PPP connections). Could - just try the connection and then immediately retry on some - kinds of failures. - -X *** Create a macro that has message size. - Peter Wemm <peter@DIALix.oz.au> - -E *** Dynamically allocate MAXNAME buffers for headers. - -E *** Dynamically allocate "line" buffer in readaliases(). - -X *** Add ability to disable Return-Receipt-To: on a privacy flag. [8.8] - -X *** Add -P to set precedence (e.g., -Pbulk). [8.8] (BCX) - -X *** Runtime option to enable/disable IDENT protocol. - -E *** Don't send ErrMsgFile to postmaster bounces. (Josh Smith, - josh@osiris.ac.hmc.edu). - -X *** Add "user" map to look up a user name via getpwnam -- so that - non-local names can be forwarded to another site. [8.8] - -E *** Have daemons that start up check the alias database for - correctness and auto-rebuild if necessary. This is to handle - the case of a system crash during an alias database rebuild. - -E *** Eliminate E qf line and e_errorqueue; use e_errorsto a la - e_receiptto. This simplifies and gives symmetry. (Eric - Wassenaar) - -X *** DECNET_RELAY support in configs. - -X *** -wN command line flag to set the width of mailq output. - (Allan Johannesen) - -E *** Move mailertable lookup after UUCP-specific class checks? - (Kimmo Suominen <kim@tac.nyc.ny.us>) - -E *** Users in more than one list with different owners get duplicate - deliveries -- maybe just assign them arbitrarily to one - envelope or the other? - -X ** Make MAXBADCOMMANDS run time configurable. - -E ** Allow mailertable entries of the form ``error:message''. - -X ** Have .forward files re-queue if the home directory isn't - accessible? On some option... - (Q.G.Campbell@newcastle.ac.uk) - -X ** Have local delivery queue if NIS is down? On some option... - (Q.G.Campbell@newcastle.ac.uk) - -E ** Have nullclient configuration resolve local names to the local - mailer and then redirect them in ruleset 5; this allows you to - redirect root differently depending on the client. It's not - clear this is really a good idea though. - -E ** Move CurHostAddr into mci struct, and make CurMCI variable - point to this, so that logging will give the correct address - instead of (0) for cached connections. Motonori Nakamura. - -X ** Allow use of a generalized network service for aliasing? - How would the protocol be defined? - James Gritton <gritton@byu.edu>. - -E ** Make "local configuration error" a temporary failure? - (add EX_CONFIG to the markfailure list) - -X ** (sigh) BSMTP. - -X ** "E" configuration line that sets environment variables. - -E ** Change listen() high-load backoff to accept and issue a 4xx - message so that it responds more quickly. - -E ** Change "/usr/tmp/dead.letter" to be based on _PATH_VARTMP. - -B ** Commas in NAME envariable cause problems (Peter Wan - <peter@cc.gatech.edu>). Merge with suggestions to use - MIME-format for 8-bit characters? - -E ** Save address information that comes back as the "additional - records" part of an MX lookup, to avoid additional name server - attempts. If there is an MX record without an additional A - record, delete it (this avoids a problem with misconfigured - DNS situations). - -X ** Allow a way to extend the $Z macro with local configuration - information. - -X ** Allow $x in -bt mode to expand macro "x". (BCX) [8.8] - -X ** Allow /address in -bt mode to expand address through ruleset 0, - aliases, etc. and display results. [8.8] - -X ** "R mailer address" in -bt mode does remotename on address. - -E ** Adjust "infinite loop in rule" code to handle entire ruleset - (Code from Michael Corrigan). - -E ** Allow :include: from command line (not SMTP) to assist in - "personal list" management -- i.e., creating lists that - cannot be EXPNed. - -X ** Database (keyed lookup) auto-rebuild. - -X ** Find a good test suite and include in the distribution. - -S ** You can use symbolic links to point into protected directories. - (AEJ) - -X ** Extend OI to allow separate settings for canonification, MX, and A - lookups. [8.8?] - -X ** Add $!x class to match any number of words not in class x. (KRE) - -X ** LOCAL_RULE_5 (Spencer Sun, spencer@phoenix.Princeton.EDU) - -X ** Add "bestmx" map -- returns "best MX host" for this address. - Allows you to do automatic detection of when you are the best - MX for a given address. [8.7?] - -X ** Some way to diddle resolver flags on a per-lookup basis, such - as a flag to the map declaration. (Rick McCarty) - - Is this really a good idea? DNSRCH can be turned off by - putting a dot at the end. AAONLY? - -X ** Extend makemap to "gather" values -- i.e., merge entries that - have the same keys. [8.8] (BCX) - -E ** Allow error messages on individual addresses in the qf file. - (BCX) - -X ** Multi-character option names. [9.1] - -X ** User database extensions for mailing lists: - list:precedence -- Precedence: value for new message - list:envelopefrom -- envelope "from" value for new message - others? [8.8] - -X ** Command line switch to set precedence (for mailing list - generation). (BCX) - -B ** Restore `T' line to eliminate X-Authentication-Warning: at - inappropriate times. (Christophe Wolfhugel) - - T could become a shorthand for Ct -- i.e., create a new - predefined class. - - Eliminate "<user> set sender to <address>" message entirely? - (this is the workaround) - -B ** Return-Path: header should have <> added if not already there. - -X ** Add heuristic to determine if other end is a sendmail; use - that to decide whether or not to honor F=I mailer flag. - [der Mouse <mouse@collatz.mcrcim.mcgill.edu>] - -X ** Automatically drop into MIME mode if you have a full name - with 8-bit characters. See envelope.c 8.19.1.1 and util.c - 8.17.1.1. From Anders Ellefsrud <anders@ifi.uio.no>. - -X ** -b? flag to read a header and show you what it will look like - after all rewriting for an indicated address. - -E ** Log $u in logsender() (for=<someaddress>). - -B ** Include SOCKADDR in MCI struct for logging (currently gives - a sockaddr of zero when printing from the cache). - -X ** Allow option to set the characters that are autoquoted in - addresses? - -X * Map that does MB/MR lookups. Rick McCarty <mccarty@io.com>. - -X * Allow $> anywhere in RHS. John Boeske <jboeske@ualberta.ca>. - -X * -V flag to print state of all (?) compilation flags. - -X * Handle Expires: header field (if still in queue). - -X * WIN/3B support (non-atomic rename, no h_addr_list, others?) - (Bruce Lilly <blilly!bruce@uu.psi.com>) - -X * Sun YBTS daemon uses -ba. [Martin Kiff <MGK@newton.npl.co.uk>] - -B * EXPN adds @domain to all mailers, including prog. Is this right? - [Bob Henry] - -B * EXPN adds @localhost instead of @$M. [Pel Emanuelsson] - -E * Change body put code to time out around individual puts. This will - make the timeout algorithm more responsive and more resilient. - Unfortunately, it's also a pain in the butt. - -X * Some way to relay unfound local users to another site. - -X * Disable all default RW sets except mailer-specific? |
