Message Submission BURL Extension
The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. [STANDARDS-TRACK]
This document is current and has been amended. 1 later RFC has changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 9 must, 2 should, 7 may.
1 Introduction
- MAYThis MAY be used in conjunction with the CHUNKING [RFC3030] mechanism so that chunks of the message can come from an external IMAP server.
3.1 SMTP Submission Extension Registration
- MUST NOTThis extends the Message Submission protocol on port 587 and MUST NOT be advertised by a regular SMTP [RFC2821] server on port 25 that acts as a relay for incoming mail from other SMTP relays.
- MUSTThe only argument defined at this time is the "imap" argument, which MUST be present in order to use IMAP URLs with BURL.
- MUSTClients MUST ignore other arguments after the BURL EHLO keyword unless they are defined by a subsequent IETF standards track specification.
3.2 BURL Transaction
- MAYIf PIPELINING [RFC2920] is advertised, the client MAY send the entire transaction in one round trip.
- MAYA more sophisticated BURL transaction MAY occur when the server also advertises CHUNKING [RFC3030].
- MUSTHowever, it MUST wait for the results of the "LAST" BDAT or BURL command prior to initiating a new transaction.
3.3 The BURL IMAP Options
- MAYSubsequent to a successful SMTP AUTH command, the submission server MAY indicate a prearranged trust relationship with a specific IMAP server by including a BURL EHLO keyword argument of the form "imap://imap.example.com".
- MUSTThe authentication identity and password used for submit credentials MUST be configurable.
- MUSTIf the IMAP URL uses the "submit+" access identifier prefix, the submit server MUST refuse the BURL command unless the userid in the URL's <access> token matches the submit client's authorization identity.
- SHOULDserver SHOULD forward the client's credentials if and only if the submit server knows that the IMAP server is in the same administrative domain.
- MUSTIf the submit server supports SASL mechanisms other than PLAIN, it MUST implement a configuration in which the submit server's embedded IMAP client uses STARTTLS and SASL PLAIN with the submit server's authentication identity and password (for the respective IMAP server) and the submit client's authorization identity.
3.5 Formal Syntax
- MUSTA submit server that advertises BURL MUST also advertise 8BITMIME [RFC1652] and perform the down conversion described in that specification on the resulting complete message if 8-bit data is received with the BURL command and passed to a 7-bit server.
- MAYIf the URL argument to BURL refers to binary data, then the submit server MAY refuse the command or down convert as described in Binary SMTP [RFC3030].
- MAYThe Submit server MAY refuse to accept a BURL command or combination of BURL and BDAT commands that result in un-encoded 8-bit data in mail or MIME [RFC2045] headers.
- MAYAlternatively, the server MAY accept such data and down convert to MIME header encoding [RFC2047].
6 Response Codes
- MUSTThis list is not exhaustive, and BURL clients MUST tolerate any valid SMTP response code.
8 Security Considerations
- SHOULDTo address this expectation, the message submission server SHOULD use STARTTLS or a mechanism providing equivalent data confidentiality when fetching the content referenced by that URL.