RFC 822 comment strings and personal name modification

While not strictly an issue of address reversal, a related topic is  that of modifying the RFC 822 phrase (more commonly referred to as a  "personal name") or RFC 822 comment that may appear  associated with an address in a header line. Phrases appear, possibly quoted depending on the contents, before a format address specification  (where the address specification is enclosed in angle brackets);  comments are text appearing within parentheses. For instance, in "John Q. Doe" &#x3c;John.Doe@acme.com&#x3e; (V.P. of Widget Development) the  is an RFC 822 phrase, that is, personal  name, and the   is a comment.

The MTA only interprets the contents of header lines when necessary. However, all registered headers containing addresses must be parsed in order to rewrite and eliminate shortform addresses and otherwise  convert them to legal addresses. During this process personal names (strings preceding angle-bracket-delimited addresses) and comment  strings (strings enclosed in parentheses) are extracted and may  optionally be modified or excluded when the header line is rebuilt.

In direct LDAP mode, the LDAP attribute named by the    MTA option if present, will be used as the personal name in an address. (Note that any eight bit characters in the value will be assumed to be UTF-8 and be encoded as such.) The MTA will quote, if appropriate, the  personal name value obtained from LDAP, according to RFC 822 rules for  such quoting; implemented as of MS 6.2 for normal messages, or as  of MS 6.2p6 when generating messages such as vacation messages.

There are a number of channel options controlling the MTA&#x27;s optional removal or modification of personal names and comment strings. This section will talk in detail about the  ,   ,   , and    channel  options used for triggering general,  mapping table based modifications to such strings; see the    channel options  and the   channel options for a complete list of additional options including  channel options appropriate when you simply wish to strip off all such strings.

When the  keyword is present on a destination  channel, then the MTA will run any personal names appearing associated  with addresses in addressing header lines (e.g.,, To:, Cc:,  etc., sorts of header lines) and message id header lines  through a   mapping table, if such a table exists. This is performed after any  address reversal. If no such table exists, then   is equivalent to  ;  see the   channel option. The  keyword acts  analogously for header lines on incoming messages; that is, it applies  to source channels. The probe to the  mapping table by default takes the form personal-name&#x7c;address or if (new in MS 6.1) the MTA option   is set, then the probe takes the form source-channel&#x7c;destination-channel&#x7c;personal-name&#x7c;address If the probe matches a mapping entry, the result of the mapping is tested. The resulting string will replace the personal name if the entry specifies a  ; a   will discard the  result of the mapping. Note that any eight bit values in the result will be assumed to be in the UTF-8 charset, and encoded as such. As of MS 6.2p3, the MTA will quote the result of the mapping, if  appropriate according to the personal name quoting rules specified in  RFC 822. See Table of PERSONAL_NAMES mapping table flags for a  description of additional flags  available for the   mapping, and  Mapping template substitutions and metacharacters  for a list  of general mapping table substitution sequences and metacharacters.

An example of a  mapping table, used in conjunction with    on an appropriate channel, to cause addition  of the   LDAP attribute&#x27;s value as a personal name only  when no personal name was already present on an address would be: PERSONAL_NAMES ! If a personal name is already present, use it as-is !   %&#x2a;&#x7c;&#x2a;    $N ! ! When no personal name is already present, look up the ! domain in the address and determine whether it is one ! of "ours": !   &#x7c;&#x2a;@&#x2a;   $CBDN&#x7c;$0@$1&#x7c;$}$1,_base_dn_{ ! ! If the domain was found, we&#x27;re now probing with ! BDN&#x7c;address&#x7c;base-DN-for-users !   BDN&#x7c;&#x2a;&#x7c;&#x2a;   \ $C$&#x5d;ldap:///$1?cn?sub?(&#x7c;(mail=$=$0$_)(mailEquivalentAddress=$=$0$_))&#x5b;$Y$E When the   channel option  is present on a destination  channel, then the MTA will run any comment strings appearing associated  with addresses in addressing header lines (e.g.,, To:, Cc:,  etc., sorts of header lines) and message id header lines  through a   mapping table, if such a table exists. This is performed after any address reversal. If no such table exists, then   is equivalent to  ; see  the   channel options. The  channnel option acts  analogously for header lines on incoming messages; that is, it applies  to source channels. The probe to the  mapping table by  default takes the form comment-string&#x7c;address or if (new in MS 6.1) the MTA option   is set,  then the probe takes the form source-channel&#x7c;destination-channel&#x7c;comment-string&#x7c;address If the probe matches a mapping entry, the result of the mapping is tested. The resulting string (which should include enclosing parentheses) will replace the comment string if the entry specifies a   ; a   will discard the result of the  mapping. See Table of COMMENT_STRINGS mapping flags  for a description of additional flags  available for the   mapping, and  Mapping template substitutions and metacharacters  for a  list of general mapping table substitution sequences and metacharacters.

When thinking about personal names and comment strings in address header lines, note that as of 7.5 the MTA supports private modifiers to the Sieve " " test,  " " and " ", to access  the personal name and comment string, respectively.

See also:
 * commentmap Option
 * sourcecommentmap Option
 * personalmap Option
 * sourcepersonalmap Option
 * use_comment_strings MTA Option
 * use_personal_names MTA Option
 * ldap_personal_name MTA Option
 * fullfromheader Option
 * Sieve address test
 * Address reversal
 * Mapping entry templates
 * Pre-defined mapping tables