RFC 524

Proposed Mail Protocol

📅 published June 1973, from ietf

📜 RFC 524: A Proposed Mail Protocol 💌 (Part 1 of 6)

Okay bestie, welcome to RFC 524! ✨ It's from J. White at SRI-ARC, filed under NIC: 17140 on 13 June 1973, and it's a Network Working Group doc. 🦋 This part doesn't list any obsoletes or updates, and it doesn't say what category it's in, so I'm not guessing 🙈.

AUTHOR'S INTENT 🎀

This is the document the author promised in (15146,) to write. 💅 It's a proposed spec for handling mail on the Network, which is the Mail Protocol.

Right now, mail handling runs on two FTP commands, MAIL and MLFL. They let an FTP user process send a file or a string of text to an FTP server process and mark it as mail for a user, identified by a local name on that host. 📬 The protocol here is way richer, both in what it can do and in how flexible it is. 🔥

The author thinks you could build software from this doc, but this REALLY IS a Request for Comments 🫶. Comments, questions, and position papers are all welcome. The author is sure there are bugs in here and hopes readers will point them out via RFC as they find them 🐛.

Some people in the Network community pointed out specific problems with the existing mail commands and asked the author to keep them in mind while designing a new one. 💜 The author tried. If someone feels their concern got brushed off, or it slipped through the cracks (sorry in advance 🙈), the author asks them to prod once more.

INTRODUCTION 🌸

THE MAIL PROTOCOL ENVIRONMENT 🧚

The Mail Protocol (MP) is run by Mail user and server processes, following the model used by earlier high-level protocols. 🍓 Those Mail user and server processes are also FTP user and server processes. So MP is basically a set of commands you can use from inside the FTP command space. ✨

The MP command set lives conceptually inside a subsystem, which you enter from the FTP command space with this command:

MAIL <CFLF>
NOTE: Since a command called 'MAIL' already exists in the FTP command space, the command name 'XMAIL' might stand in for 'MAIL' while the current mail commands are being phased out. 🔄

The MP command set may or may not be run by a process that's separate from the one running FTP proper, depending on the particular server's implementation. 🌈

Here are the implications of the 'subsystem' idea. The reader and the implementer both need to know these 💅:

  • (1) Names of MP commands are only known inside the MP subsystem. MP commands must (and should naturally) be rejected by the server if the user process sends them outside the subsystem. 🚫
  • (2) You leave the Mail subsystem (back to the FTP command space) with this command, and only this command:
EXIT <CRLF>

FTP commands must be rejected by the server if the user sends them while inside the subsystem, meaning before EXIT is issued. 🙅‍♀️

  • (3) The same command name can be given to two completely different commands without confusion, as long as one lives in the FTP command space and the other in MP. The two are told apart by their context. 🧠 So MP and FTP don't fight over command names, and MP command names can be picked without caring about the environment the subsystem sits in. 💖
NOTE: Some commands defined inside MP copy FTP commands and use the same names. So a few commands are explicitly allowed inside MP. The reader will get that this fits the conventions in 1-3 above, and that no ambiguities come out of it. 👀

The subsystem idea (the name 'subsystem' is a different story) comes from Mike Padlipsky's Unified User Level Protocol (UULP), which this author totally supports 👑. MP is accessed through FTP, not as a separate program next to FTP launched from a more general executive, and that's only because FTP is widely implemented and UULP isn't. The author hopes protocol development will soon move in the direction UULP shows. 🦋

MP follows FTP's general syntax. Commands and their responses are strings of NVT characters. Command names are limited to four or fewer alphameric characters, upper or lower case, and they end with the character SP. Commands generally end with the TELNET New Line sequence (CR LF). Command responses have a numeric part (for processes to read) and a text part (for humans to read). 🤖 Both the reader and implementer should check the FTP protocol document for the full details. This doc doesn't copy that discussion. 📚

The FTP protocol document gives replies whose second digit is '6' to RJE functions. In the same way, MP takes the reply codes whose second digit is '7' to report results that are specific to its functions. 🎀 The author's position, though, is that FTP, MP, and the RJE protocol are all best built as subsystems under a common UULP executive. Then one subset of the reply space could be used without ambiguity by all three protocols (and any defined later), since every reply would implicitly carry the name of the subsystem it came from. 🧚‍♀️

THE MAIL MODEL 💌

MP defines mail as text that goes between users (both human and process) in less than real time, though ideally close to it ⏱️. The definition leaves out console-to-console communication, where users swap info at the character or line level. 🙅‍♀️

Pieces of mail have attributes like title, content, author, and recipient. 📝 A piece of mail could be a one- or two-line message from one person to another, a draft document one person sends to a design group for review, a polished formal document one group sends to another, or a message from a process to a human user (like an RJE server telling a user over Network Mail that their job finished) 🖨️. All of these count as mail and MP supports all of them. ✨

Pieces of mail can be forwarded from one place to another. 🔁

Pieces of mail can be replied to. 💬

The author of a piece of mail can be verified, which stops forgery and misrepresentation. 🕵️‍♀️

Pieces of mail can be permanently recorded. They get a long-term identifier so they can be retrieved for reference forever, and they can be entered in catalogs 📚. Access to that recorded mail can be limited to a chosen subset of the user community 🔒.

Some hosts accept mail for recipients who live somewhere else in the Network. Those hosts take responsibility for delivering it to them (including retrying when hosts are down, and so on) and acknowledge delivery to the sender 🫡.

The big picture for the reader is processes working together in different ways to move and manage Network mail flexibly 🌐. The author claims (no proof, obviously 😭) that this picture will get even more complicated later, but that the proposal here can be easily extended to handle that too 🔮.

ORGANIZATION OF THIS DOCUMENT 🗂️

The rest of this document has these components:

  • GLOSSARY: The concepts introduced briefly above get more formal definitions, and the protocol shows how they are represented. 📖
  • MP FUNCTIONS: Defines the command sequence a user process uses to start each logical function a Mail server process can perform, like Distribution, Recording, and Delivery. ⚙️
  • EXAMPLE: Shows an example of the command-response exchange between a user and a server. 🎬
  • COMMAND SUMMARY: Summarizes the MP commands. 📋
  • COMMAND REPLIES: Gives the reply code assignments and briefly explains them. 🔢
  • FORMAL SYNTAX: Specifies the formal syntax of the command language. 🧩

In every section except the last one (the formal syntax part), the document uses verbose keyword forms, for clarity 💅. Those verbose forms only exist in this document. When you implement a Mail user or server process, you use the terse keyword forms that appear in the formal syntax section 🫶.

GLOSSARY 📚✨

Terms are listed alphabetically here. Words or phrases in the definitions that start with capital letters are formally defined elsewhere in the glossary 💖.

ACCESS LIST (for a piece of Recorded Mail) 🔐

This is the set of individuals who can access a piece of Recorded Mail, plus, for each of those individuals, the type(s) of access they get 🗝️.

