IMAP Forwarding Extension for Message Submission

1. draft-lemonade-imap-submit-01.txt • “Forward without Download” • Allow IMAP client to include previously-received message (or parts) in or as new message without downloading and then uploading the content • Current version summarizes different technical approaches, with updates from Vienna (further refinements to both)

2. IMAP Push Mechanisms • Annotated outbox/external-agent • draft w/ annotation (SMTP envelope, “ready” flag) • external agent picks up and submits • IMAP does submit intrinsically • IMAP server queues outbound messages; submits now or later • IMAP client polls message to learn status • Proxy • IMAP opens connection to Submit • OK from IMAP command means message accepted by Submit server

3. IMAP does submit intrinsically • Two submission mechanisms: Submit and IMAP • deprecate Submit: all clients use IMAP for submission • Maintain both (must add extensions to both) • Tie IMAP mechanism to Submit • Requires IMAP have the ability to queue messages • Mail queue is very complex • monitor for failures • add & delete messages • queue is simpler than full SMTP • operations to manage a single queue are same as to manage a bunch of queues

4. IMAP does submit intrinsically (cont’d) • ability to generate DSNs • ability to forward to smart relay • IMAP server queues outbound messages • OK from IMAP doesn't mean msg accepted by Submit server • Clients polls message to learn status or always gets DSNs • likely implementation approach will be to bolt sendmail onto IMAP server

5. Proxy • IMAP opens connection to Submit server in real-time; assembles data as it sends message • Does not return OK until it gets ack from Submit. • Command may thus take as long as SMTP permits for reply to DATA (10 minutes but we could shorten this) • Client can close the connection before it gets an OK. Command continues. Server can mark message as to success or failure, and if failure specific error text from Submit server.

6. Proxy (cont’d 1) • Add command to get EHLO response from Submit server. • Mandate support for a base set of extensions. • Client can issue new command if it needs to use an extension not mandated; may issue cmd only on occasion (once per session, per day, per week). • New IMAP command to submit mail. • SMTP envelope sent as literal. • Data sent as literal or as reference. • Name of IMAP folder into which message will be deposited (optional). • Flag for fail entire message if any recipients fail. • IMAP sends as unsolicited response each response code.

7. Proxy (cont’d 2) • Proxy authentication can be solved by having IMAP authenticate to Submit as an admin user (perhaps with TLS client certs), or if the client permits, by IMAP sending client's credentials to Submit. • Require Submit to support SASL authorization IDs. • Require support for MAIL FROM ... AUTH=... • Support for authorization ID allows IMAP server to send msgs from itself and to send msgs on behalf of a user, and for these cases to be distinguished. Can use SASL external if Submit server trusts IMAP server (perhaps by IP address).

8. Cons to IMAP submit • Adds complexity to IMAP for a limited case. • If IMAP used for non-SMTP messages (e.g., IM), IMAP must learn each submission mechanism • Proxy authentication problem • Admin complexity (admin must set up trust relationship between servers). • Knowing what happened to a message that was not fully successful or which the client doesn't know (connection closed) requires sent mail folder with annotated message.

9. IMAP Pull • “Pawn ticket” mechanism (urlauth) to authorize limited access to specific MAP data by submit server • Per-mailbox access generation key • Client can cause new secret to be generated at any time. • Client creates URL which can include expiration time/role/user, and signs using mailbox secret. • URL valid until earlier of expiration time or client issues command to generate new mailbox secret. • Could avoid conflating pointer to data with authentication would be to separate URL from authentication, and have BURL command accept two parameters. Doesn't really help much.

10. IMAP Pull Cons • Submit server needs to support a subset of IMAP FETCH. • IMAP server needs to support per-user mailbox secrets. • Case of forward with annotation without download and store result in sent mail requires IMAP server to supply email address that causes new mail to be deposited into a folder (generally useful in itself), or client can use COMPOSE to assemble message in outbox, then submit completed message. This latter approach also solves future delivery with revocation as message can be deleted (or modified) prior to being sent. As bonus, queued message counts against user’s quota. • Security issues with authorization token (eavesdropper can access message, during validity of token, but only if submission uses unprotected channel, hence no worse than current submission over unprotected channel).

11. IMAP COMPOSE Command • Allows client to assemble draft from parts • Useful with both IMAP Push and Pull • Solution for sent mail copy • Addresses future delivery • Quota • Cancel • Revise (still issues) • Makes IMAP Pull easier

12. URL AUTH • Can restrict authorization • Expiration time • User identity (user Maida only) • Role identity (submit server) • Useful in areas outside lemonade

13. Encrypted/signed mail • requires private key live in server (any approach)