#-h- address.fmt     2014  asc  20-dec-82 13:19:46  sventek (joseph sventek)
.so ~bin/manhdr
.hd Address (files) 20-Oct-82
address file for mail system
.ds
`address' is the user address database for use with the mail system.
This file contains information on each valid user of the system.
Although many systems support the notion of an user authorization file,
the access to this file is typically limited to users possessing hoarded
privileges.
In addition, the format of the file will prevent user programs from being
written in a portable fashion.
By providing an utility (`addr') to convert the contents of the user
authorization file to a standard form in a file accessible to all, the
above discrepancies are alleviated.
.im
Each line of the file is formatted as blank separated tokens, with the
following positional meanings:

username    home-directory  system-info* "descriptive info"

where `username' is the user's login name, `home-directory' is the user's
home directory, `system-info*' is 0 or more columns of system
specific information, and "descriptive info" is auxiliary
information about the user.
Typically, all of this information is obtained by `addr' from the system
authorization file.
The only required information is contained in the first two columns;
it is absolutely necessary that the home-directory string represent an
absolute directory name for the mail system to work correctly.
This file should be kept in sorted order.
.ex
.fi
The following in an excerpt from the author's RSX system:
.sp
.nf
anonymous   lb00:[377,377]   [377,377]   "anonymous anonymous"
graves      lb00:[006,001]   [006,001]   "wayne graves"
sventek     lb00:[002,001]   [002,001]   "joseph sventek"
system      lb00:[001,001]   [001,001]   "the system"
.fi
.sp
A complete, absolute home directory spec for this system requires the
specification of a device and an UIC.
The third column is the UIC of the user, and is used by other primitive
functions.
The last column contains the first and last names of the user as given
when the account was created.
.sa
addr(sys)
.au
Joe Sventek
#-h- hnames.fmt      2384  asc  20-dec-82 13:19:49  sventek (joseph sventek)
.so ~bin/manhdr
.hd Hnames (files) 20-Oct-82
rewriting rules for mail addresses
.ds
It is often necessary to provide extremely hybridized addresses to force
a message to be gatewayed from the system upon which it was composed to
the system upon which the intended recipient resides.
Eventually, all systems will support a common addressing syntax; until that
time, it  will be necessary for the user to present hybridized addresses to
the mail system.
The rewriting rules embodied in `hnames' permit the user to use standard
addresses (user @ host);
the system then produces the hybridized address for the user.
.im
Each line of the file consists of two tokens separated by blanks, with
the following positional meanings:

host-string      replacement-pattern

`host-string' is of the form "@hostname", while `replacement-pattern' is
any sequence of characters up to the terminating newline, and MUST
contain the character '&'.
The rewriting rules are used as follows:

.nf
repeat {
.in +3
get next address
break into form left-side@host
lookup @host in rewriting rules
if (! found)
.ti +3
break
replace all occurrences of '&' in replacement text by left-side
push replacement text back onto input
}
.in -3
.fi
.sp
The standard composition programs provided by the system load two files
containing rewriting rules in the following order: ~msg/hnames, then
~/hnames.
The first file loaded contains system-specific rewriting rules available to
all users of the system, while the second file is the user's own set of
rewriting rules kept in his home directory.
By loading the files in this order, any conflicts in host name give the
user's definition preference.
.bp
.ex
.fi
Consider the following entries in ~msg/hnames:

.nf
@lbl-unix	&@lbl-unix@lblg
@berkeley	&@berkeley@lbl-unix
@ucbvax		ucbvax!&@lbl-unix
@decvax		decvax!&@ucbvax
.fi

The following name translations will be performed

.nf
user@lblg     ==> user@lblg
user@lbl-unix ==> user@lbl-unix@lblg
user@berkeley ==> user@berkeley@lbl-unix
.ti +14
==> user@berkeley@lbl-unix@lblg
user@ucbvax   ==> ucbvax!user@berkeley
.in +14
==> ucbvax!user@berkeley@lbl-unix
==> ucbvax!user@berkeley@lbl-unix@lblg
.in -14
user@decvax   ==> decvax!user@ucbvax
.in +14
==> ucbvax!decvax!user@berkeley
==> ucbvax!decvax!user@berkeley@lbl-unix
==> ucbvax!decvax!user@berkeley@lbl-unix@lblg
.in -14
.fi
.fl
~/hnames, ~msg/hnames
.au
Joe Sventek
#-h- hosts.fmt       3428  asc  20-dec-82 13:19:54  sventek (joseph sventek)
.so ~bin/manhdr
.hd Hosts (files) 20-Oct-82
Host routing table
.ds
Once the mail delivery system has received a message to deliver to an
user on another host, it must figure out how to get the message to its
destination.
Unlike other systems which decide which network to use dependent upon
various pieces of fruit salad in the address, the tools delivery system
requires that the binding of network protocol to host name be provided
in this file, ~msg/hosts.

