12.6 Configuring Address Handling
This section describes keywords that deal with address handling. It consists of the following sections:
-
12.6.6 Specifying a Host Name to Use When Correcting Incomplete Addresses
-
12.6.9 Enabling Channel-Specific Use of the Reverse Database
-
12.6.12 Constructing Received Header Lines from Envelope To and From Addresses
12.6.1 Address Types and Conventions
Keywords: 822, 733, uucp, header_822, header_733, header_uucp
This group of keywords control what types of addresses the channel supports. A distinction is made between the addresses used in the transport layer (the message envelope) and those used in message headers.
12.6.1.1 822 (sourceroute)
Source route envelope addresses. This channel supports full RFC 822 format envelope addressing conventions including source routes. The keyword sourceroute is also available as a synonym for 822. This is the default if no other envelope address type keyword is specified.
12.6.1.2 733 (percents)
Percent sign envelope addresses. This channel supports full RFC 822 format envelope addressing with the exception of source routes; source routes should be rewritten using percent sign conventions instead. The keyword percents is also available as a synonym for 733.
Note –
Use of 733 address conventions on an SMTP channel results in these conventions being carried over to the transport layer addresses in the SMTP envelope. This may violate RFC 821. Only use 733 address conventions when you are sure they are necessary.
12.6.1.3 uucp (bangstyle)
Bang-style envelope addresses. This channel uses addresses that conform to RFC 976 bang-style address conventions in the envelope (for example, this is a UUCP channel). The keyword bangstyle is also available as a synonym for uucp.
12.6.1.4 header_822
Source route header addresses. This channel supports full RFC 822 format header addressing conventions including source routes. This is the default if no other header address type keyword is specified.
12.6.1.5 header_733
Percent sign header addresses. This channel supports RFC 822 format header addressing with the exception of source routes; source routes should be rewritten using percent sign conventions instead.
Note –
Use of 733 address conventions in message headers may violate RFC 822 and RFC 976. Only use this keyword if you are sure that the channel connects to a system that cannot deal with source route addresses.
12.6.1.6 header_uucp
UUCP or bang-style header addresses. The use of this keyword is not recommended. Such usage violates RFC 976.
12.6.2 Interpreting Addresses that Use ! and %
Keywords: bangoverpercent, nobangoverpercent, percentonly
Addresses are always interpreted in accordance with RFC 822 and RFC 976. However, there are ambiguities in the treatment of certain composite addresses that are not addressed by these standards. In particular, an address of the form A!B%C can be interpreted as either:
-
A as the routing host and C as the final destination host
or
-
C as the routing host and A as the final destination host
While RFC 976 implies that mailers can interpret addresses using the latter set of conventions, it does not say that such an interpretation is required. Some situations may be better served by the former interpretation.
The bangoverpercent keyword forces the former A!(B%C) interpretation. The nobangoverpercent keyword forces the latter (A!B)%C interpretation. nobangoverpercent is the default.
Note –
This keyword does not affect the treatment of addresses of the form A!B@C. These addresses are always treated as (A!B)@C. Such treatment is mandated by both RFC 822 and RFC 976.
The percentonly keyword ignores bang paths. When this keyword is set, percents are interpreted for routing.
12.6.3 Adding Routing Information in Addresses
Keywords: exproute, noexproute, improute, noimproute
The addressing model that the MTA deals with assumes that all systems are aware of the addresses of all other systems and how to get to them. Unfortunately, this ideal is not possible in all cases, such as when a channel connects to one or more systems that are not known to the rest of the world (for example, internal machines on a private TCP/IP network). Addresses for systems on this channel may not be legal on remote systems outside of the site. If you want to be able to reply to such addresses, they must contain a source route that tells remote systems to route messages through the local machine. The local machine can then (automatically) route the messages to these machines.
The exproute keyword (short for “explicit routing“) tells the MTA that the associated channel requires explicit routing when its addresses are passed on to remote systems. If this keyword is specified on a channel, the MTA adds routing information containing the name of the local system (or the current alias for the local system) to all header addresses and all envelope From: addresses that match the channel. noexproute, the default, specifies that no routing information should be added.
The EXPROUTE_FORWARD option can be used to restrict the action of exproute to backward-pointing addresses. Another scenario occurs when the MTA connects to a system through a channel that cannot perform proper routing for itself. In this case, all addresses associated with other channels need to have routing indicated when they are used in mail sent to the channel that connects to the incapable system.
Implicit routing and the improute keyword is used to handle this situation. The MTA knows that all addresses matching other channels need routing when they are used in mail sent to a channel marked improute. The default, noimproute, specifies that no routing information should be added to addresses in messages going out on the specified channel. The IMPROUTE_FORWARD option can be used to restrict the action of improute to backward-pointing addresses.
The exproute and improute keywords should be used sparingly. They make addresses longer, more complex, and may defeat intelligent routing schemes used by other systems. Explicit and implicit routing should not be confused with specified routes. Specified routes are used to insert routing information from rewrite rules into addresses. This is activated by the special A@B@C rewrite rule template.
Specified routes, when activated, apply to all addresses, both in the header and the envelope. Specified routes are activated by particular rewrite rules and as such are usually independent of the channel currently in use. Explicit and implicit routing, on the other hand, are controlled on a per-channel basis and the route address inserted is always the local system.
12.6.4 Disabling Rewriting of Explicit Routing Addresses
The routelocal channel keyword causes the MTA, when rewriting an address to the channel, to attempt to “short circuit” any explicit routing in the address. Explicitly routed addresses (using !, %, or @ characters) are simplified.
Use of this keyword on “internal” channels, such as internal TCP/IP channels, can allow simpler configuration of SMTP relay blocking.
Note that this keyword should not be used on channels that may require explicit % or other routing.
12.6.5 Address Rewriting Upon Message Dequeue
Keywords: connectalias, connectcanonical
The MTA normally rewrites addresses as it enqueues messages to its channel queues. No additional rewriting is performed during message dequeue. This presents a potential problem when host names change while there are messages in the channel queues still addressed to the old name.
The connectalias keyword tells the MTA to deliver to whatever host is listed in the recipient address. This is the default. The keyword connectcanonical tells the MTA to connect to the host alias for the system that to which the MTA would be connected.
12.6.6 Specifying a Host Name to Use When Correcting Incomplete Addresses
Keywords: remotehost, noremotehost, defaulthost, nodefaulthost
The MTA often receives addresses that do not contain domain names from misconfigured or incompliant mailers and SMTP clients. The MTA attempts to make such addresses legal before allowing them to pass further. The MTA does this by appending a domain name to the address (for example, appends @siroe.com to mrochek).
For envelope To: addresses missing a domain name, the MTA always assumes that the local host name should be appended. However for other addresses, such as From: addresses, in the case of the MTA SMTP server there are at least two reasonable choices for the domain name: the local MTA host name and the remote host name reported by the client SMTP. Or in some cases, there may be yet a third reasonable choice—a particular domain name to add to messages coming in that channel. Now, either of these two first choices are likely to be correct as both may occur operationally with some frequency. The use of the remote host’s domain name is appropriate when dealing with improperly configured SMTP clients. The use of the local host’s domain name may be appropriate when dealing with a lightweight remote mail client such as a POP or IMAP client that uses SMTP to post messages. Or if lightweight remote mail clients such as POP or IMAP, clients should have their own specific domain name which is not that of the local host. Then add that specific other domain name may be appropriate. The best that the MTA can do is to allow the choice to be made on a channel by channel basis.
The noremotehost channel keyword specifies that the local host’s name should be used. The keyword noremotehost is the default.
The defaulthost channel keyword is used to specify a particular host name to append to incoming bare user id’s. It must be followed by the domain name to use in completing addresses (in envelope From: and in headers) that come into that channel. (In the case of submit channels, the defaulthost keyword’s first argument also affects bare envelope To: addresses.) An optional second domain name (that has at least one period in it) may be specified to use in completing envelope To: addresses. nodefaulthost is the default.
The switchchannel keyword as described, in the preceding section, 12.4.3.8 Alternate Channels for Incoming Mail (Switch Channels) associate incoming SMTP connections with a particular channel. This facility can be used to group remote mail clients on a channel where they can receive proper treatment. Alternatively, it is simpler to deploy standards-compliant remote mail clients (even if a multitude of noncompliant clients are in use) rather than attempting to fix the network-wide problem on your MTA hosts.
12.6.7 Legalizing Messages Without Recipient Header Lines
Keywords: missingrecipientpolicy
RFC 822 (Internet) messages are required to contain recipient header lines: To:, Cc:, or Bcc: header lines. A message without such header lines is illegal. Nevertheless, some broken user agents and mailers (for example, many older versions of sendmail) emit illegal messages.
The missingrecipientpolicy keyword takes an integer value specifying the approach to use for such messages; the default value, if the keyword is not explicitly present, is 1 (pass the illegal message through unchanged).
Table 12–25 missingrecipientpolicy Values|
Value |
Action |
|---|---|
|
0 |
Use the current best practice per RFC 2822 recommendation. This is currently equivalent to value 1.. |
|
1 |
Pass the illegal message through unchanged. |
|
2 |
Place envelope To: recipients in a To: header line. |
|
3 |
Place all envelope To: recipients in a single Bcc: header line. |
|
4 |
Generate a group construct (for example, “;”) To: header line, “To: Recipients not specified: ;” |
|
5 |
Generate a blank Bcc: header line. |
|
6 |
Reject the message. |
Note that the MISSING_RECIPIENT_POLICY option can be used to set an MTA system default for this behavior. The initial Messaging Server configuration sets MISSING_RECIPIENT_POLICY to 1.
12.6.8 Stripping Illegal Blank Recipient Headers
Keywords: dropblank, nodropblank
In RFC 822 (Internet) messages, any To:, Resent-To:, Cc:, or Resent-Cc: header is required to contain at least one address—such a header may not have a blank value. Nevertheless, some mailers may emit such illegal headers. The dropblank channel keyword, if specified on a source channel, causes the MTA to strip any such illegal blank headers from incoming messages.
12.6.9 Enabling Channel-Specific Use of the Reverse Database
The reverse keyword tells the MTA that addresses in messages queued to the channel should be checked against, and possibly modified, by the address reversal database or REVERSE mapping, if either exists. noreverse exempts addresses in messages queued to the channel from address reversal processing. The reverse keyword is the default. Refer to 10.9 To Convert Addresses from an Internal Form to a Public Form
12.6.10 Enabling Restricted Mailbox Encoding
Keywords: restricted, unrestricted
Some mail systems have difficulty dealing with the full spectrum of addresses allowed by RFC 822. A particularly common example of this is sendmail-based mailers with incorrect configuration files. Quoted local-parts (or mailbox specifications) are a frequent source of trouble:
"smith, ned"@siroe.com
This is such a major source of difficulty that a methodology was laid out in RFC 1137 to work around the problem. The basic approach is to remove quoting from the address, then apply a translation that maps the characters requiring quoting into characters allowed in an atom (see RFC 822 for a definition of an atom as it is used here). For example, the preceding address would become:
smith#m#_ned@siroe.com
The restricted channel keyword tells the MTA that the channel connects to mail systems that require this encoding. The MTA then encodes quoted local-parts in both header and envelope addresses as messages are written to the channel. Incoming addresses on the channel are decoded automatically. The unrestricted keyword tells the MTA not to perform RFC 1137 encoding and decoding. The keyword unrestricted is the default.
Note –
The restricted keyword should be applied to the channel that connects to systems unable to accept quoted local-parts. It should not be applied to the channels that actually generate the quoted local-parts. (It is assumed that a channel capable of generating such an address is also capable of handling such an address.)
12.6.11 Generating of Return-path Header Lines
Keywords: addreturnpath, noaddreturnpath
Normally, adding the Return-path: header line is the responsibility of a channel performing a final delivery. But for some channels, like the ims-ms channel, it is more efficient for the MTA to add the Return-path: header rather than allowing the channel to perform add it. The addreturnpath keyword causes the MTA to add a Return-path: header when enqueuing to this channel.
12.6.12 Constructing Received Header Lines from Envelope To and From Addresses
Keywords: receivedfor, noreceivedfor, receivedfrom, noreceivedfrom
The receivedfor keyword instructs the MTA that if a message is addressed to just one envelope recipient, to include that envelope To: address in the Received: header line it constructs. The keyword receivedfor is the default. The noreceivedfor keyword instructs the MTA to construct Received: header lines without including any envelope addressee information.
The receivedfrom keyword instructs the MTA to include the original envelope From: address when constructing a Received: header line for an incoming message if the MTA has changed the envelope From: address due to, for example, certain sorts of mailing list expansions. receivedfrom is the default. The noreceivedfrom keyword instructs the MTA to construct Received: header lines without including the original envelope From: address.
12.6.13 Handling Comments in Address Header Lines
Keywords: commentinc, commentmap commentomit, commentstrip, commenttotal, sourcecommentinc, sourcecommentmap, sourcecommentomit, sourcecommentstrip, sourcecommenttotal
The MTA interprets the contents of header lines only when necessary. However, all registered header lines containing addresses must be parsed to rewrite and eliminate short form addresses and otherwise convert them to legal addresses. During this process, comments (strings enclosed in parentheses) are extracted and may be modified or excluded when the header line is rebuilt.
This behavior is controlled by the use of the commentinc, commentmap, commentomit, commentstrip, and commenttotalkeywords. The commentinc keyword tells the MTA to retain comments in header lines. It is the default. The keyword commentomit tells the MTA to remove any comments from addressing headers, for example, To:, From:, or Cc: header lines.
The keyword commenttotal tells the MTA to remove any comments from all header lines, except Received: header lines; this keyword is not normally useful or recommended. commentstrip tells the MTA to strip any nonatomic characters from all comment fields. The commentmap keyword runs comment strings through the COMMENT_STRINGS mapping table.
On source channels, this behavior is controlled by the use of the sourcecommentinc, sourcecommentmap, sourcecommentomit, sourcecommentstrip, and sourcecommenttotal keywords. The sourcecommentinc keyword indicates to the MTA to retain comments in header lines. It is the default. The sourcecommentomit keyword indicates to the MTA to remove any comments from addressing headers, for example, To:, From:, and Cc: headers. The sourcecommenttotal keyword indicates to the MTA to remove any comments from all headers, except Received: headers; as such, this keyword is not normally useful or recommended. And finally, the sourcecommentstrip keyword indicates to the MTA to strip any nonatomic characters from all comment fields. The sourcecommentmap keyword runs comment strings through source channels.
These keywords can be applied to any channel.
The syntax for the COMMENT_STRINGS mapping table is as follows:
(comment_text) | address
If the entry template sets the $Y flag, the original comment is replaced with the specified text (which should include the enclosing parentheses).
12.6.14 Handling Personal Names in Address Header Lines
Keywords: personalinc, personalmap, personalomit, personalstrip, sourcepersonalinc, sourcepersonalmap, sourcepersonalomit, sourcepersonalstrip
During the rewriting process, all header lines containing addresses must be parsed in order to rewrite and eliminate short form addresses and otherwise convert them to legal addresses. During this process personal names (strings preceding angle-bracket-delimited addresses) are extracted and can be optionally modified or excluded when the header line is rebuilt.
This behavior is controlled by the use of the personalinc, personalmap, personalomit, and personalstrip keywords. The keyword personalinc tells the MTA to retain personal names in the headers. It is the default. The keyword personalomit tells the MTA to remove all personal names. The keyword personalstrip tells the MTA to strip any nonatomic characters from all personal name fields. The personalmap keyword indicates to the MTA to run the personal names through the PERSONAL_NAMES mapping table.
On source channels, this behavior is controlled by the use of a sourcepersonalinc, sourcepersonalmap, sourcepersonalomit, or sourcepersonalstrip keyword. The sourcepersonalinc keyword indicates to the MTA to retain personal names in the headers. It is the default. The sourcepersonalomit keyword indicates to the MTA to remove all personal names. And finally, the sourcepersonalstrip indicates to the MTA to strip any nonatomic characters from all personal name fields. The sourcepersonalmap keyword indicates to the MTA to run the personal names through source channels.
These keywords can be applied to any channel. If the PERSONAL_NAMES mapping table returns 8-bit characters, they are UTF-8 encoded.
The syntax of the PERSONAL_NAMES mapping table probes is:
personal_name | address
If the template sets the $Y flag, the original personal name is replaced with the specified text.
12.6.15 Specifying Alias File and Alias Database Probes
Normally only addresses rewritten to the local channel (that is, the l channel on UNIX) are looked up in the alias file and alias database. The aliaslocal keyword may be placed on a channel to cause addresses rewritten to that channel to be looked up in the alias file and alias database also. The exact form of the lookup probes that are made is then controlled by the ALIAS_DOMAINS option.
12.6.16 Subaddress Handling
Keywords: subaddressexact, subaddressrelaxed, subaddresswild
As background regarding the concept of subaddresses, the native and ims-ms channels interpret a + character in the local portion of an address (the mailbox portion) specially: in an address of the form name+subaddress@domain the MTA considers the portion of the mailbox after the plus character a subaddress. The native channel treats a subaddress as additional cosmetic information and actually deliver to the account name, without regard to the subaddress; the ims-ms channel interprets the subaddress as the folder name to which to deliver.
Subaddresses also affect the lookup of aliases by the local channel (that is, the L channel on UNIX) and the lookup of aliases by any channel marked with the aliaslocal keyword, and the lookup of mailboxes by the directory channel. The exact handling of subaddresses for such matching is configurable: when comparing an address against an entry, the MTA always first checks the entire mailbox including the subaddress for an exact match; whether or not the MTA performs additional checks after that is configurable.
The subaddressexact keyword instructs the MTA to perform no special subaddress handling during entry matching; the entire mailbox, including the subaddress, must match an entry in order for the alias to be considered to match. No additional comparisons (in particular, no wildcard comparisons or comparisons with the subaddress removed) are performed. The subaddresswild keyword instructs the MTA that after looking for an exact match including the entire subaddress, the MTA should next look for an entry of the form name+*. The subaddressrelaxed keyword instructs the MTA that after looking for an exact match and then a match of the form name+*, that the MTA should make one additional check for a match on just the name portion. With subaddressrelaxed, an alias entry of the following form matches either name or name+subaddress, transforming a plain name to newname, and transforming name+subaddress to newname+subaddress. The subaddressrelaxed keyword is the default.
name: newname+*
Thus the subaddresswild keyword or the subaddressrelaxed keyword may be useful when aliases or a directory channel are in use yet users wish to receive mail addressed using arbitrary subaddresses. These keywords obviate the need for a separate entry for every single subaddress variant on an address.
Note that these keywords only make sense for the local channel (that is, the L channel on UNIX) and the directory channel, or any channel marked with the aliaslocal keyword.
Standard Messaging Server configurations relay upon the L channel indeed having subaddressrelaxed behavior (the default, when other keywords have not been explicitly used).
12.6.17 Enabling Channel-specific Rewrite Rules Checks
The rules keyword tells the MTA to enforce channel-specific rewrite rule checks for this channel. This is the default. The norules keyword tells the MTA not to check for this channel. These two keywords are usually used for debugging and are rarely used in actual applications.
12.6.18 Removing Source Routes
The dequeue_removeroute keyword removes source routes from envelope To: addresses as messages are dequeued. This keyword is currently only implemented on tcp-* channels. It is useful for transferring messages to systems that do not handle source routes correctly.
12.6.19 Specifying Address Must be from an Alias
Keywords: viaaliasoptional, viaaliasrequired
viaaliasrequired specifies that any final recipient address that matches the channel must be produced by an alias. A final recipient address refers to the match after alias expansion (if relevant) has been performed. The address cannot be handed directly to the MTA as a recipient address; that is, it is not sufficient for an address to merely rewrite to the channel. After rewriting to the channel, an address must also expand through an alias to be considered to have truly matched the channel.
The viaaliasrequired keyword may be used, for example, on the local channel to prevent delivery to arbitrary accounts (such as arbitrary native Berkeley mailboxes on a UNIX system).
The default is viaaliasoptional, which means that the final recipient addresses that match the channel are not required to be produced by an alias.
12.6.20 Recipient Address Handling
Keywords: acceptalladdresses, acceptvalidaddresses
acceptvalidaddresses is the default and corresponds to the MTA's standard behavior where any recipient errors are reported immediately during the SMTP dialogue. If the keyword acceptalladdresses is specified on a channel, then all recipient addresses are accepted during the SMTP dialogue. Any invalid addresses will have a DSN sent later.
- © 2010, Oracle Corporation and/or its affiliates