text:
Version 6.3
These Release Notes contain important information available at the time of release of Sun Java Messaging Server 6.3. New features and enhancements, known issues and limitations, and other information are addressed here. Read this document before you begin using Messaging Server 6.3.
Sun is not responsible for the availability of third-party Web sites mentioned in this document. Sun does not endorse and is not responsible or liable for any content, advertising, products, or other materials that are available on or through such sites or resources. Sun will not be responsible or liable for any actual or alleged damage or loss caused by or in connection with the use of or reliance on any such content, goods, or services that are available on or through such sites or resources.
These release notes contain the following sections:
Third-party URLs are referenced in this document and provide additional, related information.
Description of Changes
May 2008
Changed supported version of Directory Server from 6.0 to 6.x
August 2007
Announced that Sun Cluster 3.2 is supported with Messaging Server.
July 2007
Clarified Web browser support by pointing to Communications Express chapter.
June 2007
Clarified Sun Cluster and Veritas Cluster version support; added new bugs for ENS in HA environment and incorrect directories that are created during installation.
May 2007
Added deprecated statement for Red Hat Linux 3.1 support.
March 2007
Revenue Release of Sun JavaTM System Messaging Server 6.3
September 2006
Beta release of Sun Java System Messaging Server 6.3
Messaging Server is a high-performance, highly secure messaging platform that can scale from thousands to millions of users. It provides extensive security features that help ensure the integrity of communications through user authentication, session encryption, and the appropriate content filtering to prevent spam and viruses. With Messaging Server, enterprises and service providers can provide secure, reliable messaging services for entire communities of employees, partners, and customers.
Messaging Server provides a powerful and flexible solution to the email needs of enterprises and messaging hosts of all sizes by using open Internet standards.
The following new features and enhancements were added to the Messaging Server 6.3 release:
Message Archiving with the Sun Content Management and the Sun Compliance and Content Management Solution
Messaging Server supports archiving through the Sun Content Management and the Sun Compliance and Content Management Solution. A message archiving system saves all or some specified subset of incoming and outgoing messages on a system separate from Messaging Server. Sent, received, deleted, and moved messages can all be saved and retrieved in an archive system. Archived messages cannot be modified or removed by email users so the integrity of incoming and outgoing communication is maintained. Message archiving is useful for compliance record keeping, message store management, and message back up. See Message Archiving Using the Sun Compliance and Content Management Solution for more information.
Although operational archiving is documented, this feature is disabled until the Sun Java System Messaging Server 6.3 Patch 1 release.
The webmail server, also known as mshttpd (Messaging Server HTTP Daemon), provides email services to the Messenger Express and Communications Express clients. Now, the webmail server accesses the message store through the IMAP server. This provides several advantages:
Messenger Express and Communications Express clients are now able to access shared folders that are located on different back-end message stores.
The webmail server no longer must be installed on each back-end server.
The webmail server can serve as a front-end server performing the multiplexing capabilities previously performed by Messenger Express Multiplexor (MEM).
MEM is no longer used. See Deprecated and Removed Features for Messaging Server.
On the client side, nothing is changed except that users can now access shared folders that are not on their message store. In previous versions, the MEM received HTTP client requests and forwarded it to the appropriate webmail server on the appropriate back-end message store. Because of this, a copy of mshttpd had to be installed on every back-end server. Now, the webmail server operates as a front-end server receiving HTTP client email requests. It translates these requests to SMTP or IMAP calls and forwards the calls to either the MTA or the appropriate IMAP server on the back-end message store.
MeterMaid allows throttling by determining when an IP address has recently connected too often and should be turned away for awhile. MeterMaid represents the officer patrolling the streets, looking for those who have exceeded their allotted amount. It is a repository process that supplants conn_throttle.so , providing similar functionality but extending it across the Messaging Server product. In addition, MeterMaid is more configurable than conn_throttle.so.
At this time, no further enhancements will be made to conn_throttle.so .
Messaging Server supports the use of the popular and freely available third-party virus scanner ClamAV for the detection of virus and Trojan horse infected messages.
Programs based on the Sendmail Content Management API, also called Milters (short for Mail Filter), can now be run in Messaging Server. Milter provides a plug-in interface for third-party software to validate and modify messages as they pass through the MTA. Milters can process a message's connection (IP) information, envelope protocol elements, message headers, and/or message body contents, and modify a message's recipients, headers, and body. Possible uses for filters include spam rejection, virus filtering, and content control. In general, Milter seeks to address site-wide filtering concerns in a scalable way. See Using Milter in Sun Java System Messaging Server 6.3 Administration Guide.
The SORT extension to the IMAP protocol provides a means of server-bas ed sorting of messages, without requiring that the client download the necessary data to do so itself. See: http://www3.tools.ietf.org/html/draft-ietf-imapext-sort-18 for more information.
The IMAP IDLE extension to the IMAP specification, defined in RFC 2177, allows an IMAP server to notify the mail client when new messages arrive and other updates take place in a user's mailbox. The IMAP IDLE feature has the following benefits:
Mail clients do not have to poll the IMAP server for incoming messages.
Eliminating client polling reduces the workload on the IMAP server and enhances the server's performance. Client polling is most wasteful when a user receives few or no messages; the client continues to poll at the configured interval, typically every 5 or 10 minutes.
A mail client displays a new message to the user much closer to the actual time it arrives in the user's mailbox. A change in message status is also displayed in near-real time.
The IMAP server does not have to wait for the next IMAP polling message before it can notify the client of a new or updated mail message. Instead, the IMAP server receives a notification as soon as a new message arrives or a message changes status. The server then notifies the client through the IMAP protocol.
IMAP IDLE is off by default.
High Performance User Lookup and Authentication (HULA) provides a library for the Communications Suite to achieve consistent user lookup semantics as, for example, domainmap does for domain lookups. With HULA, the following interface changes will affect the MMP:
HULA has been implemented in multiple releases. This release supports the MMP implementation of HULA. The next release supports HULA implementation in the Message Store and the MTA.
The following interface changes will affect the MMP:
The MMP now supports user status attributes. Prior to this release, the MMP relied on the back-end servers to enforce user status. This change reduces load on the back-end during user migration scenarios.
The MMP log messages have been normalized to always include an integer connection ID which is not reused during the MMP process lifetime. Previously, the MMP messages used a hex connection context address which could be reused. Furthermore, the lpool layer used a different context address that was difficult to correlate. Now the MMP, hula and lpool layers will all use the same ID.
The MMP debug log level configuration setting now uses syslog-style log levels rather than unspecified numeric levels. The LogLevel option used to default to 1; it now defaults to 5 (LOG_NOTICE). Values below 3 produce no output. Values from 3 (LOG_ERR) to 7 (LOG_DEBUG) provide different quantities of output in the debug log.
The MMP will now support the following additional MTA options from option.dat: LDAP_DOMAIN_FILTER_SCHEMA1, LDAP_DOMAIN_FILTER_SCHEMA2, LDAP_ATTR_DOMAIN1_SCHEMA2, LDAP_ATTR_DOMAIN2_SCHEMA2, LDAP_ATTR_DOMAIN_SEARCH_FILTER, LDAP_DOMAIN_ATTR_BASEDN, LDAP_DOMAIN_ATTR_CANONICAL, LDAP_DOMAIN_ATTR_ALIAS, LDAP_UID, LDAP_DOMAIN_ATTR_UID_SEPARATOR, LDAP_DOMAIN_ATTR_STATUS, LDAP_DOMAIN_ATTR_MAIL_STATUS, LDAP_USER_STATUS, LDAP_USER_MAIL_STATUS.
The ident support in TCP access filters was implemented but untested in previous releases. A warning was placed in the manual that ident support was deprecated several releases ago. The new code does not implement support for ident. Filters which require ident will cause authentication to fail with an error.
Previous versions of MMP permitted user names with any UTF-8 character although this was untested. HULA enforces correct UTF-8 syntax and forbids overlong encodings and surrogates.
The new -k option of the imsconnutil utility disconnects users from IMAP and POP sessions. Users logged on to Communications Express lose the underlying IMAP connection and, thus, are also disconnected.
The JMQ Notification plug-in allows you to deliver notification messages using the Java Messaging Service (JMS) standard. You can now configure plug-ins to send notifications to two different messaging services:
Sun Java System Message Queue 3.6 or later, which implements the JMS standard
Event Notification Service
With Message Queue, you can produce topics to a message or a queue, or to both of these delivery methods. Message Queue also provides enhanced load balancing, scalability, and reliability. See Chapter 22, Configuring the JMQ Notification Plug-in to Produce Messages for Message Queue, in Sun Java System Messaging Server 6.3 Administration Guide.
Sender Policy Framework (SPF) is a technology that can detect and reject forged email during the SMTP dialogue. Specifically, SPF is a method that allows a domain to explicitly authorize the hosts that may use its domain name. In addition, a receiving host may be configured to check this authorization. SPF can thus significantly reduce the instances of forged email. See: Chapter 15, Handling Forged Email Using the Sender Policy Framework, in Sun Java System Messaging Server 6.3 Administration Guide
Message store quotas can now be set for specific folders and message types. Message type quotas allow you to specify limits for message types like voicemail and email. Folder quotas set limits on the size of a user's folder in bytes or messages. For example, a quota can be set on the Trash folder. Messaging Server allows you to set default quotas for domains and users as well as customized quotas. See About Message Store Quotas in Sun Java System Messaging Server 6.3 Administration Guide.
Certificates can no longer be obtained through the Administration Console. Instead, a new command called msgcert is used. The old certutil command can still be used, but it is much more complicated and is not internationalized. See Obtaining Certificates in Sun Java System Messaging Server 6.3 Administration Guide for details.
For information on the Sun JavaTM Enterprise System Monitoring Framework, see: Sun Java Enterprise System 5 Monitoring Guide.
Previous versions of the MMP did not look at the inetUserStatus, mailUserStatus, inetDomainStatus, mailDomainStatus attributes. The MMP relied on the back-end server to reject connections when accounts were inactive, disabled or deleted. The current version of the MMP now supports these attributes and terminates the connection at the MMP layer if the status is something other than "active", "overquota" or empty. This should improve the scalability of a deployment when migrating users.
MMP debug log levels and session ID: The meaning of the "LogLevel" configuration option for the MMP has been changed to make it follow syslog conventions. In previous releases, it was an arbitrary value defaulting to 1. In this release it follows syslog conventions. The default value is 5 (LOG_NOTICE), and values from 3 (LOG_ERR) to 7 (LOG_DEBUG) alter the set of messages displayed and have the same meaning they do for syslog() . Also, the messages in the MMP debug log files now use a session/connection ID that is numeric and unique within the lifetime of the MMP process.
Many of the new MTA features described in this section have been incorporated into the Messaging Server documentation. The features are listed here for completeness and to announce the new features.
(54) A new facility has been added to store information that previously would have gone in the general, forward, and reverse databases in the compiled configuration instead. A new MTA option, USE_TEXT_DATABASES, has been added to control this capability. This option is bit encoded. If bit 0 (value 1) is set the file IMTA_TABLE:general.txt is read as the MTA configuration is initialized and the information from that file replaces all uses of the general database. If bit 1 (value 2) is set the file IMTA_TABLE:reverse.txt is read and used in instead of the reverse database. Finally, if bit 2 (value 4) is set the file IMTA_TABLE:forward.txt is read and used instead of the forward database. The default value for this option is 0, which disables all use of text databases. Note that use of the text database option means that changes to the underlying files will only be seen after a cnbuild, and in the case of running processes, after a reload. Several additional MTA options can be used to set the initial size of the various text database tables: GENERAL_DATA_SIZE - Initial number of entries in the general text database. REVERSE_DATA_SIZE - Initial number of entries in the reverse text database. FORWARD_DATA_SIZE - Initial number of entries in the forward text database. The MTA stores the database template strings in string pool 3, so the STRING_POOL_SIZE_3 MTA option controls the initial allocation of space for this purpose. Note that these various options only control initial sizes; the various tables and arrays will resize automatically up to the maximum allowed size. The maximum string pool size in 6.2P8 and earlier is 10Mb, after 6.2P8 is has been increased to 50Mb. Up to 1 million entries are allowed in 6.2P8 and earlier, this has been increased to 2 million entries in later releases. (144) A new MTA option, USE_CANONICAL_RETURN, has been added. This option is bit-encoded with the various bits matching those of the USE_ORIG_RETURN option. Each place where the MTA performs a comparison operation against the envelope from (MAIL FROM) address has an assigned bit. If the bit in USE_CANONICAL_RETURN is clear normal rewriting is applied to the envelope from address prior to use. In particular rewriting from mailAlternateAddress attributes to mail attributes will be performed; mailEqvuialentAddress attributes won't be rewritten to the corresponding mail attribute. If, however, the bit is set, the corresponding address will be rewritten if it appears in a mailEquivalentAddress attribute. It should be noted that the bit USE_ORIG_RETURN will, if set, disable rewriting entirely. So setting a bit in USE_ORIG_RETURN makes the corresponding bit in USE_CANONICAL_RETURN a noop. Note that the various bits of USE_ORIG_RETURN don't appear to be documented at this time, so here's a list of them: Bit Value Usage 0 1 When set, use the original envelope From: address in ORIG_SEND_ACCESS mapping table probes 1 2 When set, use the original envelope From: address in SEND_ACCESS mapping table probes 2 4 When set, use the original envelope From: address in ORIG_MAIL_ACCESS mapping table probes 3 8 When set, use the original envelope From: address in MAIL_ACCESS mapping table probes 4 16 When set, use the original envelope From: address in mailing list [AUTH_LIST], [MODERATOR_LIST], [SASL_AUTH_LIST], and [SASL_MODERATOR_LIST] checks 5 32 When set, use the original envelope From: address in mailing list [CANT_LIST] and [SASL_CANT_LIST] checks 6 64 When set, use the original envelope From: address in mailing list [AUTH_MAPPING], [MODERATOR_MAPPING], [SASL_AUTH_MAPPING], and [SASL_MODERATOR_MAPPING] checks 7 128 When set, use the original envelope From: address in mailing list [CANT_MAPPING] and [SASL_CANT_MAPPING] checks 8 256 When set, use the original envelope From: address in mailing list [ORIGINATOR_REPLY] comparisons 9 512 When set, use the original envelope From: address in mailing list [DEFERRED_LIST], [DIRECT_LIST], [HOLD_LIST], and [NOHOLD_LIST] checks 10 1024 When set, use the original envelope From: address in mailing list [DEFERRED_MAPPING], [DIRECT_MAPPING], [HOLD_MAPPINGS], and [NOHOLD_MAPPING] checks 11 2048 When set, use the original envelope From: address in mailing list checks for whether the sender is the list moderator 12 4096 When set, use the original envelope From: address in mailing list LDAP_AUTH_DOMAIN LDAP attribute (e.g., mgrpAllowedDomain) checks 13 8192 When set, use the original envelope From: address in mailing list LDAP_CANT_DOMAIN LDAP attribute (e.g., mgrpDisallowedDomain) checks 14 16384 When set, use the original envelope From: address in mailing list LDAP_AUTH_URL LDAP attribute (e.g., mgrpAllowedBroadcaster) checks 15 32768 When set, use the original envelope From: address in mailing list LDAP_CANT_URL LDAP attribute (e.g., mgrpDisallowedBroadcaster) checks 16 65536 OBSOLETE. In Messaging Server 5.0 and Messaging Server 5.1, when set use the original envelope From: address in mailing list LDAP_MODERATOR_RFC822 comparisons; since as of Messaging Server 5.2 there is no longer any such global MTA option nor need for such an attribute (since the LDAP_MODERATOR_URL attribute value can, in fact, specify a mailto: URL pointing to an RFC 822 address), this bit no longer has any meaning. 17 131072 When set, use the original envelope From: address in mailing list LDAP_MODERATOR_URL LDAP attribute (e.g., mgrpModerator) comparisons 18 262144 When set, use the original envelope From: address in any source-specific FORWARD mapping tables probes 19 524288 When set, use the original envelope From: address in any source-specific FORWARD database probes Bit 0 is the least significant bit. (145) The SPAMFILTERn_OPTIONAL MTA options now accept two additional values: -2 and 2. -2 and 2 are the same as 0 and 1 respectively except that they also cause a syslog message to be sent in the event of a problem reported by the spam filter plugin. (146) Old-style mailing lists defined in the aliases file or aliases database now accept a nonpositional [capture] parameter. If used the [capture] parameter specifies a capture address with the same semantics as capture addresses specified by the LDAP_CAPTURE attribute applied to a user or group in LDAP. (147) The default value for the MISSING_RECIPIENT_POLICY MTA option has been changed from 2 (add envelope recipient list as a To: field) to 1 (ignore missing recipient condition). This brings Messaging Server in line with what RFC 2822 recommends. (148) Although it will rarely make sense to do so, the x_env_to keyword can now be used without also setting single on a channel. (149) The MTA now has the ability to process multiple different LDAP attributes with the same semantics. Note that this is not the same as processing of multiple values for the same attribute, which has always been supported. The handling attributes receive depends on the semantics of the attribute. The possible options are: (a) Multiple different attributes don't make sense and render the user entry invalid. In 6.2 and later this handling is the default for all attributes unless otherwise specified. (b) If multiple different attribute are specified one is chosen at random and used. LDAP_AUTOREPLY_SUBJECT, LDAP_AUTOREPLY_TEXT, and LDAP_AUTOREPLY_TEXT_INT all receive this handling in 6.2 only; in 6.3 and later they receive the handling described in item 153 below. 6.3 adds the LDAP_SPARE_3 and LDAP_PERSONAL_NAME attribute to this category. Note that this was how all attributes were handled prior to 6.2. (c) Multiple different attributes do make sense and should all be acted on. This handling is currently in effect for LDAP_CAPTURE, LDAP_ALIAS_ADDRESSES, LDAP_EQUIVALENCE_ADDRESSES and LDAP_DETOURHOST_OPTIN. Note that LDAP_DETOURHOST_OPTIN attribute was first added to Messaging Server in 6.3. (150) The MTA now has the ability to chose between multiple LDAP attributes and attribute values with different language tags and determine the correct value to use. The language tags in effect are compared against the preferred language information associated with the envelope from address. Currently the only attributes receiving this treatment are LDAP_AUTOREPLY_SUBJECT (normally mailAutoReplySubject), LDAP_AUTOREPLY_TEXT (normally mailAutoReplyText), LDAP_AUTOREPLY_TEXT_INT (normally mailAutoReplyTextInternal), LDAP_SPARE_4, LDAP_SPARE_5, LDAP_PREFIX_TEXT and LDAP_SUFFIX_TEXT. It is expected that each attribute value will have a different language tag value; if different values have the same tag value the choice between them will be essentially random. 151) The length of URLs that can be specified in a mapping URL lookup has been increased from 256 to 1024. The same increase also applies to expressions evaluated by mappings and mapping calls to other mappings. (152) A new MTA option, LOG_REASON, controls storage of error reason information in log records. Setting the option to 1 enables this storage, 0 (the default) disables it. This information, if present, appears just before diagnostic information in log records. (153) A :percent argument has been added to spamtest. If present it changes the range of the spamtest result from 0-10 to 0-100. See the Internet Draft draft-ietf-sieve-spamtestbis-05.txt for additional information on this change. (154) The SpamAssassin spam filter plugin's DEBUG option setting now accepts an integer value instead of a boolean 0 or 1. The larger the value the more debugging will be generated. In particular, a setting of 2 or greater reports exactly what was received from spamd. (155) The conversion mapping now allows a new "PREPROCESS" directive. If specified it allows charset conversions to be done on messages prior to sending them to the conversion channel. (156) The $. metacharacter sequence can now be used in a mapping or rewrite rule to establish a string which will be processed as the mapping entry result in the event of a temporary LDAP lookup failure. By default temporary LDAP failures cause the current mapping entry to fail. This is problematic in cases where different actions need to be taken depending on whether the LDAP lookup failed to find anything versus the directory server being unavailable or misconfigured. The temporary failure string is terminated by an unescaped ".". In the case of mappings once a failure string has been set using this construct it will remain set until current mapping processing is completed. Rewrite rules behave differently; a temporary failure string remains set only for the duration of the current rule. "$.." can be used to return to the default state where no temporary failure string is set and temporary LDAP failures cause mapping entry or rewrite rule failure. Note that all errors other than failure to match an entry in the directory are considered to be temporary errors; in general it isn't possible to distinguish between errors caused by incorrect LDAP URLs and errors caused by directory server configuration problems. (157) Setting the LOG_FORMAT MTA option to 4 now causes log entries to be written in an XML-compatible format. Entry log entry appears as a single XML element containing multiple attributes and no subelements. Three elements are currently defined, en for enqueue/dequeue entries, co for connection entries, and he for header entries. Enqueue/dequeue (en) elements can have the following attributes: ts - time stamp (always present) no - node name (present if LOG_NODE=1) pi - process id (present if LOG_PROCESS=1) sc - source channel (always present) dc - destination channel (always present) ac - action (always present) sz - size (always present) so - source address (always present) od - original destination address (always present) de - destination address (always present) de - destination address (always present) rf - recipient flags (present if LOG_NOTARY=1) fi - filename (present if LOG_FILENAME=1) ei - envelope id (present if LOG_ENVELOPE_ID=1) mi - message id (present if LOG_MESSAGE_ID=1) us - username (present if LOG_USERNAME=1) ss - source system (present if bit 0 of LOG_CONNECTION is set and source system information is available) se - sensitivity (present if LOG_SENSITIVITY=1) pr - priority (present if LOG_PRIORITY=1) in - intermediate address (present if LOG_INTERMEDIATE=1) ia - initial address (present if bit 0 of LOG_INTERMEDIATE is set and intermediate address information is available) fl - filter (present if LOG_FILTER=1 and filter information is available) re - reason (present if LOG_REASON=1 and reason string is set) di - diagnostic (present if diagnostic info available) tr - transport information (present if bit 5 of LOG_CONNECTION is set and transport information is available) ap - application information (present if bit 6 of LOG_CONNECTION is set and application information is available) Here is a sample en entry: en ts="2004-12-08T00:40:26.70" pi="0d3730.10.43" sc="tcp_local" dc="l" ac="E" sz="12" so="email@example.com" od="rfc822;firstname.lastname@example.com" de="email@example.com" rf="22" fi="/path/ZZ01LI4XPX0DTM00IKA8.00" ei="firstname.lastname@example.com" mi="<11a3b401c4dd01$7c1c1ee0$1906fad0@elara>" us="" ss="elara.whittlesong.com ([188.8.131.52])" in="firstname.lastname@example.com" ia="firstname.lastname@example.com" fl="spamfilter1:rvLiXh158xWdQKa9iJ0d7Q==, addheader, keep" Here is a sample co entry: co ts="2004-12-08T00:38:28.41" pi="1074b3.61.281" sc="tcp_local" dr="+" ac="O" tr="TCP|184.108.40.206|25|220.127.116.11|33469" ap="SMTP"/ Header (he) entries have the following attributes: ts - time stamp (always present, also used in en entries) no - node name (present if LOG_NODE=1, also used in en entries) pi - process id (present if LOG_PROCESS=1, also used in en entries) va - header line value (always present) Here is a sample he entry: he ts="2004-12-08T00:38:31.41" pi="1074b3.61.281" va="Subject: foo"/ (158b) Added list authorization policy values SMTP_AUTH_USED and AUTH_USED. These are similar in effect to the old SMTP_AUTH_REQUIRED and AUTH_REQ but unlike the old values do not require posters to authenticate. (159) Sieve errors are now logged as such in mail.log when LOG_FILTER is enabled. (160) The ALLOW_TRANSACTION_PER_SESSION limit kicked in one transaction too early; it now allows the specified number of transaction instead of one less. (161) The type of transport protocol in use (SMTP/ESMTP/LMTP) is now logged and made available to the various access mappings. In particular, two new modifier characters have been added to the set that can appear after an action indicator in the mail.log* files: E - An EHLO command was issued/accepted and therefore ESMTP was used L - LMTP was used Previously the only modifier characters that would appears were A (SASL authentication used) and S (TLS/SSL used). Additionally, the $E and $L flags respectively will be set as appropriate for the various *_ACCESS mappings. (162) Wildcards are now allowed in the strings used to match verdicts returned by spam filters. (163) imsimta encode now supports three new switches: -disposition=VALUE Sets the content-disposition to the specified VALUE -parameters=NAME=VALUE Specifies one or more additional content-type parameters and their values -dparameters=NAME=VALUE Specifies one or more additional content-disposition parameters and their values (164) Bit 4 (value 16) of the DOMAIN_UPLEVEL MTA option is now used to control whether address reversal rewriting is: (1) Skipped if the address is a mailEquivalentAddress (bit clear) (2) Performed only if the address is a mailAlternateAddress (bit set) (165) A value "/" given as an [envelope_from] nonpositional alias parameter, as an errors to positional alias parameter, or as a value of the mgrpErrorsTo LDAP attribute is now interpreted as a request to revert to using the original envelope from address for the incoming message while retaining mailing list semantics. This can be useful for setting up mailing lists that report all forms of list errors to the original sender. (166) The Job controller directory sweep is now more sophisticated. Instead of reading all the files in the queue directory in the order in which they are found, it reads several channel queue directories at once. This makes for much more reasonable behaviour on startup, restart, and after max_messages has been exceeded. The number of directories to be read at once is controlled by the job controller option Rebuild_Parallel_Channel. This can take any value between 1 and 100. The default is 12. (167) The sieve interpreter now keeps track of whether a response message was generated by a notify or vacation action and logs this information as needed. (168) Add the option Rebuild_In_Order parameter to the job_controller. If this is set to a non zero value, then on startup the job controller adds previously untried (ZZ*) messages to the delivery queue in creation order. Previous (and default) behavior is to add the messages in the order in which they are found on disk. There is a cost associated with recreating the queues in order. (169) Some additional reasons why a requested vacation response isn't sent are now logged. (170) Add the command imsimta cache -change command. This command allows certain job controller parameters to be changed on the fly. The allowed formats of this command are: imsimta cache -change -global -debug=<integer> imsimta cache -change -global -max_messages=<integer> imsimta cache -change -channel_template=<name> master_job=<command> imsimta cache -change -channel_template=<name> slave_job=<command> imsimta cache -change -channel=<name> master_job=<command> imsimta cache -change -channel=<name> slave_job=<command> imsimta cache -change -channel=<name> thread_depth=<integer> imsimta cache -change -channel=<name> job_limit=<integer> Changing parameters for a channel template (e.g. tcp_*) changes that parameter for all channels derived from that template. (171) Add the command imsimta qm jobs. This command displays what messages are being processed by what jobs for what channels. Typical output might be: channel <channel name> job <pid> host <host name> host <host name> <count of hosts> HOSTS BEING PROCESSED BY JOB <pid> message <subdir/message name> message <subdir/message name> processed messages: <# messages sucessfully dequeued> failed processing attempts: <# messages reenqueued> <count of messages> MESSAGES BEING PROCESSED BY JOB <pid> <count of jobs> JOBS ACTIVE FOR CHANNEL foo <count of active channels> ACTIVE CHANNELS In the past they were only available to the various *_ACCESS mappings. E - Incoming connection used ESMTP/EHLO. L - Incoming connection used LMTP/LHLO. F - NOTIFY=FAILURES active for this recipient. S - NOTIFY=SUCCESSES active for this recipient. D - NOTIFY=DELAYS active for this recipient. A - SASL used to authenticate connection. T - SSL/TLS used to secure connection. (174) The buffer used for spamfilter verdict destination strings has been increased in size from 256 to 1024 characters. This was done to accomodate the much longer verdict destination strings that Brightmail 6.0 can return. (175) Two new values now have meaning for the various SPAMFILTERx_OPTIONAL MTA options: 3 and 4. A value of 3 causes spamfilter failures to accept the message but queue it to the reprocess chanel for later processing. A value of 4 does the same thing but also logs the spam filter temporary failure to syslog. (176) The ability to log the amouint of time a message has spent in the queue has been added to the MTA logging facility. A new option, LOG_QUEUE_TIME, enables this capability. Setting the option to 1 enables queue time logging, while the default value of 0 disables it. The queue time is logged as an integer value in seconds. It appears immediately after the application information string in non-XML format logs. The attribute name in XML formatted logs for this value is "qt". (177) Source channel switching based on user or domain settings is now possible. There are three new settings involved: (a) A new channel keyword userswitchchannel. This keyword must be present on the initial source channel for user channel switching to occur. (b) A new MTA option LDAP_DOMAIN_ATTR_SOURCE_CHANNEL that specifies the name of a domain-level attribute containing the name of the channel to switch to. (c) A new MTA option LDAP_SOURCE_CHANNEL that specified is the name of a user-level attribute containing the name of the channel to switch to. Additionally, the channel being switched to must be set to allow channel switches, that is, it cannot be marked with the noswitchchannel keyword. Switching is done based on information returned by rewriting the MAIL FROM address. Note that MAIL FROM addresses are easily forged so this functionality should be used with extreme care. (178) List expansion in the context of the mgrpallowedbroadcaster LDAP attribute now includes all the attributes used to store email addresses (normally mail, mailAlternateAddress, and mailEquivalentAddress). Previously only mail attributes were returned, making it impossible to send to lists restricted to their own members using alternate addresses. (179) The default for the GROUP_DN_TEMPLATE MTA option has been changed to ""ldap:///$A??sub?mail=*". It used to be ""ldap:///$A?mail?sub?mail=*". This change makes the change described in item 178 work correctly in the case of lists defined using DNs. a domain-level attribute containing the default mailhost for the domain. If set and the attribute is present on the domain the mailhost attribute is no longer required on user entries in the domain. This option currently has no default, but preferredmailhost is the logical attribute to use as long as some other, conflicting usage doesn't exist. (181) New channel keywords generatemessagehash, keepmessagehash, and deletemessagehash. Generatemessage will, if specified on a destination channel, cause a Message-hash: header field to be inserted into the message. Keepmessagehash will cause any existing Message-hash: field to be retained. Deletemessagehash will delete any existing Message-hash: field. Deletemessagehash is the default. The value placed in Message-Hash: fields is (obviously) a hash of the message. Several new MTA options control how the hash is generated: MESSAGE_HASH_ALGORITHM - The hash algorithm. Can be any of "md2", "md4", "md5" (the default), "sha1", "md128" (for RIPE-MD128), or "md160" (for RIPE-MD160). MESSAGE_HASH_FIELDS - Comma separated list of fields from the header to hash (in order). Any known header field can be specified. If this option is not specified it defaults to "message-id,from,to,cc,bcc, resent-message-id,resent-from,resent-to,resent-cc,resent-bcc, subject,content-id,content-type,content-description". (182) New MTA option UNIQUE_ID_TEMPLATE. This option specifies a template used to convert an address into a unique identifier. The template's substitution vocabulary is the same as that for delivery options. The resulting unique identifier is intended for use by message archiving tools. (183) Per-user aliasdetourhost is now possible through the following set of features: (a) Added a 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. (b) Added a 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. (c) Added a ALIASDETOURHOST_NULL_OPTIN MTA option. This is similar to SPAMFILTERx_NULL_OPTIN - it specifies a "special" value which if used in the optin attribute is treated as the same as the attribute being omitted. The default valueis "", which means that an empty attribute value is ignored. (184) Support for a new IP_ACCESS table has been added. This access mapping is consulted during SMTP client operations just prior to attempting to open connections to a remote server. The mapping probe has the following format: source-channel|address-count|address-current|ip-current|hostname source-channel is the channel the message is being dequeued from, address-count is the total number of IP addresses for the remote server, address-current is the index of the current ip address being tried, ip-current is the current IP address, and hostname is the symbolic name of the remote server. The mapping can set the following flags: $N - Immediately reject the message with an "invalid host/domain error" Any supplied text will be logged as the reason for rejection but will not be included in the DSN. $I - Skip the current IP without attempting to connect. $A - Replace the current IP address with the mapping result. (185) The ACCESS_ORCPT MTA option has been changed from a simple boolean (0 or 1) to a bit-encoded value. Bit 0 (value 1) has the same effect it always had: It enables the addition of the ORCPT to all the various access mappings. Bits 1-4 (values 2-16), if set, selectivey enable the addition to the ORIG_SEND_ACCESS, SEND_ACCESS, ORIG_MAIL_ACCESS, and MAIL_ACCESS mappings respectively. (186) The new ACCESS_COUNTS MTA option provides a way to get at various types of recipient count information in the various recipient *_ACCESS mappings. ACCESS_COUNTS is bit-encoded in the same way as ACCESS_ORCPT now is (see the previous item for specifics) and if set enables the addition of a set of counts to the end of the access mapping probe string. Currently the format of the count addition is: RCPT-TO-count/total-recipient-count/ Note the trailing slash. It is expected that additional counter information will be added to this field in the future; all mappings making use of this information should be coded to ignore anything following the (current) last slash or they may break without warning. (187) Support for SMTP chunking (RFC 3030) has been added to both the SMTP client and server. This support is enabled by default. Four new channel keywords can be used to control whether or not chunking is allowed. They are chunkingclient - Enable client chunking support (default) chunkingserver - Enable server chunking support (default) nochunkingclient - Disable client chunking support nochunkingserver - DIsable server chunking support The log file action field has been extended to indicate whether or not chunking was used to transfer a given message. Specifically, a C will be appended if chunking is used. Note that ESMTP has to be used for chunking to work, so you'll typically see field values like "EEC" or "DEC". (188) Support has been added for a new caption channel keyword. This keyword is similar to the existing description channel keyword in that it takes a quoted string as an argument that is intended for use in channel displays. The difference is presumably that a "caption" is short than a "description". JES MF appears to need both. (189) A new utility routine has been written to verify domain-level Schema 1 and 2 information in the directory. This utilty routine is accessible to user through a new verify command in the imsimta test -domain program: % imsimta test -domain DOMAIN_MAP> verify Various checks are done by this utility, but the most important by far is verification of canonical domain settings for domains with overlapping user entries. The verification utility can return the following fatal errors: %DMAP-F-CANTGETDN, Cannot obtain DN of domain entry, directory error %DMAP-F-INTDEFERROR, Internal defined flag error on domain '%.*s', aborting %DMAP-F-INTHASHERROR, Internal hash error, aborting %DMAP-F-INTTREESTRUCTERROR, Internal tree structure error, aborting These are all indicative of an internal error in the verification code and should never occur. The following domain errors can be reported: %DMAP-E-ALIASTOOLONG, Domain alias '%s' in entry with DN '%s' is too long %DMAP-E-BASEDNTOOLONG, Base DN pointer '%s' in entry for domain '%.*s' is too long %DMAP-E-CANONICAL, Overlapping domains '%.*s' and '%.*s' defined by entries '%.*s' and '%.*s' have different canonical domains '%.*s' and '%.*s' %DMAP-E-CANONICALINVALID, Canonical domain '%.*s' defined/referenced by domain entry with DN '%.*s' is syntactically invalid %DMAP-E-CANONICALTOOLONG, Canonical name '%s' in entry for domain '%.*s' is too long %DMAP-E-CANTCONVDCDN, Cannot convert DN '%s' in DC tree to domain name %DMAP-E-CANTEXTALIAS, Empty alias pointer attribute in '%.*s' domain alias entry %DMAP-E-DOMAININVALID, Domain name '%.*s' defined/referenced by domain entry with DN '%.*s' is syntactically invalid %DMAP-E-DOMAINMULTDEF, Domain '%s' multiply defined by entries with DNs '%s' and '%s' %DMAP-E-DOMAINTOOLONG, Domain '%s' in entry with DN '%s' is too long %DMAP-E-DOMAINUNDEF, Domain name '%.*s' referenced by domain entry with DN '%.*s' never defined %DMAP-E-EMPTYCANONICAL, Domain '%.*s' has an empty canonical name %DMAP-E-INVALIDBASEDN, Base DN pointer '%.*s' in entry for domain '%.*s' is not a valid DN %DMAP-E-MULTICANONICAL, Multivalued canonical name in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-E-NOBASEDN, Domain '%.*s' has no base DN %DMAP-E-EMPTYBASEDN, Domain '%.*s' has an empty base DN %DMAP-E-NODOMAINNAME, Domain entry with DN '%s' does not have a domain name The following warnings can be reported: %DMAP-W-DISALLLOWEDATTR, Domain '%.*s' has a disallowed attribute '%s' with value '%s' %DMAP-W-DNTOOLONG, Domain entry DN '%s' is too long %DMAP-W-EMPAPPSTAT, Domain '%.*s' has an empty application status %DMAP-W-EMPDISALLLOWED, Domain '%.*s' has an empty disallowed attribute '%s' %DMAP-W-EMPDOMSTAT, Domain '%.*s' has an empty domain status %DMAP-W-EMPUIDSEP, Domain '%.*s' has an empty UID separator %DMAP-W-INVALIDAPPSTAT, Application status '%s' for domain '%.*s' is invalid %DMAP-W-INVALIDDOMSTAT, Domain status '%s' for domain '%.*s' is invalid %DMAP-W-INVALIDUIDSEP, UID separator '%s' for domain '%.*s' is invalid %DMAP-W-MULTDOMAINNAMES, Domain entry with DN '%s' has multiple domain names, used value '%s' ignored '%s' %DMAP-W-MULTIAPPSTAT, Multivalued application status in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-W-MULTIBASEDN, Multivalued base DN pointer in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-W-MULTIDOMSTAT, Multivalued domain status in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-W-MULTIUIDSEP, Multivalued UID separator in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-W-MULTIVALIAS, Multivalued alias pointer in entry for domain alias '%.*s', used value '%s' ignored '%s' %DMAP-W-NOBASEDNNODE, Base DN pointer '%.*s' in entry for domain '%.*s' doesn't point at anything %DMAP-W-NODOMAINNAME, Domain entry with DN '%s' has a blank domain alias %DMAP-W-NOENTRIES, No domain entries found, aborting Additional messages will undoubtedly be added to this list over time. (190) The ability to generate :addresses arguments to sieve vacation via an LDAP autoeply attribute has been added to Messaging Server. The new MTA option LDAP_AUTOREPLY_ADDRESSES provides the name of the attribute to use. This option has no value by default. The attribute can be multivalued, with each value specifying a separate address to pass to the :addresses vacation parameter. (191) The new LDAP_DOMAIN_ATTR_CATCHALL_MAPPING can now be used to specify the name of a LDAP domain attribute. This option is not set by default. If set the option specifies the name of a mapping which is consulted when an address associated with the domain fails to match any user entries. The format of the mapping probe is the same as that of the forward mapping, and the USE_FORWARD_DATABASE MTA option controls the format of the probe of this mapping in the same way as the forward mapping. If the mapping sets the $Y metacharacter the resulting string will replace the address being processed. (192) The MTA now fetches the block limit associated with the envelope return address and will set RET=HDRS if no return policy is specified and the message size exceeds the block limit. This prevents nondelivery reports for large messages from being undeliverable themselves. No new options or settings are associated with this change. (193) The $E metacharacter in a mapping template means "exit after processing the current template". There are cases where it is desireable to exit immediately without interpreting the rest of the template. The $+1E metacharacter sequence now produces this behavior. (194) Use of POP-before-SMTP via the MMP is now indicated in mail.log E records by the addition of a "P" to the action code. (195) Use of POP-before-SMTP can now be checked in the various *_ACCESS mappings (except PORT_ACCESS, which occurs before the necessary information has been communicated to the server), the FORWARD mapping, and any domain catchall mapping. The $P metacharacter flag is set if POP-before-SMTP is used. (196) The restriction that the same attribute cannot be assigned to multiple "slots" and hence can have multiple semantics during alias expansion and address reversal. (197) The internal separator character used to delimit multiple subject line tag additions has been changed from space to vertical bar. This makes it possible to add a tag containing spaces, as some spam filters want to do. This change effectively prevents vertical bars from being used in tags, but such usage is almost certainly nonexistant. (198) The MIME specification prohibits the use of a content-transfer-encoding other than 7bit, 8bit, and binary on multipart or message/rfc822 parts. It has long been the case that some agents violate the specification and encode multiparts and message/rfc822 objects. Accordingly, the Messaging Server MTA has code to accept such encodings and remove them. However, recently a different standards violation has shown up, one where a CTE field is present with a value of quoted-printable or base63 but the part isn't actually encoded! If the MTA tries to decode such a message the result is typically a blank messages, which is pretty much what you'd expect. Messages with this problem have become sufficiently prevalent that two new pairs of channel keywords have been added to deal with the problem - interpretation of content-transfer-encoding fields on multiparts and message/rfc822 parts can be enabled or disabled. The first pair is interpretmultipartencoding and ignoremultipartencoding and the second is interpretmessageencoding and ignoremessageencoding. The defaults are interpretmultipartencoding and interpretmessageencoding. (199) Several additional error messages the SMTP server either returns or places in DSNs have been made configurable. The new options and their default values are: ERROR_TEXT_MAILFROMDNSVERIFY invalid/host-not-in-DNS return address not allowed ERROR_TEXT_INVALID_RETURN_ADDRESS invalid/unroutable return address not allowed" ERROR_TEXT_UNKNOWN_RETURN_ADDRESS invalid/no-such-user return address ERROR_TEXT_ACCEPTED_RETURN_ADDRESS return address invalid/unroutable but accepted anyway ERROR_TEXT_SOURCE_SIEVE_ACCESS source channel sieve filter access error ERROR_TEXT_SOURCE_SIEVE_SYNTAX source channel sieve filter syntax error: ERROR_TEXT_SOURCE_SIEVE_AUTHORIZATION source channel sieve filter authorization error ERROR_TEXT_TRANSACTION_LIMIT_EXCEEDED number of transactions exceeds allowed maximum" ERROR_TEXT_INSUFFICIENT_QUEUE_SPACE insufficient free queue space available ERROR_TEXT_TEMPORARY_WRITE_ERROR error writing message temporary file ERROR_TEXT_SMTP_LINES_TOO_LONG lines longer than SMTP allows encountered; message rejected ERROR_TEXT_UNNEGOTIATED_EIGHTBIT message contains unnegotiated 8bit (200) We're seeing cases of overly agressive SMTP servers which will issue a "5xy bad recipient" response to the first RCPT TO and then disconnect immediately. (This is of course a flagrant standards violation.) The problem is Messaging Server treats this as a temporary error (which of course it is) and tries later, only to get the same result. A better thing to do which works around this server bug is to handle the one recipient as bad and requeue any remaining recipients for a later retry. (201) Two new actions are availabile to system sieves: addconversiontag and setconversiontag. Both accept a single argument: A string or list of conversion tags. Addconversiontag adds the conversion tag(s) to the current list of tags while setconversiontag empties the existing list before adding the new ones. Note that these actions are performed very late in the game so setconversiontag can be used to undo all other conversion tag setting mechanisms. (202) A new MTA option, INCLUDE_CONVERSIONTAG, has been added to selectively enable the inclusion of conversion tag information in various mapping probes. This is a bit-encoded value. The bits are assigned as follows: pos value mapping 0 1 CHARSET_CONVERSIOn - added as ;TAG= field before ;CONVERT 1 2 CONVERSION - added as ;TAG= field before ;CONVERT 2 4 FORWARD - added just before current address (| delim) 3 8 ORIG_SEND_ACCESS - added at end of probe (| delim) 4 16 SEND_ACCESS - added at end of probe (| delim) 5 32 ORIG_MAIL_ACCESS - added at end of probe (| delim) 6 64 MAIL_ACCESS - added at end of probe (| delim) In all cases the current set of tags appears in the probe as a comma separated list. (203) The sieve envelope test now accepts "conversiontag" as an envelope field specifier value. The test checks the current list of tags, one at a time. Note that the :count modifier, if specified, allows checking of the number of active conversion tags. This type of envelope test is restricted to system sieves. Also note that this test only "sees" the set of tags that were present prior to sieve processing - the effects of setconversiontag and addconversiontag actions are not visible. (204) Trailing dots on domains, e.g. "foo@bar.", are illegal in email but have been tolerated in some contexts by Messaging Server for a long time. RFC 1123 points out that trailing dots are syntactically illegal in email but notes that some convention needs to exist in user interfaces where short form names can be used. Accordingly, it may be handy in contexts like SMTP submission to be able to accept addresses with trailing dots, remove the dot while attaching special semantics to its presence. Accordingly, Messaging Server has modified in two ways: (1) Trailing dots are now accepted by the low-level address parser, making it possible to use them in context where they could not previously be used, like addresses inside of group constructs. (2) Trailing dots, when specified will cause a rewrite of the address with a trailing dot. If the rewrite with a trailing dot isn't found or otherwise fails rewriting will continue as before without the trailing dot. (205) Metacharacter substitutions can now be specified in mgrpModerator, mgrpAllowedBroadcaster and mgrpDisallowedBroadcaster attributes. In particular, the various address-related metacharacter sequences ($A for the entire address, $U for the mailbox part, $D for the domain part) refer to the current envelope from address and can in some cases be used to limit the results returned by the URL to entries that are likely (or guaranteed) to match. This may make authorization checks much more efficient. The new MTA option PROCESS_SUBSTITUTIONS controls whether or not substitutions are performed in various LDAP attributes that specify a URL. This is a bit-encoded value, with the bits defined as follows: Bit Value 0 1 Enables substitutions in mgrpDisallowedBroadcaster if set 1 2 Enables substitutions in mgrpAllowedBroadcaster if set 2 4 Enables substitutions in mgrpModerator if set 3 8 Enables substitutions in mgrpDeliverTo if set 4 16 Enables substitutions in memberURL The PROCESS_SUBSTITUTIONS MTA option defaults to 0, meaning that all of these substitutions are disabled by default. Note that the information available for substitution varies depending on whether the attribute is used for authorization checks or for actual list expansion. For authorization attributes the whole address ($A), domain ($D), host ($H), and local-part ($L) are all derived from the authenticated sender address. In the case of list expansion attributes all of these substitution values are derived from the envelope recipient address that specified the list. In both cases, however, the subaddress substitution ($S) is derived from the current envelope recipient address. The ability to access subaddress information in list expansion URLs makes it possible to define "metagroups", that is, a single group entry that in effect creates an entire collection of different groups. For example, a group with a mgrpDeliverTo value of: ldap:///o=usergroup?mail?sub?(department=$S) would make it possible to send mail to every member of a given department with an address of the form firstname.lastname@example.com. Note that a mechanism like a forward mapping could be used to alter the syntax if subaddresses are seen as too difficult. 206) New MTA option LDAP_DOMAIN_ATTR_UPLEVEL. This option specifies the name of a domain-level attribute used to store a domain-specific uplevel value which overrides the value of the DOMAIN_UPLEVEL MTA option for this one domain. Note that this attribute is only consulted if the domain is looked up. This means that setting bit 0 of this value to 1 for a domain won't make subdomains of the domain match unless bit 0 of DOMAIN_UPLEVEL is also set. As such, the way to get subdomain matching for some domains but not others is to set bit 0 of DOMAIN_UPLEVEL (this enabling subdomain matches for all domains) then clear bit 0 of the attribute for the domains where you don't want uplevel matching to occur. (207) Rewrite rules can now be used to override the default ALIAS_MAGIC setting. Specifically, a construct of the form $nT, where n is an appropriate value for the ALIAS_MAGIC MTA option, overrides the setting for the domain when the rule matches during alias expansion. ((208) $U in a PORT_ACCESS mapping template can now be used to selectively enable channel level debugging. (209) In 6.2 and earlier the PORT_ACCESS mapping was only reevaluated by the SMTP server (as opposed to the dispatcher) when bit 4 (value 16) of the LOG_CONNECTION MTA option is set, SMTP auth is enabled, or both. Additionally, evaluation only occurred when an AUTH, EHLO, or HELO command was issued. This has now been changed; PORT_ACCESS is now evaluated unconditionally as soon as the SMTP server thread starts, before the banner is sent. PORT_ACCESS may be reevaluated with different transport information when proxying from the MMP is used. (210) A useful spam-fighting strategy is to delay sending the SMTP banner for a brief time (half a second, say), then clear the input buffer, and finally send the banner. The reason this works is that many spam clients are not standards-compliant and start blasting SMTP commands as soon as the connection is open. Spam clients that do this when this capability is enabled will lose the first few commands in the SMTP dialogue, rendering the remainder of the dialogue invalid. This feature has now been implemented in Messaging Server. It can be enabled unconditionally by setting the BANNER_PURGE_DELAY SMTP channel option to the number of centiseconds to delay before purging and sending the banner. A value of 0 disabled both the delay and purge. The PORT_ACCESS mapping can also be used to control this capability. Specifying $D in the template causes an additional argument to be read from the template result, after the mandatory SMTP auth rulset and realm and optional application info addition. This value must be an integer with the same semantics as the BANNER_PURGE_DELAY value. Note that any PORT_ACCESS mapping setting overrides the BANNER_PURGE_DELAY SMTP channel option. (211) Added channel keywords acceptalladdresses and acceptvalidaddresses. Keyword acceptvalidaddresses is the default and corresponds to the MTA's standard behavior where any recipient errors are reported immediately during the SMTP dialogue. If the keyword acceptalladdresses is specified on a channel, then all recipient addresses are accepted during the SMTP dialogue. Any invalid addresses will have a DSN sent later. (212) Support has been added for postprocessing LDAP expansion results with a mapping. The new LDAP_URL_RESULT_MAPPING MTA option can be used to specify the name of a group attribute which in turn specifies the name of a mapping. This mapping will be applied to any results returned by expanding either a mgrpDeliverTo or memberURL attribute. The mapping probe will be of the form: LDAP-URL|LDAP-result If the mapping returns with $Y set the mapping result string will replace the LDAP result for alias processing purposes. If the mapping returns with $N set the result will be skipped. This mechanism can be used to define groups based on attributes that don't contain proper email address. For example, suppose a company has placed pager numbers in all their user entries. Messages can be sent to these numbers via email by suffixing them with a particular domain. A group could then be defined as follows: (a) Define a new mgrpURLResultMapping attribute in the directory and set the LDAP_URL_RESULT_MAPPING MTA option to this attribute's name. (b) Define a page-all group with the following attributes: mgrpDeliverto: ldap:///o=usergroup?pagerTelephoneNumber?sub mgrpURLResultMapping: PAGER-NUMBER-TO-ADDRESS (c) Define the mapping: PAGER-NUMBER-TO-ADDRESS *|* "$1"@pagerdomain.com$Y Even more interesting effects can be acheived by combining this mechanism with the PROCESS_SUBSTITUTION mechanism described in item 205 above. For example, it would be easy to create a metagroup where sending to an address of the form email@example.com sends a page to the user named "user". (213) Setting the LOG_QUEUE_TIME MTA option to 1 now causes an additional field to be selectively written to connection log records. This new field appears immediately after any diagnostic information and is labelled as "ct" in the XML-based log format. The value of this field is an integer count of the number of seconds that elapsed when performing the operation. So, for connection open ("O") records, the time shown is the number of seconds needed to open the connection. For connection close ("C") records it indicates the number of seconds the connection was open. For connection failure records ("Y") the value indicates the amount of time that was spent attempting to open the connection. (214) "S" transaction log entries now increment the various submitted message counters associated with the channel. (215) The $( metacharacter in a FROM_ACCESS specifies that an address should be read from the result string and used to replace the current overriding postmaster address. $) has the same effect with the added constraint that the overriding postmaster address must not be set prior to invoking the mapping. This allows for specific postmaster addresses to be used with addresses in nonlocal domains - domain postmaster addresses by definition only work with locally defined domains. The override address is (currently) the last string read from the FROM_ACCESS result prior to reading any $N/$F failure result. (216) The capture sieve action now has two optional nonpositional parameter: :dsn and :message. Only one of these can be specified in a single capture action. :dsn is the default, and encapsulates the captured message inside a special type of DSN. :message eliminates the enacapsulation and behaves more like a redirect. But unlike redirect, capture :message is only available to system sieves, always takes effect even when a more specific sieve specifies some other sort of action, and the envelope from address will be overridden with the address of the sieve owner. (217) The MTA now checks to make sure the UID attribute has a single value and reports an alias expansion error if it does not. The UID attribute is required to be single-valued in order to insure the user has a single, unique mailbox. (218) Two additional MTA options have been added to support more efficient domain lookups from user base DNs. They are: LDAP_BASEDN_FILTER_SCHEMA1 String specifying filter used to identify Schema 1 domains when performing baseDN searches. Default is the value of LDAP_DOMAIN_FILTER_SCHEMA1 if that MTA option is specified. If neither option is specified the default is "(objectclass=inetDomain)". LDAP_BASEDN_FILTER_SCHEMA2 String specifying additional filter elements used to identify Schema 2 domains when performing baseDN searches. Default is the value of LDAP_DOMAIN_FILTER_SCHEMA2 if that MTA option is specified. If neither option is specified the default is an empty string. (219) A new MTA option MESSAGE_SAVE_COPY_FLAGS has been added to control how the probes are constructed for the MESSAGE-SAVE-COPY mapping. If bit 0 (value 1) is set it adds the transport and application information to the beginning of the probe, if bit 1 (value 2) is set the original source channel is added, if bit 2 (value 4) is set the most recent conversion tag string is added. If all three bits are set the overall probe format is: transport|orig-source-channel|conversion-tags|queue-channel|return-address|D|filename (220) The LDAP_OPTIN1 through LDAP_OPTIN8 MTA options specify attributes for per-user optins to spam filtering based on destination addresses. There are now 8 new MTA options, LDAP_SOURCE_OPTIN1 through LDAP_SOURCE_OPTIN8, that provide comparable originator-address-based per-user spam filter optins. (221) Some additional switches have been added to imsimta test -rewrite: -saslused - Set internal flag indicating SASL authentication was used -tlsused - Set internal flag indication TLS is in use -esmtpused - Set internal flag indicating ESMTP is in use -lmtpused - Set internal flag indicating LMTP is in use -proxyused - Set internal flag indicating proxy authentication was used Only -saslused and -tlsused are available in 6.2; the other depend on other changes made in 6.3 and hence cannot be implemented in earlier versions. -lmtpused and -esmtpused cannot be set at the same time. -proxyused requires that -esmtpused or -lmtpused also be set. (222) New LMTP channel option MAILBOX_BUSY_FAST_RETRY. If set to 1 (the default) a 4.2.1 Mailbox busy error in response to LMTP message data is handled by retrying the message after a random but short interval; normal message backoff values do not apply. Setting the option to 0 disables this behavior.
Support for the following features may be eliminated in a future release or have already been removed in this release:
Going forward, no new features will be added to the Messenger Express and Calendar Express user interfaces. They have been deprecated in favor of the new Communications Express user interface. Both Messenger Express and Calendar Express will be removed from the product in the next major release.
This deprecation also includes the deprecation of the Messenger Express Mail Filter User Interface (msg-svr-base /SUNWmsgmf/MailFilter.war ).
The following bugs affect the deprecated Messenger Express product:
The Up and Down buttons removed.
The Up and Down buttons used to specify the ordering of your filters have been removed.
Problems may be seen in Messenger Express on Internet Explorer 6 when proxy server setting is used.
Workaround: Enable or disable "auto-detection" option in Internet Explorer's encoding menu. Use direct connection or switch to different proxy server.
Feature removed from the Advanced Mail Filter Conditions window.
The ability to specify a time frame for your filters has been removed from the Advanced Mail Filter Conditions window (of the Mail Filters user interface) for the Messaging Server 6.0 Patch 1 release. The feature was removed because the underlying support is not available.
If you create groups within an existing group, you may encounter the following error: pab::PAB_ModifyAttribute: ldap error (No Such object).
Localized Messenger Express does not merge some of the folders created by Outlook Express.
It is sometimes desired that the default "Sent" folder in Messenger Express be replaced by the "Sent Items" folder created by Outlook Express, hence all the messages sent by both client are copied to the "Sent Items" folder. This does not work with Japanese localization.
With Directory Server 5.1 or later, you will not be able to enter multiple email IDs for a single contact in the Personal Address Book.
Directory Server is exhibiting correct behavior. Due to a problem in Netscape Directory Server 4.x, you are able to enter multiple email IDs.
The Sun Java System Administration Console has been removed from the Messaging Server product.
Administration functions should be performed through the Messaging Server command-line interfaces or configuration files. References in the documentation to using the console haven't yet been corrected.
When clients connect via IMAP, POP or SMTP to the Messaging Server, they must use a SASL (RFC 2222) authentication mechanism or a simple password to prove their identity to the server. When the LDAP directory is configured to store user passwords in the clear, all user passwords are migrated to this format and the sasl.default.ldap.has_ plain_passwords option is set on the Messaging Server, then three additional authentication mechanisms are enabled: APOP, CRAM-MD5 and DIGEST-MD5. All three of these mechanisms transmit a one-way encoding of the password over the wire rather than the password itself. Due to its limited deployment and complexity, the DIGEST-MD5 mechanism is deprecated leaving only the APOP and CRAM-MD5 mechanisms.
The LMTP native channel has been deprecated and will be removed in a future release.
The Messenger Express Multiplexor has been removed in favor of the Webmail Server. See: Webmail Server Supports IMAP.
This command has been deprecated. Use imsimta cnbuild in Sun Java System Messaging Server 6.3 Administration Reference and imsimta restart in Sun Java System Messaging Server 6.3 Administration Reference instead, as appropriate.
New start-msg and stop-msg commands have replaced imsimta start and imsimta stop, which are deprecated and will be removed in a future release.
See start-msg in Sun Java System Messaging Server 6.3 Administration Reference and stop-msg in Sun Java System Messaging Server 6.3 Administration Reference for more information.
The optional SECTION option for the INSTANCENAME option of the ServiceList MMP configuration parameter is deprecated and will be removed in a future release.
MTA access to database files and the imsimta tools to manipulate MTA database files are deprecated.
Netscape browser support will be removed at a future date.
Red Hat Linux 3 platform support has been deprecated in this release and be removed in a future release. Communications Suite 5 continues to be supported on Red Hat Linux 4.
In this release, there are two notification services for event notifications and alarms: Sun Java System Message Queue (JMQ) and Event Notification Service (ENS). In a future release, the Communications Suite products will use JMQ exclusively and ENS will be deprecated. However, for this release, Messaging Server, Calendar Server, and Instant Messaging still have internal dependencies to ENS; therefore, you can continue to use ENS.
For this release, the Messaging Server IMAP IDLE feature requires the use of ENS. Messaging Server has no other dependencies on ENS. If you do not use IMAP IDLE, you can use JMQ exclusively for event notifications.
If you want to use IMAP IDLE, you must configure an ENS notification plug-in. You can also use JMQ for message notifications by configuring a JMQ notification plug-in. (Messaging Server allows you to configure multiple notification plug-ins.
The configutil parameters listed in Table 3–2 are obsolete and have been removed from the Messaging Server product.
If Messaging Server is upgraded from an earlier release to Messaging Server 6.3, the parameters listed in Table 3–2 are deleted from the configuration after upgrade. Before upgrading, Sun recommends that you save the configutil output to a file.
Removed in Messaging Server 6.0. No replacement.
Use local.ssldbpath and local.ssldbprefix instead.
Use local.ssldbpath and local.ssldbprefix instead.
No longer relevant with SSL v2 support obsoleted (as of Messaging Server 6.0).
No longer relevant with SSL v2 support obsoleted (as of Messaging Server 6.0).
No longer relevant with SSL v2 support obsoleted (as of Messaging Server 6.0). SSL v3 is now always enabled.
Removed in Messaging Server 6.0. No replacement.
Removed in Messaging Server 6.0. Use service.*.sessiontimeout instead.
Removed in Messaging Server 6.0. SSL now always asks for client cert if there is a valid certmap.conf and a valid CA for client certs in the cert database.
Removed in Messaging Server 6.0. Use service.*.sessiontimeout instead.
Removed in Messaging Server 6.0. No replacement.
Removed in Messaging Server 6.0. Use encryption.rsa.nssslpersonalityssl and local.*.sslnicknames instead. The token name can be provided as a prefix to the SSL nickname: for example, token-name:nick-name .
Never used.
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
Removed in Messaging Server 6.2. Use alarm.serverresponse.msgalarmstatinterval instead.
Never used. SSO will be enabled so long as local.webmail.sso.amnamingurl and related parameters are defined.
Use local.enduseradmincred instead.
Use local.enduseradmindn instead.
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
Use the LDAP_TIMEOUT MTA option instead.
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
Use the LOG_MESSAGES_SYSLOG MTA option instead.
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
No longer relevant with dirsync obsoleted (as of Messaging Server 6.0).
Use the DOMAIN_MATCH_URL MTA option instead.
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
Removed in Messaging Server 6.2. No replacement.
No longer necessary.
MEM is obsoleted now that webmail communicates with the store via IMAP (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
Use local.snmp.servertimeout instead.
Use local.schedule.expire instead.
Use local.store.maxlog instead.
Use local.store.notifyplugin.*.deletemsg.enable instead.
Use local.store.notifyplugin.*.debuglevel instead.
Use local.store.notifyplugin.*.maxbodysize instead.
Use local.store.notifyplugin.*.maxheadersize instead.
Use local.store.notifyplugin.*.jmqhost instead.
Use local.store.notifyplugin.*.jmqport instead.
Use local.store.notifyplugin.*.jmqpwd instead.
Use local.store.notifyplugin.*.jmqtopic instead.
Use local.store.notifyplugin.*.jmquser instead.
Use local.store.notifyplugin.*.loguser.enable instead.
Use local.store.notifyplugin.*.newmsg.enable instead.
Use local.store.notifyplugin.*.noneinbox.enable instead.
Use local.store.notifyplugin.*.purgemsg.enable instead.
Use local.store.notifyplugin.*.readmsg.enable instead.
Use local.store.notifyplugin.*.updatemsg.enable instead.
Never used.
Never used.
Use sasl.default.ldap.has_plain_passwords instead.
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
Use local.webmail.cert.enable instead.
Use local.webmail.cert.port instead.
Use local.service.http.ims5compat if necessary.
Calendar Server parameter. Not used in Messaging Server.
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
No longer relevant with Administration Server obsoleted (as of Messaging Server 6.3).
Use sasl.default.auto_transition instead.
Use the LDAP attribute mailAllowedServiceAccess instead.
Use the LDAP attribute mailAllowedServiceAccess instead.
Removed in Messaging Server 5.2p2. Use service.experimentalldapmemcache instead.
Removed in Messaging Server 5.0. No replacement.
Removed in SIMS 4.0. No replacement.
Removed when Administration Server obsoleted (as of Messaging Server 6.3). Use msgcert to manage certificate database instead.
Use local.ssldbpath and local.ssldbprefix instead.
Use local.ssldbpath and local.ssldbprefix instead.
Use local.ssldbpath and local.ssldbprefix instead.
Use msgcert request-cert instead.
Use local.store.*synclevel instead.
Use local.schedule.expire instead.
This section describes the following platform, client product, and additional software requirements for this release of Messaging Server:
Product Version Compatibility Requirements for Calendar Server 6.3.
For information about upgrading to Messaging Server 6.3 from a previous version of Messaging Server, see Messaging Server Installation Notes.
For the most current list of required patches for Sun Java System Messaging Server go to http://sunsolve.sun.com and select either "Patches" or "Patch Portal". As operating system patch requirements change and patches to Java Enterprise System components become available, updates will be made available on SunSolve, initially in the form of recommended patch clusters.
At the time of general release of the Sun Java Communications Suite 5, the following Messaging Server 6.3 upgrade patches are available:
Patch Number (English)
Patch Number (Localized Languages)
Solaris, SPARC
This release supports the following platforms:
Solaris 9 Operating System Update 2 (SPARC® and x86 Platform Editions) with required patches
Solaris 10 Operating System (SPARC and x86 Platform Editions) including Zones Support
Red Hat Enterprise Linux Advanced Server (32– and 64–bit versions), versions 3 (all updates) and 4 (all updates). See Deprecated and Removed Features for Messaging Server
Red Hat Enterprise Linux Enterprise Server (32– and 64–bit versions), versions 3 (all updates) and 4 (all updates)
Messaging Server is no longer supported on HP-UX or Windows platforms.
For detailed information about Solaris and Linux requirements, including required upgrade patches and kernel versions, see theSun Java Communications Suite 5 Installation Guide.
For a list of the Messaging Server packages, see Appendix E, Product Components for This Release, in Sun Java Communications Suite 5 Installation Guide.
The installer checks for required platform patches. You must install all required patches or the installation process will not continue.
The performance of your messaging server depends on many factors, including CPU power, available memory, disk space, file system performance, usage patterns, network bandwidth, and so on. For example, throughput is directly related to file system performance. If you have questions about sizing and performance, contact your Sun Java System representative.
Messaging Server is compatible with the product versions listed in this section:Table 3–3 Product Version Compatibility Requirements for Messaging Server
Sun Java System Directory Server
5.1, 5.2, 6.x
Sun Java System Message Queue
Sun Java System Access Manager (formerly called Identity Server)
Legacy(6.x): Supports Access Manager 6 features, including the Access Manager 6 Console and directory information tree (DIT). If you are installing Access Manager with Portal Server, Messaging Server, Calendar Server, Delegated Administrator, or Instant Messaging, you must select the Access Manager Compatible (6.x) installation type.
Realm (7.x): Supports Access Manager 7 features, including the new Access Manager 7 Console. Use the Enhanced (7.x) installation type only if you are not installing Portal Server, Messaging Server, Calendar Server, Delegated Administrator, or Instant Messaging.
Sun Java System Web Server
Sun Java System Application Server
Messaging Server 6.3 requires the use of the shared security component NSS version 3.9.3.
For more details about product version dependencies, see the Sun Java Enterprise System 5 Installation Guide for UNIX and Sun Java Enterprise System 5 Release Notes for UNIX
A high quality caching DNS server on the local network is a requirement for a production deployment of Messaging Server. Messaging Server depends heavily on the responsiveness and scalability of the DNS server.
Additionally, ensure in your setup that DNS is properly configured and that it is clearly specified how to route to hosts that are not on the local subnet:
The /etc/defaultrouter should contain the IP address of the gateway system. This address must be on a local subnet.
The /etc/resolv.conf exists and contains the proper entries for reachable DNS servers and domain suffixes.
In /etc/nsswitch.conf, the hosts: line has the files, dns and nis keywords added. The keyword files must precede dns and nis.
Make sure that the FQDN is the first host name in the /etc/hosts file.
If your Internet host table in your /etc/hosts file looks like:
18.104.22.168 budgie.west.sesta.com 184.108.40.206 budgie loghost mailhost
change it so that there is only one line for the IP address of the host. Be sure the first host name is a fully qualified domain name. For example:
18.104.22.168 budgie.west.sesta.com budgie loghost mailhost
Messaging Server can be run on the following versions of Sun Cluster and Veritas Cluster Server in a Solaris 9 or Solaris 10 environment:
Messaging Server 6.3 now supports Sun Cluster 3.2. However, note the following caveats: there is no new documentation for the new CLI introduced in Sun Cluster 3.2; Sun Cluster manuals provide examples to bridge the gap. In addition, the upgrade of Sun Cluster 3.1/Messaging Server 6.3 to Sun Cluster 3.2/Messaging Server 6.3 is currently not supported.
Supported Versions
Sun Cluster (SC)
x86: 3.1 Update 4, 3.2
Linux: Not Supported
Veritas Cluster Server (VCS)
x86: 3.5, 4.0. 4.1, 5.0
Linux: Not Supported
The following file systems are recommended for message stores:
LUFS (Logging UFS).
VxFS (Veritas File System). Veritas File System provides good system performance if configured properly. If you use VxVM, the Veritas Volume Manager, you need to carefully watch that the volumes and the log file for the volumes are set to be regularly striped.
HAStoragePlus File System for Sun Cluster installations. The HAStoragePlus File System provides better performance than the default Sun Cluster Global File System.
NFS (Network File System).
You can use NFS on MTA relay machines, for LMTP, for autoreply histories, for message defragmentation. (See the Sun Java System Messaging Server 6.3 Administration Guide. In addition, NFS can be supported on BSD-style mailboxes (/var/mail/ ) as well as for the Message Store. The following versions of NFS have been certified for use with Messaging Server: Sun StorEdge 5310 NAS Appliance.
These installation notes pertain to the Messaging Server 6.3 release:
Use the Communications Services installer to install Messaging Server.
For installation instructions, see the Sun Java Communications Suite 5 Installation Guide.
Next, you must configure Messaging Server by:
Running the Directory Server Preparation Tool, comm_dssetup.pl .
Running the Messaging Server configuration program.
For configuration instructions, see the Sun Java System Messaging Server 6.3 Administration Guide
The following changes were implemented in the latest version of comm_dssetup.pl , the program that prepares the directory server for Messaging Server use:
Silent Installation: password change
-w dirmanager_passwd has been deprecated in favor of -j passwd_file
See Messaging Server Compatibility Issues
for more changes to comm_dssetup.pl.
If you are upgrading to Messaging Server 6.3 from an earlier release, follow the upgrade instructions in the Sun Java Communications Suite 5 Upgrade Guide.
If you are installing Messaging Server for the first time or upgrading from an earlier version of Messaging Server, ensure that you have the following entry in /etc/hosts file on your Solaris system:
<ip-of system> <FQHN> <hostname>
For Example, 22.214.171.124 budgie.siroe.varrius.com budgie
On Solaris 10 platforms, you not only have to add the Fully Qualified Domain Name (FQDN) to the /etc/hosts file, but also to the /etc/inet/ipnodes file. Otherwise, you will get an error indicating that your host name is not a Fully Qualified Domain Name.
After upgrading Messaging Server, you must increase the number of file descriptors by setting the ulimit as follows:
ulimit -n number_of_file_descriptors
For example:
ulimit -n 100000
For more information about the upgrade procedure, see Sun Java Communications Suite 5 Upgrade Guide.
If you choose to use a Messaging Server 6.3 back-end with a Messaging Server 6 2005Q4 front-end, you need to configure the front end to run without an Administration Server as follows:
Install and configure the Messaging Server 6.3 back-end using the Communications Suite 5 installer.
Run the Java Enterprise System 2005Q4 installer to install the Messaging Server 6 2005Q4 front-end and choose the Configure Later option when prompted.
Open msg-svr-base/lib/config-templates/DevsetupDefaults.properties in a text editor.
Change the following line:
ADMINSERVER_SERVERROOT_CONF = /etc/mps/admin/v.5.2/shared/config/serverroot.conf
To purge users with iPlanet Delegated Administrator when you are running Messaging Server 6.3, see Purging Users with iPlanet Delegated Administrator and Messaging Server 6.3
The following table describes compatibility issues with Messaging Server:
comm_dssetup.pl, the program that prepares the directory server for Messaging Server (Calendar Server and Delegated Administrator) has been modified to work with both Directory Server 6.0 and Directory Server 5.x: Interactive Mode: Server-root and Directory Server Instances
Directory Server instance(s) reside in the server-root, or an explicit Directory Server instance directory Previous versions of Directory Server used the notion of a server-root where multiple instances and configuration info would be housed. Directory Server 6 no longer uses a server-root. Instances may be anywhere. In this question, a user needs to: 1) specify the instance directory. Or, if the user is using previous versions of Directory Server, the user can: 2) specify the server-root directory where the instances are housed. You will be prompted with an additional question to pick an instance from the server-root. Or, 3) a user who has used Directory Server 5x and is now using Directory Server 6 might manually put all of her Directory Server instances under a parent directory (what we used to call a server-root).
Note –
Server-root terminology has been removed from Directory Server 6.
no additional comments
comm_dssetup.pl, the program that prepares the directory server for Messaging Server (Calendar Server and Delegated Administrator) has been modified to work with both Directory Server 6.0 and Directory Server 5.x: Silent Installation: server-root directory
In previous versions of Silent installation, you would specify both a server-root and an instance directory. If you are using Directory Server 5.x, this still holds true. Since there is no server-root directory in Directory Server 6.0, you will need to specify the parent directory of the Directory Server instance.
no additional comments
The location of the Directory Preparation Tool (comm_dssetup.pl) has changed.
comm_dssetup.pl is now in its own package installed in /opt/SUNcomds for Solaris, and /opt/sun/comms/dssetup for Linux
Existing scripts that specify the old path need to be updated.
To install the package, be sure the Directory Preparation Tool is selected in the appropriate installer panel.
In Messaging Server 5.x, an administrator could use the IMAP list command to display all folders in the message store. In a typical message store, this caused the server to display an unusually long list.
In Messaging Server 6.x, when an administrator runs the IMAP list command, it displays only the explicitly shared folders.
To list all folders in the message store, use the mboxutil utility.
For more information on the mboxutil utility, see the Sun Java System Messaging Server 6.3 Administration Guide.
The configuration program for the Delegated Administrator has changed.
Install Delegated Administrator and run the configuration program. The current program is located at:
for Solaris, /opt/SUNWcomm/sbin/config-commda
for Linux /opt/sun/comms/config-commda
Upgrade to the new Delegated Administrator when installing this version of Messaging Server.
Upgrading Messaging Server with Webmail over IMAP protocol change (6397425, 6397451, 2137362)
The back-end server must be upgraded before upgrading the front-end server. Both the Webmail over IMAP protocol as well as the back-end message stores must be the same product version. See the Sun Java Communications Suite 5 Upgrade Guide for details.
no additional comments
This release of Communications Express is incompatible with the previous version of Messaging Server.
If you upgrade Communications Express, you must also upgrade Messaging Server.
This also applies to Calendar Server.
For more information on Communications Express, see Chapter 6, Sun Java System Communications Express 6.3 Release Notes.
Clarification is needed on RTF/HTML editing and browser compatibility for Messenger Express and Communications Express.
No additional comments.
"session.timeout Login Again" pop-up error displays when you click Communications Express in Portal Server. (6417988)
Ignore the pop-up error, close the window, and continue to use Communications Express.
No additional comments.
If you use Messaging Server with Access Manager Single Sign-on, it does not support Java Enterprise System 2004Q2 Access Manager Server. However, Access Manager 6.3 and later is supported.
The specific versions of Messaging Server that do not support Java Enterprise System 2004Q2 Access Manager Server are:
Upgrade Access Manager (JES 2004Q2) before upgrading Messaging Server.
Access Manager now has two installation types: Realm (version 7.x style) and Legacy (version 6.x style).
If you are installing Access Manager with Messaging Server, Calendar Server, Instant Messaging, Delegated Administrator, or Portal Server, you must select Legacy mode (version 6.x style). See: Sun Java System Access Manager 7 2005Q4 Release Notes
If the wrong Access Manager is installed, you will not be able to run Delegated Administrator.
If you are using iPlanet Delegated Administrator and you upgrade to Messaging Server 6.3, you cannot use the imadmin user purge command to remove users from the directory as you did with earlier versions of Messaging Server (6486836). Instead, follow the steps shown below to purge users.
This compatibility issue occurs because the Administration Console and Administration Server have been removed in Messaging Server 6.3. With earlier versions of Messaging Server, you can continue to use imadmin user purge as before.
iPlanet Delegated Administrator, originally used with Messaging Server 5.x, is a deprecated utility. It is not the same tool as Communications Suite Delegated Administrator, introduced with Messaging Server 6.x. Communications Suite Delegated Administrator supports Schema 2. iPlanet Delegated Administrator supports Schema 1. (Some administrators who have upgraded Messaging Server to 6.x, but remain in Schema 1, have continued to use iPlanet Delegated Administrator to provision users.)
Apply iPlanet Delegated Administrator patch 1.2p3.
You can download this patch at the following site:
Go to the Delegated Administrator 1.2 Patch 3 for Messaging. This patch enables the imadmin user purge command to operate in a way compatible with Messaging Server 6.3. Follow the remaining steps in this procedure to enable the new behavior.
Modify the MsgSvrN-adminurl property in the iPlanet Delegated Administrator resource.properties file.
The MsgSvrN-adminurl property sets the url of the Administration Server. When this property is set to an actual url, the imadmin user purge command will attempt to locate the Administration Server, which will not respond. The imadmin user purge command will return an error.
You must set MsgSvrN-adminurl to this value: NO_ADMIN_SERVER.
The resource.properties file is located by default in the following path:
iDA_Install_Directory /nda/classes/netscape/nda/servlet/resource.properties
Multiple Message Stores Upgraded to Messaging Server 6.3:
The value N in MsgSvrN-adminurl is a variable that must be replaced with a specific value, such as 0, that identifies the message store system that has been upgraded to Messaging Server 6.3. If you have deployed multiple back-end message stores in Messaging Server 6.3, you must change this value for each instance of the MsgSvrN-adminurl property.
For example, if you have three back-end message stores, you must change this property in the resource.properties files for all three stores. You would change, for example, the MsgSvr0-adminurl , MsgSvr1-adminurl, and MsgSvr2-adminurl properties.
Multiple Message Stores Using Different Versions of Messaging Server:
Suppose you have deployed multiple message stores and have upgraded only some stores to Messaging Server 6.3, while others remain in previous versions of Messaging Server. In this case, change the MsgSvrN-adminurl property only for the stores upgraded to Messaging Server 6.3.
When you run the imadmin user purge command on a store for which you changed the MsgSvrN-adminurl property to NO_ADMIN_SERVER, the command will operate in the new way described in Step 5, below.
When you run the imadmin user purge command on a store where the MsgSvrN-adminurl property is unchanged (still pointing to an Administration Server url), the command will operate as it has in the past.
Restart the Web Server to which you have deployed iPlanet Delegated Administrator.
The Web Server on which iPlanet Delegated Administrator is running must be restarted to enable the changes in the resource.properties file to take effect.
Use the imadmin user delete command to mark the user as deleted.
imadmin user delete sets the inetUserStatus attribute to "deleted". To delete multiple users, use the -i option. For example:
imadmin user delete -D chris -L user1 -n siroe.com -w bolton
Use the msuserpurge command to remove the user's mailbox.
msuserpurge finds all user entries where inetUserStatus or mailUserStatus are set to deleted, purges those user mailboxes from the message store, and sets mailUserStatus to removed. For example:
msuserpurge -d domain
You must run msuserpurge before you perform the next step (removing the user entry from the directory), or the user's mailbox will be orphaned.
You can schedule the msuserpurge command with the configutil parameter local.schedule.userpurge. For example:
configutil -o local.schedule.userpurge -v "30 2 * * 0 /opt/SUNWmsgsr/lib/msuserpurge -g 20"
In the preceding example, msuserpurge will run on Sundays at 2:30 a.m. It will remove the mailbox of every user marked for deletion longer than 20 days.
Use the imadmin user purge command to remove the user entry from the directory.
In earlier releases, this command performed the following actions:
Searches the directory for users marked as deleted.
Deletes each user's Personal Address Book from the directory.
Deletes each user's mailbox from the message store.
If the user's inetUserStatus attribute is set to deleted, the user entry is removed. If the user's mailUserStatus is set to deleted, the mail attributes are removed from the entry.
Now, because you modified the MsgSvr0-adminurl property, the Administration Server is not called. A message informs you that the Administration Server is not invoked. Step c, above, is not performed. The mailbox was already removed by msuserpurge in Step 3.
In Messaging Server 6.3, if the user's mailuserstatus has been set to removed (by msuserpurge) and no other services are present in the user entry, the imadmin user purge command removes the user entry from the directory.
If the attributes of another service such as calendar service are present in the user entry, the entry is not removed.
The Messaging Server 6.3 documentation set includes the following documents:
Use the following URL to see all the Messaging Server 6.3 documentation.
Messaging Server 6.3 provides the following new and updated documents:
Sun Java System Messaging Server 6.3 Administration Reference
Use either one of the following URLs to see the documentation that applies to all Communications Services products:
http://docs.sun.com/app/docs/coll/1312.2 or http://docs.sun.com/coll/1313.2
The following documents are available:
Sun Java System Delegated Administrator 6.4 Administration Guide
Sun Java Communications Suite 5 Event Notification Service Guide
Sun Java System Communications Express 6.3 Administration Guide
Sun Java System Communications Express 6.3 Customization Guide
The following guides have not been updated for this release. However, you can use the previous versions of these guides:
Sun Java System Messaging Server 6 2005Q4 MTA Developer's Reference
Sun Java System Messenger Express 6 2005Q4 Customization Guide
Sun Java System Communications Services 6 2005Q4 Schema Migration Guide
For a complete list of problems fixed in this release, see the README file delivered with the Messaging Server core software patch.
This section contains a list of the known issues with Messaging Server 6.3. The following product areas are covered:
This section describes known issues with installing, upgrading, and uninstalling Messaging Server.
This version of Messaging Server does not support a staged rolling upgrade with minimum downtime in a symmetric HA environment.
With Messaging Server 5.2, you could install the Messaging Server more than once on the same machine and patch the different installations separately. This capability enabled support for minimal-downtime staged rolling upgrades.
You must use the Communications Services installer to install a cluster agent for Messaging Server.
To install Messaging Server in a Sun Cluster environment, see Sun Cluster Software Example in Sun Java Communications Suite 5 Installation Guide.
The Select Components to Configure screen displays 0 bytes.
When Messaging Server is configured (immediately after installation), the Select Components to Configure screen displays the following components: Message Transfer Agent, Message Store, Messenger Express, Delegated Administrator LDAP entries, and Messaging Multiplexor.
However, all selected components show 0 bytes on the screen.
/opt/etc directory created during SUNWma installation
Workaround: Manually delete the directory after product installation. This issue will be fixed in a future release.
This section describes known issues in the Messaging Server product.
LDAP search performance is slightly impacted by ACIs in Directory Server version 5.x.
This issue affects many searches performed by Messaging Server.
Workaround: For faster searches, use directory manager credentials with the following commands to access the directory:
msg-svr-base/sbin/configutil -o local.ugldapbinddn -v "rootdn"
msg-svr-base/sbin/configutil -o local.ugldapbindcred -v "rootdn_passwd"
where rootdn and rootdn_passwd are the credentials of Directory Server's administrator.
To take effect, changes made using configutil often require a restart of the affected server or servers.
Workaround: None.
If you use Microsoft Outlook Express as your IMAP mail client, the read and unread flags might not work properly.
This is a known problem with the Microsoft Outlook Express client.
Workaround: Set the following configuration variable:
configutil -o local.imap.immediateflagupdate -v yes
If, while using the workaround, you experience performance issues, it is recommended that you discontinue using the workaround.
Access control filters do not work if the short form domain in used in the /etc/hosts file.
If there is a short form version of a domain name in the /etc/hosts file, there will be problems if you use a host name in an access control filter. When the IP address lookup returns a short form version of the domain name, the match will fail. Therefore, you should make sure you use a fully qualified domain name in the /etc/hosts file.
Workaround: None.
MoveUser utility does not work on a mailbox that contains over 1024 subfolders.
It has been reported that the MoveUser utility stops when attempting to move a user's account that has a mailbox containing over 1024 subfolders.
Workaround: None.
Messenger Express Multiplexor (MEM) does not have a configuration option to make use of the OS resolver or NSCD.
Workaround: Configure system as a caching-only DNS server in order to gain the benefit of caching MX and A records.
GB18030 (Chinese National Standard) is a character set now recognized by the MTA.
Implementing this support caused a change to compiled character set data. The imsimta chbuild may need to be run after an upgrade.
The XSTA, XADR commands are enabled by default.
After installation, the SMTP extension commands XSTA and XADR are enabled by default, which may enable remote and local users to retrieve sensitive information.
Workaround: Add the following lines to the <msg-svr-base>/config/tcp_local_option file (create this file if necessary) to disable the XSTA and XADR commands:
imsimta start doesn't start dispatcher and job controller.
The imsimta start, imsimta restart, and imsimta refresh commands work only when the watcher process is running.
New start-msg and stop-msg commands have replaced imsimta start and imsimta stop, which are deprecated and will be removed in a future release.
For more information about the start-msg and stop-msg commands, refer to the Messaging Server Administration Guide.
Workaround: None.
Correct certmap.conf file content required for client certificate authentication.
The certmap.conf configuration file specifies how to map a certificate to an entry in the LDAP directory. By default, the certificate subject (with two lines commented out) contains the exact DN of the LDAP directory entry.
However, a very common alternative behavior is to extract a particular attribute from the subject of the certificate and to search the directory for that attribute.
Workaround: To achieve this alternative behavior, change:
certmap default default #default:DNComps #default:FilterComps e, uid
certmap default default default:DNComps default:FilterComps e
Cannot log in to Messaging Server from Internet Explorer 6.0 SP1 when using a proxy server.
When using an HTTP proxy in Internet Explorer 6.0 SP1 on a PC as a client, you may experience difficulty in logging into Messaging Server. This problem is likely to be due to a non-standard compliant proxy server and cannot be fixed in Messaging Server.
The configure program fails with non-standard organization DNs.
The configure program does not construct intermediate RDNs between the organization DN and the User/Group suffix. This problem occurs both with Schema 1 and Schema 2.
Workaround: Create the Organization DN prior to running the configure program (or at least to the DN above the Organization DN).
NSS errors in the imta logfile when SSL is not configured.
These are not harmful errors. They are caused by the system's inability to find SSL certificates in the SSL configuration.
Workaround: You can disable SSL in the MTA as well as the Message Store:
Edit imta.cnf file and remove the channel keyword maytlsserver from tcp_local and tcp_intranet channels.
Change the following configutil configuration parameters by setting service.imap.sslusessl to 'no' and service.pop.sslusessl to 'no'.
Recompile the MTA configuration with the imsimta cnbuild command.
Restart the services (stop-msg/start-msg). This will disable the support for SSL. Please make sure that, if you need to configure the server in SSL mode after creating certificates, you will need to revert back to the changes you made previously.
Messaging Server fails to start when SNMP is enabled on Solaris 10.
Workaround: Direct snmpwalk to snmpdx instead of snmpd and go directly to port 16161 instead of port 161.
Approach of store.idx 2 Gigabyte limit should act like a quota.
The message store has a hard limit of 2 gigabytes for the store.idx file. If a folder grows to the point that the store.idx file attempts to exceed 2 gigabytes, errors will appear in the mail.log_current file.
Workaround: If possible, set a quota. Also, it is recommended that policies are set so aging rules are used to ensure folders do not grow very large.
REVERSE_URL behavior has changed.
It is not recommended that you change this attribute.
If you want to use an alternate attribute for address reversal and for primary address storage, you should not use REVERSE_URL. Instead, you set the LDAP_PRIMARY_ADDRESS to the attribute you want to use. The problem with this is the semantic overlap between the addresses you want to use for alias lookups and the ones you want to use for alias reversal. You might be able to shuffle attributes around between the LDAP_PRIMARY_ADDRESS, LDAP_EQUIVALENCE_ADDRESSES, and LDAP_ALIAS_ADDRESSES slots. The simplest case would be that you simply want to use meEndRemetente instead of mail for both. In this case all you do is set the LDAP_PRIMARY_ADDRESS MTA option to meEndRemetente and you're done. If, on the other hand, you want to continue to use the mail attribute for alias lookups, you'd have to put it in one of the other slots for that to work. Whether or not that will be allowed depends on whether or not you use mailAlternateAddress and mailEquivalentAddress attributes. Messaging Server 6.2 and earlier allow multiple attributes in each slot, but each directory entry can have at most one attribute that ends up in a given slot. This version of Messaging Server relaxes this restriction for the attributes where it makes sense (like LDAP_ALIAS_ADDRESSES or LDAP_EQUIVALENCE_ADDRESSES but not LDAP_PRIMARY_ADDRESS).
Enabled SSL Ciphers are adjusted; Weak SSL Ciphers can be disabled by default.
For Messaging Server 6.3 and going forward, the weak SSL cipher suites will be disabled by default. This is an incompatible change, so it's possible some old mail clients which only support export-grade SSL will break.
The following configuration options can be used to turn on all cipher suites including the weak ones (but excluding the NULL ciphers):
For MMP: default:SSLAdjustCipherSuites weak+all
For IMAP/POP/SMTP/MSHTTPD: configutil -o local.ssladjustciphersuites -v weak+all
However, be advised to instead only turn on the specific cipher suite needed for inter-operability. For example, the common SSL_RSA_EXPORT_WITH_RC4_40_MD5 cipher suite can be enabled with: +SSL_RSA_EXPORT_WITH_RC4_40_MD5. The 56-bit ciphers are not as weak as the 40-bit ciphers so if it's possible to only enable those, the following cipher suite works: +TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA .
imapd ENS resubscriber leaks file descriptors.
If ENS is configured, then IDLE must be configured as well. If ENS is configured and IDLE is not configured, the imapd and popd will leak file handles .
Workaround: None
The following are additional issues related to the Messaging Server product that do not have IDs.
Maximum Mailbox Size
The mailbox index (store.idx) file has a hard limit of two gigabytes. More than this will cause messages to stop being delivered to the user and could cause message store performance problems. See User Mail Not Delivered Due to Mailbox Overflow in Sun Java System Messaging Server 6.3 Administration Guide for details. Note that the sum of the message sizes in the mailbox may exceed the two gigabyte limit.
In option.dat, lines starting with #, !, or ; symbols are treated as comment lines.
In option.dat files, Messaging Server treats lines beginning with pound sign (#), exclamation point (!), or semicolon (;) characters as comment lines— even if the preceding line has a trailing backslash (\), which means the line is being continued. Consequently, you must be careful when working with long options (particularly delivery options) containing these characters.
There is a workaround for delivery options in which a natural layout could lead to continuation lines starting with a # or !.
Workaround: In delivery options, Messaging Server ignores spaces following the commas that separate individual delivery option types.
For example, instead of:
DELIVERY_OPTIONS=\ #*mailbox=@$X.LMTP:$M$_+$2S%$\$2I@ims_daemon,\ #&members=*,\ *native=@$X.lmtpnative:$M,\ *unix=@$X.lmtpnative:$M,\ /hold=$L%$D@hold,\ *file=@$X.lmtpnative:+$F,\ &@members_offline=*,\ program=$M%$P@pipe-daemon,\ forward=**,\ *^!autoreply=$M+$D@bitbucket
You can workaround the problem by adding spaces as follows:
DELIVERY_OPTIONS=\ #*mailbox=@$X.LMTP:$M$_+$2S%$\$2I@ims_daemon,\ #&members=*,\ #*native=@$X.lmtpnative:$M,\ #*unix=@$X.lmtpnative:$M,\ #/hold=$L%$D@hold,\ #*file=@$X.lmtpnative:+$F,\ #&@members_offline=*,\ #program=$M%$P@pipe-daemon,\ #forward=**,\ #*^!autoreply=$M+$D@bitbucket
DOMAIN_UPLEVEL has been modified.
The DOMAIN_UPLEVEL default value has changed from 1 to 0.
The following characters cannot be used in the User ID: $ ~ = # * + % ! @ , { } ( ) / < \> ; : " " [ ] & ?
This constraint is enforced by MTA. Allowing these characters in the User ID can cause problems in the message store. If you want to change the list of characters forbidden by the MTA, set the following option by listing a comma-separated string of the characters' ASCII values:
in the msg-svr-base/config/options.dat file. Note that you are strongly advised against relaxing this constraint.
At present, there are no localization or globalization issues.
This section describes known issues in the Communications Services and Messaging Server-specific documentation.
The ha_ip_config script does not set all of the required ENS configuration parameters for ENS execution.
If you want to run ENS in an HA environment, you must set the following parameters in the ha_ip_config script:
local.ens.port– Port (and optionally IP address) on which ENS will listen. Format: [address:]port. For example, 7997 or 192.168.1.1:7997. If local.ens.port is set, local.store.notifyplugin.enshost and local.store.notifyplugin.ensport must also be configured.
local.storenotify.enshost— IP address or host name of the ENS server. This setting must correspond to the setting in local.ens.port
local.storenotify.ensport– TCP port for the ENS server. This must correspond to the setting in local.ens.port .
Correction to bug 5076486 regarding imadmin user purge with iPlanet Delegated Administrator 1.2 Patch 2
You are able to use the imadmin user purge command with iPlanet Delegated Administrator 1.2 Patch 2 and Messaging Server 6.x. This legacy version of Delegated Administrator should not be confused with the current Delegated Administrator product documented in Chapter 5, Sun Java System Delegated Administrator 6.4 Release Notes. To use the legacy version of Delegated Administrator, you need to follow the procedures outlined in the iPlanet Delegated Administrator installation documentation on http://docs.sun.com along with the following modification:
Change the MsgSvrN-cgipath line in the iDA_install_directory/nda/classes/netscape/nda/servlet/resource.properties file to MsgSvr0–cgipath=msg-config/Tasks/operation and restart the Web Server.
In addition, if you are running on a cluster, you need to make sure that an Administration Server is always running on the same node as Messaging Server (for releases prior to 6.3).
Workaround: None.
The Messenger Express Customization Guide displays the wrong directory name in the section on customizing hosted domains.
When the user is asked to create a separate directory for each domain, the correct directory should be msg-svr-base/config/html not msg-svr-base/html .
The Messenger Express Customization Guide specifies the wrong file path for the SDK files and functions.
The SDK files and functions are located in msg-svr-base /examples/meauthsdk
Messenger Express Online Help Describes Some Features that Aren't in the Product
The following features are described in the Messenger Express Online Help but are not in the product:
Secure Messaging, also called S/MIME is only available to S/MIME customers. For information on S/MIME, see: Chapter 24, Administering S/MIME for Communications Express Mail, in Sun Java System Messaging Server 6.3 Administration Guide.
Automatic Spell Checker; this feature was removed in a previous release.
Mail Filters; this feature requires additional configuration. See: Configuring Messenger Express and Communications Express Mail Filters in Sun Java System Messaging Server 6.3 Administration Guide.
Navigation Path; you can view navigation paths when you are viewing customer-created folders. However, navigational paths will not display in default folders like the INBOX, Sent Folder, Drafts, Trash, and so on.
Since Messenger Express has been deprecated, the Messenger Express Online Help will not be updated.
No documentation available on new shared defragment database feature.
No documentation available on a new feature whereby MTA systems can share the defragment database and thereby defragmentation can be done on MTA systems instead of the store system.
Workaround: None.
The imarchive —s option is not enabled but is documented.
The imarchive -s option is not currently enabled. However, it is documented in the Sun Java System Messaging Server 6.3 Administration Reference. This option will be enabled in a future update release.
Different server-root notations are used in the product documentation.
The server-root directory (where the Messaging Server configuration files are housed) is referred to as msg-svr-base. In the Java Enterprise System documentation, it is referred to as MessagingServer-base . Both notations refer to the Messaging Server server-root directory.
The following redistributable files are provided with Messaging Server 6.x:
You can redistribute the following files in source (HTML and Javascript) or binary form (GIF files) within a licensed Messaging Server distribution only:
msg-svr-base/config/html (and subdirectories)
msg-svr-base/install/config/html (and subdirectories)
You are not permitted to distribute these files by themselves.
You can copy and use (but not modify) the following header files solely to create and distribute programs to interface with Messaging Server APIs, to compile customer written code using the documented API to interoperate or integrate with Messaging Server, and only as expressly provided in the Messaging Server documentation:
All files in the msg-svr-base /include directory (default location)
The following files are provided solely as reference for writing programs that use the documented API to integrate with Messaging Server: