PMDF System Manager's Guide
Previous Contents Index

39.2.5 Creating a Channel-specific Option File

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

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.

39.2.5.1 Location of the Option Files

PMDF-MR option files are stored in the PMDF table directory and must have names of the form channel_option with 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 mr_local_option, mrif_am_option, mrif_a1_option, etc., respectively.

39.2.5.2 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: 


option=value
value can 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 b%v, where b is the base expressed in base 10 and v is the actual value expressed in base b.

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_octet_stream channel keyword.

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 39.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 39-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.
Bit 0 is the least significant bit.
The default value for CONVERT_ROUTE is 1, (bit 0 set), which means that embedded attributes are decoded automatically for messages incoming to PMDF-MR from Message Router.

Table 39-1 Embedded Attribute Names and Numbers Recognized by PMDF-MR
Number Name PMDF-MR attribute name
1 COUNTRY C
2 ADMIN_DOMAIN ADMD
3 PRIVATE_DOMAIN PRMD
4 UNIT_NAME OU
5 ORGANIZATION O
6 SURNAME S
7 GIVEN_NAME G
8 INITIALS I
9 GENERATION GQ
10 UNIQUE_UAID UA-ID
11 X121_ADDRESS X121
12 TERMINAL_ID T-ID
13 PERSONAL_NAME encoded personal name (S/I/G)
14 ROUTE R
31 SN_USERNAME SN-U
32 SN_LOCATION SN-L
33 SN_USERNAME PR-U
34 SN_LOCATION PR-L

CONVERT_WPCORP (0, 1 or 2)

In older versions of Message Router and Message Router user agents, DECBODY1 Message Router body parts are used to transfer WordPerfect documents encapsulated in a fashion specific to Message Router. PMDF-MR can remove the encapsulation on such files, leaving a plain WordPerfect document that can be processed by applications expecting the normal WordPerfect format. Such documents are then encoded and sent as MIME application/wordperfect5.1 body parts. The CONVERT_WPCORP option specifies whether or not this conversion is done. A value of 1 enables conversion, a value of 0 disables it. A value of 2 flattens the file to text only. The default is 0. If DECBODY1 body parts are not converted they can either be retained in binary form or discarded; the ENCODE_BODYPARTS option described below controls this selection. Setting this option to a nonzero value also enables conversion of application/wordperfect5.1 objects into DECBODY1 attachments as messages flow from PMDF through PMDF-MR into Message Router. Newer versions of Message Router and Message Router user agents are likely to instead use DECBODY7 parts for WordPerfect documents, as for other binary attachments; see Section 39.2.6 for details on handling of WordPerfect attachments carried in DECBODY7 parts.

CONVERT_WPSPLUS (0-63)

The CONVERT_WPSPLUS option specifies whether or not WPS message body parts are left as WPSPLUS NBS attachments, converted to ASCII using the PMDF DCF utility, or converted to WPS file attachments (application/vnd.digital.wpsplus in MIME). This option also controls what PMDF-MR does to application/vnd.digital.wpsplus (or application/wpsplus) attachments going to Message Router. A description of the DCF utility is given in the instructions of Section 39.2.2 above. This value is bit-encoded integer. The bit assignments are as follows:
Bit Value Usage
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.
This option should not be set to an odd value unless the DCF utility is actually available. The default value is 1 on VAX or 2 on Alpha. If WPS body parts are left in NBS form they can either be retained in binary form or discarded; the ENCODE_BODYPARTS option described below controls this selection.

DELETE_HEADERS (0 or 1)

Message headers are normally deleted once they have been successfully mapped into corresponding Message Router information. The headers that remain after all conversions have been done can be saved using the SAVE_HEADERS option described below. However, under some circumstances it is useful to be able to skip the deletion step, preserving all header information. The DELETE_HEADERS option provides such a facility. Its normal default value is 1, which means that headers are deleted once converted. If this option is set to 0 converted headers will not be deleted. If the SAVE_HEADERS option is then set to 1, all headers will be saved as a separate text body part. If SAVE_HEADERS is set to 0, the DELETE_HEADERS option will have no discernable effect on message conversion.

DIRECTORY_DATABASE (file name)