In the Protocol, an Access List is shown as a series of command pairs (placed next to each other in the command stream). Each pair has an ACCESS command followed right after by an optional ACCESSTYPES command. Each pair matches one individual in the set 💕.

ACCESS <individual> <CA>

ACCESSTYPE <accesstypes> <CA>

Command arguments say which Individual gets access, and what kind(s) of access they're allowed. They can get Read Access, Controlling Access, or both 👀.

If no Individual is specified, All is implied. Without an explicit ACCESSTYPES command, the assumed access is Read Access only 🙌.

If there's no explicit Access List at all, the assumed one gives Read Access to All and Controlling Access to the Author(s) and the Clerk 👑.

ACKNOWLEDGMENT (for a piece of Mail) 💌✅

This is a kind of Unrecorded Mail. A Distribution Agent generates it, and its Recipient is the Monitor for an earlier piece of Mail. It confirms Delivery (successful or not) to the Recipient(s) of that first piece of Mail 📨.

An Acknowledgment carries the Serial Number of the Mail it acknowledges, as the Reference Serial Number 🔢.

ACKNOWLEDGMENT CONDITION (for Acknowledgments) 🚦

This is the attribute of an Acknowledgment that decides when the Distribution Agent will generate it ⏰.

These Acknowledgment Conditions are defined:

  • ALWAYS: An Acknowledgment is given once all Deliveries are complete, whether or not they all succeeded. 🌟
  • FAILURE: An Acknowledgment is given once all Deliveries are complete, if and only if Delivery to one or more Recipient(s) fails. 💀
  • NEVER: An Acknowledgment is never made. 🙅‍♀️

An Acknowledgment Condition is represented in the Protocol with this command:

ACKCONDITION <ackcondition> <CA>

In the absence of an explicit ACKCONDITION command, one with an argument of FAILURE is to be assumed. 💀

ACKNOWLEDGMENT TYPE (for Acknowledgments and Progress Reports)

Okay so this is the attribute that decides what the Content of an Acknowledgment or Progress Report looks like. 🦋

The following Acknowledgment Types are defined:

  • TERSE: The Protocol specifies the Content to be an unembellished list of the Mail's Recipient(s) and the current Delivery Status for each. Recipients whose Delivery Status is SUCCESSFUL are left off the list. A TERSE Acknowledgment's Content is one or more instances of the following:
<deliverystatus> <individual> <CRLF>

TERSE Acknowledgments and Progress Reports are meant to be process-readable. 🤖

  • VERBOSE: The Protocol does not specify the Content. It might include a list of the Recipient(s) who couldn't get the Mail and why, the times Delivery was made to others, and so on. VERBOSE Acknowledgments and Progress Reports are meant to be human-readable. 💖

An Acknowledgment Type is represented in the Protocol by the command:

ACKTYPE <acktype> <CA>

In the absence of an explicit ACKTYPE command, one with an argument of TERSE is to be assumed. 🌸

ALL

Every conceivable Individual. 🌍✨

AUTHOR (of a piece of Mail)

An Individual (there may be more than one) who gets formal recognition for having authored a piece of Mail. 🎀

AUTHOR LIST (for a piece of Mail)

The set of Individuals who are the Author(s) of a piece of Mail. 💅

An Author List is represented in the Protocol as an Individual List of type AUTHOR.

CATALOG (of Recorded Mail)

A named database that holds the Citation for each member of a set of logically related pieces of Recorded Mail. 📚

CATALOG LIST (for a Piece of Recorded Mail)

The set of Catalogs that each contain the Citation for a piece of Recorded Mail. 🧚

A Catalog List is represented in the Protocol as a series of instances (juxtaposed in the command stream) of the following command. Each instance corresponds to one Catalog in the set.

CATALOG <catalog> <CA>

CITATION (for a piece of Recorded Mail)

The Static and Dynamic Attributes of a piece of Recorded Mail. 🦋

CITATION COMPONENT

Any one of the Static or Dynamic Attributes that make up a Citation. 🧩

CITATION RETRIEVAL (for a piece of Recorded Mail)

The act of retrieving selected Citation Component(s). 🔍

CITATION TEMPLATE

A specified subset of the Citation Component(s) for a piece of Recorded Mail. 🎀

A Citation Template is represented in the Protocol by the command:

CITATIONTEMPLATE <citationtemp> <CA>

The argument is a list of Citation Component(s). If there's no explicit CITATIONTEMPLATE command (or the argument is null), one specifying Content only is to be assumed. 🫶

CLERK

The Individual who prepares a piece of Mail for Recording, Distribution, or Delivery. Conceptually, this is the Individual with proof-reading responsibility for the piece of Mail. 📝

A Clerk is represented in the Protocol as an Individual List of type CLERK and length 1.

COMMENTS (for a piece of Mail)

An informal, maybe verbose description of the Content of a piece of Mail, or any other info the Author(s) want the Recipient(s) to be able to access. 💬

Comments are represented in the Protocol by the command:

COMMENTS <comments> <CA2>

In the absence of an explicit COMMENTS command, one with a null argument is to be assumed. 🌈

CONTENT (of a piece of Mail)

It's text. 💜

Content is represented in the Protocol by either of the two commands below:

FILE <CA>

The FILE command means the Content of the Mail will be transmitted (immediately) as a file, using the FTP data transfer commands (e.g., BYTE, SOCK, TYPE) that are currently in effect. FILE works exactly like an FTP STOR command (in its use of data transfer commands, in its establishment of the data connection, and so on), with two differences: no pathname is required, and the server doesn't deposit the transmitted file in its file system. Instead, it disposes of the file in a manner appropriate for Mail. 📁

TEXT <string> <CA2>

The TEXT command means the Content of the Mail follows on the TELNET connection as a series of lines. Each line is delimited from the one before it by CR LF, and the whole thing is finally terminated by a CA2. 🧾

CONTROLLING ACCESS (to a piece of Recorded Mail)

The right of an Individual to modify a Dynamic Attribute of a piece of Recorded Mail. 🔐

Recording Agents permit an Individual to modify a Dynamic Attribute of a piece of Recorded Mail if and only if they can properly identify themselves as someone having Controlling Access to that Mail. 🙈

CREATION DATE (of a piece of Mail)

The date and time when the Clerk finishes the final draft of a piece of Mail, before releasing it to a Delivery, Distribution, or Recording Agent for further processing. Each piece of Mail has a single Creation Date. ⏰

This date is usually different from the Delivery or Recording Date, since Mail often has to be queued (waiting for another host to come up) inside the Delivery, Distribution, or Recording Agent's host before Delivery or Recording can happen. 🕰️

A Creation Date is represented in the Protocol by the command:

CREATIONDATE <datetime> <CA>

CUTOFF INTERVAL (for Distribution of a piece of Mail)

The period of time, measured from the Distribution Date, after which the Distribution Agent is to give up on Delivery attempts for any Recipient(s) who still haven't been reached. 🛑

A Cutoff Interval is represented in the Protocol by the command:

CUTOFF <interval> <CA>

In the absence of an explicit CUTOFF command, one specifying an Interval of 7 days is to be assumed. 📅

DELIVERY (of a piece of Mail)

The act of transmitting a piece of Mail to the host of one of its Recipient(s). 🚚

DELIVERY AGENT

A process that carries out Delivery of a piece of Mail. A Distribution Agent is, by nature, also a Delivery Agent. 🤝

DELIVERY DATE (of a piece of Mail to one of its Recipient(s))

The date and time when a Delivery Agent delivers a piece of Mail to a Recipient's system. Every piece of Mail has a whole bunch of Delivery Dates, one for each Recipient. 📬

DELIVERY STATUS (for a piece of Mail with respect to a Recipient)

A measure of how successful a Delivery Agent has been, at a given point in time, at delivering a piece of Mail to one of its Recipient(s). Every piece of Mail has a whole bunch of Delivery Statuses, one for each Recipient. 📊

The following Delivery Statuses are defined:

  • FAILED: Delivery was rejected by the Recipient's system. For example, the connection request was rejected, the Mail server process doesn't support Delivery, or the server didn't recognize the Recipient. ❌
  • SUCCESSFUL: Delivery was accomplished successfully. ✅
  • TIMED OUT: Either the Recipient's host was disconnected from the Net at every Delivery attempt, or no Mail server process has ever responded to the connection attempt. Hope of Delivery has been abandoned. 😭
  • WAITING: Either the Recipient's host has been disconnected from the Net at every Delivery attempt, or no Mail server process has responded to the connection attempt yet. Delivery attempts are still going on periodically. ⏳
  • UNATTEMPTED: No Delivery attempt has been made yet. 🌱

DELIVERY TYPE (for a Delivery)

The nature of the piece of Mail being delivered. 🎭

The following Delivery Types are defined:

  • FORWARD: A Delivery of type FORWARD represents a piece of Recorded or Unrecorded Mail that is being Forwarded. ↪️
  • MAIL: A Delivery of type MAIL represents a piece of Recorded or Unrecorded Mail whose ultimate source is an Individual. This is the "normal" Delivery type. 💌
  • NEGATIVE ACKNOWLEDGMENT: A Delivery of type NEGATIVE ACKNOWLEDGMENT represents a piece of Unrecorded Mail generated by a Distribution Agent. It acknowledges unsuccessful or partially unsuccessful Delivery of a previous piece of Mail (identified by Reference Serial Number) to its Recipient(s). The Recipient of this "system" Mail is the Monitor for the previous piece of Mail. 🙅
  • POSITIVE ACKNOWLEDGMENT: A Delivery of type POSITIVE ACKNOWLEDGMENT represents a piece of Unrecorded Mail generated by a Distribution Agent. It acknowledges successful Delivery of a previous piece of Mail (identified by Reference Serial Number) to its Recipient(s). The Recipient of this "system" Mail is the Monitor for the previous piece of Mail. 🙌
  • PROGRESS REPORT: A Delivery of type PROGRESS REPORT represents a piece of Unrecorded Mail generated by a Distribution Agent. It reports the Delivery of a previous piece of Mail (identified by Reference Serial Number) to its recipient(s). The Recipient of this "system" Mail is the Monitor for the previous piece of Mail. 📈
  • REPLY: A Delivery of type REPLY represents a piece of Recorded or Unrecorded Mail generated in reply to (or pertaining to) a previous piece of Mail (identified by Reference Serial Number). 💬

Delivery Type is represented in the Protocol by the command:

DELIVERYTYPE <deliverytype> <CA>

In the absence of an explicit DELIVERYTYPE command, one with an argument of MAIL is to be assumed. 💖

DISTRIBUTE DATE (for a piece of Mail)

The date and time when a piece of Mail is handed to a Distribution Agent for Distribution. 🗓️

DISTRIBUTION (of a piece of Mail)

The act of Delivering a piece of Mail to its Recipient(s). Distribution can be carried out either by the Clerk's Delivery Agent, or by a Distribution Agent acting on the Clerk's behalf. 📣

DISTRIBUTION AGENT

A Mail server process that acts as an intermediary in the delivery process. It accepts Mail for Recipient(s) in hosts other than its own, takes on responsibility for Delivering the Mail to them, and returns Acknowledgments to the appointed Monitor. 🦸

DISTRIBUTION LIST

In the Delivery or Distribution of a piece of Mail, the set of Individuals who are to receive Delivery of the Mail. 📋

In the Recording of Mail, a Distribution List is the set of Individuals who have received formal, authorized Delivery of a piece of Mail 📬 The list is kept current by Distribution Agents. Of course, any Individual with Read Access to the Mail can Deliver it informally to anyone they want, and that won't be reflected in the Distribution List, so it's a bit of a secret handshake 🤫

A Distribution List is represented in the Protocol as a series of command quintuplets, juxtaposed in the command stream 🧚 Each quintuplet starts with a RECIPIENT command, followed immediately (and optionally) by any or all of these, in this order: a GENERALDELIVERY, a GREETING, a SIGNATURE, and a DISPOSITION command. Each quintuplet corresponds to one individual in the set 💖

RECIPIENT <individual> <CA>
GENERALDELIVERY <CA>

This command only makes sense in the context of the Delivery function 💅 If the previous RECIPIENT command gets back this reply:

474 Recipient unrecognized: is General Delivery
OK?

then issuing the GENERALDELIVERY command counts as consent to go ahead with General Delivery to that Recipient ✨ If no consent is given, the RECIPIENT command is rejected, no drama. Unsolicited GENERAL DELIVERY commands in the Distribution List (the ones nobody asked for) are treated by the server as NOPs 🙈

GREETING <greeting> <CA>

The GREETING command specifies the Greeting the Recipient will see 🎀 If the first quintuplet in the list has no GREETING command, a null argument is assumed. After that, if there's no explicit GREETING command, the Greeting is assumed to be identical to the one in the previous quintuplet, so it carries over like a true bestie 🫶

SIGNATURE <signature> <CA>

The SIGNATURE command specifies the Signature the Recipient will see 🌸 Same deal as Greetings: if the first quintuplet has no SIGNATURE command, a null argument is assumed, and after that, a missing SIGNATURE command means the previous quintuplet's Signature gets reused 🦋

DISPOSITION <disposition> <CA>

The DISPOSITION command shows the intent behind the Mail being Delivered to the Recipient by the Author(s), and it can take any, all, or none of the following as arguments 👑

  • RSVP: The Author(s) request a Reply from the Recipient 💌
  • ACTION: The Author(s) expect some action from the Recipient. If ACTION doesn't show up, the Mail is just for the Recipient's information, no pressure 🍓
  • INTERRUPT: The Author(s) declare that the Recipient needs to look at the Mail urgently 🚨 In that case, the Recipient's Mail server process may, upon Delivery, choose to interrupt the Recipient if they happen to be logged in at a terminal 💀

