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 <
[email protected]>
Subject: mailsystem release: MAJOR functionality enhancement
To:
[email protected]
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:<MM>
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:<MAIL.MUMBLE>, the local host name on the Special network is
MUMBLE (or MUMBLE.#Special). If PS:<MAIL.MUMBLE.FOO> and
PS:<MAIL.MUMBLE.BAR> 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:<MAIL.MUMBLE.FOO> 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:<MAIL.MUMBLE>, 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 --
-------
