PMDF System Manager's Guide

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|address

where 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 18.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 can 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 can not be known before the delivery job starts running in a specific queue.

This sort of daemon keyword can 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 can 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 18.1.4 for additional details.