No specific action is required in response to any of these arguments, and the server is free to treat DISPOSITION commands as NOPs if it likes 🌈

The absence of a DISPOSITION command implies one with no arguments, which means for the Recipient's information only, no Reply required, and not urgent 🧸

DYNAMIC ATTRIBUTES (of a piece of Recorded Mail)

These are the attributes of a piece of Recorded Mail (the Distribution List, Access List, and Catalog List) that get initial values at Recording Time, but an Individual with Controlling Access to the piece of Mail can always change them later 🔧

FORWARDING (of Mail received for an Individual)

This is the act of moving the Mail that has been Delivered to an Individual but not yet Read over to a different Individual 📦

Users who are known at more than one host can gather their unRead Mail to one central location by doing the Forwarding function at each of those hosts. In this case, both Individuals are instances of the same User 🧚 Mail that has been Forwarded is considered Read at its source 👀

FORWARDEE

This is the Individual whose Delivered but UnRead Mail is going to be Forwarded 🦋

A Forwardee is represented in the Protocol as an Individual List of type FORWARDEE and length 1.

GENERAL DELIVERY (of a piece of Mail to an unrecognized Recipient)

This is when a server accepts Delivery of a piece of Mail on behalf of an intended Recipient whose name it doesn't recognize 🕵️‍♀️ The server holds onto the Recipient's name and makes it, plus the other information the user process supplied, available to some competent person who tries to figure out who the name belongs to. If the Recipient is recognized, the Mail gets "hand" delivered to the right Individual 💌

General Delivery of a piece of Mail to one of its intended Recipient(s) only happens after the server tells the user process what it plans to do and gets the user process's consent 🫶 If that consent isn't given, or if the server doesn't implement General Delivery at all, the server rejects the Delivery attempt for that Recipient 💀

Consent for General Delivery is represented in the Protocol by this command:

GENERALDELIVERY <CA>

GREETING (for the Delivery of a piece of Mail to a Recipient)

A short greeting to a Recipient of a piece of Mail. "Dear Dave" is a valid, and honestly pretty typical, Greeting 💖

A Greeting is represented in the Protocol by this command:

GREETING <greeting> <CA>

ID (for an Individual)

This is the password an Individual may have to present to a Mail server process to prove who they are 🔐

An Id is represented in the Protocol by this command:

ID <id> <CA>

Ids have nothing to do with accounting. When a server requires one, it's only there to protect that server from forgery or misrepresentation 🛡️

INDIVIDUAL

An instance of a User, identified by NIC Ident, or by the combination of host and Mailbox Name 🎀

INDIVIDUAL LIST (of type "t" and length "n")

This is a set of Individuals 🌸

An Individual List is represented in the Protocol as a series of "n" command pairs, juxtaposed in the command stream. Each pair is a "t" command followed immediately by an ID command, and each pair corresponds to one Individual in the set ✨

The ID command is given by the Mail user process at the option of the Mail server process. Whenever the server requires it, it must prompt for it with an appropriate reply to the preceding "t" command 🙋‍♀️ If no such prompt is given, the user process isn't obliged to provide the ID command, but it can if it wants to. In that case, the server has to treat it as if it had been prompted for and found correct 🤝

The ID command is how the server makes sure the user process isn't acting without proper authorization from the Individual(s) involved. In other words, it's how a server protects itself against forgery, misrepresentation, and so on 🔥

"t" <individual> <CA>
ID <id> <CA>

MAIL

A body of text communicated from one set of Individual(s) to another, in less than (but ideally approaching) real time ⚡

MAILBOX NAME

The name a User uses at a host to send and receive Mail 📮

MONITOR (for a piece of Mail)

This is the Individual who is the recipient for Acknowledgments and Progress Reports 👀

A Monitor is represented in the Protocol as an Individual List of type MONITOR and length 1.

Monitor defaults to the Clerk if it isn't explicitly specified 🧚

PROGRESS REPORT (for a piece of Mail)

This is a form of Unrecorded Mail, generated periodically during the distribution process by a Distribution Agent. Its Recipient is the Monitor for a previous piece of Mail, and its Content is a list of the Recipient(s) along with the current Delivery Status for each one 📊 A Progress Report carries the Serial Number of the Mail whose status it reports, as the Reference Serial Number 🎀

PROTOCOL

The Mail Protocol (MP) 💜

READ (a piece of previously-Delivered Mail)

The act, on the part of the User, of examining a piece of Delivered Mail 👁️

READ ACCESS (to a piece of Recorded Mail)

This is the right of an Individual to retrieve the Content of a piece of Recorded Mail 🔑

Recording Agents let an Individual retrieve the Content of a piece of Recorded Mail if, and only if, they can properly identify themselves as someone with Read Access to that Mail. An Individual can retrieve the Citation (everything except Content) from the Recording Agent whether or not they have Read Access to the Mail 🗂️

READ DATE (of a piece of Mail for one of its Recipient(s))

The date and time, which necessarily comes after Delivery, at which a Recipient Reads a piece of Mail 📅 Each piece of Mail has a whole bunch of Read Dates, one for each Recipient 🫶

RECIPIENT (of a piece of Mail)

An Individual who has, or is about to receive, Delivery of a piece of Mail 💌

RECORDED MAIL

A piece of Mail whose Citation is available on a long-term (indefinite) basis from a Recording Agent 📚

RECORDING

The service a Recording Agent provides 🎞️

RECORDING AGENT

A Mail server process that accepts Mail, permanently Records its Citation, and assigns a pathname so that an Individual with appropriate access can retrieve that information at any time 🗄️

RECORDING DATE

The date and time at which a piece of Mail is presented to a Recording Agent for Recording. Each piece of Recorded Mail has a single Recording Date 📆

REFERENCE SERIAL NUMBER (for an Acknowledgment, Progress Report, or Reply)

This is the Serial Number of the piece of Mail that an Acknowledgment, Progress Report, or Reply refers to 🔗

A Reference Serial Number is represented in the Protocol by this command:

REFERENCESERIAL <serialnumber> <CA>

If there's no explicit REFERENCESERIAL command, no Serial Number is to be assumed 🙅‍♀️

REPLY (to a previous piece of Mail)

A piece of Recorded or Unrecorded Mail whose Author(s) are the Recipient(s) of a previous piece of Mail. It replies to or pertains to that same piece of Mail, and it carries that piece's Serial Number as the Reference Serial Number 💬

REPORT INTERVAL (for a Progress Report)

This is the interval between Progress Reports ⏰

A Report Interval is represented in the Protocol by this command:

REPORTINTERVAL <interval> <CA>

If there's no explicit REPORTINTERVAL command, one with an argument whose value is effectively infinite is assumed, which means no Progress Reports get made 🌌

