RFC 475

FTP AND NETWORK MAIL SYSTEM ✨

okay bestie, this is RFC 475 🎀 It's from the Network Working Group, the author is A. Bhushan at MIT-DMCG, the NIC number is 14919, and it's dated March 6, 1973. The header doesn't have category, obsoletes, or updates fields, so there's nothing to report there 💅

This paper is A. Bhushan's take on the results of the Network Mail System meeting at SRI-ARC on February 23, 1973, and what it means for FTP (File Transfer Protocol). Everyone at the meeting basically agreed that network mail should live inside FTP 🫶

FTP already has two commands for mail, and they're giving very different energy 🔥 The MAIL command sends mail over the TELNET connection, and the server collects the mail and figures out where it ends by searching for the character sequence "CRLF.CRLF". The MLFL (mail file) command sends mail over the data connection. It needs a user-FTP to handle it, but it's more efficient because the server doesn't have to hunt for that special sequence 🧚 Both commands are already being used for network mailing. Lots of sites have updated their local mail and SNDMSG programs to support it, like USER@HOST at BBN_TENEX and MAIL host user at MIT-DMCG 🌈

The network mail system should give users a convenient way to send messages to other network users who have "mailboxes" at one or more hosts. Delivery doesn't have to be real-time, so no pressure 🦋 It isn't an interactive inter-console communication facility. Some sites might be able to deliver "urgent" mail in real-time, like printing it at the user's console if they're logged in right now. It also isn't a general inter-process communication facility, though messages might be deliverable to programs that have mailbox addresses. Inter-process and inter-entity communication are very desirable, but they're out of scope for the network mail system 🙈

Mailboxes and mailbox addresses are the main characters of this whole discussion 👑 A mailbox is where mail gets stored before a user picks it up. It could be a file in the user's directory or a bin for hard copy. The mailbox address is what the sender needs in order to send mail to the destination mailbox. For users with an "on-line" network mailbox, the mailbox address has the Host address plus the user's mailbox identification at that Host. The mailbox identification is whatever an FTP-server needs in order to put the mail in the right mailbox. In this document, "mailbox address" refers to the on-line network mailbox address.

NETWORK MAIL SYSTEM FUNCTIONS 💖

The network mail system should provide the following six functions:

1. CREATING: This is how the user creates or composes their message. FTP servers don't explicitly provide any message editing capability, although the server's editing conventions might apply to the MAIL command. Editing conventions for things like character delete and line cancel vary a lot across the network. Users know their local Host conventions best, so those should be used for network mail editing 📝 Users also have access to local editing systems that can be used to compose message files. The message file can then be sent with the MAIL or MLFL commands, with MLFL being preferable 💅 The current FTP approach, where creating messages is the sender's responsibility, seems adequate. TIP users who want editing facilities should use intermediate Hosts for creating and sending messages.
2. LOCATING: This is how the sender finds the receiver's address. FTP assumes the sender already knows the receiver's correct address 🤔 There's no published or "on-line" list of mailbox addresses. There is, however, a list of network participants that the Network Information Center (NIC) at SRI-ARC maintains on-line and publishes. Network users have each been assigned a unique "NIC Ident" and Host site by the NIC. So FTP specified that FTP-servers maintain a table that maps NIC Idents to mailbox identifications. The NIC will maintain on-line and publish the local mailbox address information for network participants. Users could look up a published list, or query the NIC on-line to locate destination addresses. The NIC will also provide an on-line facility (similar to FTP) that programs can use to retrieve address information. This approach, where the NIC maintains the addresses, has several advantages 🌸 Users can get a bunch of addresses for a group and use them to transmit mail. FTP servers don't need to maintain NIC Ident Tables. And the NIC can provide a great facility for locating addresses from last names, NIC Idents, or even sketchy information 🫠 It may still be desirable for FTP servers to accept NIC idents, last names, and other standard forms as mailbox identifiers.
3. SENDING: This is how the message gets sent to the destination mailbox. Messages can go directly to the destination mailbox (over TELNET or data connections) or through an intermediate Host such as the NIC 🚀 FTP doesn't explicitly provide for mail forwarding by intermediate Hosts, but FTP servers may be able to recognize addresses that aren't local and forward the mail. If mail does get forwarded, a desirable facility is for the intermediate site to send an acknowledgement (on request) when the mail is delivered, or if delivery fails within a specified time. The current FTP specifications recommend that FTP-servers accept multiple addresses, but they don't require it.
4. STORING: This is where mail is stored before it's read, and whether the information is kept for later reference or retrieval 🗃️ FTP doesn't require the sender to store mail or keep duplicate copies. It's the receiver's job to store the information for reading, reference, or retrieval. The receiver doesn't even need to store the mail as a data file, since they can print it straight to a user console or line printer 🖨️ FTP doesn't specify storage procedures for intermediate sites. An intermediate site might be used for forwarding, and the mail stays there until it's delivered to its final destination. If the mail is undeliverable, the intermediate site should return the undelivered information to the sender. A similar situation happens when the sending site defers sending mail, for example because the destination host is down. In that case the sending site acts as an intermediate forwarder as far as the user is concerned 💫
5. RECORDING: This is about whether mail should be catalogued and recorded for later reference and retrieval 📚 FTP doesn't currently have an explicit mechanism for the receiver to record mail. If an intermediate site (like the NIC) is used for mail distribution, recording mail could be one of its functions, if requested. The NIC is ideal for recording mail, but other sites may want to record it too. If mail is recorded, the entire contents don't have to be sent. Instead, only a citation for the document gets sent, and the receiver can retrieve the mail only if they want it 🫶 This is especially useful for large documents, like the NWG/RFC series, which get distributed to a group. The citation may contain the author, title, retrieval pathname, and perhaps an abstract.
6. READING: This is how the mail is finally presented to the user and read. FTP currently assumes that reading mail is entirely the receiving site's job 👀 There are still ways the sender can help the receiver get better mail reading facilities. For example, if the receiving system knows a message is urgent, it can deliver it right away at a user console. Long messages may be put in separate files, with a notification in the user's regular mail. Or, the mail could be a citation that the reading program retrieves when the user asks for it. Selective handling of different classes of mail is important for an improved network mail system ✨