Some Message Router agents restrict originator addresses on the messages they process to known subscribers registered in the DDS. In particular, the MR/S, MR/P, and MRX gateways cannot accommodate replies to unregistered addresses and hence are usually configured to return messages from unknown originators as undeliverable. Such restrictions are a serious problem in many environments. In particular, gateways between Message Router and the Internet (with its millions of subscriber addresses) are made problematic by this restriction. PMDF-MR therefore provides facilities to screen originator addresses against a database. Originator addresses not found in the database will be replaced with an address that is known to be valid. The result is that the message still cannot be replied to automatically but can nevertheless be delivered. (Various approaches can be used to reply to such messages manually --- for example, PMDF's addressing channel provides facilities for reading addressing information that is buried in message bodies; see Section 27.1.) The DIRECTORY_DATABASE option 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 CRDB utility. 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_ADDRESS option. 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_EXCEPTIONS option. The DIRECTORY_DATABASE option 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_EXCEPTIONS file is used to build new entries, the right hand side will be the original RFC 822 address.)

DIRECTORY_EXCEPTIONS (file name)

The DIRECTORY_EXCEPTIONS option is used in conjunction with the DIRECTORY_DATABASE option; see the description of DIRECTORY_DATABASE above. The DIRECTORY_EXCEPTIONS option 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_EXCEPTIONS option is not defined by default and hence unmatched entry reporting is disabled by default.

ENCODE_BODYPARTS (0 or 1)

The ENCODE_BODYPARTS option 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_DATABASE (string)

The FROM_MR_DATABASE option 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_DATABASE logical 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_AUTHOR (0 or 1)

The FROM_TO_AUTHOR option controls the optional copying of the Message Router FROM field to the AUTHOR field when no AUTHOR field is specified. RFC 2156 specifies that when both the RFC 822 From: and Sender: headers are present the From: header be mapped into the AUTHOR field while the Sender: header gets mapped to the FROM field, and if only a From: header is present it is mapped to the FROM field. The latter case causes problems with applications that incorrectly provide access to just the AUTHOR field. When set to 1, the FROM_TO_AUTHOR duplicates the FROM information in the AUTHOR field in an attempt to work around this problem. The default value is 0, which inhibits this duplication.

FROM_TO_REPLYTO (0, 1, or 2)

PMDF-MR normally converts between the RFC 822 Reply-to: header and the Message Router REPLYTOUSERS field. With some Message Router user agents, however, (such as some older versions of Teamlinks), it can in some cases (such as when both From: and Sender: RFC 822 header lines are present) be useful to propogate the From: RFC 822 header value into the Message Router REPLYTOUSERS field, if no RFC 822 Reply-to: is present. If FROM_TO_REPLYTO is set to 1, the From: value is copied to the Message Router REPLYTOUSERS field. If FROM_TO_REPLYTO is set to 2, then the From: value is copied to the REPLYTOUSERS field only if there was a non-empty Sender: value. By default, FROM_TO_REPLYTO=0, the From: value is not copied to the REPLYTOUSERS field.

NOTIFY (string)

The NOTIFY option 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.

PASSWORD (string)

In the case of an MR channel, 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 39.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.

RECIPIENT_BITS (integer)

This option controls which Message Router per recipient flags PMDF-MR sets for messages it sends, and which such flags PMDF-MR looks for in messages it receives. Bits 0, 1, 2, and 3 control the handling of the delivery receipt flags: bit 0 controls whether PMDF-MR sets the "delivery receipt requested by UA" flag; bit 1 controls whether PMDF-MR sets the "delivery receipt requested by MR" flag; bit 2 controls whether PMDF-MR looks for (delivery receipt requested by UA) flag; bit 3 controls whether PMDF-MR looks for the (delivery receipt requested by MR) flag. Bit 4 controls whether PMDF-MR sets the MR_BASIC flag. The default for MR channels is 5; the default for MRIF channels is 7. The MR flag values (from SYS$LIBRARY:MRIFDEFS.H) are: 


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_INVALID (0 or 1)

If the REJECT_INVALID option 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_HEADERS (integer)

The RESTORE_HEADERS option provides the inverse of the operation of the SAVE_HEADERS option described below. Specifically, if RESTORE_HEADERS is 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_HEADERS is 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=3 causes 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_HEADERS (0 or 1)

The SAVE_HEADERS option 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_ENVELOPE (0, 1, or 2)

The SCREEN_ENVELOPE option 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_ENVELOPE value 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_DEFAULT (string)

This option specifies a default subject line to add to messages when no subject line appears in the RFC 822 version of the message. Message Router requires that a subject line be present, and some Message Router gateways will not work properly if an empty line is used. RFC 822 does not share this restriction, so a default must be provided. This option provides a default subject line to use when the RFC 822 messages does not have one or has a blank 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_ADDRESS (RFC 822 address string)

The SUBSTITUTE_ADDRESS option is used in conjunction with the DIRECTORY_DATABASE option; see the description of DIRECTORY_DATABASE above. The SUBSTITUTE_ADDRESS option 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_DATABASE (string)

The TO_MR_DATABASE option 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_DATABASE logical 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_ATTRIBUTES (0, 1, or 2)

Message Router attribute values sometimes contain extraneous trailing space characters. The TRIM_ATTRIBUTES option 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.

Previous Next Contents Index