Internet Email to Support Diverse Service Environments (Lemonade) Profile
obsoleted by
- rfc-5550 — The Internet Email to Support Diverse Service Environments (Lemonade) Profile
Extracted elements (21)
The CATENATE extension addresses the 'fcc problem' by constructing the final outgoing message directly in the IMAP sent-mail mailbox, eliminating a separate MUA-to-server APPEND transmission of the already-assembled message.
The Lemonade 'forward without download' design maintains a single submission protocol (SMTP/SUBMIT), avoiding parallel divergent submission mechanisms. This also allows SMTP SUBMIT extensions to be reused without adding them to IMAP, and the approach remains compatible with future retrieval protocols beyond IMAP.
Two variants of 'forward without download' are provided: BURL/CATENATE (assembly on the IMAP server, reducing round-trips when the message is already staged there) and BURL/CHUNKING (assembly during submission, allowing interleaving of new data and referenced parts). The choice allows flexibility for different deployment scenarios.
In the BURL/CHUNKING variant, a third EHLO command is required after authentication if and only if the second EHLO response (post-STARTTLS) does not list any BURL options, since BURL options may only appear after authentication.
When the IMAP server does not send a CAPABILITY response code in its greeting, the mail submission server must issue an explicit CAPABILITY command to discover supported IMAP extensions, as required by RFC 3501.
Lemonade-compliant IMAP servers MUST support IMAP4Rev1, CATENATE, UIDPLUS, and URLAUTH, and MUST declare this support via the CAPABILITY command.
Lemonade-compliant IMAP servers MUST support the CONDSTORE extension to enable quick mailbox resynchronization by returning all flag changes since the last known synchronization mark.
Lemonade-compliant IMAP servers MUST support the NAMESPACE, LITERAL+, and IDLE extensions, and MUST support IMAP over TLS as required by RFC 3501.
Lemonade-compliant mail submission servers MUST support Secure SMTP over TLS (RFC 3207).
Lemonade-compliant mail submission servers MUST support SMTP service extensions for Delivery Status Notifications (RFC 3461).
Lemonade-compliant mail submission servers MUST support the SMTP Enhanced Status Codes extension (RFC 2034).
Lemonade-compliant servers MUST be able to store the $Forwarded IMAP keyword, MUST preserve it on COPY operations, and MUST support SEARCH KEYWORD $Forwarded. Once set, the $Forwarded flag SHOULD NOT be cleared.
Lemonade-compliant submit servers MUST support BURL, 8BITMIME, BINARYMIME, and CHUNKING, and MUST declare this support via EHLO. BURL MUST support URLAUTH type URLs and MUST advertise the 'imap' option following the BURL EHLO keyword.
The BURL/CATENATE variant uses the CATENATE IMAP extension to assemble messages on the IMAP server, then GENURLAUTH to obtain a URLAUTH URL, which is passed to the SMTP submit server via the BURL command for server-to-server retrieval.
The BURL/CHUNKING variant uses BDAT commands to send new message parts from the client and BURL commands to reference existing IMAP-stored parts via URLAUTH URLs, with the SMTP submit server fetching referenced parts directly from the IMAP server using URLFETCH.
The 'forward without download' feature allows an MUA to compose and forward email incorporating content from an IMAP server without downloading it to the client, using URLAUTH tokens and either CATENATE (server-side assembly) or BURL+BDAT (submission-side assembly).
The $Forwarded IMAP keyword indicates that a message was resent to another email address, embedded or attached to a new message. Mail clients set this keyword upon successful forwarding, typically to display a different icon for forwarded messages.
The URLAUTH 'pawn-ticket' mechanism provides a URI containing its own authorization credentials, allowing the SMTP submit server to access only the specific IMAP data authorized by the client, with optional time-limited validity and client-revocable access.
Even without TLS, using BURL to reference message text does not worsen security compared to direct submission: without BURL an eavesdropper gets the full message text, while with BURL access depends on the URL form used (some restrict use to authorized submission servers or specific users).
Lemonade-compliant mail submission servers SHOULD use TLS-protected IMAP connections when fetching message content using the URLAUTH token. When a client uses SMTP STARTTLS before sending a BURL command referencing non-public information, the submission server should use STARTTLS or equivalent when fetching the referenced content.
When using BURL-based message submission, the URLAUTH token must be protected from interception to prevent replay attacks that could disclose message content to an attacker. Lemonade clients SHOULD use TLS-protected IMAP and mail submission channels when using BURL.