As networks become more commonplace, it will not be unusual for there to
exist multiple routes over different networks between two hosts.
As such, it is necessary that the delivery system support the capability to
adaptively route the message, dependent upon the availability of the various
connecting network substrates.
If more than one route exists between hosts, the order of trial for the
different networks is encoded in this file, also.
.im
Each line of the file `~msg/hosts' consists of three blank-separated fields,
with the following positional meanings:

dest-host   route-host   protocol-to-use

where `dest-host' is the host we are trying to reach (no '@' here),
`route-host' is the actual host to send the message to (again, no '@'),
and `protocol-to-use' describes the protocol to use to send the message
to `route-host'.
.sp
If `route-host' is the character '*', this is shorthand to mean that
`route-host' is identical to `dest-host'.
If `protocol-to-use' is of the form

|"command to execute"

The command will be spawned, with the message file fed to the command as
its standard input.
In this way, additional network support can be achieved without rebuilding
the delivery system.
.sp
If the last character before the newline is an atsign ('@'), this implies that
the next line is an alternate route to the same destination.
The alternate routes are tried in the order listed in the file until the
message is successfully delivered.

If a particular host cannot be found in the file, and an entry for the host
`default' exists, then the action specified will be taken.
In this situation, an asterisk ('*') in column two indicates that `route-host'
is identical to the host we were unable to find in the table.
.ex
.fi
Suppose the following host table

.nf
lblg     *      decnet@
lblg     *      hyperchannel
lblh     *      decnet
default  lblg   decnet
unix     *      |"msgtouucp unix ??~msg/msgtouucp.log"
gizork   *      gizorknet
.fi
.sp
Then the following routing decisions will be made:

.in +2
.ti -2
* user@lblg - first try decnet; if that fails, try hyperchannel
.ti -2
* user@lblh - only try decnet
.ti -2
* user@unix - delivr will spawn msgtouucp with its standard input receiving
the SMTP-encoded temporary file.  It is msgtouucp's responsibility to
deliver the mail, and to exit with and error if it was unable to do so.
In this way, delivr can  requeue the  message for later delivery.
.ti -2
* user@gizork - use gizorknet protocol
.ti -2
* user@foo - hot potato route the message to lblg, which will have the
resources to deliver the message.
.in -2
.sp
If the default line had been of the form

default  *      decnet

then delivr would have attempted to deliver the mail to `foo' directly via
decnet.
.fl
~msg/hosts
.sa
hnames(5)
.di
If a host could not be found in the file and there is no default action, the
message is returned to the sender with an error indicating that they have
specified an invalid host.
.au
Joe Sventek
#-h- lnames.fmt      1005  asc  20-dec-82 13:19:57  sventek (joseph sventek)
.so ~bin/manhdr
.hd Lnames (files) 21-Oct-82
Binding of host names to networks
.ds
One of the unfortunate facts of existing systems is that a host can be
known by different names on different networks.
Hopefully, this situation will change over time; until that great day,
it is necessary for the software to know the names by which a particular
host is known on each network to which it is directly connected.
.im
The above binding is described in the file `~msg/lnames'.
Each line of this file consists of two blank-separated tokens, with the
following positional meanings:

network-name  @host-name

The value for network-name are the same used in the file ~msg/hosts.
In addition, a value for the network-name "default" should be placed
here.
This value will be used when composing the mail, as well as, whenever
`gthost' is invoked for an unknown network.
.ex
.fi
The following is the contents of the author's ~msg/lnames file:

