| Previous | Contents | Index |
The options described in this section affect and modify various aspects of PMDF address, alias, and rewriting handling, and the information placed in certain sorts of headers.
ALIAS_DOMAINS (integer)
This option takes a bit encoded integer argument controlling the format of alias file and alias database lookups. The default value is 1, meaning that alias file and alias database lookups probe with only the local part (mailbox portion) of the address. Note that for addresses matching the local channel, such a probe is made even if bit 0 (value 1) is not set. Setting bit 1 (value 2) causes a probe to be made using the entire address (including the domain name). Setting bit 2 (value 4) causes a wildcard * probe to be made, (akin to the sort of wildcard * probe made when doing a directory channelcrdblookup). If all bits are set, i.e., ALIAS_DOMAINS=7, then the order of the probes is to first probe with the entire address (the most specific check), next probe with a wildcard * local part plus the domain name, and finally probe with just the local part.
Bit Value Usage 0 1 Look up localpart. Clearing this bit disables the lookup of local parts only for channels other than the local channel; for the local channel, local parts are always looked up. 1 2 Look up localpart@ domainname. 2 4 Try an *lookup if no exact match is found.
aliaslocal channel keyword it is possible to cause
addresses matching other channels to be checked against the alias file
and alias database.
exproute
channel keyword to forward-pointing (To:, Cc:, and Bcc: lines)
addresses in the message header. A value of 1 is the default and
specifies that exproute should affect forward-pointing
header addresses. A value of 0 disables the action of the
exproute keyword on forward-pointing addresses.
improute
channel keyword to forward-pointing (To:, Cc:, and Bcc: lines)
addresses in the message header. A value of 1 is the default and
specifies that improute should affect forward-pointing
header addresses. A value of 0 disables the action of the
improute keyword on forward-pointing addresses.
NOMAIL.
inline channel keyword is used on the directory channel.
To:, Cc:, or
Bcc: header. This RFC states that a message without any
such headers is illegal. This requirement has been relaxed in the
updated RFC 2822 standard: such messages are no longer illegal.
However, some remote systems that conform to RFC 822 will not accept
these messages. In many cases, it can be useful to have PMDF modify the
message to include at least one recipient header. The
MISSING_RECIPIENT_POLICY option takes an integer value specifying what
approach to use for such messages; the default value, if the option is
not explicitly present, is 1, meaning that no action is taken.
| Value | Action |
|---|---|
| 1 | Pass the message through unchanged |
| 2 | Place envelope To: recipients in a To: header |
| 3 | Place all envelope To: recipients in a single Bcc: header |
| 4 | Generate an empty group construct To: header (i.e. "To: Recipients not specified: ;") |
| 5 | Generate a blank Bcc: header |
| 6 | Reject the message |
missingrecipientpolicy channel keyword,
discussed in Section 2.3.4.48, can be used to set per-channel controls
for this sort of behavior.
Content-disposition header to a message or message part
when PMDF parses out and re-assembles the MIME parts of a message. PMDF
can be configured to do this in several ways, for example, by using the
inner or innertrim channel keywords, or by
using the CHARSET-CONVERSION mapping table.
Normally, when parsing the MIME part headers, if PMDF finds a
name parameter in the Content-type header, it
will add a Content-disposition header with a
filename parameter. This appears to cause problems with
messages generated by Outlook Calendar, with message parts that are of
type text/calendar and do not have a Content-disposition
header. The generation of this header by PMDF can be suppressed by
specifing the SUPPRESS_CONTENT_DISP option. A value of 1 always
suppresses the generation of a Content-disposition header, and a value
of 2 suppresses the generation of the Content-disposition header only
for text/calendar message parts.
| Bit | Value | Usage |
|---|---|---|
| 0 | 1 | When set, the forward database is used. |
| 3 | 8 |
When set, channel-level granularity is used with the forward database
entries. Forward database entries' left hand sides must have the form
(note the vertical bars, |)
source-channel| from-address| to-address |
| 4 | 16 |
When set, channel-level granularity is used with the FORWARD mapping.
FORWARD mapping entries' patterns (left hand sides) must have the form
(note the vertical bars, |)
source-channel| from-address| to-address |
| Bit | Value | Usage |
|---|---|---|
| 0 | 1 | When set, address reversal is applied to addresses after they have been rewritten by the PMDF address rewriting process. |
| 1 | 2 | When set, address reversal is applied before addresses have had PMDF address rewriting applied to them. |
| 2 | 4 | When set, address reversal will be applied to all addresses, not just to backwards-pointing addresses. |
| 3 | 8 |
When set, channel-level granularity is used with the REVERSE mapping.
REVERSE mapping table (pattern) entries must have the form (note the
vertical bars, |)
source-channel| destination-channel| address |
| 4 | 16 |
When set, channel-level granularity is used with address reversal
database entries. Reversal database entries' left hand sides must have
the form (note the vertical bars, |)
source-channel| destination-channel| address |
| 5 | 32 | Apply REVERSE mapping even if a reverse database entry has already matched. |
| 6 | 64 | Apply address reversal to message ids. |
| 7 | 128 |
When set, this modifies the effect of bit 4 (channel-level granularity
of address reversal database entries); when this bit is also set, the
address reversal database entries take the form (note the vertical
bars, |)
destination-channel| address |
| 8 | 256 |
When set, this modifies the effect of bit 3 (channel-level granularity
of REVERSE mapping table entries); when this bit is also set, the
REVERSE mapping table entries take the form (note the vertical bars, |)
destination-channel| address |
| Previous | Next | Contents | Index |