PMDF System Manager's Guide
PMDF-REF-6.0

This mapping of addresses from PMDF to Message Router consists of any number of rewrite rules, stored in a database as described above in Section 39.3 ,¹ ) and roughly parallels the rewriting process performed in the regular PMDF configuration file and domain database. There are notable differences, however:

• a. When an address is converted to Message Router format, the entire address must be converted, including all the routing information in it. Note that RFC 2156 recommends discarding all source routes from addresses before converting them. In general this strategy seems dubious for X.400 mail systems and it is totally inappropriate for Message Router addresses, where routes are the primary form of information and X.400 ORname information is secondary. PMDF-MR extracts each route from an address, starting with the outermost and proceeding to inner routes. Each route may match one or more rewrite rules, which in turn may contribute to the final Message Router address.
  
• b. The right hand side of the rewrite rules is constructed in the linear attribute-value pair list (AVPL) format recommended by RFC 2156. The general form is:

  /attribute1=value1/attribute2=value2/.../ 
  

  The attributes must be chosen from the following set (which conforms to the RFCs as far as possible):

  Table 39-2 Message Router attributes recognized by PMDF-MR

  Attribute name	Message Router component (MRIF$K_)
  ADMD	AMDNAME
  C	COUNTRY
  DD.name	DDNAME (DDTYPE/DDVALUE)
  FFN	FREEFORM
  G	GIVENNAME
  GQ	GENERATION
  I	INITIALS
  IDD.name	IDDNAME (DDTYPE/DDVALUE)
  L	LOCATION
  O	ORGNAME
  OU	ORGUNIT
  PN	encoded personal name (S/I/G)
  PRMD	PRDNAME
  R	ROUTE
  S	SURNAME
  TN	TELEPHONE
  T-ID	TERMINALID
  U	USERID
  UA-ID	UNIQUEUAID
  X121	X121ADDRESS

  Note that the non-X.400 ROUTE and USERID attributes are required by Message Router, which then treats the remaining attributes as optional!

• c. As the rewrite process proceeds it may be appropriate to bring different sets of rules into play. This is accomplished by the use of the rewrite rule tag. The current tag is prepended to each pattern before looking it up in the database. The tag can be changed by any rewrite rule that matches; simply place a $T in the template, followed by the new tag value.
• d. The extraction and interpretation of percent-hack and bang-style routing is controllable using additional state-setting metacharacter control sequences.
• e. Quoting appropriate to the process of inserting unknown text into attribute-value pair lists can be enabled or disabled. The quoting consists of prefixing all occurrences of = and / with a $. This quoting is specified in RFC 2156.
• f. A large number of special metacharacter control sequences are available to control template processing actions. These control sequences are shown in Table 39-3 .
• g. Some additional metacharacter control sequences which can be used in patterns (but not in templates) are shown in Table 39-4 .
• h. The mechanism embodied by this rewriting mechanism is capable of performing all the functions called for by RFC 2156, and many more besides.

  Table 39-3 PMDF to MR template processing control sequences

  Basic Substitutions
  Control
  sequence	Template processing action
  $D	Substitute the "domain" part of the host/domain specification that did match.
  $H	Substitute the "host" part of the host/domain specification that was not part of the match.
  $K	Insert the personal name specification that was part of the original RFC 822 address. The rewrite will fail if no personal name field was present in the original address.
  $(	Insert comment string. The rewrite fails if there is no associated comment string.
  $L	Substitute the contents of the domain literal specification.
  $U	Substitute mailbox/username part of the address.
  $ n	Insert the n th element, n =0,1,...,9, in the host specification (the part that did not match). Elements are separated by dots; the first element on the left is element zero. The rewrite fails if the requested element does not exist.
  $! n	Insert the n th element, n =0,1,...,9, in the host specification (the part that did not match). Elements are separated by dots; the first element on the right is element zero. The rewrite fails if the requested element does not exist.
  $* n	Insert the n th element, n =0,1,...,9 in the domain specification (the part that did match). Elements are separated by dots; the first element on the left is element zero. The rewrite fails if the requested element does not exist.
  $# n	Insert the n th element, n =0,1,...,9, in the domain specification (the part that did match). Elements are separated by dots; the first element on the right is element zero. The rewrite fails if the requested element does not exist.
  $W	Insert a unique string.
  Substitution processing
  Control
  sequence	Template processing action
  $A	Add all subsequent text from the current addition to the ORname being built by this rewrite.
  $E	Encode all subsequent attributes using the printable string encoding. The additions buffer is flushed.
  $I	Assume printable string encoding is implicit; do not do it. The additions buffer is flushed.
  $T text</code>	Use all subsequent text as a qualifying tag for all future database queries.
  $+	Perform quoting on all subsequent addition text.
  $-	Do not perform quoting on subsequent addition text.
  Lookups
  Control
  sequence	Template processing action
  $[[ ...]</code>	Invoke customer supplied routine; substitute in result. Three comma-separated arguments are required: The image, the routine in the image, and the argument to pass to the routine. See Section 2.2.6.7 for additional information. (The " [[ " is not an error; it really is two open square brackets.)
  ${ ...}</code>	Apply specified mapping to supplied string. Two comma-separated arguments are required: The name of the mapping and the argument to be mapped. See Section 2.2.6.6 for additional information.
  Mailbox processing
  Control
  sequence	Template processing action
  $B	Extract and rewrite system! components in the mailbox/username prior to interpretation.
  $N	Attempt to interpret the mailbox/username as a personal name.
  $O	Attempt to interpret the mailbox/username as a series of attributes and associated values.
  $P	Extract and rewrite % system components in the mailbox/username prior to interpretation.
  $Q	Attempt to find and rewrite the mailbox/username.
  $X	Block extraction of any information from the mailbox prior to interpretation.
  $Y	Block all interpretation of mailbox/usernames.
  Miscellaneous
  Control
  sequence	Template processing action
  $C	Clear any existing attributes and values set by previous processing.
  $F	Null substitution; always fails and kills this rewrite.
  $G	Force failure if backward is not set.
  $J	Force failure if backward is set.
  $S	Full substitution; always successful
  $V	Force failure if envelope is not set.
  $Z	Force failure if header is not set.
  $^ n	Set precedence flag for all subsequent additions. This flushes the additions buffer if the precedence is changed, so this flag may only appear between sections of an ORname string.

  Table 39-4 PMDF to MR pattern processing metacharacter control sequences

  Control
  sequence	Pattern processing action
  $D	Special rewrite called when rewriting fails and an RFC 822 address has to be encapsulated in an X.400 address.
  $E	Special rewrite called when an empty address is presented.
  $H	Generic match-all host rule, applied if the current host fails to match when all component domains have been tried (and have failed). This applies to hosts broken out of source routes, percent-hack routes, and bang-style routes.
  $I	Initial rewrite, applied once the address has parsed successfully.
  $M	Special rewrite called before mailbox rewriting is initiated.
  $P	Special rewrite called when the $D or $E rule is called and fails.
  $U	Generic match-all rule tried when mailbox is being rewritten and fails to match anything else.

  ---

  Note

  ¹ For MR channels, this database is usually PMDF_TABLE:to_mr.dat, and has usually been constructed by the PMDF CONFIGURE MR utility from a file it also generated called PMDF_TABLE:to_mr.txt; for MRIF channels, this database is usually PMDF_TABLE:to_mrif.dat, and has usually been constructed by the PMDF CONFIGURE MR utility from a file it also generated called PMDF_TABLE:to_mrif.txt.

  ---

  ---

  Previous | Next | Contents