MODELS FOR MAIL SYSTEM USE 🦋

A mail system user can use an intermediate site to locate addresses, to record and/or distribute mail, and to create and read mail. So we have the following models for mail system use:

1. The user connects directly to the destination FTP server and sends mail using the MAIL command 📮 Local editing functions are limited to character delete and line cancel (assuming the user is in line-at-a-time mode), and server conventions may also apply. The user only needs a user-TELNET program at their site, but they need to know the destination address. This model is especially applicable to TIP and other mini-Host users who don't have a user-FTP or user-Mail programs 🍓
2. The user composes the mail with a local editor (or mail system) and then asks their user-FTP or mail program to send it directly to the destination using the FTP MAIL or MLFL commands 💌 The user needs to know the destination address. The sending program can defer the mail if the destination Host is down. TIP users can use this model through the facilities of a "home-base" Host 🏠
3. The user uses an intermediate site, such as the NIC (other sites may provide forwarding services too), for mail distribution 🌐 The user doesn't need to know destination addresses, and can use NIC idents for individuals and groups of individuals. The mail can be recorded on request, and its sending can be deferred, since the destination Host may be down or it may be more economical to defer mail 💸 The message can be created at the local site using local editing facilities, or it can be created directly at the intermediate site.
4. The user may send a citation of the mail instead of the complete mail item 🔖 The citation refers to an existing document that can be retrieved on-line, like the NIC number of a NIC journal communication.

---

Okay so someone suggested the FTP spec should say receiving mail should be "free" 💌, meaning FTP servers shouldn't make you "login" (send the USER, PASS, and ACCT commands) just to get mail. Without the access control commands, the server should charge the cost of receiving mail to an overhead or browsing account 🧾. Heads up though: this "free" mail function using the default USER account might not allow non mail-related commands without reinitializing 🙈. Honestly, this requirement would make communication between network users so much better 🫶✨.

Some systems, like Multics, have access control for receiving mail 🔐. A user can say who is allowed to send them mail. Normally people give access "...*.", which means literally anyone can send mail 📬. The access control commands would be required to gain privileged access. Using USER doesn't seem like the best way to identify who's sending mail 🤔. Think about users logged in as GUEST, ICCC, NETWORK, MIT-DMCG, and NETWORK-USER. A separate FROM command seems way more iconic 👑. It can identify the sender, and it can also be used to send acknowledgments and replies. The receiving site can tag the mail like this: FROM AKB at MIT-DMCG, logged in as GUEST. Then the receiver can send a reply to the mailbox address AKB at Host 70 (SNDMSG AKB@DMCG or MAIL DMCG AKB) 💜.

---

NETWORK INFORMATION CENTER FUNCTIONS 🗂️

The NIC is a super special facility for handling mail 💅. It provides facilities for recording and distributing mail to individuals and groups of individuals, and for locating users' addresses. It will also undertake to distribute unrecorded mail 📮. Right now the NIC requires users to log into the NIC and use NLS to create and distribute mail. Using NLS for creating mail has been a frustrating experience for many people who are used to different editing systems 😭. Recently the NIC has been overloaded at most times of the day, and even if you get a "network terminal" and log in, the interaction is quite slow 🐢. NIC (or NLS) is designed for character-at-a-time interaction with remote echo, so the use is inefficient 💀. Using NIC is especially unbearable when you fall behind in your echo by as much as an entire line 🙃.

