This section provides an overview of SNADS e-mail concepts and how they relate to e-mail concepts in the PMDF world. While readers familiar with the SNADS environment may prefer to skip this section, the information presented here may provide a useful context for readers unfamiliar with SNADS.
42.2.1 SNADS architecture
SNADS is a very different mail protocol from SMTP. A SNADS mail item is
called a distribution. There are two types of distribution:
data distributions and status distributions.
A data distribution consists of three parts, roughly corresponding to envelope information, headers, and message body. More precisely, these parts are:
A status distribution is expected by SNADS user agents for each recipient of each data distribution. These are very structured messages, and there is no equivalent in SMTP until the new NOTARY recommendations are widely implemented.
A SNADS user has a name consisting of two parts, each of which can be no more than eight characters long. These two parts are called the DEN (Distribution Element Name), and DGN (Distribution Group Name). A SNADS user name is also referred to as a DUN (Destination User Name).
Each SNADS node also has a name which has one or two parts. The first part is called the REN (Routing Element Name). The second part is called the RGN (Routing Group Name). The RGN may be absent, and often is. The SNADS node name is also referred to as a DSUN (Distribution Service Unit Name).
SNADS user names, i.e., DUN's, must be unique throughout the
SNADS network. A DUN is unique and thus provides, in effect, a complete
address, even without the DSUN. That is, a SNADS user may be addressed
using merely the user DEN and DGN information; no node information,
i.e., no REN or RGN information, is required. The theory is
that user names should not have to change if the users move from being
served by one machine to another. In practice, it is almost universal
practice to constrain user names so that the DGN of each user is the
same as the REN of the machine serving them, and to not use the RGN.
Effectively, this yields an eight character by eight character
addressing space consisting of merely the DEN and REN, or
username@ nodename. Thus, for example, a
SNADS user FRED@MVS21 will probably be found on the machine called
MVS21.
The SNADS command in a data distribution (i.e., message) contains the DEN, DGN, REN and RGN for each recipient. SNADS works by routing the distribution using the REN and RGN information only to reach the destination node, and then using the DEN and DGN to pass the distribution to the user. If a SNADS distribution is routed (using the REN and RGN) to the wrong node, then that node will redirect (using the DEN and DGN) to the right DSUN. In theory, this means that each node has to be configured to know where each user is. In practice, (with DGN and REN constrained to be the same and RGN not used), directory information of the form "users with DGN=XXX are found at REN=XXX" is sufficient.