Aunc.1364
net.general
utzoo!decvax!duke!unc!smb
Mon Nov  9 11:16:57 1981
ARPAnet mail format standards
The following is a summary of RFC733 -- the ARPAnet standard for mail
messages -- for the benefit of the Usenet community.  Note that it *is*
a summary; the main purpose is to let people prepare messages that do
not conflict with the mailers out there in ARPAland.  There's much more
that I've omitted.

A message consists of a header, a null line, followed by a body.  The
body is arbitrary text (stick to printable characters -- some systems
have trouble with control characters).  A header consists a series of
lines, each of which consists of a field-name, a colon, and some text.
The field-name must start in column 1; it should not contain blanks,
because many mailers don't handle that properly (in particular,
Berkeley mail does't recognize such lines as headers).  The text
portion may be continued by starting the next line with a tab or
blank.  Case is ignored when comparing field-names.  A number of header
types are defined by RFC733; however, *anything* that is syntactically
valid (like my "In-real-life" line) is permitted, subject to
pre-emption by later revisions to the standard.

The only mandatory lines are "From" and "Date"; these are properly
inserted by the Berkeley mailer code, and should not be included in any
messages sent to Berkeley for retransmission.  A consequence of this is
that the simplest way to send a legal RFC733-format message is to
include a null line at the beginning of your letter -- if you do that,
no one has the right to complain about violation of standards.  (If you
do insert "From" and "Date" yourself, you must be certain you know
*exactly* what you're doing, for several reasons.  First, Berkeley mail
views any "From:" line as taking precedence over the return address
generated by uucp along the way; thus, 'reply' commands may not work
correctly.  "Date:" lines must adhere to a rigid format; further, the
gateway code at Berkeley uses it presence as a signal that the message
is already in strict RFC733 format, and omits certain transformations.)

A useful header line to include is "Subject"; any arbitrary text may be
included here to give a hint to the recipient about the message
content.  No semantics are attached to this line by the standard.
Other related standard fields are "Comments" and "Keywords".

Some messages include the "In-Reply-To" line; this in some way
specifies the message to which this one is a reply.  No meaning is
attached to the content of this field unless it contains a string that
looks like a machine-readable address:  a string enclosed in .
If such a string does exist, it must match the contents of the
"Message-Id" field of the original message; that field must be of the
form <GUARANTEED-UNIQUE-STRING>.  (Theoretically, the string must
include "@host" at the end, but many systems do not adhere to that,
and it is unwise to depend on it if writing any code to use it.)
"Message-Id" and "In-Reply-To" are intended for highly-automated
systems that eliminate duplicate messages, pull your original out to
compare with the reply, etc., and should not in general be created by
the user.  (There is one other field, "References", that is used in the
same way; it, too, may not contain  strings unless they are in the
proper format.)

The other header fields contain user addresses (more on which below),
and may be specified by uucp folks, albeit with caution.  "To"
specifies the primary recipients of the message, "cc" specifies the
secondary recipients, and "bcc" specifies the recipients of "blind
carbon copies" -- their names do not show up on everyone else's copy.
Note that these fields are *not* required, even if multiple copies are
sent; however, their presence aids automated reply systems.  "Sender"
identifies the user-id that actually sent the message, and is normally
the same as the "From" field, in which case it should be omitted --
RFC733 permits some mighty odd "From" lines, which need not correspond
to a machine-readable address.  The mailer is responsible for
generating the "Sender" line if necessary, and it should *not* be
included in uucp mail.  Normally, replies are sent to the originator of
the message; if someone else should receive the reply, a "Reply-to"
line may be included.  Some versions of Berkeley mail don't seem to
handle this line correctly, and it is not clear that it works properly
through the gateway; consequently, I recommend that it not be used in
uucp/ARPA communications.

RFC733 permits very general address specifications, and I won't even
try to summarize all the legal forms.  First, anything in matched
parentheses is a comment, and is ignored.  Anything enclosed in double
quotes is treated as a single word.  The basic form of an address is
one of

       word... at machine-id
       word...@machine-id
       word... <WORD...@MACHINE-ID>
       word... <WORD AT MACHINE-ID>

In the latter two forms, anything outside the angle-brackets is
ignored.  Note that legal address must include an ARPA machine id, and
hence can't really be used as-is by uucp folks.  Fortunately,
Berkeley's software transforms "To" and "cc" lines into this form,
using their machine-id and prepending the routing information deduced
from the standard UNIX "from" lines.  Thus, all addresses in your "To"
and "cc" lines should be relative to your machine; the message will be
massaged appropriately when it passes into ARPAland.  (I'm not sure if
"Reply-To" lines are similarly treated, which is why I recommend they
not be used unless you really know what you're doing.)  If you're
sending a carbon-copy to another ARPAnet recipient, just put the ARPA
address, i.e., "user@ARPAhost" in the "cc" field without the uucp
routing stuff.

Note that the standard permits multiple-word addresses; some sites,
notably Carnegie, actually use this.  Such usages tend to confuse UNIX
mailers, since they use blank as a delimiter (ARPA uses commas; these
are inserted at the gateway as well).  I don't know about any other
sites, but for CMU, you can substitute periods for the blanks and
everyone will be happy.

Acknowledgements:  my thanks to Eric Allman and Mark Horton for reviewing
this.

-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <[email protected]>
of http://communication.ucsd.edu/A-News/


This Usenet Oldnews Archive
article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.