default		@j
.fl
~msg/lnames
.sa
hosts(5), gthost(mail)
.au
Joe Sventek
#-h- malias.fmt      3926  asc  20-dec-82 13:20:02  sventek (joseph sventek)
.so ~bin/manhdr
.hd Malias (files) 21-Oct-82
file of mail aliases
.ds
A critically important feature of any mail system is the ability to define
alias names which expand into one or more addresses at mail delivery time.
Besides permitting groups to be identified with a single name, the feature
also permits mail forwarding, network teleconferencing and many other
useful applications.
The tools mail system provides for a system-wide alias file, the contents of
which are valid for local and remote users alike.
In addition, when using the standard composition utilities, a user-specific
alias file (in the user's home directory), as well as a directory-specific
alias file (in the current directory) are loaded for use by the user.
In this latter case, the aliases are loaded in the order described; in this
way, conflicts in the alias name space are resolved in favor of the most
recently loaded value for the alias.
.sp
The expansion of aliases is similar to the expansion of macros in programming
languages.
The recursive nature of the expansion (and the possibility for infinite
recursion if the aliases are not well-formed) requires that some care be
taken when creating and modifying a specific alias definition file.
.im
Each of the alias files consists of one or more alias definitions.
Each alias definition is of the following form:

alias-name: [address] [,address]* ;

The `alias-name' should consist of alphanumerics, together with the
characters minus '-' and underscore '_'.
Each `address' can be any valid user address, including another alias name.
Commas ',' must separate addresses; an alias definition can be continued to
another line by simply breaking the definition at one of the commas.
The end of an alias is indicated by the appearance of a semi-colon ';'.
.sp
If it is desired to prevent the expansion of an alias name during mail
delivery, surrounding the name with quotes '"' will do the trick (see examples
below).

Two special forms of the alias definition are permitted in the system
alias file:
.sp
.in +2
.ti -2
* The alias-name can be separated from the definition by a question mark
'?' instead of a colon ':'.
Aliases so flagged will NOT be listed by the `users' utility.
.ti -2
* A valid form for the replacement part of the definition is

|"command to execute";

This form will cause the message to be delivered as the standard input
to a process running the specified command.
.in -2
.ex
.fi
Suppose the following definitions in the file `~msg/malias':
.sp
.nf
.in +2
all(the supreme being's children): dicomed,dicosys,graves,
    guest,hall,hiss,j,merola,mo,netnpr,netpri,oracle,
    rtsg,scherrer,sventek,sventekv,system,tape,tools,tpc;
rsx_wizards (those wild and craaaazy guys): sventek,wayne;
wayne: graves@lblh;
rmtxeq: |"rmtxeq ??~mail/rmtxeq.log";
tc_mailbugs? "tc_mailbugs", "tc_mailbugs"@lblh,
     "tc_mailbugs"@lblg;
netnpr? ;
.in -2
.fi
.sp
Perusal of these aliases displays all of the major features of possible
alias definitions:
.sp
.in +3
.ti -3
1. Multi-line definitions are achieved by simply breaking the definition
at a comma (all & tc_mailbugs).
.sp
.ti -3
2. Comments about the alias name are achieved by placing the comments
inside of parentheses next to the alias name before the ':' of '?'
separator (all & rsx_wizards).
.sp
.ti -3
3. Network addresses can be used in the replacement part of the definition
(wayne).
.sp
.ti -3
4. A command to spawn can be the replacement part of an alias in the system
alias file (rmtxeq).
.sp
.ti -3
5. A valid address can be defined as an alias also (the name spaces are
separate).  In this situation, it is important to be sure to place
the address inside of quotes in the definition part to avoid infinite
recursion (tc_mailbugs).
.sp
.ti -3
6. For those addresses for which mail is not desired, they can be aliased to
nothing (netnpr).
.in -3
.fl
~msg/malias, ~/malias, ./malias
.sa
sndmsg(1), users(1)
.au
Joe Sventek
#-h- msghlp.fmt       787  asc  20-dec-82 13:20:06  sventek (joseph sventek)
.so ~bin/manhdr
.hd Msghlp (files) 21-Oct-82
help file for msg utility
.ds
This file provides the help information used by the `msg' utility.
The only entry in the archive which should ever be changed is the
news module; this should be changed to reflect any changes in the
workings of the mail system.
.im
The file is an archive as maintained by `ar', and has to reside in
the ~msg directory.
To change the news entry in the archive, one must perform the following
steps:
.sp
.in +5
.nf
% ar xv ~msg/msghlp news
% ed news
<make your modifications and write the file>
% ar uv ~msg/msghlp news
.fi
.sp
.in -5
Any other form of modification (especially editing the archive file itself)
can have dire consequences in the workings of `msg'.
.fl
~msg/msghlp
.sa
msg(1), ar(1)
.au
Joe Sventek
#-h- rmtxeq.fmt      2070  asc  20-dec-82 13:20:09  sventek (joseph sventek)
.so ~bin/manhdr
.hd Rmtxeq (files) 20-Oct-82
valid verbs for remote job execution
.ds
One of the utilities provided with the system is `rmtxeq', which permits
non-local users to run programs on your system through the mail system.
Support for this facility can be controlled locally through two
mechanisms:
.sp
.in +3
.ti -3
1. The capability is not inherent to the system.  If the following alias
does not appear in ~msg/malias, then remote job execution will not be
possible on your system:
.sp
rmtxeq: |"rmtxeq ??~msg/rmtxeq.log";
.sp
.ti -3
2. If you wish to provide such capabilities for only a few programs, then
one can control which programs can be executed through the list of valid
verbs in the file ~msg/rmtxeq.cmd.
.sp
.in -3
.im
Each line of ~msg/rmtxeq.cmd consists of a verb which can be executed via
the remote job execution capability.
Upon receipt of a message, the `rmtxeq' utility uses the first line of the
body of the message as the command to execute, with all succeeding lines
passed to the command as its standard output.
The first blank-separated token from the command is fetched and compared with
the valid verbs found in ~msg/rmtxeq.cmd.
If the verb is valid, then the command is spawned, with the output from
the command captured and mailed back to the sender in a return message.
Attempts to execute invalid verbs are logged in ~msg/rmtxeq.log for perusal
by the system manager.
.ex
.fi
It is common to enable the alias in the system alias file for rmtxeq, and to
place the following types of verbs in ~msg/rmtxeq.cmd:

.nf
users
who
ps
finger
.fi

Since the delivery system is working on a queue, it is important to prevent
users from being able to run long jobs from within the mail system; otherwise,
the delivery of regular mail will be held up.
It is also important to prevent users from running jobs which require a large
amount of input in the original message or generate large amounts of output to
be returned, as large files can have a deleterious effect on the delivery
system.
.fl
~msg/rmtxeq.cmd
.sa
malias(5)
.au
Joe Sventek
#-h- sufile.fmt       934  asc  20-dec-82 13:20:12  sventek (joseph sventek)
.so ~bin/manhdr
.hd Sufile (files) 20-Oct-82
list of mail system super-users
.ds
Several system-management utilities are included with the system to
permit on-line control over various aspects of the delivery system.
By default, these utilities prompt the requestor for a password before
the action is taken.
Unfortunately, this prevents the utilities from being invoked in the
background or from batch queues, or from any other non-interactive
setting.
To permit their use in non-interactive situations, each of the utilities
can be invoked with a `-p' flag, which causes the validation routine to
compare the username of the process with the names listed in  `~msg/sufile'.
A name match is then equivalent to providing the correct password in the
interactive case.
.ex
.fi
The contents of the author's ~msg/sufile are displayed below:

.nf
sventek
system
.fi
.fl
~msg/sufile
.sa
mstop(sys), mtrace(sys), nalias(sys)
.au
Joe Sventek
#-h- topics.fmt      1585  asc  20-dec-82 13:20:15  sventek (joseph sventek)
.so ~bin/manhdr
.hd Topics (files) 20-Oct-82
Binding of topic names to file names
.ds
As described in the manual entry for `tc', each teleconference topic is
implemented as a set of files in the TC directory with a common filename
root, and with different suffixes differentiating the different files in the
topic set.
Due to variations in file naming capabilties on different systems,
one level of indirection mapping topic names and filename roots is required
to provide a reasonable name space for teleconference topics.
This file provides the mapping from teleconference topic name to filename
root in the TC directory.
.im
Each line of the file ~msg/topics consists of two blank separated tokens,
with the following positional meanings:

topic-name   file-name-root

where `topic-name' is the actual topic name used in calls to `tc' and in
addresses of the form tc_topic-name when making contributions to a
teleconference, and `file-name-root' is the root of the set of files
which implement the teleconference.
This file should probably be kept in sorted order, but it is not required.
.ex
.fi
Suppose the following lines make up ~msg/topics:

.nf
general			general
info-vax		infovax
unix-wizards		unixwhiz
.fi
.sp
For the teleconference unix-wizards, the following four files appear in the
TC directory:
.sp
.nf
unixwhiz.nfo - read and/or write access lists and help info
unixwhiz.bnd - current first and last entry numbers
unixwhiz.tc  - encrypted archive of teleconference entries
unixwhiz.ndx - indices into .tc file for entries
.fi
.fl
~msg/topics
.sa
tc(1)
.au
Joe Sventek