Skip to main content

Internet Email to Support Diverse Service Environments (Lemonade) Profile
RFC 4550

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    lemonade mailing list <>, 
    lemonade chair <>
Subject: Protocol Action: 'Lemonade Profile' to Proposed 

The IESG has approved the following document:

- 'Lemonade Profile '
   <draft-ietf-lemonade-profile-08.txt> as a Proposed Standard

This document is the product of the Enhancements to Internet email to 
Support Diverse Service Environments Working Group. 

The IESG contact persons are Ted Hardie and Lisa Dusseault.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary
The LEMONADE profile is a profile (a set of required extensions,
restrictions and usage modes) of the IMAP and mail submission protocols.
This profile allows clients (especially those that are constrained in
memory, bandwidth, processing power, or other areas) to efficiently use
IMAP and Submission to access and submit mail.  This includes the
ability to forward received mail without needing to download and upload
the mail, to optimize submission and to efficiently resynchronize in
case of loss of connectivity with the server.
Working Group Summary
The IETF LEMONADE WG has done considerable work on developing protocols
to support features to improve email access in diverse environments.
This includes various efficiency improvements to the base IMAP and SMTP
protocols that have been documented in separate documents.  A notable
addition is a mechanism to forward a message without downloading it to
the client.  The profile explains this and other improvements along with
examples.  To aid interoperability, this document indicates which IMAP &
SMTP extensions are mandatory.  Though work is continuing on additional
improvements, there is consensus in the WG to progress the LEMONADE

Protocol Quality
The profile lists several new features to IMAP  and SMTP that have
already been implemented by several vendors.  This has already resulted
in changes to the spec to clarify the protocols.  In addition it has
resulted in removing some other new protocols that are not fully baked
at this time and will be included in a later revision of this document.
The document was reviewed for the IESG by Ted Hardie.  The PROTO
shepherd is Glenn Parsons.

RFC Editor Note