Absent from Oracle Communications Messaging Server's support for Lemonade Profile 1 is SMTP BINARYMIME. In addition, Messaging Server's CONDSTORE and ANNOTATE implementations might cause performance issues, so use caution when working with these features. See the appropriate sections in the following information for details.
Topics:
Lemonade refers to an IETF working group formed to address the requirements of supporting standards-based email in a mobile or other resource-constrained environment. A "resource-constrained" environment is one where any or all of the following might be encountered:
Low bandwidth, high latency networks
Intermittent network connectivity
Scarce power and compute cycles
Minimizing data usage is a goal
The Lemonade Profile (RFC 4550, http://tools.ietf.org/html/rfc4550) defines a set of IMAP and SMTP extensions that address these constraints. Messaging Server implements most of the extensions defined in RFC 4550 (Lemonade Profile 1) and some of the extensions defined in RFC 5550 (Lemonade Profile 2). This information describes the configurable extensions.
Note:
The Lemonade standard is mostly intended for mobile clients. Its goal is to reduce network traffic (both in volume and number of interactions) and to move the CPU load from the client to the server. Clients must have support for Lemonade built into them.Some of the more interesting features of Lemonade include the following:
Forward a message without download (enabled by CATENATE, URLAUTH, and BURL)
Quick resync (enabled by CONDSTORE and QRESYNC)
Persistent sort and search (enabled by CONTEXT)
Conversion
The following sections describe these features in more detail.
Note:
Refer to the discussion on BURL support for SMTP SUBMIT in the Messaging Server Reference for details on configuring and using BURL.Messaging Server supports the BURL command, which extends the SMTP submission profile by adding a new command to fetch submission data from an IMAP server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. Thus, you could forward an email message without first downloading it to the client.
For more information, see http://www.ietf.org/rfc/rfc4468.txt.
Support is enabled in Messaging Server by the BURL_ACCESS mapping. The mapping receives two different probe strings:
port_access-probe-info|channel|uid| port_access-probe-info|channel|uid|url
Here port_access-probe-info consists of all the information usually included in a PORT_ACCESS mapping table probe. It will be blank if BURL is being used in a "disconnected" context such as batch SMTP. The channel is the current source channel and uid is the user's authenticatd UID. The uid will be blank if no authentication has been performed. The $:S input flags will be set if SASL authentication has been performed and $:T will be set if TLS is in use.
The first probe is done when responding to EHLO. In order to offer BURL support the mapping must set $Y and optionally provide a space-separated list of supported URL types. The mapping assumes imap if no string is returned.
The second probe is performed when a BURL command is actually sent by the submit client. It includes the URL specified in the BURL command. Additionally, $:| will be set if the URL contains any vertical bars (which if present could possibly confuse some sorts of access checks). The mapping must set $Y for the URL to be accepted for processing. If $D is also set the string result of the mapping replaces the originally specified URL.
At an absolute minimum the mapping must verify that a proper type of URL has been specified. Typically only imap: URLs should be allowed. Additionally, in the case of "submit" IMAP URLs, a check needs to be made to insure that the URL belongs to the user, that is, the access user in the URL matches the authenticated UID for the submit session. Additionally, it is almost always essential to restrict access to an appropriate set of IMAP servers.
The default BURL settings for Unified Configuration are the following:
BURL_ACCESS *|tcp_*|%*| imap$Y *|*@*|imap://*;URLAUTH=submit+$1*:* $:A$M$Y
The SMTP server has to have the ability to log in to the IMAP server as the submit user. The imap_username and imap_password MTA options are used to accomplish this. imap_username specifies the submit user and defaults to the setting of the imap.submituser option if not specified. The imap_password option specifies the password which of course much match the value set for the submit user account. The imap_password option has no default value.
Messaging Server supports the URLAUTH extension to IMAP and the IMAP URL Scheme (IMAPURL). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server. An IMAP server that supports this extension indicates this with a capability name of "URLAUTH."
For more information, see http://www.ietf.org/rfc/rfc4467.txt.
Messaging Server supports the CATENATE extension to IMAP, which extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server.
For more information, see http://www.ietf.org/rfc/rfc4469.txt.
Messaging Server supports IMAP Conditional Store Operations (CONDSTORE). IMAP CONDSTORE enables clients to coordinate changes to a common IMAP mailbox, for example, when multiple users are accessing shared mailboxes. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.
Warning:
Use caution when enabling CONDSTORE with Convergence, as there might be degradation of IMAP performance. Our hope is to fix this problem in a future release. When this happens, we will remove this caution.For more information, see http://www.ietf.org/rfc/rfc4551.txt.
Messaging Server supports the ANNOTATE extension to IMAP, which permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, you could use IMAP ANNOTATE to attach comments and other useful information to a message, or to attach annotations to specific parts of a message, marking them as seen or important, or a comment added.
Warning:
Use caution when enabling ANNOTATE, as there might be degradation of IMAP performance. Our hope is to fix this problem in a future release. When this happens, we will remove this caution.For more information, see http://www.ietf.org/rfc/rfc5257.txt. Of note in this document is Section 3.4, "Access Control," which summarizes access control restrictions, including the new ACL "n" right.
When migrating a multi-system deployment from Messaging Server 6.3 to 7, it is important that the systems advertise consistent IMAP extension sets, especially with respect to CONDSTORE. During migration you can configure Messaging Server 7 to display the same capability set as the older Messaging Server version. You can also turn on the new features on all back systems simultaneously. This feature is only of real significance with CONDSTORE and if you have lemonade-aware clients.
You can also filter the initial capability vector advertised in the IMAP banner in the MMP.
Set the IMAP capability options to 1 to control the CAPABILITIES vector. To see a list of these options, run the following command:
msconfig msconfig> help option capability_*
You can also refer to the Messaging Server Reference to see the IMAP capability options.
The default values for most of these options is 1. The exceptions are IMAP4 and CONDSTORE. The default for IMAP4 is 0 unless obsoleteimap is set, in which case it is 1. These options only affect whether a particular feature is advertised, except for imap.capability_condstore which also enables the feature.
Turning on (or not turning off) a capability does not necessarily mean that the feature will be advertised. IDLE, STARTTLS, and XREFRESH are only advertised if enabled by these options and other condition exist that make it appropriate for them to be advertised.
Messaging Server supports Lemonade Profile 1, which is an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients that do not have local storage or are otherwise unable to release a message for delivery at an appointed time. This functionality is useful for sending announcements to be read at the beginning of a work day, to send birthday greetings a day or so ahead, or to use as a lightweight facility to build a personal reminder service.
For more information, see http://tools.ietf.org/rfc/rfc4865.txt.
Support is enabled in Messaging Server by placing the futurerelease channel option on the source channel used for initial message submission. The option takes a single integer argument: the maximum number of seconds a message can be held.