RFC 680

RFC 680: Message Transmission Protocol ✨

Okay bestie, this is RFC 680 🎀 It was published on April 30, 1975 by the Network Working Group, with NIC 32116. The authors are Theodore H. Myer and D. Austin Henderson, both from BBN-TENEX 💖 The title block doesn't list a category, and it doesn't say this doc obsoletes or updates anything 🙈

---

This doc defines a bunch of message fields that go beyond the ones covered in RFC 561 🦋 The overall message format is compatible with RFC 561, and it leans super hard on the miscellaneous fields RFC 561 already set up 💅 The goal is to create ARPANET standards for the syntax and semantics of these extra fields. Not every Message Server is expected to automatically process all of them 🙈 But sites that want to use these fields need a standard to work with 🫶

This doc tries to walk the line between stuff that's useful for humans and stuff that's useful for machines 🧚 The general vibe is that these fields are helpful to people even when nothing processes them automatically. Most machine-readable bits are wrapped in angle brackets (<>), so automatic processes can tell easily and unambiguously whether to look in a field and where 🔍 The whole spec is made excessively general so people can experiment 🌈 Future docs based on experience will get more specific. This is just the next step after <RFC 561> ⭐

The doc has two sections 💅 Section I covers the relevant parts of RFC 561 that define the basic message syntax. Section II lists the new (and existing) header fields along with their proposed uses.

SECTION I: BASIC MESSAGE SYNTAX 🎀

Here's the grammar, copied exactly as it is in the original 💖

<message>            ::=     <header><crlf><body>
<header>             ::=     <required header><optional header>
<required header>    ::=     <date item><sender item>
<date item>          ::=     DATE:<sp><date><sp>AT<sp>
                             <time>-<zone><crlf>
<date>               ::=     <vdate>  !  <tdate>
<vdate>              ::=     <dayofmonth><SP><vmonth><SP><vyear>
<tdate>              ::=     <tmonth>/<dayofmonth>/<tyear>
<dayofmonth>         ::=     one or two decimal digits
<vmonth>             ::=     JAN ! FEB ! MAR ! APR ! MAY ! JUN !
                             JUL ! AUG ! SEP ! OCT ! NOV !  DEC
<tmonth>             ::=     one or two decimal digits
<vyear>              ::=     four decimal digits
<tyear>              ::=     two decimal digits
<zone>               ::=     EST ! EDT ! CST ! CDT ! MST ! MDT !
                             PST ! PDT ! GMT ! GDT
<time>               ::=     four decimal digits
<sender item         :=      SENDER: <sp><user><sp>AT<sp><host>
                             <crlf>
<optional header>    ::=     <subjects><optional items>
<subjects>           ::=     !<subject item> !
                             <subject item><subjects>
<subject item>       ::=     SUBJECT:<sp><line><crlf>
<optional items>     ::=     <optional item> ! <optional item>
                             <optional items>
<optional item>      ::=     <messid> ! <addressee item> !
                             <other item>
<addressee item>     ::=     <addressee keyword>:<sp><addressee
                             list><crlf>
<addressee keywork>  ::=     TO:! CC:! BCC:!
<messid>             ::=     Message-ID:<sp>[<Net
                             Address>}]<line>
                             <crlf>
<other item>         ::=     <other keyword>:<sp><line><crlf>
<other keyword>      ::=     FROM ! IN-REPLY-TO! REFERENCES!
                             KEYWORD ! PRECEDENCE !
                             MESSAGE-CLASS!
                             SPECIAL-HANDLING! AUTHENTICATION!
                             ACCESSION-KEY
<address list>       ::=     <addressee> ! <addressee><addressee
                             list>
<addressee>          ::=     <mailbox> ! <mailbox group>
<mailbox>            ::=     <user><host spec><attention spec>
<host spec>          ::=     !@<host>
<attention spec>     ::=     (ATTN:<sp><user list>)
<user list>          ::=     <user> ! <user><user list>
<mailbox group>      ::=     <group name>:(<group numbers>)
<group numbers>      ::=     ! (<mailbox list>)
<mailbox list>       ::=     <mailbox> ! <mailbox>,<mailboxlist>
<body>               ::=     <line><CRLF> ! <line><CRLF><body>
<user>               ::=     <word>
<host>               ::=     a standard host name
<group name>         ::=     ! <word>
<line>               ::=     a string containing any of the 128
                             ASCII
                             characters except CR and LF
