The Internet Email to Support Diverse Service Environments (Lemonade) Profile
obsoletes
- rfc-4550 — Internet Email to Support Diverse Service Environments (Lemonade) Profile
updates
Extracted elements (27)
Forward without download uses BURL+URLAUTH (and optionally CATENATE) so that the SMTP submit server fetches message content directly from the IMAP store. This avoids the client downloading and re-uploading large attachments, which is prohibitive over low-bandwidth or high-latency mobile links. A single submission protocol is preserved rather than layering a separate forwarding protocol onto IMAP.
The 'pawn-ticket' authorization model (URLAUTH) grants the Submission Server access only to the specific message part authorized by the client. The ticket can be revoked and carries an expiry time, so the Submission Server cannot access any IMAP data beyond what the client explicitly delegates.
Two assembly strategies are defined: (1) CATENATE-first: the client assembles the full message on the IMAP server using CATENATE, obtains a URLAUTH token, and gives it to the Submission Server via BURL; preferred when an fcc copy is needed. (2) BURL/BDAT inline: the client sends header text via BDAT and references IMAP body parts via BURL without prior CATENATE; preferred when no server-side copy is needed.
Four verified technical errata (IDs 1807–1810) for RFC 5162 (QRESYNC) are incorporated: (1807) servers MUST include UID in all unsolicited FETCH responses after a CONDSTORE-enabling command; (1808) servers MUST NOT send HIGHESTMODSEQ in the tagged OK response to CLOSE; (1809) clients MUST prefer the HIGHESTMODSEQ response code over MODSEQ FETCH item values; (1810) servers MUST send HIGHESTMODSEQ below any delayed EXPUNGE mod-sequence to prevent client sync loss.
If an IMAP server supports PARTIAL in IMAP URLs used with CATENATE and URLAUTH, it MUST advertise the URL-PARTIAL capability in both the CAPABILITY response and the equivalent response-code.
Lemonade-compliant IMAP servers MUST support CONDSTORE, QRESYNC, and ENABLE extensions to allow clients to quickly resynchronize a mailbox by requesting all flag changes and expunges since a previously recorded state.
Lemonade IMAP servers MUST support the BINARY extension (moving MIME decoding to the server) and MUST always accept binary-encoded MIME messages in APPEND commands for any folder. CONVERT MUST also be supported to allow clients to request media type conversions and image scaling.
Lemonade Message Delivery Agents MUST support Sieve and the following Sieve extensions: ENOTIFY, IMAP4FLAGS, RELATIONAL, VACATION, VARIABLES, and comparator-i;unicode-casemap.
Lemonade Message Stores MUST implement ESEARCH, CONTEXT=SEARCH, ESORT, CONTEXT=SORT, and SORT extensions to enable efficient server-side filtering and view management for constrained clients.
Lemonade Message Stores MUST provide IMAP-COMPRESS support for application-level stream compression as a fallback when TLS is not actively providing compression. TLS DEFLATE is SHOULD.
Lemonade Message Stores MUST send the CAPABILITY response code in the initial server greeting and after LOGIN/AUTHENTICATE commands, enabling clients to discover supported extensions without a separate CAPABILITY command.
Lemonade Message Stores MUST store $SubmitPending and $Submitted IMAP keywords, MUST preserve them on COPY, and MUST support SEARCH KEYWORD for each. Submission state transitions (pending → submitting → submitted) are managed atomically using STORE (UNCHANGEDSINCE).
Lemonade Message Stores MUST store the $Forwarded IMAP keyword, MUST preserve it on COPY operations, and MUST support SEARCH KEYWORD $Forwarded. Once set, the flag SHOULD NOT be cleared.
Lemonade Message Stores MUST support a comprehensive set of IMAP extensions including BINARY, CATENATE, COMPRESS=DEFLATE, CONDSTORE, CONTEXT=SEARCH, CONTEXT=SORT, CONVERT, ENABLE, ESEARCH, ESORT, I18NLEVEL=1, IDLE, LITERAL+, NAMESPACE, NOTIFY, QRESYNC, SASL-IR, SORT, UIDPLUS, URLAUTH, URL-PARTIAL, and the $Forwarded, $SubmitPending, $Submitted IMAP keywords.
Lemonade Message Stores MUST support CATENATE, UIDPLUS, URLAUTH, and URL-PARTIAL. CATENATE allows message assembly on the server from existing parts and new data; URLAUTH issues time-limited authorization tokens for delegated access to specific messages.
Lemonade Message Stores MUST support LITERAL+ (saves a round trip per non-synchronizing literal) and SASL-IR (saves a round trip during authentication, potentially pipelining the entire auth sequence). Servers MUST also support IMAP over TLS.
Lemonade Message Stores MUST support the IDLE extension, and IDLE responses MUST be sent in a timely manner when changes occur. Stores also MUST support NOTIFY to allow clients to request specific event types (message delivery, mailbox renames) for both the selected folder and others.
Lemonade Message User Agents MUST connect to the Submission Server on port 587 unless explicitly configured otherwise. If port 587 fails, the client MAY retry on port 25.
Lemonade Submission Servers MUST support BURL [SMTP-BURL], and BURL MUST support URLAUTH-type URLs; the server MUST advertise the 'imap' option following the BURL EHLO keyword. This enables the Submission Server to fetch message content directly from an IMAP server.
Lemonade Submission Servers MUST support BURL (with URLAUTH/imap), 8BITMIME, BINARYMIME, CHUNKING, PIPELINING, DSN, ENHANCEDSTATUSCODES, SIZE, and STARTTLS SMTP extensions. These are the baseline extensions required for all Lemonade-compliant submission servers.
Lemonade Submission Servers MUST support SMTP PIPELINING to reduce round trips, which is critical for high-latency networks such as mobile or satellite links.
Lemonade Submission Servers MUST support STARTTLS [SMTP-TLS]. Support for DEFLATE compression in TLS [TLS-COMP] is RECOMMENDED.
Submission Servers MUST support the SIZE extension, MUST expand all BURL parts before evaluating message size acceptability, and clients MUST NOT send a message if they know it exceeds the advertised maximum size. The declared size MUST be at least as large as the assembled message after BURL resolution.
The $Forwarded IMAP keyword marks a message that was forwarded to another address. The $SubmitPending keyword marks a message awaiting submission. The $Submitted keyword marks a message that has begun the submission process; both submission keywords together indicate active in-flight submission.
This document registers the URL-PARTIAL IMAP capability in the IANA IMAP Capability registry. It also registers three IMAP keywords: $Forwarded, $SubmitPending, and $Submitted.
Confidentiality of submitted messages: TLS on the submission path guards against eavesdropping. If TLS is absent, using BURL is no worse than submitting the message text directly; in some BURL forms the eavesdropper may gain less access than with direct text submission.
When using BURL, the URLAUTH token transmitted to the Submission Server must be protected against interception to prevent replay attacks that could expose message content. Both the IMAP session issuing GENURLAUTH and the submission path must be TLS-protected. Submission Servers SHOULD use TLS-protected IMAP connections when fetching content via URLAUTH.