Internet DRAFT - draft-kundrat-imap-submit
draft-kundrat-imap-submit
Internet Engineering Task Force J. Kundrat
Internet-Draft August 27, 2013
Intended status: Standards Track
Expires: February 26, 2014
IMAP SUBMIT Extension
draft-kundrat-imap-submit-02
Abstract
This document extends the IMAP protocol with a feature to submit
e-mail messages for delivery. It is intended to serve as a better
alternative to the URLAUTH/BURL approach.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 26, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 3
Kundrat Expires February 26, 2014 [Page 1]
Internet-Draft IMAP SUBMIT Extension August 2013
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 3
3.1. New IMAP Capabilities . . . . . . . . . . . . . . . . . . 4
3.1.1. The SUBMIT Capability . . . . . . . . . . . . . . . . 4
3.1.2. The SUBMIT= Capabilities Family . . . . . . . . . . . 4
3.1.2.1. SUBMIT=DSN . . . . . . . . . . . . . . . . . . . . 4
3.2. Additional Response Codes . . . . . . . . . . . . . . . . 4
3.2.1. The POLICYDENIED Response Code . . . . . . . . . . . . 4
3.2.2. The SUBMISSIONRACE Response Code . . . . . . . . . . . 4
3.3. UID SUBMIT command . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Delivery options . . . . . . . . . . . . . . . . . . . 6
3.3.1.1. FROM Delivery Option . . . . . . . . . . . . . . . 6
3.3.1.1.1. DSN-ENVID Submission Option . . . . . . . . . 6
3.3.1.2. RECIPIENT Delivery Option . . . . . . . . . . . . 7
3.3.1.2.1. DSN Submission Option . . . . . . . . . . . . 7
3.3.1.2.2. DSN-RET Submission Option . . . . . . . . . . 9
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. FIXME Items . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B.1. Changes in -02 since -01 . . . . . . . . . . . . 13
Appendix B.2. Changes in -01 since -00 . . . . . . . . . . . . 13
Appendix B.3. Changes in -00 since private-01 . . . . . . . . . 13
Appendix B.4. Changes in private-01 since private-00 . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
In the traditional IMAP/ESMTP service model, a MUA transfers each
outgoing message twice -- once for storing it in the user's "sent
mail" folder, and the second time for actual message submission over
(E)SMTP. Under certain circumstances, such as when the message
contains data which are already available in another message stored
on the same IMAP server (such as when forwarding an unread attachment
to another recipient), the MUA has to download the data before the
message can be composed, resulting in transmitting the data three
times in total.
Many proposals exist which aim to reduce this high number of
transfers to the lowest possible number. The CATENATE extension
[RFC4469] enables IMAP clients to have the IMAP servers compose
messages on their behalf, optionally using data already available on
the IMAP server. Using CATENATE, MUAs do not have to download
individual message parts before including them to the newly created
message.
The LEMONADE extension family [RFC5550] mandates full support for
BURL [RFC4468] and URLAUTH [RFC4467] extensions. When coupled with a
properly configured pair of ESMTP and IMAP servers, these two
extensions allow MUAs to have the submission server obtain the
message payload from the IMAP server. This approach completely
Kundrat Expires February 26, 2014 [Page 2]
Internet-Draft IMAP SUBMIT Extension August 2013
eliminates the need to upload the message data to the ESMTP server,
achieving the "forward-without-download" goal.
The BURL/URLAUTH extensions, however, put a significant burden on the
server operators who suddenly have to establish an explicit trust
relation between their submission and IMAP servers, and make this
trust path visible to the users' MUAs. No MUA-visible means of
discovering this trust relation are defined. Furthermore, the whole
scheme still requires the MUAs to maintain two distinct connections
speaking different protocols. Users are prompted for two sets of
credentials to authenticate to each of these two services. Real-
world support issues were reported where users are able to access
their IMAP service while access to the submission service is blocked
by a mis-configured firewall.
The SUBMIT extension of the IMAP protocol effectively moves the
message submission process to be initiated by a user's request to
their IMAP server. When deployed, this scenario provides a perfect
discoverability to the users' MUAs, saves the overhead of
establishing and securing a separate TCP connection against the
submission server, reduces the amount of the configuration data the
users are required to provide, and simplifies the trust paths which
are required to exist between the submission and the IMAP servers.
When combined with the existing CATENATE extension [RFC4469], the
SUBMIT command works at least as effectively as the Lemonade trio of
CATENATE/BURL/URLAUTH.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Mode of Operation
The SUBMIT extension adds the UID SUBMIT IMAP command which instructs
the IMAP server to arrange for delivery of an already existing IMAP
message. How this message is composed is outside of scope of this
extension, but it is assumed that clients will often use the APPEND
or APPEND ... CATENATE commands.
Upon receiving the SUBMIT command, the IMAP server is asked for
arranging the initial message submission. Clients MAY pass
additional data in form of various options of the SUBMIT command (the
delivery options). The server checks the passed data and delivery
options, optionally performs sanity checks on the message contents,
verifies against a local policy whether the user is authorized for
message submission, and if none of these checks fail, the server
passes the message for subsequent delivery. The delivery method is
outside of scope of this document, but typical methods would be
invoking a `sendmail`-compatible binary or passing the message to an
ESMTP gateway.
Kundrat Expires February 26, 2014 [Page 3]
Internet-Draft IMAP SUBMIT Extension August 2013
3. IMAP Protocol Changes
This extension introduces one new IMAP command, a few related
response codes and a new family of the IMAP capabilities.
3.1. New IMAP Capabilities
3.1.1. The SUBMIT Capability
Servers implementing this extension announce its presence through the
SUBMIT capability. If the server supports this extension but message
submission is unconditionally disabled by a security policy or
service configuration, this capability MUST NOT be announced.
When this capability is present, clients may assume that chances are
high that submitting messages over IMAP will work.
3.1.2. The SUBMIT= Capabilities Family
The SUBMIT commands issued by the IMAP clients MAY contain delivery
options, and these options might contain other fine grained options.
Servers supporting voluntary features MUST indicate so by including
the appropriate strings in the CAPABILITY responses. All
capabilities used for these purposes begin with the SUBMIT= prefix.
3.1.2.1. SUBMIT=DSN
If the server supports user control of generating the Delivery Status
Notifications (DSN), it MUST announce the SUBMIT=DSN capability.
Clients MUST NOT attempt to control DSN options through the DSN
submission option unless the server announces the SUBMIT=DSN
capability.
3.2. Additional Response Codes
The following response codes are defined for communicating the reason
why submission failed in a machine-readable way.
3.2.1. The POLICYDENIED Response Code
The POLICYDENIED response code SHOULD be used if the server rejects
message submission as a result of a policy based decision which MAY
take the message content, submission options, user's behavior and
transaction history into account.
Upon seeing the POLICYDENIED response code, the client MUST inform
the user that message submission failed, and include the text of the
response in the error message. Clients MUST NOT attempt to
automatically re-queue this message for sending over IMAP. The
clients MAY, however, choose to continue the message submission by
another channel, perhaps over an ESMTP service.
Kundrat Expires February 26, 2014 [Page 4]
Internet-Draft IMAP SUBMIT Extension August 2013
3.2.2. The SUBMISSIONRACE Response Code
The SUBMISSIONRACE response code MUST be sent in the tagged response
if the client asks for submission of a message that is either not
marked with the $SubmitPending keyword or marked with the $Submitted
keyword.
The SUBMISSIONRACE response code could SHOULD have a preference over
the POLICYDENIED response code.
3.3. UID SUBMIT command
The UID SUBMIT command submits a message for delivery.
Arguments:
o UID of message to be sent
o optional list of delivery options
Responses: FETCH response with updated message flags
Result:
OK Message submitted for delivery
NO Submission failed
BAD Invalid commands or options
This command is only valid in the selected state.
The server MUST check its local policy configuration and verify that
the authenticated user is allowed to submit messages. The decision
MAY be based on the user's credentials, the message contents, past
history of the user, or any other criteria the server deems relevant.
The server SHOULD take into account any other local policies before
it proceeds with further submission.
Clients MUST NOT submit a message which is either not marked with the
$SubmitPending keyword from [RFC5550], or which is marked with the
$Submitted keyword. Servers MUST reject such a command with a tagged
NO bearing the SUBMISSIONRACE response code.
In the course of submission, servers MUST atomically add the
$Submitted flag to the message, as described in LEMONADE [RFC5550].
A transient state where the message is temporarily marked with both
$Submitted and $SubmitPending flags MAY be hidden from any IMAP
session or it MAY be visible in some or all of them.
If the command succeeded, the message MUST be marked with the
$Submitted keyword, the $SubmitPending keyword MUST be cleared and a
FETCH response containing the message UID and its new flags MUST be
sent.
Kundrat Expires February 26, 2014 [Page 5]
Internet-Draft IMAP SUBMIT Extension August 2013
If the command fails, the server MUST clear both the $Submitted or
$SubmitPending keywords.
If the server supports CONDSTORE [RFC4551] or QRESYNC [RFC5172]
extensions, any flag changes MUST obey the usual MODSEQ invariants.
Any changes in the MODSEQ values MUST be communicated to the clients,
as mandated by the relevant extensions.
Clients MUST be prepared to handle failing submission at any time.
Servers MAY reject message submission for any reason.
The server MUST process all specified delivery options and their
detailed options. The server MUST respond with a tagged BAD if the
client used unrecognized or unannounced option, or if a recognized
option is used in an invalid way. If the server cannot honor a
recognized and announced option, it MUST respond with a tagged NO
with the POLICYDENIED response code and the message MUST NOT be
submitted, nor its flags changed.
Servers MAY alter the message payload of the outgoing message in
conformance with best current practice about Internet mail.
Individual recipients MAY receive different versions of the message.
In particular, servers MUST change message headers so that the
identity of addresses present in the Bcc headers is not revealed to
other recipients. This mode of operation is described in [RFC5321]
and [RFC5322]. The copy stored on the IMAP server MUST NOT be
altered by these modifications.
3.3.1. Delivery options
The following two delivery options are defined by this extension.
These options apply to the message as a whole:
3.3.1.1. FROM Delivery Option
Syntax: one e-mail address with optional further data
The FROM delivery option corresponds to the FROM field of the SMTP
envelope. If not present, its value MUST be inferred from the
message payload.
It is an error if the FROM delivery option is present more than once.
Servers MUST reject such commands using the BAD tagged response and
the message MUST NOT be submitted. Message flags of the source
message MUST NOT be modified.
The following per-message submission option is defined by this
extensions:
3.3.1.1.1. DSN-ENVID Submission Option
Syntax: specification of ESMTP Envelope ID
Kundrat Expires February 26, 2014 [Page 6]
Internet-Draft IMAP SUBMIT Extension August 2013
This per-message submission option corresponds to the ENVID=...
parameter from [RFC3461]. It allows senders to attach a machine-
readable ID to be received in the delivery status reports concerning
this message.
Clients MUST NOT use the DSN-ENVID return option unless the server
announces the SUBMIT=DSN capability or a SUBMIT=... capability
defined by future extensions which make use of the ENVID ESMTP
parameter.
3.3.1.2. RECIPIENT Delivery Option
Syntax: one e-mail address followed by optional further data
The RECIPIENT delivery option corresponds to the RCPT TO field of the
SMTP envelope.
The RECIPIENT delivery option MAY be present more than once. Servers
MAY impose a limit on the number of recipients of a single message.
If the RECIPIENT delivery option is present, servers MUST ignore any
To, Cc and Bcc headers in the message payload when determining the
list of recipients of this message. That is, the final list of
recipients of the message MUST consist exactly of those recipients
specified in the RECIPIENT delivery options. The server MUST still
sanitize the headers of the submitted message to guarantee the
privacy of the recipients listed in the Bcc message header.
If the RECIPIENT delivery option is missing, servers MUST infer its
value from the message payload. For example, each address present in
any of To, Cc and Bcc message headers MUST be present in the
recipient list.
Servers MAY impose a local policy decision about always sending a
copy of message to a certain address. This operation MUST NOT remove
any addresses from the list of recipients, as obtained either from
the user-specified list of recipients passed through the RECIPIENTS
delivery options, or inferred from the mail headers.
Message submission MUST be atomic -- message is either submitted for
delivery to all recipients, or it MUST NOT be submitted for delivery
to anyone. Actual delivery MAY still fail for certain recipients, as
per usual ESMTP semantics.
The following submission options are defined for the RECIPIENT
delivery option:
3.3.1.2.1. DSN Submission Option
Syntax: delivery status notice specification
Kundrat Expires February 26, 2014 [Page 7]
Internet-Draft IMAP SUBMIT Extension August 2013
The DSN submission option controls generating of delivery status
notifications related to the currently submitted message. When not
given, an implementation-defined default value MUST be used. The
default value MUST be either (FAILURE) or (DELAY, FAILURE), as
Kundrat Expires February 26, 2014 [Page 8]
Internet-Draft IMAP SUBMIT Extension August 2013
mandated by [RFC3461].
It is an error if the DSN submission option is present multiple times
for one recipient.
Clients MUST NOT specify the DSN submission option unless the server
announces the SUBMIT=DSN capability. Support for the SUBMIT=DSN
submission option is OPTIONAL.
The DSN specification is either "NONE" to deactivate DSNs altogether,
or a parenthesized list of any of the following DSN options:
SUCCESS requests generating DSNs upon successful delivery of a
message
DELAY activates generating DSNs when delivery is delayed
FAILURE requests generating DSNs when the delivery fails
The order of DSN requests is not significant. A single DSN option
item MUST NOT be repeated in the DSN specification for one recipient.
3.3.1.2.2. DSN-RET Submission Option
Syntax: DSN return option specification
This per-recipient submission option corresponds to the RET=...
parameter from [RFC3461]. Two values are defined, "HDRS" and "FULL",
meaning to include only the headers or the full message,
respectively, in the generated delivery status reports.
Clients MUST NOT use the DSN-RET return option unless the server
announces the SUBMIT=DSN capability.
4. Example
This section contains an example of how message submission over IMAP
works.
The following example shows how client should submit a message with
UID 123 in the current mailbox for delivery. If the message is
passed through SMTP, its From address in the SMTP envelope MUST be
set to foo@example.org and it MUST be submitted for delivery to two
recipients, the a@example.org and b@example.org. The DSN options are
set to report about excess delays and failures in message delivery
for the first recipient. System's default policy of DSN production
is retained for the second recipient.
C: x UID SUBMIT 123 (FROM "foo@example.org"
RECIPIENT "a@example.org" DSN (delay failure)
RECIPIENT "b@example.org"
)
S: * 10 FETCH (UID 123 FLAGS ($Submitted))
S: x OK Message passed to the sendmail binary
Kundrat Expires February 26, 2014 [Page 9]
Internet-Draft IMAP SUBMIT Extension August 2013
In the following example, a message is delivered to addresses
specified in the message payload. No delivery options are given, and
therefore the From and To envelope items are inferred from the actual
payload. The DSN options, if supported, are set to an
implementation-defined default value.
C: x UID SUBMIT 123
S: * 10 FETCH (UID 123 FLAGS ($Submitted))
S: x OK Message passed to the sendmail binary
5. Acknowledgements
FIXME
6. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located
at:
http://www.iana.org/assignments/imap4-capabilities
This document defines the following list of IMAP capabilities. IANA
will be asked to add them to the registry:
o SUBMIT
o SUBMIT=DSN
FIXME: response codes
7. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234].
Non-terminals referenced but not defined below are as defined by
[RFC3501], or [RFC5234].
Kundrat Expires February 26, 2014 [Page 10]
Internet-Draft IMAP SUBMIT Extension August 2013
capability =/ "SUBMIT" / "SUBMIT=DSN"
;; This extension also reserves all further
;; capabilities starting with the "SUBMIT="
;; prefix for future extensions related to the
;; message submission over IMAP
uid =/ "UID" SP sendmail
sendmail = "SUBMIT" SP uniqueid [SP delivery-options]
delivery-options = "(" delivery-option *( SP delivery-option ) ")"
delivery-option = submission-from / submission-recipient
submission-from = "FROM" SP one-email-addr [SP mail-from-params]
;; MUST NOT be present more than once
;; in the delivery-options block
submission-recipient= "RECIPIENT" SP one-email-addr [SP mail-rcpt-params]
;; MAY be present more than once
mail-from-params = "(" mail-from-param *( SP mail-from-param ) ")"
mail-from-param = sub-option-dsn-envid / sub-generic-option
mail-rcpt-params = "(" mail-rcpt-param *( SP mail-rcpt-param ) ")"
mail-rcpt-param = sub-option-rcpt-dsn / sub-option-dsn-ret
/ sub-generic-option
sub-generic-option = string SP string
;; FIXME: do we want to retain this in without any semantics?
sub-option-rcpt-dsn = "DSN" SP ( "NONE" / dsn-spec )
;; MUST NOT be present more than once for each recipient
dsn-spec = "(" dsn-spec-item *( SP dsn-spec-item ) ")"
;; an individual dsn-spec-item MUST NOT
;; be present more than once in this list
dsn-spec-item = "DELAY" / "FAILURE" / "SUCCESS"
sub-option-dsn-ret = "DSN-RET" SP ( "FULL" / "HDRS" )
;; MUST NOT be present more than once for each recipient
sub-option-dsn-envid= "DSN-ENVID" SP xtext
;; MUST NOT be present more than once
;; <xtext> is defined in [RFC3461], section 4.
;; The allowed syntax is further limited by
;; its section 4.4.
one-email-addr = string
;; valid e-mail address as per [RFC5321]
Kundrat Expires February 26, 2014 [Page 11]
Internet-Draft IMAP SUBMIT Extension August 2013
8. Security Considerations
This extension introduces a new way of allowing authenticated users
to submit Internet mail. Servers supporting this extension SHOULD
implement the same security measures as other SUBMISSION [RFC4409]
servers open to users.
The redirect command from SIEVE [RFC5228] already requires some types
of IMAP message stores to be able to generate outgoing mail.
Security considerations for this extension are similar.
For the IMAP-based submission to work, the server operators MUST
configure their MTA systems to accept submission requests from their
IMAP servers. This change MAY have security implications, even
though services supporting the SIEVE filtering are already configured
to accept e-mails for submission.
The new trust path MAY replace the trust path required for the BURL/
URLAUTH operation required by the LEMONADE extension family.
9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC
3461, January 2003.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
[RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", RFC 4467, May 2006.
[RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468,
May 2006.
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP)
CATENATE Extension", RFC 4469, April 2006.
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE Operation or Quick Flag Changes Resynchronization",
RFC 4551, June 2006.
[RFC5172] Varada, S., "Negotiation for IPv6 Datagram Compression
Using IPv6 Control Protocol", RFC 5172, March 2008.
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008.
Kundrat Expires February 26, 2014 [Page 12]
Internet-Draft IMAP SUBMIT Extension August 2013
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5550] Cridland, D., Melnikov, A. and S. Maes, "The Internet
Email to Support Diverse Service Environments (Lemonade)
Profile", RFC 5550, August 2009.
Appendix A. FIXME Items
IANA and the response codes
"if the command fails, server MUST clear both $SubmitPending and
$Submitted" -- what to do when there's something like a disk error?
Appendix B. Changelog
Appendix B.1. Changes in -02 since -01
o Clarified priorities of SUBMISSIONRACE and POLICYDENIED
o Clarify failover procedure upon seeing a POLICYDENIED
o Clarified message flag manipulation
o Clarified recipient list mangling
o More editorial work
Appendix B.2. Changes in -01 since -00
o "Delivery options" is the new name for former "submission
options"; changed the existing DSN options family to use this new
syntax (thanks to Arnt for this suggestion)
o Clarified the visibility of the transitional state with both
$Submitted and $SubmitPending
o Some editorial work
o Fixed an error in the example (multiple FROM addresses...)
Appendix B.3. Changes in -00 since private-01
o Renamed to SUBMIT
o DSNs are per-recipient, not per-message
Kundrat Expires February 26, 2014 [Page 13]
Internet-Draft IMAP SUBMIT Extension August 2013
o The introduction was rewritten
o Miscellaneous clarifications
o Changed DSN NIL to DSN NONE
o Clarified the semantics of the RECIPIENT submission option to
guarantee Bcc privacy
o Editorial tweaks, including changes to the required SHOULD/MUST/
...
o DSN's ENVID and RET
Appendix B.4. Changes in private-01 since private-00
o Removed the superfluous SENDER submission option
o Mandating Bcc removal in conformance with RFC 5321 / RFC 5322
Author's Address
Jan Kundrat
Eledrova 558
Prague 181 00
CZ
Email: jkt@flaska.net
Kundrat Expires February 26, 2014 [Page 14]
