UUCP mail interchange format standard
RFC 976

Document Type RFC - Unknown (February 1986; No errata)
Updated by RFC 1137
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html 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