1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc4468.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,787 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                          C. Newman
    1.11 +Request for Comments: 4468                              Sun Microsystems
    1.12 +Updates: 3463                                                   May 2006
    1.13 +Category: Standards Track
    1.14 +
    1.15 +
    1.16 +                   Message Submission BURL Extension
    1.17 +
    1.18 +Status of This Memo
    1.19 +
    1.20 +   This document specifies an Internet standards track protocol for the
    1.21 +   Internet community, and requests discussion and suggestions for
    1.22 +   improvements.  Please refer to the current edition of the "Internet
    1.23 +   Official Protocol Standards" (STD 1) for the standardization state
    1.24 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.25 +
    1.26 +Copyright Notice
    1.27 +
    1.28 +   Copyright (C) The Internet Society (2006).
    1.29 +
    1.30 +Abstract
    1.31 +
    1.32 +   The submission profile of Simple Mail Transfer Protocol (SMTP)
    1.33 +   provides a standard way for an email client to submit a complete
    1.34 +   message for delivery.  This specification extends the submission
    1.35 +   profile by adding a new BURL command that can be used to fetch
    1.36 +   submission data from an Internet Message Access Protocol (IMAP)
    1.37 +   server.  This permits a mail client to inject content from an IMAP
    1.38 +   server into the SMTP infrastructure without downloading it to the
    1.39 +   client and uploading it back to the server.
    1.40 +
    1.41 +
    1.42 +
    1.43 +
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Newman                      Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 4468           Message Submission BURL Extension            May 2006
    1.64 +
    1.65 +
    1.66 +Table of Contents
    1.67 +
    1.68 +   1. Introduction ....................................................2
    1.69 +   2. Conventions Used in This Document ...............................2
    1.70 +   3. BURL Submission Extension .......................................3
    1.71 +      3.1. SMTP Submission Extension Registration .....................3
    1.72 +      3.2. BURL Transaction ...........................................3
    1.73 +      3.3. The BURL IMAP Options ......................................4
    1.74 +      3.4. Examples ...................................................5
    1.75 +      3.5. Formal Syntax ..............................................6
    1.76 +   4. 8-Bit and Binary ................................................7
    1.77 +   5. Updates to RFC 3463 .............................................7
    1.78 +   6. Response Codes ..................................................7
    1.79 +   7. IANA Considerations .............................................9
    1.80 +   8. Security Considerations .........................................9
    1.81 +   9. References .....................................................11
    1.82 +      9.1. Normative References ......................................11
    1.83 +      9.2. Informative References ....................................12
    1.84 +   Appendix A.  Acknowledgements .....................................13
    1.85 +
    1.86 +1.  Introduction
    1.87 +
    1.88 +   This specification defines an extension to the standard Message
    1.89 +   Submission [RFC4409] protocol to permit data to be fetched from an
    1.90 +   IMAP server at message submission time.  This MAY be used in
    1.91 +   conjunction with the CHUNKING [RFC3030] mechanism so that chunks of
    1.92 +   the message can come from an external IMAP server.  This provides the
    1.93 +   ability to forward an email message without first downloading it to
    1.94 +   the client.
    1.95 +
    1.96 +2.  Conventions Used in This Document
    1.97 +
    1.98 +   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
    1.99 +   in this document are to be interpreted as defined in "Key words for
   1.100 +   use in RFCs to Indicate Requirement Levels" [RFC2119].
   1.101 +
   1.102 +   The formal syntax uses the Augmented Backus-Naur Form (ABNF)
   1.103 +   [RFC4234] notation including the core rules defined in Appendix B of
   1.104 +   RFC 4234.
   1.105 +
   1.106 +
   1.107 +
   1.108 +
   1.109 +
   1.110 +
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Newman                      Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 4468           Message Submission BURL Extension            May 2006
   1.120 +
   1.121 +
   1.122 +3.  BURL Submission Extension
   1.123 +
   1.124 +   This section defines the BURL submission extension.
   1.125 +
   1.126 +3.1.  SMTP Submission Extension Registration
   1.127 +
   1.128 +   1.  The name of this submission extension is "BURL".  This extends
   1.129 +       the Message Submission protocol on port 587 and MUST NOT be
   1.130 +       advertised by a regular SMTP [RFC2821] server on port 25 that
   1.131 +       acts as a relay for incoming mail from other SMTP relays.
   1.132 +
   1.133 +   2.  The EHLO keyword value associated with the extension is "BURL".
   1.134 +
   1.135 +   3.  The BURL EHLO keyword will have zero or more arguments.  The only
   1.136 +       argument defined at this time is the "imap" argument, which MUST
   1.137 +       be present in order to use IMAP URLs with BURL.  Clients MUST
   1.138 +       ignore other arguments after the BURL EHLO keyword unless they
   1.139 +       are defined by a subsequent IETF standards track specification.
   1.140 +       The arguments that appear after the BURL EHLO keyword may change
   1.141 +       subsequent to the use of SMTP AUTH [RFC2554], so a server that
   1.142 +       advertises BURL with no arguments prior to authentication
   1.143 +       indicates that BURL is supported but authentication is required
   1.144 +       to use it.
   1.145 +
   1.146 +   4.  This extension adds the BURL SMTP verb.  This verb is used as a
   1.147 +       replacement for the DATA command and is only permitted during a
   1.148 +       mail transaction after at least one successful RCPT TO.
   1.149 +
   1.150 +3.2.  BURL Transaction
   1.151 +
   1.152 +   A simple BURL transaction will consist of MAIL FROM, one or more RCPT
   1.153 +   TO headers, and a BURL command with the "LAST" tag.  The BURL command
   1.154 +   will include an IMAP URL pointing to a fully formed message ready for
   1.155 +   injection into the SMTP infrastructure.  If PIPELINING [RFC2920] is
   1.156 +   advertised, the client MAY send the entire transaction in one round
   1.157 +   trip.  If no valid RCPT TO address is supplied, the BURL command will
   1.158 +   simply fail, and no resolution of the BURL URL argument will be
   1.159 +   performed.  If at least one valid RCPT TO address is supplied, then
   1.160 +   the BURL URL argument will be resolved before the server responds to
   1.161 +   the command.
   1.162 +
   1.163 +   A more sophisticated BURL transaction MAY occur when the server also
   1.164 +   advertises CHUNKING [RFC3030].  In this case, the BURL and BDAT
   1.165 +   commands may be interleaved until one of them terminates the
   1.166 +   transaction with the "LAST" argument.  If PIPELINING [RFC2920] is
   1.167 +   also advertised, then the client may pipeline the entire transaction
   1.168 +   in one round-trip.  However, it MUST wait for the results of the
   1.169 +   "LAST" BDAT or BURL command prior to initiating a new transaction.
   1.170 +
   1.171 +
   1.172 +
   1.173 +Newman                      Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 4468           Message Submission BURL Extension            May 2006
   1.176 +
   1.177 +
   1.178 +   The BURL command directs the server to fetch the data object to which
   1.179 +   the URL refers and include it in the message.  If the URL fetch
   1.180 +   fails, the server will fail the entire transaction.
   1.181 +
   1.182 +3.3.  The BURL IMAP Options
   1.183 +
   1.184 +   When "imap" is present in the space-separated list of arguments
   1.185 +   following the BURL EHLO keyword, it indicates that the BURL command
   1.186 +   supports the URLAUTH [RFC4467] extended form of IMAP URLs [RFC2192]
   1.187 +   and that the submit server is configured with the necessary
   1.188 +   credentials to resolve "urlauth=submit+" IMAP URLs for the submit
   1.189 +   server's domain.
   1.190 +
   1.191 +   Subsequent to a successful SMTP AUTH command, the submission server
   1.192 +   MAY indicate a prearranged trust relationship with a specific IMAP
   1.193 +   server by including a BURL EHLO keyword argument of the form
   1.194 +   "imap://imap.example.com".  In this case, the submission server will
   1.195 +   permit a regular IMAP URL referring to messages or parts of messages
   1.196 +   on imap.example.com that the user who authenticated to the submit
   1.197 +   server can access.  Note that this form does not imply that the
   1.198 +   submit server supports URLAUTH URLs; the submit server must advertise
   1.199 +   both "imap" and "imap://imap.example.com" to indicate support for
   1.200 +   both extended and non-extended URL forms.
   1.201 +
   1.202 +   When the submit server connects to the IMAP server, it acts as an
   1.203 +   IMAP client and thus is subject to both the mandatory-to-implement
   1.204 +   IMAP capabilities in Section 6.1.1 of RFC 3501, and the security
   1.205 +   considerations in Section 11 of RFC 3501.  Specifically, this
   1.206 +   requires that the submit server implement a configuration that uses
   1.207 +   STARTTLS followed by SASL PLAIN [SASL-PLAIN] to authenticate to the
   1.208 +   IMAP server.
   1.209 +
   1.210 +   When the submit server resolves a URLAUTH IMAP URL, it uses submit
   1.211 +   server credentials when authenticating to the IMAP server.  The
   1.212 +   authentication identity and password used for submit credentials MUST
   1.213 +   be configurable.  The string "submit" is suggested as a default value
   1.214 +   for the authentication identity, with no default for the password.
   1.215 +   Typically, the authorization identity is empty in this case; thus the
   1.216 +   IMAP server will derive the authorization identity from the
   1.217 +   authentication identity.  If the IMAP URL uses the "submit+" access
   1.218 +   identifier prefix, the submit server MUST refuse the BURL command
   1.219 +   unless the userid in the URL's <access> token matches the submit
   1.220 +   client's authorization identity.
   1.221 +
   1.222 +   When the submit server resolves a regular IMAP URL, it uses the
   1.223 +   submit client's authorization identity when authenticating to the
   1.224 +   IMAP server.  If both the submit client and the submit server's
   1.225 +   embedded IMAP client use SASL PLAIN (or the equivalent), the submit
   1.226 +
   1.227 +
   1.228 +
   1.229 +Newman                      Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 4468           Message Submission BURL Extension            May 2006
   1.232 +
   1.233 +
   1.234 +   server SHOULD forward the client's credentials if and only if the
   1.235 +   submit server knows that the IMAP server is in the same
   1.236 +   administrative domain.  If the submit server supports SASL mechanisms
   1.237 +   other than PLAIN, it MUST implement a configuration in which the
   1.238 +   submit server's embedded IMAP client uses STARTTLS and SASL PLAIN
   1.239 +   with the submit server's authentication identity and password (for
   1.240 +   the respective IMAP server) and the submit client's authorization
   1.241 +   identity.
   1.242 +
   1.243 +3.4.  Examples
   1.244 +
   1.245 +   In examples, "C:" and "S:" indicate lines sent by the client and
   1.246 +   server, respectively.  If a single "C:" or "S:" label applies to
   1.247 +   multiple lines, then the line breaks between those lines are for
   1.248 +   editorial clarity only and are not part of the actual protocol
   1.249 +   exchange.
   1.250 +
   1.251 +   Two successful submissions (without and with pipelining) follow:
   1.252 +
   1.253 +   <SSL/TLS encryption layer negotiated>
   1.254 +   C: EHLO potter.example.com
   1.255 +   S: 250-owlry.example.com
   1.256 +   S: 250-8BITMIME
   1.257 +   S: 250-BURL imap
   1.258 +   S: 250-AUTH PLAIN
   1.259 +   S: 250-DSN
   1.260 +   S: 250 ENHANCEDSTATUSCODES
   1.261 +   C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
   1.262 +   S: 235 2.7.0 PLAIN authentication successful.
   1.263 +   C: MAIL FROM:<harry@gryffindor.example.com>
   1.264 +   S: 250 2.5.0 Address Ok.
   1.265 +   C: RCPT TO:<ron@gryffindor.example.com>
   1.266 +   S: 250 2.1.5 ron@gryffindor.example.com OK.
   1.267 +   C: BURL imap://harry@gryffindor.example.com/outbox
   1.268 +           ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
   1.269 +           :internal:91354a473744909de610943775f92038 LAST
   1.270 +   S: 250 2.5.0 Ok.
   1.271 +
   1.272 +   <SSL/TLS encryption layer negotiated>
   1.273 +   C: EHLO potter.example.com
   1.274 +   S: 250-owlry.example.com
   1.275 +   S: 250-8BITMIME
   1.276 +   S: 250-PIPELINING
   1.277 +   S: 250-BURL imap
   1.278 +   S: 250-AUTH PLAIN
   1.279 +   S: 250-DSN
   1.280 +   S: 250 ENHANCEDSTATUSCODES
   1.281 +   C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
   1.282 +
   1.283 +
   1.284 +
   1.285 +Newman                      Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 4468           Message Submission BURL Extension            May 2006
   1.288 +
   1.289 +
   1.290 +   C: MAIL FROM:<harry@gryffindor.example.com>
   1.291 +   C: RCPT TO:<ron@gryffindor.example.com>
   1.292 +   C: BURL imap://harry@gryffindor.example.com/outbox
   1.293 +           ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
   1.294 +           :internal:91354a473744909de610943775f92038 LAST
   1.295 +   S: 235 2.7.0 PLAIN authentication successful.
   1.296 +   S: 250 2.5.0 Address Ok.
   1.297 +   S: 250 2.1.5 ron@gryffindor.example.com OK.
   1.298 +   S: 250 2.5.0 Ok.
   1.299 +
   1.300 +   Note that PIPELINING of the AUTH command is only permitted if the
   1.301 +   selected mechanism can be completed in one round trip, a client
   1.302 +   initial response is provided, and no SASL security layer is
   1.303 +   negotiated.  This is possible for PLAIN and EXTERNAL, but not for
   1.304 +   most other SASL mechanisms.
   1.305 +
   1.306 +   Some examples of failure cases:
   1.307 +
   1.308 +   C: MAIL FROM:<harry@gryffindor.example.com>
   1.309 +   C: RCPT TO:<malfoy@slitherin.example.com>
   1.310 +   C: BURL imap://harry@gryffindor.example.com/outbox
   1.311 +           ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
   1.312 +           :internal:91354a473744909de610943775f92038 LAST
   1.313 +   S: 250 2.5.0 Address Ok.
   1.314 +   S: 550 5.7.1 Relaying not allowed: malfoy@slitherin.example.com
   1.315 +   S: 554 5.5.0 No recipients have been specified.
   1.316 +
   1.317 +   C: MAIL FROM:<harry@gryffindor.example.com>
   1.318 +   C: RCPT TO:<ron@gryffindor.example.com>
   1.319 +   C: BURL imap://harry@gryffindor.example.com/outbox
   1.320 +           ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
   1.321 +           :internal:71354a473744909de610943775f92038 LAST
   1.322 +   S: 250 2.5.0 Address Ok.
   1.323 +   S: 250 2.1.5 ron@gryffindor.example.com OK.
   1.324 +   S: 554 5.7.0 IMAP URL authorization failed
   1.325 +
   1.326 +3.5.  Formal Syntax
   1.327 +
   1.328 +   The following syntax specification inherits ABNF [RFC4234] and
   1.329 +   Uniform Resource Identifiers [RFC3986].
   1.330 +
   1.331 +      burl-param  = "imap" / ("imap://" authority)
   1.332 +                  ; parameter to BURL EHLO keyword
   1.333 +
   1.334 +      burl-cmd    = "BURL" SP absolute-URI [SP end-marker] CRLF
   1.335 +
   1.336 +      end-marker  = "LAST"
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Newman                      Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 4468           Message Submission BURL Extension            May 2006
   1.344 +
   1.345 +
   1.346 +4.  8-Bit and Binary
   1.347 +
   1.348 +   A submit server that advertises BURL MUST also advertise 8BITMIME
   1.349 +   [RFC1652] and perform the down conversion described in that
   1.350 +   specification on the resulting complete message if 8-bit data is
   1.351 +   received with the BURL command and passed to a 7-bit server.  If the
   1.352 +   URL argument to BURL refers to binary data, then the submit server
   1.353 +   MAY refuse the command or down convert as described in Binary SMTP
   1.354 +   [RFC3030].
   1.355 +
   1.356 +   The Submit server MAY refuse to accept a BURL command or combination
   1.357 +   of BURL and BDAT commands that result in un-encoded 8-bit data in
   1.358 +   mail or MIME [RFC2045] headers.  Alternatively, the server MAY accept
   1.359 +   such data and down convert to MIME header encoding [RFC2047].
   1.360 +
   1.361 +5.  Updates to RFC 3463
   1.362 +
   1.363 +   SMTP or Submit servers that advertise ENHANCEDSTATUSCODES [RFC2034]
   1.364 +   use enhanced status codes defined in RFC 3463 [RFC3463].  The BURL
   1.365 +   extension introduces new error cases that that RFC did not consider.
   1.366 +   The following additional enhanced status codes are defined by this
   1.367 +   specification:
   1.368 +
   1.369 +   X.6.6 Message content not available
   1.370 +
   1.371 +      The message content could not be fetched from a remote system.
   1.372 +      This may be useful as a permanent or persistent temporary
   1.373 +      notification.
   1.374 +
   1.375 +   X.7.8 Trust relationship required
   1.376 +
   1.377 +      The submission server requires a configured trust relationship
   1.378 +      with a third-party server in order to access the message content.
   1.379 +
   1.380 +6.  Response Codes
   1.381 +
   1.382 +   This section includes example response codes to the BURL command.
   1.383 +   Other text may be used with the same response codes.  This list is
   1.384 +   not exhaustive, and BURL clients MUST tolerate any valid SMTP
   1.385 +   response code.  Most of these examples include the appropriate
   1.386 +   enhanced status code [RFC3463].
   1.387 +
   1.388 +   554 5.5.0 No recipients have been specified
   1.389 +
   1.390 +      This response code occurs when BURL is used (for example, with
   1.391 +      PIPELINING) and all RCPT TOs failed.
   1.392 +
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Newman                      Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 4468           Message Submission BURL Extension            May 2006
   1.400 +
   1.401 +
   1.402 +   503 5.5.0 Valid RCPT TO required before BURL
   1.403 +
   1.404 +      This response code is an alternative to the previous one when BURL
   1.405 +      is used (for example, with PIPELINING) and all RCPT TOs failed.
   1.406 +
   1.407 +   554 5.6.3 Conversion required but not supported
   1.408 +
   1.409 +      This response code occurs when the URL points to binary data and
   1.410 +      the implementation does not support down conversion to base64.
   1.411 +      This can also be used if the URL points to message data with 8-bit
   1.412 +      content in headers and the server does not down convert such
   1.413 +      content.
   1.414 +
   1.415 +   554 5.3.4 Message too big for system
   1.416 +
   1.417 +      The message (subsequent to URL resolution) is larger than the
   1.418 +      per-message size limit for this server.
   1.419 +
   1.420 +   554 5.7.8 URL resolution requires trust relationship
   1.421 +
   1.422 +      The submit server does not have a trust relationship with the IMAP
   1.423 +      server specified in the URL argument to BURL.
   1.424 +
   1.425 +   552 5.2.2 Mailbox full
   1.426 +
   1.427 +      The recipient is local, the submit server supports direct
   1.428 +      delivery, and the recipient has exceeded his quota and any grace
   1.429 +      period for delivery attempts.
   1.430 +
   1.431 +   554 5.6.6 IMAP URL resolution failed
   1.432 +
   1.433 +      The IMAP URLFETCH command returned an error or no data.
   1.434 +
   1.435 +   250 2.5.0 Waiting for additional BURL or BDAT commands
   1.436 +
   1.437 +      A BURL command without the "LAST" modifier was sent.  The URL for
   1.438 +      this BURL command was successfully resolved, but the content will
   1.439 +      not necessarily be committed to persistent storage until the rest
   1.440 +      of the message content is collected.  For example, a Unix server
   1.441 +      may have written the content to a queue file buffer, but may not
   1.442 +      yet have performed an fsync() operation.  If the server loses
   1.443 +      power, the content can still be lost.
   1.444 +
   1.445 +   451 4.4.1 IMAP server unavailable
   1.446 +
   1.447 +      The connection to the IMAP server to resolve the URL failed.
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Newman                      Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 4468           Message Submission BURL Extension            May 2006
   1.456 +
   1.457 +
   1.458 +   250 2.5.0 Ok.
   1.459 +
   1.460 +      The URL was successfully resolved, and the complete message data
   1.461 +      has been committed to persistent storage.
   1.462 +
   1.463 +   250 2.6.4 MIME header conversion with loss performed
   1.464 +
   1.465 +      The URL pointed to message data that included mail or MIME headers
   1.466 +      with 8-bit data.  This data was converted to MIME header encoding
   1.467 +      [RFC2047], but the submit server may not have correctly guessed
   1.468 +      the unlabeled character set.
   1.469 +
   1.470 +7.  IANA Considerations
   1.471 +
   1.472 +   The "BURL" SMTP extension as described in Section 3 has been
   1.473 +   registered.  This registration has been marked for use by message
   1.474 +   submission [RFC4409] only in the registry.
   1.475 +
   1.476 +8.  Security Considerations
   1.477 +
   1.478 +   Modern SMTP submission servers often include content-based security
   1.479 +   and denial-of-service defense mechanisms such as virus filtering,
   1.480 +   size limits, server-generated signatures, spam filtering, etc.
   1.481 +   Implementations of BURL should fetch the URL content prior to
   1.482 +   application of such content-based mechanisms in order to preserve
   1.483 +   their function.
   1.484 +
   1.485 +   Clients that generate unsolicited bulk email or email with viruses
   1.486 +   could use this mechanism to compensate for a slow link between the
   1.487 +   client and submit server.  In particular, this mechanism would make
   1.488 +   it feasible for a programmable cell phone or other device on a slow
   1.489 +   link to become a significant source of unsolicited bulk email and/or
   1.490 +   viruses.  This makes it more important for submit server vendors
   1.491 +   implementing BURL to have auditing and/or defenses against such
   1.492 +   denial-of-service attacks including mandatory authentication, logging
   1.493 +   that associates unique client identifiers with mail transactions,
   1.494 +   limits on reuse of the same IMAP URL, rate limits, recipient count
   1.495 +   limits, and content filters.
   1.496 +
   1.497 +   Transfer of the URLAUTH [RFC4467] form of IMAP URLs in the clear can
   1.498 +   expose the authorization token to network eavesdroppers.
   1.499 +   Implementations that support such URLs can address this issue by
   1.500 +   using a strong confidentiality protection mechanism.  For example,
   1.501 +   the SMTP STARTTLS [RFC3207] and the IMAP STARTTLS [RFC3501]
   1.502 +   extensions, in combination with a configuration setting that requires
   1.503 +   their use with such IMAP URLs, would address this concern.
   1.504 +
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Newman                      Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 4468           Message Submission BURL Extension            May 2006
   1.512 +
   1.513 +
   1.514 +   Use of a prearranged trust relationship between a submit server and a
   1.515 +   specific IMAP server introduces security considerations.  A
   1.516 +   compromise of the submit server should not automatically compromise
   1.517 +   all accounts on the IMAP server, so trust relationships involving
   1.518 +   super-user proxy credentials are strongly discouraged.  A system that
   1.519 +   requires the submit server to authenticate to the IMAP server with
   1.520 +   submit credentials and subsequently requires a URLAUTH URL to fetch
   1.521 +   any content addresses this concern.  A trusted third party model for
   1.522 +   proxy credentials (such as that provided by Kerberos 5 [RFC4120])
   1.523 +   would also suffice.
   1.524 +
   1.525 +   When a client uses SMTP STARTTLS to send a BURL command that
   1.526 +   references non-public information, there is a user expectation that
   1.527 +   the entire message content will be treated confidentially.  To
   1.528 +   address this expectation, the message submission server SHOULD use
   1.529 +   STARTTLS or a mechanism providing equivalent data confidentiality
   1.530 +   when fetching the content referenced by that URL.
   1.531 +
   1.532 +   A legitimate user of a submit server may try to compromise other
   1.533 +   accounts on the server by providing an IMAP URLAUTH URL that points
   1.534 +   to a server under that user's control that is designed to undermine
   1.535 +   the security of the submit server.  For this reason, the IMAP client
   1.536 +   code that the submit server uses must be robust with respect to
   1.537 +   arbitrary input sizes (including large IMAP literals) and arbitrary
   1.538 +   delays from the IMAP server.  Requiring a prearranged trust
   1.539 +   relationship between a submit server and the IMAP server also
   1.540 +   addresses this concern.
   1.541 +
   1.542 +   An authorized user of the submit server could set up a fraudulent
   1.543 +   IMAP server and pass a URL for that server to the submit server.  The
   1.544 +   submit server might then contact the fraudulent IMAP server to
   1.545 +   authenticate with submit credentials and fetch content.  There are
   1.546 +   several ways to mitigate this potential attack.  A submit server that
   1.547 +   only uses submit credentials with a fixed set of trusted IMAP servers
   1.548 +   will not be vulnerable to exposure of those credentials.  A submit
   1.549 +   server can treat the IMAP server as untrusted and include defenses
   1.550 +   for buffer overflows, denial-of-service slowdowns, and other
   1.551 +   potential attacks.  Finally, because authentication is required to
   1.552 +   use BURL, it is possible to keep a secure audit trail and use that to
   1.553 +   detect and punish the offending party.
   1.554 +
   1.555 +
   1.556 +
   1.557 +
   1.558 +
   1.559 +
   1.560 +
   1.561 +
   1.562 +
   1.563 +
   1.564 +
   1.565 +Newman                      Standards Track                    [Page 10]
   1.566 +
   1.567 +RFC 4468           Message Submission BURL Extension            May 2006
   1.568 +
   1.569 +
   1.570 +9.  References
   1.571 +
   1.572 +9.1.  Normative References
   1.573 +
   1.574 +   [RFC1652]     Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
   1.575 +                 Crocker, "SMTP Service Extension for
   1.576 +                 8bit-MIMEtransport", RFC 1652, July 1994.
   1.577 +
   1.578 +   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
   1.579 +                 Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.580 +
   1.581 +   [RFC2192]     Newman, C., "IMAP URL Scheme", RFC 2192,
   1.582 +                 September 1997.
   1.583 +
   1.584 +   [RFC2554]     Myers, J., "SMTP Service Extension for Authentication",
   1.585 +                 RFC 2554, March 1999.
   1.586 +
   1.587 +   [RFC2821]     Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
   1.588 +                 April 2001.
   1.589 +
   1.590 +   [RFC3207]     Hoffman, P., "SMTP Service Extension for Secure SMTP
   1.591 +                 over Transport Layer Security", RFC 3207,
   1.592 +                 February 2002.
   1.593 +
   1.594 +   [RFC3501]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
   1.595 +                 VERSION 4rev1", RFC 3501, March 2003.
   1.596 +
   1.597 +   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
   1.598 +                 "Uniform Resource Identifier (URI): Generic Syntax",
   1.599 +                 STD 66, RFC 3986, January 2005.
   1.600 +
   1.601 +   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
   1.602 +                 Specifications: ABNF", RFC 4234, October 2005.
   1.603 +
   1.604 +   [RFC4409]     Gellens, R. and J. Klensin, "Message Submission for
   1.605 +                 Mail", RFC 4409, April 2006.
   1.606 +
   1.607 +   [RFC4467]     Crispin, M., "Internet Message Access Protocol (IMAP) -
   1.608 +                 URLAUTH Extension", RFC 4467, May 2006.
   1.609 +
   1.610 +
   1.611 +
   1.612 +
   1.613 +
   1.614 +
   1.615 +
   1.616 +
   1.617 +
   1.618 +
   1.619 +
   1.620 +
   1.621 +Newman                      Standards Track                    [Page 11]
   1.622 +
   1.623 +RFC 4468           Message Submission BURL Extension            May 2006
   1.624 +
   1.625 +
   1.626 +9.2.  Informative References
   1.627 +
   1.628 +   [RFC2034]     Freed, N., "SMTP Service Extension for Returning
   1.629 +                 Enhanced Error Codes", RFC 2034, October 1996.
   1.630 +
   1.631 +   [RFC2045]     Freed, N. and N. Borenstein, "Multipurpose Internet
   1.632 +                 Mail Extensions (MIME) Part One: Format of Internet
   1.633 +                 Message Bodies", RFC 2045, November 1996.
   1.634 +
   1.635 +   [RFC2047]     Moore, K., "MIME (Multipurpose Internet Mail
   1.636 +                 Extensions) Part Three: Message Header Extensions for
   1.637 +                 Non-ASCII Text", RFC 2047, November 1996.
   1.638 +
   1.639 +   [RFC2920]     Freed, N., "SMTP Service Extension for Command
   1.640 +                 Pipelining", STD 60, RFC 2920, September 2000.
   1.641 +
   1.642 +   [RFC3030]     Vaudreuil, G., "SMTP Service Extensions for
   1.643 +                 Transmission of Large and Binary MIME Messages",
   1.644 +                 RFC 3030, December 2000.
   1.645 +
   1.646 +   [RFC3463]     Vaudreuil, G., "Enhanced Mail System Status Codes",
   1.647 +                 RFC 3463, January 2003.
   1.648 +
   1.649 +   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
   1.650 +                 Kerberos Network Authentication Service (V5)", RFC
   1.651 +                 4120, July 2005.
   1.652 +
   1.653 +   [SASL-PLAIN]  Zeilenga, K., "The Plain SASL Mechanism", Work in
   1.654 +                 Progress, March 2005.
   1.655 +
   1.656 +
   1.657 +
   1.658 +
   1.659 +
   1.660 +
   1.661 +
   1.662 +
   1.663 +
   1.664 +
   1.665 +
   1.666 +
   1.667 +
   1.668 +
   1.669 +
   1.670 +
   1.671 +
   1.672 +
   1.673 +
   1.674 +
   1.675 +
   1.676 +
   1.677 +Newman                      Standards Track                    [Page 12]
   1.678 +
   1.679 +RFC 4468           Message Submission BURL Extension            May 2006
   1.680 +
   1.681 +
   1.682 +Appendix A.  Acknowledgements
   1.683 +
   1.684 +   This document is a product of the lemonade WG.  Many thanks are due
   1.685 +   to all the participants of that working group for their input.  Mark
   1.686 +   Crispin was instrumental in the conception of this mechanism.  Thanks
   1.687 +   to Randall Gellens, Alexey Melnikov, Sam Hartman, Ned Freed, Dave
   1.688 +   Cridland, Peter Coates, and Mark Crispin for review comments on the
   1.689 +   document.  Thanks to the RFC Editor for correcting the author's
   1.690 +   grammar mistakes.  Thanks to Ted Hardie, Randall Gellens, Mark
   1.691 +   Crispin, Pete Resnick, and Greg Vaudreuil for extremely interesting
   1.692 +   debates comparing this proposal and alternatives.  Thanks to the
   1.693 +   lemonade WG chairs Eric Burger and Glenn Parsons for concluding the
   1.694 +   debate at the correct time and making sure this document got
   1.695 +   completed.
   1.696 +
   1.697 +Author's Address
   1.698 +
   1.699 +   Chris Newman
   1.700 +   Sun Microsystems
   1.701 +   3401 Centrelake Dr., Suite 410
   1.702 +   Ontario, CA  91761
   1.703 +   US
   1.704 +
   1.705 +   EMail: chris.newman@sun.com
   1.706 +
   1.707 +
   1.708 +
   1.709 +
   1.710 +
   1.711 +
   1.712 +
   1.713 +
   1.714 +
   1.715 +
   1.716 +
   1.717 +
   1.718 +
   1.719 +
   1.720 +
   1.721 +
   1.722 +
   1.723 +
   1.724 +
   1.725 +
   1.726 +
   1.727 +
   1.728 +
   1.729 +
   1.730 +
   1.731 +
   1.732 +
   1.733 +Newman                      Standards Track                    [Page 13]
   1.734 +
   1.735 +RFC 4468           Message Submission BURL Extension            May 2006
   1.736 +
   1.737 +
   1.738 +Full Copyright Statement
   1.739 +
   1.740 +   Copyright (C) The Internet Society (2006).
   1.741 +
   1.742 +   This document is subject to the rights, licenses and restrictions
   1.743 +   contained in BCP 78, and except as set forth therein, the authors
   1.744 +   retain all their rights.
   1.745 +
   1.746 +   This document and the information contained herein are provided on an
   1.747 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1.748 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   1.749 +   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   1.750 +   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   1.751 +   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1.752 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.753 +
   1.754 +Intellectual Property
   1.755 +
   1.756 +   The IETF takes no position regarding the validity or scope of any
   1.757 +   Intellectual Property Rights or other rights that might be claimed to
   1.758 +   pertain to the implementation or use of the technology described in
   1.759 +   this document or the extent to which any license under such rights
   1.760 +   might or might not be available; nor does it represent that it has
   1.761 +   made any independent effort to identify any such rights.  Information
   1.762 +   on the procedures with respect to rights in RFC documents can be
   1.763 +   found in BCP 78 and BCP 79.
   1.764 +
   1.765 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.766 +   assurances of licenses to be made available, or the result of an
   1.767 +   attempt made to obtain a general license or permission for the use of
   1.768 +   such proprietary rights by implementers or users of this
   1.769 +   specification can be obtained from the IETF on-line IPR repository at
   1.770 +   http://www.ietf.org/ipr.
   1.771 +
   1.772 +   The IETF invites any interested party to bring to its attention any
   1.773 +   copyrights, patents or patent applications, or other proprietary
   1.774 +   rights that may cover technology that may be required to implement
   1.775 +   this standard.  Please address the information to the IETF at
   1.776 +   ietf-ipr@ietf.org.
   1.777 +
   1.778 +Acknowledgement
   1.779 +
   1.780 +   Funding for the RFC Editor function is provided by the IETF
   1.781 +   Administrative Support Activity (IASA).
   1.782 +
   1.783 +
   1.784 +
   1.785 +
   1.786 +
   1.787 +
   1.788 +
   1.789 +Newman                      Standards Track                    [Page 14]
   1.790 +