Internet DRAFT - draft-gellens-lemon-push
draft-gellens-lemon-push
Internet Draft: IMAP Message Submission R. Gellens, Editor
Document: draft-gellens-lemonade-push-00.txt Qualcomm
Expires: June 2004 December 2003
IMAP Message Submission
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes an IMAP protocol extension allowing clients
to submit new messages using IMAP. This is the so-called "IMAP
Push" approach currently being considered by the lemonade working
group as one solution to the "forward without download" problem
(that is, as a means for clients to send new messages consisting of
or containing all or parts of previously received messages without
having to download and upload the data). This proposal relies on
additional IMAP extensions, including CATENATE and Annotations. The
IMAP extension described here requires that the message to be
submitted be already composed and ready to go at the time of
submission.
Gellens [Page 1] Expires June 2004
Internet Draft IMAP Message Submission December 2003
Table of Contents
1. Conventions Used in this Document . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
3. Concept of Operation . . . . . . . . . . . . . . . . . . . . 2
4. SUBMIT Extension . . . . . . . . . . . . . . . . . . . . . 3
4.1 SUBMIT Command . . . . . . . . . . . . . . . . . . . . . 3
4.2 UID SUBMIT . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 SUBMIT Response . . . . . . . . . . . . . . . . . . . . . 5
5. Required SMTP/Submit Extensions . . . . . . . . . . . . . . 5
6. Annotations . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. SMTP/Submit Extension Discovery . . . . . . . . . . . . 6
6.2. Message Envelope and Status . . . . . . . . . . . . . . 6
6.2.1. Security Considerations . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
10. Informative References . . . . . . . . . . . . . . . . . . 9
11. Editor's Address . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property Statement . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
1. Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
In protocol examples, "C:" designates lines sent by the client,
while "S:" show lines sent by the server. In such examples, line
breaks are for editorial clarity only.
2. Introduction
3. Concept of Operation
The client composes the message, presumably using the [CATENATE]
extension (although potentially using only APPEND). Annotations are
used to specify the desired SMTP/Submit envelope, including
MAIL-FROM, RCPT-TO, and any extensions. This creates a draft
message in an IMAP mailbox containing headers, body, and envelope.
The message status is indicated in an annotation, which will
generally be either 'pending' or 'queued' prior to submission.
Gellens [Page 2] Expires June 2004
Internet Draft IMAP Message Submission December 2003
When desired, the client uses the SUBMIT or UID SUBMIT command as
specified here. This causes the message to be submitted to the
message submission server for processing. The status of the message
is returned as a response, and is also indicated in the message
annotation.
The SUBMIT extension can require that the submit server used by the
IMAP server support certain extensions. Currently, only the [DSN]
extension is required. The client can learn which extensions are
supported by the submit server by fetching a server annotation
(using [ANNOTATEMORE]). The IMAP server can either dynamically
obtain the supported extensions when this annotation is accessed,
or, if the IMAP and submit servers are integrated, can cache or
obtain this information internally.
If one or more recipients are rejected by the submit server, the
IMAP server either aborts the message submission or continues. By
default it aborts, but the client can optionally instruct the server
to continue.
If one or more recipients failed, the client can use CATENATE to
create a new draft which identical to the failed draft except for
the corrected recipient information (both message header and RCPT-TO
annotation) and can then resubmit the new message. If the rejected
recipient is not disclosed in the header, the client can instead
correct the recipient in the RCPT-TO annotation in the original
message and resubmit the corrected draft.
NOTE: the requirement for and use of annotations could be avoided by
having the SMTP/submit envelope be passed as a literal in the SUBMIT
command, but this has a number of disadvantages. It severs the
linkage between the draft message and the envelope, requiring the
client to maintain the envelope in local storage, and prevents the
message from being prepared for submission by one client and
submitted by another. It also requires DSNs to learn the status of
failed recipients if the client disconnects before receiving the
response to the SUBMIT command.
4. SUBMIT Extension
The SUBMIT extension is advertised by "SUBMIT" in the CAPABILITY
response.
Gellens [Page 3] Expires June 2004
Internet Draft IMAP Message Submission December 2003
4.1 SUBMIT Command
Arguments: message sequence number
OPTIONAL "NOABORT"
Responses: untagged responses: SUBMIT
Result: OK - submit completed: if "NOABORT" was specified, then
all recipients were accepted by the submit server;
otherwise at least one recipient was accepted
NO - submit error: submit server rejected some (unless
"NOABORT" specified) or all recipients; the submit
server rejected one or more extensions; the submit
server rejected the message for some other reason.
BAD - command not supported or arguments invalid
The SUBMIT command is only valid when a mailbox has been selected.
The indicated message is submitted to the message submission server.
Error responses by the submit server are returned in untagged SUBMIT
responses (one per error). If there are no errors, no SUBMIT
responses are returned. When the message has been accepted by the
submit server, an OK response is sent. If a recipient is rejected,
by default the submission is aborted, although the remaining
recipients will be checked (the IMAP server continues to send RCPT
TO commands, but sends RSET or QUIT instead of DATA). If the
optional "NOABORT" option is specified, the submission is not
aborted. If an extension or other aspect of the message is
rejected, the submission is aborted even if "NOABORT" was specified.
If the connection to the client closes, or the client logs out,
before the command response had been sent, the server continues
processing the command.
The client learns the status of the submitted message by the SUBMIT
response and the command result. The client can also learn the
status by examining the annotation. The annotation allows the
client to find out what happened to a message submitted before a
disconnect.
Note that multiple SUBMIT commands can be pipelined together.
Examples:
C: a15 SUBMIT 12
S: * SUBMIT "MAIL FROM:<hapless@example.com>" "550 5.7.0 user
not authorized to submit (subscription expired)"
S: a15 NO not my fault submission rejected by submit server
C: a15 SUBMIT 12
S: a15 OK submission accepted by submit server submit.example.com
Gellens [Page 4] Expires June 2004
Internet Draft IMAP Message Submission December 2003
C: a15 SUBMIT 12
S: * SUBMIT "RCPT TO:<friend@example.org>" "550 5.1.1 <friend> User
unknown"
S: * SUBMIT "RCPT TO:<b1ff@example.org>" "550 5.1.1 <b1ff> User
unknown"
S: a15 NO not my fault submission rejected by submit server
4.2 UID SUBMIT
This document adds SUBMIT as a valid command to UID. The parameters
are the same as for SUBMIT, but instead of a sequence number a
unique identifier is used.
4.3 SUBMIT Response
Contents: envelope errors
The SUBMIT response lists any error responses returned by the submit
server to the SMTP/submit commands. Each response contains the
SMTP/submit command followed by the response code and text returned
by the server. Both the command and the response are strings. Note
that multi-line responses are returned as a single string containing
the reply minus the CRLFs and repeated response codes, and with line
breaks replaced by a single space.
Example:
S: * SUBMIT "MAIL FROM:<hapless@example.com>" "550 5.7.0 user
not authorized to submit (subscription expired)"
S: * SUBMIT "RCPT TO:<b1ff@example.org>" "550 5.1.1 <b1ff> User
unknown"
5. Required SMTP/Submit Extensions
Currently, only [DSN] is the only SMTP/submit extension required to
be supported.
Gellens [Page 5] Expires June 2004
Internet Draft IMAP Message Submission December 2003
6. Annotations
6.1. SMTP/Submit Extension Discovery
The "/submit-capabilities" entry is used to access the capabilities
supported by the submit server. The IMAP server MUST ensure that
the response is accurate when received by the client. This can be
done by opening a connection to the submit server to learn the
capabilities when the "/submit-capabilities" entry is accessed, or
by caching the information with a mechanism to update it when it
changes (for example, if the two servers are combined or have other
means of communication).
Example:
C: a GETANNOTATION "" "/submit-capabilities" "value"
S: * ANNOTATION "/submit-capabilities" ("value.shared"
"(PIPELINING) (8BITMIME) (ENHANCEDSTATUSCODES) (ETRN)
(AUTH CRAM-MD5 NTLM PLAIN LOGIN) (AUTH=LOGIN)
(SIZE 2147483647)")
6.2. Message Envelope and Status
This specification adds the following entry names:
/draft-envelope
Defines the top-level of annotations containing the SMTP/submit
envelope for draft (sent or unsent) messages.
/draft-envelope/$state
The value of this annotation indicates the draft state:
"pending", "queued", "sent", "rejected", or "partially-sent".
/draft-envelope/mail-from
Holds elements of the mail-from portion of the envelope.
/draft-envelope/mail-from/<address>
Is named and contains the address, not including angle brackets,
to be sent in the MAIL FROM command. Note that the value of
this attribute is identical to its name.
Gellens [Page 6] Expires June 2004
Internet Draft IMAP Message Submission December 2003
/draft-envelope/mail-from/<address>/dsn
Contains the DSN extension values to be used with this MAIL
FROM.
/draft-envelope/mail-from/<address>/$status
Contains the response code and text returned by the submit
server to the MAIL FROM command. It is placed under the
<address> sub-entry to be consistent with the handling of RCPT
TO entries. This entry has no value until the SUBMIT command is
used on this message. If a new SUBMIT command is issued
following a previous one, the server must only return the
updated status.
/draft-envelope/rcpt-to
Holds elements of the rcpt-to portions of the envelope.
/draft-envelope/rcpt-to/<address>
Is named and contains the address of this recipient. Note that
the value of this attribute is identical to its name.
/draft-envelope/rcpt-to/<address>/dsn
Contains the DSN extension parameters and values for this
recipient.
/draft-envelope/rcpt-to/<address>/$status
Contains the response code and text returned by the submit
server to this RCPT TO command. This entry has no value until
the SUBMIT command is used on this message. If a new SUBMIT
command is issued following a previous one, the server must only
return the updated status.
Note that SMTP/submit extensions are specified as entries under the
command being extended. The IMAP server SHOULD process all entries
which do not start with "$" under
"/draft-envelope/mail-from/<address>" and
"/draft-envelope/rcpt-to/<address>" as extensions without trying to
recognize them. This allows new extensions to be introduced without
modifying the IMAP server. Note that new submit command may be
defined in the future. Such commands would have their own entries
under "/draft-envelope". Since it is conceivable that such commands
would be used in place of MAIL FROM or RCPT TO, the IMAP server
SHOULD NOT process unrecognized entries under "/draft-envelope" but
instead SHOULD return a BAD response to the SUBMIT command.
Gellens [Page 7] Expires June 2004
Internet Draft IMAP Message Submission December 2003
Example:
C: a FETCH 12 (ANNOTATION ("/draft-envelope/*" "value.priv"))
S: * 12 FETCH (ANNOTATION
("/draft-envelope/$state" ("value.priv" "rejected")
"/draft-envelope/mail-from/schlmo@example.com"
("value.priv" "schlmo@example.com")
"/draft-envelope/mail-from/schlmo@example.com/dsn"
("value.priv" "ENVID 00BADBAD00")
"/draft-envelope/mail-from/schlmo@example.com/$status"
("value.priv" "250 2.1.0 sender ok")
"/draft-envelope/rcpt-to/b1ff@example.com"
("value.priv" "b1ff@example.com")
"/draft-envelope/rcpt-to/b1ff@example.com/dsn"
("value.priv" "NOTIFY=success")
"/draft-envelope/rcpt-to/b1ff@example.com/$status"
("value.priv" "550 5.1.1 User unknown")))
6.2.1. Security Considerations
This approach requires that the submit server trust the IMAP server
to submit messages on behalf of the end user. In addition, since
new functionality is being added to IMAP, including expansion of
referenced data, implementation errors have the potential to create
vulnerabilities that could compromise the IMAP server, giving access
to all of the user's IMAP data, all IMAP data for all users, or root
access to the system.
7. IANA Considerations
The hard-working IANA staff is kindly requested to add "SUBMIT" to
the IMAP4 capabilities registry with a reference to this document.
8. Acknowledgements
The editor is grateful for and would like to acknowledge the
significant contributions made to this document by several members
of the lemonade group, most especially Cyrus Daboo.
Gellens [Page 8] Expires June 2004
Internet Draft IMAP Message Submission December 2003
9. Normative References
[binary SMTP] "SMTP Service Extensions for Transmission of Large and
Binary MIME Messages", G. Vaudreuil, December 2000, RFC 3030.
[BURL] Newman, C., "Message Composition",
draft-newman-lemonade-compose-xx (work in progress).
[DSN] "Simple Mail Transfer Protocol (SMTP) Service Extension for
Delivery Status Notifications (DSNs)", K. Moore, January 2003, RFC
3461
[IMAP] "INTERNET MESSAGE ACCESS PROTOCOL -- VERSION 4rev1", M.
Crispin, March 2003, RFC 3501.
[message submission] "Message Submission", R. Gellens, J. Klensin,
December 1998, RFC 2476.
[URL access-type] "Definition of the URL MIME External-Body
Access-Type", N. Freed, K. Moore, A. Cargille, October 1996, RFC
2017.
[URLAUTH] Crispin, Newman, "Internet Message Access Protocol (IMAP)
- URLAUTH Extension", draft-crispin-imap-urlauth-xx (work in
progress).
10. Informative References
[annotate] Gellens, Daboo, "IMAP ANNOTATE Extension" (work in
progress).
[ANNOTATEMORE] Daboo, (work in progress).
[CATENATE] Resnick,
[mailbox referrals] "IMAP4 Mailbox Referrals", M. Gahrns, September
1997, RFC 2193.
[SMTP] "Simple Mail Transfer Protocol", J. Klensin, Ed., April 2001,
RFC 2821.
Gellens [Page 9] Expires June 2004
Internet Draft IMAP Message Submission December 2003
11. Editor's Address
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
USA
randy@qualcomm.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
Gellens [Page 10] Expires June 2004
Internet Draft IMAP Message Submission December 2003
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gellens [Page 11] Expires June 2004