RFC 915

NETWORK MAIL PATH SERVICE 💌

okay bestie, this is RFC 915 🎀 written by Marc A. Elvy of Harvard University and Rudy Nedved of Carnegie-Mellon University, dated December 1984. The header doesn't name a category and doesn't list anything it obsoletes or updates. The Status section says it's a proposal for a new service on the ARPA-Internet that wants discussion and suggestions for improvements, and distribution is unlimited 🦋

STATUS OF THIS MEMO ✨

okay so the whole point of this memo is to propose a brand new service for the ARPA-Internet community. The authors are literally asking everyone to talk about it and send ideas for making it better 💅 It's giving "open collab, come slide into the replies" energy 🫶

INTRODUCTION 🌸

the network mail path service is the answer to a very real problem: people need to figure out mailbox addresses for hosts that aren't on the ARPA-Internet. Those hosts can still be reached through one or more relay hosts that run UUCP (Unix To Unix Copy) mail, CSNET mail, MAILNET mail, BITNET mail, and so on 📬

anyone can use it as long as they can reach one of the hosts running a mail path server over TCP/TELNET. Easy access, no drama 💖

DISCUSSION 💜

so right now a bunch of hosts that aren't connected to the ARPA-Internet can still send mail to the ARPA-Internet crowd, and vice versa 🌈 The ARPA-Internet normally uses mailbox addresses shaped like user@host or local-part@domain [1, 5].

to get around the fact that non-ARPA hosts aren't directly connected, mail maintainers started using the local-part of the address as a sneaky little container for special routing or relay info. Those encoded addresses came in lots of different shapes and totally became common practice. Some examples:

demco%ucb-ean.cdn%ubc.csnet@CSNET-RELAY.ARPA

"Rudy.Nedved%CMCCTE@CARNEGIE.MAILNET"@MIT-MULTICS.ARPA

ihnp4!cmucsg!ern@UT-SALLY.ARPA

mss.dartmouth@CSNET-RELAY.ARPA

nedved%CMCCTF.BITNET@WISCVM.ARPA

ngl the confusion and frustration were rampant 💀 people really need to be able to talk to each other, so something had to make addressing mail to non-ARPA-Internet hosts easier. The big fix in the works is the Domain Name system and its related facilities [2, 3, 7, 9]. The goal there is for mailbox addresses to be as simple as the current ARPA-Internet format, like user@domain 🧚

but here's the question: how do people find those weird encoded addresses until the domain name system is working and covering most of the hosts in the mail world? 🙈 The proposal is a network service for the ARPA-Internet plus a mail service for the non-ARPA-Internet hosts. You give it a host, plus an optional addressing system, communication protocol, or other info, and it gives you back the mailbox address format for sending mail to that host. For example, nedved@Carnegie.MAILNET would be translated by the server into nedved%Carnegie.MAILNET@MIT-MULTICS.ARPA. This memo only covers the network service part 🍓

DOCUMENT CONVENTIONS 🎀

unless otherwise noted, all numbers are decimal. Also, "host" means one computer system that might have more than one name attached to it. It can have a name for each network or mail connection it supports, and possibly a few nicknames or aliases for the computer itself and for each set of network names it has picked up 💅

OVERVIEW 🦋

the network service is a connection-based application running on TCP [4]. A server listens for TCP connections on the assigned port 117 [8]. When you connect, it replies with a coded greeting and then waits for a command line. Every command line you send gets a coded response back. The special command QUIT makes the server send a coded closing message and then close the connection 👋

DESIGN GOALS 🌟

one of the big goals is to serve as many ARPA-Internet hosts as possible 👑 experience has shown that software people usually implement TELNET/TCP [6] before any other network application or protocol. So it's a sub-goal that people can access the service with programs that already implement TELNET/TCP, with minimal changes. That's why TELNET/TCP on port 117 will just work correctly ✨

the server understands TELNET options, but it refuses every option negotiation that disagrees with the NVT characteristics defined by the TELNET protocol (see [6]). It does not echo, and it expects command lines to end with <CRLF> (ASCII code 13 (octal 15) followed by code 10 (octal 12)). Character echoing and line editing are expected to be handled by the user's host, for the user's benefit 🫶

mail systems and other programs should also be able to access and understand the service. Each command reply can have multiple lines of text that a novice user can understand. Each command is also encoded so a program can easily parse the lines and pull out useful info, like whether the operation succeeded 🔥

THE PROTOCOL 🧚

the protocol is still developing, so the command lines are a command (case ignored), then white space, then the argument(s), then a <CRLF>. White space is required if any arguments are supplied, but the arguments themselves are optional. White space after the command and after any optional arguments gets ignored 💖

<cmdline> := <cmd> [<WS> <args>] [<WS>] <CRLF>

<WS> := [<WS>] <WS> | <TAB> | <SPACE>

coded response lines follow a rigid format: a 3-digit decimal code, then either a space or a dash, then text made of ASCII characters from 32 to 126 (octal 40 to 176), ending with <CRLF>. The dash after the code means at least one more response line is coming, and the space means the current line is the last one 🌈

<rspline> := <digit><digit><digit><cont><rtext><CRLF>

<cont> := <SPACE> | "-"
<rtext> := ASCII characters in the range 32 to 126.

some successful responses to certain commands have rigid formats so programs can pull out path info. The commands with format restrictions are clearly noted, and the response format gets documented right alongside the command 🍓

the response codes are in the range 200 to 599 inclusive. The first, most significant digit is the success indicator. It covers simple success and total failure, but also temporary failure and the need for more information, which has worked really well for SMTP [5] and other similar protocols 💜

2xx  Positive reply.

3xx  Intermedate reply. Positive acknowlegement but more
     information is neccessary.

4xx  Temporary error. Try again later.

5xx  Permanent error. Do not retry.

the second digit classifies the response to give a flavor of certain kinds of success. The flavor shows up in whether a host name is known by a domain name server or not 👑

x0x  Command related response.

x1x  Connection related response.

x2x  Database related response.

x3x  Domain transition related response.

x4x  Data added response.

x5x  Data deleted response.

x6x  Data modified response.

BASIC IMPLEMENTATION 🎀

the minimum implementation supports three commands: HELP, PATH, and QUIT 💅

• HELP gives some level of documentation and might list the known addressing or communication protocols.
• PATH takes a required argument: a user name or id, then an @, then a domain-style host name. That domain can be an addressing protocol, a communication environment, or an unofficial or colloquial domain.
• QUIT ends the session.

here's a sample session 🦋

S: (server listens on port 117)
U: (user connects to port 117)
S: 210-Welcome to the CMU network mail path service.
S: 210 Type 'HELP' for help.
U: help
S: 200-The server currently knows about the following mail worlds:
S: 200-    BITNET,UUCP,CSNET,.AC.UK,EARNET,JANET,CDNNET
S: 200-Use the PATH command with "user@host.world" to get the
S: 200 ARPA-Internet mail address.
U: path root@inria.uucp
S: 220 philabs!mcvax!inria!root@SEISMO.ARPA
U: quit
S: 211 Bye bye.
S: (server closes connection)

and that's the first chunk 🌸 the detailed protocol description, the 412 timeout, and the rules for experimental commands are still coming up next ✨

PATH COMMAND ARGUMENTS ✨

Okay bestie, so the server is basically a helper for users who might only know a tiny bit about the host they want. 🧚 That's why the PATH command takes domain-style host names that can be complete or incomplete, and they can be the common or colloquial kind too. 💅 The server searches the entire database for anything that matches, picks the best answer, and ignores any local domain information. 🫶

If several hosts share the same nickname or alias and don't have distinguishing domain components, the server sends back an error response listing every host it found. 😭 Some implementations even split up the host name and say, in the error message, that they didn't find the host but found something else that might be what the user meant. Iconic behaviour, honestly. 🦋

---

MAIL PATH SERVICE AND DOMAINS 🌸

Okay so, as I said earlier, the mail path service is NOT meant to replace or compete with the domain name system. 🙅‍♀️ It's a stop-gap. Once most of the domain name system is in place, it will probably get turned off on some or most of the hosts running it. 💀

Mail systems should check the domain name servers for the specified host before they try a mail path server. 📬 Mail path servers should be modified, once one or more domain servers are in place, to check whether a host is part of the domain system. If it is, they should generate an error or an indication, but they still include the path information. 🎀

The names used by the mail path servers have no official standing in the ARPA-Internet community, and they have colloquial origins. 🍓 Domain name components are based on the administrative entities involved, but a lot of the unofficial, common domain-style names for non-ARPA-Internet hosts are based on the protocol used, the relay host used, or some acronym that someone dreamed up. 🙈 Only a few of the domain-style names that are privately in use are expected to be used by the ARPA-Internet community once the domain name service is in use by most of the community. 👑

---

CAVEATS 😬

The biggest problem with the new service, as it's implemented, is that it reports paths from the service host instead of from the user's host. 🥲 This is just the nature of software. It would be more convenient if it reported a correct path from the caller's host. That would need a different way of managing the database, though. The method would have to quickly compute the path from the caller's machine, or a machine would have to keep up-to-date databases for each host, which is impractical. 🙃

There are two minor problems with the database used by the software. 🔍 First, many relay hosts exist in several different protocol or addressing name spaces but under different names. The cross-referencing for these multi-protocol relay hosts is done by hand. Given how reliable these relay hosts seem to be, though, the problem doesn't appear to be significant. ✨ Second, the data should be collected from the actual relay hosts to make sure it's correct, but in many cases that's impossible. 💔

---

EXAMPLES 🎀

Okay, the examples are the fun part! 🥰

