First, the useresent channel keyword, if used on the local
channel, controls whether or not PMDF preferentially uses any Resent-
headers in its construction of headers to pass to VMS MAIL.
Next, PMDF checks for the existence of a PMDF-TO-VMSMAIL table in the
mapping file. If this table exists, each address is converted into a
probe string of the form
channelname|addresswhere
channelname is the name of the channel
performing the operation and address is the
address being processed. Since this operation is normally done when
PMDF is delivering messages to VMS MAIL, the channel name should be the
name of the channel actually delivering the message.
If no mapping entry matches the probe string, the address is not changed. However, if an entry does match, the result of the mapping replaces the address. The result can either be a VMS MAIL address or a RFC 822 address. The mapping template should specify a $< metacharacter if it produces a RFC 822 address and $> metacharacter if it produces a VMS MAIL address. No further conversion will be done if $> is specified.
If the conversion process has resulted in a RFC 822 address, at this point, the process proceeds to convert the address into a format acceptable to VMS MAIL. This operation is almost the inverse of conversion described in Section 19.1.1, Conversion of VMS To: addresses to PMDF format . The "\d" and "\s" forms are substituted, respectively, for double and single quotes. An IN%" " wrapper is added to each address.
A couple of additional operations are also performed in an attempt to make up for limitations of VMS MAIL. VMS MAIL makes some attempt to add DECnet routing information to the lines it processes. Specifically, the name of the local DECnet node is prepended to some addresses. This information is added because without it addresses transferred to remote nodes via MAIL-11 are not repliable (the operation is actually performed by the remote node using its own name for the originating node).
However, the processing done by VMS MAIL is incomplete. First, if multiple addresses appear on the VMS MAIL From: line, only the first address has DECnet routing information added to it. Second, the VMS MAIL To: and Cc: lines are also used for replies in some cases. In particular, the Pathworks MAIL application provides a REPLY-TO-ALL function that attempts to send to all addresses on the VMS MAIL From:, To: and Cc: lines. Unfortunately VMS MAIL fails to prepend correct node information to To: and Cc: line addresses.
PMDF attempts to correct these problems if requested to do so. The
daemon channel keyword is used to activate this feature
--- if this keyword is present the argument given to it is interpreted
as a DECnet node name (the double colons may be included if desired;
they will be added automatically if they are not specified as part of
the node name). This node name information is prepended to the second
and subsequent addresses appearing on the VMS MAIL From: line. This
node information is appended to every address that appears on
the To: and Cc: lines.
If the special argument SYS$NODE is given to the daemon
keyword the SYS$NODE logical is translated and the result is used as
the prepended node name. This can be useful in heterogeneous cluster
environments with complex queue setups where the DECnet node name
associated with a channel may not be known before the delivery job
starts running in a specific queue.
This sort of daemon keyword may be used on any channel
associated with VMS MAIL: local (l), DECnet MAIL-11 (d, d_), and MAIL
(mail_) channels are all affected. Usually this feature is used with d
and d_ channels; it may occasionally be useful on the l channel, but a
price is incurred in terms of unnecessarily complex addresses in this
case. Note that the daemon keyword controls additional
functionality when used in conjunction with mail_ channels; see the
Section 19.1.4 for additional details.