DSN language and customization

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

As mentioned in the discussion of the sample DSN of Example non-delivery DSN, there are a number of localizable, customizable files consulted when constructing DSNs; these files will be discussed further in Customizing DSNs via the return files. By default, if no NOTIFICATION_LANGUAGE mapping table is configured, the return_*.* files located in the IMTA_LANG: directory will be used to generate all DSNs. However, separate sets of return_*.* files can be created and located in separate directories---for localization or site customization purposes. Indeed, the MTA is distributed with several sets of language-specific return_*.* files, and a basic NOTIFICATION_LANGUAGE mapping table (referenced in the mappings file via file inclusion of the mappings.locale file) which selects among the language-specific directories based on language preference of original message senders. That is, the NOTIFICATION_LANGUAGE mapping table selects, based on any language preference of the original message sender, a directory in which to find an appropriate set of return_*.* files for generating a DSN back to that sender.

Probes to the NOTIFICATION_LANGUAGE mapping table have the form:


In the probe, dsn-type can be a comma-separated list including any of failed, bounced, timedout, delayed, deferred, delivered, read, relayed, expanded, capture, error, or (as of MS 7.0u2) journal. The accept-language field will have any values (possibly a comma-separated list) found on (preferentially) an Accept-Language: header line in the original message (the message that the DSN will be reporting on), or if that header line is not present then from a Preferred-language: header line if present, or failing that an X-Accept-Language: header line. Note that valid language tag values are discussed in RFC 3066 (Tags for the Identification of Languages).

The pattern (right hand side) of a NOTIFICATION_LANGUAGE entry may set the $I flag to specify the directory (or as of MS 7.0 update 3, a list of comma-separated directories) from which the MTA should use return_*.* files when constructing a DSN. It may also optionally set the $T flag to set an override Subject: header field value to use in the DSN. Note that the default Subject: field values for the various types of DSNs are shown in Table of DSN types and their default Subject: field text. When both flags are set, the directory argument should be first (left-most), separated by a vertical bar character from the Subject: header field.

Note: If using NOTIFICATION_LANGUAGE to select an alternate directory of return_*.txt regardless of DSN type, then it is important to have a complete set of return_*.txt files present in the specified directory. If the MTA cannot locate a return_*.txt file of the appropriate type in the directory in which the MTA has been told to find such files, then the DSN will be constructed omitting that part of the usual structure and the resulting DSN will therefore look "odd" or "incomplete".

Note: When the MTA has been configured to send copies of notifications to the postmaster (see for instance the sendpost and warnpost channel options), those postmaster copies of the notification message back to the original sender are copies of the text sent back to the original sender, and in particular are in the language selected for the original sender. The postmaster's own personal language preferences, if any, are not relevant to these copies; the purpose of these copies being to be a copy of what the original sender was sent.

See also: