idnits 2.17.1 draft-kundrat-imap-submit-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 26, 2013) is 4076 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 4551 (Obsoleted by RFC 7162) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Kundrat 3 Internet-Draft February 26, 2013 4 Intended status: Standards Track 5 Expires: August 28, 2013 7 IMAP SUBMIT Extension 8 draft-kundrat-imap-submit-01 10 Abstract 12 This document extends the IMAP protocol with a feature to submit 13 e-mail messages for delivery. It is intended to serve as a better 14 alternative to the URLAUTH/BURL approach. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 28, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 3 53 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4 54 3.1. New IMAP Capabilities . . . . . . . . . . . . . . . . . . 4 55 3.1.1. The SUBMIT Capability . . . . . . . . . . . . . . . . 4 56 3.1.2. The SUBMIT= Capabilities Family . . . . . . . . . . . 4 57 3.1.2.1. SUBMIT=DSN . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Additional Response Codes . . . . . . . . . . . . . . . . 4 59 3.2.1. The POLICYDENIED Response Code . . . . . . . . . . . . 4 60 3.2.2. The SUBMISSIONRACE Response Code . . . . . . . . . . . 4 61 3.3. UID SUBMIT command . . . . . . . . . . . . . . . . . . . . 4 62 3.3.1. Delivery options . . . . . . . . . . . . . . . . . . . 6 63 3.3.1.1. FROM Delivery Option . . . . . . . . . . . . . . . 6 64 3.3.1.1.1. DSN-ENVID Submission Option . . . . . . . . . 6 65 3.3.1.2. RECIPIENT Delivery Option . . . . . . . . . . . . 7 66 3.3.1.2.1. DSN Submission Option . . . . . . . . . . . . 7 67 3.3.1.2.2. DSN-RET Submission Option . . . . . . . . . . 8 68 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Appendix A. FIXME Items . . . . . . . . . . . . . . . . . . . . . 12 75 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 12 76 Appendix B.1. Changes in -01 since -00 . . . . . . . . . . . . 12 77 Appendix B.2. Changes in -00 since private-01 . . . . . . . . . 12 78 Appendix B.3. Changes in private-01 since private-00 . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 In the traditional IMAP/ESMTP service model, a MUA transfers each 84 outgoing message twice -- once for storing it in the user's "sent 85 mail" folder, and the second time for actual message submission over 86 (E)SMTP. Under certain circumstances, such as when the message 87 contains data which are already available in another message stored 88 on the same IMAP server (such as when forwarding an unread attachment 89 to another recipient), the MUA has to download the data before the 90 message can be composed, resulting in transmitting the data three 91 times in total. 93 Many proposals exist which aim to reduce this high number of 94 transfers to the lowest possible number. The CATENATE extension 95 [RFC4469] enables IMAP clients to have the IMAP servers compose 96 messages on their behalf, optionally using data already available on 97 the IMAP server. Using CATENATE, MUAs do not have to download 98 individual message parts before including them to the newly created 99 message. 101 The LEMONADE extension family [RFC5550] mandates full support for 102 BURL [RFC4468] and URLAUTH [RFC4467] extensions. When coupled with a 103 properly configured pair of ESMTP and IMAP servers, these two 104 extensions allow MUAs to have the submission server obtain the 105 message payload from the IMAP server. This approach completely 106 eliminates the need to upload the message data to the ESMTP server, 107 achieving the "forward-without-download" goal. 109 The BURL/URLAUTH extensions, however, put a significant burden on the 110 server operators who suddenly have to establish an explicit trust 111 relation between their submission and IMAP servers, and make this 112 trust path visible to the users' MUAs. No MUA-visible means of 113 discovering this trust relation are defined. Furthermore, the whole 114 scheme still requires the MUAs to maintain two distinct connections 115 speaking different protocols. Users are prompted for two sets of 116 credentials to authenticate to each of these two services. Real- 117 world support issues were reported where users are able to access 118 their IMAP service while access to the submission service is blocked 119 by a mis-configured firewall. 121 The SUBMIT extension of the IMAP protocol effectively moves the 122 message submission process to be initiated by a user's request to 123 their IMAP server. When deployed, this scenario provides a perfect 124 discoverability to the users' MUAs, saves the overhead of 125 establishing and securing a separate TCP connection against the 126 submission server, reduces the amount of the configuration data the 127 users are required to provide, and simplifies the trust paths which 128 are required to exist between the submission and the IMAP servers. 129 When combined with the existing CATENATE extension [RFC4469], the 130 SUBMIT command works at least as effectively as the Lemonade trio of 131 CATENATE/BURL/URLAUTH. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2. Mode of Operation 141 The SUBMIT extension adds the UID SUBMIT IMAP command which instructs 142 the IMAP server to arrange for delivery of an already existing IMAP 143 message. How this message is composed is outside of scope of this 144 extension, but it is assumed that clients will often use the APPEND 145 or APPEND ... CATENATE commands. 147 Upon receiving the SUBMIT command, the IMAP server is asked for 148 arranging the initial message submission. Clients MAY pass 149 additional data in form of various options of the SUBMIT command (the 150 delivery options). The server checks the passed data and delivery 151 options, optionally performs sanity checks on the message contents, 152 verifies against a local policy whether the user is authorized for 153 message submission, and if none of these checks fail, the server 154 passes the message for subsequent delivery. The delivery method is 155 outside of scope of this document, but typical methods would be 156 invoking a `sendmail`-compatible binary or passing the message to an 157 ESMTP gateway. 159 3. IMAP Protocol Changes 161 This extension introduces one new IMAP command, a few related 162 response codes and a new family of the IMAP capabilities. 164 3.1. New IMAP Capabilities 166 3.1.1. The SUBMIT Capability 168 Servers implementing this extension announce its presence through the 169 SUBMIT capability. If the server supports this extension but message 170 submission is unconditionally disabled by a security policy or 171 service configuration, this capability MUST NOT be announced. 173 3.1.2. The SUBMIT= Capabilities Family 175 The SUBMIT commands issued by the IMAP clients MAY contain delivery 176 options, and these options might contain other fine grained options. 177 Servers supporting voluntary features MUST indicate so by including 178 the appropriate strings in the CAPABILITY responses. All 179 capabilities used for these purposes begin with the SUBMIT= prefix. 181 3.1.2.1. SUBMIT=DSN 183 If the server supports user control of generating the Delivery Status 184 Notifications (DSN), it MUST announce the SUBMIT=DSN capability. 185 Clients MUST NOT attempt to control DSN options through the DSN 186 submission option unless the server announces the SUBMIT=DSN 187 capability. 189 3.2. Additional Response Codes 191 The following response codes are defined for communicating the reason 192 why submission failed in a machine-readable way. 194 3.2.1. The POLICYDENIED Response Code 196 The POLICYDENIED response code SHOULD be used if the server rejects 197 message submission as a result of a policy based decision which MAY 198 take the message content, user's behavior and transaction history 199 into account. 201 3.2.2. The SUBMISSIONRACE Response Code 203 The SUBMISSIONRACE response code MUST be sent in the tagged response 204 if the client asks for submission of a message that is either not 205 marked with the $SubmitPending keyword or marked with the $Submitted 206 keyword. 208 3.3. UID SUBMIT command 209 The UID SUBMIT command submits a message for delivery. 211 Arguments: 213 o UID of message to be sent 215 o optional list of delivery options 217 Responses: FETCH response with updated message flags 219 Result: 221 OK Message submitted for delivery 223 NO Submission failed 225 BAD Invalid commands or options 227 This command is only valid in the selected state. 229 The server MUST check its local policy configuration and verify that 230 the authenticated user is allowed to submit messages. The decision 231 MAY be based on the user's credentials, the message contents, past 232 history of the user, or any other criteria the server deems relevant. 233 The server SHOULD take into account any other local policies before 234 it proceeds with further submission. 236 Clients MUST NOT submit a message which is either not marked with the 237 $SubmitPending keyword from [RFC5550], or which is marked with the 238 $Submitted keyword. Servers MUST reject such a command with a tagged 239 NO bearing the SUBMISSIONRACE response code. 241 In the course of submission, servers MUST atomically add the 242 $Submitted flag to the message, as described in LEMONADE [RFC5550]. 243 A transient state where the message is temporarily marked with both 244 $Submitted and $SubmitPending flags MAY be hidden from any IMAP 245 session or it MAY be visible in all of them. 247 If the command succeeded, the message MUST be marked with the 248 $Submitted keyword, the $SubmitPending keyword MUST be cleared and a 249 FETCH response containing the message UID and its new flags MUST be 250 sent. 252 If the command fails, the server MUST clear both the $Submitted or 253 $SubmitPending keywords. 255 If the server supports CONDSTORE [RFC4551] or QRESYNC [RFC5172] 256 extensions, any flag changes MUST obey the usual MODSEQ invariants. 257 Any changes in the MODSEQ values MUST be communicated to the clients, 258 as mandated by the relevant extensions. 260 Clients MUST be prepared to handle failing submission at any time. 262 Servers MAY reject message submission for any reason. 264 The server MUST process all specified delivery options and their 265 detailed options. The server MUST respond with a tagged BAD if the 266 client used unrecognized or unannounced option, or if a recognized 267 option is used in an invalid way. If the server cannot honor a 268 recognized and announced option, it MUST respond with a tagged NO 269 with the POLICYDENIED response code and the message MUST NOT be 270 submitted, nor its flags changed. 272 Servers MAY alter the message payload of the outgoing message in 273 conformance with best current practice about Internet mail. 274 Individual recipients MAY receive different versions of the message. 275 In particular, servers MUST change message headers so that the 276 identity of addresses present in the Bcc headers is not revealed to 277 other recipients. This mode of operation is described in [RFC5321] 278 and [RFC5322]. The copy stored on the IMAP server MUST NOT be 279 altered by these modifications. 281 3.3.1. Delivery options 283 The following two delivery options are defined by this extension. 284 These options apply to the message as a whole: 286 3.3.1.1. FROM Delivery Option 288 Syntax: one e-mail address with optional further data 290 The FROM delivery option corresponds to the FROM field of the SMTP 291 envelope. If not present, its value MUST be inferred from the 292 message payload. 294 It is an error if the FROM delivery option is present more than once. 295 Servers MUST reject such commands using the BAD tagged response and 296 the message MUST NOT be submitted. Message flags of the source 297 message MUST NOT be modified. 299 The following per-message submission option is defined by this 300 extensions: 302 3.3.1.1.1. DSN-ENVID Submission Option 304 Syntax: specification of ESMTP Envelope ID 306 This per-message submission option corresponds to the ENVID=... 307 parameter from [RFC3461]. It allows senders to attach a machine- 308 readable ID to be received in the delivery status reports concerning 309 this message. 311 Clients MUST NOT use the DSN-ENVID return option unless the server 312 announces the SUBMIT=DSN capability or a SUBMIT=... capability 313 defined by future extensions which make use of the ENVID ESMTP 314 parameter. 316 3.3.1.2. RECIPIENT Delivery Option 318 Syntax: one e-mail address followed by optional further data 320 The RECIPIENT delivery option corresponds to the RCPT TO field of the 321 SMTP envelope. 323 The RECIPIENT delivery option MAY be present more than once. Servers 324 MAY impose a limit on the number of recipients of a single message. 326 If the RECIPIENT delivery option is present, servers MUST ignore any 327 To, Cc and Bcc headers in the message payload when determining the 328 list of recipients of this message. That is, the final list of 329 recipients of the message MUST consist exactly of those recipients 330 specified in the RECIPIENT delivery options. The server MUST still 331 sanitize the headers of the submitted message to guarantee the 332 privacy of the recipients listed in the Bcc message header. 334 If the RECIPIENT delivery option is missing, servers MUST infer its 335 value from the message payload. For example, each address present in 336 any of To, Cc and Bcc message headers MUST be present in the 337 recipient list. 339 Servers MAY impose a local policy decision about always sending a 340 copy of message to a certain address. This operation MUST NOT affect 341 the user-specified list of recipients passed through the RECIPIENTS 342 delivery options. 344 Message submission MUST be atomic -- message is either submitted for 345 delivery to all recipients, or it MUST NOT be submitted for delivery 346 to anyone. Actual delivery MAY still fail for certain recipients, as 347 per usual ESMTP semantics. 349 The following submission options are defined for the RECIPIENT 350 delivery option: 352 3.3.1.2.1. DSN Submission Option 354 Syntax: delivery status notice specification 356 The DSN submission option controls generating of delivery status 357 notifications related to the currently submitted message. When not 358 given, an implementation-defined default value MUST be used. The 359 default value MUST be either (FAILURE) or (DELAY, FAILURE), as 360 mandated by [RFC3461]. 362 It is an error if the DSN submission option is present multiple times 363 for one recipient. 365 Clients MUST NOT specify the DSN submission option unless the server 366 announces the SUBMIT=DSN capability. Support for the SUBMIT=DSN 367 submission option is OPTIONAL. 369 The DSN specification is either "NONE" to deactivate DSNs altogether, 370 or a parenthesized list of any of the following DSN options: 372 SUCCESS requests generating DSNs upon successful delivery of a 373 message 375 DELAY activates generating DSNs when delivery is delayed 377 FAILURE requests generating DSNs when the delivery fails 379 The order of DSN requests is not significant. A single DSN option 380 item MUST NOT be repeated in the DSN specification for one recipient. 382 3.3.1.2.2. DSN-RET Submission Option 384 Syntax: DSN return option specification 386 This per-recipient submission option corresponds to the RET=... 387 parameter from [RFC3461]. Two values are defined, "HDRS" and "FULL", 388 meaning to include only the headers or the full message, 389 respectively, in the generated delivery status reports. 391 Clients MUST NOT use the DSN-RET return option unless the server 392 announces the SUBMIT=DSN capability. 394 4. Example 396 This section contains an example of how message submission over IMAP 397 works. 399 The following example shows how client should submit a message with 400 UID 123 in the current mailbox for delivery. If the message is 401 passed through SMTP, its From address in the SMTP envelope MUST be 402 set to foo@example.org and it MUST be submitted for delivery to two 403 recipients, the a@example.org and b@example.org. The DSN options are 404 set to report about excess delays and failures in message delivery 405 for the first recipient. System's default policy of DSN production 406 is retained for the second recipient. 408 C: x UID SUBMIT 123 (FROM "foo@example.org" 409 RECIPIENT "a@example.org" DSN (delay failure) 410 RECIPIENT "b@example.org" 411 ) 412 S: * 10 FETCH (UID 123 FLAGS ($Submitted)) 413 S: x OK Message passed to the sendmail binary 415 In the following example, a message is delivered to addresses 416 specified in the message payload. No delivery options are given, and 417 therefore the From and To envelope items are inferred from the actual 418 payload. The DSN options, if supported, are set to an 419 implementation-defined default value. 421 C: x UID SUBMIT 123 422 S: * 10 FETCH (UID 123 FLAGS ($Submitted)) 423 S: x OK Message passed to the sendmail binary 425 5. Acknowledgements 427 FIXME 429 6. IANA Considerations 431 IMAP4 capabilities are registered by publishing a standards track or 432 IESG approved experimental RFC. The registry is currently located 433 at: 435 http://www.iana.org/assignments/imap4-capabilities 437 This document defines the following list of IMAP capabilities. IANA 438 will be asked to add them to the registry: 440 o SUBMIT 442 o SUBMIT=DSN 444 FIXME: response codes 446 7. Formal Syntax 448 The following syntax specification uses the Augmented Backus-Naur 449 Form (ABNF) notation as specified in [RFC5234]. 451 Non-terminals referenced but not defined below are as defined by 452 [RFC3501], or [RFC5234]. 454 capability =/ "SUBMIT" / "SUBMIT=DSN" 455 ;; This extension also reserves all further 456 ;; capabilities starting with the "SUBMIT=" 457 ;; prefix for future extensions related to the 458 ;; message submission over IMAP 460 uid =/ "UID" SP sendmail 462 sendmail = "SUBMIT" SP uniqueid [SP delivery-options] 464 delivery-options = "(" delivery-option *( SP delivery-option ) ")" 466 delivery-option = submission-from / submission-recipient 468 submission-from = "FROM" SP one-email-addr [SP mail-from-params] 469 ;; MUST NOT be present more than once 470 ;; in the delivery-options block 472 submission-recipient= "RECIPIENT" SP one-email-addr [SP mail-rcpt-params] 473 ;; MAY be present more than once 475 mail-from-params = "(" mail-from-param *( SP mail-from-param ) ")" 477 mail-from-param = sub-option-dsn-envid / sub-generic-option 479 mail-rcpt-params = "(" mail-rcpt-param *( SP mail-rcpt-param ) ")" 481 mail-rcpt-param = sub-option-rcpt-dsn / sub-option-dsn-ret 482 / sub-generic-option 484 sub-generic-option = string SP string 485 ;; FIXME: do we want to retain this in without any semantics? 487 sub-option-rcpt-dsn = "DSN" SP ( "NONE" / dsn-spec ) 488 ;; MUST NOT be present more than once for each recipient 490 dsn-spec = "(" dsn-spec-item *( SP dsn-spec-item ) ")" 491 ;; an individual dsn-spec-item MUST NOT 492 ;; be present more than once in this list 494 dsn-spec-item = "DELAY" / "FAILURE" / "SUCCESS" 496 sub-option-dsn-ret = "DSN-RET" SP ( "FULL" / "HDRS" ) 497 ;; MUST NOT be present more than once for each recipient 499 sub-option-dsn-envid= "DSN-ENVID" SP xtext 500 ;; MUST NOT be present more than once 501 ;; is defined in [RFC3461], section 4. 502 ;; The allowed syntax is further limited by 503 ;; its section 4.4. 505 one-email-addr = string 506 ;; valid e-mail address as per [RFC5321] 508 8. Security Considerations 510 This extension introduces a new way of allowing authenticated users 511 to submit Internet mail. Servers supporting this extension SHOULD 512 implement the same security measures as other SUBMISSION [RFC4409] 513 servers open to users. 515 The redirect command from SIEVE [RFC5228] already requires some types 516 of IMAP message stores to be able to generate outgoing mail. 517 Security considerations for this extension are similar. 519 For the IMAP-based submission to work, the server operators MUST 520 configure their MTA systems to accept submission requests from their 521 IMAP servers. This change MAY have security implications, even 522 though services supporting the SIEVE filtering are already configured 523 to accept e-mails for submission. 525 The new trust path MAY replace the trust path required for the BURL/ 526 URLAUTH operation required by the LEMONADE extension family. 528 9. References 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 534 Extension for Delivery Status Notifications (DSNs)", RFC 535 3461, January 2003. 537 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 538 4rev1", RFC 3501, March 2003. 540 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 541 RFC 4409, April 2006. 543 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - 544 URLAUTH Extension", RFC 4467, May 2006. 546 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, 547 May 2006. 549 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) 550 CATENATE Extension", RFC 4469, April 2006. 552 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional 553 STORE Operation or Quick Flag Changes Resynchronization", 554 RFC 4551, June 2006. 556 [RFC5172] Varada, S., "Negotiation for IPv6 Datagram Compression 557 Using IPv6 Control Protocol", RFC 5172, March 2008. 559 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 560 Language", RFC 5228, January 2008. 562 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 563 Specifications: ABNF", STD 68, RFC 5234, January 2008. 565 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 566 October 2008. 568 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 569 October 2008. 571 [RFC5550] Cridland, D., Melnikov, A. and S. Maes, "The Internet 572 Email to Support Diverse Service Environments (Lemonade) 573 Profile", RFC 5550, August 2009. 575 Appendix A. FIXME Items 577 What's got higher priority, SUBMISSIONRACE or POLICYDENIED? :) 579 IANA and the response codes 581 "if the command fails, server MUST clear both $SubmitPending and 582 $Submitted" -- what to do when there's something like a disk error? 584 Appendix B. Changelog 586 Appendix B.1. Changes in -01 since -00 588 o "Delivery options" is the new name for former "submission 589 options"; changed the existing DSN options family to use this new 590 syntax (thanks to Arnt for this suggestion) 592 o Clarified the visibility of the transitional state with both 593 $Submitted and $SubmitPending 595 o Some editorial work 597 o Fixed an error in the example (multiple FROM addresses...) 599 Appendix B.2. Changes in -00 since private-01 601 o Renamed to SUBMIT 603 o DSNs are per-recipient, not per-message 605 o The introduction was rewritten 607 o Miscellaneous clarifications 609 o Changed DSN NIL to DSN NONE 611 o Clarified the semantics of the RECIPIENT submission option to 612 guarantee Bcc privacy 614 o Editorial tweaks, including changes to the required SHOULD/MUST/ 615 ... 617 o DSN's ENVID and RET 619 Appendix B.3. Changes in private-01 since private-00 621 o Removed the superfluous SENDER submission option 623 o Mandating Bcc removal in conformance with RFC 5321 / RFC 5322 625 Author's Address 627 Jan Kundrat 628 Eledrova 558 629 Prague 181 00 630 CZ 632 Email: jkt@flaska.net