15-Jul-84 10:47:19-PDT,3723;000000000001 Mail-From: MRC created at 15-Jul-84 10:47:11 Date: Sun 15 Jul 84 10:47:11-PDT From: Mark Crispin Subject: mailsystem release: MAJOR functionality enhancement To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This is to announce a major functionality improvement to the TOPS-20 mailsystem (available, as usual, from [SU-SCORE]MRC: via ANONYMOUS FTP): the addition of the "Special" network. By defining systemwide logical name MAILS:, a site may define a set of hosts which are delivered to externally from the mailsystem by creating a directory for the desired host as a subdirectory of MAILS:. The lowest level node of MAILS: defines the local host name on the "Special" network. For example, if MAILS: has been ^EDEFINE'd as being PS:, the local host name on the Special network is MUMBLE (or MUMBLE.#Special). If PS: and PS: exist, you can mail to hosts FOO and BAR. The reason for separate directories is to allow for different means of delivery. For example, you can give the mail delivery program for host FOO user group access to PS: without giving that same program access to any other mail. This is useful in "TTY network" type applications when host FOO would dial you up and pick up its mail. Files queued to the Special network are to the appropriate directory (obviously, mail to the local host is handled directly by MMailr -- not to PS:, etc.). The file name is of the form MAIL.*. The format is DIFFERENT from MMailr queued files - by design: these are not MMailr files. The format is a list of destinations delimited by CRLF, and finally a line with only a form-feed in it. A well-written program should be prepared to discard any line which starts with a form-feed and has other stuff in the line, to allow for future expansion of this format. It should be emphasized that MMailr does not deliver any mail to the Special network. It merely drops messages into a directory for some external process to pick up and deliver. Also, there is no provision for receiving mail from the Special network; it is the responsibility of the external process to build and queue properly formatted MMailr queue files to MAILQ:. Finally, to guarantee that the REPLY command in MM works it is advisable that all the hosts in a "Special cluster" create the subdirectories for all the other hosts (in otherwords, the subdirectories under MAILS: comprise the "host table" for the local Special network). MMailr will take care of any necessary transmogrification in RFC 822 format using the conventions instructed in DOMAINS.TXT. This means that the rubouts around the host name are NOT present in the files written by MMailr in the Special network directory. This frees the external application to do any non-RFC 822 transmogrification which may be necessary (e.g. for UUCP, see below). This can even be used in a more general fashion to support UUCP or MMDF. This is one by defining, say, UUCP as a Special network HOST, instead of the individual sites on UUCP (an impossible task). One could then use the DOMAINS.TXT functionality combined with transmogrification in the UUCP handler to deliver UUCP mail. For example, one might do "foo!bar"@UUCP or if bar is in DOMAINS.TXT foo@bar. Some work is being done in the area of supporting UUCP. The changed modulre HSTNAM and MMailr; of course, since everything uses HSTNAM you'll need to rebuild the entire mailsystem. -- Mark -- -------