Special Network Handling in the TOPS-20 Mailsystem Mark Crispin Centre Mondial Informatique et Ressource Humaine 19 July 1984 LAST UPDATED: Mark Crispin, PANDA PROGRAMMING, 19 March 1985 INTRODUCTION The Special Network is a new concept in the TOPS-20 mailsystem to satisfy a long-recognized but poorly-understood need: to be able to compose, send, and receive mail to a "generic network" or rather a generic set of hosts. Many sites have "networks" which consist of little more than a TTY link to some other place; others have various one-of-a-kind communication links. It is highly impractical to implement support in the mailsystem for every conceivable "network" of this type. Additionally, the technology for adding support for a network to the mailsystem, while well-defined, is rather complicated and its mysteries are seemingly impenetrable to even a sophisticated system programmer who has never done it before. A name/address translation parser must be added to the HSTNAM module, following certain specific (and ill-documented) rules; a network driver must be added to MMailr, and virtually the entire mailsystem must be rebuilt to ensure that all modules utilize the up to date version of HSTNAM. It was concluded that some form of generic network support was needed which would interact with some external agent to deliver and receive mail. The idea of some sort of configuration/command file was considered and rejected. This sort of implementation would have the tendency to lead to a "host table"; a concept which is completely at odds with the modern mailsystem's philosophy of consulting external intelligent agents (a.k.a. "name servers") for all name/address lookups. Only in DOMAINS.TXT does any "host table" concept (regrettably) remain. Additionally, there remained the problem of what to do with the case of having multiple sites with different translation means. Consequently, it was decided to have a separate disk directory for queue files to the external mail delivery agents on a per-destination site basis. The advantages of this scheme become obvious when one considers the various security implications. Previously, a mail delivery agent had to run privileged, even when delivering mail to the network. Now, it only needs access to the single directory corresponding to the remote site it is delivering mail to. To emphasize that these external agent queue files are not MMailr format queue files, the format is similar but NOT identical to MMailr format (see below) and is incompatible (albeit not by much) from MMailr format. Before writing these files, MMailr performs any transmogrification as necessary. Of course, an agent going to a non-RFC 822 "network" (e.g. UUCP) may wish to modify the headers itself to suit the needs of the remote host. SPECIFICATIONS A new relative domain, .#Special, is now in the mailsystem. It identifies a "generic" network and not any particular transport means known by the mailsystem. In order for a site to utilize this functionality, the system-wide logical name MAILS: must be defined to point to the generic network root-directory. This directory has, as its subdirectories, the names of all the valid Special hosts known to the local site. In addition, the lowest level name in the directory tree for MAILS: must be set up as the local site's "host name" on the Special network. To make this clear, consider the following example. A system called CMIRH wishes to set up a Special network which consists of itself (always) and three other systems, named CMU, RUTGERS, and SUMEX-AIM. [NOTE: this is not to imply that such a Special network exists -- I am merely describing the environment used in debugging.] CMIRH wishes to have the Special network mail go to subdirectories of their MAILQ: directory, which has the (canonical) name of PS:. To do this, the following line is added to CMIRH's SYSTEM:n-CONFIG.CMD: DEFINE MAILS: PS: Subsequently, three subdirectories: PS: PS: PS: are created. Similar albeit not identical actions have to be taken at the other sites to accomplish full, two way communications. It is important to note that the "CMIRH" directory at SUMEX-AIM would be PS:. Mail sent to a "Special" host goes to the appropriate directory in the following format: ("user@host" format) ("user" only, NOT "user@host") . . . ... message in RFC 822 format ... The sender and at least one recipient must be given. Each message is contained in its own file, all of which have a filename of "-MAIL" and an extension which should be considered random. The delivery of the messages is accomplished by an external process which periodically checks the relevant directory, and transmits the recipient list and text of the message in some mutually-agreed upon format to the destination. Receipt of messages from a Special host is accomplished by some mail composition agent (typically the other end of the delivery process) which writes a standard MMailr-format queued mail file on MAILQ: and follows the normal procedure for waking up MMailr. In other words, there is little or no difference between a Special network receiver and a "standard" network receiver such as MAISER. OTHER INFORMATION The changes to the mailsystem to support the Special network are in HSTNAM and MMailr. These are now part of the standard, officially supported version of the mailsystem. A sample external network driving program for a "TTY network" is Cafard, described in CAFARD.DOC. The work described herein was performed under contract to the World Centre, Paris, France and is in the public domain by agreement with the World Centre with the exception of the Cafard program which is distributed by PANDA PROGRAMMING.