As per Relevance of the word february, we have this rfc below:
Network Working Group Mark. R.
Request for Comments: 976 Bell
February 1986
UUCP Mail Interchange Format
Status of This
In response to the need for maintenance of current information
the status and progress of various projects in the ARPA-
community, this RFC is issued for the benefit of community members
The information contained in this document is accurate as of the
of publication, but is subject to change. Subsequent RFCs
reflect such changes
This document defines the standard format for the transmission
mail messages between machines in the UUCP Project. It does
address the format for storage of messages on one machine, nor
lower level transport mechanisms used to get the data from
machine to the next. It represents a standard for conformance
hosts in the UUCP zone. Distribution of this memo is unlimited
1.
This document is intended to define the standard format for
transmission of mail messages between machines in the UUCP Project
It does not address the format for storage of messages on
machine, nor the lower level transport mechanisms used to get
data from one machine to the next. We assume remote execution of
rmail command (or equivalent) as the UUCP network
operation
The general philosophy is that, if we were to invent a new standard
we would make ourselves incompatible with existing systems.
are already too many (incompatible) standards in the world,
in ambiguities such as a!b@c.d which is parsed a!(b@c.d) in the
UUCP world, and (a!b)@c.d in the Internet world. (Neither
allows parentheses, and in adding them we would be compatible
neither. There would also be serious problems with the shell
with the UUCP transport mechanism.)
Having an established, well documented, and extensible family
standards already defined by the ARPA community, we choose to
these standards for the UUCP zone as well. (The UUCP zone is
subset of the community connected by UUCP which chooses to
with the UUCP project. It represents an administrative entity.)
While the actual transport mechanism is up to the two hosts
arrange, and might include UUCP, SMTP, MMDF, or some other facility
we adopt RFC-920 (domains) and RFC-822 (mail format) as UUCP
standards. All mail transmitted between systems should conform
Horton [Page 1]
RFC 976 February 1986
UUCP Mail Interchange Format
those two standards. In addition, should the ARPA community
these standards at a later time, we intend to change our standards
remain compatible with theirs, given a reasonable time to
software
This document specifies an interpretation of RFC-822 and RFC-920
the UUCP world. It shows how the envelope should be encoded, and
UUCP routing is accomplished in an environment of
implementations
2.
Messages can be divided into two parts: the envelope and the message
The envelope contains information needed by the mail
services, and the message contains information useful to the
and receiver. The message is divided into the header and the body
Sometimes an intermediate host will add to the message (e.g.
Received line) but, except in the case of a gateway which
translate formats, it is not expected that intermediate hosts
change the message itself. In the UUCP world, the envelope
of the "destination addresses" (normally represented as the
or arguments to the rmail command) and the "source path" (
represented in one or more lines at the beginning of the
beginning either "From " or ">From ", sometimes called "From
lines".) The RFC-822 header lines (including "From:" and "To:")
part of the message, as is the text of the message body itself
UUCP uses short host names, such as "ucbvax", at and below
transport layer. We refer to these names as "6 letter names",
because all implementations of UUCP consider at least the first 6
letters significant. (Some consider the first 7 or the first 14
significant, but we must use the lowest common denominator.)
names may be longer than 6 characters, but all such names much
unique in their first 6 letters. RFC-920 domain names, such
"ucbvax.Berkeley.EDU", are called "domain names." The two names
different. Upper and lower case are usually considered different
6 letter names, but are considered equivalent in domain names.
such as "ucbvax.UUCP", consisting of a 6 letter name followed
".UUCP", previously were domain style references to a host with
given 6 letter name. Such names are being phased out in favor
organizational domain names such as "ucbvax.Berkeley.EDU
Horton [Page 2]
RFC 976 February 1986
UUCP Mail Interchange Format
2.1 Hybrid
There are (among others) two major kinds of mailing address
used in the UUCP world. The a!b!c!user ("bang paths") is used
older UUCP software to explicitly route mail to the destination.
user@domain ("domain") syntax is used in conformance to RFC-822.
Under most circumstances, it is possible to look at a given
and determine which sort of address it is. However, a hybrid
with a ! to the left of an @, such as a!b@c, is ambiguous: it
be interpreted as (a!b)@c.d or a!(b@c.d). Both interpretations
be useful. The first interpretation is required by RFC-822,
second is a de-facto standard in the UUCP software
Because of the confusion surrounding hybrid addresses, we
that all transport layer software avoid the use of hybrid
at all times. A pure bang syntax can be used to disambiguate,
written c.d!a!b in the first case above, and a!c.d!b in the second
We recommend that all implementations use this "bang domain"
unless they are sure of what is running on the next machine
In conformance with RFC-822 and the AT&T Message
Architecture, we recommand that any host that accepts
addresses apply the (a!b)@c.d interpretation
2.2
Since SMTP is not available to much of the UUCP domain, we define
method to be used for "remote execution" based transport mechanisms
The command to be "remotely executed" should
rmail user@domain ...
with the message on the standard input of the command.
"user@domain" argument must conform to RFC-920 and RFC-822.
than one address argument is allowed, in order to save
costs for multiple recipients of the same message
An alternative form that may be used
rmail domain!
where "domain" contains at least one period and no !'s. This is
be interpreted exactly the same as user@domain, and can be used
transport a message across old UUCP hosts without fear that
might change the address. The "user" string can contain
characters except "@". This character is forbidden because it
unknown what an intermediate host might do to it. (It is
Horton [Page 3]
RFC 976 February 1986
UUCP Mail Interchange Format
recommended that the "%" character be avoided, since some hosts
"%" as a synonym for "@".) However, to route across hosts that don'
understand domains, the following is
rmail a!b!c!domain!
A "domain" can be distinguished from a 6 letter UUCP site
because a domain will contain at least one period. (In the case
single level domains with no periods, a period should be added to
end, e.g. Mark.Horton@att becomes "att.!Mark.Horton". A
from ! to @ format should remove a trailing dot at the end of
domain, if one is present.) We don't expect this to happen,
for local networks using addresses like "user@host".
A simple implementation can always generate domain!user
(rather than user@domain) since it is safe to assume that
are class 3 (Classes are explained in section 3.5).
2.3 Batch
Standard conforming implementations may optionally support a
called "Batch SMTP". SMTP (Simple Mail Transfer Protocol) is
ARPA community standard mail transfer protocol (RFC-821). It is
used on BITNET and Mailnet. While SMTP was designed to
interactive, it is possible to batch up a series of commands and
them off to a remote machine for batch execution. This is used
BITNET, and is appropriate for UUCP. One advantage to BSMTP is
the UNIX shell does not get involved in the interpretation
messages, so it becomes possible to include special characters
as space and parentheses in electronic messages. (Such
are expected to be popular in X.400 addresses.)
To support BSMTP on UNIX, a conforming host should arrange that
to the user "b-smtp" is interpreted as Batch SMTP commands. (We
b-smtp instead of bsmtp because bsmtp might conflict with a
name.) Since many mail systems treat lines consisting of a
period as an "end of file" flag, and since SMTP uses the period as
required end of file flag, and to strip off headers, we put an
"#" at the beginning of each BSMTP line. On a sendmail system,
easy way to implement this is to include the
b-smtp: "|egrep '^#' | sed 's/^#//' | /usr/lib/sendmail -bs
which will feed the commands to an SMTP interpreter. A
solution would appropriately check for errors and send back an
message to the sender
Horton [Page 4]
RFC 976 February 1986
UUCP Mail Interchange Format
An example BSMTP message from seismo.CSS.GOV to cbosgd.ATT.COM
shown here. This sample is the file shipped over the UUCP link
in put to the command "rmail b-smtp". Note that the RFC- 822
is between the DATA line and the period line. The
information is passed in the MAIL FROM and RCPT TO lines. The
of the sending system is in the HELO line. The actual
information (above the # lines) is ignored and need not be present
From foo!bar Sun Jan 12 23:59:00 1986 remote from seismo Date
Tue, 18 Feb 86 13:07:36
From: mark@ucbvax.Berkeley.
Message-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU> To
b-smtp@cbosgd.ATT.
#HELO seismo.CSS.
#MAIL FROM:
#RCPT TO:
#
#Date: Tue, 18 Feb 86 13:07:36
#From: mark@ucbvax.Berkeley.
#Message-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU> #To
mark@cbosgd.ATT.
#
#This is a sample message
#.
#
2.4
The standard input of the command should begin with a single
From domain!user date remote from
followed immediately by the RFC-822 format headers and body of
message. It is possible that there will be additional From_
preceding this line - these lines may be added, one line for
system the message passes through. It is also possible that
"system" fields will be stacked into a single line, with many !'s
the "user" string. The ">" character may precede the "From".
general, this is the "envelope" information, and should follow
same conventions that previous UUCP mail has followed. The
difference is that, when the system names are stacked up,
previously the result would have been a!b!c!mysys!me, the new
will be a!b!c!mysys!domain!me, where domain will contain at least
period, and "mysys" is often the 6 letter UUCP name for the
Horton [Page 5]
RFC 976 February 1986
UUCP Mail Interchange Format
system named by "domain". If the "domain!" is redundant, it may
omitted from the envelope, either in the source path or in
destination address
The receiving system may discard extra "From_" lines if it folds
information into a a single From_ line. It passes
path!domain!user along as the "envelope" information containing
address of the sender of the message, and possibly preserves
forwarding date and system in a newly generated header line, such
Received or Sent-By. (Adding Received using this information
discouraged, since the line appears to have been added on a
system than the one actually adding it. That other system may
actually included a Received line too! The Sent-By line is similar
Received, but the date need not be converted into RFC-822 format,
the line is not claimed to have been added by the system whose
is mentioned.)
If the receiving system passes the message along to another system
it will add a "From_" line to the front, giving the same user@
address for the sender, and its own name for the system. If
receiving system stores the message in a local mailbox, it
recommended that a single "From_" line be generated at the front
the message, keeping the date (in the same format, since certain
reading programs are sensitive to this format), and not using
"remote from system" syntax
Note - if an intermediate system adds text such as "system!" to
front of a "user@domain" syntax address, either in the envelope
the body, this is a violation of this standard and of RFC-822.
2.5
In order to properly route mail, it is sometimes necessary to
what software a destination or intermediate machine is running,
what conventions it follows. We have tried to minimize the amount
this information that is necessary, but the support of subdomains
require that different methods are used in different situations.
purposes of predicting the behavior of other hosts, we divide
into three classes. These classes are
Class 1 old-style UUCP ! routing only. We assume that the
understands local user names
rmail
Horton [Page 6]
RFC 976 February 1986
UUCP Mail Interchange Format
and bang
rmail host1!host2!
but we assume nothing more about the host. If we
no information about a host, we can treat it as class 1
with no problems, since we make no assumptions
how it will handle hybrid addresses
Class 2 Old style UUCP ! routing, and 4.2BSD style
parsing. We assume the capabilities of class 1,
the ability to
rmail user@
if the "domain" is one outside the UUCP zone
the host knows about. Class 2 hosts do not
understand domain!user or have routers. Hosts in non
UUCP RFC-920 domains are considered class 2, even
they may not understand host!user
Class 3 All class 1 and 2 features are present. In addition
class 3 hosts must be able to route UUCP mail for
that are not immediately adjacent and also
the
rmail domain!
as described above. All gateways into UUCP must
class 3.
This document describes what class 3 hosts must be able to process
Classes 1 and 2 already exist, and will continue to exist for a
time, but are viewed as "older systems" that may eventually
upgraded to class 3 status
3.
The algorithm for delivering a message to an address "user@domain
over UUCP links can be summarized as follows
a. If the address is actually of the form @domain1:user@domain2,
the "domain" used for the remainder should be "domain1"
instead of "domain2", and the bang form
domain1!domain2!user
Horton [Page 7]
RFC 976 February 1986
UUCP Mail Interchange Format
b. Determine d: the most specific part of "domain" that
recognized locally. This part will be a suffix of "domain".
This can be done by scanning through a table with entries
go from specific to general, comparing entries with "domain
to see if the entries are at the tail of "domain".
example, with the address "mark@osgd.cb.att.com", if the
host recognizes "uucp" and "att.com", d would be "att.com".
The final entry in the table will be the null string,
any completely unrecognized domain
c. Look in the found table entry for g: the name of
"gateway", and for r: a UUCP !-style route to reach g. G
not necessarily directly connected to the local host,
should be viewed as a gateway into the d domain. (The
of g and r for a given d may be different on different hosts
although g will often be the same.)
d. Look at the beginning of r to find the "next hop" host n.
will always be directly connected to the local host
e. Determine, if possible, the class of g and n
f. Create an appropriate destination string s to be
by n. (See below.)
g. Pass the message off to n with destination information s
In an environment with other types of networks that do not
UUCP ! parsing, the table will probably contain
information, such as which type of link to use. The
information may be replaced in other environments by
specific to the network
The first entries in the table mentioned in part (b) are
very specific, and allow well known routes to be
directly instead of routing through the domain tree. The
tree should be reserved for cases where no better information
available, or where traffic is very light, or where the
route is the best available. If a better route is available,
information can be put in the table. If a host has
significant amount of traffic sent to a second host, it
normally expected that the two hosts will set up a direct
link and make an entry in their tables to send mail directly,
if they are in separate domains. Routing tables should
constructed to try to keep paths short and inexpensive for as
traffic as possible
Horton [Page 8]
RFC 976 February 1986
UUCP Mail Interchange Format
Here are some hints for the construction of the destination
n (step f above.) The "envelope recipient" information (
argument(s) to rmail) may be in either domain !
(host.com!user) or domain @ form (user@host.com) as long as
sending site is sure the next hop is class 3. If the next hop
not class 3, or the sending site is not sure, the ! form should
used, if possible, since it is hard to predict what the next
would do with a hybrid address
If the gateway is known to be class 3, domain ! form may be used
but if the sending site is not sure, and the entire
string was matched in the lookup (rather than some parent domain),
the 6 letter ! form should be used: r!user, for example
dumbhost!host!user. If the gateway appears to actually be
gateway for a subdomain, e.g. because a parent domain was matched
(such as the address user@host.gateway.com, where host.gateway.
was not found but gateway.com was) it can be assumed to be
class 3. This allows routes such
dumbhost!domain!host.domain.com!user to be used with a
degree of safety. If a direct link exists to the
host, the user@domain syntax or the domain!user syntax may
used
All hosts conforming to this standard are class 3, and
subdomain gateways must be class 3 hosts
4.
Suppose host A.D.COM sends mail to host C.D.COM. Let's suppose
the 6 letter names for these hosts are aname and dname, and that
intermediate host to be routed through has name bname
The user on A
mail user@c.d.
The user interface creates a file such
Date: 9 Jan 1985 8:39
From: myname@A.D.COM (My Name
Subject: sample
To: user@c.d.
This is a sample
and passes it to the transport mechanism with a command such
Horton [Page 9]
RFC 976 February 1986
UUCP Mail Interchange Format
sendmail user@c.d.com <
The transport mechanism looks up a route to c.d.com. It does
find c.d.com in its database, so it looks up d.com, and finds
the path is bname!dname!%s, and that c.d.com is a class 3 host
Plugging in c.d.com!user, it gets the path bname!dname!c.d.com!user
(If it had found c.d.com with path bname!cname!%s, it would
omitted the domain from the resulting path: bname!cname!user,
it is not sure whether the destination host is class 1, 2, or 3.)
It prepends a From_ line and passes it to uux
uux - bname!rmail dname!c.d.com!user < file
where file2
From A.D.COM!user Wed Jan 9 12:43:35 1985 remote from aname Date
9 Jan 1985 8:39
From: myname@A.D.COM (My Name
Subject: sample
To: user@c.d.
This is a sample
(Note the blank line at the end of the message - at least one
line is required.) This results in the
rmail dname!c.d.com!
running on B. B prepends its own from line and passes the
along
uux - dname!rmail c.d.com!user < file
where file3
From nuucp Wed Jan 9 12:43:35 1985 remote from bname >
A.D.COM!user Wed Jan 9 11:21:48 1985 remote from aname Date: 9
Jan 1985 8:39
From: myname@A.D.COM (My Name
Subject: sample
To: user@c.d.
This is a sample
Horton [Page 10]
RFC 976 February 1986
UUCP Mail Interchange Format
The
rmail c.d.com!
is run on C, which stacks the From_
From bname!aname!A.D.COM!user Wed Jan 9 12:43:35 1985 Date: 9
Jan 1985 8:39
From: myname@A.D.COM (My Name
Subject: sample
To: user@c.d.
This is a sample
and stores the message locally, probably in this same format
5.
Hosts conforming to this standard should accept all of the
forms
rmail localuser (no !%@ in user
rmail hosta!hostb!user (no !%@ in user
rmail user@domain (only . in domain
rmail domain!user (at least 1 . in domain
rmail domain.!user (in case domain has no dots
The "envelope" portion of the message ("From_" lines) should
to existing conventions, using ! routing. The "heading" portion
the message (the Word: lines such as Date:, From:, To:, and Subject:)
must conform to RFC-822. All header addresses must be in the @ form
The originating site should ensure that the addresses conform
RFC-822, since no requirement is placed on forwarding sites
gateways to transform addresses into legal RFC-822 format. (
forwarding sites and gateways should NOT, however, change a
RFC-822 address such as user@domain into an illegal RFC-822
such as gateway!user@domain, even if forwarding to a class 1
host.)
6.
[1] Postel, J., "Simple Mail Transfer Protocol", RFC-821,
USC/Information Sciences Institute, August, 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet
Messages", RFC-822, Department of Electrical Engineering
University of Delaware, August, 1982.
Horton [Page 11]
RFC 976 February 1986
UUCP Mail Interchange Format
[3] Postel, J., and J. K. Reynolds, "Domain Requirements", RFC-920,
USC/Information Sciences Institute, October, 1984.
Horton [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