REQUESTOR

The Individual on whose behalf a Mail user process connects to and interacts with a Mail server process 🧑‍💻

A Requestor is represented in the Protocol as an Individual List of type REQUESTOR and length 1.

SERIAL NUMBER (for a piece of Mail)

A Serial Number 🎀 is a short-term identifier that the Clerk (or his system) attaches to a piece of Mail. It rides along with Acknowledgments, Progress Reports, and Replies, and it's how you match each of those back to the original. A Serial Number lives from the moment the Clerk assigns it until the Recipient(s) Reply(s) get Delivered to the Author(s), or until they decide not to reply at all 💅.

A Serial Number shows up in the Protocol as this command:

SERIAL <serialnumber> <CA>

If there's no explicit SERIAL command, then no Serial Number is assumed 🙈.

SIGNATURE (for the delivery of a piece of Mail to a Recipient) ✨ This is a human-readable note about who the Author(s) of a piece of Mail are. Jim and Dick is a valid Signature, so you know it's giving duo energy 👯.

A Signature is represented in the Protocol by this command:

SIGNATURE <signature> <CA>

STATIC ATTRIBUTES (of a piece of Recorded Mail) 🔒 These are the attributes of Recorded Mail (Content, Title, Comments, Author(s), Clerk, and Creation Date) that get locked in at Recording Time. Once they're set, they can never be changed, so they're basically forever 💖.

You can set Static Attributes one at a time with their own commands, which are described elsewhere. Or you can set them all at once by pointing at an existing piece of Recorded Mail. This command gives the current piece of Mail the same Static Attributes as the one it references, and it's exactly the same as sending a bunch of TITLE, COMMENTS, and so on commands 🦋.

LOCATION <fileaddr> <CA>

TITLE (of a piece of Mail) 🌸 A Title is a short, snappy description of what the Content is about.

A Title is represented in the Protocol by this command:

TITLE <title> <CA>

If there's no explicit TITLE command, the Title is assumed to be a null argument 🫶.

UNRECORDED MAIL 📭 This is Mail that never gets handed to a Recording Agent for permanent storage and cataloging. It just gets Delivered straight to its Recipient(s) by a Delivery Agent.

UPDATE REQUEST (to a Recording Agent for a piece of Recorded Mail) 🔥 This is when you ask a Recording Agent to add, replace, or delete an Individual on the Access or Distribution List for a piece of Mail. You can also ask it to add or delete a Catalog on the Catalog List 👑.

An Update Request is represented in the Protocol by this command:

UPDATETYPE <updatetype> <CA>

It gets followed right away in the command stream by an Access, Distribution, or Catalog List.

USER 🧚 A process or a human who sends and/or receives Mail. Main character energy, honestly 🌈.

USER VERIFICATION ⭐ This is the act of confirming that an ID really belongs to a specific Individual. No catfishing allowed 💀.

USER VERIFICATION AGENT 💜 This is a Mail server process that does the User Verification.

MP FUNCTIONS 🦋

An MP function is what happens when a Mail user process asks for a major task related to managing Mail and a server goes and performs it. The following functions are defined:

RECORDING
DELIVERY
DISTRIBUTION
FORWARDING
CITATION RETRIEVAL
UPDATE CITATION
USER VERIFICATION

Okay so you'd expect the Network to have just a few Recording Agents (who do the Recording, Citation Retrieval, and Update Citation functions) 🗂️. It'd also have a few Distribution Agents (who do the Distribution function), one or two User Verification Agents (who do the User Verification Function), and tons of hosts doing the Delivery and Forwarding functions 🌸.

A host can implement any, all, or none of the functions the Protocol defines, and that's totally fine 💅. A host can also require a login (for accounting purposes) before it lets a user process touch any of the functions it has implemented 🔐.

If an FTP server process doesn't want to implement MP, or doesn't want to implement a particular MP function, it just rejects the command asking for that unimplemented server with this reply:

400 Function not implemented.

If a server wants login before anyone can get into the MP subsystem or a particular MP function, it rejects the command asking for that charged-for service with this reply:

332 Login first, please.

The functions defined in MP are below ✨.

RECORDING 🎀

The Recording function is kicked off with this command:

RECORD <CA>

Once that command goes out, the user process shall provide the following, in whatever order works for it:

(1) Any Static Attributes it wants.

