Lemonade Profile 1 Support

Introduction to Lemonade

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 5550, http://tools.ietf.org/html/rfc5550) defines a set of IMAP and SMTP extensions that address these constraints. Sun Java System Messaging Server implements the extensions defined in RFC 5550. This page 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.

Lemonade Features

Some of the more interesting features of Lemonaded 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 (note that the only conversion supported in Messaging Server 7.0 is character set conversion)

The following sections describe these features in more detail.

Support for BURL

Messaging Server 7.0 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 7.0 by a new 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. So, assuming that all users connect to an IMAP server called mail.example.com, a minimal BURL_ACCESS would be something like:

BURL_ACCESS

  *|                                                                   imap$Y
  *|*@*|imap://$S*@mail.example.com/*;URLAUTH=submit+$1*:internal:$H*  $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 service.imap.submituser configutil option if not specified. IMAP_PASSWORD specifies the password which of course much match the value set for the submit user account. The IMAP_PASSWORD option has no default value.

IMAP URLAUTH Support

Messaging Server 7.0 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.

IMAP CATENATE Support

Messaging Server 7.0 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.

IMAP Conditional Store Operation Support

Messaging Server 7.0 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 Sun 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.

IMAP ANNOTATE Support

Messaging Server 7.0 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.

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.

Controlling IMAP CAPABILITIES Vector

When migrating a multi-system deployment from Messaging Server 6.3 to 7.0, it's important that the systems advertise consistent IMAP extension sets, especially with respect to CONDSTORE. During migration you can configure 7.0 to display the same capability set as the older Messaging Server version, and you can 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.

Note that you can also filter the initial capability vector advertised in the IMAP banner in the MMP.

Set the configutil options below to TRUE to control the CAPABILITIES vector:

The default values for most of these options is TRUE. The exceptions are IMAP4 and CONDSTORE. The default for IMAP4 is FALSE unless local.obsoleteimap is set, in which case it is TRUE. These options only affect whether a particular feature is advertised, except for
service.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 will only be advertised if enabled by these options and other condition exist that make it appropriate for them to be advertised.

Support for SMTP Submission Service Extension for Future Message Release

Messaging Server 7.0 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 which 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/html/draft-ietf-lemonade-futuredelivery.

Support is enabled in Messaging Server by placing the futurereleasechannel option on the source channel used for initial message submission. The keyword takes a single integer argument: the maximum number of seconds a message can be held.