This section describes the architecture of PMDF-XGS; in particular, the structure of PMDF-XGS vis--vis SNADS.
42.3.1 SNADS addresses in PMDF-XGS
PMDF-XGS maps the DEN part of a DUN into an SMTP user name, and the DGN
part of a DUN into a short-form host name, e.g., a short-form
SMTP host name. Each PMDF-XGS SNADS channel, e.g., the
snads_local channel, has associated with it the name of an immediately
adjacent DSUN or SNADS node, and the necessary information on how to
reach that node. (Once a message from PMDF to the SNADS world makes it
to that immediately adjacent SNADS node, then SNADS routing takes over
for getting the message to the intended final SNADS destination.)
PMDF has a number of facilities that can be used to assist in the transformation between RFC 822 style addresses and SNADS address; see Section 42.4 for details.
42.3.2 The topology of the PMDF-XGS connection to the SNADS world
In a simple PMDF-XGS gateway configuration, there is one SNADS channel,
snads_local, which connects via the PMDF-XGS transport bridge to one
immediately adjacent SNADS node; this effectively is a connection to
the entire SNADS world for which that adjacent SNADS node can route
messages. Distributions (messages) from the SNADS world addressed to
PMDF are routed within the SNADS world first to the SNADS node adjacent
to the PMDF-XGS transport bridge and then out through the PMDF-XGS
transport bridge to the PMDF-XGS/PMDF system via the snads_local
channel. (Note that although messages from PMDF to the SNADS world may
physically be being routed through a particular SNADS node, that is
purely a SNADS network issue and is invisible from the PMDF side. This
is similar to the way that all messages from SNADS pass through the
PMDF system, even if the message is destined for some other SMTP host
or other mail system to which PMDF provides access.)
In a more complex PMDF-XGS gateway configuration, there may be many SNADS channels, each associated with a different SNADS node (DSUN). In this case, each message (distribution) going to the SNADS world will be sent directly to the DSUN serving the message recipient over the respective snads_ren channel (where ren is the REN portion of the DSUN), and distributions (messages) coming from the SNADS world to PMDF will be transmitted back through that snads_ren channel. The use of such a configuration is mainly an issue of efficiency and convenience at the SNADS network level; to cut down on SNADS network traffic, or for administrative reasons, it may be desirable to have SNADS nodes communicate directly with the PMDF-XGS transport bridge rather than routing their distributions to the PMDF-XGS transport bridge through another SNADS node.
42.3.3 The function of the tranport bridge
Note that the PMDF-XGS transport bridge performs no SNADS routing. This
is true even in the case (multiple SNADS channels) where the PMDF-XGS
transport bridge is directly adjacent to several SNADS nodes; when
multiple channels are used, the PMDF system itself handles routing
messages to appropriate channels. The PMDF-XGS transport bridge is
purely a pipeline converter, taking SNADS distributions and squirting
them over TCP/IP to PMDF, or receiving messages over TCP/IP from PMDF
and converting them into SNADS distributions which it squirts to the
SNADS world. The PMDF-XGS transport bridge, although it is configured
to appear from the SNADS side as a SNADS node itself, and to accept
special TCP/IP connections from the PMDF side, is effectively
transparent from the e-mail point of view. The PMDF-XGS transport
bridge never holds any mail: it has no internal queues.
At the IP level, the PMDF-XGS transport bridge system needs its own name. And for clarity, the discussion in this documentation gives the PMDF-XGS transport bridge system its own SNADS node name distinct from the apparent SNADS node name used for the PMDF-XGS/PMDF system itself. However, in point of fact the PMDF-XGS transport bridge system and the actual PMDF-XGS/PMDF system itself are effectively the same "SNADS node" from the SNADS point of view, and you may, if you wish, use one SNADS name for both.
When a mail item is given to the PMDF-XGS transport bridge by PMDF, the PMDF-XGS transport bridge converts it, passes it on to the SNADS node associated with the channel, and waits for the SNADS node to accept responsibility for the mail before telling PMDF that the transfer is complete. When a SNADS distribution is received from SNADS, the distribution is converted to SMTP and passed immediately to PMDF: only when PMDF has accepted responsibility for the mail will the PMDF-XGS transport bridge confirm to the sending SNADS system that the transfer has been completed. That is, the PMDF-XGS transport bridge is not a destination point for messages and does not accept messages on its own behalf or perform routing of messages; it merely passes messages straight through in either direction. Hand-off of responsibility for the messages occurs between the PMDF system and the SNADS nodes; the PMDF-XGS transport bridge acts as an intermediary in relaying the confirmation that a message has been received from one side to the other, but does not accept the message itself, and thus at any instant either the PMDF system or a SNADS node has primary responsibility for a message (and a copy of the message).
42.3.4 Message attachments
MIME messages may have messages of complex and arbitrary structure. The
SNADS world, on the other hand, does not allow for messages with
attachments. So PMDF has to perform a message structure conversion when
sending to SNADS. Messages with multiple parts are
"flattened", with text markers inserted to show the original
message structure, and any binary attachments are split out and sent as
individual separate messages.
42.3.5 Notification/status messages
When sending to the SNADS world, PMDF-XGS converts SMTP notification
requests (requests for read or delivery receipts) to SNADS status
requests; then when the SNADS side sends the status distribution back,
PMDF-XGS converts it to an SMTP notification message.
The SNADS side expects a status distribution back for each recipient of a data distribution (message). Since the return of such receipt messages can not in general be guaranteed from the SMTP/RFC 822 side --- the generation of responses to such requests is entirely up to the eventual receiving mailer and user agent, and while some mailers and user agents support them, others do not -- the PMDF-XGS gateway sends a status distribution (message) back to the SNADS sender when the gateway first receives the message destined for the SMTP/RFC 822 side. That is, SNADS senders will receive a status distribution from the PMDF-XGS gateway itself not, in general, from the eventual message recipient.