Content and Clerk are required. Defaults for the other Static Attributes (which the server applies if the matching commands don't show up) are:

  • Title or Comments as specified in the glossary.
  • Author to the Clerk.
  • Creation Date to the Recording Date.

(2) Initial values for any Dynamic Attributes it wants.

Defaults (which the server applies if the matching commands don't show up) are:

  • Distribution and Catalog Lists to null.
  • Access List as specified in the glossary.

The Recording function ends with one of these two commands:

EXIT <CA>    or    ABORT <CA>

EXIT is the normal ending. It tells the server to go ahead and perform the Recording function with the parameters that were just given 🥰. ABORT is the abnormal ending. It exits the function without the server taking any action at all, so the whole command exchange, starting from RECORD, is basically a NOP 🙃.

DELIVERY 📬

The Delivery function gets started with this command:

DELIVER <CA>

Once that command goes out, the user process shall provide the following, in whatever order works for it:

(1) Any Static Attributes it wants.

Content is required. Defaults for the other Static Attributes (which the server applies if the matching commands don't show up) are:

  • Title or Comments as specified in the glossary.
  • Clerk to null
  • Author to the Clerk.
  • Creation Date to the Delivery Date.

(2) Any Dynamic Attributes it wants.

Distribution List is required. Defaults (which the server applies if the matching commands don't show up) are:

  • Catalog List to null
  • Access List as specified in the glossary.

Both of these attributes are only for the Recipient's information when they're presented in the context of Delivery. So defaulting them to null just means the Clerk doesn't want them passed along to the Recipient 🤫.

(3) Any or all of the following optional parameters:

  • (a) Delivery Type
  • (b) Acknowledgment Type

Specifying this parameter is appropriate if and only if the Delivery Type is POSITIVE or NEGATIVE ACKNOWLEDGMENT or PROGRESS REPORT. In this context, Acknowledgment Type tells the server how to read the Content of the Acknowledgment 🧐.

  • (c) Serial Number

The Serial Number assigned to the piece of Mail being Delivered. This parameter is inappropriate unless the Delivery Type is FORWARD (in which case the Serial Number is the one kept from the previous Delivery), MAIL, or REPLY 🔁.

  • (d) Reference Serial Number

The Serial Number assigned to the piece of Mail that the current piece of Mail is an Acknowledgment, Progress Report, or Reply to. Specifying this parameter is therefore inappropriate if the Delivery Type is MAIL 🙅‍♀️.

The Delivery function ends with one of these two commands:

EXIT <CA>    or    ABORT <CA>

EXIT is the normal ending. It tells the server to perform the Delivery function with the parameters that were just given 💖. ABORT is the abnormal ending. It exits the function without the server taking any action, so the whole command exchange, starting from DELIVER, is basically a NOP 😭.

DISTRIBUTION 📣

The Distribution function gets started with this command:

DISTRIBUTE <CA>

Once that command goes out, the user process shall provide the following, in whatever order works for it:

(1) Any Static Attributes it wants.

Content is required. Defaults for the other Static Attributes (which the server applies if the matching commands don't show up) are:

  • Title or Comments as specified in the glossary.
  • Clerk to null
  • Author to the Clerk.
  • Creation Date to the Delivery Date.

(2) Any Dynamic Attributes it wants.

Distribution List is required. Defaults (which the server applies if the matching commands don't show up) are:

  • Catalog List to null
  • Access List as specified in the glossary.

Both of these attributes are only for the Recipient(s) information when they're presented in the context of Distribution. So defaulting them to null just means the Clerk doesn't want them passed along to the Recipient(s) 🌈.

(3) Any or all of the following optional parameters:

  • (a) Delivery Type

MAIL, FORWARD, or REPLY only.

  • (b) Serial Number

The Serial Number of the Mail being Distributed. The Distribution Agent will relay this Serial Number to each Recipient at Delivery 📨.

  • (c) Reference Serial Number

The Serial Number of the piece of Mail that the current piece of Mail is a Reply to. The Distribution Agent will relay this Serial Number to each Recipient at Delivery. Specifying this parameter is appropriate if and only if the Delivery Type is REPLY 🎯.

  • (d) Acknowledgment Condition

An Acknowledgment is requested from the Distribution Agent if and only if the Acknowledgment Condition is other than NEVER ✅.

  • (e) Acknowledgment Type
  • (f) Cutoff Interval
  • (g) Report Interval

Progress Reports are requested from the Distribution Agent if and only if this parameter is specified explicitly 📊.

  • (h) Monitor

This parameter is ignored unless an Acknowledgment or Progress Reports (or both) are requested 👀.

The Distribution function ends with one of these two commands:

EXIT <CA>    or    ABORT <CA>

4. Distribution, Continued 📬

okay so EXIT is the happy path bestie ✨ it means normal termination, and the server then runs the Distribution function using the parameters you just handed over 💌 ABORT is the bail-out move 🙈 it exits with no action taken by the server, so the whole exchange that started with DISTRIBUTE is literally a NOP. nothing happened, no drama 🫶

FORWARDING 🦋

The Forwarding function gets invoked with this command:

FORWARD <CA>

Once you send that, the user process shall provide the following, in whatever order works for it 💅

  1. Forwardee
  2. Distribution list

This is the set of Individual(s) to whom the Mail is to be Forwarded.

The Forwarding function ends with one of these:

EXIT <CA>    or    ABORT <CA>

EXIT is normal termination, and the server then performs the Forwarding function using the parameters you just gave it 🎀 ABORT is abnormal termination, so the server takes no action and the whole exchange starting with FORWARD is a NOP 🙃

CITATION RETRIEVAL 🌸

The Citation Retrieval function gets invoked with this command:

RETRIEVE <CA>

Once that's given, the user process shall provide the following, in any order that suits it 💖

  1. The pathname of the piece of Mail whose Citation is to be retrieved:
PATHNAME <pathname> <CA>
  1. Any or all of the following optional parameters:
    • (a) Citation Template
    • (b) Requestor

This parameter is required if and only if Content is requested and Read Access happens not to be granted to All, in which case the server verifies that the Requestor has Read Access to the piece of Mail. 🔐

  • (c) FILE <CA>

This command is appropriate if and only if Content is requested. If you send FILE, the Content of the Mail gets returned to the user process as a file, after any other Citation Components you asked for have come back over the TELNET connection 📁 It uses the FTP data transfer commands (e.g., BYTE, SOCK, TYPE) that are in effect at the time. FILE is exactly equivalent in effect to an FTP RETR command, including how it uses data transfer commands and how it sets up the data connection, except that no pathname is required. ngl this is giving FTP energy, very on brand 🧚

Without a FILE command, Content comes back over the TELNET connection like any other Citation Component 💅

The server returns the Citation Components in the order you requested them, with one exception: Content, if it was requested as a file, is always returned after the 'end of citation' indication. Each one comes back as a reply whose numeric code is 172, and whose text is exactly the command normally used to communicate that same parameter to the server. A reply whose numeric code is 173 terminates the reply list 🏁

Title and Content can each contain the TELNET New Line sequence (CR LF) in general, so they're sent as continued replies using the FTP reply continuation convention (see the FTP protocol document). The first four characters of each reply line, except the first and last, are blanks that the server inserted. The user process must delete them to correctly recover the value of the Title or Content 🦋

The Citation Retrieval function ends with one of these:

EXIT <CA>    or    ABORT <CA>

EXIT is normal termination, and the server performs the Citation Retrieval function with the parameters you just gave 🎉 ABORT is abnormal termination, so the server takes no action and the whole exchange starting with RETRIEVE is a NOP 🫠

UPDATE CITATION 💜

The Update Citation function gets invoked with this command:

UPDATE <CA>

Once that's given, the user process shall provide the following, in any order that suits it ✨

  1. Requestor

This parameter is required unless Controlling Access has been granted to All. If Controlling Access is granted to All and you send it anyway, the server treats it as a NOP. Otherwise the server verifies that the Requestor has Controlling Access to the piece of Mail 👑

  1. One or more Update Requests

The Update Citation function ends with one of these:

EXIT <CA>    or    ABORT <CA>

EXIT is normal termination, and the server performs the Update Citation function with the parameters you just gave 🌈 ABORT is abnormal termination, so the server takes no action and the whole exchange starting with UPDATE is a NOP 🥲

USER VERIFICATION 🧚

The User Verification function gets invoked with this command:

VERIFY <CA>

Once that's given, the user process shall specify any number of Requestors 🫶

The server prompts for the Id for each Requestor, the user process provides it, and the server returns a reply. The reply's numeric code is 272 if the Id is correct, or 472 otherwise 🔍

The User Verification function ends with one of these:

EXIT <CA>    or    ABORT <CA>

EXAMPLE 🎀

In this example, a short message gets recorded for public access and distributed to a single recipient. The user process is assumed to already be connected to the server 🔌

Note: This would be the implementation of NIC Journal Submission, where the NIC is understood to be both a Recording and Distribution Agent. 💀

Replies from the server are in brackets. Here we go 🍓

The Mail system gets invoked:

MAIL <CA>

Mail system is invoked, and the server replies with what it supports:

[261 RE DE DI FW CI UP UV -- supported.]

The Recording function gets invoked:

REC <CA>
[200 OK.]

A Title is given:

TITL SMFS Runs on TENEX 1.31 at the NIC <CA>
[200 OK.]

The Content of the message is entered:

TEXT The NIC came up on TENEX 1.31 on 1-APR. <CRLF> I tried SMFS
here on the new monitor and it <CRLF> works fine.  I don't
understand why I had <CRLF> problems running your copy of the code
at <CRLF> BBN-TENEX.  Are you still unable to reference <CRLF> the
same archived file from two different <CRLF> TENEXs? <CA2>
[200 OK.]

The Clerk is identified as White at SRI-ARC:

CLER WHITE@SRI-ARC <CR>
[330 OK.  Now Id, please]

His Id is supplied:

ID id <CA>
[200 OK.]

Exit from the Recording function is effected, and the pathname '15490' is returned by the Recording Agent for the now Recorded Mail. Ta-da, it's recorded 🎊

EXIT <CA>
[270 15490 -- is assigned as the pathname.]

The Distribution function gets invoked:

DIST <CA>
[200 OK.]

The message just recorded is specified for Distribution:

LOC SRI-ARC 15490 <CA>
[200 OK.]

The Recipient is specified via NIC Ident to be Dave Crocker at UCLA-NMC:

RECI * DHC <CA>
[200 OK.]

A Greeting is given:

GREE Dave <CA>
[200 OK.]

A reply is requested:

DISP R
[200 OK.]

The message is signed:

SIGN Jim
[200 OK.]

Acknowledgment of the Mail's Delivery is requested whether Delivery succeeds or fails. 📨

ACKC A <CA>
[200 OK.]

The Acknowledgment is to be terse 🤏

ACKT T <CA>
[200 OK.]

If Delivery hasn't been effected within 24 hours, the attempt is to be abandoned, and an Acknowledgment of failure returned. The Monitor (to whom the Acknowledgment is sent) is allowed to default to the Clerk ⏰

CUT 1 D <CA>
[200 OK.]

A Serial Number is assigned for purposes of coordinating Acknowledgment and Reply. A desirable implementation of the sender's user and server processes is one in which the Serial Number is assigned by the user process, rather than by the human user himself, in such a way that his server process can automatically make the association between original Mail, and subsequent Acknowledgment and Reply. the server does the matching for you, so chef's kiss 👩‍💻

SERI serial <CA>
[200 OK.]

Exit from the Distribution function is effected:

EXIT <CA>
[200 OK.]

Exit from the Mail subsystem is effected:

EXIT <CA>
[200 OK.]

COMMAND SUMMARY 💅

Every command requires at least one reply from the server 💬

THOSE SPECIFIC TO MP 🌸

ABORT <CA>
ACCESS <individual> <CA>
ACCESSTYPES <accesstypes> <CA>
ACKCONDITION <ackcondition> <CA>
ACKTYPE <acktype> <CA>
AUTHOR <individual> <CA>
CATALOG <catalog> <CA>
CITATIONTEMPLATE <citationtemp> <CA>
CLERK <individual> <CA>
COMMENTS <comments> <CA>
CREATIONDATE <datetime> <CA>
CUTOFF <interval> <CA>
DELIVER <CA>
DELIVERYTYPE <deliverytype> <CA>
DISPOSITION <disposition> <CA>
DISTRIBUTE <CA>
EXIT <CA>
FILE <CA>
FORWARD <CA>
FORWARDEE <individual> <CA>
GENERALDELIVERY <CA>
GREETING <greeting> <CA>
ID <id> <CA>
LOCATION <fileaddr> <CA>
MAIL <CA>
MONITOR <individual> <CA>
PATHNAME <pathname> <CA>
RECIPIENT <individual> <CA>
RECORD <CA>
REFERENCESERIAL <serialnumber> <CA>
REPORTINTERVAL <interval> <CA>
REQUESTOR <individual> <CA>
RETRIEVE <CA>
SERIAL <serialnumber> <CA>
SIGNATURE <signature> <CA>
TEXT <string> <CA2>
TITLE <title> <CA>
UPDATE <CA>
UPDATETYPE <updatetype> <CA>
VERIFY <CA>

THOSE BORROWED FROM FTP 🦋

The following commands are borrowed from FTP, and they're also defined as MP commands so you can transfer the Content of a piece of Mail in 'file' form. For how they work and their syntax, check the FTP protocol document 📖 The borrowed commands are BYTE, SOCK, PASV, TYPE, STRU, MODE, REST, and SITE.

The following commands are also borrowed from FTP and defined as MP commands, so you can change accounting parameters inside the MP subsystem. The accounting parameters in force when you enter the subsystem apply inside it (where needed) until they get changed. Any values you change them to while inside the subsystem stay in effect after you return to the FTP command space 💸 The borrowed commands are USER, PASS, and ACCT.

The following miscellaneous commands are borrowed from FTP and also defined as MP commands: HELP and NOOP ✨

COMMAND REPLIES 💌

Okay so bestie, real talk: this list is definitely NOT complete 🙈 The author tried their absolute best to predict every kind of back-and-forth between user and server, but some crucial reply code assignments probably slipped through the cracks. Anyway, here's the lineup!

172 <A Citation Component>

Sent in response to the EXIT command, which wraps up the Citation Retrieval function. 📚

173 End of citation.

This one shows up after a list of 172 replies. Think of it as the "that's all, folks" 🎬

200 OK.

The classic, standard, positive acknowledgment used all over the Protocol. Honestly the MVP ✨

270 <pathname> -- is assigned as the pathname.

Sent in response to the EXIT command, which ends the Record function. 🗂️

271 <functionlist> -- supported.

Sent in response to the MAIL command, which is how the user process gets into the Mail subsystem. This one is mandatory and seriously important, because it's how the user process figures out which functions the server supports. Main character energy 👑

272 Requestor is who he says he is.

Sent in response to an ID command in the User Verification function. It tells the user process that the Id given really is the Individual's. Verified bestie 🫶

330 OK. Now Id, please.

Sent in response to the first command in each pair of commands in an Individual List. This reply means the next command from the user process has to be ID 🧚

332 Login first, please.

Sent in response to any command that invokes a Mail function (like RECORD, DISTRIBUTE, DELIVER), or to the MAIL command itself. It basically says "yes, I support that, but you need to log in before using it" 🔐

400 Function not implemented.

Sent in response to any command that invokes a Mail function (like RECORD, DISTRIBUTE, DELIVER), or to the MAIL command itself. This one means the server does NOT support the requested function. Oof 💀

431 Incorrect Id.

Sent in response to the ID command in an Individual List command pair. It means the Id specified was wrong 🙅‍♀️

440 <Error relayed from Recording Agent>

Sent in response to the LOCATION command. This means the server tried to grab the specified piece of Mail from an FTP server, but it failed because the FTP server sent back the error reply whose text is copied into the current reply. Relay drama 📬

470 No such pathname.

Sent in response to the PATHNAME command (inside the Citation Retrieval function). It means the server doesn't recognize that pathname 🗺️

471 No unRead Mail to Forward.

Sent in response to the EXIT command, which ends the Forwarding Function. Nothing unread to forward, bestie, so it's giving empty inbox 📭

472 Requestor is NOT who he says he is.

Sent in response to an ID command in the User Verification function. It tells the user process that the Id given is NOT the Individual's. Not it 🚫

473 You don't have Read Access to the Mail.

Sent in response to the LOCATION command, or to the PATHNAME command in a Citation Retrieval function. It means the Requestor doesn't have Read Access to that piece of Mail. Locked out 🔒

474 Recipient unrecognized; is General Delivery OK?

Sent in response to an instance of the RECIPIENT command in a Distribution List (in the Delivery function). This one says the Recipient isn't recognized, but the server will try General Delivery to them if the user process replies with a GENERALDELIVERY command. If not, the Recipient gets rejected. Second chances 🎀

475 That Individual is not at this host.

570 No such NIC Ident or Mailbox Name.

Sent in response to any command where a NIC Ident or Mailbox Name shows up as an argument. It means the Individual doesn't exist 👻

571 Invalid host.

Sent in response to any command where a host address or standard host name shows up as an argument. It means no such host exists 🌐

572 No such catalog.

Sent in response to the CATALOG command. It means that Catalog doesn't exist 📖

Any '500' reply.

Any of the error replies tied to FTP RETR/STOR commands count here too 💅

FORMAL SYNTAX 🧁

Okay, so the terse keyword forms you'd actually use when building a Mail user or server process are made by deleting characters from the verbose forms. Those deleted characters are still included, just wrapped in brackets, all through the description below. You can use spaces pretty freely between the terminal elements of the syntax, but in some cases at least one space has to separate two elements, otherwise you couldn't tell where one ends and the next begins ✨

<CA2>            ::= TELNET Go Ahead character
<CA>             ::= TELNET new line (CR LF)
<CRLF>           ::= CR LF
<accesstypes>    ::= <readaccess> <controlaccess>
<ackcondition>   ::= A[LWAYS] | F[AILURE] | N[EVER]
<acktype>        ::= T[ERSE] | V[ERBOSE]
<action>         ::= A[CTION] | null
<catalog>        ::= <string>
<citationcomp>   ::= D[ISTRIBUTION]L[IST] | A[CESS]L[IST] |
                     C[ATALOG]L[IST] | C[ON]T[ENT] |  T[ITLE] |
                     C[OM]M[ENTS] | AU[THOR] | CL[ERK] |
                     C[REATION]D[ATE]
<citationtemp>   ::= <citationcomp> | <citationcomp>
                     <citationtemp>
<command>        ::= <shortbody> <CA> | <longbody> <CA2>
<comments>       ::= <string>
<controlaccess>  ::= C[ONTROLLING] | null
<count>          ::= decimal integer
<date>           ::= <dayofmonth> / <month> / <year>
<datetime>       ::= <date> <time>
<dayofmonth>     ::= decimal integer, 1-31
<days>           ::= <count> D[AYS]
<deliverystatus> ::= F[AILED] | S[UCCESSFUL] | T[IMED OUT] |

                     W[AITING] | U[NATTEMPTED]
<deliverytype>   ::= F[ORWARD] | M[AIL] | N[EGATIVE
                     ACKNOWLEDGMENT] | P[OSITIVE
                     ACKNOWLEDGMENT] | P[ROGRESS]R[EPORT]
                     | R[EPLY]
<disposition>    ::= <rsvp> <action> <interrupt>
<fileaddr>       ::= <host> <pathname>
<functionlist>   ::= <functiontype> | <functiontype>
                     <functionlist>
<functiontype>   ::= RE[CORDING] | DE[LIVERY] | DI[STRIBUTION] |
                     F[OR]W[ARDING] | CI[TATION RETEiEVAL] |
                     UP[DATE] | U[SER]V[ERIFICATION]
<globalname>     ::= * <nicident>
<greeting>       ::= <string>
<host>           ::= <hostname> | <hostaddress>
<hostaddress>    ::= decimal integer, 0-255
<hostname>       ::= standard host name
<hour>           ::= decimal integer, 0-23
<hours>          ::= <count> H[OURS]
<individual>     ::= <localname> | <globalname>
<interrupt>      ::= I[NTERRUPT] | null
<interval>       ::= <days> | <hours> | <days> <hours>
<localname>      ::= <mailbox> @ <host> | <mailbox> @
   NOTE: Host defaults to that of the server
<longbody>       ::= COM[MENTS] <comments> |
                     TEXT <string>
<mailbox>        ::= <string>
<minute>         ::= decimal integer, 0-59
<month>          ::= decimal integer, 1-12
<nicident>       ::= <string>
<id>             ::= <string>
<pathname>       ::= <string>
<readaccess>     ::= R[EAD] | null
<rsvp>           ::= R[SVP] | null
<serialnumber>   ::= <string>
<shortbody>      ::= ABOR[T] |
                     ACC[ESS] <individual> |
                     ACKC[ONDITION] <ackcondition> |
                     ACKT[YPE] <acktype> |
                     AC[CESS]TY[PES] <accesstypes> |
                     AUTH[OR] <individual> |
                     CAT[ALOG] <catalog> |
                     CLER[K] <individual> |
                     CR[EATION]DA[TE] <datetime> |
                     CUT[OFF] <interval> |
                     C[ITATION]TEM[PLATE] <citationtemp> |
                     DELI[VER] |
                     DE[LIVERY]TY[PE] <delivverytype> |
                     DISP[OSITION] <disposition> |
                     DIST[RIBUTE] |
                     EXIT |
                     FILE |
                     FOR[WARDE]E <individual> |
                     FOR[WARD] |
                     GEN[ERAL]D[ELIVERY] |
                     GREE[TING] <greeting> |
                     ID <ID> |
                     LOC[ATION] <fileaddr> |
                     MAIL |
                     MON[ITOR] <individual> |
                     PATH[NAME] <pathname> |
                     RECI[PIENT] <individual> |
                     REC[ORD] |
                     REQ[UESTO]R <individual> |
                     R[EFERENCE]SER[IAL] <serialnumber> |
                     R[EPORT]INT[ERVAL] <interval> |
                     SERI[AL] <serialnumber> |
                     SIGN[ATURE] <signature> |
                     TITL[E] <title> |
                     UPDA[TE] |
                     UP[DATE]TY[PE] <updatetype> |
                     VER[IFY]
<signature>      ::= <string>
<string>         ::= any non-zero number of visible characters
                     (in particular, CA and CA2 are excluded)
<time>           ::= <hour> : <minute> <timezone>
<timezone>       ::= EST | EDT | CST | CDT | MST | MDT | PST |
                     PDT | GMT
<title>          ::= <string>
<updatetype>     ::= A[DD] | R[EPLACE] | D[ELETE]
<year>           ::= full year in decimal (e.g., 1973)

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Root 2/98 ]

📦 where this page comes from