<word>               ::=     a string containing any of the 128
                             ASCII
                             characters except CR, LF, and SP
<CRLF>               ::=     CR LF
<SP>                 ::=     space

Notes, bestie 📝

1. A message can have at most one MESSAGE-ID item.
2. All items with the same keyword must be grasped together.

Please note the following 👀

(1) The case (upper or lower) of keywords doesn't matter. That covers 'FROM', 'DATE', 'SUBJECT', 'AT', <host>, <zone>, <vmonth> and <keyword>. Even though 'FROM' is written in uppercase in the formal syntax above, it can show up in an actual message header as 'FROM', 'from', 'From', or whatever else 💅

(2) Nobody's legislated the format of <user> beyond banning spaces from it 🙈

(3) The time has no internal punctuation ⏰

SECTION II: MESSAGE HEADER FIELDS 💖

A. ORIGINATOR SPECIFICATION FIELDS 🦋

FROM

This field holds the identity of the person who wanted this message sent 💌 It's expected to be the originator field the user specifies when one person enters a message on behalf of another. The message-creation process should default this field to the user entering the message. [The usage for FROM and SENDER differs from that of RFC 561.]

SENDER

This field holds the identity of the person who sends the message 📮 It's expected that the message-creation process sets this automatically. Some sites might not include this field in external communications 🙈

AUTHENTICATION

This field describes which originator fields have been authenticated, and which operating systems did the authenticating 🔐 It should be created by the message transmission and/or reception processes (FTP/Operating System level).

It's expected that current systems will only be able to authenticate the SENDER field 😭 Later systems might have ways to verify that the FROM actually authorized the SENDER to act for them 👑 Once the FROM is authenticated, the SENDER won't be necessary for external distribution anymore 🫶

B. REFERENCE SPECIFICATION FIELDS 🌸

MESSAGE-ID

This field holds a unique identifier that refers to this message 🪪 The format is:

[Net Address]Text String CRLF

Examples:

[ISIB]7-DEC-74.14:23:45
[ARC]QLOURNAL 39274a3

Uniqueness is guaranteed when each net-address message processor makes the text after the net-address unique for that net-address. Note that it says net-address and not site name 👀 That would let BBN, for instance, allocate unique identifiers across all four machines, which can be addressed as BBN within the message system. Users get a more integrated service out of that ✨

The text after the net-address isn't defined here, because the problems with that spec are too big right now 😭 The net-address should still let automatic processes figure out if they can handle the text after it intelligently. That opens up a few kinds of automatic processing for the local message reader 🧚

1. If the site uses a filing mechanism the reader knows, the reader can retrieve the message.
2. If the site supports remote message access (a protocol not currently defined), the message id can be passed to the remote site. The message has been filed in the Datacomputer, using the entire message id (including the net-address) as the handle, so the reader can retrieve it from the Datacomputer 💾

IN-REPLY-TO

This field identifies previous correspondence that this message answers 💬 If message identifiers are used in this field, they should be enclosed in angle brackets (<>).

REFERENCES

This field identifies other correspondence that this message references 📚 If message identifiers are used, they should be enclosed in angle brackets (<>).

KEYWORDS

This field holds keywords or phrases from the message, separated by commas 🏷️

C. RECEIVER SPECIFICATION FIELDS 💌

TO

This field holds the identity of the primary receivers of the message 💖

CC

This field holds the identity of the secondary receivers of the message 🩷

BCC

This field holds the identity of the tertiary receivers of the message 🤫 It should not be made available to the primary and secondary receivers, but it may be recorded to provide information for access control 🔒

D. MESSAGE-TYPE SPECIFICATION FIELDS 🎀

PRECEDENCE

This field describes how important and urgent the message is 🚨 Machine-readable notations go in angle brackets (<>). <PRIORITY> means the message should be delivered as soon as possible. <ROUTINE> means priority processing isn't necessary. Plain text can also go in this field 💅

MESSAGE-CLASS

This field describes the "legal" status of the message ⚖️ Examples include Official, Unofficial, Record, Off the Record, and Junk Mail. No automatic processing of this field is immediately expected 🙈 Some message creation processes might, for example, always insert:

MESSAGE CLASS: Unofficial ARPANET Message

SPECIAL-HANDLING

This field holds any special instructions for how the receiver's end should handle the message 🫣 Machine-readable notations go in angle brackets (<>). <PRIVATE> means the message reception process should not help the user pass copies around to others 🤐 Plain text can also go in this field 🦋