Find a route to CMU-CC-TE in the CARNEGIE part of MAILNET for user id EN0C 🗺️

   S: (server listens on port 117)
   U: (user connects to port 117)
   S: 210-Welcome to the CMU network mail path service
   S: 210 Type 'HELP' for help.
   U: path EN0C@CMU-CC-TE.CARNEGIE.MAILNET
   S: 220 EN0C%CMU-CC-TE%CARNEGIE.MAILNET@MIT-MULTICS.ARPA
   U: quit
   S: 211 Bye bye.
   S: (server closes connection)

Find a route to a host with an unknown addressing system or communication protocol, where the name might be an alias 🦋

   S: (server listens on port 117)
   U: (user connects to port 117)
   S: 210-Welcome to the CMU network mail path service
   S: 210 Type 'HELP' for help.
   U: path mss@dartvax
   S: 220 mss%dartmouth@CSNET-RELAY.ARPA
   U: quit
   S: 211 Bye bye.
   S: (server closes connection)

Find a route to a host known by a very long domain-style name that isn't in the current ARPA-Internet host tables 🧚

   S: (server listens on port 117)
   U: (user connects to port 117)
   S: 210-Welcome to the CMU network mail path service
   S: 210 Type 'HELP' for help.
   U: path rob@vax1.cent.lanc.ac.uk
   S: 220 rob%vax1.cent.lanc@UCL-CS.ARPA
   U: quit
   S: 211 Bye bye.
   S: (server closes connection)

Find a route to a host with no extra information, where the name turns out to be ambiguous 🙈

   S: (server listens on port 117)
   U: (user connects to port 117)
   S: 210-Welcome to the CMU network mail path service
   S: 210 Type 'HELP' for help.
   U: path brad@pitt
   S: 521-Several hosts found under the name of 'pitt', try one of:
   S: 521-brad@pitt.UUCP
   S: 521-brad@pitt.CSNET
   U: path brad@pitt.CSNET
   S: 220 brad%pitt@CSNET-RELAY.ARPA
   U: quit
   S: 211 Bye bye.
   S: (server closes connection)

---

ACKNOWLEDGEMENTS 🫶

The original protocol was documented by Marc Elvy, for a server that he and Alan Langerman built. 🛠️ The server used the pathalias software, which Steve Bellovin created and Peter Honeyman and Robert T. Morris modified, to maintain the host-to-host connection database. 🗄️ That software gave people a way to make sense of the jungle of UUCP hosts, and it's honestly so impressive. 👑

The Info-Nets@MIT-MC mailing list, created and maintained by Robert Krawitz, made the CMU and Harvard mail path projects aware of each other. The people on that list also provided many of the mail relay databases used by the mail path servers. 💜 The original server can be accessed through TCP port 117 on harvard.arpa. The "pathto" program, which runs under 4.2BSD UNIX, can be obtained as a front end to the server from RFC915@HARVARD.ARPA. 🌈

The current protocol scope was changed by Rudy Nedved to cover BITNET, CSNET, MAILNET and other "mail networks." Marc Elvy, Alan Langerman and others then refined it further. ✨

Comments should be sent to RFC-915@HARVARD.ARPA or mailed (via the U.S. Postal Service) to these people 💌

   Marc A. Elvy
   108 Aiken Computation Laboratory
   33 Oxford Street
   Harvard University
   Cambridge, MA 02138

   (617) 495-5849

   Rudy Nedved
   Department of Computer Science
   Carnegie-Mellon University
   Schenley Park
   Pittsburgh, PA 15213

   (412) 578-7685

---

REFERENCES 📚

[1] Crocker, D. "Standard for the Format of ARPA Internet Text Messages". RFC 822, Department of Electrical Engineering, University of Delaware, August, 1982.

[2] Mockapetris, P. "Domain Names - Concepts and Facilities". RFC 882, USC/Information Sciences Institute, Novemeber, 1983.

[3] Mockapetris, P. "Domain Names - Implementation Specification". RFC 883, USC/Information Sciences Institute, Novemeber, 1983.

[4] Postel, J. "Transmission Control Protocol- DARPA Internet Program Protocol Specification". RFC 793, USC/Information Sciences Institute, September, 1981.

[5] Postel, J. "Simple Mail Transfer Prootcol". RFC 821, USC/Information Sciences Institute, August, 1982.

[6] Postel, J., and J. Reynolds. "Telnet Protocol Specification". RFC 854, USC/Information Sciences Institute, May, 1983.

[7] Postel, J. "Domain Name System Implementation Schedule". RFC 897, USC/Information Sciences Institute, Feburary, 1984.

[8] Reynolds, J., and J. Postel. "Assigned Numbers". RFC 923, USC/Information Sciences Institute, October, 1984.

[9] Su, Z., and Postel, J. "The Domain Naming Convention for Internet User Applications". RFC 819, SRI International, August, 1982.