Previous Contents Index Next |
iPlanet Messaging Server 5.2 Reference Manual |
Chapter 5 MTA Configuration
The following topics are covered in this chapter:
MTA Configuration File
The MTA Configuration Files
This section explains the structure and layout of the MTA configuration files. Some configuration modifications are performed by using the command-line interface, as described in Chapter 2 "Message Transfer Agent Command-line Utilities." Modifications not possible through the command line are performed by editing the configuration files. We recommend that only experienced administrators edit and modify the configuration files.
All configuration files are ASCII text files that are created or changed with any text editor. Permissions for the configuration file should be set to world-readable. Failure to make configuration files world-readable may cause unexpected MTA failures. A physical line in most files is limited to 252 characters and you can split a logical line into multiple physical lines using the backslash (\) continuation character.
Table 5-1 lists the MTA configuration files with a short description.
Table 5-1    MTA Configuration files
File
Description
Specifies options used by the autoreply program. server_root/msg-instance/imta/config/autoreply_option
Alias File (mandatory)
Implements aliases not present in the directory. server_root/msg-instance/imta/config/aliases
Sets channel specific options. server_root/msg-instance/imta/config/channel_option
Used by conversion channel to control message body part conversions. server_root/msg-instance/imta/config/conversions
Dirsync Option File (mandatory only if running in dirsync mode)
Specifies options used by the dirsync program. server_root/msg-instance/imta/config/dirsync.opt
Dispatcher Configuration File (mandatory)
Specifies configuration file options for the service dispatcher. server_root/msg-instance/imta/config/dispatcher.cnf
Job Controller Configuration File (mandatory)
Defines Job Controller options server_root/msg-instance/imta/config/job_controller.cnf
MTA Configuration File (mandatory)
Defines address rewriting and routing as well as channel definition. server_root/msg-instance/imta/config/imta.cnf
Mapping File (mandatory)
Repository of mapping tables. server_root/msg-instance/imta/config/mappings
Defines global MTA options. server_root/msg-instance/imta/config/option.dat
Tailor File (mandatory)
Specifies locations. server_root/msg-instance/imta/config/imta_tailor
Table 5-2 lists the MTA database files with a short description.
MTA Configuration File
The MTA configuration file (imta.cnf) contains the routing and address rewriting configuration information. It defines all channels and their characteristics, the rules to route mail among those channels, and the method in which addresses are rewritten by the MTA.
Structure of the imta.cnf File
The configuration file consists of two parts: domain rewriting rules and channel definitions. The domain rewriting rules appear first in the file and are separated from the channel definitions by a blank line. The channel definitions are collectively referred to as the channel table. An individual channel definition forms a channel block.
Comments in the File
Comment lines may appear anywhere in the configuration file. A comment is introduced with an exclamation point (!) in column one. Liberal use of comments to explain what is going on is strongly encouraged. The following imta.cnf file fragment displays the use of comment lines.
! Part I: Rewrite rules
!
ims-ms.my_server.siroe.com $E$U@ims-ms-daemon
!
! Part II: Channel definitions
Distinguishing between blank lines and comment lines is important. Blank lines play an important role in delimiting sections of the configuration file. Comment lines are ignored by the configuration file reading routinesthey are literally "not there" as far as the routines are concerned and do not count as blank lines.
Including Other Files
The contents of other files may be included in the configuration file. If a line is encountered with a less than sign (<) in column one, the rest of the line is treated as a file name; the file name should always be an absolute and full file path. The file is opened and its contents are spliced into the configuration file at that point. Include files may be nested up to three levels deep. The following imta.cnf file fragment includes the /usr/iplanet/server5/msg-tango/table/internet.rules file.
</usr/iplanet/server5/msg-tango/table/internet.rules
Note Any files included in the configuration file must be world-readable just as the configuration file is world-readable.
Domain Rewrite Rules
Domain rewrite rules play two important roles:
Rewrite addresses into their proper form.
Determine to which channels a message should be enqueued. The determination of which channel to enqueue a message is made by rewriting its envelope To: address. Each rewrite rule appears on a single line in the upper half of the imta.cnf file.
For additional information about configuring rewrite rules, refer to the chapter "Configuring Rewrite Rules" in the iPlanet Messaging Server Administrator's Guide.
Rewrite Rule Structure
Rewrite rules appear in the upper-half of the MTA configuration file, imta.cnf. Each rule in the configuration file appears on a single line. Comments, but not blank lines, are allowed between the rules. The rewrite rules end with a blank line, after which the channel definitions follow. Figure 5-1 shows the rewrite rule section of a partial configuration file.
Figure 5-1   
Rewrite rules consist of two parts: a pattern, followed by an equivalence string or template. The two parts must be separated by spaces, although spaces are not allowed within the parts themselves. The structure for rewrite rules is as follows:
pattern template
Indicates the string to search for in the domain name. In Figure 5-1, the patterns are a, b, c, and d.
If the pattern matches the domain part of the address, the rewrite rule is applied to the address. A blank space must separate the pattern from the template. For more information about pattern syntax, see "Rewrite Rule Patterns and Tags" on page 219.
Is one of the following. For more information about template syntax, see "Rewrite Rule Templates" on page 221.
UserTemplate%DomainTemplate@ChannelTag[controls]
UserTemplate@ChannelTag[controls]
UserTemplate%DomainTemplate[controls]
UserTemplate@DomainTemplate@ChannelTag[controls]
UserTemplate@DomainTemplate@SourceRoute@ChannelTag[controls]
UserTemplate Specifies how the user part of the address is rewritten. Substitution sequences can be used to represent parts of the original address or the results of a database lookup. The substitution sequences are replaced with what they represent to construct the rewritten address. In Figure 6-1, the $U substitution sequence is used. For more information, see "Template Substitutions and Rewrite Rule Control Sequences" on page 222.
DomainTemplate Specifies how the domain part of the address is rewritten. Like the UserTemplate, the DomainTemplate can contain substitution sequences.
ChannelTag Indicates the channel to which this message is sent. (All channel definitions must include a channel tag as well as a channel name. The channel tag typically appears in rewrite rules, as well as in its channel definition.)
controls The applicability of a rule can be limited using controls. Some control sequences must appear at the beginning of the rule; other controls must appear at the end of the rule. Some can appear almost anywhere in a rule. For more information about controls, see "Template Substitutions and Rewrite Rule Control Sequences" on page 222.
Rewrite Rule Patterns and Tags
Most rewrite rule patterns consist either of a specific host name that will match only that host or of a subdomain pattern that will match any host/domain in the entire subdomain.
For example, the following rewrite rule pattern contains a specific host name that will match the specified host only:
The next rewrite rule pattern contains a subdomain pattern that will match any host or domain in the entire subdomain:
This pattern will not, however, match the exact host name siroe.com; to match the exact host name siroe.com, a separate siroe.com pattern would be needed.
The MTA attempts to rewrite host/domain names starting from the specific host name and then incrementally generalizing the name to make it less specific. This means that a more specific rewrite rule pattern will be preferentially used over more general rewrite rule patterns. For example, assume the following rewrite rule patterns are present in the configuration file:
hosta.subnet.siroe.com
.subnet.siroe.com
.siroe.com
Based on the rewrite rule patterns, an address of jdoe@hosta.subnet.siroe.com will match the hosta.subnet.siroe.com rewrite rule pattern; an address of jdoe@hostb.subnet.siroe.com will match the .subnet.siroe.com rewrite rule pattern; and an address of jdoe@hostc.siroe.com will match the .siroe.com rewrite rule pattern.
In particular, the use of rewrite rules incorporating subdomain rewrite rule patterns is common for sites on the Internet. Such a site will typically have a number of rewrite rules for their own internal hosts and subnets, and then will include rewrite rules for the top-level Internet domains into their configuration from the file internet.rules (server-instance/imta/config/internet.rules).
This file is required to contain the following:
Rewrite rules with patterns that match the top level Internet domains
Templates that rewrite addresses matching such patterns to an outgoing TCP/IP channel In addition to the more common sorts of host or subdomain rewrite rule patterns already discussed, rewrite rules may also make use of several special patterns, summarized in Table 5-3, and discussed in the following subsections.
In addition to these special patterns, Messaging Server also has the concept of tags, which may appear in rewrite rule patterns. These tags are used in situations where an address may be rewritten several times and, based upon previous rewrites, distinctions must be made in subsequent rewrites by controlling which rewrite rules match the address. For more information, see the iPlanet Messaging Server Administrator's Guide.
Rewrite Rule Templates
The following sections describe in more detail template formats for rewrite rules. Table 5-4 summarizes the template formats.
Template Substitutions and Rewrite Rule Control Sequences
Substitutions are used to rewrite user names or addresses by inserting a character string into the rewritten address, the value of which is determined by the particular substitution sequence used.
Control sequences impose additional conditions to the applicability of a given rewrite rule. Not only must the pattern portion of the rewrite rule match the host or domain specification being examined, but other aspects of the address being rewritten must meet conditions set by the control sequence or sequences.
If a domain or host specification matches the pattern portion of a rewrite rule but doesn't meet all of the criteria imposed by a control sequences in the rule's template, then the rewrite rule fails and the rewriter continues to look for other applicable rules.
Table 5-5 summarizes the template substitutions and control sequences.
For more information on substitutions, refer to the iPlanet Messaging Server Administrator's Guide.
Channel Definitions
The second part of an MTA configuration file contains the definitions for the channels themselves. These definitions are collectively referred to as the "channel host table," which defines the channels that the MTA can use and the names associated with each channel. Each individual channel definition forms a "channel block." Blocks are separated by single blank lines. Comments (but no blank lines) may appear inside a channel block. A channel block contains a list of keywords which define the configuration of a channel. These keywords are referred to as "channel keywords." See Table 5-6 for more information.
The following imta.cnf file fragment displays a sample channel block:
[blank line]
! sample channel block
channelname keyword1 keyword2
routing_system
[blank line]
The routing_system is the host name associated with this channel. During the address rewriting process, the host part of the address is checked against the hostnames associated with the channels before any pattern matching in the rewrite rules. The only exception to this is that the $* and exact pattern match rewrite rules are checked first.
For detailed information about channel definitions and channel table keywords, refer to the section "Channel Configuration Keywords," and to Table 5-6.
Channel Configuration Keywords
The first line of each channel block is composed of the channel name, followed by a list of keywords defining the configuration of the specific channel. The following tables describe keywords and how they control various aspects of channel behavior, such as the types of addresses the channel supports. A distinction is made between the addresses used in the transfer layer (the message envelope) and those used in message headers.
The keywords following the channel name are used to assign various attributes to the channel. Keywords are case-insensitive and may be up to 32 characters long; any additional characters are ignored. The supported keywords are listed in Table 5-6 and Table 5-7; the keywords shown in boldface are defaults. Table 5-6 lists channel keywords alphabetically; Table 5-7 lists channel keywords by functional group.
Specifying a keyword not on this list is not an error (although it may be incorrect). On UNIX systems, undefined keywords are interpreted as group IDs which are required from a process in order to enqueue mail to the channel. The imsimta test -rewrite utility tells you whether you have keywords in your configuration file that don't match any keywords, and which are interpreted as group ids.
Table 5-6    Channel Keywords Listed Alphabetically
Keyword
Usage
Use % routing in the envelope; synonymous with percents.
Percent sign envelope addresses. 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.
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.
Use source routes in the envelope; synonymous with 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.
Adds a Return-path: header when enqueuing to this channel.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.
Number of addresses per message file.
The addrsperfile keyword is used to put a limit on the maximum number of recipients that can be associated with a single message file in a channel queue, thus limiting the number of recipients that are processed in a single operation. See multiple.
integer specifies the maximum number of recipient addresses allowed in a message file; if this number is reached, the MTA automatically creates additional message files to accommodate them.
Number of addresses to be processed by a single job.
The addrsperjob keyword computes the number of concurrent jobs to start by dividing the total number of To: addressees in all entries by the given value.
integer specifies the number of addresses that must be sent to the associated channel before more than one master process is created to handle the addresses. If a value less than or equal to zero is specified, it is interpreted as a request to queue only one service job.
Query 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. Normally only addresses rewritten to the local channel (the l channel on UNIX) are looked up in the alias file and alias database. The exact form of the lookup probes that are performed is then controlled by the ALIAS_DOMAINS option.
Redirect postmaster messages to the local channel postmaster.
If the aliaspostmaster keyword is placed on a channel, then any messages addressed to the username postmaster (lowercase, uppercase, or mixed case) at the official channel name is redirected to postmaster@local-host, where local-host is the official local host name (the name on the local channel).
Note that Internet standards require that any domain in the DNS that accepts mail has a valid postmaster account that receives mail. So the aliaspostmaster keyword can be useful when it is desired to centralize postmaster responsibilities, rather than setting separate postmaster accounts for separate domains.
This keyword (and associated SMTP ETRN command keywords) control the MTA response when sending a message. The SMTP client issues the SMTP ETRN command, requesting that the MTA attempt to deliver messages in the MTA queues.
Use SMTP AUTH information in header. The authrewrite channel keyword may be used on a source channel to have the MTA propagate authenticated originator information, if available, into the headers. Normally the SMTP AUTH information is used, though this may be overridden via the FROM_ACCESS mapping.
integer can be one of the following:
1Add a Sender: header, or a Resent-sender: header if a Resent-from: or Resent-sender: was already present containing the AUTH originator.
Specifies the frequency of message delivery retries of messages unsuccessfully delivered. backoff specifies the interval values between retries of all messages regardless of priority unless overridden by nonurgentbackoff, normalbackoff, or urgentbackoff.
backoff "interval1" ["interval2"] ["interval3"] ["interval4"] ["interval5"] ["interval6"] ["interval7"] ["interval8"]
The interval uses ISO 8601P syntax and is as follows:
P[yearsY][monthsM][weeksW][daysD][T[hoursH][minutesM][secondsS]]
The variables years, months, weeks, days, hours, minutes, and seconds are integer values that specify the interval between delivery attempts (the first variable specifies the interval between the initial delivery failure and the first delivery attempt). The alphabetic variable labels (P, Y, M, W, D, H, M, S, and T) are case-insensitive. The initial P is required. The other variables are optional, except that T is required if any time values are specified.
Up to eight intervals can be specified with any of the backoff, nonurgentbackoff, normalbackoff, urgentbackoff keywords. The last interval specified is used as the interval for additional retry attempts that may be needed. Deliveries are attempted for a period of time specified by the notices keyword. If a successful delivery cannot be made, a delivery failure notification is generated and the message is returned to sender.
The default intervals between delivery retries attempts in minutes is shown below:
urgent: 30, 60, 60, 120, 120, 120, 240
normal: 60, 120, 120, 240, 240, 240, 480
nonurgent: 120, 240, 240, 480, 480, 480, 960
See the iPlanet Messaging Server Administrator's Guide for complete usage and examples.
Group A!B%C as A!(B%C). That is, the bangoverpercent keyword forces "bang" addresses (A!B%C) to interpret A as the routing host and C as the final destination host.
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 FRC 976.
Use UUCP! (bang-style) routing in the envelope; synonymous with uucp.
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.
Channel is served by both a master and slave program. The bidirectional, master, and slave keywords determines whether the MTA initiates delivery activity when a message is queued to the channel. The use of these keywords reflects certain fundamental characteristics of the corresponding channel program or programs. The descriptions of the various channels the MTA supports indicate when and where these keywords should be used.
Maximum number of MTA blocks allowed per message. The MTA rejects attempts to queue messages containing more blocks than this to the channel. An MTA block is normally 1024 bytes; this can be changed with the BLOCK_SIZE option in the MTA option file.
Cache all connection information and enables all forms of caching.
The SMTP channel cache normally records both connection successes and failures. However, this caching strategy is not necessarily appropriate for all situations.The cacheeverything, cachefailures, cachesuccesses, and nocache keywords are provided to adjust the MTA's cache.
Cache only connection failure information. See cacheeverything.
Cache only connection success information. This keyword is equivalent to nocache for channels. See cacheeverything.
Specify the location of channel filter file; synonym for destinationfilter. The channelfilter keyword may be used on general MTA channels to specify a channel-level filter to apply to outgoing messages.
The filter argument is a required URL that describes the channel filter location.
Default character set to associate with 7-bit text messages.
The MIME specification provides a mechanism to label the character set used in a plain text message. Specifically, a charset= parameter can be specified as part of the Content-type: header line. Various character set names are defined in MIME, including US-ASCII (default), ISO-8859-1, ISO-8859-2, and so on. Some existing systems and user agents do not provide a mechanism for generating these character set labels; as a result, some plain text messages may not be properly labeled. The charset7, charset8, and charsetesc channel keywords provide a per-channel mechanism to specify character set names to be inserted into message headers. If the appropriate keyword is not specified, no character set name is inserted into the Content-type: header lines.
Default character set to associate with 8-bit text messages.
The charset8 keyword also controls the MIME encoding of 8-bit characters in message headers (where 8-bit data is unconditionally illegal). The MTA normally MIME-encodes any (illegal) 8-bit data encountered in message headers, labeling it as the UNKNOWN charset if no charset8 value has been specified. See charset7 and charsetesc.
Default character set to associate with 7-bit text messages containing the escape character. See charset7 and charset8.
Check the SMTP response banner returned by the remote SMTP server for the string "ESMTP." If this string is found, EHLO is used. If the string is not found, HELO is used. The default behavior is to use EHLO on all initial connection attempts, unless the banner line contains the string "fire away," in which case HELO is used. Note that there is no keyword corresponding to this default behavior, which lies between the behaviors resulting from the ehlo and checkehlo keywords.
Leave comments in message header lines intact.
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 commenttotal keywords.
Runs comment strings in message header lines through the COMMENT_STRINGS mapping table. See commentinc.
Remove problematic characters from comment fields in message header lines. See commentinc.
Strip comments (material in parentheses) from all header lines, except Received: header lines; this keyword is not normally useful or recommended. See commentinc.
Does not rewrite addresses upon message dequeue and deliver to whatever host is listed in the recipient address.
Rewrite addresses upon message dequeue and connect to the host alias for the system to which the MTA would be connected.
Send copies of failures to the postmaster unless the originator address is blank. The postmaster then receives copies of all failed messages except those messages that are actually themselves bounces or notifications.
The keywords sendpost, copysendpost, errsendpost, and nosendpost control the sending of failed messages to the postmaster. The default behavior, if none of these keywords is specified, is to send a copy of failed mail messages to the postmaster, unless error returns are completely suppressed with a blank Errors-to: header line or a blank envelope From: address. This default behavior does not correspond to any of the keyword settings.
Send copies of warnings to the postmaster unless the originator address is blank. In this case, the postmaster receives copies of all warnings of undelivered messages except for undelivered messages that are actually themselves bounces or notifications.
The keywords warnpost, copywarnpost, errwarnpost, and nowarnpost are used to control the sending of warning messages to the postmaster. The default behavior, if none of these keywords is specified, is to send a copy of warnings to the postmaster unless warnings are completely suppressed with a blank Warnings-to: header line or a blank envelope From: address. This default behavior does not correspond to any of the keyword settings.
Specify the name of a gateway through which to route mail. The daemon keyword is used on SMTP channels to control the choice of target host. Normally such channels connect to whatever host is listed in the envelop address of the message being processed. The daemon keyword is used to tell the channel to instead connect to a specific remote system, generally a firewall or mailhub system, regardless of the envelope address.
Syntax:
daemon routing_hostname
The actual remote system name should appear directly after the daemon keyword. If the argument after the daemon keyword is not a fully qualified domain name, the argument is ignored and the channel connects to the channel's official host.
Convert date fields in message headers to four-digit years. Two- digit dates with a value less than 50 have 2000 added, while values greater than 50 have 1900 added.
Convert date fields in message headers to two-digit years. The MTA removes the leading two digits from four-digit dates. This is intended to provide compatibility with incompliant mail systems that require two digit dates; it should never be used for any other purpose.
Include day of week in date specifications in date fields in message headers and add this information to date and time headers if it is missing.
Specify a particular host name to use to complete addresses. This host name is appended to incoming bare user ids.
Syntax:
defaulthost host1 [host2]
The defaulthost keyword must be followed by the domain name (host1) to use in completing addresses (in envelope From: addresses and in headers) that come into that channel. An optional second domain name (host2) may be specified to use in completing envelope To: addresses. host2 must include at least one period in its name.
Channel determines whether or not to do MX lookups from network. The defaultmx keyword specifies that mx should be used if the network says that MX records are supported. The keyword defaultmx is the default on channels that support MX lookups in any form
Honor and implement recognition of deferred delivery dates (the Deferred-delivery: header line). Messages with a deferred delivery date in the future are held in the channel queue until they either expire and are returned or the deferred delivery date is reached. See RFC 1327 for details on the format and operation of the Deferred-delivery: header line.
Reassemble any MIME-compliant message and partial parts queued to this channel. When a channel is marked defragment, any partial messages queued to the channel are placed in the defragmentation channel queue instead. After all the parts have arrived, the message is rebuilt and sent on its way.
Removes source routes from envelope To: addresses when dequeuing.The dequeue_removeroute channel keyword can be used on outgoing TCP/IP channels to cause source routes to be removed from envelope recipient addresses. In particular, this keyword may be useful at sites that use the mailhost attribute to direct messages to NMS systems or other systems that do not support source routes.
Specifies the location of channel filter file that applies to outgoing messages. The destinationfilter is a synonym for channelfilter.
Syntax:
destinationfilter filter
The filter argument is a required URL that describes the channel filter location.
Disable support for the ETRN SMTP command. ETRN is not advertised by the SMTP server as a supported command. See allowetrn.
Tell the MTA to honor only those ETRN commands that specify a domain. The domainetrn keyword also causes the MTA not to echo back the name of the channel that the domain matched and that the MTA be attempts to run. See allowetrn.
Issue SMTP VRFY command using full address (for example, user@host) as its argument. The domainvrfy, localvrfy, and novrfy keywords control the MTA's use of the VRFY command in its SMTP client.
Strip blank To:, Resent-To, Cc:, or Resent-Cc: headers from incoming messages if specified on a source channel.
Channel supports 8-bit characters. The eightbit keyword should be used on channels that do not restrict the use of characters with ordinal values greater than 127 (decimal).
Channel should negotiate use of eight bit transmission, if possible.
Some transfers, such as extended SMTP, may actually support a form of negotiation to determine if eight-bit characters can be transmitted. The eightnegotiate keyword can be used to instruct the channel to encode messages when negotiation fails. This is the default for all channels; channels that do not support negotiation assume that the transfer is capable of handling eight-bit data
Channel should reject messages that contain unnegotiated 8-bit data.
Send copies of failures to the postmaster if the originator address is illegal (cannot be returned). See copysendpost.
Send copies of warnings to the postmaster if the originator address is illegal (cannot be returned). See copywarnpost.
Channel in which to perform deferred expansion due to application of expandlimit. The reprocessing channel would be used by default, if expandchannel were not specified, but use of a processing channel is typically necessary for Messaging Server configurations. If a channel for deferred processing is specified via expandchannel, that channel should be a reprocessing or processing channel. However, the Messaging Server typically should be a processing channel; specification of other sorts of channels may lead to unpredictable results.
Process an incoming message "offline" when the number of addressees exceeds this limit.
The expandlimit keyword takes an integer argument that specifies how many addresses should be accepted in messages coming from the channel before deferring processing. The default value is infinite if the expandlimit keyword is not specified. A value of 0 forces deferred processing on all incoming addresses from the channel.
Use explicit routing for this channel's addresses. 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.
Specify effect on address when a mailbox filter fileinto operation is applied. The fileinto keyword is currently supported only for ims-ms channels.
For ims-ms channels, the usual usage is:
fileinto $U+$S@$D
The above specifies that the folder name should be inserted as a sub-address into the original address, replacing any originally present sub-address.
Number of queue entries to be processed by a single job. The filesperjob keyword divides the number of actual queue entries or files by the given value. The number of queue entries resulting from a given message is controlled by a large number of factors, including but not limited to the use of the single and single_sys keywords and the specification of header modifying actions in mailing lists.
The filesperjob and addrsperjob keywords can be used to create additional master processes.
The argument for filesperjob is a single positive integer which specifies the number of addresses or queue entries (files) that must be sent to the associated channel before more than one master process is created to handle them. If a value less than or equal to zero is given, it is interpreted as a request to queue only one service job. Not specifying a keyword defaults to a value of 0.
Specify the location of user filter files. The filter keyword may be used on the native and ims-ms channels.
The argument for filter is a required URL describing the filter file location.
Affects verification of source IP address. The forwardcheckdelete keyword tells the MTA to perform a forward lookup after each reverse lookup and to ignore (delete) the reverse lookup returned name if the forward lookup of that name does not match the original connection IP address. Use the original IP address instead.
The fowardchecknone, forwardchecktag, and forwardcheckdelete keywords can modify the effects of performing reverse lookups and controlling whether the MTA performs a forward lookup of an IP name found using a DNS reverse lookup. If such forward lookups are requested, these keywords also determine what the MTA does if the forward lookup of the IP name does not match the original IP number of the connection.
Tell the MTA to perform a forward lookup after each reverse lookup and to tag the IP name with an asterisk, *, if the number found using the forward lookup does not match that of the original connection. See forwardcheckdelete.
Use % routing in the message header. This channel supports RFC 822 format header addressing with the exception of source routes; source routes should be rewritten using percent sign conventions instead.
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.
Use source routes in the message header. 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.
Use ! (bang-style) or UUCP routing in the header. The use of this keyword is not recommended. Such usage violates RFC 976.
Align header lines for message headers enqueued on this channel. This keyword takes an integer-valued argument. The alignment point is the margin where the contents of headers are aligned.
Syntax:
headerlabelalign alignment_point
The headerlabelalign keyword takes an integer-valued argument. The alignment point is the margin where the contents of headers are aligned.The default value is 0, which causes headers not to be aligned.
Control the length of message header lines enqueued on this channel. Lines longer than this keyword specifies are folded in accordance with RFC 822 folding rules.
Syntax:
headerlinelength length
The length value is an integer. The default, if this keyword is not explicitly set, is 80. Lines longer than this are folded in accordance with RFC 822 folding rules.
Apply header trimming rules from an options file to the message headers upon message enqueue (use with caution) before the original message headers are processed.
Syntax:
headerread channel_read_headers.opt
channel is the name of the channel with which the header option file is associated.
Applies header trimming rules from an options file to the message headers (use with caution) after the original message headers are processed. The headertrim keyword impacts only messages that are destined to that channel. Source channels are not impacted.
Syntax:
headertrim channel_headers.opt
channel is the name of the channel with which the header option file is associated.
Mark as .HELD an incoming message when the number of addressees exceeds this limit and enqueue to the reprocess channel (or to whatever channel is specified via the expandchannel keyword). As .HELD messages, the files sit unprocessed in that MTA queue area awaiting manual intervention by the MTA postmaster.
Hold messages for users that are over quota. These messages remain in the MTA queue until they can either be delivered or they time out and are returned to their sender by the message return job. The holdexquota and noexquota keywords control the handling of messages addressed to Berkeley mailbox users (UNIX) who have exceeded their disk quota.
Disable IDENT lookups; perform IP-to-hostname translation. Both IP number and host name are included in the Received: header lines for the message.
Has the same effect as identnone as far as IDENT lookups, reverse DNS lookups, and information displayed in Received: header. Where it differs is that with identnonelimited the IP literal address is always used as the basis for any channel switching due to use of the switchannel keyword, regardless of whether the DNS reverse lookup succeeds in determining a host name.
Disable IDENT lookups and inhibits the usual DNS reverse lookup translation of IP number to host name. This might result in a performance improvement at the cost of less user-friendly information in the Received: header.
Disable this IDENT lookup, but does perform IP to host name translation. Only the host name is included in the Received: header for the message.
Perform IDENT lookups on incoming SMTP connections and IP to host name translation. The IDENT lookup uses the IDENT protocol (RFC 1413). The information obtained from the IDENT protocol (usually the identity of the user making the SMTP connection) is then inserted into the Received: header lines of the message, with the host name corresponding to the incoming IP number, as reported from a DNS reverse lookup and the IP number itself.
Has the same effect as identtcp as far as IDENT lookups, reverse DNS lookups, and information displayed in Received: header. Where it differs from identtcp is that the IP literal address is always used as the basis for any channel switching due to use of the switchchannel keyword, regardless of whether the DNS revers lookup succeeds in determining a host name.
Perform IDENT lookups on incoming SMTP connections; disable IP to hostname translation.
Enable IDENT protocol (RFC 1413). The information obtained from the IDENT protocol (usually the identity of the user making the SMTP connection) is then inserted into the Received: header lines of the message, with the actual incoming IP number, as reported from a DNS reverse lookup; the IP number itself is not included in the Received: header.
Use implicit routing for this channel's addresses. The improute keyword indicates to the MTA that all addresses matching other channels need routing when they are used in mail sent to a channel marked improute.
Include final form of address in delivery notifications (recipient address). The includefinal and suppressfinal channel keywords control whether the MTA also includes the final form of the address.
Parse messages and rewrite inner message headers. This keyword can be applied to any channel.
Apply header trimming rules from an options file to inner message headers for example, embedded MESSAGE/RFC822 headers (use with caution).
Syntax:
innertrim channel_headers.opt
channel is the name of the channel with which the header option file is associated.
Bind to the specified TCP/IP interface address as the source address for outbound connections. On a system with multiple interface addresses this keyword controls which address is used as the source IP address when the MTA sends outgoing SMTP messages. Note that it complements the Dispatcher option INTERFACE_ADDRESS, which controls which interface address a TCP/IP channel listens on for accepting incoming connections and messages.
Interpret Encoding: header on incoming messages, if otherwise configured to do so.
Specify a host in which to connect even when all other connection attempts fail. In effect, this acts as an MX record of last resort. This is only useful on SMTP channels.
The keyword requires a single parameter specifying the name of the "system of last resort."
Message lines exceeding this length limit are wrapped (MIME encoded). The linelength keyword provides a mechanism for limiting the maximum permissible message line length on a channel-by-channel basis. Messages queued to a given channel with lines longer than the limit specified for that channel are automatically encoded.
The linelength keyword causes encoding of data to perform "soft" line wrapping for transport purposes.
Maximum number of lines allowed per message. The MTA rejects attempts to queue messages containing more than this number of lines to the channel. The keywords, blocklimit and linelimit, can be imposed simultaneously, if necessary.
Issue SMTP VRFY command using local part of the address. For example, for the address user1@siroe.com, user1 is used with the VRFY command. See domainvrfy.
Log message enqueues and dequeues into the log file and activates logging for a particular channel. Logging is controlled on a per-channel basis. All log entries are made to the file mail.log_current in the log directory server_root/msg-instance/log/imta/mail.log_current.
Places a string into the SMTP banner in order for the SMTP server to check if it is communicating with itself. When loopcheck is set, the SMTP server advertises an XLOOP extension. When it communicates with an SMTP server supporting XLOOP, the MTA's SMTP client compares the advertised string with the value of its MTA and immediately bounces the message if the client is in fact communicating with the SMTP server.
Verify that an entry in the DNS exists for the domain used on the SMTP MAIL FROM: command when set on an incoming TCP/IP channel. The MTA rejects the message if no such entry exists.
Channel is served only by a master program. See bidirectional.
Generate debugging output in the channel's master program output.
Some channel programs include optional code to assist in debugging by producing additional diagnostic output. The master_debug and slave_debug channel keywords are provided to enable generation of this debugging output on a per-channel basis.
On UNIX, when master_debug and slave_debug is enabled for the l channel, users receive imta_sendmail.log-uniqueid files in their current directory (if they have write access to the directory; otherwise, the debug output goes to stdout) containing MTA debug information.
Maximum number of MTA blocks per message; longer messages are broken into multiple messages. An MTA block is normally 1024 bytes; this can be changed with the BLOCK_SIZE option in the MTA option file.
The maxblocks and maxlines keywords are used to impose size limits beyond which automatic fragmentation are activated.
Maximum number of addresses per message header line; longer header lines are broken into multiple header lines.
This keyword requires a single integer parameter that specifies the associated limit. By default, no limit is imposed on the length of a header line nor on the number of addresses that can appear.
Maximum number of characters per message header line; longer header lines are broken into multiple header lines.
This keyword requires a single integer parameter that specifies the associated limit. By default, no limit is imposed on the length of a header line nor on the number of addresses that can appear.
Maximum number of concurrent jobs that can be running at one time. Normally maxjobs is set to a value that is less than or equal to the total number of jobs that can run simultaneously in whatever Job Controller pool or pools the channel uses.
Maximum number of message lines per message; longer messages are broken into multiple messages. This limit can be imposed simultaneously if necessary. See maxblocks.
Specifies maximum length of headers to process and rewrite. Messages with headers longer than specified are still accepted and delivered; the only difference is that the long header lines are not rewritten in any way.
Cause the SMTP server to permit clients to attempt to use SASL authentication.
The maysaslserver, mustsaslserver, nosasl, nosaslserver, nosaslswitchchannel, and saslswitchchannel keywords are used to configure SASL (SMTP AUTH) use during the SMTP protocol by SMTP channels such as TCP/IP channels.
SMTP client and server allow TLS use to incoming connections and to attempt TLS upon outgoing connections.
The maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, and tlsswitchchannel channel keywords are used to configure TLS use during the SMTP protocol by SMTP based channels such as TCP/IP channels.
SMTP client attempts TLS use when sending outgoing messages, if sending to an SMTP server that supports TLS. See maytls.
SMTP server allows TLS use and advertises support for the STARTTLS extension when receiving messages. See maytls.
Controls handling of messages missing recipient header lines.
Syntax:
missingrecipientpolicy integer
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 0, meaning that envelope To: addresses are placed in a To: header.
The values for missingrecipientpolicy are:
0Place envelope To: recipients in a To: header line.
1Pass the illegal message through unchanged.
2Place envelope To: recipients in a To: header line.
3Place all envelope To: recipients in a single Bcc: header line.
4Generate a group construct (for example, ;) To: header line, To: Recipients not specified.
Serves channel for Microsoft Exchange gateways and clients. The msexchange channel keyword also causes advertisement (and recognition) of broken TLS commands.
Accept multiple destination hosts in a single message copy for the entire channel. Note that at least one copy of each message is created for each channel the message is queued to, regardless of the keywords used. The multiple keyword corresponds in general to imposing no limit on the number of recipients in a message file, however the SMTP channel defaults to 99.
The keywords multiple, addrsperfile, single, and single_sys can be used to control how multiple addresses are handled.
Cause the SMTP server to insist that clients use SASL authentication; the SMTP server does not accept messages unless the remote client successfully authenticates. See maysaslserver.
SMTP client and server insist upon TLS use n both outgoing and incoming connections and does not transfer messages with remote sides that do not support TLS. Email is not exchanged with remote systems that fail to successfully negotiate TLS use. See maytls.
SMTP client insists upon TLS use when sending outgoing messages and does not send messages to any remote SMTP server that does not support TLS use. See maytls.
SMTP server insists upon TLS use and does not accept messages from any remote SMTP client that does not support TLS use. See maytls.
TCP/IP network and software supports MX record lookups. The mx keyword is currently equivalent to nonrandommx. See randommx.
Consult specified nameservers rather than TCP/IP stack's choice when nameserver lookups are being performed, that is, unless the nsswitch.conf file on UNIX or the Windows NT TCP/IP configuration selects no use of nameservers.
Syntax:
nameservers IP_address1 IP_address2 ...
nameservers requires a space separated list of IP addresses for the nameservers.
Do not add a Return-path: header when enqueuing to this channel.
Group A!B%C as (A!B)%C (default). That is, the nobangoverpercent keyword forces "bang" addresses (A!B%C) to interpret C as the routing host and A as the final destination host.
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 FRC 976.
No limit specified for the number of MTA blocks allowed per message. See blocklimit.
Do not cache any connection information. See cacheeverything.
Do not perform channel filtering for outgoing messages; synonym for nodestinationfilter. See channelfilter.
Remove day of week from date/time specifications. This is intended to provide compatibility with incompliant mail systems that cannot process this information properly; it should never be used for any other purpose. See dayofweek.
Do not specify a domain name to use to complete addresses. See defaulthost.
Do not perform special processing for message/partial messages. See defragment.
Do not perform channel filtering for outgoing messages. See destinationfilter.
Do not strip blank To:, Resent-To:, Cc:, or Resent-Cc: headers. See dropblank.
No explicit routing for this channel's addresses. See exproute.
Return to originator any messages to users who are over quota. See holdexquota.
Mailbox filter fileinto operator has no effect. See fileinto.
Do not apply header trimming rules from option file upon message enqueue. See headerread.
Do not apply header trimming rules from options file. See headertrim.
No implicit routing for this channel's addresses. See improute.
Do not rewrite inner message headers. See inner.
Do not apply header trimming to inner message headers. See innertrim.
No limit specified for the number of lines allowed per message. See linelimit.
Do not log message enqueues and dequeues into the log file. See logging.
Do not place a string into the SMTP banner in order for the SMTP server to check if it is communicating with itself. See loopcheck.
The MTA does not verify that an entry in the DNS exists for the domain used. See mailfromdnsverify.
Do not generate debugging output in the channel's master program output. See master_debug.
Channel does not serve MS Exchange gateways. See msexchange.
Perform MX lookups; does not randomize returned entries of equal precedencethey should be processed in the same order in which they are received. Equivalent to mx. See also randommx.
Specifies the frequency for attempted delivery of nonurgent messages. See backoff.
Syntax:
nonurgentbackoff "interval1" ["interval2"] ["interval3"] ["interval4"] ["interval5"] ["interval6"] ["interval7"] ["interval8"]
The interval uses ISO 8601P syntax and is as follows:
P[yearsY][monthsM][weeksW][daysD][T[hoursH][minutesM][secondsS]]
The variables years, months, weeks, days, hours, minutes, and seconds are integer values that specify the interval between delivery attempts (the first variable specifies the interval between the initial delivery failure and the first delivery attempt). The alphabetic variable labels (P, Y, M, W, D, H, M, S, and T) are case-insensitive. The initial P is required. The other variables are optional, except that T is required if any time values are specified.
Force messages above the specified size to wait unconditionally for a periodic job. The nonurgentblocklimit keyword instructs the MTA to downgrade messages larger than the specified size to lower than nonurgent priority (second class priority).
Specify the amount of time which may elapse before notices are sent and messages returned for messages of non-urgent priority.
Different return handling for messages of different priorities may be explicitly set using the nonurgentnotices, normalnotices, or urgentnotices keywords. Otherwise, the notices keyword values are used for all messages. See notices.
Syntax:
nonurgentnotices age1 [age2] [age3] [age4] [age5]
The keyword is followed by a list of up to five monotonically increasing integer values. These values refer to the message ages at which warning messages are sent. The ages have units of days if the RETURN_UNITS option is 0 or not specified in the option file; or hours if the RETURN_UNITS option is 1. When an undeliverable message attains or exceeds the last listed age, it is returned (bounced).
Do not include Envelope to address in Received: header line. The noreceivedfor keyword instructs the MTA to construct Received: header lines without including any envelope addressee information. See receivedfor.
Construct Received: header lines without including the original envelope From: address. The noreceivedfrom keyword instructs the MTA to construct Received: header lines without including the original envelope From: address. See receivedfrom.
Use local host's domain name as the default domain name to complete addresses. See remotehost.
Do not apply RFC 1137 restricted encoding to addresses. Equivalent to unrestricted keyword. See restricted.
Do not apply reverse database to addresses. noreverse exempts addresses in messages queued to the channel from address reversal processing. See reverse.
Specifies the frequency for attempted delivery of normal messages. See backoff.
Syntax:
normalbackoff "interval1" ["interval2"] ["interval3"] ["interval4"] ["interval5"] ["interval6"] ["interval7"] ["interval8"]
The interval uses ISO 8601P syntax and is as follows:
P[yearsY][monthsM][weeksW][daysD][T[hoursH][minutesM][secondsS]]
The variables years, months, weeks, days, hours, minutes, and seconds are integer values that specify the interval between delivery attempts (the first variable specifies the interval between the initial delivery failure and the first delivery attempt). The alphabetic variable labels (P, Y, M, W, D, H, M, S, and T) are case-insensitive. The initial P is required. The other variables are optional, except that T is required if any time values are specified.
Downgrade messages larger than the specified size to nonurgent priority.
Specify the amount of time which may elapse before notices are sent and messages returned for messages of normal priority. See notices.
Syntax:
normalnotices age1 [age2] [age3] [age4] [age5]
The keyword is followed by a list of up to five monotonically increasing integer values. These values refer to the message ages at which warning messages are sent. The ages have units of days if the RETURN_UNITS option is 0 or not specified in the option file; or hours if the RETURN_UNITS option is 1. When an undeliverable message attains or exceeds the last listed age, it is returned (bounced).
Do not perform channel-specific rewrite rule checks. This keyword is usually used for debugging and is rarely used in actual applications. See rules.
SASL authentication is not permitted or attempted. Do not allow switching to this channel upon successful SASL authentication. See maysaslserver.
Do not send copies of failures to the postmaster. See sendpost.
Service conversions for messages coming into this channel must be enabled via CHARSET_CONVERSIONS. See service.
Do not perform channel filtering for incoming messages. See sourcefilter.
Do not switch to the channel associated with the originating host; does not permit being switched to. See switchchannel.
Specifies the amount of time that may elapse before notices are sent and messages returned.
Syntax:
notices age1 [age2] [age3] [age4] [age5]
The keyword is followed by a list of up to five monotonically increasing integer values. These values refer to the message ages at which warning messages are sent. The ages have units of days if the RETURN_UNITS option is 0 or not specified in the option file; or hours if the RETURN_UNITS option is 1. When an undeliverable message attains or exceeds the last listed age, it is returned (bounced).
When a message attains any of the other ages, a warning notice is sent. The default if no keyword is given is to use the notices setting for the local channel. If no setting has been made for the local channel, then the defaults 3, 6, 9, 12 are used, meaning that warning messages are sent when the message attains the ages 3, 6, and 9 days (or hours) and the message is returned after remaining in the channel queue for more than 12 days (or hours).
SMTP client and server neither attempt nor allow TLS use. See maytls.
SMTP client does not attempt TLS use when sending messages. See maytlsclient.
SMTP server does not offer or allow TLS use when receiving messages. See maytlsserver.
Do not send copies of warnings to the postmaster. See warnpost.
Do not add X-Envelope-to header lines while enqueuing. See x_env_to.
Ignores bang paths in address of the form A!B%C. When this keyword is set, percents are interpreted for routing.
Leave personal name fields in message header lines intact when rewriting addresses.
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.
Run personal names through PERSONAL_NAMES mapping table. See personalinc.
Remove personal name fields from message header lines. See personalinc.
Strip problematic characters from personal name fields in message header lines. See personalinc.
Specifies processing pool master channel in which programs run.
The MTA creates service jobs (channel master programs) to deliver messages. The Job Controller, which launches these jobs, associates them with pools. Pool types are defined in the job_controller.cnf file. The pool with which each channel's master program is associated can be selected on a channel-by-channel basis, using the pool keyword.
The pool keyword must be followed by the name of the pool to which delivery jobs for the current channel should be queued. The name of the pool should not contain more than 12 characters. If the pool keyword is omitted, then the pool used is the default pool, the first queue listed in the Job Controller configuration file.
Connect to the specified TCP/IP port. The SMTP over TCP/IP channels normally connect to port 25 when sending messages. The port keyword can be used to instruct an SMTP over TCP/IP channel to connect to a nonstandard port.
Both the message's header and body are sent to the postmaster when a delivery failure occurs.
Only the message's header is sent to the postmaster when a delivery failure occurs.
Perform MX lookups. MX record values of equal precedence should be processed in random order. Some TCP/IP networks support the use of MX (mail forwarding) records and some do not. Some TCP/IP channel programs can be configured not to use MX records if they are not provided by the network to which the MTA system is connected.
Includes envelope To: address in Received: head if a message is addressed to just one envelope recipient.
Include the original envelope From: address when constructing Received: header lines if the MTA has changed the envelope From: address due to, for example, certain sorts of mailing list expansions.
Use remote host's name as the default domain name to complete addresses. The use of the remote host's domain name is appropriate when dealing with improperly configured SMTP clients.
The remotehost keyword must be followed by the domain name to use in completing addresses that come into that channel.
Apply RFC 1137 restricted encoding to addresses. 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 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.
Set the return address for the local Postmaster. By default, the Postmaster's return address that is used when the MTA constructs bounce or notification messages is postmaster@local-host, where local-host is the official local host name (the name on the local channel).
Syntax:
returnaddress postmaster_address
returnaddress takes a required argument specifying the Postmaster address.
Control use of blank envelope return addresses.
Syntax:
returnenvelope bit_flag
The returnenvelope keyword takes a single integer value, which is interpreted as a set of bit flags.
Bit 0 (value = 1) controls whether or not return notifications generated by the MTA are written with a blank envelope address or with the address of the local postmaster. Setting the bit forces the use of the local postmaster address; clearing the bit forces the use of a blank address.
Bit 1 (value = 2) controls whether or not the MTA replaces all blank envelope addresses with the address of the local postmaster. This is used to accommodate noncompliant systems that do not conform to RFC 821, RFC 822, or RFC 1123.
Set the personal name for the local Postmaster. By default, the Postmaster's personal name that is used when the MTA constructs bounce or notification messages is "MTA e-Mail Interconnect."
Syntax:
returnpersonal postmaster_name
returnpersonal takes a required argument specifying the Postmaster personal name.
Apply reverse database or REVERSE mapping to addresses in messages queued to the channel.
Attempt short-circuit routing to any explicit routing in addresses when rewriting an address to the channel. 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 % our other routing.
Perform channel-specific rewrite rule checks. Usually used for debugging.
Cause incoming connections to be switched to a specified channel upon a client's successful use of SASL.
Syntax:
saslswitchchannel channel
The channel argument specifies the channel to which to switch.
Sends copies of failed messages to the postmaster. See copysendpost.
Send an ETRN command, if the remote SMTP server says it supports ETRN. The sendetrn and nosendetrn keywords control whether the MTA SMTP client sends an ETRN command at the beginning of an SMTP connection or does not sent an ETRN command at all.
The sendetrn keyword should be followed by the name of the system requesting that its messages receive a delivery attempt.
Allow messages of any sensitivity. The sensitivity keywords set an upper limit on the sensitivity of messages that can be accepted by a channel. A message with no Sensitivity: header is considered to be of normal, that is, the lowest, sensitivity. Messages with a higher sensitivity than that specified by such a keyword is reject when enqueued to the channel with an error message.
Note that the MTA performs this sort of sensitivity checking at a per-message, not per-recipient, level. If a desalination channel for one recipient fails the sensitivity check, then the message bounces for all recipients, not just for those recipients associated with the sensitive channel.
Reject messages whose sensitivity is higher than normal. See sensitivitycompanyconfidential.
Reject messages whose sensitivity is higher than personal. See sensitivitycompanyconfidential.
Reject messages whose sensitivity is higher than private. See sensitivitycompanyconfidential.
Perform service conversions for messages coming into the channel. The service keyword unconditionally enables service conversions regardless of CHARSET-CONVERSION entry.
Channel does not support 8-bit characters; 8-bit characters must be encoded. The MTA provides facilities to automatically encode such messages so that troublesome eight-bit characters do not appear directly in the message. This encoding can be applied to all messages on a given channel by specifying the sevenbit keyword.
Honor all ETRN commands, but without echoing the name of the channel that the domain matched and that the MTA attempts to run. See allowetrn.
Only one envelope To: address per message copy or destination address on the channel. See multiple.
Each message copy must be for a single destination system. See multiple.
Channel is serviced only by a slave program. See bidirectional.
Generate debugging output in slave programs. See master_debug.
Channel uses SMTP. The smtp keywords specify whether or not a channel supports the SMTP protocol and what type of SMTP line terminator the MTA expects to see as part of that protocol. The smtp keyword or one of the other smtp_* keywords is mandatory for all SMTP channels.
The keywords smtp_cr, smtp_crlf, smtp_crorlf, and smtp_lf can be used on SMTP channels to not only select use of the SMTP protocol, but also to further specify the character sequences to accept as line terminators. It is normal to use CRLF sequences as the SMTP line terminator, and this is what the MTA always generates; these keywords only affect the handling of incoming material.
Require CRLF as the SMTP line terminator. This means that lines must be terminated with a carriage return (CR) line feed (LF) sequence. See smtp.
Allow any of CR (carriage return), LF (line feed), or full CRLF as the SMTP line terminator. See smtp.
Accept LF (linefeed) without a preceding CR (carriage return) as an SMTP line terminator. See smtp.
Maximum number of MTA blocks allowed per incoming message. The MTA rejects attempts to submit a message containing more blocks than this to the channel. See blocklimit.
Leave comments in incoming message header lines.
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. On source channels, this behavior is controlled by the use of the sourcecommentinc, sourcecommentmap, sourcecommentomit, sourcecommentstrip, and sourcecommenttotal keywords.
Runs comment strings in message header lines through source channels. See sourcecommentinc.
Remove comments from incoming message header lines, for example, To:, From:, and Cc: headers. See sourcecommentinc.
Remove problematic characters from comment field in incoming message header lines. See sourcecommentinc.
Strip comments (material in parentheses) everywhere in incoming messages. The sourcecommenttotal keyword indicates to the MTA to remove any comments from all headers, except Received: headers. This keyword is not normally useful or recommended. See sourcecommentinc.
Specify the location of channel filter file for incoming messages.
The filter argument is a required URL that describes the channel filter location.
Leave personal names in incoming message header lines intact.
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. On source channels, this behavior is controlled by the use of the sourcepersonalinc, sourcepersonalmap, sourcepersonalomit, and sourcepersonalstrip keywords.
Run personal names through source channels. See sourcepersonalinc.
Remove personal name fields from incoming message header lines. See sourcepersonalinc.
Strip problematic characters from personal name fields in incoming message header lines. See sourcepersonalinc.
Use source routes in the message envelope; synonymous with 822.
Specify degree of protocol streaming for channel to use.
This keyword requires an integer parameter; how the parameter is interpreted is specific to the protocol in use.
The streaming values available range from 0 to 3. A value of 0 specifies no streaming, a value of 1 causes groups of RCPT TO commands to stream, a value of 2 causes MAIL FROM/RCPT TO to stream, and a value of 3 causes HELO/MAIL FROM/RCPT TO or RSET/MAIL FROM/RCPT TO streaming to be used. The default value is 0.
Alias must match exactly, including exact subaddress match. 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 wildcarded comparisons or comparisons with the subaddress removed) are performed.
Alias without subaddress may match. 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. The subaddressrelaxed keyword is the default.
Alias with subaddress wildcard may match. 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 keyword should be followed by an integer that specifies the number of subdirectories across which to spread messages for the channel.
Marks the channel as a submit-only channel. This is normally useful on TCP/IP channels, such as an SMTP server run on a special port used solely for submitting messages. RFC 2476 establishes port 587 for message submissions.
Suppress the final address form from notification messages, if an original address form is present, from notification messages. See includefinal.
Switch from the server channel to the channel associated with the originating host. If switchchannel is specified on the initial channel the server uses, the IP address of the connecting (originating) host is matched against the channel table; if it matches, the source channel changes accordingly. If no IP address match is found or if a match is found that matches the original default incoming channel, the MTA may optionally try matching using the host name found by performing a DNS reverse lookup.
Number of messages per thread. The threaddepth keyword may be used to instruct the MTA's multithreaded SMTP client to handle only the specified number of messages in any one thread, using additional threads even for messages all to the same destination normally all handled in one thread).
Switch to specified channel upon successful TLS negotiation. See maytls.
Syntax:
tlsswitchchannel channel
The channel parameter specifies the channel to which to switch.
Do not apply RFC 1137 restricted encoding to addresses. See restricted.
Specify the frequency for attempted delivery of urgent messages. See backoff.
Syntax:
urgentbackoff "interval1" ["interval2"] ["interval3"] ["interval4"] ["interval5"] ["interval6"] ["interval7"] ["interval8"]
The interval uses ISO 8601P syntax and is as follows:
P[yearsY][monthsM][weeksW][daysD][T[hoursH][minutesM][secondsS]]
The variables years, months, weeks, days, hours, minutes, and seconds are integer values that specify the interval between delivery attempts (the first variable specifies the interval between the initial delivery failure and the first delivery attempt). The alphabetic variable labels (P, Y, M, W, D, H, M, S, and T) are case-insensitive. The initial P is required. The other variables are optional, except that T is required if any time values are specified.
Force messages larger the specified size to normal priority.
Specify the amount of time which may elapse before notices are sent and messages returned for messages of urgent priority. See notices.
Syntax:
urgentnotices age1 [age2] [age3] [age4] [age5]
The keyword is followed by a list of up to five monotonically increasing integer values. These values refer to the message ages at which warning messages are sent. The ages have units of days if the RETURN_UNITS option is 0 or not specified in the option file; or hours if the RETURN_UNITS option is 1. When an undeliverable message attains or exceeds the last listed age, it is returned (bounced).
Present the address as originally presented to the MTA for notification messages.
Specify the queue for master channel program processing of urgent messages. The user keyword is used on pipe channels to indicate under what username to run.
Note that the argument to user is normally forced to lowercase, but original case is preserved if the argument is quoted.
Use UUCP! (bang-style) routing in the envelope; synonymous with bangstyle.
Specify that final recipient addresses that match the channel are not required to be produced by an alias.
Specify 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).
Issue a detailed, informative response for SMTP VRFY command.
The vrfyallow, vrfydefault, and vrfyhide keywords control the MTA SMTP server's response when a sending SMTP client issues a SMTP VRFY command. These keywords allow per-channel control of VRFY responses, as opposed to the HIDE_VERIFY option, which normally applies to all incoming TCP/IP channels handled through the same SMTP server.
Provide a detailed, informative response for SMTP VRFY command, unless the channel option HIDE_VERIFY=1 has been specified. See vrfyallow.
Issue only a vague, ambiguous response to SMTP VRFY command. See vrfyallow.
Send copies of warnings to the postmaster. See copywarnpost.
Add X-Envelope-to header lines while enqueuing. The x_env_to and nox_env_to keywords control the generation or suppression of X-Envelope-to header lines on copies of messages queued to a specific channel. On channels that are marked with the single keyword, the x_env_to keyword enables generation of these headers.
The x_env_to keyword requires the single keyword in order to take effect.
Table 5-7 lists channel keywords for functional group.
For additional description about the channel keyword functionality groups, see the chapter "Configuring Channel Definitions" in the iPlanet Messaging Server Administrator's Guide.
Table 5-7    Channel Keywords Grouped by Functionality
Functionality
Associated Keywords
nonurgentnotices, normalnotices, notices, urgentnotices
defaultmx, defaultnameservers, mx, nameservers, nomx, nonrandommx, randommx
forwardcheckdelete, forwardchecknone, forwardchecktag, identnone, identnonelimited, identnonenumeric, identnonesymbolic, identtcp, identtcplimited, identtcpnumeric, identtcpsymbolic
headerread, headertrim, innertrim, noheaderread, noheadertrim, noinnertrim
aliaspostmaster, noreturnaddress, noreturnpersonal, returnaddress, returnpersonal
commentinc, commentmap, commentomit, commentstrip, commenttotal, sourcecommentinc, sourcecommentmap, sourcecommentomit, sourcecommentstrip, sourcecommenttotal
personalinc, personalmap, personalomit, personalstrip, sourcepersonalinc, sourcepersonalmap, sourcepersonalomit, sourcepersonalstrip
blocklimit, linelimit, noblocklimit, nolinelimit, sourceblocklimit
sensitivitycompanyconfidential, sensitivitynormal, sensitivitypersonal, sensitivityprivate
maysaslserver, mustsaslserver, nosasl, nosaslserver, nosasl, saslswitchchannel
channelfilter, destinationfilter, fileinto, filter, nochannelfilter, nodestinationfilter, nofileinto, nofilter, nosourcefilter, sourcefilter
maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, tlsswitchchannel
Alias File
The alias file is used to set aliases not set in the directory. In particular, the postmaster alias is a good example. The MTA has to be restarted for any changes to take effect. Any line that begins with an exclamation point is considered to be a comment and is ignored. Blank lines are also ignored.
A physical line in this file is limited to 1024 characters. You can split a logical line into multiple physical lines using the backslash (\) continuation character.
The format of the file is as follows:
user@domain: <address>
user@domain: <address> <address> ...
The following is an example aliases file:
! A /var/mail user
mailsrv@siroe.com: mailsrv@native-daemon
!A message store user
ms_testuser@siroe.com: mstestuser@ims-ms-daemon
Including Other Files in the Alias File
Other files can be included in the primary alias file. A line of the following form directs the MTA to read the file-spec file:
<file-spec
The file specification must be a complete file path specification and the file must have the same protections as the primary alias file; for example, it must be world readable.
The contents of the included file are inserted into the alias file at its point of reference. The same effect can be achieved by replacing the reference to the included file with the file's actual contents. The format of include files is identical to that of the primary alias file itself. Indeed, include files may themselves include other files. Up to three levels of include file nesting are allowed.
/var/mail Channel Option File
An option file may be used to control various characteristics of the native channel. This native channel option file must be stored in the MTA configuration directory and named native_option (for example, server_root/msg-instance/imta/config/native_option).
Option files consist of several lines. Each line contains the setting for one option. An option setting has the form:
option=value
The value may be either a string or an integer, depending on the option's requirements.
SMTP Channel Option Files
An option file may be used to control various characteristics of TCP/IP channels. Such an option file must be stored in the MTA configuration directory (server_root/msg-instance/imta/config) and named x_option, where x is the name of the channel.
Format of the File
Option files consist of several lines. Each line contains the setting for one option. An option setting has the form:
option=value
The value may be either a string or floating point value, depending on the option's requirements. If the option accepts an integer value, a base may be specified using notation of the form b%v, where b is the base expressed in base 10 and vb.
Available SMTP Channel Options
The available options are listed in Table 5-9.
Conversions
There are two broad categories of conversions in the MTA, controlled by two corresponding mapping tables and the MTA conversions file.
The first category is that of character set, formatting, and labelling conversions performed internally by the MTA. The application of such conversions is controlled by the CHARSET-CONVERSION mapping table.
The second category is that of conversions of message attachments using external, third-party programs and site-supplied procedures, such as document converters and virus scanners. The application of such conversions is controlled by the CONVERSIONS mapping table, and messages requiring such conversions are thereby routed through the MTA conversion channel, which in turn executes the site-specified external conversion procedure.
The MTA conversions file is used to specify the details of external CONVERSION table triggered conversions and to specify the details of some internal CHARSET-CONVERSION table triggered conversions.
Character Set Conversion and Message Reformatting Mapping
One very basic mapping table in the MTA is the character set conversion table. The name of this table is CHARSET-CONVERSION. It is used to specify what sorts of channel-to-channel character set conversions and message reformatting should be performed.
The MTA probes the CHARSET-CONVERSION mapping table in two different ways. The first probe is used to determine whether or not the MTA should reformat the message and if so, what formatting options should be used. (If no reformatting is specified the MTA does not bother to check for specific character set conversions.) The input string for this first probe has the general form:
IN-CHAN=in-channel;OUT-CHAN=out-channel;CONVERT
Here in-channel is the name of the source channel (where the message comes from) and out-channel is the name of the destination channel (where the message is going). If a match occurs the resulting string should be a comma-separated list of keywords. The keywords provided are listed in Table 5-10.
For more information on character set conversion and message reformatting mapping, see the iPlanet Messaging Server Administration Guide.
Conversion File
Configuration of the conversion channel in the MTA configuration file (imta.cnf) is performed by default. With the rewrite rules from the default configuration, an address of the form user@conversion.localhostname or user@conversion is routed through the conversion channel, regardless of what the CONVERSIONS mapping states.
The actual conversions performed by the conversion channel are controlled by rules specified in the MTA conversion file. This is the file specified by the IMTA_CONVERSION_FILE option in the MTA tailor file. By default, this is the file server_root/msg-instance/imta/conversions.
The MTA conversion file is a text file containing entries in a format that is modeled after MIME Content-Type parameters. Each entry consists of one or more lines grouped together; each line contains one or more name=value; parameter clauses. Quoting rules conform to MIME conventions for Content-Type header line parameters. Every line except the last must end with a semicolon (;). A physical line in this file is limited to 1024 characters. You can split a logical line into multiple physical lines using the backslash (\) continuation character. Entries are terminated either by a line that does not end in a semicolon, one or more blank lines, or both.
The rule parameters currently provided are shown in Table 5-11. Parameters not listed in the table are ignored.
Predefined Environment Variables
Table 5-12 shows the basic set of environment variables available for use by the conversion command.
Additional environment variables containing Content-type: parameter information or Content-disposition: parameter information can be created as needed using the PARAMETER-SYMBOL-n or DPARAMETER-SYMBOL-n parameters respectively.
Table 5-13 displays additional override options available for use by the conversion channel. The converter procedure may use these to pass information back to the conversion channel. To set these options, set OVERRIDE-OPTION-FILE=1 in the desired conversion entry and then have the converter procedure set the desired options in the OUTPUT_OPTIONS file.
Mapping File
Many components of the MTA employ table lookup-oriented information. Generally speaking, this sort of table is used to transform (that is, map) an input string into an output string. Such tables, called mapping tables, are usually presented as two columns, the first (or left-hand) column giving the possible input strings and the second (or right-hand) column giving the resulting output string for the input it is associated with. Most of the MTA databases are instances of just this sort of mapping table. The MTA database files, however, do not provide wildcard-lookup facilities, owing to inherent inefficiencies in having to scan the entire database for wildcard matches.
The mapping file provides the MTA with facilities for supporting multiple mapping tables. Full wildcard facilities are provided, and multistep and iterative mapping methods can be accommodated as well. This approach is more compute-intensive than using a database, especially when the number of entries is large. However, the attendant gain in flexibility may serve to eliminate the need for most of the entries in an equivalent database, and this may result in lower overhead overall.
For discussion on REVERSE and FORWARD address mapping, see the iPlanet Messaging Server Administrator's Guide.
Locating and Loading the Mapping File
All mappings are kept in the MTA mapping file. (This is the file specified with the IMTA_MAPPING_FILE option in the MTA tailor file; by default, this is server_root/msg-instance/imta/config/mappings.) The contents of the mapping file is incorporated into the compiled configuration.
The mapping file should be world readable. Failure to allow world-read access leads to erratic behavior.
File Format in the Mapping File
The mapping file consists of a series of separate tables. Each table begins with its name. Names always have an alphabetic character in the first column. The table name is followed by a required blank line, and then by the entries in the table. Entries consist of zero or more indented lines. Each entry must be preceded by at least one space. Each entry line consists of two columns separated by one or more spaces or tabs. Any spaces within an entry must be quoted using the $ character. A blank line must appear after each mapping table name and between each mapping table; no blank lines can appear between entries in a single table. Comments are introduced by an exclamation mark (!) in the first column.
The resulting format looks like:
An application using the mapping table TABLE-2-NAME would map the string pattern2-2 into whatever is specified by template2-2. Each pattern or template can contain up to 252 characters. There is no limit to the number of entries that can appear in a mapping (although excessive numbers of entries may consume huge amounts of CPU and can consume excessive amounts of memory). Long lines (over 252 characters) may be continued by ending them with a backslash (\). The white space between the two columns and before the first column may not be omitted.
Duplicate mapping table names are not allowed in the mapping file.
Including Other Files in the Mapping File
Other files may be included in the mapping file. This is done with a line of the form:
<file-spec
This effectively substitutes the contents of the file file-spec into the mapping file at the point where the include appears. The file specification should specify a full file path (directory, and so forth). All files included in this fashion must be world readable. Comments are also allowed in such included mapping files. Includes can be nested up to three levels deep. Include files are loaded at the same time the mapping file is loadedthey are not loaded on demand, so there is no performance or memory savings involved in using include files.
Mapping Operations
All mappings in the mapping file are applied in a consistent way. The only things that change from one mapping to the next is the source of input strings and what the output from the mapping is used for.
A mapping operation always starts off with an input string and a mapping table. The entries in the mapping table are scanned one at a time from top to bottom in the order in which they appear in the table. The left side of each entry is used as pattern, and the input string is compared in a case-blind fashion with that pattern.
Mapping Entry Patterns
Patterns can contain wildcard characters. In particular, the usual wildcard characters are allowed: an asterisk (*) matches zero or more characters, and each percent sign (%) matches a single character. Asterisks, percent signs, spaces, and tabs can be quoted by preceding them with a dollar sign ($). Quoting an asterisk or percent sign robs it of any special meaning. Spaces and tabs must be quoted to prevent them from ending prematurely a pattern or template. Literal dollar sign characters should be doubled ($$), the first dollar sign quoting the second one.
For more information about mapping pattern wildcards, see the section "Mapping File" in the chapter "About MTA Services and Configuration" in the iPlanet Messaging Server Administrator's Guide.
Mapping Entry Templates
Table 5-15 lists the special substitution and standard processing metacharacters. Any other metacharacters are reserved for mapping-specific applications.
See the iPlanet Messaging Server Administrator's Guide for more discussion on mapping entry templates.
For more information on the substitution sequences and metacharacters, see the "About MTA Services and Configuration" chapter in the iPlanet Messaging Server Administrator's Guide.
Option File
Global MTA options, as opposed to channel options, are specified in the MTA option file.
The MTA uses an option file to provide a means of overriding the default values of various parameters that apply to the MTA as a whole. In particular, the option file is used to establish sizes of the various tables into which the configuration and alias files are read.
Locating and Loading the MTA Option File
The option file is the file specified with the IMTA_OPTION_FILE option in the IMTA tailor file (server_root/msg-instance/imta/config/imta_tailor). By default, this is server_root/msg-instance/imta/config/option.dat.
Option File Format and Available Options
Option files consist of several lines. Each line contains the setting for one option. An option setting has the form:
option=value
The value may be either a string, an integer, or a floating point value depending on the option's requirements. If the option accepts an integer value, a base may be specified using notation of the form b%v, where b is the base expressed in base 10 and v is the actual value expressed in base b.
Comments are allowed. Any line that begins with an exclamation point (!) is considered to be a comment and is ignored. Blank lines are also ignored in any option file.
The available options are listed in Table 5-16.
Table 5-16    Option File Options
Options
Description
If ACCESS_ERRORS is set to 0 (the default), when an address causes an access failure the MTA reports it as an "illegal host or domain" error. This is the same error that would occur if the address were simply illegal. Although confusing, this usage provides an important element of security in circumstances where information about restricted channels should not be revealed. Setting ACCESS_ERRORS to 1 overrides this default and provide a more descriptive error.
Specifies whether or not the ORCPT address is used in various mappings.
Controls the format of alias file and alias database lookups. This option takes a bit-encoded integer as its argument. The default value is 1, meaning that alias file and alias database lookups probe with only the local part (mailbox portion) of the address. Not 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. If all bits are set, that is ALIAS_DOMAIN=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.
Specifies a URL to query for alias lookups. The URL must be specified using standard LDAP URL syntax, except the LDAP server and port must be omitted. The LDAP server and port are specified via the LDAP_HOST and LDAP_PORT options.
See "MTA Direct LDAP Operation" in the iPlanet Messaging Server Administrator's Guide for certain substitution sequences.
Sets the size of the alias hash table. This is an upper limit on the number of aliases that can be defined in the alias file. The default is 256; the maximum value is 32,767.
Controls the size of the index table that contains the list of alias translation value pointers. The total number of addresses on the right sides of all of the alias definitions in the alias file cannot exceed this value. The default is 320; the maximum value is 20,000.
Places an absolute limit on the size, in blocks, of any message that may be sent or received with the MTA. Any message exceeding this size is rejected. By default, the MTA imposes no size limits. Note that the blocklimit channel keyword can be used to impose limits on a per-channel basis. The size in bytes of a block is specified with the BLOCK_SIZE option.
The MTA uses the concept of a "block" in several ways. For example, the MTA log files (resulting from placing the logging keyword on channels) record message sizes in terms of blocks. Message size limits specified using the maxblocks keyword are also in terms of blocks. Normally, an MTA block is equivalent to 1024 characters. This option can be used to modify this sense of what a block is.
Used to force bounces of messages over the specified size to return only the message headers, rather than the full message content.
Controls the size of the channel table. The total number of channels in the configuration file cannot exceed this value. The default is 256; the maximum is 32,767.
Sets the comment characters in the MTA configuration files. The value of this option takes the form of a list of ASCII character values in decimal. The default is the list {33, 59}, which specifies exclamation points and semicolons as comment introduction characters.
Specifies the maximum size of an originating message that will be returned in a notification message. If the original message content is larger than this size, then the message will not be returned in a notification message. The units are in blocks (see BLOCK_SIZE).
Controls the size of the conversion entry table, and thus the total number of conversion file entries cannot exceed this number. The default is 32.
Specifies whether debugging output from the MTA's dequeue facility (QU) is produced. If enabled with a value of 1, this output is produced on all channels that use the QU routines. The default of 0 disables this output.
Determines whether or not a message is mapped into memory when dequeuing. The default is 1.
Controls the size of the domain rewrite rules hash table. Each rewrite rule in the configuration file consumes one slot in this hash table; thus the number of rewrite rules cannot exceed this option's value. The default is 512; the maximum number of rewrite rules is 32,767.
Controls the application of the 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.
Specifies the maximum size of the table that tracks the list of files contributed to the configuration.
Specifies a maximum header size. If the message's header exceeds this limit, the message is rejected.
Controls how many delivery attempt history records are included in returned messages. The delivery history provides an indication of how many delivery attempts were made and might indicate the reason the delivery attempts failed. The default value for this option is 20.
Controls the production of operator messages when a message is forced into a held state because it has too many Received: header lines. The default is 0 and specifies that the syslog messages are not generated when messages or forced to .HELD status due to too many Received: header lines. The value of 1 specifies that syslog messages are generated.
Controls the size of the channel hosts hash table. Each channel host specified on a channel definition in the MTA configuration file (both official hosts and aliases) consumes one slot in this hash table, so the total number of channel hosts cannot exceed the value specified. The default is 512; the maximum value allowed is 32,767.
Specifies the domain name to use when constructing message IDs. By default, the official host name of the local channel is used.
Controls the application of the 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.
Specifies the default attribute if no attribute is specified in the LDAP query for URLs that are supposed to return a single result.
Specifies the size of the internal table of LDAP attribute names.
Specifies the default host to which to connect when performing LDAP queries.
Specifies the port to which to connect when performing LDAP queries. The default value is 389, the standard LDAP port number.
Controls the length of time to wait (in hundredths of seconds) before timing out on an LDAP query. The default value is 200.
Places an absolute limit on the overall number of lines in any message that may be sent or received with the MTA. Any message exceeding this limit is rejected. By default, the MTA imposes no line-count limits.The linelimit channel keyword can be used to impose limits on a per channel basis.
Controls how many lines of message content the MTA includes when generating a notification message for which it is appropriate to return on a sample of the contents. The default is 20.
The LOG_CONNECTION option controls whether or not connection information, for example, the domain name of the SMTP client sending the message, is saved in mail.log file entries and the writing of connection records when the logging channel keyword is enabled for the channel. This value is a decimal integer representing a bit-encoded integer, the interpretation of which is given below:
Bit-0 Value-1: When set, connection information is included in E and D log records.
Bit-1 Value-2: When set, connection open, close, and fail records are logged by message enqueue and dequeue agents such as the SMTP clients and servers.
Bit-2 Value-4: When set, I records are logged recording ETRN events.
Where Bit 0 is the least significant bit.
This channel option defaults to the setting of the global MTA option LOG_CONNECTION as set in the MTA option file. This channel option may be set explicitly to override on a per-channel basis the behavior requested by the global option.
Sends MTA connection log file entries to syslog (UNIX) or event log (Windows NT). 0 is the default and indicates that syslog (event log) logging is not performed. A value of 1 indicates that syslog logging is performed.
Specifies the bins for delivery delay range counters. The parameters for this options should be a comma-separated list of up to five integers. The default values are 60, 600, 6000, 60000, 600000.
Controls whether the names of the files in which messages are stored are saved in the mail.log file. A value of 1 enables file name logging. A value of 0 (the default) disables it.
Controls formatting options for the mail.log file. A value of 1 (the default) is the standard format. A value of 2 requests non-null formatting: empty address fields are converted to the string "<>." A value of 3 requests counted formatting: all variable length fields are preceded by N, where N is a count of the number of characters in the field.
Specifies the limit of "frustration counts." In a process, if repeated retries of writing a counter fails, the "frustration count" is incremented. Once the count reaches this limit, that process stops attempting to write counters.
Controls whether the MTA writes message headers to the mail.log file. A value of 1 enables message header logging. The specific headers written to the log file are controlled by a site-supplied log_header.opt file. The format of this file is that of other MTA header option files. For example, a log_header.opt file containing the following would result in writing the first To and the first From header per message to the log file. A value of 0 (the default) disables message header logging:
Controls whether the domain name for the local host is appended to logged addresses that don't already contain a domain name. A value of 1 enables this feature, which is useful when logs from multiple systems running the MTA are concatenated and processed. A value of 0, the default, disables this feature.
Controls whether message IDs are saved in the mail.log file. A value of 1 enables message ID logging. A value of 0 (the default) disables it.
Sends MTA message log file entries to syslog (UNIX) or event log (Windows NT). 0 is the default and indicates that syslog (event log) logging is not performed. A value of 1 indicates that syslog logging is performed.
Controls the production of syslog messages by the MTA message logging facility.
Specifies the bin sizes for message size range counters. The value is a comma-separated list of up to five integers. The default values are 2, 10, 50, 100, 500.
Controls whether the user name associated with a process that enqueues mail is saved in the mail.log file. A value of 1 enables user name logging. A value of 0 (the default) disables it.
Specifies the size of the mapping table name table, and thus the total number of mapping table cannot exceed this number. The default is 32.
Controls the degree of indirection allowed in aliases; that is, how deeply aliases may be nested, with one alias referring to another alias, and so forth. The default value is 10.
Controls what fraction of the available message blocks can be used by message headers.
Controls what fraction of the available message lines can be used by message headers.
Specifies how large (in MTA blocks) a message the MTA keeps entirely in memory; messages larger than this size is written to temporary files. The default is 10. For systems with lots of memory, increasing this value may provide a performance improvement.
As the MTA processes a message, it scans any Received: header lines attached to the message looking for references to the official local host name. (Any Received line that the MTA inserts contains this name.) If the number of Received lines containing this name exceeds the MAX_LOCAL_RECEIVED_LINES value, the message is entered in the MTA queue in a held state. The default for this value is 10 if no value is specified in the option file. This check blocks certain kinds of message forwarding loops. The message must be manually moved from the held state for processing to continue.
Specify the maximum depth to which the MTA should process MIME messages. The default is 100, which means that the MTA processes up to 100 levels of message nesting.
Specify the maximum number of MIME parts that the MTA should process in a MIME message.
As the MTA processes a message, it counts the number of Received: header lines in the message's header. If the number of Received lines exceeds the MAX_RECEIVED_LINES value, the message is entered in the MTA queue in a held state. The default for this value is 50 if no value is specified in the option file. This check blocks certain kinds of message forwarding loops. The message must be manually moved from the held state for processing to continue.
Used to instruct the MTA to downgrade the priority of messages based on size: messages above the specified size is downgraded to non-urgent priority. This priority, in turn, affects the processing priority of the messagehow quickly the Job Controller processes the message.
Used to instruct the MTA to downgrade the priority of messages based on size: Messages above the specified size is downgraded to lower than nonurgent priority. The value is interpreted in terms of MTA blocks, as specified by the BLOCK_SIZE option. Note also that the nonurgentblocklimit channel keyword may be used to impose such downgrade thresholds on a per channel basis.
Specifies mailing list access controls are OR'ed by default, instead of AND'ed.
Sets the domain name to use when constructing Received headers. By default, the official host name of the local channel is used.
Sets the iPlanet Messaging Server version string that is to be used when constructing Received: header lines. By default, the string "(iPlanet Messaging Server version-info)" is used; use of the default is strongly recommended. Note that this option is a complement to the (also not recommended) CUSTOM_VERSION_STRING TCP/IP SMTP channel option.
In the above description, note the mention of constructing a Received: header line; that is, this option does not change already present Received: header lines, but rather only affects what is used when generating a new Received: header line. Also note that this option is option and the CUSTOM_VERSION_STRING option should not be used.
A non-ASCII string could be specified, but the MTA would then have to MIME encode the non-ASCII characters. Since user agent handling of MIME encoded header lines is not always useful, specifying a non-ASCII value would be inadvisable. So while the value is not strictly limited to being an ASCII string, it is not recommended to use anything other than ASCII.
Sets the return address for the local postmaster. The local postmaster's address is postmaster@localhost by default, but it can be overridden with the address of your choice. Care should be taken in the selection of this addressan illegal selection may cause rapid message looping and pileups of huge numbers of spurious error messages.
Enables or disables debugging output in the nightly message bouncer batch job. A value of 0 disables this output (the default), while a value of 1 enables it. Debugging output, if enabled, appears in the output log file, if such a log file is present. The presence of an output log file is controlled by the crontab entry for the return job.
Controls whether or not a history of delivery attempts is included in returned messages. The delivery history provides some indication of how many delivery attempts were made and, in some cases, indicates the reason the delivery attempts failed. A value of 1 enables the inclusion of this information and is the default. A value of 0 disables return of delivery history information. The HISTORY_TO_RETURN option controls how much history information is actually returned.
Takes a single integer value, which is interpreted as a set of bit flags. Bit 0 (value = 1) controls whether return notifications generated by the MTA are written with a blank envelope address or with the address of the local postmaster. Setting the bit forces the use of the local postmaster address; clearing the bit forces the use of a blank addresses. Note that the use of blank address is mandated by RFC 1123. However, some systems do not handle blank-envelope-from-address properly and may require the use of this option. Bit 1 (value = 2) controls whether the MTA replaces all blank envelope addresses with the address of the local postmaster. Again, this is used to accommodate noncompliant systems that don't conform to RFC 821, RFC 822, or RFC 1123. Note that the returnenvelope channel keyword can be used to impose this sort of control on a per-channel basis.
Specifies the personal name to use when the MTA generates postmaster messages (for example, bounce messages). By default, the MTA uses the string, Internet Mail Delivery.
Controls the time units used by the message return system. A value of 0 selects units of days. A value of 1 selects units of hours. By default, units of days are used. On UNIX systems, the scheduling of the execution of the message return job is performed by changing the crontab entry and controlling when it runs. On Windows NT systems, the scheduling of execution of the message return job is performed by the Scheduler.
Controls whether the MTA applies the address reversal to envelope From addresses as well as header addresses. This option has no effect if the USE_REVERSE_DATABASE option is set to 0 or if the reverse database and reverse mapping does not exist. The default is 1, which means that the MTA attempts to apply the database to envelope From addresses. A value of 0 disables this use of the address reversal database.
Controls whether the connection log information generated by setting LOG_CONNECTION =1 is stored in the usual the MTA message logging files, mail.log* or is stored separately in connection.log* files. The default (0) causes connection logging to be stored in the regular message log files; 1 causes the connection logging to be stored separately.
Sets the syslog level of syslog messages or the severity of the Windows NT event log entry.
For syslog, this option corresponds to the priority argument of the syslog call. Both the facility and severity can be set by applying a logical OR operation to the desired values. On Solaris, see /usr/include/sys/syslog.h for a definition of valid values. Be sure to coordinate setting the SNDOPR_PRIORITY option with how syslog messages are handled, as controlled by the syslog.conf file.
Enforces strict Sieve compliance for location of require clauses. The default is 0.
Controls the number of character slots allocated to the string pool used to hold rewrite rule templates and alias list members. A fatal error occurs if the total number of characters consumed by these parts of the configuration and alias files exceeds this limit. The default is 60,000; the maximum allowed value is 10,000,000.
Used to instruct the MTA to downgrade the priority of messages based on size: messages above the specified size are downgraded to normal priority. This priority, in turn, affects the Job Controller's processing priority for processing the message. The value is interpreted in terms of the MTA blocks, as specified by the BLOCK_SIZE option. Note also that the urgentblocklimit channel keyword may be used to impose such downgrade thresholds on a per-channel basis.
Controls whether the MTA uses the alias database as a source of system aliases for local addresses. The default (1), means that the MTA checks the database if it exists. A value of 0 disables this use of the alias database.
Controls the use of the domain database. The default (1) means that the MTA checks the database if it exists.
Controls whether the MTA uses the information contained in Errors-to header lines when returning messages. Setting this option to 1 directs the MTA to make use of this header line. The default (0), disable uses of this header line.
Controls whether the MTA uses the address reversal database and REVERSE mapping as a source of substitution addresses. This value is a decimal integer representing a bit-encoded integer, the interpretation of which is given in Table 5-17.
Controls whether the MTA uses the information contained in Warnings-to header lines when returning messages. Setting this option to 1 directs the MTA to make use of these header lines. The default is 0, which disables use of this header line.
Controls the total number of patterns that appear throughout mapping tables. the default is 8000. The maximum allowed is 200,000.
Note that bit 0 is the least significant bit.
The default value for USE_REVERSE_DATABASE is 5, which means that the MTA reverse envelope From addresses and both backward and forward pointing addresses after they have passed through the normal address rewriting process. Simple address strings are presented to both REVERSE mapping and the reverse database. A value of 0 disables the use of the address reversal completely.
Header Option Files
Some special option files may be associated with a channel that describe how to trim the headers on messages queued to that channel or received by that channel. This facility is completely general and may be applied to any channel; it is controlled by the headertrim, noheadertrim, headerread, and noheaderread channel keywords.
Various MTA channels have their own channel-level option files as well. Header option files have a different format than other MTA option files, so a header option file is always a separate file.
Header Option File Location
For destination channel based header trimming to be applied upon message enqueue after normal header processing, the MTA looks in the config directory (server_root/msg-instance/imta/config) for header options files with names of the form channel_headers.opt, where channel is the name of the channel with which the header option file is associated. The headertrim keyword must be specified on the channel to enable the use of such a header option file.
For source channel based header trimming to be applied upon message enqueue before normal header processing, the MTA looks in the config directory (server_root/msg-instance/imta/config) for header options files with names of the form channel_read_headers.opt, where channel is the name of the channel with which the header option file is associated. The headerread keyword must be specified on the channel to enable the use of such a header option file.
Header option files should be world readable.
Header Option File Format
Simply put, the contents of a header option file are formatted as a set of message header lines. Note, however, that the bodies of the header lines do not conform to RFC 822.
The general structure of a line from a header options file is:
Header-name: OPTION=VALUE, OPTION=VALUE, OPTION=VALUE, ...
Header-name is the name of a header line that the MTA recognizes (any of the header lines described in this manual may be specified, plus any of the header lines standardized in RFC 822, RFC 987, RFC 1049, RFC 1421, RFC 1422, RFC 1423, RFC 1424, RFC 1327, and RFC 1521 (MIME).
Header lines not recognized by the MTA are controlled by the special header line name Other:. A set of options to be applied to all header lines not named in the header option file can also be given on a special Defaults: line. The use of Defaults: guards against the inevitable expansion of the MTA's known header line table in future releases.
Various options can then be specified to control the retention of the corresponding header lines. The available options are listed in Table 5-18.
Tailor File
The MTA tailor file (imta_tailor) is an option file in which the location of various MTA components are set. This file must always exist in the server_root/msg-instance/imta/config directory for the MTA to function properly. The file may be edited to reflect the changes in a particular installation. Some options in the file should not be edited. The MTA should be restarted after making any changes to the file. It is preferable to make the changes while the MTA is down.
An option setting has the form:
option=value
The value can be either a string or an integer, depending on the option's requirements. Comments are allowed. Any line that begins with an exclamation point is considered to be a comment and is ignored. Blank lines are also ignored. Options that are available and can be edited are shown in Table 5-19.
Note This file is not used in direct LDAP mode.
This file is used to set options for the dirsync program that cannot be set through the command line. This file (dirsync.opt) should be located in the MTA configuration directory. In this file, any line that begins with an exclamation point is considered to be a comment and is ignored. Blank lines are also ignored. The format of this file is:
option=value
The value may be either a string or an integer, depending on the option's requirements. If any of the options in this file are changed, perform a full dirsync after the change. The available options are as follows:
Autoreply Option File
This file is used for setting options for the autoreply or vacation program. This file should be located in the MTA configuration directory. In this file, any line that begins with an exclamation point is considered to be a comment and is ignored. Blank lines are also ignored The format of this file is:
option=value
The value may be either a string or an integer, depending on the option's requirements.
The available options are:
Job Controller Configuration
At startup, the Job Controller reads a configuration file that specifies parameters, pools, and channel processing information. This configuration information is specified in the file job_controller.cnf in the server_root/msg-instance/imta/config/ directory.
For more information on the Job Controller, see the "About MTA Services and Configuration" chapter in the iPlanet Messaging Server Administrator's Guide.
Job Controller Configuration File
In accordance with the format of the MTA option files, the Job Controller configuration file contains lines of the form:
option=value
In addition to option settings, the file may contain a line consisting of a section and value enclosed in square-brackets ([ ]) in the form:
[section-type=value]
Such a line indicates that option settings following this line apply only to the section named by value. Initial option settings that appear before any such section tags apply globally to all sections. Per section option settings override global defaults for that section. Recognized section types for the Job Controller configuration file are POOL, to define pools and their parameters, and CHANNEL, to define channel processing information, and PERIODIC_JOB for the various periodic jobs started by the Job Controller.
Any options permitted on POOL or CHANNEL sections can be specified at the beginning (general options), thus becoming the default for the option.
The Job Controller configuration file options are described in the following three tables (Table 5-22, Table 5-23, and Table 5-24). They are split into general options, pool options, and channel options groups.
Table 5-22 shows the general Job Controller configuration options.
Table 5-23 describes the POOL option for the Job Controller configuration.
Table 5-24 describes the CHANNEL options for the Job Controller configuration.
Dispatcher
The MTA multithreaded Dispatcher is a multithreaded connection dispatching agent that permits multiple multithreaded servers to share responsibility for a given service. When using the Dispatcher, it is possible to have several multithreaded SMTP servers running concurrently. In addition to having multiple servers for a single service, each server may handle simultaneously one or more active connections.
Dispatcher Configuration File
The Dispatcher configuration information is specified in the server_root/msg-instance/imta/dispatcher.cnf file. A default configuration file is created at installation time and can be used without any changes made. However, if you want to modify the default configuration file for security or performance reasons, you can do so by editing the dispatcher.cnf file.
Configuration File Format
The Dispatcher configuration file format is similar to the format of other MTA configuration files. Lines specifying options have the following form:
option=value
The option is the name of an option and value is the string or integer to which the options is set. If the option accepts an integer value, a base may be specified using notation of the form b%v, where b is the base expressed in base 10 and v is the actual value expressed in base b. Such option specifications are grouped into sections corresponding to the service to which the following option settings apply, using lines of the following form:
[SERVICE=service-name]
The service-name is the name of a service. Initial option specifications that appear before any such section tag apply globally to all sections.
Table 5-25 shows the available options.
Table 5-25    Dispatcher configuration file options
Option
Description
Controls the depth of the TCP backlog queue for the socket. The default value for each service is MAX_CONNS*MAX_PROCS (with a minimum value of 5). This option should not be set higher than the underlying TCP/IP kernel supports.
Enables debugging output. Enabling all debugging is done by setting the option to -1. The actual meaning of each bit is described in Table 5-26.
Specifies the host name or IP address of source against which to check incoming connections. Various groups maintain information about unsolicited email sources or open relay sites. Some sites check incoming IP connections against the lists maintained by such groups. Up to five DNS_VERIFY_DOMAIN options can be specified for each service. Note that SMTP is typically the only service for which such checks make sense. For example:
DNS_VERIFY_DOMAIN=rbl.maps.siroe.com
DNS_VERIFY_DMAIN=dul.maps.siroe.com
If this options is enabled on a well known port (25, 110, or 143), then a standard message such as the one below is sent before the connection is closed:
500 5.7.1 access_control: host 192.168.51.32 found on DNS list and rejected
If you wish the MTA to log such rejections, the 24th bit of the Dispatcher debugging DEBUG option can be set (DEBUG=16%1000000) to cause logging of the rejections to the dispatcher.log file. Log entries take the following form:
Specifying ENABLE_RBL=1 causes the Dispatcher to compare incoming connections to the "Black Hole" list at maps.siroe.com. For instance, if the Dispatcher receives a connection from 192.168.51.32, then it attempts to obtain the IP address for the hostname 32.51.168.192.rbl.maps.siroe.com. If the query is successful, the connection is closed rather than handed off to a worker process. If this option is enabled on a well-known port (25, 110, or 143), then a standard message such as the one below is sent before the connection is closed:
5.7.1 Mail from 192.168.51.32 refused, see http://maps.siroe.com/rbl/
If you want the MTA to log such rejections, set bit 24 of the Dispatcher debugging DEBUG option, DEBUG=16%1000000, to cause logging of the rejections to the dispatcher.log file; entries take the form:
access_control: host a.b.c.d found on DNS list and rejected
See the section "To Use DNS Lookups Including RBL Checking for SMTP Relay Blocking" in the "Mail Filtering and Access Control" chapter of the iPlanet Messaging Server Administrator's Guide for more information.
Controls how long the expired connections (those that have been closed) and processes (those that have exited) remain listed for statistical purpose in the Dispatcher statistics.
The INTERFACE_ADDRESS option can be used to specify the IP address interface to which the Dispatcher service should bind. By default, the Dispatcher binds to all IP addresses. But for systems having multiple network interfaces each with its own IP address, it may be useful to bind different services to the different interfaces. Note that if INTERFACE_ADDRESS is specified for a service, then that is the only interface IP address to which that Dispatcher service bind. Only one such explicit interface IP address may be specified for a particular service (though other similar Dispatcher services may be defined for other interface IP addresses).
If IDENT=1 is set for a service, it causes the Dispatcher to try an IDENT query on incoming connections for that service, and to note the remote username (if available) as part of the Dispatcher statistics. The default is IDENT=0, meaning that no such query is made.
Specifies the image that is run by server processes when created by the Dispatcher. The specified image should be one designed to be controlled by the Dispatcher.
Causes the Dispatcher to direct output for corresponding server processes to the specified file. LOGFILE can include a %s which includes the local system's hostname in the file specification. For example, LOGFILE=tcp_smtp_server_%s.log on node freddy results in log files with the name tcp_smtp_server_freddy.log-*.
Specifies a maximum number of connections that may be active on any server process. The MAX_CONNS option affects the Dispatcher's management of connections. When the maximum number of concurrent sessions is reached, the server process stops listening for new connections. When all currently open connections are closed, the original server exits. The default value for MAX_CONNS is 10. The maximum possible value for MAX_CONNS is 50.
For the multithreaded SMTP server, the choice of setting this option is mainly a performance issue relating to the number of processes and the size of the process virtual address space.
Setting MAX_CONNS to higher values allows more connections, but at the potential cost of decreased performance for each individual connection. If it is set to 1, then for every incoming client connection, only one server process is used. When the client shuts down, the server process also exits. Note that the value of MAX_CONNS multiplied by the value of MAX_PROCS controls the maximum number of simultaneous connections that can be accepted.
Specifies the maximum number of concurrent asynchronous hand-offs in progress that the Dispatcher allows for newly established TCP/IP connections to a service port. The default value is 5.
Specifies the maximum idle time for a server process. When an server process has had no active connections for this period, it becomes eligible for shutdown. This option is only effective if there are more than the value of MIN_PROCS server processes currently in the Dispatcher's pool for this service.
Specifies the maximum number of connections an server process can handle in its lifetime. Its purpose is to perform worker-process housekeeping.
Requests that server processes be kept only for the specified number of seconds. This is part of the Dispatcher's ability to perform worker-process housekeeping. When an server process is created, a countdown timer is set to the specified number of seconds. When the countdown time has expired, the SMTP server process is subject to shutdown.
Controls the maximum number of server processes that are created for this service.
Specifies the maximum number of server processes available before the Dispatcher shuts down. In order to provide a minimum availability for the service, the Dispatcher does not shut down server processes that might otherwise be eligible for shutdown if shutting them down results in having fewer than MAX_SHUTDOWN server processes for the service. This means that processes that are eligible for shutdown can continue running until a shutdown "slot" is available.
Determines the minimum number of connections that each Worker Process must have before considering the addition of a new server process to the pool of currently available server processes. The Dispatcher attempts to distribute connections evenly across this pool.
Determines the minimum number of server processes that are created by the Dispatcher for the current service. Upon initialization, the Dispatcher creates this many detached processes to start its pool. When a process is shut down, the Dispatcher ensures that there are at least this many available processes in the pool for this service.
The interpretation and allowed values for the PARAMETER option are service specific. In the case of an SMTP service, the PARAMETER option may be set to CHANNEL=channelname, to associate a default TCP/IP channel with the port for that service. For instance:
PARAMETER=CHANNEL=tcp_incoming
This can be useful if you want to run servers on multiple portsif your internal POP and IMAP clients have been configured to use a port other than the normal port 25 for message submission, separating their message traffic from incoming SMTP messages from external hostsand if you want to associate different TCP/IP channels with the different port numbers.
Specifies the TCP port(s) to which the Dispatcher listens for incoming connections for the current service. Connections made to this port are transferred to one of the SMTP server processes created for this service. Specifying PORT=0 disables the current service.
Specifies the thread stack size of the server. The purpose of this option is to reduce the chances of the server running out of stack when processing deeply nested MIME messages (several hundreds of levels of nesting). Note that these messages are in all likelihood spam messages destined to break mail handlers. Having the server fail protects other mail handlers farther down the road.
Debugging and Log Files
Dispatcher error and debugging output (if enabled) are written to the file dispatcher.log in the MTA log directory.
Debugging output may be enabled using the option DEBUG in the Dispatcher configuration file, or on a per-process level, using the IMTA_DISPATCHER_DEBUG environment variable (UNIX).
The DEBUG option or IMTA_DISPATCHER_DEBUG environment variable (UNIX) defines a 32-bit debug mask in hexadecimal. Enabling all debugging is done by setting the option to -1, or by defining the logical or environment variable system-wide to the value FFFFFFFF. The actual meaning of each bit is described in Table 5-26.
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated August 15, 2002