UUCP mail interchange format standard
RFC 976
Document | Type |
RFC - Unknown
(February 1986; No errata)
Updated by RFC 1137
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 976 (Unknown) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group Mark. R. Horton
Request for Comments: 976 Bell Laboratories
February 1986
UUCP Mail Interchange Format Standard
Status of This Memo
In response to the need for maintenance of current information about
the status and progress of various projects in the ARPA-Internet
community, this RFC is issued for the benefit of community members.
The information contained in this document is accurate as of the date
of publication, but is subject to change. Subsequent RFCs will
reflect such changes.
This document defines the standard format for the transmission of
mail messages between machines in the UUCP Project. It does not
address the format for storage of messages on one machine, nor the
lower level transport mechanisms used to get the data from one
machine to the next. It represents a standard for conformance by
hosts in the UUCP zone. Distribution of this memo is unlimited.
1. Introduction
This document is intended to define the standard format for the
transmission of mail messages between machines in the UUCP Project.
It does not address the format for storage of messages on one
machine, nor the lower level transport mechanisms used to get the
data from one machine to the next. We assume remote execution of the
rmail command (or equivalent) as the UUCP network primitive
operation.
The general philosophy is that, if we were to invent a new standard,
we would make ourselves incompatible with existing systems. There
are already too many (incompatible) standards in the world, resulting
in ambiguities such as a!b@c.d which is parsed a!(b@c.d) in the old
UUCP world, and (a!b)@c.d in the Internet world. (Neither standard
allows parentheses, and in adding them we would be compatible with
neither. There would also be serious problems with the shell and
with the UUCP transport mechanism.)
Having an established, well documented, and extensible family of
standards already defined by the ARPA community, we choose to adopt
these standards for the UUCP zone as well. (The UUCP zone is that
subset of the community connected by UUCP which chooses to register
with the UUCP project. It represents an administrative entity.)
While the actual transport mechanism is up to the two hosts to
arrange, and might include UUCP, SMTP, MMDF, or some other facility,
we adopt RFC-920 (domains) and RFC-822 (mail format) as UUCP zone
standards. All mail transmitted between systems should conform to
Horton [Page 1]
RFC 976 February 1986
UUCP Mail Interchange Format Standard
those two standards. In addition, should the ARPA community change
these standards at a later time, we intend to change our standards to
remain compatible with theirs, given a reasonable time to upgrade
software.
This document specifies an interpretation of RFC-822 and RFC-920 in
the UUCP world. It shows how the envelope should be encoded, and how
UUCP routing is accomplished in an environment of mixed
implementations.
2. Basics
Messages can be divided into two parts: the envelope and the message.
The envelope contains information needed by the mail transport
services, and the message contains information useful to the sender
and receiver. The message is divided into the header and the body.
Sometimes an intermediate host will add to the message (e.g. a
Received line) but, except in the case of a gateway which must
translate formats, it is not expected that intermediate hosts will
change the message itself. In the UUCP world, the envelope consists
of the "destination addresses" (normally represented as the argument
or arguments to the rmail command) and the "source path" (normally
represented in one or more lines at the beginning of the message
beginning either "From " or ">From ", sometimes called "From_
lines".) The RFC-822 header lines (including "From:" and "To:") are
part of the message, as is the text of the message body itself.
UUCP uses short host names, such as "ucbvax", at and below the
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.) UUCP
names may be longer than 6 characters, but all such names much be
unique in their first 6 letters. RFC-920 domain names, such as
"ucbvax.Berkeley.EDU", are called "domain names." The two names are
different. Upper and lower case are usually considered different in
6 letter names, but are considered equivalent in domain names. Names
Show full document text