| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group G. Vaudreuil |
| 8 | Request for Comments: 3030 Lucent Technologies |
| 9 | Obsolete: 1830 December 2000 |
| 10 | Category: Standards Track |
| 11 | |
| 12 | |
| 13 | SMTP Service Extensions |
| 14 | for Transmission of Large |
| 15 | and Binary MIME Messages |
| 16 | |
| 17 | Status of this Memo |
| 18 | |
| 19 | This document specifies an Internet standards track protocol for the |
| 20 | Internet community, and requests discussion and suggestions for |
| 21 | improvements. Please refer to the current edition of the "Internet |
| 22 | Official Protocol Standards" (STD 1) for the standardization state |
| 23 | and status of this protocol. Distribution of this memo is unlimited. |
| 24 | |
| 25 | Copyright Notice |
| 26 | |
| 27 | Copyright (C) The Internet Society (2000). All Rights Reserved. |
| 28 | |
| 29 | Abstract |
| 30 | |
| 31 | This memo defines two extensions to the SMTP (Simple Mail Transfer |
| 32 | Protocol) service. The first extension enables a SMTP client and |
| 33 | server to negotiate the use of an alternative to the DATA command, |
| 34 | called "BDAT", for efficiently sending large MIME (Multipurpose |
| 35 | Internet Mail Extensions) messages. The second extension takes |
| 36 | advantage of the BDAT command to permit the negotiated sending of |
| 37 | MIME messages that employ the binary transfer encoding. This |
| 38 | document is intended to update and obsolete RFC 1830. |
| 39 | |
| 40 | Working Group Summary |
| 41 | |
| 42 | This protocol is not the product of an IETF working group, however |
| 43 | the specification resulted from discussions within the ESMTP working |
| 44 | group. The resulting protocol documented in RFC 1830 was classified |
| 45 | as experimental at that time due to questions about the robustness of |
| 46 | the Binary Content-Transfer-Encoding deployed in then existent MIME |
| 47 | implementations. As MIME has matured and other uses of the Binary |
| 48 | Content-Transfer-Encoding have been deployed, these concerns have |
| 49 | been allayed. With this document, Binary ESMTP is expected to become |
| 50 | standards-track. |
| 51 | |
| 52 | |
| 53 | |
| 54 | |
| 55 | |
| 56 | |
| 57 | |
| 58 | Vaudreuil Standards Track [Page 1] |
| 59 | |
| 60 | RFC 3030 Binary ESMTP December 2000 |
| 61 | |
| 62 | |
| 63 | Document Conventions |
| 64 | |
| 65 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| 66 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| 67 | document are to be interpreted as described in RFC 2119 [RFC2119]. |
| 68 | |
| 69 | Table of Contents |
| 70 | |
| 71 | 1. Overview ................................................... 2 |
| 72 | 2. Framework for the Large Message Extensions ................. 3 |
| 73 | 3. Framework for the Binary Service Extension ................. 5 |
| 74 | 4. Examples ................................................... 8 |
| 75 | 4.1 Simple Chunking .......................................... 8 |
| 76 | 4.2 Pipelining BINARYMIME .................................... 8 |
| 77 | 5. Security Considerations .................................... 9 |
| 78 | 6. References ................................................. 9 |
| 79 | 7. Author's Address ........................................... 10 |
| 80 | 8. Appendix A - Changes from RFC 1830 ......................... 11 |
| 81 | 9. Full Copyright Statement ................................... 12 |
| 82 | |
| 83 | 1. Overview |
| 84 | |
| 85 | The MIME extensions to the Internet message format provides for the |
| 86 | transmission of many kinds of data that were previously unsupported |
| 87 | in Internet mail. Anticipating the need to transport the new media |
| 88 | more efficiently, the SMTP protocol has been extended to provide |
| 89 | transport for new message types. RFC 1652 defines one such extension |
| 90 | for the transmission of unencoded 8-bit MIME messages [8BIT]. This |
| 91 | service extension permits the receiver SMTP to declare support for |
| 92 | 8-bit body parts and the sender to request 8-bit transmission of a |
| 93 | particular message. |
| 94 | |
| 95 | One expected result of the use of MIME is that the Internet mail |
| 96 | system will be expected to carry very large mail messages. In such |
| 97 | transactions, there is a performance-based desire to eliminate the |
| 98 | requirement that the message be scanned for "CR LF . CR LF" sequences |
| 99 | upon sending and receiving to detect the end of message. |
| 100 | |
| 101 | Independent of the need to send large messages, Internet mail is |
| 102 | increasingly multimedia. There is a need to avoid the overhead of |
| 103 | base64 and quoted-printable encoding of binary objects sent using the |
| 104 | MIME message format over SMTP between hosts that support binary |
| 105 | message processing. |
| 106 | |
| 107 | |
| 108 | |
| 109 | |
| 110 | |
| 111 | |
| 112 | |
| 113 | |
| 114 | Vaudreuil Standards Track [Page 2] |
| 115 | |
| 116 | RFC 3030 Binary ESMTP December 2000 |
| 117 | |
| 118 | |
| 119 | This memo uses the mechanism defined in [ESMTP] to define two |
| 120 | extensions to the SMTP service whereby an SMTP server ("receiver- |
| 121 | SMTP") may declare support for the message chunking transmission mode |
| 122 | and support for the reception of Binary messages, which the SMTP |
| 123 | client ("sender-SMTP") is then free to use. |
| 124 | |
| 125 | 2. Framework for the Large Message Extensions |
| 126 | |
| 127 | The following service extension is hereby defined: |
| 128 | |
| 129 | 1) The name of the data chunking service extension is "CHUNKING". |
| 130 | |
| 131 | 2) The EHLO keyword value associated with this extension is |
| 132 | "CHUNKING". |
| 133 | |
| 134 | 3) A new SMTP verb, BDAT, is defined as an alternative to the "DATA" |
| 135 | command of [RFC821]. The BDAT verb takes two arguments. The |
| 136 | first argument indicates the length, in octets, of the binary data |
| 137 | chunk. The second optional argument indicates that the data chunk |
| 138 | is the last. |
| 139 | |
| 140 | bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF |
| 141 | chunk-size ::= 1*DIGIT |
| 142 | end-marker ::= "LAST" |
| 143 | |
| 144 | 4) This extension may be used for SMTP message submission. [Submit] |
| 145 | |
| 146 | 5) Servers that offer the BDAT extension MUST continue to support the |
| 147 | regular SMTP DATA command. Clients are free to use DATA to |
| 148 | transfer appropriately encoded to servers that support the |
| 149 | CHUNKING extension if they wish to do so. |
| 150 | |
| 151 | The CHUNKING service extension enables the use of the BDAT |
| 152 | alternative to the DATA command. This extension can be used for any |
| 153 | message, whether 7-bit, 8BITMIME or BINARYMIME. |
| 154 | |
| 155 | When a sender-SMTP wishes to send (using the MAIL command) a large |
| 156 | message using the CHUNKING extension, it first issues the EHLO |
| 157 | command to the receiver-SMTP. If the receiver-SMTP responds with |
| 158 | code 250 to the EHLO command and the response includes the EHLO |
| 159 | keyword value CHUNKING, then the receiver-SMTP is indicating that it |
| 160 | supports the BDAT command and will accept the sending of messages in |
| 161 | chunks. |
| 162 | |
| 163 | After all MAIL and RCPT responses are collected and processed, the |
| 164 | message is sent using a series of BDAT commands. The BDAT command |
| 165 | takes one required argument, the exact length of the data segment in |
| 166 | |
| 167 | |
| 168 | |
| 169 | |
| 170 | Vaudreuil Standards Track [Page 3] |
| 171 | |
| 172 | RFC 3030 Binary ESMTP December 2000 |
| 173 | |
| 174 | |
| 175 | octets. The message data is sent immediately after the trailing <CR> |
| 176 | <LF> of the BDAT command line. Once the receiver-SMTP receives the |
| 177 | specified number of octets, it will return a 250 reply code. |
| 178 | |
| 179 | The optional LAST parameter on the BDAT command indicates that this |
| 180 | is the last chunk of message data to be sent. The last BDAT command |
| 181 | MAY have a byte-count of zero indicating there is no additional data |
| 182 | to be sent. Any BDAT command sent after the BDAT LAST is illegal and |
| 183 | MUST be replied to with a 503 "Bad sequence of commands" reply code. |
| 184 | The state resulting from this error is indeterminate. A RSET command |
| 185 | MUST be sent to clear the transaction before continuing. |
| 186 | |
| 187 | A 250 response MUST be sent to each successful BDAT data block within |
| 188 | a mail transaction. If a failure occurs after a BDAT command is |
| 189 | received, the receiver-SMTP MUST accept and discard the associated |
| 190 | message data before sending the appropriate 5XX or 4XX code. If a |
| 191 | 5XX or 4XX code is received by the sender-SMTP in response to a BDAT |
| 192 | chunk, the transaction should be considered failed and the sender- |
| 193 | SMTP MUST NOT send any additional BDAT segments. If the receiver- |
| 194 | SMTP has declared support for command pipelining [PIPE], the receiver |
| 195 | SMTP MUST be prepared to accept and discard additional BDAT chunks |
| 196 | already in the pipeline after the failed BDAT. |
| 197 | |
| 198 | Note: An error on the receiver-SMTP such as disk full or imminent |
| 199 | shutdown can only be reported after the BDAT segment has been |
| 200 | received. It is therefore important to choose a reasonable chunk |
| 201 | size given the expected end-to-end bandwidth. |
| 202 | |
| 203 | Note: Because the receiver-SMTP does not acknowledge the BDAT |
| 204 | command before the message data is sent, it is important to send |
| 205 | the BDAT only to systems that have declared their capability to |
| 206 | accept BDAT commands. Illegally sending a BDAT command and |
| 207 | associated message data to a non-CHUNKING capable system will |
| 208 | result in the receiver-SMTP parsing the associated message data as |
| 209 | if it were a potentially very long, ESMTP command line containing |
| 210 | binary data. |
| 211 | |
| 212 | The resulting state from a failed BDAT command is indeterminate. A |
| 213 | RSET command MUST be issued to clear the transaction before |
| 214 | additional commands may be sent. The RSET command, when issued after |
| 215 | the first BDAT and before the BDAT LAST, clears all segments sent |
| 216 | during that transaction and resets the session. |
| 217 | |
| 218 | DATA and BDAT commands cannot be used in the same transaction. If a |
| 219 | DATA statement is issued after a BDAT for the current transaction, a |
| 220 | 503 "Bad sequence of commands" MUST be issued. The state resulting |
| 221 | from this error is indeterminate. A RSET command MUST be sent to |
| 222 | |
| 223 | |
| 224 | |
| 225 | |
| 226 | Vaudreuil Standards Track [Page 4] |
| 227 | |
| 228 | RFC 3030 Binary ESMTP December 2000 |
| 229 | |
| 230 | |
| 231 | clear the transaction before continuing. There is no prohibition on |
| 232 | using DATA and BDAT in the same session, so long as they are not |
| 233 | mixed in the same transaction. |
| 234 | |
| 235 | The local storage size of a message may not accurately reflect the |
| 236 | actual size of the message sent due to local storage conventions. In |
| 237 | particular, text messages sent with the BDAT command MUST be sent in |
| 238 | the canonical MIME format with lines delimited with a <CR><LF>. It |
| 239 | may not be possible to convert the entire message to the canonical |
| 240 | format at once. CHUNKING provides a mechanism to convert the message |
| 241 | to canonical form, accurately count the bytes, and send the message a |
| 242 | single chunk at a time. |
| 243 | |
| 244 | Note: Correct byte counting is essential. If the sender-SMTP |
| 245 | indicates a chunk-size larger than the actual chunk-size, the |
| 246 | receiver-SMTP will continue to wait for the remainder of the data |
| 247 | or when using streaming, will read the subsequent command as |
| 248 | additional message data. In the case where a portion of the |
| 249 | previous command was read as data, the parser will return a syntax |
| 250 | error when the incomplete command is read. |
| 251 | |
| 252 | If the sender-SMTP indicates a chunk-size smaller than the actual |
| 253 | chunk-size, the receiver-SMTP will interpret the remainder of the |
| 254 | message data as invalid commands. Note that the remainder of the |
| 255 | message data may be binary and as such lexicographical parsers |
| 256 | MUST be prepared to receive, process, and reject lines of |
| 257 | arbitrary octets. |
| 258 | |
| 259 | 3. Framework for the Binary Service Extension |
| 260 | |
| 261 | The following service extension is hereby defined: |
| 262 | |
| 263 | 1) The name of the binary service extension is "BINARYMIME". |
| 264 | |
| 265 | 2) The EHLO keyword value associated with this extension is |
| 266 | "BINARYMIME". |
| 267 | |
| 268 | 3) The BINARYMIME service extension can only be used with the |
| 269 | "CHUNKING" service extension. |
| 270 | |
| 271 | 4) No parameter is used with the BINARYMIME keyword. |
| 272 | |
| 273 | 5) [8BIT] defines the BODY parameter for the MAIL command. This |
| 274 | extension defines an additional value for the BODY parameter, |
| 275 | "BINARYMIME". The value "BINARYMIME" associated with this |
| 276 | parameter indicates that this message is a Binary MIME message (in |
| 277 | |
| 278 | |
| 279 | |
| 280 | |
| 281 | |
| 282 | Vaudreuil Standards Track [Page 5] |
| 283 | |
| 284 | RFC 3030 Binary ESMTP December 2000 |
| 285 | |
| 286 | |
| 287 | strict compliance with [MIME]) with arbitrary octet content being |
| 288 | sent. The revised syntax of the value is as follows, using the |
| 289 | ABNF notation of [RFC822]: |
| 290 | |
| 291 | body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME" |
| 292 | |
| 293 | 6) No new verbs are defined for the BINARYMIME extension. |
| 294 | |
| 295 | 7) This extension may be used for SMTP message submission. [Submit] |
| 296 | |
| 297 | 8) The maximum length of a MAIL FROM command line is increased by 16 |
| 298 | characters by the possible addition of the BODY=BINARYMIME keyword |
| 299 | and value;. |
| 300 | |
| 301 | A sender-SMTP may request that a binary MIME message be sent without |
| 302 | transport encoding by sending a BODY parameter with a value of |
| 303 | "BINARYMIME" with the MAIL command. When the receiver-SMTP accepts a |
| 304 | MAIL command with the BINARYMIME body-value, it agrees to preserve |
| 305 | all bits in each octet passed using the BDAT command. Once a |
| 306 | receiver-SMTP supporting the BINARYMIME service extension accepts a |
| 307 | message containing binary material, the receiver-SMTP MUST deliver or |
| 308 | relay the message in such a way as to preserve all bits in each |
| 309 | octet. |
| 310 | |
| 311 | BINARYMIME cannot be used with the DATA command. If a DATA command |
| 312 | is issued after a MAIL command containing the body-value of |
| 313 | "BINARYMIME", a 503 "Bad sequence of commands" response MUST be sent. |
| 314 | The resulting state from this error condition is indeterminate and |
| 315 | the transaction MUST be reset with the RSET command. |
| 316 | |
| 317 | It is especially important when using BINARYMIME to ensure that the |
| 318 | MIME message itself is properly formed. In particular, it is |
| 319 | essential that text be canonically encoded with each line properly |
| 320 | terminated with <CR><LF>. Any transformation of text into non- |
| 321 | canonical MIME to observe local storage conventions MUST be reversed |
| 322 | before sending as BINARYMIME. Some line-oriented shortcuts will |
| 323 | break if used with BINARYMIME. A sender-SMTP MUST use the canonical |
| 324 | encoding for a given MIME content-type. In particular, text/* MUST |
| 325 | be sent with <CR><LF> terminated lines. |
| 326 | |
| 327 | Note: Although CR and LF do not necessarily represent ends of text |
| 328 | lines in BDAT chunks and use of the binary transfer encoding is |
| 329 | allowed, the RFC 2781 prohibition against using a UTF-16 charset |
| 330 | within the text top-level media type remains. |
| 331 | |
| 332 | |
| 333 | |
| 334 | |
| 335 | |
| 336 | |
| 337 | |
| 338 | Vaudreuil Standards Track [Page 6] |
| 339 | |
| 340 | RFC 3030 Binary ESMTP December 2000 |
| 341 | |
| 342 | |
| 343 | The syntax of the extended MAIL command is identical to the MAIL |
| 344 | command in [RFC821], except that a BODY=BINARYMIME parameter and |
| 345 | value MUST be added. The complete syntax of this extended command is |
| 346 | defined in [ESMTP]. |
| 347 | |
| 348 | If a receiver-SMTP does not indicate support the BINARYMIME message |
| 349 | format then the sender-SMTP MUST NOT, under any circumstances, send |
| 350 | binary data. |
| 351 | |
| 352 | If the receiver-SMTP does not support BINARYMIME and the message to |
| 353 | be sent is a MIME object with a binary encoding, a sender-SMTP has |
| 354 | three options with which to forward the message. First, if the |
| 355 | receiver-SMTP supports the 8bit-MIMEtransport extension [8bit] and |
| 356 | the content is amenable to being encoded in 8bit, the sender-SMTP may |
| 357 | implement a gateway transformation to convert the message into valid |
| 358 | 8bit-encoded MIME. Second, it may implement a gateway transformation |
| 359 | to convert the message into valid 7bit-encoded MIME. Third, it may |
| 360 | treat this as a permanent error and handle it in the usual manner for |
| 361 | delivery failures. The specifics of MIME content-transfer-encodings, |
| 362 | including transformations from Binary MIME to 8bit or 7bit MIME are |
| 363 | not described by this RFC; the conversion is nevertheless constrained |
| 364 | in the following ways: |
| 365 | |
| 366 | 1. The conversion MUST cause no loss of information; MIME |
| 367 | transport encodings MUST be employed as needed to insure this |
| 368 | is the case. |
| 369 | |
| 370 | 2. The resulting message MUST be valid 7bit or 8bit MIME. In |
| 371 | particular, the transformation MUST NOT result in nested Base- |
| 372 | 64 or Quoted-Printable content-transfer-encodings. |
| 373 | |
| 374 | Note that at the time of this writing there are no mechanisms for |
| 375 | converting a binary MIME object into an 8-bit MIME object. Such a |
| 376 | transformation will require the specification of a new MIME content- |
| 377 | transfer-encoding. |
| 378 | |
| 379 | If the MIME message contains a "Binary" content-transfer-encoding and |
| 380 | the BODY parameter does not indicate BINARYMIME, the message MUST be |
| 381 | accepted. The message SHOULD be returned to the sender with an |
| 382 | appropriate DSN. The message contents MAY be returned to the sender |
| 383 | if the offending content can be mangled into a legal DSN structure. |
| 384 | "Fixing" and forwarding the offending content is beyond the scope of |
| 385 | this document. |
| 386 | |
| 387 | |
| 388 | |
| 389 | |
| 390 | |
| 391 | |
| 392 | |
| 393 | |
| 394 | Vaudreuil Standards Track [Page 7] |
| 395 | |
| 396 | RFC 3030 Binary ESMTP December 2000 |
| 397 | |
| 398 | |
| 399 | 4. Examples |
| 400 | |
| 401 | 4.1 Simple Chunking |
| 402 | |
| 403 | The following simple dialogue illustrates the use of the large |
| 404 | message extension to send a short pseudo-RFC 822 message to one |
| 405 | recipient using the CHUNKING extension: |
| 406 | |
| 407 | R: <wait for connection on TCP port 25> |
| 408 | S: <open connection to server> |
| 409 | R: 220 cnri.reston.va.us SMTP service ready |
| 410 | S: EHLO ymir.claremont.edu |
| 411 | R: 250-cnri.reston.va.us says hello |
| 412 | R: 250 CHUNKING |
| 413 | S: MAIL FROM:<Sam@Random.com> |
| 414 | R: 250 <Sam@Random.com> Sender ok |
| 415 | S: RCPT TO:<Susan@Random.com> |
| 416 | R: 250 <Susan@random.com> Recipient ok |
| 417 | S: BDAT 86 LAST |
| 418 | S: To: Susan@random.com<CR><LF> |
| 419 | S: From: Sam@random.com<CR><LF> |
| 420 | S: Subject: This is a bodyless test message<CR><LF> |
| 421 | R: 250 Message OK, 86 octets received |
| 422 | S: QUIT |
| 423 | R: 221 Goodbye |
| 424 | |
| 425 | 4.2 Pipelining BINARYMIME |
| 426 | |
| 427 | The following dialogue illustrates the use of the large message |
| 428 | extension to send a BINARYMIME object to two recipients using the |
| 429 | CHUNKING and PIPELINING extensions: |
| 430 | |
| 431 | R: <wait for connection on TCP port |
| 432 | S: <open connection to server> |
| 433 | R: 220 cnri.reston.va.us SMTP service ready |
| 434 | S: EHLO ymir.claremont.edu |
| 435 | R: 250-cnri.reston.va.us says hello |
| 436 | R: 250-PIPELINING |
| 437 | R: 250-BINARYMIME |
| 438 | R: 250 CHUNKING |
| 439 | S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME |
| 440 | S: RCPT TO:<gvaudre@cnri.reston.va.us> |
| 441 | S: RCPT TO:<jstewart@cnri.reston.va.us> |
| 442 | R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok |
| 443 | R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok |
| 444 | R: 250 <jstewart@cnri.reston.va.us>... Recipient ok |
| 445 | S: BDAT 100000 |
| 446 | S: (First 10000 octets of canonical MIME message data) |
| 447 | |
| 448 | |
| 449 | |
| 450 | Vaudreuil Standards Track [Page 8] |
| 451 | |
| 452 | RFC 3030 Binary ESMTP December 2000 |
| 453 | |
| 454 | |
| 455 | S: BDAT 324 |
| 456 | S: (Remaining 324 octets of canonical MIME message data) |
| 457 | S: BDAT 0 LAST |
| 458 | R: 250 100000 octets received |
| 459 | R: 250 324 octets received |
| 460 | R: 250 Message OK, 100324 octets received |
| 461 | S: QUIT |
| 462 | R: 221 Goodbye |
| 463 | |
| 464 | 5. Security Considerations |
| 465 | |
| 466 | This extension is not known to present any additional security issues |
| 467 | not already endemic to electronic mail and present in fully |
| 468 | conforming implementations of [RFC821], or otherwise made possible by |
| 469 | [MIME]. |
| 470 | |
| 471 | 6. References |
| 472 | |
| 473 | [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of |
| 474 | Large and Binary MIME Messages", RFC 1830, August 1995. |
| 475 | |
| 476 | [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC |
| 477 | 821, August 1982. |
| 478 | |
| 479 | [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text |
| 480 | Messages", STD 11, RFC 822, August 1982. |
| 481 | |
| 482 | [MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail |
| 483 | Extensions (MIME) Part One: Format of Internet Message |
| 484 | Bodies", RFC 2045, November 1996. |
| 485 | |
| 486 | [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, |
| 487 | December 1998. |
| 488 | |
| 489 | [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. |
| 490 | Crocker, "SMTP Service Extensions", RFC 1869, November |
| 491 | 1995. |
| 492 | |
| 493 | [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. |
| 494 | Crocker, "SMTP Service Extension for 8bit-MIMEtransport", |
| 495 | RFC 1652, July 1994. |
| 496 | |
| 497 | [PIPE] Freed, N., "SMTP Service Extensions for Command |
| 498 | Pipelining", RFC 2920, September 2000. |
| 499 | |
| 500 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| 501 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| 502 | |
| 503 | |
| 504 | |
| 505 | |
| 506 | Vaudreuil Standards Track [Page 9] |
| 507 | |
| 508 | RFC 3030 Binary ESMTP December 2000 |
| 509 | |
| 510 | |
| 511 | 7. Author's Address |
| 512 | |
| 513 | Gregory M. Vaudreuil |
| 514 | Lucent Technologies |
| 515 | 17080 Dallas Parkway |
| 516 | Dallas, TX 75248-1905 |
| 517 | |
| 518 | Phone/Fax: +1-972-733-2722 |
| 519 | EMail: GregV@ieee.org |
| 520 | |
| 521 | |
| 522 | |
| 523 | |
| 524 | |
| 525 | |
| 526 | |
| 527 | |
| 528 | |
| 529 | |
| 530 | |
| 531 | |
| 532 | |
| 533 | |
| 534 | |
| 535 | |
| 536 | |
| 537 | |
| 538 | |
| 539 | |
| 540 | |
| 541 | |
| 542 | |
| 543 | |
| 544 | |
| 545 | |
| 546 | |
| 547 | |
| 548 | |
| 549 | |
| 550 | |
| 551 | |
| 552 | |
| 553 | |
| 554 | |
| 555 | |
| 556 | |
| 557 | |
| 558 | |
| 559 | |
| 560 | |
| 561 | |
| 562 | Vaudreuil Standards Track [Page 10] |
| 563 | |
| 564 | RFC 3030 Binary ESMTP December 2000 |
| 565 | |
| 566 | |
| 567 | Appendix A - Changes from RFC 1830 |
| 568 | |
| 569 | Numerous editorial changes including required intellectual property |
| 570 | boilerplate and revised authors contact information |
| 571 | |
| 572 | Corrected the simple chunking example to use the correct number of |
| 573 | bytes. Updated the pipelining example to illustrate use of the BDAT |
| 574 | 0 LAST construct. |
| 575 | |
| 576 | |
| 577 | |
| 578 | |
| 579 | |
| 580 | |
| 581 | |
| 582 | |
| 583 | |
| 584 | |
| 585 | |
| 586 | |
| 587 | |
| 588 | |
| 589 | |
| 590 | |
| 591 | |
| 592 | |
| 593 | |
| 594 | |
| 595 | |
| 596 | |
| 597 | |
| 598 | |
| 599 | |
| 600 | |
| 601 | |
| 602 | |
| 603 | |
| 604 | |
| 605 | |
| 606 | |
| 607 | |
| 608 | |
| 609 | |
| 610 | |
| 611 | |
| 612 | |
| 613 | |
| 614 | |
| 615 | |
| 616 | |
| 617 | |
| 618 | Vaudreuil Standards Track [Page 11] |
| 619 | |
| 620 | RFC 3030 Binary ESMTP December 2000 |
| 621 | |
| 622 | |
| 623 | Full Copyright Statement |
| 624 | |
| 625 | Copyright (C) The Internet Society (2000). All Rights Reserved. |
| 626 | |
| 627 | This document and translations of it may be copied and furnished to |
| 628 | others, and derivative works that comment on or otherwise explain it |
| 629 | or assist in its implementation may be prepared, copied, published |
| 630 | and distributed, in whole or in part, without restriction of any |
| 631 | kind, provided that the above copyright notice and this paragraph are |
| 632 | included on all such copies and derivative works. However, this |
| 633 | document itself may not be modified in any way, such as by removing |
| 634 | the copyright notice or references to the Internet Society or other |
| 635 | Internet organizations, except as needed for the purpose of |
| 636 | developing Internet standards in which case the procedures for |
| 637 | copyrights defined in the Internet Standards process must be |
| 638 | followed, or as required to translate it into languages other than |
| 639 | English. |
| 640 | |
| 641 | The limited permissions granted above are perpetual and will not be |
| 642 | revoked by the Internet Society or its successors or assigns. |
| 643 | |
| 644 | This document and the information contained herein is provided on an |
| 645 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
| 646 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
| 647 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
| 648 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
| 649 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
| 650 | |
| 651 | Acknowledgement |
| 652 | |
| 653 | Funding for the RFC Editor function is currently provided by the |
| 654 | Internet Society. |
| 655 | |
| 656 | |
| 657 | |
| 658 | |
| 659 | |
| 660 | |
| 661 | |
| 662 | |
| 663 | |
| 664 | |
| 665 | |
| 666 | |
| 667 | |
| 668 | |
| 669 | |
| 670 | |
| 671 | |
| 672 | |
| 673 | |
| 674 | Vaudreuil Standards Track [Page 12] |
| 675 | |