]>

Eledrova 558 Prague 181 00 CZ jkt@flaska.net

General Internet Engineering Task Force IMAP SMTP ESMTP submission submit sendmail 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.

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 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 mandates full support for BURL and URLAUTH 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 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 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 changes the trust paths which are required to exist between the submission and the IMAP servers. When combined with the existing CATENATE extension , the SUBMIT command works at least as effectively as the Lemonade trio of CATENATE/BURL/URLAUTH.

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.

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 server checks the passed data and submission 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.

This extension introduces one new IMAP command, a few related response codes and a new family of the IMAP capabilities.

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.

The SUBMIT commands issued by the IMAP clients 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 begin with the SUBMIT= prefix.

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.

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 SUBMIT command submits a message for delivery. Arguments: UID of message to be sent optional list of submission options Responses: FETCH response with updated message flags Result: Message submitted for delivery Submission failed 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 , 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 . 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 fails, the server MUST clear both the $Submitted or $SubmitPending keywords. If the server supports CONDSTORE or QRESYNC 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 submission options. The server MUST respond with a tagged BAD if the client used unrecognized or unannounced submission option, or if a recognized submission option is used in an invalid way. 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 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 and . The copy stored on the IMAP server MUST NOT be altered by these modifications.

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. 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.

Syntax: one e-mail address The RECIPIENT submission option corresponds to the RCPT 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. 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 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 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 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. Actual delivery MAY still fail for certain recipients.

Syntax: delivery status notice specification The DSN options are specified per-recipient, not per-message, and therefore their syntax is different from the other submission options. 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 mandated by . 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 options: requests generating DSNs upon successful delivery of a message activates generating DSNs when delivery is delayed requests generating DSNs when the delivery fails The order of DSN requests is not significant.

Syntax: DSN return option specification This per-message submission option corresponds to the RET=... parameter from . 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-ENVID return option unless the server announces the SUBMIT=DSN capability.

Syntax: specification of ESMTP Envelope ID This per-message submission option corresponds to the ENVID=... parameter from . 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.

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.

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 To envelope items are inferred from the actual payload. The DSN options, if supported, are set to an implementation-defined default value.

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: SUBMIT SUBMIT=DSN FIXME: response codes

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in . Non-terminals referenced but not defined below are as defined by , or .

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] ]]>

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 servers open to users. The redirect command from SIEVE 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.

&RFC2119; &RFC5234; &RFC3501; &RFC3461; &RFC4409; &RFC4467; &RFC4468; &RFC4469; &RFC4551; &RFC5172; &RFC5228; &RFC5321; &RFC5322; &RFC5550;

What's got higher priority, SUBMISSIONRACE or POLICYDENIED? :) 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?

Renamed to SUBMIT DSNs are per-recipient, not per-message The introduction was rewritten Miscellaneous clarifications Changed DSN NIL to DSN NONE Clarified the semantics of the RECIPIENT submission option to guarantee Bcc privacy Editorial tweaks, including changes to the required SHOULD/MUST/... DSN's ENVID and RET

Removed the superfluous SENDER submission option Mandating Bcc removal in conformance with RFC 5321 / RFC 5322