Sun Java System Messaging Server 6 2005Q4 Administration Reference

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 inTable 4–6 and Table 4–7; the keywords shown in boldface are defaults. Table 4–6 lists channel keywords alphabetically; Table 4–7lists 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 4–6 Channel Keywords Listed Alphabetically


Keyword	Usage
`733`	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. Syntax: `733`
`822`	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. Syntax: `822`
`addreturnpath`	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. Syntax: `addreturnpath` `header` `header` is the header line to be added.
`addrsperfile`	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. Syntax: `addrsperfile` `integer` `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.
`addrsperjob`	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. Syntax: `addrsperjob` `integer` `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.
`aliasdetourhost`	Allows source-channel-specific overriding of a hosted user's `mailHost` attribute value. In particular, `aliasdetourhost` is commonly used to achieve a “detour” in the routing of messages destined for local (hosted on this system) users to a separate host for some kind of processing. A message can be verified (the address is a legitimate local address) on the original host, detoured to the processing host, and then returned to the original host for expansion and delivery. `aliasdetourhost` allows better configuration and use of “intermediate filtering” sorts of channels and third party filtering hosts. `aliasdetourhost` is usually used in addition to use of an alternate conversion channel. `aliasdetourhost` is used to affect the routing for the local (hosted on this system) users, while an alternate conversion channel is used to affect the routing for remote recipients.
`aliaslocal`	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. Syntax: `aliaslocal`
`aliaspostmaster`	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. Syntax: `aliaspostmaster`
`allowetrn`	Honor all ETRN commands. 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. Syntax: `allowetern`
`allowswitchchannel`	Allow the source channel to switch to this channel. Syntax: `allowswitchchannel` `channel`
`alternatechannel`	Specify an alternate channel to which to enqueue a message when at least one of `alternateblocklimit`, `alternatelinelimit`, or `alternaterecipientlimit` is exceeded. If any of the `alternatelimit` channel keyword limits is exceeded, the message is diverted to the `alternatechannel`. Using one or more `alternatelimit` keywords without using alternatechannel does not cause an error; instead, it is merely ignored. Therefore, using `alternatelimit` keywords have no effect unless the `alternatechannel` keyword is specified. Syntax*: `alternatechannel` `channel`
`alternateblocklimit`	Specify the maximum number of MTA blocks allowed per message on the original channel where the `alternatechannel` keyword is placed. Messages exceeding this number of blocks are forced to the channel’s `alternatechannel`. Note that the interpretation of block size can be changed in the MTA options file by modifying the `BLOCK_SIZE` option. Syntax: `alternateblocklimit` `integer` default: no limit
`alternatelinelimit`	Specify the maximum number of lines allowed per message on the original channel where the `alternatechannel` keyword is placed. Messages exceeding this number of lines are forced to the channel’s `alternatechannel`. Syntax: `alternatelinelimit` `integer` default: no limit
`alternaterecipientlimit`	Specify a limit on envelope recipients for a message copy on the original channel where the `alternatechannel` keyword is placed. Messages exceeding this number of envelope recipients on a message copy are forced to the channel’s `alternatechannel`. The `alternaterecipientlimit` value is checked before addresses are split up into separate files due to channel keywords such as `addrsperfile`, `single`, or `single_sys`. Consequently, the `alternaterecipientlimit` value is compared against the total number of recipients (of the message in question) being enqueued to the channel in question, rather than being compared against the possibly smaller number of such recipients that may be stored in a particular disk file in the channel in question’s queue area. Syntax: `alternaterecipientlimit` `integer` default: no limit
`authrewrite`	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. Syntax: `authrewrite` `integer` `integer` can be one of the following: 0 - Don’t change anything (default) 1—Add a Sender: or a Resent-sender: header field containing the address provided by the authentication operation. The Resent- variant is used if other resent- fields are present. 2—Add a Sender: header containing the address provided by the authentication operation. 3 - Construct a probe in an AUTH_REWRITE mapping table of the form: `mail-from\|sender\|from\|auth-sender` See Messaging Server Administration Guide for more information. 4 - Same as 3 except the resent- variables are never used. 5 - Replace/add the From: or Resent-from: header field with the authenticated originator address. 6 - replace the From: header field with the authenticated originator address.
`backoff`	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`. Syntax: `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, 240normal: 60, 120, 120, 240, 240, 240, 480nonurgent: 120, 240, 240, 480, 480, 480, 960 See the Sun Java System Messaging Server 6 2005Q4 Administration Guide for complete usage and examples.
`bangoverpercent`	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. Syntax: `bangoverpercent`
`bangstyle`	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`. Syntax: `bangstyle`
`bidirectional`	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. Syntax: `bidirectional`
`blocketrn`	Do not honor ETRN commands. See allowetrn. Syntax: `blocketrn`
`blocklimit`	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. Syntax: `blocklimit` `integer`
`cacheeverything`	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. Syntax: `cacheeverything`
`cachefailures`	Cache only connection failure information. See cacheeverything. Syntax: `cachefailures`
`cachesuccesses`	Cache only connection success information. This keyword is equivalent to `nocache` for channels. See cacheeverything. Syntax: `cachesuccesses`
`channelfilter`	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. Syntax: `channelfilter` `filter` The `filter` argument is a required URL that describes the channel filter location.
`charset7`	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. Syntax: `charset7` `charsetname` The `charsetname` argument specifies the character set name.
`charset8`	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. Syntax: `charset8` `charsetname` The `charsetname` argument specifies the character set name.
`charsetesc`	Default character set to associate with 7-bit text messages containing the escape character. See charset7 and charset8. Syntax: `charsetesc` `charsetname` The `charsetname` argument specifies the character set name.
`checkehlo`	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. Syntax: `checkehlo`
`commentinc`	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. Syntax: `commentinc`
`commentmap`	Runs comment strings in message header lines through the `COMMENT_STRINGS` mapping table. See `commentinc`. Syntax: `commentmap`
`commentomit`	Remove comments from message header lines. See `commentinc`. Syntax: `commentomit`
`commentstrip`	Remove problematic characters from comment fields in message header lines. See `commentinc`. Syntax: `commentstrip`
`commenttotal`	Strip comments (material in parentheses) from all header lines, except Received: header lines; this keyword is not normally useful or recommended. See `commentinc`. Syntax: `commenttotal`
`connectalias`	Does not rewrite addresses upon message dequeue and deliver to whatever host is listed in the recipient address. Syntax:`connectalias`
`connectcanonical`	Rewrite addresses upon message dequeue and connect to the host alias for the system to which the MTA would be connected. Syntax: `connectcanonical`
`connectrecipientlimit`	Limits the number of session recipients in an SMTP session. Syntax:`disconnectrecipientlimit` integer
`copysendpost`	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. Syntax: `copysendpost`
`copywarnpost`	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. Syntax: `copywarnpost`
`daemon`	Specify the name or IP address 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` or `daemon` `[IP address]` 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 or a domain literal in square brackets, the argument is ignored and the channel connects to the channel’s official host.
`datefour`	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. Syntax: `datefour`
`datetwo`	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. Syntax: `datetwo`
`dayofweek`	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. Syntax: `dayofweek`
`defaulthost`	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.
`defaultnameservers`	Use TCP/IP stack’s choice of nameservers. Syntax: `defaultnameservers`
`defaultmx`	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 Syntax: `defaultmx`
`deferralrejectlimit`	Sets a limit on the number of bad `RCPT TO:` addresses that are allowed during a single session. After the specified number of `To:` addresses have been rejected, all subsequent recipients, good or bad, are rejected with a `4xx` error. Provides same functionality as the `ALLOW_REJECTIONS_BEFORE_DEFERRAL SMTP` channel keyword, but on a per-channel basis. Syntax: `deferralrejectlimit` `integer` where `integer` is the specified number of bad `RCPT TO`: addresses that are allowed in a single session.
`deferred`	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. Syntax: `deferred`
`defragment`	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. Syntax: `defragment`
`dequeue_removeroute`	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. Syntax: `dequeue_removeroute`
`destinationbrightmail`	Specifies that all messages destined to this channel be subject to Brightmail processing if the recipient has opted in via the LDAP attribute `mailAntiUBEService` (or equivalent). Syntax: `destinationbrightmail`
`destinationbrightmailoptin`	Specifies that all messages destined to this channel will be subject to the specified brightmail processing (either spam or virus or both) even if those services have not been opted in by the user or domain via the LDAP attribute. The filter list follows the keyword. The list following must be either `spam` or `virus` or `spam,virus` or `virus,spam.` Example 1: `ims-ms destinationbrightmailoptin spam,virus. . .` All mail destined for the message store is scanned for both spam and virus by Brightmail
`destinationfilter`	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.
`destinationnosolicit`	The `NO-SOLICIT SMTP` extension (described in the Internet Draft `draft-malamud-no-soliciting-07.txt`) has been implemented with Messaging Server. This option specifies a comma-separated list of solicitation field values that will not be accepted in mail queued to this channel. Syntax: `destinationnosolicit` `value1, value2, value3...` where `value1, value2, value3` is a comma-separated list of solicitation field values.
`destinationspamfilterXoptin`	Run messages destined to this channel through spam filtering software X.
`disableetrn`	Disable support for the ETRN SMTP command. ETRN is not advertised by the SMTP server as a supported command. See allowetrn. Syntax: `disableetrn`
`disconnectbadauthlimit`	Used to place a limit on the number of unsuccessful authentication attempts that will be allowed in a session before the session is disconnected. Default: `3`.
`disconnectbadcommandlimit`	Limits the number of bad commands in an SMTP session. Syntax: `disconnectbadcommandlimit` integer
`disconnecttransactionlimit`	Limits the number of transactions in an SMTP session. Syntax: `disconnecttransactionlimit` integer
`disconnectrejectlimit`	Limits the number of rejected recipients in an SMTP session. Syntax: `disconnectrejectlimit` integer
`dispositionchannel`	Overrides the process channel as the place to initially queue message disposition notifications (MDNs). If the named channel does not exist, Messaging Server resumes using the process channel. Syntax: dispositionchannel `channel`
`domainetrn`	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. Syntax: `domainetrn`
`domainvrfy`	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. Syntax: `domainvrfy`
`dropblank`	Strip blank To:, Resent-To, Cc:, or Resent-Cc: headers from incoming messages if specified on a source channel. Syntax: `dropblank`
`ehlo`	Use EHLO on all initial SMTP connections. See checkehlo. Syntax: `ehlo`
`eightbit`	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). Syntax: `eightbit`
`eightnegotiate`	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 Syntax: `eightnegotiate`
`eightstrict`	Channel should reject incoming messages with headers that contain illegal eight bit data. Syntax: `eightstrict`
`errsendpost`	Send copies of failures to the postmaster if the originator address is illegal (cannot be returned). See copysendpost. Syntax: `errsendpost`
`errwarnpost`	Send copies of warnings to the postmaster if the originator address is illegal (cannot be returned). See copywarnpost. Syntax: `errwarnpost`
`expandchannel`	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. Syntax: `expandchannel`
`expandlimit`	Process an incoming message “offline” when the number of addressees exceeds this limit. Syntax: `expandlimit` `integer` 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.
`expnallow`	Allows `EXPN` even if it has been disabled at the SMTP server level with the `DISABLE_EXPAND` SMTP channel option. Syntax: `expnallow`
`expndisable`	Disables `EXPN` unconditionally. Syntax: `expndisable`
expndefault	Allows `EXPN` if the SMTP server is set to allow it. Syntax: `expndefault`
`exproute`	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. Syntax: `exproute`
`fileinto`	Specify effect on address when a mailbox filter `fileinto` operation is applied. The `fileinto` keyword is currently supported only for ims-ms and LMTP 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. For LMTP channels, the usual usage is:`fileinto @$4O:$U+$S@$D` where `$4O` is a 4 and the letter O, not the number zero.
`filesperjob`	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. Syntax: `filesperjob` `integer` 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.
`filter`	Specify the location of user filter files. The `filter` keyword may be used on the native and ims-ms channels. Syntax: `filter` `url` The argument for filter is a required URL describing the filter file location.
`forwardcheckdelete`	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. Syntax: `forwardcheckdelete`
`forwardchecknone`	No forward lookup is performed. See `forwardcheckdelete`. Syntax:`forwardchecknone`
`forwardchecktag`	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`. Syntax*: `forwardchecktag`
`header_733`	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. Syntax: `header_733`
`header_822`	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. Syntax: `header_822`
`header_uucp`	Use ! (bang-style) or UUCP routing in the header. The use of this keyword is not recommended. Such usage violates RFC 976. Syntax: `header_uucp`
`headerlabelalign`	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.
`headerlimit`	Imposes a limit on the maximum size of the primary (outermost) message header. The primary message headers are silently truncated when the limit is reached. If the global MTA option, `HEADER_LIMIT`, is set, it overrides this channel-level limit. Default: no limit
`headerlinelength`	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.
`headerread`	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. When the headerread keyword is used, the MTA will look for a file called `channel_read_headers.opt` where `channel` is the name of the channel. Syntax: `headerread`
`headertrim`	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. When the `headertrim` keyword is used, the MTA will look for a file called `channel_headers.opt` where `channel` is the name of the channel. Syntax: `headertrim`
`holdlimit`	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. Syntax: `holdlimit` `integer`
`holdexquota`	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. Syntax: `holdexquota`
`identnone`	Disable IDENT lookups; perform IP-to-hostname translation. Both IP number and host name are included in the Received: header lines for the message. Syntax: `identnone`
`identnonelimited`	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. Syntax: `identnonelimited`
`identnonenumeric`	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. Syntax: `identnonenumeric`
`identnonesymbolic`	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. Syntax: `identnonesymbolic`
`identtcp`	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. Syntax: `identtcp`
`identtcplimited`	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. Syntax: `identtcplimited`
`identtcpnumeric`	Perform IDENT lookups on incoming SMTP connections; disable IP to hostname translation. Syntax: `identtcpnumeric`
`identtcpsymbolic`	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. Syntax: `identtcpsymbolic`
`ignoreencoding`	Ignore Encoding: header on incoming messages. Syntax: `ignoreencoding`
`improute`	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. Syntax: `improute`
`includefinal`	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. Syntax: `includefinal`
`inner`	Parse messages and rewrite inner message headers. This keyword can be applied to any channel. Syntax: `inner`
`innertrim`	Apply header trimming rules from an options file to inner message headers for example, embedded MESSAGE/RFC822 headers (use with caution). When the `inntertrim` keyword is used, the MTA will look for a file called `channel_headers.opt` where `channel` is the name of the channel. Syntax: `innertrim`
`interfaceaddress`	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. Syntax: `interfaceaddress` `address`
`interpretencoding`	Interpret Encoding: header on incoming messages, if otherwise configured to do so. Syntax: `interpretencoding`
`language`	Specifies the default language of encoded words in headers. Syntax: `language` `default_language`
`lastresort`	Specify a host to 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. Syntax: `lastresort` `host` The keyword requires a single parameter specifying the name of the “system of last resort.”
`linelength`	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. Syntax: `linelength` `length`
`linelimit`	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. Syntax: `linelimit` `integer`
`lmtp`	Specifies that this channel uses LMTP rather than SMTP. Do not use the `smtp` and `lmtp` keywords on the same channel. Syntax: `lmtp`
`localvrfy`	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. Syntax: `localvrfy`
`logging`	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 `msg_svr_base/log/imta/mail.log_current`. Syntax: `logging`
`loopcheck`	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. Syntax: `loopcheck`
`mailfromdnsverify`	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. Syntax: `mailfromdnsverify`
`master`	Channel is served only by a master program. See bidirectional. Syntax: `master`
`master_debug`	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. Syntax: `master_debug`
`maxblocks`	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. Syntax: `maxblocks` `integer`
`maxheaderaddrs`	Maximum number of addresses per message header line; longer header lines are broken into multiple header lines. Syntax: `maxheaderaddrs` `integer` 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.
`maxheaderchars`	Maximum number of characters per message header line; longer header lines are broken into multiple header lines. Syntax: `maxheaderchars` `integer` 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.
`maxjobs`	Maximum number of concurrent jobs that can be running at one time. If the computed number of service jobs is greater than this value, only `maxjobs` jobs are actually created. Normally `maxjobs` is limited by 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. The default for this value if `maxjobs` is not specified is `100`. Syntax: `maxjobs` `integer`
`maxlines`	Maximum number of message lines per message; longer messages are broken into multiple messages. This limit can be imposed simultaneously if necessary. See maxblocks. Syntax: `maxlines` `integer`
`maxprocchars`	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. Syntax: `maxprocchars` `integer` The default is processing headers of any length.
`maysaslserver`	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. Syntax: `maysaslserver`
`maytls`	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. Syntax: `maytls`
`maytlsclient`	SMTP client attempts TLS use when sending outgoing messages, if sending to an SMTP server that supports TLS. See maytls. Syntax: `maytlsclient`
`maytlsserver`	SMTP server allows TLS use and advertises support for the `STARTTLS` extension when receiving messages. See maytls. Syntax: `maytlsserver`
`missingrecipientpolicy`	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 1 (pass the illegal message through unchanged). The values for `missingrecipientpolicy` are: `0`—Place envelope To: recipients in a To: header line. `1`—Pass the illegal message through unchanged. `2`—Place envelope To: recipients in a To: header line. `3`—Place all envelope To: recipients in a single Bcc: header line. `4`—Generate a group construct (for example, ” ;”) To: header line, “To: Recipients not specified: ;”. `5`—Generate a blank Bcc: header line. `6`—Reject the message.
`msexchange`	Serves channel for Microsoft Exchange gateways and clients. The `msexchange` channel keyword also causes advertisement (and recognition) of broken TLS commands. Syntax: `msexchange`
`multiple`	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. Syntax: `multiple`
`mustsaslserver`	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. Syntax: `mustsaslserver`
`musttls`	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`. Syntax: `musttls`
`musttlsclient`	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. Syntax: `musttlsclient`
`musttlsserver`	SMTP server insists upon TLS use and does not accept messages from any remote SMTP client that does not support TLS use. See `maytls`. Syntax: `musttlsserver`
`mx`	TCP/IP network and software supports MX record lookups. The `mx` keyword is currently equivalent to `nonrandommx`. See randommx. Syntax: `mx`
`nameparameterlengthlimit`	Controls the points at which the name content-type and filename content-disposition parameters are truncated. See `parameterlengthlimit`. Default: `128` Syntax: `nameparameterlengthlimit` `integer`
`nameservers`	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.
`noaddreturnpath`	Do not add a Return-path: header when enqueuing to this channel.
`nobangoverpercent`	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. Syntax: `nobangoverpercent`
`noblocklimit`	No limit specified for the number of MTA blocks allowed per message. See blocklimit. Syntax: `noblocklimit`
`nocache`	Do not cache any connection information. See cacheeverything. Syntax: `nocache`
`nochannelfilter`	Do not perform channel filtering for outgoing messages; synonym for `nodestinationfilter`. See `channelfilter`. Syntax: `nochannelfilter`
`nodayofweek`	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`. Syntax: `nodayofweek`
`nodefaulthost`	Do not specify a domain name to use to complete addresses. See `defaulthost`. Syntax: `nodefaulthost`
`nodeferred`	Do not honor deferred delivery dates. See deferred. Syntax: `nodeferred`
`nodefragment`	Do not perform special processing for message/partial messages. See defragment. Syntax: `nodefragment`
`nodestinationfilter`	Do not perform channel filtering for outgoing messages. See destinationfilter. Syntax: `nodestinationfilter`
`nodropblank`	Do not strip blank To:, Resent-To:, Cc:, or Resent-Cc: headers. See `dropblank`. Syntax: `nodropblank`
`noehlo`	Never use the SMTP EHLO command. See `ehlo`. Syntax: `noehlo`
`noexproute`	No explicit routing for this channel’s addresses. See `exproute`. Syntax: `noexproute`
`noexquota`	Return to originator any messages to users who are over quota. The `holdexquota` and `noexquota` keywords control the handling of messages addressed to Berkeley mailbox users (UNIX) who have exceeded their disk quota. See `holdexquota`. Syntax: `noexquota`
`nofileinto`	Mailbox filter `fileinto` operator has no effect. See `fileinto`. Syntax: `nofileinto`
`nofilter`	Do not perform user mailbox filtering. See filter. Syntax: `nofilter`
`noheaderread`	Do not apply header trimming rules from option file upon message enqueue. See `headerread`. Syntax: `noheaderread`
`noheadertrim`	Do not apply header trimming rules from options file. See `headertrim`. Syntax: `noheadertrim`
`noimproute`	No implicit routing for this channel’s addresses. See `improute`. Syntax: `noimproute`
`noinner`	Do not rewrite inner message headers. See `inner`. Syntax: `noinner`
`noinnertrim`	Do not apply header trimming to inner message headers. See `innertrim`. Syntax: `noinnertrim`
`nolinelimit`	No limit specified for the number of lines allowed per message. See `linelimit`. Syntax: `nolinelimit`
`nologging`	Do not log message enqueues and dequeues into the log file. See `logging`. Syntax: `nologging`
`noloopcheck`	Instructs the SMTP client not check the value of any XLOOP parameter in the EHLO server response to see if the SMTP client is communicating with the SMTP server on the same machine. Syntax: `noloopcheck`
`nomailfromdnsverify`	The MTA does not verify that an entry in the DNS exists for the domain used. See `mailfromdnsverify`. Syntax: `nomailfromdnsverify`
`nomaster_debug`	Do not generate debugging output in the channel’s master program output. See `master_debug`. Syntax: `nomaster_debug`
`nomsexchange`	Channel does not serve MS Exchange gateways. See `msexchange`. Syntax: `nomsexchange`
`nomx`	TCP/IP network does not support MX lookups. See `mx`. Syntax: `nomx`
`nonrandommx`	Perform MX lookups; does not randomize returned entries of equal precedence—they should be processed in the same order in which they are received. Equivalent to `mx`. See also `randommx`. Syntax: `nonrandommx`
`nonurgentbackoff`	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. See `backoff`.
`nonurgentblocklimit`	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). Syntax: `nonurgentblocklimit` `integer`
`nonurgentnotices`	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).
`noreceivedfor`	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. Syntax: `noreceivedfor`
`noreceivedfrom`	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`. Syntax: `noreceivedfrom`
`noremotehost`	Use local host’s domain name as the default domain name to complete addresses. See `remotehost`. Syntax: `noremotehost`
`norestricted`	Do not apply RFC 1137 restricted encoding to addresses. Equivalent to `unrestricted` keyword. See restricted. Syntax: `norestricted`
`noreturnaddress`	Use the `RETURN_ADDRESS` option value. See returnaddress. Syntax: `noreturnaddress`
`noreturnpersonal`	Use the `RETURN_PERSONAL` option value. See returnpersonal. Syntax: `noreturnpersonal`
`noreverse`	Do not apply reverse database to addresses. `noreverse` exempts addresses in messages queued to the channel from address reversal processing. See `reverse`. Syntax: `noreverse`
`normalbackoff`	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. See `backoff`.
`normalblocklimit`	Downgrade messages larger than the specified size to nonurgent priority. Syntax: `normalblocklimit` `integer`
`normalnotices`	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).
`norules`	Do not perform channel-specific rewrite rule checks. This keyword is usually used for debugging and is rarely used in actual applications. See rules. Syntax: `norules`
`nosasl`	SASL authentication is not permitted or attempted. Do not allow switching to this channel upon successful SASL authentication. See `maysaslserver`. Syntax: `nosasl`
`nosaslserver`	SASL authentication is not permitted. See `maysaslserver`. Syntax: `nosaslserver`
`nosendetrn`	Do not send an `ETRN` command. See `sendetrn`. Syntax: `nosendetrn`
`nosendpost`	Do not send copies of failures to the postmaster. See `sendpost`. Syntax: `nosendpost`
`noservice`	Service conversions for messages coming into this channel must be enabled via `CHARSET_CONVERSIONS`. See `service`. Syntax: `noservice`
`noslave_debug`	Do not generate slave debugging output. See `slave_debug`. Syntax: `noslave_debug`
`nosmtp`	Channel does not use SMTP. See `smtp`. Syntax: `nosmtp`
`nosourcefilter`	Do not perform channel filtering for incoming messages. See `sourcefilter`. Syntax: `nosourcefilter`
`noswitchchannel`	Do not switch to the channel associated with the originating host; does not permit being switched to. See `switchchannel`. Syntax:`noswitchchannel`
`notices`	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).
`notificationchannel`	Overrides the process channel as the place to initially queue delivery status notifications (DSNs). If the named channel does not exist, Messaging Server resumes using the process channel. Syntax: `notificationchannel` `channel`
`notls`	SMTP client and server neither attempt nor allow TLS use. See `maytls`. Syntax: `notls`
`notlsclient`	SMTP client does not attempt TLS use when sending messages. See `maytlsclient`. Syntax: `notlsclient`
`notlsserver`	SMTP server does not offer or allow TLS use when receiving messages. See `maytlsserver`. Syntax: `notlsserver`
`novrfy`	Do not issue `SMTP` `VRFY` commands. See `vrfyallow`. Syntax:`novrfy`
`nowarnpost`	Do not send copies of warnings to the postmaster. See `warnpost`. Syntax: `nowarnpost`
`nox_env_to`	Do not add X-Envelope-to header lines while enqueuing. See `x_env_to`. Syntax: `nox_env_to`
`parameterlengthlimit`	Controls the points at which general content-type and content-disposition parameters are truncated. See `nameparameterlengthlimit`. Default: `1024` Syntax:`parameterlengthlimit` `integer`
`percentonly`	Ignores bang paths in address of the form `A!B%C.` When this keyword is set, percents are interpreted for routing. Syntax: `percentonly`
`percents`	Use % routing in the envelope; synonymous with 733. Syntax: `percents`
`personalinc`	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. Syntax: `personalinc`
`personalmap`	Run personal names through `PERSONAL_NAMES` mapping table. See `personalinc`. Syntax: `personalmap`
`personalomit`	Remove personal name fields from message header lines. See `personalinc`. Syntax: `personalomit`
`personalstrip`	Strip problematic characters from personal name fields in message header lines. See `personalinc`. Syntax: `personalstrip`
`pool`	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. Syntax: `pool` `pool_name` 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.
`port`	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. Syntax: `port` `port_number`
`postheadbody`	Both the message’s header and body are sent to the postmaster when a delivery failure occurs. Syntax: `postheadbody`
`postheadonly`	Only the message’s header is sent to the postmaster when a delivery failure occurs. Syntax: `postheadonly`
`randommx`	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. The MTA randomizes the order of returned MX records of equal preference regardless of the `mx/randommx/nonrandommx` setting Syntax: `randommx`
`receivedfor`	Includes envelope To: address in Received: head if a message is addressed to just one envelope recipient. Syntax: `receivedfor`
`receivedfrom`	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. Syntax: `receivedfrom`
`recipientcutoff`	Will not accept a message for delivery if the total number of recipient addresses exceeds this value. Default: Infinite. Syntax: `recipientcutoff` `integer`
`recipientlimit`	Specifies the total number of recipient addresses that will be accepted for the message. Default: Infinite. Syntax: `recipientlimit` `integer`
`rejectsmtp`	Deprecated. Replaced by `rejectsmtplonglines`. Syntax: `rejectsmtp`
`rejectsmtplonglines`	Rejects messages that contain lines longer than 1000 characters (including CRLF). Reject the line when it is over 1000 characters. If the `rejectsmtp` keyword is placed on a channel, a line over 1000 characters (including CRLF) is rejected. This keyword must be applied to the initial channel used for submission (such as `tcp_local`). It will not affect any channel that is switched to subsequently. See `truncatesmtplonglines` and `wrapsmtplonglines`. Syntax: `rejectsmtp`
`remotehost`	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. Syntax: `remotehost`
`restricted`	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. Syntax: `restricted`
`returnaddress`	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.
`returnenvelope`	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.
`returnpersonal`	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.
`reverse`	Apply reverse database or REVERSE mapping to addresses in messages queued to the channel. Syntax: `reverse`
`routelocal`	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. Syntax: `routelocal`
`rules`	Perform channel-specific rewrite rule checks. Usually used for debugging. Syntax: `rules`
`saslswitchchannel`	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.
`sendpost`	Sends copies of failed messages to the postmaster. See `copysendpost`. Syntax: `sendpost`
`sendetrn`	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. Syntax: `sendetrn` `host` The `sendetrn` keyword should be followed by the name of the system requesting that its messages receive a delivery attempt.
`sensitivitycompanyconfidential`	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. Syntax: `sensitivitycompanyconfidential`
`sensitivitynormal`	Reject messages whose sensitivity is higher than normal. See `sensitivitycompanyconfidential`. Syntax: `sensitivitynormal`
`sensitivitypersonal`	Reject messages whose sensitivity is higher than personal. See `sensitivitycompanyconfidential`. Syntax: `sensitivitypersonal`
`sensitivityprivate`	Reject messages whose sensitivity is higher than private. See `sensitivitycompanyconfidential`. Syntax: `sensitivityprivate`.
`service`	Perform service conversions for messages coming into the channel. The `service` keyword unconditionally enables service conversions regardless of `CHARSET-CONVERSION` entry. Syntax: `service`
`sevenbit`	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. Syntax: `sevenbit`
`silentetrn`	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`. Syntax: `silentetrn`
`single`	Only one envelope To: address per message copy or destination address on the channel. See `multiple`. Syntax: `single`
`single_sys`	Each message copy must be for a single destination system. See multiple. Syntax: `single_sys`
`slave`	Channel is serviced only by a slave program. See bidirectional. Syntax: `slave`
`slave_debug`	Generate debugging output in slave programs. See master_debug. Syntax: `slave_debug`
`smtp`	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. The `smtp` keyword is synonymous to the `smtp_crlf` keyword. Syntax: `smtp`
`smtp_cr`	Accept CR as an SMTP line terminator. See `smtp`. Syntax: `smtp_cr`
`smtp_crlf`	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`. Syntax: `smtp_crlf`
`smtp_crorlf`	Allow any of CR (carriage return), LF (line feed), or full CRLF as the SMTP line terminator. See `smtp`. Syntax: `smtp_crorlf`
`smtp_lf`	Accept LF (linefeed) without a preceding CR (carriage return) as an SMTP line terminator. See `smtp`. Syntax: `smtp_lf`
`sourceblocklimit`	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`. Syntax: `sourceblocklimit` `integer`
`sourcebrightmail`	Specifies that all messages originating from this channel receive Brightmail processing. All recipient addresses will be made known to Brightmail regardless of destination channel if the recipient or the recipient’s domain has opted in via the LDAP attribute. Looks at recipient’s LDAP attribute `mailAntiUBEService` (or equivalent) to determine whether spam, virus or both or none are filtered. If `mailAntiUBEService` doesn’t specify either spam or virus, then mail is not sent to the Brightmail server for filtering. This should be placed on the switched-to channel, if `switchchannel` is in effect. Syntax: `sourcebrightmail`
`sourcebrightmailoptin`	Specifies that all messages originating from this channel will be subject to the specified Brightmail processing (either spam or virus or both) even if those services have not been opted in by the user or domain via the LDAP attribute. The system-wide default filter list follows the keyword. The list following must be either `spam` or `virus` or `spam,virus` or `virus,spam`. This should be placed on the switched-to channel, if `switchchannel` is in effect. Example 1: `tcp_local sourcebrightmailoptin spam,virus . . .` Specifies that mail be scanned for both spam and virus by Brightmail regardless of the user’s LDAP attribute. Example 2: `tcp_local sourcebrightmailoptin virus . . .` Specifies that mail will default to only virus scanning. In this case, spam filtering can be enabled on a per user basis, or by destination domain via the LDAP attributes.
`sourcecommentinc`	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. Syntax: `sourcecommentinc`
`sourcecommentmap`	Runs comment strings in message header lines through source channels. See `sourcecommentinc`. Syntax: `sourcecommentmap`
`sourcecommentomit`	Remove comments from incoming message header lines, for example, To:, From:, and Cc: headers. See `sourcecommentinc`. Syntax: `sourcecommentomit`
`sourcecommentstrip`	Remove problematic characters from comment field in incoming message header lines. See `sourcecommentinc`. Syntax:`sourcecommentstrip`
`sourcecommenttotal`	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`. Syntax: `sourcecommenttotal`
`sourcefilter`	Specify the location of channel filter file for incoming messages. Syntax: `sourcefilter` `filter` The `filter` argument is a required URL that describes the channel filter location.
`sourcenosolicit`	The `NO-SOLICIT SMTP` extension (described in the Internet Draft `draft-malamud-no-soliciting-07.txt`) has been implemented with Messaging Server. This option specifies a comma-separated list of solicitation field values that will be blocked in mail submitted by this channel. This list of values will appear in the `NO-SOLICIT EHLO` response. Glob-style wildcards can be used in the values, however, values containing wildcards will not appear in the `EHLO` announcement. Syntax: `sourcenosolicit` `value1, value2, value3...` where `value1, value2, value3` is a comma-separated list of solicitation field values.
`sourcepersonalinc`	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. Syntax: `sourcepersonalinc`
`sourcepersonalmap`	Run personal names through source channels. See `sourcepersonalinc`. Syntax: `sourcepersonalmap`
`sourcepersonalomit`	Remove personal name fields from incoming message header lines. See `sourcepersonalinc`. Syntax: `sourcepersonalomit`
`sourcepersonalstrip`	Strip problematic characters from personal name fields in incoming message header lines. See `sourcepersonalinc`. Syntax: `sourcepersonalstrip`
`sourceroute`	Use source routes in the message envelope; synonymous with 822. Syntax: `sourceroute`
sourcespamfilterXoptin	Run messages originating from this channel through spam filtering software X.
`streaming`	Specify degree of protocol streaming for channel to use. Syntax: `streaming 0\|1\|2\|3` 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`.
`subaddressexact`	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. Syntax: `subaddressexact`
`subaddressrelaxed`	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. Syntax*: `subaddressrelaxed`
`subaddresswild`	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+. Syntax*: `subaddresswild`
`subdirs`	Use multiple subdirectories. Syntax: `subdirs` `integer` The keyword should be followed by an integer that specifies the number of subdirectories across which to spread messages for the channel.
`submit`	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. Syntax:`submit`
`suppressfinal`	Suppress the final address form from notification messages, if an original address form is present, from notification messages. See `includefinal`. Syntax:`suppressfinal`
`switchchannel`	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. Syntax: `switchchannel`
`threaddepth`	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). Default: `10` Syntax: `threaddepth` `integer`
`tlsswitchchannel`	Switch to specified channel upon successful TLS negotiation. See `maytls`. Syntax: `tlsswitchchannel` `channel` The `channel` parameter specifies the channel to which to switch.
`transactionlimit`	Provides functionality equivalent to the `ALLOW_TRANSACTIONS_PER_SESSION` SMTP channel option (See Available SMTP Channel Options) on a per-channel basis. The default is no limit. Syntax: `transactionlimit` `integer`
`truncatesmtp`	Replaced and deprecated by `truncatesmtplonglines`. Syntax: `truncatesmtp`
`truncatesmtplonglines`	Truncate the line when it is over 1000 characters. If the `truncatesmtp` keyword is placed on a channel, a line over 1000 characters is truncated. This keyword must be applied to the initial channel used for submission (such as `tcp_local`). It will not affect any channel that is switched to subsequently. See `rejectsmtplonglines` and `wrapsmtplonglines`. Syntax: `truncatesmtplonglines`
`unrestricted`	Do not apply RFC 1137 restricted encoding to addresses. See restricted. Syntax: `unrestricted`
`urgentbackoff`	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.
`urgentblocklimit`	Force messages larger the specified size to normal priority. Syntax:`urgentblocklimit`
`urgentnotices`	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).
`useintermediate`	Present the address as originally presented to the MTA for notification messages. Syntax: `useintermediate`
`user`	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. Syntax: `user` `username` Note that the argument to `user` is normally forced to lowercase, but original case is preserved if the argument is quoted.
`uucp`	Use UUCP! (bang-style) routing in the envelope; synonymous with bangstyle. Syntax: `uucp`
`viaaliasoptional`	Specify that final recipient addresses that match the channel are not required to be produced by an alias. Syntax: `viaaliasoptional`
`viaaliasrequired`	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). Syntax: `viaaliasrequired`
`vrfyallow`	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 an `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. Syntax: `vrfyallow`
`vrfydefault`	Provide a detailed, informative response for `SMTP` `VRFY` command, unless the channel option `HIDE_VERIFY=1` has been specified. See `vrfyallow`. Syntax: `vrfydefault`
`vrfyhide`	Issue only a vague, ambiguous response to `SMTP` `VRFY` command. See `vrfyallow`. Syntax: `vrfyhide`
`uucp`	Use UUCP ! routing in the envelope; synonymous with BANGSTYLE.
`warnpost`	Send copies of warnings to the postmaster. See `copywarnpost`. Syntax: `warnpost`
`wrapsmtp`	Replaced and deprecated by `wrapsmtplonglines`. Syntax: `wrapsmtp`
`wrapsmtplonglines`	Wrap the line instead of truncating it. If the `wrapsmtp` keyword is placed on a channel, a long line (over 1000 characters) wraps to the next line. This keyword must be applied to the initial channel used for submission (such as `tcp_local`). It will not affect any channel that is switched to subsequently. See `rejectsmtplonglines` and `truncatesmtplonglines`. Syntax: `wrapsmtplonglines`
`x_env_to`	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. Syntax: `x_env_to single` The `x_env_to` keyword requires the `single` keyword in order to take effect.

