This chapter describes how to use channel keyword definitions in the MTA configuration file imta.cnf. Please read Chapter 10, About MTA Services and Configuration, as well as Channel Definitions and The MTA Configuration File before reading this chapter. This chapter contains the following sections:
If you make channel definition changes in imta.cnf, you must restart any programs or channels that load the configuration data only once when they start up—for example, the SMTP server—by using the imsimta restart command. If you are using a compiled configuration, you must recompile and then restart. For more information about compiling configuration information and starting programs, see the Sun Java System Messaging Server 6 2005Q4 Administration Reference.
Many configurations involve repetition of various channel keywords on all or nearly all channels. Maintaining such a configuration is both tedious and error-prone. To simplify some configurations, you can specify which keywords are defaults for various channels.
For example, the following line in a configuration file indicates that all channel blocks following the line will inherit the keywords specified in the line:
defaults keyword1 keyword2 keyword3 ...
The defaults line can be thought of as a special channel block that changes the keyword defaults without actually specifying a channel. The defaults line also does not require any additional lines of channel block information (if any are specified they will be ignored).
There is no limit on the number of defaults lines that can be specified—the effects of multiple defaults lines are cumulative with the most recently encountered (reading from top to bottom) line having precedence.
It may be useful to unconditionally eliminate the effects of any defaults lines starting at some point in the configuration file (at the start of a standalone section of channel blocks in an external file, for example). The nodefaults line is provided for this purpose. For example, inserting the following line in the configuration file nullifies all settings established by any previous defaults channel and returns the configuration to the state that would apply if no defaults had been specified:
nodefaults
Like regular channel blocks, a blank line must separate each defaults or nodefaults channel block from other channel blocks. The defaults and nodefaults channel blocks are the only channel blocks which may appear before the local channel in the configuration file. However, like any other channel block, they must appear after the last rewrite rule.
The following table is an alphabetized list of keywords.
Table 12–1 Alphabetized List of Channel Keywords
Keyword |
For More Information... |
---|---|
733 | |
822 | |
addreturnpath | |
addrsperfile | |
Aliasdetourhost | |
aliaslocal | |
aliaspostmaster | |
allowetrn | |
allowswitchchannel | |
alternatechannel | |
alternateblocklimit | |
alternatelinelimit | |
alternaterecipientlimit | |
authrewrite | |
backoff |
Specifying the Retry Frequency for Messages that Failed Delivery |
bangoverpercent | |
bangstyle | |
bidirectional | |
blocketrn | |
blocklimit | |
cacheeverything | |
cachefailures | |
cachesuccesses | |
channelfilter | |
charset7 | |
charset8 | |
charsetesc | |
checkehlo | |
commentinc | |
commentmap | |
commentomit | |
commentstrip | |
commenttotal | |
connectalias | |
connectcanonical | |
copysendpost | |
copywarnpost | |
daemon | |
datefour | |
datetwo | |
dayofweek | |
defaulthost |
Specifying a Host Name to Use When Correcting Incomplete Addresses |
defaultmx | |
defaultnameservers | |
deferralrejectlimit | |
deferred | |
defragment | |
dequeue_removeroute | |
destinationfilter | |
destinationnosolicit | |
destinationspamfilterXoptin | |
disableetrn | |
dispositionchannel | |
disconnectbadauthlimit | |
disconnectbadcommandlimit | |
domainetrn | |
domainvrfy | |
dropblank | |
ehlo | |
eightbit | |
eightnegotiate | |
eightstrict | |
errsendpost | |
errwarnpost | |
expandchannel | |
expandlimit | |
expnallow | |
expndisable | |
expndefault | |
exproute | |
fileinto | |
filesperjob | |
filter | |
forwardcheckdelete | |
forwardchecknone | |
forwardchecktag | |
header_733 | |
header_822 | |
header_uucp | |
headerlabelalign | |
headerlimit | |
headerlinelength | |
headerread | |
headertrim | |
holdexquota | |
holdlimit | |
identnone | |
identnonelimited | |
identnonenumeric | |
identnonesymbolic | |
identtcp | |
identtcplimited | |
identtcpsymbolic | |
ignoreencoding | |
immnonurgent | |
improute | |
includefinal |
To Include Altered Addresses in Status Notification Messages |
inenttcpnumeric | |
inner | |
innertrim | |
interfaceaddress | |
interpretencoding | |
language | |
lastresort | |
linelength | |
linelimit | |
localvrfy | |
logging | |
logheader | |
loopcheck | |
mailfromdnsverify | |
master | |
master_debug | |
maxblocks | |
maxheaderaddrs | |
maxheaderchars | |
maxjobs | |
maxlines | |
maxprocchars | |
maysaslserver | |
maytls | |
maytlsclient | |
maytlsserver | |
missingrecipientpolicy | |
msexchange | |
multiple | |
mustsaslserver | |
musttls | |
musttlsclient | |
musttlsserver | |
mx | |
namelengthlimit |
Controlling the Length of General and Filename Content-type and Content-disposition Parameters |
nameservers | |
noaddreturnpath | |
nobangoverpercent | |
noblocklimit | |
nocache | |
nochannelfilter | |
nodayofweek | |
nodefaulthost |
Specifying a Host Name to Use When Correcting Incomplete Addresses |
nodeferred | |
nodefragment | |
nodestinationfilter | |
nodropblank | |
noehlo | |
noexproute | |
noexquota | |
nofileinto | |
nofilter | |
noheaderread | |
noheadertrim | |
noimproute | |
noinner | |
noinnertrim | |
nolinelimit | |
nologging | |
noloopcheck | |
nomailfromdnsverify | |
nomaster_debug | |
nomsexchange | |
nomx | |
norandomemx | |
nonurgentbackoff |
Specifying the Retry Frequency for Messages that Failed Delivery |
nonurgentblocklimit | |
nonurgentnotices | |
noreceivedfor |
Constructing Received Header Lines from Envelope To and From Addresses |
noreceivedfrom |
Constructing Received Header Lines from Envelope To and From Addresses |
noremotehost |
Specifying a Host Name to Use When Correcting Incomplete Addresses |
norestricted | |
noreturnaddress | |
noreturnpersonal | |
noreverse | |
normalbackoff |
Specifying the Retry Frequency for Messages that Failed Delivery |
normalblocklimit | |
normalnotices | |
norules | |
nosasl | |
nosaslserver | |
nosaslswitchchannel | |
nosendetrn | |
nosendpost | |
noservice | |
noslave_debug | |
nosmtp | |
nosourcefilter | |
noswitchchannel | |
notices | |
notificationchannel | |
notls | |
notlsclient | |
notlsserver | |
novrfy | |
nowarnpost | |
nox_env_to | |
parameterlengthlimit |
Controlling the Length of General and Filename Content-type and Content-disposition Parameters |
percentonly | |
percents | |
personalinc | |
personalmap | |
personalomit | |
personalstrip | |
pool | |
port | |
postheadbody | |
postheadonly | |
randommx | |
receivedfor |
Constructing Received Header Lines from Envelope To and From Addresses |
receivedfrom |
Constructing Received Header Lines from Envelope To and From Addresses |
recipientcutoff | |
recipientlimit | |
rejectsmtplonglines | |
remotehost |
Specifying a Host Name to Use When Correcting Incomplete Addresses |
restricted | |
returnaddress | |
returnenvelope | |
returnpersonal | |
reverse | |
routelocal | |
rules | |
saslswitchchannel | |
sendetrn | |
sendpost | |
sensitivitycompanyconfidential | |
sensitivitynormal | |
sensitivitypersonal | |
sensitivityprivate | |
service | |
sevenbit | |
silentetrn | |
single | |
single_sys | |
slave | |
slave_debug | |
smtp | |
smtp_cr | |
smtp_crlf | |
smtp_crorlf | |
smtp_lf | |
sourceblocklimit | |
sourcecommentinc | |
sourcecommentmap | |
sourcecommentomit | |
sourcecommentstrip | |
sourcecommenttotal | |
sourcefilter | |
sourcenosolicit | |
sourcepersonalinc | |
sourcepersonalmap | |
sourcepersonalomit | |
sourcepersonalstrip | |
sourceroute | |
sourcespamfilterXoptin | |
streaming | |
subaddressexact | |
subaddressrelaxed | |
subaddresswild | |
subdirs |
Spreading a Channel Message Queue Across Multiple Subdirectories |
submit | |
suppressfinal |
To Include Altered Addresses in Status Notification Messages |
switchchannel | |
threaddepth | |
tlsswitchchannel | |
transactionlimit | |
truncatesmtplonglines | |
unrestricted | |
urgentbackoff |
Specifying the Retry Frequency for Messages that Failed Delivery |
urgentblocklimit | |
urgentnotices | |
useintermediate |
To Include Altered Addresses in Status Notification Messages |
user | |
uucp | |
viaaliasoptional | |
viaaliasrequired | |
vrfyallow | |
vrfydefault | |
vrfyhide | |
warnpost | |
wrapsmtplonglines | |
x_env_to |
The following tables are categorized lists of keywords. The tables and categories are as follows:
Table 12–2 Address Handling Keywords
Table 12–3 Attachments and MIME Processing
Table 12–4 Character Sets and Eight Bit Data
Table 12–5 File Creation in the MTA Queue Area
Table 12–6 Header Keywords
Table 12–7 Incoming Channel Matching and Switching Keywords
Table 12–8 Logging and Debugging Channel Keywords
Table 12–9 Long Address Lists or Headers Channel Keywords
Table 12–10 Mailbox Filter Channel Keywords
Table 12–11 NO-SOLICIT SMTP Extension Support Keywords
Table 12–12 Notification and Postmaster Messages Keywords
Table 12–13 Processing Control and Job Submission Keywords
Table 12–14 Sensitivity Limit Keywords
Table 12–15 Keywords for Limits on Messages, User Quotas, Privileges, and Authentication Attempts
Table 12–16 SMTP Authentication, SASL and TLS Keywords
Table 12–17 SMTP Commands and Protocol Keywords
Table 12–18 TCP/IP Connection and DNS Lookup Support Keywords
Table 12–19 Miscellaneous Keywords
Keyword |
Page |
Definition |
---|---|---|
Address Handling |
||
733 |
Use % routing in the envelope; synonymous with percents. Address Types and Conventions |
|
822 |
Use source routes in the envelope; same as sourceroute. |
|
addreturnpath |
Generating of Return-path Header Lines Add Return-path: header to messages enqueued to this channel. |
|
aliaslocal |
Specifying Alias File and Alias Database Probes Look up rewritten addresses in the alias file and alias database. |
|
authrewrite |
TCP/IP Connection and DNS Lookup Support Used on a source channel to have the MTA propagate authenticated originator information, if available, into the headers. |
|
bangoverpercent |
Adding Routing Information in Addresses Group A!B%C as A!(B%C) |
|
bangstyle |
Use UUCP ! routing in the envelope; synonymous with uucp. |
|
defaulthost |
Specifying a Host Name to Use When Correcting Incomplete Addresses Specify a domain name to use to complete addresses |
|
dequeue_removeroute |
Removes source routes from envelope To: addresses. |
|
exproute |
Adding Routing Information in Addresses Require explicit routing when addresses passed to remote systems. |
|
holdlimit |
Expansion of Multiple Addresses Hold message when number of envelope recipient addresses exceeds this limit. |
|
improute |
Adding Routing Information in Addresses Implicit routing for this channel’s addresses |
|
missingrecipientpolicy |
Legalizing Messages Without Recipient Header Lines Set policy for how to legalize (which header to add) messages that are lacking any recipient headers. |
|
noaddreturnpath |
Generating of Return-path Header Lines Do not add Return-path: header when enqueuing message. |
|
nobangoverpercent |
Adding Routing Information in Addresses Group A!B%C as (A!B)%C |
|
nodefaulthost |
Specifying a Host Name to Use When Correcting Incomplete Addresses Do not specify a domain name to use to complete addresses |
|
noexproute |
Adding Routing Information in Addresses No explicit routing for this channel’s addresses |
|
noimproute |
Adding Routing Information in Addresses No implicit routing for this channel’s addresses |
|
noreceivedfrom |
Constructing Received Header Lines from Envelope To and From Addresses Construct Received: header lines without including the original envelope From: address. |
|
noremotehost |
Specifying a Host Name to Use When Correcting Incomplete Addresses Use local host’s domain name as the default domain name to complete addresses |
|
norestricted |
Enabling Restricted Mailbox Encoding Same as unsrestricted. |
|
noreverse |
Enabling Channel-Specific Use of the Reverse Database Exempts addresses in messages from address reversal processing |
|
norules |
Enabling Channel-specific Rewrite Rules Checks Do not enforce channel-specific rewrite rule checks for this channel. |
|
percentonly |
Adding Routing Information in Addresses Ignores bang paths. Use % routing in the envelope. |
|
percents |
Use % routing in the envelope; synonymous with 733. |
|
remotehost |
Specifying a Host Name to Use When Correcting Incomplete Addresses Use remote host’s name as the default domain name to complete addresses |
|
restricted |
Enabling Restricted Mailbox Encoding The channel connects to mail systems that require encoding. |
|
reverse |
Enabling Channel-Specific Use of the Reverse Database Checked addresses against address reversal database or REVERSE mapping |
|
routelocal |
Disabling Rewriting of Explicit Routing Addresses Causes the MTA, when rewriting an address to the channel, to attempt to “short circuit” any explicit routing in the address. |
|
rules |
Enabling Channel-specific Rewrite Rules Checks Enforce channel-specific rewrite rule checks for this channel. |
|
sourceroute |
Synonymous with 822. |
|
subaddressexact |
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. |
|
subaddressrelaxed |
After looking for an exact match and then a match of the form name+*, the MTA should make one additional check for a match on just the name portion. |
|
subaddresswild |
After looking for an exact match including the entire subaddress, the MTA should next look for an entry of the form name+*. |
|
unrestricted |
Enabling Restricted Mailbox Encoding Tells the MTA not to perform RFC 1137 encoding and decoding. |
|
uucp |
Use UUCP! routing in the envelope; synonymous with bangstyle. |
|
viaaliasoptional |
Specifying Address Must be from an Alias Final recipient addresses that match the channel are not required to be produced by an alias. |
|
viaaliasrequired |
Specifying Address Must be from an Alias Final recipient address that matches the channel must be produced by an alias. |
Table 12–3 Attachments and MIME Processing
Keyword |
Definition |
|
---|---|---|
defragment |
Automatic Defragmentation of Message/Partial Messages Partial messages queued to the channel are placed in the defragmentation channel queue instead. |
|
ignoreencoding |
Ignoring the Encoding Header Line Ignore Encoding: header on incoming messages. |
|
interpretencoding |
Ignoring the Encoding Header Line Interpret Encoding: header on incoming messages, if the need arises. |
|
nodefragment |
Automatic Defragmentation of Message/Partial Messages Disables defragmention. |
Table 12–4 Character Sets and Eigth Bit Data
Keyword |
Definition |
|
---|---|---|
charset7 |
Character Set Labeling and Eight-Bit Data Default character set to associate with 7-bit text messages |
|
charset8 |
Character Set Labeling and Eight-Bit Data Default character set to associate with 8-bit text messages |
|
charsetesc |
Character Set Labeling and Eight-Bit Data Default character set to associate with 7-bit text containing the escape character |
|
eightbit |
Character Set Labeling and Eight-Bit Data Channel supports eight-bit characters. |
|
eightnegotiate |
Character Set Labeling and Eight-Bit Data Channel should negotiate use of eight-bit transmission if possible. |
|
eightstrict |
Character Set Labeling and Eight-Bit Data Reject messages with headers that contain unnegotiated eight-bit data. |
|
sevenbit |
Character Set Labeling and Eight-Bit Data Do not support 8-bit characters; 8-bit characters must be encoded. |
Table 12–5 File Creation in the MTA Queue Area
Keyword |
Page |
Definition |
---|---|---|
addrsperfile |
Handling Mail Delivery to Over Quota Users Limit on the maximum number of recipients that can be associated with a single message file in a channel queue |
|
expandchannel |
Expansion of Multiple Addresses Specifies channel in which to perform deferred expansion due to application of expandlimit. |
|
expandlimit |
Expansion of Multiple Addresses Processes an incoming message “off-line” when the number of addressees exceeds this limit. |
|
multiple |
Handling Mail Delivery to Over Quota Users No limit on the number of recipients in a message file, however the SMTP channel defaults to 99. |
|
single |
Handling Mail Delivery to Over Quota Users A separate copy of the message will be created for each destination address on the channel. |
|
single_sys |
Handling Mail Delivery to Over Quota Users Create a single message copy for each destination system used. |
|
subdirs |
Spreading a Channel Message Queue Across Multiple Subdirectories Specifies the number of subdirectories across which to spread messages for the channel queues. |
Table 12–6 Header Keywords
Keyword |
Definition |
|
---|---|---|
authrewrite |
TCP/IP Connection and DNS Lookup Support Used on a source channel to have the MTA propagate authenticated originator information, if available, into the headers. |
|
commentinc |
Handling Comments in Address Header Lines Leave comments in message header lines intact. |
|
commentmap |
Handling Comments in Address Header Lines Runs comment strings in message header lines through the COMMENT_STRINGS mapping table. |
|
commentomit |
Handling Comments in Address Header Lines Remove comments from message header lines. |
|
commentstrip |
Handling Comments in Address Header Lines Remove problematic characters from comment fields in message header lines. |
|
commenttotal |
Handling Comments in Address Header Lines Strip comments (material in parentheses) from all header lines, except Received: header lines. Not recommended. |
|
datefour |
Converting Date to Two- or Four-Digits Expand all year fields to four digits. |
|
datetwo |
Converting Date to Two- or Four-Digits Remove the leading two digits from four-digit dates. Provides compatibility with mail systems that require two digit dates; it should never be used for any other purpose. |
|
dayofweek |
Specifying Day of Week in Date Retain day of the week information and adds this information to date and time headers if it is missing. |
|
defaulthost |
Specifying a Host Name to Use When Correcting Incomplete Addresses Specify a domain name to use to complete addresses |
|
dropblank |
Stripping Illegal Blank Recipient Headers Strip illegal blank headers from incoming messages. |
|
header_733 |
Use % routing in the message header. |
|
header_822 |
Use source routes in the message header. |
|
headerlabelalign |
Controls the alignment point for message headers enqueued on this channel; it takes an integer-valued argument. |
|
headerlinelength |
Controls the length of header lines enqueued on this channel. |
|
headerread |
Removing Selected Message Header Lines 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. |
|
headertrim |
Removing Selected Message Header Lines Applies header trimming rules from an options file to the message headers after the original message headers are processed. |
|
header_uucp |
Use ! routing in the header |
|
inner |
Parse messages and rewrite inner headers. |
|
innertrim |
Removing Selected Message Header Lines Apply header trimming rules from an options file to inner message headers (use with caution). |
|
language |
Setting Default Language in Headers Specifies the default language in headers. |
|
maxheaderaddrs |
Automatic Splitting of Long Header Lines Controls how many addresses can appear on a single line. |
|
maxheaderchars |
Automatic Splitting of Long Header Lines Controls how many characters can appear on a single line. |
|
missingrecipientpolicy |
Legalizing Messages Without Recipient Header Lines Set policy for how to legalize (which header to add) messages that are lacking any recipient headers. |
|
nodayofweek |
Specifying Day of Week in Date Removes day of the week from date and time headers. Provides compatibility with mail systems that cannot process this information; it should never be used for any other purpose. |
|
nodefaulthost |
Specifying a Host Name to Use When Correcting Incomplete Addresses Do not specify a domain name to use to complete addresses |
|
nodropblank |
Stripping Illegal Blank Recipient Headers Do not strip illegal blank headers from incoming messages. |
|
noheaderread |
Removing Selected Message Header Lines Do not apply header trimming rules from option file. |
|
noheadertrim |
Removing Selected Message Header Lines Do not apply header trimming rules from options file. |
|
noinner |
Do not to rewrite inner message header lines. |
|
noinnertrim |
Removing Selected Message Header Lines Do not apply header trimming to inner message headers. |
|
noreceivedfor |
Constructing Received Header Lines from Envelope To and From Addresses Construct Received: header lines without including any envelope recipient information. |
|
noreceivedfrom |
Constructing Received Header Lines from Envelope To and From Addresses Construct Received: header lines without including the original envelope From: address. |
|
noremotehost |
Specifying a Host Name to Use When Correcting Incomplete Addresses Use local host’s domain name as the default domain name to complete addresses |
|
noreverse |
Enabling Channel-Specific Use of the Reverse Database Exempts addresses in messages queued to the channel from address reversal processing |
|
norules |
Enabling Channel-specific Rewrite Rules Checks Do not enforce channel-specific rewrite rule checks for this channel. |
|
nox_env_to |
Generating/Removing X-Envelope-to Header Lines Remove X-Envelope-to header lines. |
|
personalinc |
Handling Personal Names in Address Header Lines Leave personal name fields in message header lines intact. |
|
personalmap |
Handling Personal Names in Address Header Lines Run personal names through PERSONAL_NAMES mapping table. |
|
personalomit |
Handling Personal Names in Address Header Lines Remove personal name fields from message header lines. |
|
personalstrip |
Handling Personal Names in Address Header Lines Strip problem characters from personal name fields in header lines. |
|
receivedfor |
Constructing Received Header Lines from Envelope To and From Addresses If a message is addressed to just one envelope recipient, to include that envelope To: address in the Received: header line it constructs. |
|
receivedfrom |
Constructing Received Header Lines from Envelope To and From Addresses Include the original envelope From: address when constructing a Received: header line for an incoming message if the MTA has changed the envelope From: address. |
|
remotehost |
Specifying a Host Name to Use When Correcting Incomplete Addresses Use remote host’s name as the default domain name to complete addresses |
|
restricted |
Enabling Restricted Mailbox Encoding Channel connects to mail systems that require this encoding. |
|
reverse |
Enabling Channel-Specific Use of the Reverse Database Check addresses against address reversal database or REVERSE mapping |
|
rules |
Enabling Channel-specific Rewrite Rules Checks Enforce channel-specific rewrite rule checks for this channel. |
|
sensitivitycompanyconfidential |
Companyconfidential is the upper sensitivity limit of messages accepted. |
|
sensitivitynormal |
Normal is the upper sensitivity limit of messages accepted. |
|
sensitivitypersonal |
Personal is the upper sensitivity limit of messages accepted. |
|
sensitivityprivate |
Private is the upper sensitivity limit of messages accepted. |
|
sourcecommentinc |
Handling Comments in Address Header Lines Leave comments in incoming message header lines. |
|
sourcecommentmap |
Handling Comments in Address Header Lines Runs comment strings in header lines through source channels. |
|
sourcecommentomit |
Handling Comments in Address Header Lines Remove comments from incoming message header lines, for example, To:, From:, and Cc: headers. |
|
sourcecommentstrip |
Handling Comments in Address Header Lines Remove problematic characters from comment field in incoming header lines. |
|
sourcecommenttotal |
Handling Comments in Address Header Lines Strip comments (material in parentheses) in incoming messages. |
|
sourcepersonalinc |
Handling Personal Names in Address Header Lines Leave personal names in incoming message header lines intact. |
|
sourcepersonalmap |
Handling Personal Names in Address Header Lines Run personal names through source channels. |
|
sourcepersonalomit |
Handling Personal Names in Address Header Lines Remove personal name fields from incoming message header lines. |
|
sourcepersonalstrip |
Handling Personal Names in Address Header Lines Strip problematic characters from personal name fields in incoming message header lines. |
|
unrestricted |
Enabling Restricted Mailbox Encoding Tells the MTA not to perform RFC 1137 encoding and decoding. |
|
x_env_to |
Generating/Removing X-Envelope-to Header Lines Enables generation of X-Envelope-to header lines. |
Table 12–7 Incoming Channel Matching and Switching Keywords
Keyword |
Definition |
|
---|---|---|
allowswitchchannel |
Alternate Channels for Incoming Mail (Switch Channels) Allows switching to this channel from a switchchannel channel |
|
nosaslswitchchannel |
SMTP Authentication, SASL, and TLS No switching to this channel upon successful SASL authentication |
|
noswitchchannel |
Alternate Channels for Incoming Mail (Switch Channels) No channel switching should be done to or from the channel. |
|
switchchannel |
Alternate Channels for Incoming Mail (Switch Channels) Switches from the server channel to the channel associated with the originating host. |
|
saslswitchchannel |
SMTP Authentication, SASL, and TLS Cause incoming connections to be switched to a specified channel upon a client’s successful use of SASL. |
|
tlsswitchchannel |
Switches to another channel upon successful TLS negotiation. |
Table 12–8 Logging and Debugging Channel Keywords
Keyword |
Definition |
|
---|---|---|
logging |
Log message enqueues and dequeues into the log file and activates logging for a particular channel. |
|
loopcheck |
Places a string into the SMTP EHLO response banner in order for the MTA to check if it is communicating with itself. |
|
master_debug |
Create debugging output in the channel’s master program output. |
|
nologging |
Do not log message enqueues and dequeues into the log file. |
|
noloopcheck |
No string into the SMTP EHLO response banner. |
|
nomaster_debug |
No debugging output in the channel’s master program output. |
|
noslave_debug |
Do not generate slave debugging output. |
|
slave_debug |
Generate slave debug output. |
Table 12–9 Long Address Lists or Headers Channel Keywords
Keyword |
Definition |
|
---|---|---|
expandchannel |
Expansion of Multiple Addresses Specifies channel in which to perform deferred expansion due to application of expandlimit. |
|
expandlimit |
Expansion of Multiple Addresses Processes an incoming message “off-line” when the number of addressees exceeds this limit. |
|
holdlimit |
Expansion of Multiple Addresses Holds a message when the number of addresses exceeds this limit. |
|
maxprocchars |
Maximum length header that can be processed and rewritten. |
Table 12–10 Mailbox Filter Channel Keywords
Keyword |
Definition |
|
---|---|---|
channelfilter |
Specifying Mailbox Filter File Location Location of channel filter file; same as destinationfilter. |
|
destinationfilter |
Location of channel filter file that applies to outgoing messages. |
|
destinationspamfilterXoptin |
Run messages destined to this channel through spam filtering software X. |
|
fileinto |
Specifying Mailbox Filter File Location Specify effect on address when a mailbox filter fileinto operation is applied. |
|
filter |
Specifying Mailbox Filter File Location Specify the location of user filter files. |
|
nochannelfilter |
Specifying Mailbox Filter File Location No channel filtering for outgoing messages. Also known as nodestinationfilter. |
|
nodestinationfilter |
Specifying Mailbox Filter File Location Do not perform channel filtering for outgoing messages. |
|
nofileinto |
Specifying Mailbox Filter File Location Mailbox filter fileinto operator has no effect. |
|
nofilter |
Specifying Mailbox Filter File Location Do not perform user mailbox filtering. |
|
nosourcefilter |
Specifying Mailbox Filter File Location Do not perform channel filtering for incoming messages. |
|
sourcefilter |
Specifying Mailbox Filter File Location Specify the location of channel filter file for incoming messages. |
|
sourcespamfilterXoptin |
Run messages originating from this channel through spam filtering software X. |
Table 12–11 NO-SOLICIT SMTP Extension Support Keywords
Keyword |
Definition |
|
---|---|---|
sourcenosolicit |
NO-SOLICIT SMTP Extension Support Specifies a comma-separated list of solicitation field values that will be blocked in mail submitted by this channel. |
|
destinationnosolicit |
NO-SOLICIT SMTP Extension Support Specifies a comma-separated list of solicitation field values that will not be accepted in mail queued to this channel. |
Table 12–12 Notification and Postmaster Messages Keywords
Keyword |
Definition |
|
---|---|---|
(See page Controlling Delivery Status Notification Messages for complete notification procedures) |
||
aliaspostmaster |
Postmaster Returned Message Content Messages addressed to the user name postmaster at the official channel name are redirected to postmaster@local-host, where local-host is the local host name (the name on the local channel). |
|
copysendpost |
Sends a copy of the failure notice to the postmaster unless the originator address on the failing message is blank. |
|
copywarnpost |
Sends a copy of the warning message to the postmaster unless the originator address on the undelivered message is blank. |
|
errsendpost |
Sends a copy of the failure notice to the postmaster only when the notice cannot be returned to the originator. |
|
errwarnpost |
Sends a copy of the warning message to the postmaster when the notice cannot be returned to the originator. |
|
includefinal |
To Include Altered Addresses in Status Notification Messages Include final form of recipient address in delivery notifications. |
|
nonurgentnotices |
To Set Notification Message Delivery Intervals Specifies the amount of time that may elapse before notices are sent and messages returned for messages of non-urgent priority. |
|
noreturnaddress |
Postmaster Returned Message Content Use RETURN_ADDRESS option value as postmaster address name. |
|
noreturnpersonal |
Postmaster Returned Message Content Use RETURN_PERSONAL option value as postmaster personal name. |
|
normalnotices |
To Set Notification Message Delivery Intervals Specifies the amount of time that may elapse before notices are sent and messages returned for messages of normal priority. |
|
nosendpost |
Disables sending a copy of all failed messages to the postmaster. |
|
notices |
To Set Notification Message Delivery Intervals Specifies the amount of time that may elapse before notices are sent and messages returned. |
|
nowarnpost |
Disables sending a copy of warning messages to the postmaster. |
|
postheadbody |
Postmaster Returned Message Content Returns both the headers and the contents of the message. |
|
postheadonly |
Postmaster Returned Message Content Returns only headers to the postmaster. |
|
returnaddress |
Postmaster Returned Message Content Specifies the return address for the local postmaster. |
|
returnenvelope |
Blank Envelope Return Addresses Control use of blank envelope return addresses. |
|
returnpersonal |
Postmaster Returned Message Content Set the personal name for the local postmaster. |
|
sendpost |
Enables sending a copy of all failed messages to the postmaster. |
|
suppressfinal |
To Include Altered Addresses in Status Notification Messages Suppress the final address form from notification messages, if an original address form is present, from notification messages. |
|
urgentnotices |
To Set Notification Message Delivery Intervals Specify the amount of time which may elapse before notices are sent and messages returned for messages of urgent priority. |
|
useintermediate |
To Include Altered Addresses in Status Notification Messages Uses an intermediate form of the address produced after list expansion, but prior to user mailbox name generation. |
|
warnpost |
Enables sending a copy of warning messages to the postmaster. |
Table 12–13 Processing Control and Job Submission Keywords
Keyword |
Definition |
|
---|---|---|
(See Configuring Message Processing and Delivery for greater functional granularity) |
||
backoff |
Specifying the Retry Frequency for Messages that Failed Delivery Frequency of attempted redelivery of unsuccessfully delivered messages. Can be overridden by the keywords normalbackoff, nonurgentbackoff, urgentbackoff. |
|
bidirectional |
Setting Channel Directionality Channel served by a master and slave program. |
|
deferred |
Implementing Deferred Delivery Dates Recognize and honor of the Deferred-delivery: header line. |
|
expandchannel |
Expansion of Multiple Addresses Specifies channel in which to perform deferred expansion due to application of expandlimit. |
|
expandlimit |
Expansion of Multiple Addresses Processes an incoming message “off-line” when the number of addressees exceeds this limit. |
|
filesperjob |
Number of queue entries to be processed by a single job. |
|
Implementing Deferred Delivery Dates Starts delivery immediately after submission for urgent, normal, and non-urgent messages. |
||
master |
Setting Channel Directionality Channel served by a master program (master). |
|
maxjobs |
Maximum number of jobs that can be running concurrently for the channel. |
|
nodeferred |
Implementing Deferred Delivery Dates Specifies that Deferred-delivery: header line not be honored. |
|
nonurgentbackoff |
Specifying the Retry Frequency for Messages that Failed Delivery The frequency for attempted redelivery of nonurgent messages. |
|
nonurgentblocklimit |
Message Priority Based on Size Forces messages above this size to lower than nonurgent priority (second class priority), meaning that the messages will always wait for the next periodic job for further processing. |
|
normalbackoff |
Specifying the Retry Frequency for Messages that Failed Delivery The frequency for attempted redelivery of normal messages. |
|
normalblocklimit |
Message Priority Based on Size Forces messages above this size to nonurgent priority. |
|
noservice |
Service conversions for messages coming into this channel must be enabled via CHARSET-CONVERSION. |
|
pool |
Processing Pools for Channel Execution Jobs Specifies a pool for a channel. Must be followed by the pool name to which delivery jobs for the current channel should be pooled. |
|
service |
Unconditionally enables service conversions regardless of CHARSET-CONVERSION entry. |
|
slave |
Setting Channel Directionality Channel served by a slave program (slave). |
|
threaddepth |
Number of messages triggering new thread with multithreaded SMTP client. |
|
transactionlimit |
Limits the number of messages allowed per connection. |
|
urgentbackoff |
Specifying the Retry Frequency for Messages that Failed Delivery The frequency for attempted redelivery of urgent messages. |
|
urgentblocklimit |
Message Priority Based on Size Forces messages above this size to normal priority. |
|
user |
Used on pipe channels to indicate under what user name to run. |
Table 12–14 Sensitivity Limit Keywords
Keyword |
Definition |
|
---|---|---|
sensitivitycompanyconfidential |
Upper sensitivity limit of messages accepted. |
|
sensitivitynormal |
Normal is the upper sensitivity limit of messages accepted. |
|
sensitivitypersonal |
Personal is the upper sensitivity limit of messages accepted. |
|
sensitivityprivate |
Private is the upper sensitivity limit of messages accepted. |
Table 12–15 Keywords for Limits on Messages, User Quotas, Privileges, and Authentication Attempts
Keyword |
Definition |
|
---|---|---|
alternatechannel |
Retargeting Messages Exceeding Limit on Size or Recipients Alternate destination channel for alternateblocklimit, alternatelinelimit, and alternaterecipientlimit |
|
alternateblocklimit |
Retargeting Messages Exceeding Limit on Size or Recipients Specifies limit on the number of blocks in a message before it will be sent to alternativechannel. |
|
alternatelinelimit |
Retargeting Messages Exceeding Limit on Size or Recipients Specifies limit on the number of lines in a message before it will be sent to alternativechannel. |
|
alternaterecipientlimit |
Retargeting Messages Exceeding Limit on Size or Recipients Specifies limit on the number of recipients in a message before it will be sent to alternativechannel. |
|
blocklimit |
Specifying Absolute Message Size Limits Maximum number of MTA blocks allowed per message. |
|
disconnectbadauthlimit |
Limits on Unsuccessful Authentication Attempts Limit on the number of unsuccessful authentication attempts that will be allowed in a session before the session is disconnected. |
|
disconnectbadcommandlimit |
Limits the number of session bad commands. |
|
disconnectrecipientlimit |
Limits the number of session recipients. |
|
disconnectrejectlimit |
Limits the number of rejected recipients. |
|
disconnecttransactionlimit |
Limits the number of transactions. |
|
headerlimit |
Limit on the maximum size of the primary (outermost) message header |
|
holdexquota |
Handling Mail Delivery to Over Quota Users Hold messages for users that are over quota. |
|
holdlimit |
Expansion of Multiple Addresses Holds an incoming message when the number of addresses exceeds this limit. |
|
linelength |
Imposing Message Line Length Restrictions Limits the maximum permissible message line length on a channel-by-channel basis. |
|
linelimit |
Specifying Absolute Message Size Limits Maximum number of lines allowed per message. |
|
maxblocks |
Automatic Fragmentation of Large Messages Specifies the maximum number of blocks allowed in a message. |
|
maxlines |
Automatic Fragmentation of Large Messages Specifies the maximum number of lines allowed in a message. |
|
nameparameterlengthlimit |
Controlling the Length of General and Filename Content-type and Content-disposition Parameters Controls the points at which the name content-type and filename content-disposition parameters are truncated. |
|
noblocklimit |
Specifying Absolute Message Size Limits No limit for the number of MTA blocks allowed per message. |
|
noexquota |
Handling Mail Delivery to Over Quota Users Return to originator any messages to users who are over quota. |
|
nolinelimit |
Specifying Absolute Message Size Limits No limit specified for the number of lines allowed per message. |
|
nonurgentblocklimit |
Message Priority Based on Size Forces messages above this size to lower than nonurgent priority (second class priority), meaning that the messages will always wait for the next periodic job for further processing. |
|
normalblocklimit |
Message Priority Based on Size Forces messages above this size to nonurgent priority. |
|
parameterlengthlimit |
Controlling the Length of General and Filename Content-type and Content-disposition Parameters Controls the points at which general content-type and content-disposition parameters are truncated. |
|
recipientcutoff. |
Rejects message if recipients exceed this value. |
|
recipientlimit |
Limits the number of recipient addresses that will be accepted for the message. |
|
rejectsmtplonglines |
Handling SMTP Mail with Lines Exceeding 1000 Characters Rejects messages that contain lines longer than 1000 characters (including CRLF). |
|
sourceblocklimit |
Specifying Absolute Message Size Limits Maximum number of MTA blocks allowed per incoming message. |
|
truncatesmtplonglines |
Handling SMTP Mail with Lines Exceeding 1000 Characters Truncate the line when it is over 1000 characters. |
|
wrapsmtplonglines |
Handling SMTP Mail with Lines Exceeding 1000 Characters Wrap the line when it is over 1000 characters. |
|
urgentblocklimit |
Message Priority Based on Size Forces messages above this size to normal priority. |
Table 12–16 SMTP Authentication, SASL and TLS Keywords
Keyword |
Definition |
|
---|---|---|
(See SMTP Authentication, SASL, and TLS for greater functional granularity) |
||
authrewrite |
TCP/IP Connection and DNS Lookup Support Used on a source channel to have the MTA propagate authenticated originator information, if available, into the headers. |
|
maysaslserver |
SMTP Authentication, SASL, and TLS Permit clients to attempt to use SASL authentication. |
|
maytls |
Causes the MTA to offer TLS to incoming connections and to attempt TLS upon outgoing connections. |
|
maytlsclient |
The MTA SMTP client will attempt TLS use when sending outgoing messages, if sending to an SMTP server that supports TLS. |
|
maytlsserver |
The MTA SMTP server will advertise support for the STARTTLS extension and will allow TLS use when receiving messages. |
|
msexchange |
Specifying Microsoft Exchange Gateway Channels Used on TCP/IP channels to tell the MTA that this is a channel that communicates with Microsoft Exchange gateways and clients. |
|
mustsaslserver |
SMTP Authentication, SASL, and TLS SMTP server does not accept messages unless remote client successfully authenticates. |
|
musttls |
Insist upon TLS in both outgoing and incoming connections. |
|
musttlsclient |
The MTA SMTP client will insist on TLS use when sending outgoing messages (the MTA will issue the STARTTLS command and that command must succeed). |
|
musttlsserver |
The MTA SMTP server will advertise support for the STARTTLS extension and will insist upon TLS use when receiving incoming messages. |
|
nomsexchange |
TCP/IP Connection and DNS Lookup Support Default. |
|
nosasl |
SMTP Authentication, SASL, and TLS SASL authentication is not permitted or attempted. |
|
nosaslserver |
SMTP Authentication, SASL, and TLS SASL authentication is not permitted. |
|
notls |
TLS will not be permitted or attempted. |
|
notlsclient |
TLS use will not be attempted by the MTA SMTP client on outgoing connections (the STARTTLS command will not be issued during outgoing connections). |
|
notlsserver |
TLS use will not be permitted by the MTA SMTP server on incoming connections (the STARTTLS extension will not be advertised by the SMTP server nor the command itself accepted). |
|
saslswitchchannel |
SMTP Authentication, SASL, and TLS Cause incoming connections to be switched to a specified channel upon a client’s successful use of SASL. |
|
tlsswitchchannel |
Cause incoming connections to be switched to a specified channel upon a client's successful TLS negotiation. It takes a required value, specifying the channel to which to switch. |
Table 12–17 SMTP Commands and Protocol Keywords
Keyword |
Definition |
|
---|---|---|
(See SMTP Command and Protocol Support for greater functional granularity) |
||
allowetrn |
Honors ETRN commands. |
|
blocketrn |
Blocks ETRN commands. |
|
checkehlo |
Checks the SMTP response banner to determine whether to use EHLO or HELO. |
|
disableetrn |
Disable support for the ETRN SMTP command. |
|
domainetrn |
Honors only those ETRN commands that specify a domain. |
|
domainvrfy |
Issues VRFY commands using a full address. |
|
ehlo |
Uses the SMTP EHLO command on initial connections. |
|
eightbit |
Character Set Labeling and Eight-Bit Data Channel supports eight-bit characters. |
|
eightnegotiate |
Character Set Labeling and Eight-Bit Data Channel should negotiate use of eight-bit transmission if possible. |
|
eightstrict |
Character Set Labeling and Eight-Bit Data Reject messages with headers that contain unnegotiated eight-bit data. |
|
expnallow |
Allows EXPN even if it has been disabled at the SMTP server level with the DISABLE_EXPAND SMTP channel option. |
|
expndisable |
Disables EXPN unconditionally. |
|
expndefault |
Allows EXPN if the SMTP server is set to allow it. |
|
localvrfy |
Issues VRFY commands using a local address. |
|
mailfromdnsverify |
Verifies domain used on MAIL FROM: command exists in the DNS. |
|
noehlo |
Does not use the EHLO command. |
|
nomailfromdnsverify |
Does not verify that the domain used on the MAIL FROM: command exists in the DNS. |
|
nosendetrn |
Does not send ETRN commands. |
|
nosmtp |
Channel Protocol Selection and Line Terminators Does not support the SMTP protocol. This is the default. |
|
novrfy |
Does not issue VRFY commands. |
|
sendetrn |
Sends ETRN commands. |
|
sevenbit |
Character Set Labeling and Eight-Bit Data Do not support 8-bit characters; 8-bit characters must be encoded. |
|
silentetrn |
Honors ETRN commands without echoing channel information. |
|
smtp |
Channel Protocol Selection and Line Terminators Supports the SMTP protocol. The keyword smtp is mandatory for all SMTP channels. (This keyword is equivalent to smtp_crorlf.) |
|
smtp_cr |
Channel Protocol Selection and Line Terminators Accepts lines terminated with a carriage return (CR) without a following line feed (LF). |
|
smtp_crlf |
Channel Protocol Selection and Line Terminators Lines must be terminated with a carriage return (CR) line feed (LF) sequence. |
|
smtp_crorlf |
Channel Protocol Selection and Line Terminators Lines may be terminated with any of a carriage return (CR), or a line feed (LF) sequence, or a full CRLF. |
|
smtp_lf |
Channel Protocol Selection and Line Terminators Accepts lines terminated with linefeed (LF) without preceding CR. |
|
streaming |
Controls the degree of protocol streaming used in the protocol associated with a channel. |
|
vrfyallow |
Provides informative responses to VRFY commands. |
|
vrfydefault |
Provides default responses to VRFY command, according to channel’s HIDE_VERIFY option setting. |
|
vrfyhide |
Provides obfuscatory responses to SMTP VRFY command. |
Table 12–18 TCP/IP Connection and DNS Lookup Support Keywords
Keyword |
Definition |
|
---|---|---|
TCP/IP Connection and DNS Lookup Support (See TCP/IP Connection and DNS Lookup Support for greater functional granularity) |
||
cacheeverything |
Caching for Channel Connection Information Caches all connection information. |
|
cachefailures |
Caching for Channel Connection Information Caches only connection failure information. |
|
cachesuccesses |
Caching for Channel Connection Information Caches only connection success information. |
|
connectalias |
Address Rewriting Upon Message Dequeue Deliver to whatever host is listed in the recipient address. |
|
connectcanonical |
Address Rewriting Upon Message Dequeue Connect to the host alias for the system to which the MTA would be connected. |
|
daemon |
Connects to a specific host system regardless of the envelope address. |
|
defaultmx |
Channel determines whether to do MX lookups from network. |
|
defaultnameservers |
Consults TCP/IP stack’s choice of nameservers. |
|
forwardcheckdelete |
If reverse DNS lookup performed, next performs a forward lookup on the returned name to check that the returned IP number matches the original; if not, deletes the name and use the IP address. |
|
forwardchecknone |
Does not perform a forward lookup after a DNS reverse lookup. |
|
forwardchecktag |
If a reverse DNS lookup has been performed, next performs a forward lookup on the returned name to check that the returned IP number matches the original; if not, tags the name with *. |
|
identnone |
No perform IDENT lookups; performs IP to hostname translation; includes both hostname and IP address in Received: header. |
|
identnonelimited |
No IDENT lookups; does perform IP to hostname translation, but does not use the hostname during channel switching; includes both hostname and IP address in Received: header. |
|
identnonenumeric |
Does not perform IDENT lookups or IP to hostname translation. |
|
identnonesymbolic |
Does not perform IDENT lookups; does perform IP to hostname translation; includes only the hostname in Received: header. |
|
identtcp |
Performs IDENT lookups on incoming SMTP connections and IP to hostname translation; include both hostname and IP address in Received: header |
|
identtcplimited |
Performs IDENT lookups on incoming SMTP connections and IP to hostname translation, but do not use the hostname during channel switching. Include hostname and IP address in Received: header. |
|
indenttcpnumeric |
Performs IDENT lookups on incoming SMTP connections, but does not perform IP to hostname translation. |
|
identtcpsymbolic |
Performs IDENT lookups on incoming SMTP connections and IP to hostname translation; includes only hostname in Received: header. |
|
interfaceaddress |
TCP/IP Port Number and Interface Address Binds to the specified TCP/IP interface address. |
|
lastresort |
Specifies a last resort host. |
|
mailfromdnsverify |
Verifies that the domain used on the MAIL FROM: command exists in the DNS. |
|
mx |
TCP/IP network and software supports MX records lookup. |
|
nameservers |
Specifies a list of nameservers to consult rather than consulting the TCP/IP stack's own choice of nameservers; nameservers requires a space separated list of IP addresses for the nameservers. |
|
nocache |
Caching for Channel Connection Information Does not cache any connection information. |
|
nomailfromdnsverify |
Does not verify that the domain used on the MAIL FROM: command exists in the DNS. |
|
nomx |
TCP/IP network does not support MX lookups. |
|
nonrandomemx |
Does MX lookups; does not randomize returned entries with equal precedence. |
|
port |
TCP/IP Port Number and Interface Address Specifies the default port number for SMTP connections. The standard port is 25. |
|
randommx |
Does MX lookups; randomizes returned entries with equal precedence. |
|
single |
Specifies that a separate copy of the message should be created for each destination address on the channel. |
|
single_sys |
Creates single copy of message for each destination system used. |
|
threaddepth |
Number of messages triggering new thread with multithreaded SMTP client. |
Table 12–19 Miscellaneous Keywords
Keyword |
Definition |
|
---|---|---|
deferralrejectlimit |
Setting Limits on Bad RCPT TO Addresses Sets limit on the number of bad RCPT TO: addresses |
|
dispositionchannel |
Overrides the process channel as the place to initially queue delivery status notifications (DSNs). |
|
destinationfilter |
Specifying Mailbox Filter File Location Used on general MTA channels to specify a channel-level filter to apply to outgoing messages. |
|
filter |
Specifying Mailbox Filter File Location Takes a required URL argument describing the filter file location |
|
nodestinationfilter |
Specifying Mailbox Filter File Location No channel mailbox filter is enabled for either direction of the channel. |
|
nosourcefilter |
Specifying Mailbox Filter File Location No channel mailbox filter is enabled for source channel. |
|
nofilter |
Specifying Mailbox Filter File Location The default and means that a user mailbox filters are not enabled for the channel. |
|
notificationchannel |
Overrides the process channel as the place to initially queue message disposition notifications (MDNs). |
|
sourcefilter |
Specifying Mailbox Filter File Location Used on general MTA channels to specify a channel-level filter to apply to incoming messages |
|
submit |
Used to mark a channel as a submit-only channel. |
|
user |
Used on pipe channels to indicate under what user name to run. |
Depending on the type of installation, Messaging Server provides several SMTP channels at installation time (see table below). These channels implement SMTP over TCP/IP. The multithreaded TCP SMTP channel includes a multithreaded SMTP server that runs under the control of the Dispatcher. Outgoing SMTP mail is processed by the channel program tcp_smtp_client, and runs as needed under the control of the Job Controller.
Table 12–20 SMTP Channels
Channel |
Definition |
---|---|
tcp_local |
Receives inbound messages from remote SMTP hosts. Depending on whether you use a smarthost/firewall configuration, either sends outbound messages directly to remote SMTP hosts or sends outbound messages to the smarthost/firewall system. |
tcp_intranet |
Receives and sends messages within the intranet. |
tcp_auth |
Used as a switch channel for tcp_local; authenticated users switch to the tcp_auth channel to avoid relay-blocking restrictions. |
tcp_submit |
Accepts message submissions—usually from user agents—on the reserved submission port 587 (see RFC 2476). |
tcp_tas |
IA special channel used by sites doing Unified Messaging. |
You can modify the definitions of these channels or create new channels by adding or removing channel keywords as described in this section. In addition, an option file may be used to control various characteristics of TCP/IP channels. Such an option file must be stored in the MTA configuration directory (msg_svr_base/config) and named x_option, where x is the name of the channel. Refer to the Option File in Sun Java System Messaging Server 6 2005Q4 Administration Reference for details.
This section is divided into the following subsections:
TCP/IP channel option files control various characteristics of TCP/IP channels. Channel option files must be stored in the MTA configuration directory and named x_option, where x is the name of the channel. For example, /msg_svr_base/config/tcp_local_option
The option file consists of one or more keywords and associated values. For example you can disable mailing list expansion on your server by including the DISABLE_EXPAND keyword in the option file and setting the value to 1.
Other option file keywords allow you to:
Set a limit on the number of recipients allowed per message (ALLOW_RECIPIENTS_PER_TRANSACTION)
Set a limit on the number of messages allowed per connection (ALLOW_TRANSACTIONS_PER_SESSION)
Fine tune the type of information logged to the MTA log file (LOG_CONNECTION, LOG_TRANPORTINFO)
Specify the maximum number of simultaneous outbound connections that the client channel program allows (MAX_CLIENT_THREADS)
For information about all channel option keywords and syntax, see the Sun Java System Messaging Server 6 2005Q4 Administration Reference.
You can specify whether an SMTP channel supports certain SMTP commands, such as EHLO, ETRN, EXPN and VRFY. You can also specify whether the channel support DNS domain verification, which characters the channel accepts as line terminators, and so on. This section describes the following:
Table 12–21 summarizes the keywords described in this section.
Table 12–21 SMTP Command and Protocol Keywords
Channel Keyword(s) |
Description |
---|---|
Protocol Selection and Line Terminators |
Specifies whether the channel supports the SMTP protocol and specifies the character sequences accepted as line terminators. |
smtp |
Supports the SMTP protocol. The keyword smtp is mandatory for all SMTP channels. (This keyword is equivalent to smtp_crorlf.) |
nosmtp |
Does not support the SMTP protocol. This is the default. |
smtp_cr |
Accepts lines terminated with a carriage return (CR) without a following line feed (LF). |
smtp_crlf |
Lines must be terminated with a carriage return (CR) line feed (LF) sequence. |
smtp_lf |
Accepts lines terminated with a linefeed (LF) without a preceding CR. |
smtp_crorlf |
Lines may be terminated with any of a carriage return (CR), or a line feed (LF) sequence, or a full CRLF. |
EHLO keywords |
Specifies how the channel handles EHLO commands |
ehlo |
Uses the SMTP EHLO command on initial connections. |
checkehlo |
Checks the SMTP response banner to determine whether to use EHLO or HELO. |
noehlo |
Does not use the EHLO command. |
ETRN keywords |
Specifies how the channel handles ETRN commands (requests for queue processing) |
allowetrn |
Honors ETRN commands. |
blocketrn |
Blocks ETRN commands. |
domainetrn |
Honors only those ETRN commands that specify a domain. |
silentetrn |
Honors ETRN commands without echoing channel information. |
sendetrn |
Sends ETRN commands. |
nosendetrn |
Does not send ETRN commands. |
VRFY keywords |
Specifies how the channel handles VRFY commands |
domainvrfy |
Issues VRFY commands using a full address. |
localvrfy |
Issues VRFY commands using a local address. |
novrfy |
Does not issue VRFY commands. |
vrfyallow |
Provides informative responses to VRFY commands. |
vrfydefault |
Provides default responses to VRFY command, according to channel’s HIDE_VERIFY option setting. |
vrfyhide |
Provides obfuscatory responses to SMTP VRFY command. |
EXPN Keywords |
Specifies how the channel handles EXPN keywords |
expnallow |
Allows EXPN even if it has been disabled at the SMTP server level with the DISABLE_EXPAND SMTP channel option. |
expndisable |
Disables EXPN unconditionally. |
expndefault |
Allows EXPN if the SMTP server is set to allow it. (Default) |
DNS Domain Verification |
Specifies whether the channel performs DNS domain verification |
mailfromdnsverify |
Verifies that the domain used on the MAIL FROM: command exists in the DNS. |
nomailfromdnsverify |
Does not verify that the domain used on the MAIL FROM: command exists in the DNS. |
Character Sets and Eight-bit data |
Specifies how the channel handles eight-bit data (Note: Although these keywords are commonly used on SMTP channels, they are potentially relevant to any sort of channel.) |
charset7 |
Default character set to associate with 7-bit text messages |
charset8 |
Default character set to associate with 8-bit text messages |
charsetesc |
Default character set to associate with 7-bit text containing the escape character |
eightbit |
Channel supports eight-bit characters. |
eightnegotiate |
Channel should negotiate use of eight-bit transmission if possible. |
eightstrict |
Channel should reject messages with headers that contain illegal eight-bit data. |
sevenbit |
Channel does not support eight-bit characters; eight-bit characters must be encoded. |
Protocol streaming |
Specify degree of protocol streaming for channel to use. |
streaming |
Controls the degree of protocol streaming used in the protocol associated with a channel. |
Keywords: smtp, nosmtp, smtp_crlf, smtp_cr, smtp_crorlf, smtp_lf
The smtp and nosmtp keywords specify whether or not a channel supports the SMTP protocol. The smtp keyword, or one of its variations, is mandatory for all SMTP channels.
The keywords smtp_crlf, smtp_cr, smtp_crorlf, and smtp_lf can be used on SMTP channels to specify the character sequences that the MTA will accept as line terminators. The keyword smtp_crlf means that lines must be terminated with a carriage return (CR) line feed (LF) sequence. The keyword smtp_lf or smtp means that an LF without a preceding CR is accepted. Finally, smtp_cr means that a CR is accepted without a following LF. These option affect only the handling of incoming material.
Because the SMTP standard requires CRLF as the line terminator, the MTA always generates the standard CRLF sequence. The various smtp keywords merely control whether the MTA will accept additional non-standard line terminators. For example, you can specify smtp_crlf if you want the MTA to accept only strictly legal SMTP messages and reject any messages with nonstandard line terminators.
Keywords: ehlo, noehlo, checkehlo
The SMTP protocol has been extended (RFC 1869) to allow for negotiation of additional commands. This is done by using the new EHLO command, which replaces RFC 821's HELO command. Extended SMTP servers respond to EHLO by providing a list of the extensions they support. Unextended servers return an unknown command error and the client then sends the old HELO command instead.
This fallback strategy normally works well with both extended and unextended servers. Problems can arise, however, with servers that do not implement SMTP according to RFC 821. In particular, some noncompliant servers are known to drop the connection on receipt of an unknown command.
The SMTP client implements a strategy whereby it attempts to reconnect and use HELO when any server drops the connection on receipt of an EHLO. However, this strategy might not work if the remote server not only drops the connection but also goes into a problematic state upon receipt of EHLO.
The channel keywords ehlo, noehlo, and checkehlo are provided to deal with such situations. The ehlo keyword tells the MTA to use the EHLO command on all initial connection attempts. The noehlo keyword disables all use of the EHLO command. The checkehlo keyword tests the response banner returned by the remote SMTP server for the string “ESMTP”. If this string is found EHLO is used; if not, 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.
Keywords: allowetrn, blocketrn, disableetrn, domainetrn, silentetrn, sendetrn, nosendetrn, novrfy
The ETRN command, defined in RFC 1985, provides an extension to the SMTP service whereby an SMTP client and server can interact to give the server an opportunity to start the processing of its queues for messages to go to a given host.
Using ETRN, an SMTP client can request that a remote SMTP server start processing the message queues destined for sending to the SMTP client. Thus, ETRN provides a way to implement “polling” of remote SMTP systems for messages incoming to one’s own system. This can be useful for systems that have only transient connections between each other, for example, sites that are set up as secondary mail exchange (MX) hosts for other sites that only have a dial-up connection to the Internet. By enabling this command, you permit remote, possibly dial-up, servers to request delivery of their mail.
The SMTP client specifies on the SMTP ETRN command line the name of the system to which to send messages (generally the SMTP client system’s own name). If the remote SMTP server supports the ETRN command, it will trigger execution of a separate process to connect back to the named system and send any messages awaiting delivery for that named system.
The allowetrn, blocketrn, domainetrn, and silentetrn keywords control the MTA response when a sending SMTP client issues the ETRN command, requesting that the MTA attempt to deliver messages in the MTA queues.
By default, the MTA will attempt to honor all ETRN commands; that is, the allowetrn keyword is enabled. You can specify that the MTA not honor ETRN commands by including the blocketrn keyword in the channel definition.
You can specify that the MTA honor all ETRN commands, but without echoing the name of the channel that the domain matched and that the MTA will be attempting to run by including the silentetrn keyword. The domainetrn keyword specifies that the MTA honor only ETRN commands that specify a domain; it also causes the MTA not to echo back the name of the channel that the domain matched and that the MTA will be attempting to run.
disableetrn disables support for the ETRN command entirely; ETRN is not advertised by the SMTP server as a supported command.
The sendetrn and nosendetrn channel keywords control whether the MTA sends an ETRN command at the beginning of an SMTP connection. The default is nosendetrn, meaning that the MTA will not send an ETRN command. The sendetrn keyword tells the MTA to send an ETRN command, if the remote SMTP server says it supports ETRN. The sendetrn keyword should be followed by the name of the system requesting that its messages receive a delivery attempt.
Keywords: domainvrfy, localvrfy, vrfyallow, vrfydefault, vrfyhide
The VRFY command enables SMTP clients to send a request to an SMTP server to verify that mail for a specific user name resides on the server. The VRFY command is defined in RFC 821.
The server sends a response indicating whether the user is local or not, whether mail will be forwarded, and so on. A response of 250 indicates that the user name is local; a response of 251 indicates that the user name is not local, but the server can forward the message. The server response includes the mailbox name.
Under normal circumstances there is no reason to issue a VRFY command as part of an SMTP dialogue. The SMTP RCPT TO command should perform the same function that VRFY does and return an appropriate error. However, servers exist that can accept any address in a RCPT TO (and bounce it later), whereas these same servers perform more extensive checking as part of a VRFY command.
By default, the MTA does not send a VRFY command (the novrfy keyword is enabled).
If necessary, the MTA can be configured to issue the SMTP VRFY command by including the domainvrfy or localvrfy keyword in the channel definition. The keyword domainvrfy causes a VRFY command to be issued with a full address (user@host) as its argument. The localvrfy keyword causes the MTA to issue a VRFY command with just the local part of the address (user).
The vrfyallow, vrfydefault, and vrfyhide keywords control the SMTP server’s response when a sending SMTP client issues an SMTP VRFY command.
The vrfyallow keyword tells the MTA to issue a detailed, informative response. The vrfydefault tells the MTA to provide a detailed, informative response, unless the channel option HIDE_VERIFY=1 has been specified. The vrfyhide keyword tells the MTA to issue only a vague, ambiguous response. 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.
Keywords: expnallow, expndisable, expndefault
expnallow allows EXPN even if it has been disabled at the SMTP server level with the DISABLE_EXPAND SMTP channel option. expndisable disables EXPN unconditionally. expndefault allows EXPN if the SMTP server is set to allow it (default). Expansion can be disabled on a per-list basis, but if it is disabled at the server level, the per-list settings are irrelevant.
Keywords: mailfromdnsverify, nomailfromdnsverify
Setting mailfromdnsverify on an incoming TCP/IP channel causes the MTA to verify that an entry in the DNS exists for the domain used on the SMTP MAIL FROM command and to reject the message if no such entry exists. The default, nomailfromdnsverify, means that no such check is performed. Note that performing DNS checks on the return address domain may result in rejecting some desired valid messages (for instance, from legitimate sites that simply have not yet registered their domain name, or at times of bad information in the DNS); it is contrary to the spirit of being generous in what you accept and getting the e-mail through, expressed in RFC 1123, Requirements for Internet Hosts. However, some sites may desire to perform such checks in cases where unsolicited bulk email (UBE) is being sent with forged e-mail addresses from non-existent domains.
Because the introduction of DNS wildcard entries in the COM and ORG top-level domains has made mailfromdnsverify less useful, the mailfromdnsverify code has been modified. When the DNS returns one or more A records, these values are compared against the domain literals specified by the new MTA option BLOCKED_MAIL_FROM_IPS. If a match is found, the domain is considered to be invalid. In order to restore correct behavior the current correct setting is:
BLOCKED_MAIL_FROM_IPS=[64.94.110.11]
This option’s value defaults to an empty string.
Keywords: charset7, charset8, charsetesc, sevenbit, eightbit, eightnegotiate, eightstrict
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 (the default), ISO-8859-1, ISO-8859-2, and many more that have been subsequently defined.
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 which lack character set labelling. Each keyword requires a single argument giving the character set name. The names are not checked for validity. Note, however, that character set conversion can only be done on character sets specified in the character set definition file charsets.txt found in the MTA table directory. The names defined in this file should be used if possible.
The charset7 character set name is used if the message contains only seven bit characters; the charset8 character set name will be used if eight bit data is found in the message; charsetesc will be used if a message containing only seven bit data happens to contain escape characters also. If the appropriate keyword is not specified no character set name will be inserted into Content-type: header lines.
Note that 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.
These character set specifications never override existing labels; that is, they have no effect if a message already has a character set label or is of a type other than text. It is usually appropriate to label MTA local channels as follows:
l ... charset7 US-ASCII charset8 ISO-8859-1 ... hostname |
If there is no Content-type header in the message, it is added. This keyword also adds the MIME-version: header line if it is missing.
The charsetesc keyword tends to be particularly useful on channels that receive unlabeled messages using Japanese or Korean character sets that contain the escape character.
Some transports restrict the use of characters with ordinal values greater than 127 (decimal). Most notably, some SMTP servers will strip the high bit and thus garble messages that use characters in this eight-bit range.
Messaging Server 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 enqueued to a given channel by specifying the sevenbit keyword. A channel should be marked eightbit if no such restriction exists.
The SMTP protocol disallows eightbit “unless the remote SMTP server explicitly says it supports the SMTP extension allowing eightbit.” Some transports such as extended SMTP may actually support a form of negotiation to determine if eight bit characters can be transmitted. Therefore, the use of the eightnegotiate keyword is strongly recommended to instruct the channel to encode messages when negotiation fails. This is the default for all channels; channels that do not support negotiation will simply assume that the transport is capable of handling eight bit data.
The eightstrict keyword tells Messaging Server to reject any incoming messages with headers that contain illegal eight bit data.
Keywords: streaming
Some mail protocols support streaming operations. This means that the MTA can issue more than one operation at a time and wait for replies to each operation to arrive in batches. The streaming keyword controls the degree of protocol streaming used in the protocol associated with a channel. This keyword requires an integer parameter; how the parameter is interpreted is specific to the protocol in use.
Under normal circumstances, the extent of streaming support available is negotiated using the SMTP pipelining extension. As such this keyword should never be used under normal circumstances.
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.
You can specify information about how the server handles TCP/IP connections and address lookups. This section describes the following:
Table 12–22 lists the TCP/IP connection and DNS lookup keywords described in this section.
Table 12–22 TCP/IP Connection and DNS Lookup Keywords
Channel Keyword(s) |
Description |
---|---|
Port Selection and Interface Address |
Specifies the default port number and interface address for SMTP connections |
port |
Specifies the default port number for SMTP connections. The standard port is 25. |
interfaceaddress |
Binds to the specified TCP/IP interface address. |
Cache Keywords |
Specifies how connection information is cached |
cacheeverything |
Caches all connection information. |
cachefailures |
Caches only connection failure information. |
cachesuccesses |
Caches only connection success information. |
nocache |
Does not cache any connection information. |
Reverse DNS Lookups |
Specifies how to handle Reverse DNS lookups on incoming SMTP connections |
forwardcheckdelete |
If a reverse DNS lookup has been performed, next performs a forward lookup on the returned name to check that the returned IP number matches the original; if not, deletes the name and use the IP address. |
forwardchecknone |
Does not perform a forward lookup after a DNS reverse lookup. |
forwardchecktag |
If a reverse DNS lookup has been performed, next performs a forward lookup on the returned name to check that the returned IP number matches the original; if not, tags the name with *. |
IDENT Lookups/DNS Reverse Lookups |
Specifies how to handle IDENT lookups and DNS Reverse Lookups on incoming SMTP connections |
identnone |
Does not perform IDENT lookups; does perform IP to hostname translation; includes both hostname and IP address in Received: header. |
identnonelimited |
Does not perform IDENT lookups; does perform IP to hostname translation, but does not use the hostname during channel switching; includes both hostname and IP address in Received: header. |
identnonenumeric |
Does not perform IDENT lookups or IP to hostname translation. |
identnonesymbolic |
Does not perform IDENT lookups; does perform IP to hostname translation; includes only the hostname in Received: header. |
identtcp |
Performs IDENT lookups on incoming SMTP connections and IP to hostname translation; include both hostname and IP address in Received: header |
identtcplimited |
Performs IDENT lookups on incoming SMTP connections and IP to hostname translation, but do not use the hostname during channel switching. Includes both hostname and IP address in Received: header. |
indenttcpnumeric |
Performs IDENT lookups on incoming SMTP connections, but does not perform IP to hostname translation. |
identtcpsymbolic |
Performs IDENT lookups on incoming SMTP connections and IP to hostname translation; includes only hostname in Received: header. |
MX Record Support and TCP/IP Nameserver |
Specifies whether and how the channel supports MX record lookups |
mx |
TCP/IP network and software supports MX records lookup. |
nomx |
TCP/IP network does not support MX lookups. |
defaultmx |
Channel determines whether to do MX lookups from network. |
randommx |
Does MX lookups; randomizes returned entries with equal precedence. |
nonrandomemx |
Does MX lookups; does not randomize returned entries with equal precedence. |
nameservers |
Specifies a list of nameservers to consult rather than consulting the TCP/IP stack's own choice of nameservers; nameservers requires a space separated list of IP addresses for the nameservers. |
defaultnameservers |
Consults TCP/IP stack’s choice of nameservers. |
lastresort |
Specifies a last resort host. |
Switch keywords |
Controls selection of alternate channels for incoming mail |
allowswitchchannel |
Allows switching to this channel from a switchchannel channel |
noswitchchannel |
Stays with the server channel; does not switch to the channel associated with the originating host; does not permit being switched to. |
switchchannel |
Switches from the server channel to the channel associated with the originating host. |
tlsswitchchannel |
Switches to another channel upon successful TLS negotiation. |
saslswitchchannel |
Switches to another channel when SASL authentication is successful. |
Target Host Choice and Storage of Message Copies |
Specifies a target host system and how message copies are stored. |
daemon |
Connects to a specific host system regardless of the envelope address. |
single |
Specifies that a separate copy of the message should be created for each destination address on the channel. |
single_sys |
Creates a single copy of the message for each destination system used. |
Keywords: port, interfaceaddress
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. Note that this keyword complements the Dispatcher option PORT, which controls which ports the MTA listens on for accepting SMTP connections.
The interfaceaddress keyword controls the address to which a TCP/IP channel binds as the source address for outbound connections; that is, on a system with multiple interface addresses this keyword controls which address will be used as the source IP address when the MTA sends outgoing SMTP messages. Note that this keyword complements the Dispatcher option INTERFACE_ADDRESS, which controls which interface address a TCP/IP channel listens on for accepting incoming connections and messages.
Keywords: cacheeverything, nocache, cachefailures, cachesuccesses
Channels using the SMTP protocol maintain a cache containing a history of prior connection attempts. This cache is used to avoid reconnecting multiple times to inaccessible hosts, which can waste lots of time and delay other messages. The cache is a per process cache and only persists during a single run of the outbound SMTP delivery channel.
The cache normally records both connection successes and failures. (Successful connection attempts are recorded in order to offset subsequent failures—a host that succeeded before but fails now doesn't warrant as long of a delay before making another connection attempt as does one that has never been tried or one that has failed previously.)
However, the caching strategy used by the MTA is not necessarily appropriate for all situations. Therefore channel keywords are provided to adjust the MTA cache.
The cacheeverything keyword enables all forms of caching and is the default. The nocache keyword disables all caching.
The cachefailures keyword enables caching of connection failures but not successes—this forces a somewhat more restricted retry than cacheeverything does. Finally, cachesuccesses caches only successes. This last keyword is effectively equivalent to nocache for SMTP channels.
Keywords: forwardchecknone, forwardchecktag, forwardcheckdelete
The forwardchecknone, forwardchecktag, and forwardcheckdelete channel keywords can modify the effects of doing reverse DNS lookups. These keywords can control whether the MTA does a forward lookup of an IP name found using a DNS reverse lookup, and if such forward lookups are requested, specify what the MTA does if the forward lookup of the IP name does not match the original IP number of the connection.
The forwardchecknone keyword is the default, and means that no forward lookup is done. The forwardchecktag keyword tells the MTA to do 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. The forwardcheckdelete keyword tells the MTA to do 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; in this case, the MTA uses the original IP address instead.
Having the forward lookup not match the original IP address is normal at many sites, where a more “generic” IP name is used for several different IP addresses.
Keywords: identnone, identnonelimited, identtnonnumeric, identnonesymbolic, identtcp, identtcpnumeric, identtcpsymbolic, identtcplimited
The IDENT keywords control how the MTA handles connections and lookups using the IDENT protocol. The IDENT protocol is described in RFC 1413.
The identtcp, identtcpsymbolic, and identtcpnumeric keywords tell the MTA to perform a connection and lookup using the IDENT protocol. The information obtained from the IDENT protocol (usually the identity of the user making the SMTP connection) is inserted into the Received: header of the message as follows:
identtcp inserts the host name corresponding to the incoming IP number, as reported from a DNS reverse lookup and the IP number itself.
identtcpsymbolic inserts the host name corresponding to the incoming IP number, as reported from a DNS reverse lookup; the IP number itself is not included in the Received: header.
identtcpnumeric inserts the actual incoming IP number—no DNS reverse lookup on the IP number is performed.
The remote system must be running an IDENT server for the IDENT lookup caused by identtcp, identtcpsymbolic, or identtcpnumeric to be useful.
Be aware that IDENT query attempts may incur a performance hit. Increasingly routers will “black hole” attempted connections to ports that they don’t recognize. If this happens on an IDENT query, then the MTA does not hear back until the connection times out (a TCP/IP stack controlled time-out, typically on the order of a minute or two).
Another performance factor occurs when comparing identtcp, indenttcplimited, or identtcpsymbolic to identtcpnumeric. The DNS reverse lookup called for with identtcp, identtcplimited, or identtcpsymbolic incurs some additional overhead to obtain the more user-friendly host name.
The identnone keyword disables IDENT lookup, but does specify IP to host name translation, and both IP number and host name will be included in the Received: header for the message.
The identnonesymbolic keyword disables IDENT lookup, but does do IP to host name translation; only the host name will be included in the Received: header for the message.
The identnonenumeric keyword disables this IDENT lookup and inhibits the usual DNS reverse lookup translation of IP number to host name, and might result in a performance improvement at the cost of less user-friendly information in the Received: header. This is the default.
The identtcplimited and identnonelimited keywords have the same effect as identtcp and identnone, respectively, as far as IDENT lookups, reverse DNS lookups, and information displayed in Received: header. Where they differ is that with identtcplimited or identnonelimited 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 reverse lookup succeeds in determining a host name.
Keywords: mx, nomx, defaultmx, randommx, nonrandommx
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 that the MTA system is connected to. The mx, nomx, defaultmx, randommx, nonrandommx keywords control MX record support.
The keyword randommx specifies that MX lookups should be done and MX record values of equal precedence should be processed in random order. The keyword nonrandommx specifies that MX lookups should be done and MX values of equal precedence should be processed in the same order in which they were received.
The mx keyword is currently equivalent to nonrandommx; it might change to be equivalent to randommx in a future release. The nomx keyword disables MX lookups. 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.
Keywords: nameservers, defaultnameservers
When name server lookups are being performed, the nameservers channel keyword may be used to specify a list of name servers to consult rather than consulting the TCP/IP stack's own choice of name servers. The nameservers keyword requires a space separated list of IP addresses for the name servers, as shown in the following example:
nameservers 1.2.3.1 1.2.3.2
The default, defaultnameservers, means use the TCP/IP stack's own choice of name servers.
To prevent name server lookups on UNIX, you can modify the nsswitch.conf file. On NT, modify the TCP/IP configuration.
Keywords: lastresort
The lastresort keyword is used to specify a host to connect to even when all other connection attempts fail. In effect this acts as an MX record of last resort. This is only useful on SMTP channels.
The keyword requires a single parameter specifying the name of the “system of last resort.” For example:
tcp_local single_sys smtp mx lastresort mailhub.siroe.com TCP-DAEMON
Keywords: switchchannel, allowswitchchannel, noswitchchannel. See also saslswitchchannel on SMTP Authentication, SASL, and TLS, and tlsswitchchannel on Transport Layer Security
The following keywords control selection of an alternate channel for incoming mail: switchchannel, allowswitchchannel, noswitchchannel.
When the MTA accepts an incoming connection from a remote system, it must choose a channel with which to associate the connection. Normally this decision is based on the transfer used; for example, an incoming SMTP over TCP/IP connection is automatically associated with the tcp_local channel.
This convention breaks down, however, when multiple outgoing channels with different characteristics are used to handle different systems over the same transfer. When this happens, incoming connections are not associated with the same channel as outgoing connections, and the result is that the corresponding channel characteristics are not associated with the remote system.
The switchchannel keyword provides a way to eliminate this difficulty. If switchchannel is specified on the initial channel the server uses, the IP address of the connecting (originating) host will be matched against the channel table and if it matches the source channel will change 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 doing a DNS reverse lookup. The source channel may change to any channel marked switchchannel or allowswitchchannel (the default). The noswitchchannel keyword specifies that no channel switching should be done to or from the channel.
Specification of switchchannel on anything other than a channel that a server associates with by default has no effect. At present, switchchannel only affects SMTP channels, but there are actually no other channels where switchchannel would be reasonable.
Keywords: daemon, single, single_sys
The interpretation and usage of the daemon keyword depends upon the type of channel to which it is applied.
The daemon keyword is used on SMTP channels to control the choice of a target host.
Normally, channels connect to whatever host is listed in the envelope 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 mail hub system, regardless of the envelope address. The actual remote system name should appear directly after the daemon keyword, as shown in the following example:
tcp_firewall smtp mx daemon firewall.acme.com TCP-DAEMON
If the argument after the daemon keyword is not a fully qualified domain name, the argument will be ignored and the channel will connect to the channel's official host. The official host is the fully qualified hostname associated with the channel. This can be specified in the second line of a three line channel block:
tcp_firewall smtp mx daemon router firewall.acme.com TCP-DAEMON
The official host can also be specified after TCP-DAEMON in a two-line channel block so outbound connections will identify themselves as a particular host:
tcp_firewall smtp mx daemon router TCP-DAEMON firewall.acme.com
When specifying the firewall or gateway system name as the official host name, the argument given to the daemon keyword is typically specified as router, as shown in the following example:
tcp_firewall smtp mx daemon router firewall.acme.com TCP-DAEMON
Other keywords of interest are single and single_sys. The single keyword specifies that a separate copy of the message should be created for each destination address on the channel. The single_sys keyword creates a single copy of the message for each destination system used. Note that at least one copy of each message is created for each channel the message is queued to, regardless of the keywords used.
Keywords: maysaslserver, mustsaslserver, nosasl, nosaslserver, saslswitchchannel, nosaslswitchchannel)
You can control whether the Messaging Server supports authentication to the SMTP server using SASL (Simple Authentication and Security Layer). SASL is defined in RFC 2222 and or more information about SASL, SMTP authentication, and security is in Chapter 19, Configuring Security and Access Control.
The maysaslserver, mustsaslserver, nosasl, nosaslserver, switchchannel, and saslswitchchannel channel keywords are used to configure SASL (SMTP AUTH) use during the SMTP protocol by SMTP channels such as TCP/IP channels.
nosasl is the default and means that SASL authentication is not permitted or attempted. It subsumes nosaslserver, which means that SASL authentication is not permitted. Specifying maysaslserver causes the SMTP server to permit clients to attempt to use SASL authentication. Specifying mustsaslserver causes the SMTP server to insist that clients use SASL authentication; the SMTP server does not accept messages unless the remote client successfully authenticates.
Use saslswitchchannel to cause incoming connections to be switched to a specified channel upon a client’s successful use of SASL. It takes a required value, specifying the channel to which to switch.
The authrewrite channel keyword and associated AUTH_REWRITE mapping table allows modification of header and envelope addresses using addressing information obtained from authentication operations. Specifically, SASL authentication can be configured to provide an authorized email address. Normally the SMTP AUTH information is used, though this may be overridden via the FROM_ACCESS mapping. The authrewrite keyword takes a required bit value, according to Table 12–23.
Table 12–23 authrewrite Bit Values
Bit |
Value |
Description |
---|---|---|
0 |
1 |
Don’t change anything (default) |
1 |
2 |
Add either a Sender: or Resent-sender: header field containing the address provided by the authentication operation. The Resent-variant is used if other resent- fields are present. |
2 |
4 |
Add a Sender: header field containing the address provided by the authentication operation. |
3 |
8 |
Construct a probe in a mapping table called AUTH_REWRITE of the form: mail-from|sender|from|auth-sender where mail-from is the envelope From: address, sender is the address from the Sender: or Resent-sender: header field, from is the address from the From: or Resent-From: header field, and auth-sender is the address provided by the authentication operation. The result is run through the AUTH_REWRITE mapping. The mapping should return a list of items separated by vertical bars ( | ). The items are consumed, in order, by the setting of the following flags: $J $K Replace the envelope From: address for the message $Y $T Add an appropriate Sender: or Resent-sender: header field. $N Reject the message. Mapping result provides text of the error message. If no text is provided, invalid originator address used error message is displayed. $Z Add an appropriate From: or Resent-from: header field. (Note that in general overriding a From: field is a very bad idea.) The Resent- variants are used if other Resent- fields are present in the header. |
4 |
16 |
Apply AUTH_REWRITE mapping even when authentication has not provided an authenticated address. If the bit is clear, the mapping is only applied if an authenticated address is available. |
5 |
32 |
Include the source channel at the beginning of the AUTH_REWRITE mapping probe. It is separated from the remaining information by a |. If the bit is clear, the channel is not included. |
The $Z flag should be highly restricted as there are few legitimate uses for modifying envelope and header addresses.
Keywords: msexchange, nomsexchange
The msexchange channel keyword may be used on TCP/IP channels to tell the MTA that this is a channel that communicates with Microsoft Exchange gateways and clients. When placed on an incoming TCP/IP channel which has SASL enabled (via a maysaslserver or mustsaslserver keyword), it causes the MTA’s SMTP server to advertise AUTH using an “incorrect” format (based upon the original ESMTP AUTH specification, which was actually incompatible with correct ESMTP usage, rather than the newer, corrected AUTH specification). Some Microsoft Exchange clients, for instance, does not recognize the correct AUTH format and only recognizes the incorrect AUTH format.
The msexchange channel keyword also causes advertisement (and recognition) of broken TLS commands.
nomsexchange is the default.
Keywords: maytls, maytlsclient, maytlsserver, musttls, musttlsclient, musttlsserver, notls, notlsclient, notlsserver, tlsswitchchannel
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.
The default is notls, and means that TLS will not be permitted or attempted. It subsumes the notlsclient keyword, which means that TLS use will not be attempted by the MTA SMTP client on outgoing connections (the STARTTLS command will not be issued during outgoing connections) and the notlsserver keyword, which means that TLS use will not be permitted by the MTA SMTP server on incoming connections (the STARTTLS extension will not be advertised by the SMTP server nor the command itself accepted).
Specifying maytls causes the MTA to offer TLS to incoming connections and to attempt TLS upon outgoing connections. It subsumes maytlsclient, which means that the MTA SMTP client will attempt TLS use when sending outgoing messages, if sending to an SMTP server that supports TLS, and maytlsserver, which means that the MTA SMTP server will advertise support for the STARTTLS extension and will allow TLS use when receiving messages.
Note that for TLS to work, the following conditions must be in place:
Protections/ownerships of the certificates have to be set so that the mailsrv account can access the files.
The directory where the certificates are stored need to have protections/ownerships set such that the mailsrv account can access the files within that directory.
Specifying musttls will cause the MTA to insist upon TLS in both outgoing and incoming connections; email will not be exchanged with remote systems that fail to successfully negotiate TLS use. It subsumes musttlsclient, which means that the MTA SMTP client will insist on TLS use when sending outgoing messages and will not send to SMTP servers that do not successfully negotiate TLS use (the MTA will issue the STARTTLS command and that command must succeed). It also subsumes musttlsserver, which means that the MTA SMTP server will advertise support for the STARTTLS extension and will insist upon TLS use when receiving incoming messages and will not accept messages from clients that do not successfully negotiate TLS use.
The tlsswitchchannel keyword is used to cause incoming connections to be switched to a specified channel upon a client's successful TLS negotiation. It takes a required value, specifying the channel to which to switch.
You can configure when the server attempts to deliver messages based on certain criteria. You can also specify parameters for job processing, such as processing limits for service jobs, or when to spawn a new SMTP channel thread. This section describes the following:
For conceptual information on message processing and delivery, refer to Table 12–24
Configuring Message Processing and Delivery summarizes the keywords described in this section.
Table 12–24 Message Processing and Delivery Keywords
Keyword |
Definition |
---|---|
Immediate Delivery |
Defines specification for immediate delivery of messages. |
Starts delivery immediately after submission for urgent, normal, and non-urgent messages. |
|
Channel Directionality |
Specifies type of by which program a channel is served |
bidirectional |
Channel is served by a master and slave programs. |
master |
Channel is served by a master program (master). |
slave |
Channel is served by a slave program (slave). |
Deferred Delivery |
Defines specification for delivery of deferred jobs. |
Specifies the frequency for attempted redelivery of deferred messages. Can be overridden by normalbackoff, nonurgentbackoff, urgentbackoff. |
|
Implements recognition and honoring of the Deferred-delivery: header line. |
|
Default. Specifies that Deferred-delivery: header line not be honored. |
|
The frequency for attempted redelivery of nonurgent messages. |
|
The frequency for attempted redelivery of normal messages. |
|
The frequency for attempted redelivery of urgent messages. |
|
Message Priority Based on Size |
Defines message priority based on message size. |
Forces messages above this size to lower than nonurgent priority (second class priority), meaning that the messages will always wait for the next periodic job for further processing. |
|
Forces messages above this size to nonurgent priority. |
|
Forces messages above this size to normal priority. |
|
Processing Pools for Channel Execution Jobs |
Specifies the pools for processing messages of different urgencies and deferral of jobs |
Specifies the pool in which channels run. |
|
Specifies a time delay before channels run. |
|
Service Job Limits |
Specifies the number of service jobs and the maximum number of message files to handle per job |
Specifies the maximum number of jobs that can be running concurrently for the channel. |
|
Specifies the number of queue entries to be processed by a single job. |
|
SMTP Channel Threads | |
Number of messages triggering new thread with multithreaded SMTP client. |
|
Multiple Address Expansion |
Defines processing for messages with many recipients |
Processes an incoming message “off-line” when the number of addressees exceeds this limit. |
|
Specifies channel in which to perform deferred expansion due to application of expandlimit. |
|
Holds an incoming message when the number of addresses exceeds this limit. |
|
Transaction Limits |
Specifies connection transaction limits |
transactionlimit |
Limits the number of messages allowed per connection. |
Undeliverable Message Notifications |
Specifies when undeliverable message notifications are sent. |
Specifies the amount of time that may elapse before notices are sent and messages returned. |
|
Specifies the amount of time that may elapse before notices are sent and messages returned for messages of non-urgent priority. |
|
Specifies the amount of time that may elapse before notices are sent and messages returned for messages of normal priority. |
|
Specify the amount of time which may elapse before notices are sent and messages returned for messages of urgent priority. |
Keywords: master, slave, bidirectional
Three keywords are used to specify whether a channel is served by a master program (master), a slave program (slave), or both (bidirectional). The default, if none of these keywords are specified, is bidirectional. These keywords determine 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.
Keywords: deferred, nodeferred, immnonurgent
The deferred channel keyword implements recognition and honoring of 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.
The keyword nodeferred is the default. It is important to realize that while support for deferred message processing is mandated by RFC 1327, actual implementation of it effectively lets people use the mail system as an extension of their disk quota.
The keyword immnonurgent starts delivery immediately after submission for urgent, normal, and non-urgent messages.
Keywords: backoff, nonurgentbackoff, normalbackoff, urgentbackoff, notices
By default, the frequency of delivery retries for messages that have had delivery failures depends on the message’s priority. The default intervals between delivery attempts (in minutes) is shown below. The first number after the priority indicates the number of minutes after the initial delivery failure that the first delivery retry is attempted:
urgent: 30, 60, 60, 120, 120, 120, 240 normal: 60, 120, 120, 240, 240, 240, 480 nonurgent: 120, 240, 240, 480, 480, 480, 960
For urgent messages, a retry is attempted 30 minutes after the initial delivery failure, 60 minutes after the first delivery retry, 60 minutes after the second retry, 120 minutes after the third and so on. Retries after the last specified attempt repeat at the same interval. Thus, for urgent messages, retries occur every 240 minutes.
Delivery attempts continue for a period of time specified by the notices, nonurgentnotices, normalnotices, or urgentnotices keywords. If a successful delivery cannot be made, a delivery failure notification is generated and the message is returned to sender. (For details on the notices keyword, see To Set Notification Message Delivery Intervals
The backoff keywords allow you to specify customized sets of delivery retry intervals for messages of varying priorities. nonurgentbackoff specifies the intervals for nonurgent messages. normalbackoff specifies the intervals for normal messages. urgentbackoff specifies the intervals for urgent messages. If none of these keywords is specified, backoff specifies the intervals for all messages regardless of priority.
An example, is shown below:
urgentbackoff "pt30m" "pt1h" "pt2h" "pt3h" "pt4h" "pt5h" "pt8h" "pt16h"
Here, delivery retries of urgent messages is attempted 30 minutes after the initial delivery failure, one hour after the first delivery attempt (1 hour 30 minutes after initial failure), two hours after the second delivery attempt, three hours after the third, four hours after the fourth, five hours after the fifth, eight hours after the sixth, 16 hours after the seventh delivery attempt. Subsequent attempts are made every 16 hours until the 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. Note that the interval syntax is in ISO 8601P and is described in the Sun Java System Messaging Server Administration Reference.
In this next example,
normalbackoff "pt30m" "pt1h" "pt8h" "p1d" "p2d” "p1w"
a delivery retry of normal messages is attempted 30 minutes after the initial delivery failure, one hour after the first delivery attempt, eight hours after the second attempt, one day after the third, two days after the fourth, one week after the fifth and repeating each week until the 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.
In this final example,
backoff "pt30m" "pt120m" "pt16h" "pt36h" "p3d"
all failed message deliveries, regardless of message priority—unless overridden by nonurgentbackoff, normalbackoff, or urgentbackoff—will be retried 30 minutes after the initial delivery failure, two hours after the first retry attempt, 16 hours after the second attempt, 36 hours after the third, three days after the fourth and repeating every three days until the 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.
You can configure various channels to share resources by running within the same pool. You might want to configure other channels to run in pools dedicated to a particular channel. Within each pool, messages are automatically sorted into different processing queues according to message priority. Higher priority messages in the pool are processed before lower-priority messages. (See Message Priority Based on Size
The pools where the jobs are created can be selected on a channel by channel basis by using the pool keyword. The pool keyword must be followed by the name of the pool to which delivery jobs for the current channel should be pooled. The name of the pool should not contain more than twelve characters.
For further information on Job Controller concepts and configuration, refer to Job Controller File, Job Controller File, and Service Job Limits.
Keywords: maxjobs, filesperjob
Each time a message is enqueued to a channel, the Job Controller ensures that there is a job running to deliver the message. This might involve starting a new job process, adding a thread, or simply noting that a job is already running. A single service job may not be sufficient to ensure prompt delivery of all messages, however. (For further information on Job Controller concepts and configuration, refer to Job Controller File, Processing Pools for Channel Execution Jobs and The Job Controller.
For any given installation, there is a reasonable maximum number of processes and threads to be started for delivering messages. This maximum number depends on factors such as the number of processors, the speed of the disks, and the characteristics of the connections. In the MTA configuration, it is possible to control the following:
The maximum number of processes to start running for a given channel (the maxjobs channel keyword)
The maximum number of processes to start for a set of channels (the JOB_LIMIT parameter in the relevant pool section of the Job Controller configuration file)
The number of queued messages received before a new thread or process is started (the threaddepth channel keyword)
For some channels, the maximum number of threads that will run within a given delivery program (max_client_threads parameter in the channel option file)
The maximum number of processes to start running for a given channel is the minimum of the maxjobs set on the channel and the JOB_LIMIT set for the pool that the channel runs in.
Assume a message needs processing. In general, the Job Controller starts new processes as follows:
If no process is running for a channel and the pool job limit has not been reached, then the Job Controller starts a new process.
If a channel program is single-threaded or the thread limit has been reached and the backlog increases past a multiple of threads (specified with threaddepth) and neither the channel nor pool job limit has been reached, the Job Controller starts a new process
If a channel program is multithreaded and the thread limit has not been reached and the backlog of messages increase past a multiple of threaddepth, a new thread is started.
For SMTP channels in particular, new threads or processes are started as messages are enqueued for different hosts. Thus, for SMTP channels, the Job Controller starts new processes as follows. Assume a message needs processing:
If no process is running for an SMTP channel and the pool limit has not been reached, the Job Controller starts a new process.
If the thread limit (MAX_CLIENT_THREADS) has been reached, a message is enqueued for a host not yet being serviced, and neither the channel (maxjobs) nor pool job limit (JOB_LIMIT) has been reached then a new process is started.
If the thread limit has not been reached and a message is enqueued for a host not yet being serviced, then a new thread is started.
If the thread limit has not been reached and a message is enqueued that takes the backlog of messages for that host increase past a multiple of threaddepth, a new thread is started.
See also SMTP Channel Threads.
The filesperjob keyword can be used to cause the MTA to create additional service jobs. This keyword takes a single positive integer parameter which specifies how many queue entries (that is, files) must be sent to the associated channel before more than one service job 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 is equivalent to specifying a value of zero. The effect of this keyword is maximized; the larger number computed will be the number of service jobs that are actually created.
The filesperjob keyword divides the number of actual queue entries or files by the given value. Note that 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 maxjobs keyword places an upper bound on the total number of service jobs that can be running concurrently. This keyword must be followed by an integer value; if the computed number of service jobs is greater than this value only maxjobs jobs will actually be created. The default for this value if maxjobs is not specified is 100. Normally maxjobs is set to a value that is less than or equal to the total number of jobs that can run simultaneously in whatever service pool or pools the channel uses.
transactionlimit limits the number of messages allowed per connection. This can be used to thwart attackers in the following way:
An attacker can connect via SMTP and send many RCPT TO commands in an attempt to guess legitimate email addresses. Such an attack can be thwarted by limiting the number of invalid RCPT TOs allowed in a transaction. The attacker may respond by using multiple transactions, but with transactionlimit you can limit the number of transaction allowed in an SMTP session. The attacker can use multiple sessions, but now his cost is getting prohibitive. Connection throttling can be used to limit the number of sessions in various ways making the cost really prohibitive in most cases.
This is not without cost our side, however. Some SMTP clients react badly to recipient limits, transaction limits, or both. Exceptions need to be made for these clients. But TCP channel options apply to the SMTP server unconditionally. The solution is to use channel keywords and switchchannel to route problematic agents to channels with larger limits.
Keywords: urgentblocklimit, normalblocklimit, nonurgentblocklimit
The urgentblocklimit, normalblocklimit, and nonurgentblocklimit keywords may be used to instruct the MTA to downgrade the priority of messages based on size. These keywords affect the priority that the Job Controller applies when processing the message.
The multithreaded SMTP client sorts outgoing messages to different destinations to different threads. The threaddepth keyword may be used to instruct the 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 (hence normally all handled in one thread). The default for this keyword is 10.
Each time the backlog for a channel increases past a multiple of threaddepth, the Job Controller tries to increase the amount of processing dedicated to processing messages queued for that channel. For multithreaded channels, the Job Controller advises any job processing messages for that channel to start a new thread, or if all jobs have the maximum threads allowed for the channel (MAX_CLIENT_THREADS in the option for the tcp_* channels) it will start a new process. For single-threaded channels it will start new process. Note that the Job Controller will not start a new job if the job limit for the channel (maxjobs) or the pool (JOB_LIMIT) has been reached.
Essentially, threaddepth controls how aggressive jobs are scheduled. Let's consider two different situations:
(1) a normal (outbound) SMTP channel
(2) a forward-to-a-smart-host SMTP channel
The job controller sorts messages destined for a particular channel by the destination host, and it schedules the jobs to process messages based on the backlog on these destinations hosts.
In the first instance, there will be a large number of destination hosts and the backlog for most of them will be small. There will be lots of threads running and everything should work well, except, perhaps, for destination hosts like aol, yahoo, hotmail, and so on, where there can be a large amount of traffic. With a thread depth of 128, you'd only get a second thread delivering to yahoo once the backlog reached 128. This is not desirable.
In the second instance, there is only the one destination host and having many threads delivering to that host are desirable. If anything, the default value of 10 could be too small.
Use of threaddepth may be of particular interest for achieving multithreading on a daemon router TCP/IP channel—a TCP/IP channel that connects to a single specific SMTP server—when the SMTP server to which the channel connects can handle multiple simultaneous connections.
Keywords: expandlimit, expandchannel, holdlimit
Most channels support the specification of multiple recipient addresses in the transfer of each inbound message. The specification of many recipient addresses in a single message may result in delays in message transfer processing (online delays). If the delays are long enough, network time-outs can occur, which in turn can lead to repeated message submission attempts and other problems.
The MTA provides a special facility to force deferred (offline) processing if more than a given number of addresses are specified for a single message. Deferral of message processing can decrease on-line delays enormously. Note, however, that the processing overhead is deferred, not avoided completely.
This special facility is activated by using a combination of, for instance, the generic reprocessing channel and the expandlimit keyword. 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 will force deferred processing on all incoming addresses from the channel.
The expandlimit keyword must not be specified on the local channel or the reprocessing channel itself; the results of such a specification are unpredictable.
The channel actually used to perform the deferred processing may be specified using the expandchannel keyword; the reprocessing channel is used by default, if expandchannel is not specified, but use of some other reprocessing or processing channel may be useful for special purposes. If a channel for deferred processing is specified via expandchannel, that channel should be a reprocessing or processing channel; specification of other sorts of channels may lead to unpredictable results.
The reprocessing channel, or whatever channel is used to perform the deferred processing, must be added to the MTA configuration file in order for the expandlimit keyword to have any effect. If your configuration was built by the MTA configuration utility, then you should already have a reprocessing channel.
Extraordinarily large lists of recipient addresses are often a characteristic of unsolicited bulk email. The holdlimit keyword tells the MTA that messages coming in the channel that result in more than the specified number of recipients should be marked as .HELD messages and enqueued to the reprocess channel (or to whatever channel is specified via the expandchannel keyword). The files will sit unprocessed in the reprocess queue awaiting manual intervention by the MTA postmaster.
The service keyword unconditionally enables service conversions regardless of CHARSET-CONVERSION entry. If the noservice keyword is set, service conversions for messages coming into this channel must be enabled via CHARSET-CONVERSION.
This section describes keywords that deal with address handling. It consists of the following sections:
Specifying a Host Name to Use When Correcting Incomplete Addresses
Constructing Received Header Lines from Envelope To and From Addresses
Keywords: 822, 733, uucp, header_822, header_733, header_uucp
This group of keywords control what types of addresses the channel supports. A distinction is made between the addresses used in the transport layer (the message envelope) and those used in message headers.
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.
Percent sign envelope addresses. This channel supports full RFC 822 format envelope addressing with the exception of source routes; source routes should be rewritten using percent sign conventions instead. The keyword percents is also available as a synonym for 733.
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.
Bang-style envelope addresses. This channel uses addresses that conform to RFC 976 bang-style address conventions in the envelope (for example, this is a UUCP channel). The keyword bangstyle is also available as a synonym for uucp.
Source route header addresses. This channel supports full RFC 822 format header addressing conventions including source routes. This is the default if no other header address type keyword is specified.
Percent sign header addresses. This channel supports RFC 822 format header addressing with the exception of source routes; source routes should be rewritten using percent sign conventions instead.
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.
UUCP or bang-style header addresses. The use of this keyword is not recommended. Such usage violates RFC 976.
Keywords: bangoverpercent, nobangoverpercent, percentonly
Addresses are always interpreted in accordance with RFC 822 and RFC 976. However, there are ambiguities in the treatment of certain composite addresses that are not addressed by these standards. In particular, an address of the form A!B%C can be interpreted as either:
A as the routing host and C as the final destination host
or
C as the routing host and A as the final destination host
While RFC 976 implies that mailers can interpret addresses using the latter set of conventions, it does not say that such an interpretation is required. Some situations may be better served by the former interpretation.
The bangoverpercent keyword forces the former A!(B%C) interpretation. The nobangoverpercent keyword forces the latter (A!B)%C interpretation. nobangoverpercent is the default.
This keyword does not affect the treatment of addresses of the form A!B@C. These addresses are always treated as (A!B)@C. Such treatment is mandated by both RFC 822 and RFC 976.
The percentonly keyword ignores bang paths. When this keyword is set, percents are interpreted for routing.
Keywords: exproute, noexproute, improute, noimproute
The addressing model that the MTA deals with assumes that all systems are aware of the addresses of all other systems and how to get to them. Unfortunately, this ideal is not possible in all cases, such as when a channel connects to one or more systems that are not known to the rest of the world (for example, internal machines on a private TCP/IP network). Addresses for systems on this channel may not be legal on remote systems outside of the site. If you want to be able to reply to such addresses, they must contain a source route that tells remote systems to route messages through the local machine. The local machine can then (automatically) route the messages to these machines.
The exproute keyword (short for “explicit routing“) tells the MTA that the associated channel requires explicit routing when its addresses are passed on to remote systems. If this keyword is specified on a channel, the MTA adds routing information containing the name of the local system (or the current alias for the local system) to all header addresses and all envelope From: addresses that match the channel. noexproute, the default, specifies that no routing information should be added.
The EXPROUTE_FORWARD option can be used to restrict the action of exproute to backward-pointing addresses. Another scenario occurs when the MTA connects to a system through a channel that cannot perform proper routing for itself. In this case, all addresses associated with other channels need to have routing indicated when they are used in mail sent to the channel that connects to the incapable system.
Implicit routing and the improute keyword is used to handle this situation. The MTA knows that all addresses matching other channels need routing when they are used in mail sent to a channel marked improute. The default, noimproute, specifies that no routing information should be added to addresses in messages going out on the specified channel. The IMPROUTE_FORWARD option can be used to restrict the action of improute to backward-pointing addresses.
The exproute and improute keywords should be used sparingly. They make addresses longer, more complex, and may defeat intelligent routing schemes used by other systems. Explicit and implicit routing should not be confused with specified routes. Specified routes are used to insert routing information from rewrite rules into addresses. This is activated by the special A@B@C rewrite rule template.
Specified routes, when activated, apply to all addresses, both in the header and the envelope. Specified routes are activated by particular rewrite rules and as such are usually independent of the channel currently in use. Explicit and implicit routing, on the other hand, are controlled on a per-channel basis and the route address inserted is always the local system.
The routelocal channel keyword causes the MTA, when rewriting an address to the channel, to attempt to “short circuit” any explicit routing in the address. Explicitly routed addresses (using !, %, or @ characters) are simplified.
Use of this keyword on “internal” channels, such as internal TCP/IP channels, can allow simpler configuration of SMTP relay blocking.
Note that this keyword should not be used on channels that may require explicit % or other routing.
Keywords: connectalias, connectcanonical
The MTA normally rewrites addresses as it enqueues messages to its channel queues. No additional rewriting is performed during message dequeue. This presents a potential problem when host names change while there are messages in the channel queues still addressed to the old name.
The connectalias keyword tells the MTA to deliver to whatever host is listed in the recipient address. This is the default. The keyword connectcanonical tells the MTA to connect to the host alias for the system that to which the MTA would be connected.
Keywords: remotehost, noremotehost, defaulthost, nodefaulthost
The MTA often receives addresses that do not contain domain names from misconfigured or incompliant mailers and SMTP clients. The MTA attempts to make such addresses legal before allowing them to pass further. The MTA does this by appending a domain name to the address (for example, appends @siroe.com to mrochek).
For envelope To: addresses missing a domain name, the MTA always assumes that the local host name should be appended. However for other addresses, such as From: addresses, in the case of the MTA SMTP server there are at least two reasonable choices for the domain name: the local MTA host name and the remote host name reported by the client SMTP. Or in some cases, there may be yet a third reasonable choice—a particular domain name to add to messages coming in that channel. Now, either of these two first choices are likely to be correct as both may occur operationally with some frequency. The use of the remote host’s domain name is appropriate when dealing with improperly configured SMTP clients. The use of the local host’s domain name may be appropriate when dealing with a lightweight remote mail client such as a POP or IMAP client that uses SMTP to post messages. Or if lightweight remote mail clients such as POP or IMAP, clients should have their own specific domain name which is not that of the local host. Then add that specific other domain name may be appropriate. The best that the MTA can do is to allow the choice to be made on a channel by channel basis.
The noremotehost channel keyword specifies that the local host’s name should be used. The keyword noremotehost is the default.
The defaulthost channel keyword is used to specify a particular host name to append to incoming bare user id’s. It must be followed by the domain name to use in completing addresses (in envelope From: and in headers) that come into that channel. (In the case of submit channels, the defaulthost keyword’s first argument also affects bare envelope To: addresses.) An optional second domain name (that has at least one period in it) may be specified to use in completing envelope To: addresses. nodefaulthost is the default.
The switchchannel keyword as described, in the preceding section, Alternate Channels for Incoming Mail (Switch Channels) associate incoming SMTP connections with a particular channel. This facility can be used to group remote mail clients on a channel where they can receive proper treatment. Alternatively, it is simpler to deploy standards-compliant remote mail clients (even if a multitude of noncompliant clients are in use) rather than attempting to fix the network-wide problem on your MTA hosts.
Keywords: missingrecipientpolicy
RFC 822 (Internet) messages are required to contain recipient header lines: To:, Cc:, or Bcc: header lines. A message without such header lines is illegal. Nevertheless, some broken user agents and mailers (for example, many older versions of sendmail) emit illegal messages.
The missingrecipientpolicy keyword takes an integer value specifying the approach to use for such messages; the default value, if the keyword is not explicitly present, is 1 (pass the illegal message through unchanged).
Table 12–25 missingrecipientpolicy Values
Value |
Action |
---|---|
0 |
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. |
Note that the MISSING_RECIPIENT_POLICY option can be used to set an MTA system default for this behavior. The initial Messaging Server configuration sets MISSING_RECIPIENT_POLICY to 1.
Keywords: dropblank, nodropblank
In RFC 822 (Internet) messages, any To:, Resent-To:, Cc:, or Resent-Cc: header is required to contain at least one address—such a header may not have a blank value. Nevertheless, some mailers may emit such illegal headers. The dropblank channel keyword, if specified on a source channel, causes the MTA to strip any such illegal blank headers from incoming messages.
The reverse keyword tells the MTA that addresses in messages queued to the channel should be checked against, and possibly modified, by the address reversal database or REVERSE mapping, if either exists. noreverse exempts addresses in messages queued to the channel from address reversal processing. The reverse keyword is the default. Refer to To Convert Addresses from an Internal Form to a Public Form
Keywords: restricted, unrestricted
Some mail systems have difficulty dealing with the full spectrum of addresses allowed by RFC 822. A particularly common example of this is sendmail-based mailers with incorrect configuration files. Quoted local-parts (or mailbox specifications) are a frequent source of trouble:
"smith, ned"@siroe.com
This is such a major source of difficulty that a methodology was laid out in RFC 1137 to work around the problem. The basic approach is to remove quoting from the address, then apply a translation that maps the characters requiring quoting into characters allowed in an atom (see RFC 822 for a definition of an atom as it is used here). For example, the preceding address would become:
smith#m#_ned@siroe.com
The restricted channel keyword tells the MTA that the channel connects to mail systems that require this encoding. The MTA then encodes quoted local-parts in both header and envelope addresses as messages are written to the channel. Incoming addresses on the channel are decoded automatically. The unrestricted keyword tells the MTA not to perform RFC 1137 encoding and decoding. The keyword unrestricted is the default.
The restricted keyword should be applied to the channel that connects to systems unable to accept quoted local-parts. It should not be applied to the channels that actually generate the quoted local-parts. (It is assumed that a channel capable of generating such an address is also capable of handling such an address.)
Keywords: addreturnpath, noaddreturnpath
Normally, adding the Return-path: header line is the responsibility of a channel performing a final delivery. But for some channels, like the ims-ms channel, it is more efficient for the MTA to add the Return-path: header rather than allowing the channel to perform add it. The addreturnpath keyword causes the MTA to add a Return-path: header when enqueuing to this channel.
Keywords: receivedfor, noreceivedfor, receivedfrom, noreceivedfrom
The receivedfor keyword instructs the MTA that if a message is addressed to just one envelope recipient, to include that envelope To: address in the Received: header line it constructs. The keyword receivedfor is the default. The noreceivedfor keyword instructs the MTA to construct Received: header lines without including any envelope addressee information.
The receivedfrom keyword instructs the MTA to include the original envelope From: address when constructing a Received: header line for an incoming message if the MTA has changed the envelope From: address due to, for example, certain sorts of mailing list expansions. receivedfrom is the default. The noreceivedfrom keyword instructs the MTA to construct Received: header lines without including the original envelope From: address.
Keywords: commentinc, commentmap commentomit, commentstrip, commenttotal, sourcecommentinc, sourcecommentmap, sourcecommentomit, sourcecommentstrip, sourcecommenttotal
The MTA interprets the contents of header lines only when necessary. However, all registered header lines containing addresses must be parsed to rewrite and eliminate short form addresses and otherwise convert them to legal addresses. During this process, comments (strings enclosed in parentheses) are extracted and may be modified or excluded when the header line is rebuilt.
This behavior is controlled by the use of the commentinc, commentmap, commentomit, commentstrip, and commenttotalkeywords. The commentinc keyword tells the MTA to retain comments in header lines. It is the default. The keyword commentomit tells the MTA to remove any comments from addressing headers, for example, To:, From:, or Cc: header lines.
The keyword commenttotal tells the MTA to remove any comments from all header lines, except Received: header lines; this keyword is not normally useful or recommended. commentstrip tells the MTA to strip any nonatomic characters from all comment fields. The commentmap keyword runs comment strings through the COMMENT_STRINGS mapping table.
On source channels, this behavior is controlled by the use of the sourcecommentinc, sourcecommentmap, sourcecommentomit, sourcecommentstrip, and sourcecommenttotal keywords. The sourcecommentinc keyword indicates to the MTA to retain comments in header lines. It is the default. The sourcecommentomit keyword indicates to the MTA to remove any comments from addressing headers, for example, To:, From:, and Cc: headers. The sourcecommenttotal keyword indicates to the MTA to remove any comments from all headers, except Received: headers; as such, this keyword is not normally useful or recommended. And finally, the sourcecommentstrip keyword indicates to the MTA to strip any nonatomic characters from all comment fields. The sourcecommentmap keyword runs comment strings through source channels.
These keywords can be applied to any channel.
The syntax for the COMMENT_STRINGS mapping table is as follows:
(comment_text) | address
If the entry template sets the $Y flag, the original comment is replaced with the specified text (which should include the enclosing parentheses).
Keywords: personalinc, personalmap, personalomit, personalstrip, sourcepersonalinc, sourcepersonalmap, sourcepersonalomit, sourcepersonalstrip
During the rewriting process, all header lines containing addresses must be parsed in order to rewrite and eliminate short form addresses and otherwise convert them to legal addresses. During this process personal names (strings preceding angle-bracket-delimited addresses) are extracted and can be optionally modified or excluded when the header line is rebuilt.
This behavior is controlled by the use of the personalinc, personalmap, personalomit, and personalstrip keywords. The keyword personalinc tells the MTA to retain personal names in the headers. It is the default. The keyword personalomit tells the MTA to remove all personal names. The keyword personalstrip tells the MTA to strip any nonatomic characters from all personal name fields. The personalmap keyword indicates to the MTA to run the personal names through the PERSONAL_NAMES mapping table.
On source channels, this behavior is controlled by the use of a sourcepersonalinc, sourcepersonalmap, sourcepersonalomit, or sourcepersonalstrip keyword. The sourcepersonalinc keyword indicates to the MTA to retain personal names in the headers. It is the default. The sourcepersonalomit keyword indicates to the MTA to remove all personal names. And finally, the sourcepersonalstrip indicates to the MTA to strip any nonatomic characters from all personal name fields. The sourcepersonalmap keyword indicates to the MTA to run the personal names through source channels.
These keywords can be applied to any channel.
The syntax of the PERSONAL_NAMES mapping table probes is:
personal_name | address
If the template sets the $Y flag, the original personal name is replaced with the specified text.
Normally only addresses rewritten to the local channel (that is, the l channel on UNIX) are looked up in the alias file and alias database. The aliaslocal keyword may be placed on a channel to cause addresses rewritten to that channel to be looked up in the alias file and alias database also. The exact form of the lookup probes that are made is then controlled by the ALIAS_DOMAINS option.
Keywords: subaddressexact, subaddressrelaxed, subaddresswild
As background regarding the concept of subaddresses, the native and ims-ms channels interpret a + character in the local portion of an address (the mailbox portion) specially: in an address of the form name+subaddress@domain the MTA considers the portion of the mailbox after the plus character a subaddress. The native channel treats a subaddress as additional cosmetic information and actually deliver to the account name, without regard to the subaddress; the ims-ms channel interprets the subaddress as the folder name to which to deliver.
Subaddresses also affect the lookup of aliases by the local channel (that is, the L channel on UNIX) and the lookup of aliases by any channel marked with the aliaslocal keyword, and the lookup of mailboxes by the directory channel. The exact handling of subaddresses for such matching is configurable: when comparing an address against an entry, the MTA always first checks the entire mailbox including the subaddress for an exact match; whether or not the MTA performs additional checks after that is configurable.
The subaddressexact keyword instructs the MTA to perform no special subaddress handling during entry matching; the entire mailbox, including the subaddress, must match an entry in order for the alias to be considered to match. No additional comparisons (in particular, no wildcard comparisons or comparisons with the subaddress removed) are performed. The subaddresswild keyword instructs the MTA that after looking for an exact match including the entire subaddress, the MTA should next look for an entry of the form name+*. The subaddressrelaxed keyword instructs the MTA that after looking for an exact match and then a match of the form name+*, that the MTA should make one additional check for a match on just the name portion. With subaddressrelaxed, an alias entry of the following form matches either name or name+subaddress, transforming a plain name to newname, and transforming name+subaddress to newname+subaddress. The subaddressrelaxed keyword is the default.
name: newname+*
Thus the subaddresswild keyword or the subaddressrelaxed keyword may be useful when aliases or a directory channel are in use yet users wish to receive mail addressed using arbitrary subaddresses. These keywords obviate the need for a separate entry for every single subaddress variant on an address.
Note that these keywords only make sense for the local channel (that is, the L channel on UNIX) and the directory channel, or any channel marked with the aliaslocal keyword.
Standard Messaging Server configurations relay upon the L channel indeed having subaddressrelaxed behavior (the default, when other keywords have not been explicitly used).
The rules keyword tells the MTA to enforce channel-specific rewrite rule checks for this channel. This is the default. The norules keyword tells the MTA not to check for this channel. These two keywords are usually used for debugging and are rarely used in actual applications.
The dequeue_removeroute keyword removes source routes from envelope To: addresses as messages are dequeued. This keyword is currently only implemented on tcp-* channels. It is useful for transferring messages to systems that do not handle source routes correctly.
Keywords: viaaliasoptional, viaaliasrequired
viaaliasrequired specifies that any final recipient address that matches the channel must be produced by an alias. A final recipient address refers to the match after alias expansion (if relevant) has been performed. The address cannot be handed directly to the MTA as a recipient address; that is, it is not sufficient for an address to merely rewrite to the channel. After rewriting to the channel, an address must also expand through an alias to be considered to have truly matched the channel.
The viaaliasrequired keyword may be used, for example, on the local channel to prevent delivery to arbitrary accounts (such as arbitrary native Berkeley mailboxes on a UNIX system).
The default is viaaliasoptional, which means that the final recipient addresses that match the channel are not required to be produced by an alias.
This section describes keywords that deal with header and envelope information. It consists of the following sections:
The contents of header lines are interpreted only when necessary. However, MIME messages can contain multiple sets of message headers as a result of the ability to imbed messages within messages (message/RFC822). The MTA normally only interprets and rewrites the outermost set of message headers. The MTA can optionally be told to apply header rewriting to inner headers within the message as well.
This behavior is controlled by the use of the noinner and inner keywords. The keyword noinner tells the MTA not to rewrite inner message header lines. It is the default. The keyword inner tells the MTA to parse messages and rewrite inner headers. These keywords can be applied to any channel.
Keywords: headertrim, noheadertrim, headerread, noheaderread, innertrim noinnertrim
The MTA provides per-channel facilities for trimming or removing selected message header lines from messages. This is done through a combination of a channel keyword and an associated header option file or two. Header option file format is described in Header Option Files in Sun Java System Messaging Server 6 2005Q4 Administration Reference.
The headertrim keyword instructs the MTA to consult a header option file associated with the channel and to trim the headers on messages queued to that destination channel accordingly, after the original message headers are processed. The noheadertrim keyword bypasses header trimming. The keyword noheadertrim is the default.
The innertrim keyword instructs the MTA to perform header trimming on inner message parts, that is, embedded MESSAGE/RFC822 parts, as well. The noinnertrim keyword, which is the default, tells the MTA not to perform any header trimming on inner message parts.
The headerread keyword instructs the MTA to consult a header option file associated with the channel and to trim the headers on messages enqueued by that source channel accordingly, before the original message headers are processed. Note that headertrim header trimming, on the other hand, is applied after the messages have been processed and is the destination channel, rather than the source channel. The noheaderread keyword bypasses message enqueue header trimming. noheaderread is the default.
Unlike the headeromit and headerbottom keywords, the headertrim and headerread keywords may be applied to any channel whatsoever. Note, however, that stripping away vital header information from messages may cause improper operation of the MTA. Be extremely careful when selecting headers to remove or limit. This facility exists because there are occasional situations where selected header lines must be removed or otherwise limited.
Stripping away header information from messages may cause improper operation of the MTA. Be careful when selecting headers to remove or limit. These keywords are provided for the rare situations where selected header lines must be removed or limited. Before trimming or removing any header line, you must understand the usage of that header line and have considered the possible implications of its removal.
Header options files for the headertrim and innertrim keywords have names of the form channel_headers.opt with channel, the name of the channel with which the header option file is associated. Similarly, header options files for the headerread keyword have names of the form channel_read_headers.opt. These files are stored in the MTA configuration directory, instance_root/imta/config/.
Keywords: x_env_to, nox_env_to
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 while the nox_env_to removes such headers from enqueued messages. The default is nox_env_to.
The x_env_to keyword also requires the single keyword in order to take effect.
The original RFC 822 specification called for two-digit years in the date fields in message headers. This was later changed to four digits by RFC 1123. However, some older mail systems cannot accommodate four-digit dates. In addition, some newer mail systems can no longer tolerate two-digit dates.
Systems that cannot handle both formats are in violation of the standards.
The datefour and datetwo keywords control the MTA’s processing of the year field in message header dates. The keyword datefour, the default, instructs the MTA to expand all year fields to four digits. Two- digit dates with a value less than 50 have 2000 added, while values greater than 50 have 1900 added.
The keyword datetwo instructs the MTA to remove 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.
Keywords: dayofweek, nodayofweek
The RFC 822 specification allows for a leading day of the week specification in the date fields in message headers. However, some systems cannot accommodate day of the week information. This makes some systems reluctant to include this information, even though it is quite useful information to have in the headers.
The dayofweek and nodayofweek keywords control the MTA’s processing of day of the week information. The keyword dayofweek, the default, instructs the MTA to retain any day of the week information and to add this information to date and time headers if it is missing.
The keyword nodayofweek instructs the MTA to remove any leading day of the week information from date and time headers. 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.
Keywords: maxheaderaddrs, maxheaderchars
Some message transfers, notably some sendmail implementations, cannot process long header lines properly. This often leads not just to damaged headers but to erroneous message rejection. Although this is a gross violation of standards, it is nevertheless a common problem.
The MTA provides per-channel facilities to split (break) long header lines into multiple, independent header lines. The maxheaderaddrs keyword controls how many addresses can appear on a single line. The maxheaderchars keyword controls how many characters can appear on a single line. Both keywords require 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.
Keywords: headerlabelalign, headerlinelength
The headerlabelalign keyword controls the alignment point for message headers enqueued on this channel; it takes an integer-valued argument. The alignment point is the margin where the contents of headers are aligned. For example, sample header lines with an alignment point of 10 might look like this:
To: joe@siroe.com From: mary@siroe.com Subject: Alignment test |
The default headerlabelalign is 0, which causes headers not to be aligned. The headerlinelength keyword controls the length of message header lines enqueued on this channel. Lines longer than this are folded in accordance with RFC 822 folding rules.
These keywords only control the format of the headers of the message in the message queue; the actual display of headers is normally controlled by the user agent. In addition, headers are routinely reformatted as they are transferred across the Internet, so these keywords may have no visible effect even when used in conjunction with simple user agents that do not reformat message headers.
Processing of long header lines containing lots of addresses can consume significant system resources. The maxprocchars keyword is used to specify the maximum length header that the MTA can process and rewrite. Messages with headers longer than this are still accepted and delivered; the only difference is that the long header lines are not rewritten in any way. A single integer argument is required. The default is processing headers of any length.
Keywords: sensitivitynormal, sensitivitypersonal, sensitivityprivate sensitivitycompanyconfidential
The sensitivity checking keywords set an upper limit on the sensitivity of messages that can be accepted by a channel. The default is sensitivitycompanyconfidential; messages of any sensitivity are allowed through. 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 rejected when enqueued to the channel with an error message:
message too sensitive for one or more paths used
Note that the MTA does this sort of sensitivity checking at a per-message, not per-recipient, level: if a destination 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.
Encoded words in headers can have a specific language. The language keyword specifies the default language.
This section describes keywords that deal with attachments and MIME processing. It consists of the following sections:
Keywords: ignoreencoding, interpretencoding
The MTA can convert various nonstandard message formats to MIME using the Yes CHARSET-CONVERSION. In particular, the RFC 1154 format uses a nonstandard Encoding: header line. However, some gateways emit incorrect information on this header line, with the result that sometimes it is desirable to ignore this header line. The ignoreencoding keyword instructs the MTA to ignore any Encoding: header line.
Unless the MTA has a CHARSET-CONVERSION enabled, such headers are ignored in any case. The interpretencoding keyword instructs the MTA to pay attention to any Encoding: header line, if otherwise configured to do so, and is the default.
Keywords: defragment, nodefragment
The MIME standard provides the message/partial content type for breaking up messages into smaller parts. This is useful when messages have to traverse networks with size limits, or traverse unreliable networks where message fragmentation can provide a form of “checkpointing,” allowing for less subsequent duplication of effort when network failures occur during message transfer. Information is included in each part so that the message can be automatically reassembled after it arrives at its destination.
The defragment channel keyword and the defragmentation channel provide the means to reassemble messages in the MTA. 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. The nodefragment disables this special processing. The keyword nodefragment is the default.
Messages are retained in the defragment channel queue only for a limited time. When one half of the time before the first nondelivery notice is sent has elapsed, the various parts of a message will be sent on without being reassembled. This choice of time value eliminates the possibility of a nondelivery notification being sent about a message in the defragment channel queue.
The notices channel keyword controls the amount of time that can elapse before nondelivery notifications are sent, and hence also controls the amount of time messages are retained before being sent on in pieces. Set the notices keyword value to twice the amount of time you wish to retain messages for possible defragmentation. For example, a notices value of 4 would cause retention of message fragments for two days:
defragment notices 4 DEFRAGMENT-DAEMON |
Some email systems or network transfers cannot handle messages that exceed certain size limits. The MTA provides facilities to impose such limits on a channel-by-channel basis. Messages larger than the set limits are automatically split (fragmented) into multiple, smaller messages. The content type used for such fragments is message/partial, and a unique ID parameter is added so that parts of the same message can be associated with one another and, possibly, be automatically reassembled by the receiving mailer.
The maxblocks and maxlines keywords are used to impose size limits beyond which automatic fragmentation are activated. Both of these keywords must be followed by a single integer value. The keyword maxblocks specifies the maximum number of blocks allowed in a message. An MTA block is normally 1024 bytes; this can be changed with the BLOCK_SIZE option in the MTA option file. The keyword maxlines specifies the maximum number of lines allowed in a message. These two limits can be imposed simultaneously if necessary.
Message headers are, to a certain extent, included in the size of a message. Because message headers cannot be split into multiple messages, and yet they themselves can exceed the specified size limits, a rather complex mechanism is used to account for message header sizes. This logic is controlled by the MAX_HEADER_BLOCK_USE and MAX_HEADER_LINE_USE options in the MTA option file.
MAX_HEADER_BLOCK_USE is used to specify a real number between 0 and 1. The default value is 0.5. A message's header is allowed to occupy this much of the total number of blocks a message can consume (specified by the maxblocks keyword). If the message header is larger, the MTA takes the product of MAX_HEADER_BLOCK_USE and maxblocks as the size of the header (the header size is taken to be the smaller of the actual header size and maxblocks) * MAX_HEADER_BLOCK_USE.
For example, if maxblocks is 10 and MAX_HEADER_BLOCK_USE is the default, 0.5, any message header larger than 5 blocks is treated as a 5-block header, and if the message is 5 or fewer blocks in size it is not fragmented. A value of 0 causes headers to be effectively ignored insofar as message-size limits are concerned.
A value of 1 allows headers to use up all of the size that's available. Each fragment always contains at least one message line, regardless of whether or not the limits are exceeded by this. MAX_HEADER_LINE_USE operates in a similar fashion in conjunction with the maxlines keyword.
The SMTP specification allows for lines of text containing up to 1000 bytes. However, some transfers may impose more severe restrictions on line length. 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 various encodings available in the MTA always result in a reduction of line length to fewer than 80 characters. The original message may be recovered after such encoding is done by applying an appropriating decoding filter.
Encoding can only reduce line lengths to fewer than 80 characters. Specification of line length values less than 80 may not actually produce lines with lengths that comply with the stated restriction.
The linelength keyword causes encoding of data to perform “soft” line wrapping for transport purposes. The encoding is normally decoded at the receiving side so that the original “long” lines are recovered. For “hard” line wrapping, see the “Record, text” in Table 13–7.
This section describes keywords that set size limits on messages, user quotas, and privileges. It consists of the following sections:
Keywords: disconnectbadauthlimit
This keyword can be used to place a limit on the number of unsuccessful authentication attempts that will be allowed in a session before the session is disconnected. The default value for this option is 3.
Keywords: blocklimit, noblocklimit, linelimit, nolinelimit, sourceblocklimit
Although fragmentation can automatically break messages into smaller pieces, it is appropriate in some cases to reject messages larger than some administratively defined limit, (for example, to avoid service denial attacks).
The blocklimit, linelimit, and sourceblocklimit keywords are used to impose absolute size limits. Each of these keywords must be followed by a single integer value.
The keyword blocklimit specifies the maximum number of blocks allowed in a 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.
The keyword sourceblocklimit specifies the maximum number of blocks allowed in an incoming message. The MTA rejects attempts to submit a message containing more blocks than this to the channel. In other words, blocklimit applies to destination channels; sourceblocklimit applies to source channels. An MTA block is normally 1024 bytes; this can be changed with the BLOCK_SIZE option in the MTA option file.
Source block limits can also be specified on a per sender basis by specifying a user LDAP attribute with the MTA option LDAP_SOURCEBLOCKLIMIT, and adding this attribute to the senders LDAP entry. Source block limits are also supported based on the sender’s domain. Specify a domain LDAP attribute with the MTA option LDAP_DOMAIN_ATTR_SOURCEBLOCKLIMIT, and adding this attribute to the sender’s domain LDAP entry. There are no defaults for either of these values.
The keyword linelimit specifies the maximum number of lines allowed in a 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.
The MTA options LINE_LIMIT and BLOCK_LIMIT can be used to impose similar limits on all channels. These limits have the advantage that they apply across all channels. Therefore, the MTA servers can make them known to mail clients prior to obtaining message recipient information. This simplifies the process of message rejection in some protocols.
The nolinelimit and noblocklimit channel keywords are the default and mean that no limits are imposed, other than any global limits imposed via the LINE_LIMIT or BLOCK_LIMIT MTA options.
Keywords: alternatechannel, alternateblocklimit, alternatelinelimit, alternaterecipientlimit
The MTA provides the ability to retarget messages that exceed a specified limit on the number of recipients, message size, or message lines to an alternate destination channel. This is implemented as a set of the following channel keywords alternatechannel, alternateblocklimit, alternatelinelimit, and alternaterecipientlimit that can be placed on any destination channel. The alternatechannel keyword takes a single argument specifying the name of the alternate channel to use. The other keywords each accept an integer argument specifying a corresponding threshold. A message that exceeds any of these thresholds will be enqueued to the alternate channel instead of the original destination channel.
In the following channel block example, large messages over 5,000 blocks, that would have gone out the tcp_local channel to the Internet, instead go out the tcp_big channel:
tcp_local smtp ...other keywords... alternatechannel tcp_big alternateblocklimit 5 tcp-daemon tcp_big smtp ...rest of keywords... tcp-big-daemon |
Here are some examples of how the alternate* channel keywords can be used:
If you want to deliver large messages at a delayed or an off-hours time, you can control when the alternatechannel (for example, tcp_big) runs.
One method is to use the imsimta qm utility’s STOP channel_name and START channel_name commands, executing these commands periodically via your own custom periodic job that is run by the Job Controller or via a cron job.
When you want the Job Controller to process large messages or messages with many recipients in their own pool, you might also use the alternatechannel.
You can separate small messages or messages with few recipients from the large messages or messages with many recipients, since the latter might take longer for remote SMTP servers to process and accept; you might not want the larger messages to delay delivery of the smaller messages.
Note that the Job Controller’s regular scheduling of messages and assigning of messages to threads and processes are acceptable in most configurations.
When you want to set special TCP/IP channel time-out values for large messages or for messages with many recipients, you can use the alternatechannel.
In particular, setting special TCP/IP channel time-out values can be helpful if you want to send messages to remote hosts that take exceptionally long to receive large messages or messages with many recipients.
Note that the default automatic time-out adjustment should be sufficient for most configurations. At most, you might want to adjust the values from the defaults and not use a special channel. In particular, see the channel options STATUS_DATA_RECV_PER_ADDR_TIME and STATUS_DATA_RECV_PER_BLOCK_TIME in the Sun Java System Messaging Server 6 2005Q4 Administration Reference.
When you want special MIME message fragmentation for especially large messages, you can use the alternatechannel and the alternateblocklimit channel keywords along with the maxblocks channel keyword.
Typically, you would put the desired maxblocks size on your regular outbound TCP/IP channels, when you want to fragment messages over a specified size. The maxblocks channel keyword is normally both the threshold at which to perform fragmentation and the size to make the fragments.
But, if you want to have a larger threshold trigger and make smaller actual fragments, you can use the alternatechannel and alternateblocklimit on the outbound TCP/IP channel. You can then use the maxblock size on your alternate channel to fragment messages over a particular size.
You might use the alternatechannel in conjunction with special filtering. For instance, a message with many recipients might need more careful scrutiny of its content in case it is spam. You might want to do different filtering based on the outgoing channel (See the destinationfilter channel keyword in Specifying Mailbox Filter File Location.
If you are performing relatively resource-intensive scanning (such as virus filtering) via the conversion channel, very large messages might have a resource issue. You might want to use an alternate conversion channel. Or, you might want to do special conversion procedures within the regular conversion channel, based on the outgoing channel.
You can use the alternatechannel when you want large outgoing messages to go out their own channel, so that they stand out when you analyze the mail.log* file or in counters displays.
Furthermore, if you are trying to do careful analysis of delivery statistics, it is useful to process large messages in their own channel. This is because large messages or messages with many recipients that are sent to remote SMTP hosts are likely to take longer to finish processing, thus creating different delivery statistics for larger messages than for typical messages.
Keywords: holdexquota, noexquota
The noexquota and holdexquota keywords control the handling of messages addressed to Berkeley mailbox users (UNIX), that is, users delivered to uid the native channel, who have exceeded their disk quotas.
noexquota tells the MTA to return messages addressed to over quota users to the message’s sender. holdexquota tells the MTA to hold messages to over quota users; such 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.
Keywords: rejectsmtplonglines, wrapsmtplonglines, truncatesmtplonglines
rejectsmtplonglines adds the option of rejecting messages that contain lines longer than the 1000 characters (including CRLF) that SMTP allows. The other options in this area are wrapsmtplonglines, which wraps overly long lines, and the default truncatesmtplonglines, which truncates overly long lines. Both of these keywords 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.
Keywords: parameterlengthlimit and nameparameterlengthlimit
parameterlengthlimit controls the points at which general content-type and content-disposition parameters are truncated. It defaults to 1024. nameparameterlengthlimit controls the points at which the name content-type and the filename content-disposition parameters are truncated. It defaults to 128. Note that only the outermost message header is processed unless MIME processing is being performed on the message. MIME processing can be enabled in a variety of ways including, but not limited to, the inner keyword or the use of charset conversions.
Keywords: recipientlimit and recipientcutoff
recipientlimit specifies the total number of recipient addresses that will be accepted for the message. recipientcutoff compares the total number of recipients that were presented to the MTA to the specified value. No message will be accepted for delivery if the limit if the value is exceeded. Both keywords accept a single integer argument. The default for both infinite unless the corresponding channel keyword is specified.
Recipient limits can also be set on a sender or sender’s domain. This is done by specifying a user or domain LDAP attribute with the appropriate MTA option: LDAP_RECIPIENTLIMIT, LDAP_RECIPIENTCUTOFF, LDAP_DOMAIN_ATTR_RECIPIENTLIMIT, LDAP_DOMAIN_ATTR_RECIPIENTCUTOFF, and adding the attribute to the sender’s user entry or domain entry.
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 is no limit.
This section describes keywords that allow you to control disk resources by specifying file creation in the MTA queue. It consists of the following sections:
Keywords: multiple, addrsperfile, single, single_sys
The MTA allows multiple destination addresses to appear in each queued message. Some channel programs may only be able to process messages with one recipient, or with a limited number of recipients, or with a single destination system per message copy. For example, the SMTP channels master program establishes a connection only to a single remote host in a given transaction, so only addresses to that host can be processed (this, despite the fact, that a single channel is typically used for all SMTP traffic).
Another example is that some SMTP servers may impose a limit on the number of recipients they can handle at one time, and they may not be able to handle this type of error.
The keywords multiple, addrsperfile, single, and single_sys can be used to control how multiple addresses are handled. The keyword single means that a separate copy of the message should be created for each destination address on the channel. Use of single on tcp_* channels is not recommended because it changes the way the job controller manages traffic and is not appropriate for normal SMTP scenarios. The keyword single_sys creates a single copy of the message for each destination system used. The keyword multiple, the default, creates a single copy of the message for the entire channel.
At least one copy of each message is created for each channel the message is queued to, regardless of the keywords used.
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. This keyword requires a single-integer argument specifying 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. (The default 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.)
By default, all messages queued to a channel are stored as files in the directory/imta/queue/channel-name, where channel-name is the name of the channel. However, a channel that handles a large number of messages and tends to build up a large store of message files waiting for processing, for example, a TCP/IP channel, may get better performance out of the file system if those message files are spread across a number of subdirectories. The subdirs channel keyword provides this capability: it should be followed by an integer that specifies the number of subdirectories across which to spread messages for the channel, for example:
tcp_local single_sys smtp subdirs 10
Keywords: disconnectbadcommandlimit, disconnectrecipientlimit, disconnectrejectlimit, disconnecttransactionlimit
Four new channel keywords provide the ability to cause the SMTP server to disconnect from the client after some number of errors have been detected:
disconnectrecipientlimit - Limits the number of session recipients.
disconnectrejectlimit - Limits the number of rejected recipients.
disconnecttransactionlimit - Limits the number of transactions.
disconnectbadcommandlimit - Limits the number of bad commands.
These are all session limits. With the exception of disconnectbadcommandlimit, all of these limits are checked when a MAIL FROM or RSET command is issued. If any of them have been exceeded, the server will issue a 4xy error and disconnect. The bad command limit differs only in being checked when a bad command is issued.
This section describe logging and debugging keywords.
Keywords: logging, nologging, logheader
The MTA provides facilities for logging each message as it is enqueued and dequeued. The logging and nologging keywords control logging for messages on a per-channel basis. By default, the initial configuration turns on logging for all channels. You can disable logging for a particular channel by substituting the nologging keyword in the channel definition.
logheader overrides the LOG_HEADER MTA option on a per channel basis. A value of 0 (the default) disables message header logging. See the Option File in Sun Java System Messaging Server 6 2005Q4 Administration Reference for more information.
For more information about logging, see Chapter 21, Managing Logging.
Keywords: master_debug, slave_debug, nomaster_debug, noslave_debug
Some channel programs include optional code to assist in debugging by producing additional diagnostic output. Two channel keywords are provided to enable generation of this debugging output on a per-channel basis. The keywords are master_debug, which enables debugging output in master programs, and slave_debug, which enables debugging output in slave programs. Both types of debugging output are disabled by default, corresponding to nomaster_debug and noslave_debug.
When activated, debugging output ends up in the log file associated with the channel program. The location of the log file may vary from program to program. Log files are usually kept in the log directory. Master programs usually have log file names of the form x_master.log, where x is the name of the channel. Slave programs usually have log file names of the form x_slave.log.
On UNIX, when master_debug and slave_debug are enabled for the l channel, users then 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.
Keywords: loopcheck, noloopcheck
The loopcheck keyword places a string into the SMTP EHLO response banner in order for the MTA 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 bounce the message if the client is in fact communicating with the SMTP server.
This section describes miscellaneous keywords. It consists of the following sections:
Keywords: notificationchannel, dispositionchannel
These keywords override the process channel as the place to initially queue delivery status notifications (DSNs) and message disposition notifications (MDNs), respectively. If the named channel does not exist, Messaging Server resumes using the process channel.
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.
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.
Messaging Server supports RFC 2476's Message Submission protocol. The submit keyword may be used to mark a channel as a submit-only channel. This is normally useful mostly 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 such message submission use.
Keywords: user
The user keyword is used on pipe channels to indicate under what user name to run.
Note that the argument to user is normally forced to lowercase, but original case is preserved if the argument is quoted.
Keywords: filter, nofilter, channelfilter, nochannelfilter, destinationfilter nodestinationfilter, sourcefilter, nosourcefilter, fileinto, nofileinto)
The filter keyword may be used on the native and ims-ms channels to specify the location of user filter files for that channel. It takes a required URL argument describing the filter file location. nofilter is the default and means that a user mailbox filters are not enabled for the channel.
The sourcefilter and destinationfilter keywords may be used on general MTA channels to specify a channel-level filter to apply to incoming and outgoing messages, respectively. These keywords take a required URL argument describing the channel filter file location. nosourcefilter and nodestinationfilter are the defaults and mean that no channel mailbox filter is enabled for either direction of the channel.
The obsolete channelfilter and nochannelfilter keywords are synonyms for destinationfilter and nodestinationfilter, respectively.
The fileinto keyword, currently supported only for the ims-ms and LMTP channels, specifies how to alter an address when a mailbox filter fileinto operator is applied. 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.
Keywords: destinationspamfilterXoptin, sourcespamfilterXoptin
destinationspamfilterXoptin specifies that all messages destined to this channel are run through filtering software X. (Filtering software X is defined by spamfilterX_library in option.dat.) The filter parameters follow the keyword and the available parameters depend on the filtering program.
sourcespamfilterXoptin specifies that all messages originating from this channel are run through filtering software X. (Filtering software X is defined by spamfilterX_library in option.dat.) The system-wide default parameters follow the keyword and the available parameters depend on the filtering program. If switchchannel is in effect, this keyword is placed on the switched-to channel.
For complete details on how these keywords are used, see To Specify Channel-level Filtering.
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.
The argument for aliasdetourhost is a host or domain name, or a host/domain specification. (Note that rewrite rules can handle host names, IP literal addresses, and channel tags, which are implicitly considered to be host names.) If specified on a source channel, the keyword causes alias expansion of addresses stored in LDAP to stop just prior to the point where mailhost information is checked (after conversion tag information has been processed). At that point the message will be sent to the aliasdetourhost value and the address is treated has successfully completed, but before alias expansion and after address validation.
An example of where aliasdetourhost can be used to circumvent various problems associated with conversion channel filtering is as follows: assume a system is set up with a front-end MTA and a back-end mail store. User have their delivery options set to forward and mailbox. The MTA uses the alternate conversion channel for anti-virus/spam system. When a message arrives for this user, the MTA alias expands and produces two recipients, one local and one remote. The remote recipient’s copy gets sent directly. The local recipient’s copy, on the other hand, goes to your conversion channel, is scanned, and returns. Alias expansion is then applied a second time, producing a second copy to the remote recipient and the local recipient’s copy is delivered normally. Net result: Two copies to the remote recipient, one to the local recipient.
Instead of using an alternate conversion channel for locally-hosted users (but possibly still using an alternate conversion channel for other recipients), a channel using aliasdetourhost can do the following:
Accept messages.
Route messages to an external spam/virus filter
Re-accept messages for address expansion and delivery.
Example 1:
Assume a third-party scanner running on a separate host from the MTA. The following example allows user entry forwarding to be used without creating spurious duplicates while preserving the ability to perform recipient address validation prior to accepting the message.
Create a new channel tcp_scanner.
Put the daemon keyword on that channel, pointing to your filtering system. Add the enqueue_removeroute to this channel, too. The tcp_scanner channel looks like this in imta.cnf:
tcp_scanner smtp mx single_sys subdirs 20 noreverse maxjobs 7 pool SMTP_POOL daemon my_a-v_filter.siroe.com enqueue_removeroute tcp_scanner-daemon |
Add aliasDetourHost tcp_scanner-daemon to tcp_local on all inbound source tcp channels that you want scanned, which would likely include tcp_local, tcp_submit, tcp_intranet and tcp_auth. Here we show an example for tcp_local and tcp_submit.
! tcp_local tcp_local smtp mx single_sys remotehost inner switchchannel identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0 aliasdetourhost tcp_scanner-daemon tcp-daemon |
! tcp_submit tcp_submit submit smtp mx single_sys mustsaslserver maytlsserver missingrecipientpolicy 4 aliasdetourhost tcp_scanner-daemon tcp_submit-daemon |
Note that the argument for the aliasdetourhost (tcp_scanner-daemon) is the official hostname of the new channel tcp_scanner.
Create a rewrite rule to receive the message back from the scanning system via the tcp_scanner channel.
[1.2.3.4] $E$R$U[1.2.3.4]@tcp_scanner-daemon
where 1.2.3.4 is the ip address of the scanner system.
If you don’t have this rewrite rule, the message will come in via one of the other tcp* source channels and the message will get scanned again because they all have the aliasdetourhost. A loop will occur.
Recompile your configuration, and restart dispatcher.
#imsimta cnbuild #imsimta restart dispatcher |
Example 2:
Assume a third-party scanner running on the same host as the MTA but listening on a different port. Assume mail is accepted on port 10024 and relays back on 10025.
Create a new channel tcp_scanner.
! tcp_scanner tcp_scanner smtp nomx single_sys identnonenumeric subdirs 20 maxjobs 7 pool SCAN_POOL daemon 127.0.0.1 port 10024 enqueue_removeroute tcp_scanner-daemon |
Add aliasDetourHost tcp_scanner-daemon to tcp_local on all inbound source tcp channels that you want scanned, which would likely include tcp_local, tcp_submit, tcp_intranet, and so forth. Here we show an example for tcp_local and tcp_submit.
! tcp_local tcp_local smtp mx single_sys remotehost inner switchchannel identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver maysaslserversaslswitchchannel tcp_auth missingrecipientpolicy 0 aliasdetourhost tcp_scanner-daemon tcp-daemon |
! tcp_submit tcp_submit submit smtp mx single_sys mustsaslserver maytlsserver missingrecipientpolicy 4 aliasdetourhost tcp_scanner-daemon tcp_submit-daemon |
Add to the mappings file to re-route outbound mail through the tcp_scanner channel.
CONVERSIONS in-chan=tcp_scanner;out-chan=*;CONVERT No in-chan=tcp_*;out-chan=tcp_local;CONVERT Yes,Channel=tcp_scanner
In job_controller.cnf, under SMTP_POOL, add a limit to the number of concurrent scans.
Although the scanning software should also have a limit, it’s good to keep this set the same so messaging server doesn’t try to send mail to the scanner when it’s not going to accept the message.
! [POOL=SCAN_POOL] job_limit=2 ! |
Add a new service to dispatcher.cnf to accept mail back from the scanner on a special port and source it from tcp_scan as to not scan it again
! [SERVICE=SMTP_SCANNING] INTERFACE_ADDRESS=127.0.0.1 PORT=10025 IMAGE=IMTA_BIN:tcp_smtp_server LOGFILE=IMTA_LOG:tcp_smtp_server.log STACKSIZE=2048000 PARAMETER=CHANNEL=tcp_scanner ! |
Recompile your configuration, and restart dispatcher.
# imsimta cnbuild # imsimta restart job_controller # imsimta restart dispatcher |
Keywords: sourcenosolicit and destinationnosolicit
The NO-SOLICIT SMTP extension described in the Internet-Draft draft-malamud-no-soliciting-07.txt has been implemented in Messaging Server as a proposed standard. The following channel keywords can be used to control this facility:
sourcenosolicit 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.
destinationnosolicit specifies a comma-separated list of solicitation field values that will not be accepted in mail queued to this channel.
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.