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 can prefer to skip this section, the information presented here can provide a useful context for readers unfamiliar with SNADS.

4.2.1 SNADS Architecture

A data distribution consists of three parts, roughly corresponding to envelope information, headers, and message body. More precisely, these parts are:

1. A SNADS command, which is envelope information: originator, recipients and message id;
2. A DIA profile (Document Interchange Architecture profile), which is structured header information; and
3. A DIA document, which is either FFT (Final Form Text --- simple EBCDIC text), RFT (Revisable Form Text --- a word processing format), or a binary file.

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 can 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 can 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.