The PMDF-MR configuration utility creates an initial
mr_local_option. channel option file or initial
mrif_mailbox_option. channel option files for
you, based upon the information you provided it. You should use
the PMDF-MR configuration utility to generate these initial channel
options files, which you can want to further customize manually
PMDF-MR uses channel-specific option files to specify various configuration options that cannot be specified in the PMDF configuration or option files. These files are read by the PMDF-MR channel programs during initialization.
220.127.116.11 Location of the Option Files
PMDF-MR option files are stored in the PMDF table directory and must
have names of the form
channelname the name of the PMDF-MR channel for
which this option file applies. Since the channel names for PMDF-MR are
usually mr_local (for PMDF-MR used to connect to Message Router), or
names along the lines of mrif_am, mrif_a1, etc., (for PMDF-MR
acting as a Message Router Transport Service replacement), the
filenames are usually
18.104.22.168 Format of the Option File
Option files consist of several lines. Each line contains the setting
for one option. An option setting has the form:
valuecan be either a string or an integer, depending on the option's requirements. If the option accepts an integer value,
value, a base can be specified using notation of the form
bis the base expressed in base 10 and
vis the actual value expressed in base
Comments are allowed. Any line that begins with an exclamation point is considered to be a comment and is ignored. Blank lines are also ignored in any option file.
The available options are:
A1_COMPAT_MODE (integer)Some ALL-IN-1 configurations like to pass attachment file name information around by putting it in the subject of the "message wrapper" that ALL-IN-1 puts around attachments. (MailWorks can also be put into "ALL-IN-1 compatibility mode" where it also operates in this fashion via MailWorks' AI1_COMPAT_MODE option.) The PMDF-MR A1_COMPAT_MODE option controls whether PMDF-MR looks for such file names in the "message wrapper" around each attachment coming from ALL-IN-1, and whether PMDF-MR constructs such a "message wrapper" around attachments going in to Message Router. The A1_COMPAT_MODE option takes a bit encoded value; bit 0 controls whether PMDF-MR looks for a filename on the subject coming out of Message Router; bit 1 of the option controls whether PMDF-MR constructs such a wrapper on messages going in. Thus for instance A1_COMPAT_MODE=3 tells PMDF-MR both to look for such file names in message wrappers coming out, and to construct such wrappers for messages going in. The default value is 0.
A1_TRIVIAL (0 or 1)If A1_TRIVIAL=1 is set, then PMDF-MR will attempt to detect the "message wrappers" that ALL-IN-1 puts around attachments, and to omit only those trivial "message wrappers", while leaving "real" message structures, i.e., message parts corresponding to forwarded messages, unchanged. The default is 0, meaning that PMDF-MR preserves the original Message Router message structure.
ADJUST_HOP_COUNT (-2, -1, 0, or 1)Default of 0 means the value of the hop-count header if present is copied into the Message Router hop count. A value of 1 means to add the number of Received: lines to the hop-count in addition to using the value present in any existing hop-count header. A value of -1 forces the hop count to always start at one (if using PMDF-MR in MR TS replacement mode) or zero (if using PMDF-MR in traditional mode to connect to Message Router). A value of -2 completely disables the generation of any hop-count headers for messages coming from Message Router.
BINARY_ENCODING (string)The BINARY_ENCODING option controls the MIME transfer encoding used when binary format Message Router body parts are converted into MIME body parts. Possible values include BASE64, QUOTED-PRINTABLE, X-UUENCODE and HEXADECIMAL. The standard BASE64 MIME encoding is the default.
CONVERT_APPLEFILE (string)This option specifies the Message Router tag string that is applied to MacBinary objects by PMDF-MR when sending to Message Router. Possible values include MACBINARY, MACB or MB or whatever you have set to be the type for MACBINARY in Message Router. See the related option CONVERT_MACBINARY for additional information on the use of this option.
CONVERT_APPLICATION_OCTET_STREAM (FDL string)MIME's application/octet-stream content-type is used to transfer untyped raw binary data. The CONVERT_APPLICATION_OCTET_STREAM option controls what File Description Language (FDL) information is associated with such data as it enters Message Router. Whether or not such data is ever converted in the first place is controlled by the
CONVERT_DX (0, 1 or 2)The CONVERT_DX option specifies whether or not DX message body parts are converted to ASCII using the DCF utility. A description of the DCF utility is given in the instructions of Section 40.2.2 above. A value of 0 inhibits this conversion and a value of 1 activates it. A value of two causes PMDF to turn the DX NBS attachment into a DX file. The default value is 1 on VAX or 2 on Alpha. This option should not be set to 1 unless the DCF utility is actually available. If DX body parts are not converted they can either be retained in binary form or discarded; the ENCODE_BODYPARTS option described below controls this selection.
CONVERT_DECBODY7 (0 or 1)DECBODY7 Message Router body parts are used to transfer OpenVMS files using a special OpenVMS-specific encoding. PMDF-MR has the ability to convert this encoding to and from the OpenVMS-specific encoding used by PMDF (and thus by VMS MAIL). The CONVERT_DECBODY7 option specifies whether or not this conversion is done. A value of 1 enables conversion, a value of 0 disables it. The default is 1. If DECBODY7 body parts are not converted they can either be retained in binary form or discarded; the ENCODE_BODYPARTS option described below controls this selection.
CONVERT_MACBINARY (-1, 0, 1, or 2)A value of 0 converts MacBinary Message Router attachments with the label specified by the CONVERT_APPLEFILE option into AppleSingle format before entering PMDF. This is the default. A value of 1 converts MacBinary attachments into BinHex format. A value of 2 converts MacBinary to AppleDouble format. A value of -1 disables this conversion completely.
CONVERT_ROUTE (bit encoding)Although Message Router supports many address elements that correspond to X.400-1984 address attributes, some Message Router gateways and User Agents do not support these attributes. These applications instead elect to embed additional attributes as routing information. Specifically, elements are embedded as NAME=VALUE strings actually within a route element, rather than as elements in their own right. See Table 40-1 for a list of the embedded names and numbers that PMDF-MR can deal with. PMDF-MR also supports embedded domain-defined attributes in *name\value format in addition to to the names listed in the table. PMDF-MR provides support for this embedding via the CONVERT_ROUTE option. CONVERT_ROUTE is a bit-encoded integer:
Bit Usage 0 When set, all routes found in incoming addresses are scanned and decoded to their corresponding elements if possible. 1 When set, attributes in addresses flowing from PMDF-MR into Message Router are embedded in route elements. Note that a flag in the TO_MR rules can be used to explicitly direct embedding of attributes into route elements, regardless of the value of this bit. 2,3 These two bits control the optional removal of duplicate information from addresses. Duplication can occur when a converted route matches up with an existing attribute already in the address. If bit 2 is set to 1 the attribute generated by decoding the route is deleted if it duplicates an existing attribute. If bit 3 is set to 1 the existing attribute is deleted in favor of the attribute decoded from the route. Setting both bits 2 and 3 is reserved for future use.
|Number||Name||PMDF-MR attribute name|
|13||PERSONAL_NAME||encoded personal name (S/I/G)|
|0||1||If set, the PMDF DCF utility is used to convert WPSPLUS NBS attachments into ASCII text. If bits 0, 1 and 4 are all clear, the handling of WPSPLUS NBS attachments is controlled by the ENCODE_BODYPARTS option.|
|1||2||If set, WPSPLUS NBS attachments are turned into WPSPLUS files. Bit 1 is overridden by bit 0 if bit 0 is set. This option is only available in conjunction with Message Router V3.3 or later.|
|2||4||Blocks the deletion of temporary WPSPLUS files if set. This is useful for debugging.|
|3||8||Blocks the deletion of temporary ASCII files if set. This is useful for debugging.|
|4||16||If set, WPSPLUS NBS attachments are decoded into WPSMAIL format. Bit 4 is overridden by either of bits 0 or 1.|
|5||32||If set, application/vnd.digital.wpsplus and application/wpsplus attachments are converted into WPSPLUS NBS attachments. This option is only available in conjunction with Message Router V3.3 or later. If this bit is not set, the handling of such attachments is controlled by the MIME-TO-MR-CONTENT-TYPES mapping.|
DIRECTORY_DATABASEoption controls these screening facilities. If defined, this option should translate into a path and file name for a PMDF database file created with the
PMDF CRDButility. Each originator address is then translated into its Message Router equivalent, converted into USER@MAILBOX@ROUTE format (i.e., as the address would appear in a DDS reverse lookup entry), and looked up in the database. If a match occurs the originator address is left untouched; if no match occurs the address is replaced by the address specified by the
SUBSTITUTE_ADDRESSoption. The original address is also added to the message body along with an explanatory note so that the recipient will understand what was done. Finally, the unmatched entry is optionally recorded in the exceptions file specified by the
DIRECTORY_DATABASEoption is not defined by default and hence screening is disabled by default. The database is normally populated by dumping all the reverse lookup entries in the DDS to a flat file and then converting it using
crdb. The right hand side of each database entry is unused; it can be filled in with whatever information is handy or useful. (If the
DIRECTORY_EXCEPTIONSfile is used to build new entries, the right hand side will be the original RFC 822 address.)
DIRECTORY_EXCEPTIONSoption is used in conjunction with the
DIRECTORY_DATABASEoption; see the description of
DIRECTORY_EXCEPTIONSoption specifies a flat text file where unmatched originator addresses are recorded. If both a directory database and exception file are active and an originator address fails to match, an entry will be made in the exception file. Each entry in that file consists of a single line containing the unmatched Message Router address on the left and the corresponding RFC 822 address prior to conversion on the right. The
DIRECTORY_EXCEPTIONSoption is not defined by default and hence unmatched entry reporting is disabled by default.
ENCODE_BODYPARTSoption controls the disposition of binary body parts of Message Router messages that don't get converted to text by some other means (see the options described above for descriptions of the various conversions that are possible). PMDF-MR can either encode these body parts in a special printable format that other PMDF-MR installations can understand and decode, or it can simply discard them. A value of 1 for this option specifies encoding, a value of 0 specifies discarding (a note is attached indicating that this was done). The default is 1.
FROM_MR_DATABASEoption is used to override the default database used to map Message Router addresses into PMDF 822-style addresses. The default database file pointed to by the
PMDF_FROM_MR_DATABASElogical name is used if this option is not specified. This option is mostly used with MR TS replacement channels, or when a second Message Router channel is set up that needs a database other than the one used on the primary Message Router channel.
FROM_TO_AUTHORoption controls the optional copying of the Message Router FROM field to the
AUTHORfield when no
AUTHORfield is specified. RFC 2156 specifies that when both the RFC 822
Sender:headers are present the
From:header be mapped into the
AUTHORfield while the
Sender:header gets mapped to the
FROMfield, and if only a
From:header is present it is mapped to the
FROMfield. The latter case causes problems with applications that incorrectly provide access to just the
AUTHORfield. When set to 1, the
FROMinformation in the AUTHOR field in an attempt to work around this problem. The default value is 0, which inhibits this duplication.
Reply-to:header and the Message Router
REPLYTOUSERSfield. With some Message Router user agents, however, (such as some older versions of Teamlinks), it can in some cases (such as when both
Sender:RFC 822 header lines are present) be useful to propogate the
From:RFC 822 header value into the Message Router
REPLYTOUSERSfield, if no RFC 822
Reply-to:is present. If
FROM_TO_REPLYTOis set to 1, the
From:value is copied to the Message Router
FROM_TO_REPLYTOis set to 2, then the
From:value is copied to the
REPLYTOUSERSfield only if there was a non-empty
Sender:value. By default,
From:value is not copied to the
NOTIFYoption specifies the name of a VMS mailbox used for pending message notifications. PMDF-MR sends a message to this mailbox each time a message enters the channel queue and is ready for an agent to pick up. This option is only available for MRIF channels. For a MRIF channel connecting to MailWorks, this should usually be set to MUAS$NOTIF_FETCH_MBX; for a MRIF channel connecting to ALL-IN-1, this should usually be set to OA$NOTIFY_MBX.
mr_, this option specifies the password associated with the Message Router mailbox with which this PMDF-MR channel is associated. (Note that the actual mailbox name and DECnet node are given in the PMDF configuration file channel block.) The password is whatever string was given to MRMAN as shown in the instructions of Section 40.2.1 above. This option is required for proper operation of the channel. This password is secret, so be sure to protect this option file against world access. In the case of a MRIF channel,
mrif_, this option specifies the password the agent must provide in order to successfully connect to PMDF-MR and thus to PMDF. The password is whatever string the Message Router agent, ALL-IN-1 or MailWorks, is configured to use as its own password. Again, this option is required for proper channel operation. This password is secret, so be sure to protect this option file against world access.
mrif$m_ua_basic 8 mrif$m_ua_confirmed 16 mrif$m_mr_basic 32 mrif$m_mr_confirmed 64 mrif$m_action 128
REJECT_INVALIDoption is set to 1, when a message coming from Message Router has an illegal Message Router message format causing HP's Message Router routines to refuse to process the message with a MRIF-E-INVALIDMSG error, then PMDF will issue an error code back to Message Router; Message Router will then silently sideline the message as a -BAD message, allowing the other messages waiting to go to PMDF to be processed. The default value is 0, meaning that PMDF will not issue that error code to Message Router and the message will remain in the PMDF mailbox inside MRMAN for manual intervention by the PMDF postmaster.
RESTORE_HEADERSoption provides the inverse of the operation of the
SAVE_HEADERSoption described below. Specifically, if
RESTORE_HEADERSis set to 1, any headers saved in a special Message Router body part at the end of the message will be detected and restored as actual message headers. The format of the body part complies with RFC 2156. If
RESTORE_HEADERSis set to 2, any headers saved in a special Message Router body part at the beginning of the message will be detected and restored as actual message headers.
RESTORE_HEADERS=3causes PMDF-MR to look for the special Message Router body part as the first part, and if not present there as the final part. The default value for this option is 0, which disables this operation.
SAVE_HEADERSoption controls the disposition of message headers that cannot be mapped into corresponding Message Router information. The default value is 1, which causes such information, if present, to be stored in a special text body part whose format conforms with RFC 2156. A value of 0 will cause such header information to be discarded.
SCREEN_ENVELOPEoption controls the screening PMDF-MR uses to decide which envelope recipient addresses it should deliver to. By convention, PMDF-MR is only supposed to operate on addresses that have the action bit set (in the per-recipient flags field) and which contain the PMDF-MR mailbox as their first route specification. However, in some configurations this sort of screening can eliminate some legitimate addresses. A
SCREEN_ENVELOPEvalue of 2 is the default, and specifies that screening be done according to the specifications. A value of 1 causes PMDF-MR to accept addresses with no associated route information as its own. A value of 0 causes PMDF-MR to accept any address with the action bit set regardless of the route the address contains. A setting of 2 for
SCREEN_ENVELOPE(the default) is strongly recommended for all MR channels. Envelope screening is usually inappropriate for MRIF channels so a value of 0 should be specified.
Subject:header line. Whatever string is specified is used literally with the exception of dollar sign characters. Dollar sign characters are expanded into a unique alphanumeric string; (some gateways can require that subject lines be unique as well as nonempty). A literal dollar sign can be inserted by specifying a pair of dollar signs "$$". The default string "- no subject ($) -" is used if this option is not specified.
SUBSTITUTE_ADDRESSoption is used in conjunction with the
DIRECTORY_DATABASEoption; see the description of
SUBSTITUTE_ADDRESSoption specifies a known, valid RFC 822 address (e.g.,
user@domain) which should be used to replace unmatched originator addresses. This option has no default value and must be specified if screening-by-directory is to be effective.
TO_MR_DATABASEoption is used to override the default database used to map PMDF 822-style addresses into Message Router addresses. The default database file pointed to by the
PMDF_TO_MR_DATABASElogical name is used if this option is not specified. This option is mostly used with MR TS replacement channels, or when a second Message Router channel is set up that needs a database other than the one used on the primary Message Router channel.
TRIM_ATTRIBUTESoption provides a facility that can be used to eliminate these spaces and possibly the entire attribute. A value of 0 turns off all trimming actions. A value of 1 eliminates leading and trailing spaces and compresses multiple embedded spaces into a single space in all attribute values. The special value containing a single space character is left alone; such values have special meaning in X.400 addresses. A value of 2 performs the same compression operations as 1 does and also removes attributes with empty value strings completely. The default for this option is 2.