Miscellaneous Keywords

This section describes miscellaneous keywords. It consists of the following sections:

• Channel Operation Type

• Pipe Channel

• Specifying Mailbox Filter File Location

• Spam Filter Keywords

• Routing After Address Validation But Before Expansion

• NO-SOLICIT SMTP Extension Support

• Setting Limits on Bad RCPT TO Addresses

Process Channel Overrides

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.

Channel Operation Type

Keywords: submit

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.

Pipe Channel

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.

Specifying Mailbox Filter File Location

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.

Spam Filter Keywords

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.

Routing After Address Validation But Before Expansion

Keywords: aliasdetourhost

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.

1. 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

2. 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.

3. 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.

4. 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.

1. 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

2. 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

3. 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

4. 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 !

5. 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 !

6. Recompile your configuration, and restart dispatcher.

   # imsimta cnbuild # imsimta restart job_controller # imsimta restart dispatcher

NO-SOLICIT SMTP Extension Support

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.

Setting Limits on Bad RCPT TO Addresses

Keywords: deferralrejectlimit

Sets a limit on the number of bad RCPT TO: addresses that are allowed during a single session. After the specified number of To: addresses have been rejected, all subsequent recipients, good or bad, are rejected with a 4xx error. Provides same functionality as the ALLOW_REJECTIONS_BEFORE_DEFERRAL SMTP channel keyword, but on a per-channel basis.