diff options
Diffstat (limited to 'doc/rfc/rfc4468.txt')
| -rw-r--r-- | doc/rfc/rfc4468.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc4468.txt b/doc/rfc/rfc4468.txt new file mode 100644 index 0000000..b16dcb4 --- /dev/null +++ b/doc/rfc/rfc4468.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group C. Newman +Request for Comments: 4468 Sun Microsystems +Updates: 3463 May 2006 +Category: Standards Track + + + Message Submission BURL Extension + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + 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. + + + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 1] + +RFC 4468 Message Submission BURL Extension May 2006 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions Used in This Document ...............................2 + 3. BURL Submission Extension .......................................3 + 3.1. SMTP Submission Extension Registration .....................3 + 3.2. BURL Transaction ...........................................3 + 3.3. The BURL IMAP Options ......................................4 + 3.4. Examples ...................................................5 + 3.5. Formal Syntax ..............................................6 + 4. 8-Bit and Binary ................................................7 + 5. Updates to RFC 3463 .............................................7 + 6. Response Codes ..................................................7 + 7. IANA Considerations .............................................9 + 8. Security Considerations .........................................9 + 9. References .....................................................11 + 9.1. Normative References ......................................11 + 9.2. Informative References ....................................12 + Appendix A. Acknowledgements .....................................13 + +1. Introduction + + This specification defines an extension to the standard Message + Submission [RFC4409] protocol to permit data to be fetched from an + IMAP server at message submission time. This MAY be used in + conjunction with the CHUNKING [RFC3030] mechanism so that chunks of + the message can come from an external IMAP server. This provides the + ability to forward an email message without first downloading it to + the client. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as defined in "Key words for + use in RFCs to Indicate Requirement Levels" [RFC2119]. + + The formal syntax uses the Augmented Backus-Naur Form (ABNF) + [RFC4234] notation including the core rules defined in Appendix B of + RFC 4234. + + + + + + + + + + + + +Newman Standards Track [Page 2] + +RFC 4468 Message Submission BURL Extension May 2006 + + +3. BURL Submission Extension + + This section defines the BURL submission extension. + +3.1. SMTP Submission Extension Registration + + 1. The name of this submission extension is "BURL". This 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. + + 2. The EHLO keyword value associated with the extension is "BURL". + + 3. The BURL EHLO keyword will have zero or more arguments. The only + argument defined at this time is the "imap" argument, which MUST + be present in order to use IMAP URLs with BURL. Clients MUST + ignore other arguments after the BURL EHLO keyword unless they + are defined by a subsequent IETF standards track specification. + The arguments that appear after the BURL EHLO keyword may change + subsequent to the use of SMTP AUTH [RFC2554], so a server that + advertises BURL with no arguments prior to authentication + indicates that BURL is supported but authentication is required + to use it. + + 4. This extension adds the BURL SMTP verb. This verb is used as a + replacement for the DATA command and is only permitted during a + mail transaction after at least one successful RCPT TO. + +3.2. BURL Transaction + + A simple BURL transaction will consist of MAIL FROM, one or more RCPT + TO headers, and a BURL command with the "LAST" tag. The BURL command + will include an IMAP URL pointing to a fully formed message ready for + injection into the SMTP infrastructure. If PIPELINING [RFC2920] is + advertised, the client MAY send the entire transaction in one round + trip. If no valid RCPT TO address is supplied, the BURL command will + simply fail, and no resolution of the BURL URL argument will be + performed. If at least one valid RCPT TO address is supplied, then + the BURL URL argument will be resolved before the server responds to + the command. + + A more sophisticated BURL transaction MAY occur when the server also + advertises CHUNKING [RFC3030]. In this case, the BURL and BDAT + commands may be interleaved until one of them terminates the + transaction with the "LAST" argument. If PIPELINING [RFC2920] is + also advertised, then the client may pipeline the entire transaction + in one round-trip. However, it MUST wait for the results of the + "LAST" BDAT or BURL command prior to initiating a new transaction. + + + +Newman Standards Track [Page 3] + +RFC 4468 Message Submission BURL Extension May 2006 + + + The BURL command directs the server to fetch the data object to which + the URL refers and include it in the message. If the URL fetch + fails, the server will fail the entire transaction. + +3.3. The BURL IMAP Options + + When "imap" is present in the space-separated list of arguments + following the BURL EHLO keyword, it indicates that the BURL command + supports the URLAUTH [RFC4467] extended form of IMAP URLs [RFC2192] + and that the submit server is configured with the necessary + credentials to resolve "urlauth=submit+" IMAP URLs for the submit + server's domain. + + Subsequent 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". In this case, the submission server will + permit a regular IMAP URL referring to messages or parts of messages + on imap.example.com that the user who authenticated to the submit + server can access. Note that this form does not imply that the + submit server supports URLAUTH URLs; the submit server must advertise + both "imap" and "imap://imap.example.com" to indicate support for + both extended and non-extended URL forms. + + When the submit server connects to the IMAP server, it acts as an + IMAP client and thus is subject to both the mandatory-to-implement + IMAP capabilities in Section 6.1.1 of RFC 3501, and the security + considerations in Section 11 of RFC 3501. Specifically, this + requires that the submit server implement a configuration that uses + STARTTLS followed by SASL PLAIN [SASL-PLAIN] to authenticate to the + IMAP server. + + When the submit server resolves a URLAUTH IMAP URL, it uses submit + server credentials when authenticating to the IMAP server. The + authentication identity and password used for submit credentials MUST + be configurable. The string "submit" is suggested as a default value + for the authentication identity, with no default for the password. + Typically, the authorization identity is empty in this case; thus the + IMAP server will derive the authorization identity from the + authentication identity. If 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. + + When the submit server resolves a regular IMAP URL, it uses the + submit client's authorization identity when authenticating to the + IMAP server. If both the submit client and the submit server's + embedded IMAP client use SASL PLAIN (or the equivalent), the submit + + + +Newman Standards Track [Page 4] + +RFC 4468 Message Submission BURL Extension May 2006 + + + server SHOULD forward the client's credentials if and only if the + submit server knows that the IMAP server is in the same + administrative domain. If 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.4. Examples + + In examples, "C:" and "S:" indicate lines sent by the client and + server, respectively. If a single "C:" or "S:" label applies to + multiple lines, then the line breaks between those lines are for + editorial clarity only and are not part of the actual protocol + exchange. + + Two successful submissions (without and with pipelining) follow: + + <SSL/TLS encryption layer negotiated> + C: EHLO potter.example.com + S: 250-owlry.example.com + S: 250-8BITMIME + S: 250-BURL imap + S: 250-AUTH PLAIN + S: 250-DSN + S: 250 ENHANCEDSTATUSCODES + C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= + S: 235 2.7.0 PLAIN authentication successful. + C: MAIL FROM:<harry@gryffindor.example.com> + S: 250 2.5.0 Address Ok. + C: RCPT TO:<ron@gryffindor.example.com> + S: 250 2.1.5 ron@gryffindor.example.com OK. + C: BURL imap://harry@gryffindor.example.com/outbox + ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry + :internal:91354a473744909de610943775f92038 LAST + S: 250 2.5.0 Ok. + + <SSL/TLS encryption layer negotiated> + C: EHLO potter.example.com + S: 250-owlry.example.com + S: 250-8BITMIME + S: 250-PIPELINING + S: 250-BURL imap + S: 250-AUTH PLAIN + S: 250-DSN + S: 250 ENHANCEDSTATUSCODES + C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= + + + +Newman Standards Track [Page 5] + +RFC 4468 Message Submission BURL Extension May 2006 + + + C: MAIL FROM:<harry@gryffindor.example.com> + C: RCPT TO:<ron@gryffindor.example.com> + C: BURL imap://harry@gryffindor.example.com/outbox + ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry + :internal:91354a473744909de610943775f92038 LAST + S: 235 2.7.0 PLAIN authentication successful. + S: 250 2.5.0 Address Ok. + S: 250 2.1.5 ron@gryffindor.example.com OK. + S: 250 2.5.0 Ok. + + Note that PIPELINING of the AUTH command is only permitted if the + selected mechanism can be completed in one round trip, a client + initial response is provided, and no SASL security layer is + negotiated. This is possible for PLAIN and EXTERNAL, but not for + most other SASL mechanisms. + + Some examples of failure cases: + + C: MAIL FROM:<harry@gryffindor.example.com> + C: RCPT TO:<malfoy@slitherin.example.com> + C: BURL imap://harry@gryffindor.example.com/outbox + ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry + :internal:91354a473744909de610943775f92038 LAST + S: 250 2.5.0 Address Ok. + S: 550 5.7.1 Relaying not allowed: malfoy@slitherin.example.com + S: 554 5.5.0 No recipients have been specified. + + C: MAIL FROM:<harry@gryffindor.example.com> + C: RCPT TO:<ron@gryffindor.example.com> + C: BURL imap://harry@gryffindor.example.com/outbox + ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry + :internal:71354a473744909de610943775f92038 LAST + S: 250 2.5.0 Address Ok. + S: 250 2.1.5 ron@gryffindor.example.com OK. + S: 554 5.7.0 IMAP URL authorization failed + +3.5. Formal Syntax + + The following syntax specification inherits ABNF [RFC4234] and + Uniform Resource Identifiers [RFC3986]. + + burl-param = "imap" / ("imap://" authority) + ; parameter to BURL EHLO keyword + + burl-cmd = "BURL" SP absolute-URI [SP end-marker] CRLF + + end-marker = "LAST" + + + + +Newman Standards Track [Page 6] + +RFC 4468 Message Submission BURL Extension May 2006 + + +4. 8-Bit and Binary + + A 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. If 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]. + + The 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. Alternatively, the server MAY accept + such data and down convert to MIME header encoding [RFC2047]. + +5. Updates to RFC 3463 + + SMTP or Submit servers that advertise ENHANCEDSTATUSCODES [RFC2034] + use enhanced status codes defined in RFC 3463 [RFC3463]. The BURL + extension introduces new error cases that that RFC did not consider. + The following additional enhanced status codes are defined by this + specification: + + X.6.6 Message content not available + + The message content could not be fetched from a remote system. + This may be useful as a permanent or persistent temporary + notification. + + X.7.8 Trust relationship required + + The submission server requires a configured trust relationship + with a third-party server in order to access the message content. + +6. Response Codes + + This section includes example response codes to the BURL command. + Other text may be used with the same response codes. This list is + not exhaustive, and BURL clients MUST tolerate any valid SMTP + response code. Most of these examples include the appropriate + enhanced status code [RFC3463]. + + 554 5.5.0 No recipients have been specified + + This response code occurs when BURL is used (for example, with + PIPELINING) and all RCPT TOs failed. + + + + + +Newman Standards Track [Page 7] + +RFC 4468 Message Submission BURL Extension May 2006 + + + 503 5.5.0 Valid RCPT TO required before BURL + + This response code is an alternative to the previous one when BURL + is used (for example, with PIPELINING) and all RCPT TOs failed. + + 554 5.6.3 Conversion required but not supported + + This response code occurs when the URL points to binary data and + the implementation does not support down conversion to base64. + This can also be used if the URL points to message data with 8-bit + content in headers and the server does not down convert such + content. + + 554 5.3.4 Message too big for system + + The message (subsequent to URL resolution) is larger than the + per-message size limit for this server. + + 554 5.7.8 URL resolution requires trust relationship + + The submit server does not have a trust relationship with the IMAP + server specified in the URL argument to BURL. + + 552 5.2.2 Mailbox full + + The recipient is local, the submit server supports direct + delivery, and the recipient has exceeded his quota and any grace + period for delivery attempts. + + 554 5.6.6 IMAP URL resolution failed + + The IMAP URLFETCH command returned an error or no data. + + 250 2.5.0 Waiting for additional BURL or BDAT commands + + A BURL command without the "LAST" modifier was sent. The URL for + this BURL command was successfully resolved, but the content will + not necessarily be committed to persistent storage until the rest + of the message content is collected. For example, a Unix server + may have written the content to a queue file buffer, but may not + yet have performed an fsync() operation. If the server loses + power, the content can still be lost. + + 451 4.4.1 IMAP server unavailable + + The connection to the IMAP server to resolve the URL failed. + + + + + +Newman Standards Track [Page 8] + +RFC 4468 Message Submission BURL Extension May 2006 + + + 250 2.5.0 Ok. + + The URL was successfully resolved, and the complete message data + has been committed to persistent storage. + + 250 2.6.4 MIME header conversion with loss performed + + The URL pointed to message data that included mail or MIME headers + with 8-bit data. This data was converted to MIME header encoding + [RFC2047], but the submit server may not have correctly guessed + the unlabeled character set. + +7. IANA Considerations + + The "BURL" SMTP extension as described in Section 3 has been + registered. This registration has been marked for use by message + submission [RFC4409] only in the registry. + +8. Security Considerations + + Modern SMTP submission servers often include content-based security + and denial-of-service defense mechanisms such as virus filtering, + size limits, server-generated signatures, spam filtering, etc. + Implementations of BURL should fetch the URL content prior to + application of such content-based mechanisms in order to preserve + their function. + + Clients that generate unsolicited bulk email or email with viruses + could use this mechanism to compensate for a slow link between the + client and submit server. In particular, this mechanism would make + it feasible for a programmable cell phone or other device on a slow + link to become a significant source of unsolicited bulk email and/or + viruses. This makes it more important for submit server vendors + implementing BURL to have auditing and/or defenses against such + denial-of-service attacks including mandatory authentication, logging + that associates unique client identifiers with mail transactions, + limits on reuse of the same IMAP URL, rate limits, recipient count + limits, and content filters. + + Transfer of the URLAUTH [RFC4467] form of IMAP URLs in the clear can + expose the authorization token to network eavesdroppers. + Implementations that support such URLs can address this issue by + using a strong confidentiality protection mechanism. For example, + the SMTP STARTTLS [RFC3207] and the IMAP STARTTLS [RFC3501] + extensions, in combination with a configuration setting that requires + their use with such IMAP URLs, would address this concern. + + + + + +Newman Standards Track [Page 9] + +RFC 4468 Message Submission BURL Extension May 2006 + + + Use of a prearranged trust relationship between a submit server and a + specific IMAP server introduces security considerations. A + compromise of the submit server should not automatically compromise + all accounts on the IMAP server, so trust relationships involving + super-user proxy credentials are strongly discouraged. A system that + requires the submit server to authenticate to the IMAP server with + submit credentials and subsequently requires a URLAUTH URL to fetch + any content addresses this concern. A trusted third party model for + proxy credentials (such as that provided by Kerberos 5 [RFC4120]) + would also suffice. + + When a client uses SMTP STARTTLS to send a BURL command that + references non-public information, there is a user expectation that + the entire message content will be treated confidentially. To + 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. + + A legitimate user of a submit server may try to compromise other + accounts on the server by providing an IMAP URLAUTH URL that points + to a server under that user's control that is designed to undermine + the security of the submit server. For this reason, the IMAP client + code that the submit server uses must be robust with respect to + arbitrary input sizes (including large IMAP literals) and arbitrary + delays from the IMAP server. Requiring a prearranged trust + relationship between a submit server and the IMAP server also + addresses this concern. + + An authorized user of the submit server could set up a fraudulent + IMAP server and pass a URL for that server to the submit server. The + submit server might then contact the fraudulent IMAP server to + authenticate with submit credentials and fetch content. There are + several ways to mitigate this potential attack. A submit server that + only uses submit credentials with a fixed set of trusted IMAP servers + will not be vulnerable to exposure of those credentials. A submit + server can treat the IMAP server as untrusted and include defenses + for buffer overflows, denial-of-service slowdowns, and other + potential attacks. Finally, because authentication is required to + use BURL, it is possible to keep a secure audit trail and use that to + detect and punish the offending party. + + + + + + + + + + + +Newman Standards Track [Page 10] + +RFC 4468 Message Submission BURL Extension May 2006 + + +9. References + +9.1. Normative References + + [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. + Crocker, "SMTP Service Extension for + 8bit-MIMEtransport", RFC 1652, July 1994. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, + September 1997. + + [RFC2554] Myers, J., "SMTP Service Extension for Authentication", + RFC 2554, March 1999. + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP + over Transport Layer Security", RFC 3207, + February 2002. + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - + VERSION 4rev1", RFC 3501, March 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [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. + + + + + + + + + + + + +Newman Standards Track [Page 11] + +RFC 4468 Message Submission BURL Extension May 2006 + + +9.2. Informative References + + [RFC2034] Freed, N., "SMTP Service Extension for Returning + Enhanced Error Codes", RFC 2034, October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", RFC 2045, November 1996. + + [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail + Extensions) Part Three: Message Header Extensions for + Non-ASCII Text", RFC 2047, November 1996. + + [RFC2920] Freed, N., "SMTP Service Extension for Command + Pipelining", STD 60, RFC 2920, September 2000. + + [RFC3030] Vaudreuil, G., "SMTP Service Extensions for + Transmission of Large and Binary MIME Messages", + RFC 3030, December 2000. + + [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", + RFC 3463, January 2003. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC + 4120, July 2005. + + [SASL-PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in + Progress, March 2005. + + + + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 12] + +RFC 4468 Message Submission BURL Extension May 2006 + + +Appendix A. Acknowledgements + + This document is a product of the lemonade WG. Many thanks are due + to all the participants of that working group for their input. Mark + Crispin was instrumental in the conception of this mechanism. Thanks + to Randall Gellens, Alexey Melnikov, Sam Hartman, Ned Freed, Dave + Cridland, Peter Coates, and Mark Crispin for review comments on the + document. Thanks to the RFC Editor for correcting the author's + grammar mistakes. Thanks to Ted Hardie, Randall Gellens, Mark + Crispin, Pete Resnick, and Greg Vaudreuil for extremely interesting + debates comparing this proposal and alternatives. Thanks to the + lemonade WG chairs Eric Burger and Glenn Parsons for concluding the + debate at the correct time and making sure this document got + completed. + +Author's Address + + Chris Newman + Sun Microsystems + 3401 Centrelake Dr., Suite 410 + Ontario, CA 91761 + US + + EMail: chris.newman@sun.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 13] + +RFC 4468 Message Submission BURL Extension May 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Newman Standards Track [Page 14] + |