| Internet Engineering Task Force | J. Kundrat |
| Internet-Draft | July 14, 2012 |
| Intended status: Standards Track | |
| Expires: January 13, 2013 |
IMAP SENDMAIL Extension
draft-imap-sendmail-00
This document extends the IMAP protocol with a feature to submit e-mail messages for delivery.
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 January 13, 2013.
Copyright (c) 2012 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.
Many proposals exist which aim at providing the forward-without-download feature where user can reuse parts of her message for composing and sending a new one. The CATENATE extension [RFC4469] adds a method for constructing an IMAP message from parts to be obtained purely on the server side; the LEMONADE extension [RFC5550] mandates full support for BURL [RFC4468] and URLAUTH [RFC4467]. Together with a properly configured IMAP and SMTP servers and with enough client support, these extensions allow for possibility to forward messages without a prior download.
This functionality puts a certain burden on clients -- each of them must be properly configured with two accounts instead of one. It is not enough to configure user's client for access to IMAP, one must also provide all details for a proper SMTP server if it's required to be able to send e-mails. In addition, both SMTP and IMAP servers have to be properly configured to allow an additional mode of authentication and authorization.
This extension drastically simplifies the client operation and minimizes configuration requirements on the server side. If combined with the existing CATENATE extension [RFC4469], it works at least as effectively as the Lemonade trio.
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].
The SENDMAIL extension adds the UID SENDMAIL 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 SENDMAIL command, the IMAP server is asked for arranging the message submission. Clients MAY pass additional data in form of various options of the SENDMAIL command. The server checks the passed data and submission options, optionally performs sanity checks on the message contents, verifies against a local policy that the user is authorized for message submission, and if none of these checks fails, the server passes the message for final delivery. The delivery method is outside of scope of this document, but typical methods would be invoking the `sendmail` binary or passing the message to an ESMTP gateway.
This extension introduces one new IMAP command, a few capabilities and related response codes.
Servers implementing this extension announce its presence through the SENDMAIL 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.
The SENDMAIL command MAY contain submission options. Servers supporting voluntary features MUST indicate so by including the appropriate strings in the CAPABILITY responses. All capabilities used for these purposes use the SENDMAIL= prefix.
If the server supports user control of generating the Delivery Status Notifications (DSN), it MUST announce the SENDMAIL=DSN capability. Clients MUST NOT attempt to control DSN options through the DSN submission option unless the server announced SENDMAIL=DSN.
The following response codes are defined for communicating the reason why submission failed in a machine-readable way.
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, user's behavior and transaction history into account.
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 UID SENDMAIL command submits a message for delivery.
Arguments:
Responses: FETCH response with updated message flags
Result:
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 SHOULD atomically add the $Submitted flag to the message, as described in LEMONADE [RFC5550]. This transition MAY be hidden from any IMAP session or it MAY be visible in 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.
If the command failed, 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.
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 submission options. The server MUST respond with a tagged BAD if the client used unrecognized or unannounced submission option. If the server cannot honor a recognized and announced submission option, it MUST respond with a tagged NO with the POLICYDENIED response code and the message MUST NOT be submitted.
Servers MAY alter the message payload in conformance with best current practice about Internet mail. Individual recipients MAY receive different versions of the message. In particular, servers MAY change message headers so that the identity of addresses present in the Bcc headers is not revealed in some messages. However, such an action is OPTIONAL and concerned clients SHOULD use an explicit list of RECIPIENT submission options if they wish to conceal the identity of some recipients.
The following submission options are defined by this extension:
Syntax: one e-mail address
The FROM submission 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 submission option is present more than once.
Syntax: one e-mail address
The SENDER submission option corresponds to the SENDER field of the SMTP envelope. If not present, its value MUST be inferred from the computed value of the FROM submission option or from the message payload.
It is an error if the SENDER submission option is present more than once.
Syntax: delivery status notice specification
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.
It is an error if the DSN submission option is present multiple times.
Clients MUST NOT specify the DSN submission option unless the server announces the SENDMAIL=DSN capability. Support for the SENDMAIL=DSN submission option is OPTIONAL.
The DSN specification is either NIL to deactivate DSNs altogether, or a parenthesized list of any of the following options:
The order of DSN requests is not significant.
Syntax: one e-mail address
The RECIPIENT submission option corresponds to the TO field of the SMTP envelope.
The RECIPIENT submission option MAY be present more than once. Servers MAY impose a limit on the number of recipients of a single message.
If the RECIPIENT submission 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 submission options.
If the RECIPIENT submission 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 SHOULD 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 affect the user-specified list of recipients passed through the RECIPIENTS submission options.
Message submission MUST be atomic -- message is either submitted for delivery to all recipients, or it MUST NOT be submitted for delivery to anyone.
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, the Sender to bar@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 failures in message delivery.
C: x UID SENDMAIL 123 (FROM "foo@example.org"
SENDER "bar@example.org"
RECIPIENT "a@example.org"
RECIPIENT "b@example.org"
DSN (delay failure)
)
S: * 10 FETCH (UID 123 FLAGS ($Submitted))
S: x OK Message passed to the sendmail binary
In the following example, a message is delivered to addresses specified in the message payload. No submission options are given, and therefore the From and Sender envelope items are inferred from the actual payload. The DSN options, if supported, are set to an implementation-defined default value.
C: x UID SENDMAIL 123 S: * 10 FETCH (UID 123 FLAGS ($Submitted)) S: x OK Message passed to the sendmail binary
FIXME
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:
FIXME: response codes
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].
capability =/ "SENDMAIL" / "SENDMAIL=DSN"
uid =/ "UID" SP sendmail
sendmail = "SENDMAIL" SP uniqueid [SP submission-options]
submission-options = "(" submission-option *( SP submission-option ) ")"
submission-option = sub-option-from / sub-option-sender /
sub-option-recipient / sub-option-dsn
sub-option-from = "FROM" SP one-email-addr
;; MUST NOT be present more than once
sub-option-sender = "SENDER" SP one-email-addr
;; MUST NOT be present more than once
sub-option-recipient= "RECIPIENT" SP one-email-addr
;; MAY be present more than once
sub-option-dsn = "DSN" SP ( NIL / dsn-spec )
;; MUST NOT be present more than once
dsn-spec = "(" dsn-spec-item *( SP dsn-spec-item ) ")"
;; an individual dsn-spec-item MUST NOT
;; be present more than once
dsn-spec-item = "DELAY" / "FAILURE" / "SUCCESS"
one-email-addr = string
;; valid e-mail address as per [RFC5321]
This extension introduces a 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.
FIXME: better citations
FIXME: clarify order of inference for the FROM and SENDER submission options
What's got higher priority, SUBMISSIONRACE or POLICYDENIED? :)
IANA and the response codes