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.
Note that for fileinto to work with LMTP, the tcp_lmtpss channel on the backend message store requires the flagtransfer keyword. (see 16.5.1 To Configure Back End Stores with LMTP and a Minimal MTA).
Keywords: destinationspamfilterXoptin, sourcespamfilterXoptin, disabledestinationspamfilterX, disablesourcespamfilterX
destinationspamfilterXoptin specifies that all messages destined to this channel are run through filtering software X even if those services are not specified by user or domain with the LDAP_OPTINX LDAP attributes. (Filtering software X is defined by spamfilterX_library in option.dat.) The optin parameters follow the keyword and the available parameters depend on the filtering program. For example, Brightmail parameters are normally spam or virus or spam,virus. The SpamAssassin parameter is spam.
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.
sourcespamfilterX and destinationspamfilterX do the same thing as destinationspamfilterXoptin and destinationspamfilterXoptin, but don't accept optin parameters. They are used with filtering software that do not pass parameters and are simply enabled or not.
disabledestinationspamfilter X disables spam filter X for messages destined to this channel. If a message came from a channel that enabled spam filter X (example: destinationspamfilterXoptin) or the filter was enabled through the use of optin attributes in a user or domain LDAP entry, this keyword will disable it.
disablesourcespamfilterX disables spam filter X for messages coming from this channel. If a message is sent to a channel that enables spam filter X (example: destinationspamfilterXoptin) or the filter was enabled through the use of optin attributes in a user or domain LDAP entry, this keyword will disable it.
For complete details on how these keywords are used, see To Specify Channel-level Filtering.
Keywords: aliasdetourhost, aliasoptindetourhost
aliasdetourhost and aliasoptindetourhost allow 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. (Note that when we mention aliasdetourhost we are also describing aliasoptindetourhost, which is similar function to aliasdetourhost except detouring only occurs if the user has opted in via an LDAP following attribute.
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 |
Per-user aliasdetourhost is now possible through the following set of features:
aliasoptindetourhost channel keyword. This is similar in function to aliasdetourhost except detouring only occurs if the user has opted in via the following attribute. The keyword's value is a comma-separated list of potential detour hosts.
LDAP_DETOURHOST_OPTIN MTA option which specifies the name of an attribute used to opt the user in to the detour (assuming of course the source channel has aliasoptindetourhost set). If the values of this attribute contain periods they will be compared against the list of potential detour hosts and the first host on the list that matches will be the chosen detour. If the value doesn't contain a period the first detour host will be used unconditionally.
ALIASDETOURHOST_NULL_OPTIN MTA option, which is similar to SPAMFILTERx_NULL_OPTIN (see Table 14–1. It specifies a special value which if used in the LDAP_DETOURHOST_OPTIN attribute is treated as the same as the attribute being omitted. The default value is "", which means that an empty attribute value is ignored.
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.
Keywords: caption and description
These keywords take a quoted string as an argument and are used for channel displays in the Monitoring Framework Console. If no caption or description are present, the Monitoring Framework agent invents one from the channel name.