Channel Configuration Keywords lists channel keywords for functional group.

For additional description about the channel keyword functionality groups, see Chapter 12, Configuring Channel Definitions, in Sun Java System Messaging Server 6 2005Q4 Administration Guide.

Table 4–7 Channel Keywords Grouped by Functionality


Functionality	Associated Keywords
Address types	`733`, `822`, `uucp`, `header_733`, `header_822`, `header_uucp`
Address interpretation	`bangoverpercent`, `nobangoverpercent`, `percentonly`
Alternate channels	`alternatechannel`, `alternateblocklimit`, `alternatelinelimit`, `alternaterecipientlimit`
Brightmail	`destinationbrightmail`, `destinationbrightmailoptin`, `sourcebrightmail`, `sourcebrightmailoptin`
Routing information in addresses	`exproute`, `improute`, `noexproute`, `noimproute`
Short circuiting rewriting of routing addresses	`routelocal`
Address rewriting upon message dequeue	`connectalias`, `connectcanonical`
Channel-specific rewrite rules	`norules`, `rules`
Channel directionality	`bidirectional`, `master, slave`
Message size affection priority	`nonurgentblocklimit`, `normalblocklimit`, `urgentblocklimit`
Channel connection information caching	`cacheeverything`, `cachefailures`, `cachesuccesses`, `nocache`
Address and message file processing amounts	`addrsperjob`, `filesperjob`, `maxjobs`
Multiple addresses	`addrsperfile`, `multiple`, `single`, `single_sys`
Expansion of multiple addresses	`expandchannel`, `expandlimit`, `holdlimit`
Multiple subdirectories	`subdirs`
Service job queue scheduling	`pool`, `maxjobs`
Deferred delivery dates	`deferred`, `nodeferred`
Undeliverable message notification times	`nonurgentnotices`, `normalnotices`, `notices`, `urgentnotices`
Returned messages	`copysendpost`, `errsendpost`, `nosendpost`, `sendpost`
Warning messages	`copywarnpost`, `errwarnpost`, `nowarnpost`, `warnpost`
Postmaster returned message content	`postheadbody`, `postheadonly`
Including altered addresses in notification messages	`includefinal`, `suppressfinal`, `useintermediate`
Protocol streaming	`streaming`
Triggering new threads in multithreaded channels	`threaddepth`
Channel protocol selection	`nosmtp`, `smtp`, `smtp_cr`, `smtp_crlf`, `smtp_crorlf`, `smtp_lf`
SMTP EHLO command	`checkehlo`, `ehlo`, `noehlo`
Receiving an SMTP ETRN command	`allowetrn`, `blocketrn`, `disableetrn`, `domainetrn`, `silentetrn`
Sending an SMTP ETRN command	`nosendetrn`, `sendetrn`
SMTP VRFY commands	`domainvrfy`, `localvrfy`, `novrfy`
Responding to SMTP VRFY commands	`vrfyallow`, `vrfydefault`, `vrfyhide`
SMTP EXPN commands	`expnallow`, `expndisable`, `expndefault`
TCP/IP port number	`interfaceaddress`, `port`
TCP/IP MX record support	`defaultmx`, `defaultnameservers,` `mx`, `nameservers`, `nomx`, `nonrandommx`, `randommx`
Last resort host specification	`lastresort`
Reverse DNS and IDENT lookups on incoming SMTP connections	`forwardcheckdelete`, `forwardchecknone`, `forwardchecktag`, `identnone`, `identnonelimited`, `identnonenumeric`, `identnonesymbolic`, `identtcp`, `identtcplimited`, `identtcpnumeric`, `identtcpsymbolic`
Alternate channels for incoming mail	`allowswitchchannel`, `noswitchchannel`, `switchchannel`
Host name for incomplete addresses	`defaulthost`, `nodefaulthost`, `noremotehost`, `remotehost`
Illegal blank recipient headers	`dropblank`, `nodropblank`
Messages without recipient header	`missingrecipientpolicy`
Eight-bit capability	`eightbit`, `eightnegotiate`, `eightstrict`, `sevenbit`
Character set labeling	`charset7`, `charset8`, `charsetesc`
Message line length restrictions	`linelength`
Channel-specific use of the reverse database	`noreverse`, `reverse`
Inner header rewriting	`inner`, `noinner`
Restricted mailbox encoding	`norestricted`, `restricted`, `unrestricted`
Message header line trimming	`headerread`, `headertrim`, `innertrim`, `noheaderread`, `noheadertrim`, `noinnertrim`
Encoding: header line	`ignoreencoding`, `interpretencoding`
X-Envelope-to: Header Lines generation	`nox_env_to`, `x_env_to`
Return-path: header line generation	`addreturnpath`, `noaddreturnpath`
Envelope To: and From: Addresses in Received: Header Lines	`noreceivedfor`, `noreceivedfrom`, `receivedfor`, `receivedfrom`
Postmaster address	`aliaspostmaster`, `noreturnaddress`, `noreturnpersonal`, `returnaddress`, `returnpersonal`
Blank envelope return addresses	`returnenvelope`
Comments in address header lines	`commentinc`, `commentmap`, `commentomit`, `commentstrip`, `commenttotal`, `sourcecommentinc`, `sourcecommentmap`, `sourcecommentomit`, `sourcecommentstrip`, `sourcecommenttotal`
Personal names in address header lines	`personalinc`, `personalmap`, `personalomit`, `personalstrip`, `sourcepersonalinc`, `sourcepersonalmap`, `sourcepersonalomit`, `sourcepersonalstrip`
Alias file and alias database probes	`aliaslocal`
Subaddresses	`subaddressexact`, `subaddressrelaxed`, `subaddresswild`
Addresses produced by aliases	`viaaliasoptional`, `viaaliasrequired`
Two or four digit date conversion	`datefour`, `datetwo`
Day of week in date specifications	`dayofweek`, `nodayofweek`
Automatic splitting of long header lines	`maxheaderaddrs`, `maxheaderchars`
Header alignment and folding	`headerlabelalign`, `headerlinelength`
Automatic defragmentation of messages and partial messages	`defragment`, `nodefragment`
Automatic fragmentation of large messages	`maxblocks`, `maxlines`
Absolute message size limits	`blocklimit`, `linelimit`, `noblocklimit`, `nolinelimit`, `sourceblocklimit`
Maximum length header	`maxprocchars`
Mail delivery to over quota users	`holdexquota`, `noexquota`
Gateway daemons	`daemon`
Processing of account or message router mailbox	`user`
Message logging	`logging`, `nologging`
Debugging channel master and slave programs	`master_debug`, `nomaster_debug`, `noslave_debug`, `slave_debug`
Sensitivity checking	`sensitivitycompanyconfidential`, `sensitivitynormal`, `sensitivitypersonal`, `sensitivityprivate`
SASL configuration	`maysaslserver`, `mustsaslserver`, `nosasl`, `nosaslserver`, `nosasl`, `saslswitchchannel`
Verify the domain on mail From: is in the DNS	`mailfromdnsverify`, `nomailfromdnsverify`
Channel operation type	`submit`
Filter file location	`channelfilter`, `destinationfilter`, `fileinto`, `filter`, `nochannelfilter`, `nodestinationfilter`, `nofileinto`, `nofilter`, `nosourcefilter`, `sourcefilter`
Authenticated address from SMTP AUTH in header	`authrewrite`
Transport layer security	`maytls`, `maytlsclient`, `maytlsserver`, `musttls`, `musttlsclient`, `musttlsserver`, `notls`, `notlsclient`, `notlsserver`, `tlsswitchchannel`
MS Exchange Gateway channels	`msexchange`, `nomsexchange`
Remove source routes	`dequeue_removeroute`
Default language	`language`
Loopcheck	`loopcheck`, `noloopcheck`
Service	`noservice`, `service`
Deferred delivery	`backoff`, `nonurgentbackoff`, `normalbackoff`, `urgentbackoff`
Lines over 1000 characters	`rejectsmtp`, `truncatesmtp`, `wrapsmtp`
Process Channel Overrides	`dispositionchannel`, `notificationchannel`
`NO-SOLICIT SMTP` extension support	`sourcenosolicit`, `destinationnosolicit`
Limits the number of bad `RCPT TO:` addresses	`deferralrejectlimit`