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
An Image/Link below is provided (as is) to download presentation
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
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)
IMAP Push Mechanisms
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
IMAP opens connection to Submit
OK from IMAP command means message accepted by Submit server
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
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
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.
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.
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).
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.
“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.
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).
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
Revise (still issues)
Makes IMAP Pull easier
Can restrict authorization
User identity (user Maida only)
Role identity (submit server)
Useful in areas outside lemonade
requires private key live in server (any approach)