An alternative to direct use of NIC is to use it via FTP and programs at the user's site 🧚. Users can create journal documents with their own local editing system and then transfer them to NIC via FTP. The user may have to specify information like author, title, where the acknowledgment should be sent, and journal number if the item is to be recorded 📝. It should also be possible for users to send sequential files to NIC and have them restructured into NLS form without doing an "input sequential" (a suggestion is to "NLS" the file if its name is suffixed with .NLS) ✨. Alternatively, it should be possible for users to retrieve journal documents and other sequential files without doing a previous "output sequential" 🌸.

The NIC currently delivers mail via hardcopy and/or on-line 🖨️. On-line currently means the user has to log into NIC to see if they have a message and read it with "print branch" 😤. The messages aren't seen by destination users for several days, and many users get their hard copy before they've had a chance to check their on-line NIC mail 😭. If the NIC were to deliver mail via FTP to network users, the mail turnaround time would be greatly sped up, and users wouldn't have to log into the NIC 🏃‍♀️. Large documents don't need to be mailed in their entirety. Only a citation needs to be sent 📚. The NIC will have to collect information on the mailbox addresses of Network participants for delivering mail, especially since it appears that many FTP servers are not "respecting" NIC idents 🙈. It is recognized that a user may have only one (the most used) of these addresses 💖.

The NIC identification subsystem (currently accessible via NLS only) contains information on users (such as affiliation, US Mail address, telephone numbers, etc.) and groups (members, etc.) 📇. The on-line mailbox address information can be added here. The NIC will undertake to provide a facility whereby the identification subsystem can be queried by programs, allowing mailing programs to retrieve the addresses automatically 🤖. This facility will be separate from FTP 🦋.

---

FTP MODIFICATIONS 💅

The FTP currently does not provide explicit facilities for recording mail, communicating sender's address, sending program readable citations, specifying author and title for documents, requesting acknowledgments, and indicating message type (urgent, ordinary, and long) 😤. To overcome these deficiencies, we can take any of the following approaches:

1. Kludge the desired features in the pathname syntax of the MAIL and MLFL commands, justifying the kludge on the grounds that most of the functions are to be used only by the NIC.
2. Add new commands for the desired functions and alter the MAIL and MLFL commands somewhat to recognize the existence of the new commands.
3. Define a new mail command which incorporates the missing functions (in the process defining new commands for the desired functions). The MAIL and MLFL commands can be used in their present form but may be gradually phased out.

The first approach seems undesirable to me, as many of the missing functions can be used by other sites as well 🙅‍♀️. Plus it'll be easier to write programs that deal with commands rather than a complex syntax 🧠. The second and third approaches aren't very different from each other. The third approach seems preferable because it will allow existing mail programs to function in their present form 🫶. Using the third approach, consider the following new FTP commands:

1. MLTO (mail to): The argument is one or more mailbox identifiers separated by "," (commas). It is suggested that if there is no argument, the mail should be sent to some responsible user or printed on a printer. This command starts the sequence of optional FTP mail related commands described below. The sequence ends with the TEXT, FILE, or CITA (citation) commands. 📬
2. FROM: The argument is the address of the sender or senders. It is in a standard form that can be interpreted by programs as well as human users. The information is to be used for identifying the sender(s), for sending replies, and for sending acknowledgments if the receiver is an intermediate forwarding site. 🫂
3. MTYP (mail type): This identifies the type of mail as U (urgent), O (ordinary), and L (long). The receiving system can take the appropriate actions from this knowledge. The default assumption is ordinary mail. 🏷️
4. RECO (record the mail): The argument, if present, is the identifying information for recording (such as NIC Journal number). If no argument is present, the server will assign the recording information and send an appropriate reply (real-time or deferred). 📝
5. AUTH (author): Identifies the author of the document in a form acceptable to the server (NIC ident may be required by NIC). ✍️
6. TITL (title): Identifies the title of the document. The argument is an ASCII string ending with the sequence CRLF.CRLF. 🎀
7. ACKN (acknowledge): Relevant for intermediate forwarding sites. Asks the server to send acknowledgment on delivery or if delivery fails within a specified time. 🔔
8. TEXT: No arguments. Starts the transfer of mail over TELNET connection in an identical manner as MAIL. 💬
9. FILE: No arguments. Starts transfer of mail over the data connection in an identical manner as MLFL. 🗃️
10. CITA (citation): Argument is the pathname of retrievable file. 🦋

We also need to define new reply codes for handling mail 🌈. Some sites have expressed the need for replies such as "send only X bytes of mail". Other replies could specifically request additional commands such as USER/PASS/ACCT for privileged mailing, FROM/ACKN for mail forwarding, and AUTH/TITL for recorded mail. Another suggestion that may be given consideration is allowing TYPE/BYTE other than A/8 for the FILE command. Mailing large files between like machines such as PDP-10s is more efficient in I/36 ⚡. The RDML and RDMF commands proposed by Bressler and Thomas (NWG/RFC 458) also merit consideration, as they would aid the handling of mail for users who have mailboxes at different Hosts 👑.

     [This RFC was put into machine readable form for entry]
  [into the online RFC archives by Kelly Tardif, Viagenie 10/99]