Ims-ms channel configuration

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


ims-ms channel configuration

An appropriate initial ims-ms channel definition and rewrite rule(s) are normally set up by the initial Messaging Server MTA installation and configuration process. Such a channel definition usually looks something like:


msconfig> show channel:ims-ms
role.channel:ims-ms.official_host_name = ims-ms-daemon
role.channel:ims-ms.backoff = PT5M PT10M PT30M PT1H PT2H PT4H
role.channel:ims-ms.defragment (novalue)

role.channel:ims-ms.fileinto = $U+$S@$D
role.channel:ims-ms.maxjobs = 2
role.channel:ims-ms.notices = 1 7 14 21 28
role.channel:ims-ms.pool = IMS_POOL

role.channel:ims-ms.subdirs = 20

or in legacy configuration:


ims-ms defragment subdirs 20 notices 1 7 14 21 28 \
 backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" \
 maxjobs 2 pool IMS_POOL fileinto $U+$S@$D 
ims-ms-daemon 

Because the ims-ms channel is, on a typical system hosting a Message Store, such an important channel in the overall picture of message handling, here is a brief synopsis of these typical ims-ms channel option usages, discussed in turn.

  • ims-ms channels should all normally be marked with the defragment channel option so that any incoming MIME fragmented messages will take a detour through the defragment channel to get an attempt at MIME message reassembly before being delivered to the Message Store.
  • The ims-ms channel is typically a heavily used channel, at least on a system that hosts a Message Store with numerous active users. For a heavily used such channel, it is typically a good idea to configure with a generous number of subdirectories for performance reasons; thus the use of the subdirs option. On an especially busy Message Store system, where user quotas are enforced but a generous quota grace period is allowed, an even higher value for subdirs may be desirable. On a system that is only, or primarily, an SMTP relay host, that does not have a significantly used message store, use of subdirs may be unnecessary and the option might be removed.
  • With the MTA option return_units at its (default) setting of 0 so that notices values are interpreted in units of days, the ims-ms channel is often set to retain messages for a rather long period, intended to cover the overquota grace period---that is, give users a chance to clean out old messages and receive their additional messages -- before eventually returning (bouncing) the messages as undeliverable. That is, a special setting rather more generous than the setting used for other channels (such as channels attempting to deliver out to the Internet) is often used.
  • Fairly "rapid" initial additional delivery attempts are often configured for the ims-ms channel, via small initial backoff values. Since a user mailbox may get temporarily locked by the Message Store while another message is being delivered, or while a user is moving or copying a message to another folder via IMAP, it is possible to see short-term inabilities to deliver to a particular mailbox that will resolve relatively quickly. Thus it is worthwhile to re-attempt delivery at fairly rapid initial intervals. (This is unlike the case of a channel attempting to deliver to remote Internet hosts, where remote hosts may be unreachable for hours or days and hence where very rapid repeated delivery attempts may be useless and often even counter-productive, and where furthermore, Internet standards require waiting at least one half hour before reattempting message delivery to remote Internet hosts.)
  • Due to the importance, in a typical deployment, of the ims-ms channel, a separate Job Controller pool intended for the sole use of the ims-ms channel is usually defined, and then the ims-ms channel is configured to run in that processing pool via the pool keyword. In particular, in this way the ims-ms channel runs in a separate Job Controller processing pool than TCP/IP channels (another heavily used type of channel), or than internal processing channels such as the process channel (used for processing notification messages, hence subject to periods of heavy use); the potential for competition for resources between these different types of channels is limited thereby. The maxjobs channel option is used to limit the number of simultaneously running ims-ms channel processes. Note that the ims-ms channel is multi-threaded; see the DELIVER_THREADS  ims-ms-channel-specific option. So even a single ims-ms channel process can be attempting multiple deliveries at once. The Job Controller attempts to sort messages destined for a particular user into the same processing thread; this limits mailbox locking contention between different processing threads. (For another factor that can affect ims-ms channel performance, see the threaddepth channel option.)
  • The fileinto channel option is used to specify support for Sieve fileinto actions. (That is, the fileinto channel option is used to specify what a Sieve fileinto action actually causes to occur---namely, changing the address to include the folder name as a subaddress. The ims-ms channel by default then interprets the subaddress as a request to deliver to the user's named folder, unless disabled via the ims-ms-channel-specific option FILEINTO.)

Rewrite rules for the ims-ms channel involve more complexity than the rewrite rules for many other types of channels, as they are fundamentally intertwined with direct LDAP lookup processing. This discussion will not attempt to cover the whole of direct LDAP lookup processing; instead, this discussion will merely provide a brief overview (simplifying and omitting some details) of the basics of the rewriting involved in routing to the ims-ms channel.

Basic rewrite rules relevant for the ims-ms channel are normally set up by the initial Messaging Server MTA installation and configuration process. Those rewrite rules usually look something like:


! Basic direct LDAP rewrite rule to select local users 
! 
$* $A$E$F$U%$H$V$H@local-channel-official-host-name
! 
! ...various other rewrite rules... 
! 
! ims-ms 
.ims-ms-daemon $U%$H.ims-ms-daemon@ims-ms-daemon 

where local-channel-official-host-name is the "l" channel's official host name, l.official_host_name in Unified Configuration, (or in legacy configuration, the first name on the second logical line of the c"l", lowercase ell, channel definition).

In Unified Configuration, this would appear as:


msconfig> show rewrite * $*
role.rewrite.rule = $* $A$E$F$U%$H$V$H@&/IMTA_HOST/
msconfig> show rewrite * .ims-ms-daemon
role.rewrite.rule = .ims-ms-daemon $U%$H.ims-ms-daemon@ims-ms-daemon

where note that the &/IMTA_HOST/ handles the insertion of the ldap_local_host value (which normally should match the channel:l.official_host_name value).

Also extremely relevant for the rewriting process for the ims-ms channel, and normal routing of messages to the ims-ms channel, are the MTA options alias_urlN, especially alias_url0, and delivery_options, especially its mailbox clause, normally set to:


*mailbox=$M%$\$2I$_+$2S@ims-ms-daemon 

(And security-related settings are the use of the viaaliasrequired channel option on the local channel, and the ORIG_MAIL_ACCESS mapping table entry that blocks direct submission to username@ims-ms-daemon sorts of addresses; that is, these two configuration choices add in restrictions to mean that "local" addresses must have an alias in LDAP, and route to the ims-ms channel by way of an alias expansion.)

The normal process of routing messages to the ims-ms channel involves rewriting, alias expansion, and application of user LDAP attributes, as follows:

  1. Initially, the domain in an envelope To address (recipient address) is used to do an LDAP search for the domain; this is done via the (direct LDAP domain lookup) rewrite rule:

    
        $* $A$E$F$U%$H$V$H@local-channel-official-host-name
    
  2. If the domain was found in LDAP, various domain level attributes are set and this rewrite rule (when the LDAP lookup succeeds) forcibly matches the address to the local (lowercase l) channel.
  3. When an address matches the local (lowercase "l") channel, the MTA performs alias expansion on the address. In particular, this includes an LDAP lookup (the alias_url0 lookup, and if other alias_urlN lookups are configured, then if necessary those lookups also) attempting to find an LDAP entry for this user address.
  4. When a user entry is found in LDAP, the values of its mailDeliveryOption LDAP attribute (more specifically, the LDAP attribute named by the MTA option ldap_delivery_option) are inspected. A value of mailbox will cause the configured rule for the mailbox clause of the delivery_options MTA option to be applied; namely, the address will be converted to the form (if no subaddress/folder name is present):

    uid%lowercased-domain-name@ims-ms-daemon 
    
    

    or if a subaddress/folder name is present:

    uid%lowercased-domain-name+folder@ims-ms-daemon 
    
    

    Or if the domain name is actually the default domain name (as specified via either the defaultdomain option -- in legacy configuration, the configutil parameter service.defaultdomain, or the MTA option ldap_default_domain), then the domain name (and leading percent character) are omitted, hence:

    uid@ims-ms-daemon 
    
    

    or

    uid+folder@ims-ms-daemon
    
    
    
  5. This (transformed) address then goes through rewriting, and it forcibly matches the ims-ms channel, due to the matching official host name (ims-ms-daemon) for the channel: the message is routed to the ims-ms channel.


See also: