Ims-ms channel configuration

channel configuration
An appropriate initial  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&#x3e; 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  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  channel option usages, discussed in turn.



 channels should all normally be marked with the     channel option so that    any incoming MIME    fragmented messages will take a detour through the      channel    to get an attempt at MIME message reassembly before being delivered to    the Message Store. 

 The 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      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      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   may be unnecessary and the    option might be removed. 

 With the MTA option     at its (default)    setting of 0 so that      values are interpreted in units    of days, the      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   channel, via small initial      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       channel, a separate    Job Controller pool intended for the    sole use of    the   channel is usually defined, and then the      channel is    configured to run in that processing pool via the      keyword. In particular, in this way the  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      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     channel option is used to limit    the number of simultaneously running   channel processes. Note that the  channel is multi-threaded; see the          -channel-specific option. So even a single  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   channel performance, see the         channel option.) 

 The  channel option is used to    specify support for    Sieve   actions. (That is, the     channel option is used to specify what a Sieve      action actually causes to occur---namely,    changing the address to include the folder name as a    subaddress. The      channel by default then interprets the subaddress as a request    to deliver to the user&#x27;s named folder, unless disabled via the     -channel-specific   option  .) 



Rewrite rules for the  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   channel.

Basic rewrite rules relevant for the  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 ! $&#x2a; $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   is the "l" channel&#x27;s 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&#x3e; show rewrite &#x2a; $&#x2a; role.rewrite.rule = $&#x2a; $A$E$F$U%$H$V$H@&/IMTA_HOST/ msconfig&#x3e; show rewrite &#x2a; .ims-ms-daemon role.rewrite.rule = .ims-ms-daemon $U%$H.ims-ms-daemon@ims-ms-daemon where note that the  handles the insertion of the    value (which normally should match the    value).

Also extremely relevant for the rewriting process for the   channel, and normal routing of messages to the   channel,  are the  MTA options    ,  especially  , and   ,  especially its   clause, normally  set to: &#x2a;mailbox=$M%$\$2I$_+$2S@ims-ms-daemon (And security-related settings are the use of the   channel  option on the local channel, and  the    mapping  table entry that blocks direct submission  to    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   channel by way of an alias expansion.)

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





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: $&#x2a; $A$E$F$U%$H$V$H@local-channel-official-host-name </li>

 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. </li>

 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      lookup, and if    other       lookups are configured, then if necessary    those lookups also) attempting to find an LDAP entry for this user    address. </li>



When a user entry is found in LDAP, the values of its     LDAP attribute (more specifically, the    LDAP attribute named by the MTA option     ) are    inspected. A value of  will cause the configured    rule for the   clause of the         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    option -- in legacy configuration, the configutil parameter , or the  MTA option   ),  then the domain name (and leading  percent character) are omitted, hence: uid@ims-ms-daemon or uid+folder@ims-ms-daemon </li>

 This (transformed) address then goes through rewriting, and it forcibly matches the  channel, due to the   matching official host name  for the channel: the    message is routed to the   channel. </li>

</ol>

See also:
 * official_host_name Option
 * ldap_local_host MTA Option
 * backoff Option
 * defragment Option
 * Sieve fileinto action
 * fileinto Option
 * Subaddresses in aliases
 * maxjobs Option
 * notices Option
 * pool Option
 * subdirs Option
 * quotaenforcement Store Option
 * quotagraceperiod Store Option
 * threaddepth Option
 * return_units MTA Option
 * Defragmentation channel
 * Job Controller operation
 * TCPIP channels
 * Process and reprocess channels
 * Notification messages
 * ims-ms-channel-specific options
 * DELIVER_THREADS
 * FILEINTO ims-ms-channel-specific option
 * Rewrite rules
 * Overview of Direct LDAP configuration
 * official_host_name Option
 * alias_url0 MTA Option
 * delivery_options MTA Option
 * ldap_delivery_option MTA Option
 * Local channel
 * Recipient access mapping tables
 * Aliases in LDAP
 * Additional ims-ms channels
 * Channel options
 * ims-ms channels