idnits 2.17.1 draft-kundrat-imap-submit-02.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 (August 27, 2013) is 3895 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 August 27, 2013 4 Intended status: Standards Track 5 Expires: February 26, 2014 7 IMAP SUBMIT Extension 8 draft-kundrat-imap-submit-02 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 February 26, 2014. 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 . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . 9 68 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Appendix A. FIXME Items . . . . . . . . . . . . . . . . . . . . . 13 75 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 13 76 Appendix B.1. Changes in -02 since -01 . . . . . . . . . . . . 13 77 Appendix B.2. Changes in -01 since -00 . . . . . . . . . . . . 13 78 Appendix B.3. Changes in -00 since private-01 . . . . . . . . . 13 79 Appendix B.4. Changes in private-01 since private-00 . . . . . 14 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 In the traditional IMAP/ESMTP service model, a MUA transfers each 85 outgoing message twice -- once for storing it in the user's "sent 86 mail" folder, and the second time for actual message submission over 87 (E)SMTP. Under certain circumstances, such as when the message 88 contains data which are already available in another message stored 89 on the same IMAP server (such as when forwarding an unread attachment 90 to another recipient), the MUA has to download the data before the 91 message can be composed, resulting in transmitting the data three 92 times in total. 94 Many proposals exist which aim to reduce this high number of 95 transfers to the lowest possible number. The CATENATE extension 96 [RFC4469] enables IMAP clients to have the IMAP servers compose 97 messages on their behalf, optionally using data already available on 98 the IMAP server. Using CATENATE, MUAs do not have to download 99 individual message parts before including them to the newly created 100 message. 102 The LEMONADE extension family [RFC5550] mandates full support for 103 BURL [RFC4468] and URLAUTH [RFC4467] extensions. When coupled with a 104 properly configured pair of ESMTP and IMAP servers, these two 105 extensions allow MUAs to have the submission server obtain the 106 message payload from the IMAP server. This approach completely 107 eliminates the need to upload the message data to the ESMTP server, 108 achieving the "forward-without-download" goal. 110 The BURL/URLAUTH extensions, however, put a significant burden on the 111 server operators who suddenly have to establish an explicit trust 112 relation between their submission and IMAP servers, and make this 113 trust path visible to the users' MUAs. No MUA-visible means of 114 discovering this trust relation are defined. Furthermore, the whole 115 scheme still requires the MUAs to maintain two distinct connections 116 speaking different protocols. Users are prompted for two sets of 117 credentials to authenticate to each of these two services. Real- 118 world support issues were reported where users are able to access 119 their IMAP service while access to the submission service is blocked 120 by a mis-configured firewall. 122 The SUBMIT extension of the IMAP protocol effectively moves the 123 message submission process to be initiated by a user's request to 124 their IMAP server. When deployed, this scenario provides a perfect 125 discoverability to the users' MUAs, saves the overhead of 126 establishing and securing a separate TCP connection against the 127 submission server, reduces the amount of the configuration data the 128 users are required to provide, and simplifies the trust paths which 129 are required to exist between the submission and the IMAP servers. 130 When combined with the existing CATENATE extension [RFC4469], the 131 SUBMIT command works at least as effectively as the Lemonade trio of 132 CATENATE/BURL/URLAUTH. 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 2. Mode of Operation 142 The SUBMIT extension adds the UID SUBMIT IMAP command which instructs 143 the IMAP server to arrange for delivery of an already existing IMAP 144 message. How this message is composed is outside of scope of this 145 extension, but it is assumed that clients will often use the APPEND 146 or APPEND ... CATENATE commands. 148 Upon receiving the SUBMIT command, the IMAP server is asked for 149 arranging the initial message submission. Clients MAY pass 150 additional data in form of various options of the SUBMIT command (the 151 delivery options). The server checks the passed data and delivery 152 options, optionally performs sanity checks on the message contents, 153 verifies against a local policy whether the user is authorized for 154 message submission, and if none of these checks fail, the server 155 passes the message for subsequent delivery. The delivery method is 156 outside of scope of this document, but typical methods would be 157 invoking a `sendmail`-compatible binary or passing the message to an 158 ESMTP gateway. 160 3. IMAP Protocol Changes 162 This extension introduces one new IMAP command, a few related 163 response codes and a new family of the IMAP capabilities. 165 3.1. New IMAP Capabilities 167 3.1.1. The SUBMIT Capability 169 Servers implementing this extension announce its presence through the 170 SUBMIT capability. If the server supports this extension but message 171 submission is unconditionally disabled by a security policy or 172 service configuration, this capability MUST NOT be announced. 174 When this capability is present, clients may assume that chances are 175 high that submitting messages over IMAP will work. 177 3.1.2. The SUBMIT= Capabilities Family 179 The SUBMIT commands issued by the IMAP clients MAY contain delivery 180 options, and these options might contain other fine grained options. 181 Servers supporting voluntary features MUST indicate so by including 182 the appropriate strings in the CAPABILITY responses. All 183 capabilities used for these purposes begin with the SUBMIT= prefix. 185 3.1.2.1. SUBMIT=DSN 187 If the server supports user control of generating the Delivery Status 188 Notifications (DSN), it MUST announce the SUBMIT=DSN capability. 189 Clients MUST NOT attempt to control DSN options through the DSN 190 submission option unless the server announces the SUBMIT=DSN 191 capability. 193 3.2. Additional Response Codes 195 The following response codes are defined for communicating the reason 196 why submission failed in a machine-readable way. 198 3.2.1. The POLICYDENIED Response Code 200 The POLICYDENIED response code SHOULD be used if the server rejects 201 message submission as a result of a policy based decision which MAY 202 take the message content, submission options, user's behavior and 203 transaction history into account. 205 Upon seeing the POLICYDENIED response code, the client MUST inform 206 the user that message submission failed, and include the text of the 207 response in the error message. Clients MUST NOT attempt to 208 automatically re-queue this message for sending over IMAP. The 209 clients MAY, however, choose to continue the message submission by 210 another channel, perhaps over an ESMTP service. 212 3.2.2. The SUBMISSIONRACE Response Code 214 The SUBMISSIONRACE response code MUST be sent in the tagged response 215 if the client asks for submission of a message that is either not 216 marked with the $SubmitPending keyword or marked with the $Submitted 217 keyword. 219 The SUBMISSIONRACE response code could SHOULD have a preference over 220 the POLICYDENIED response code. 222 3.3. UID SUBMIT command 224 The UID SUBMIT command submits a message for delivery. 226 Arguments: 228 o UID of message to be sent 230 o optional list of delivery options 232 Responses: FETCH response with updated message flags 234 Result: 236 OK Message submitted for delivery 238 NO Submission failed 240 BAD Invalid commands or options 242 This command is only valid in the selected state. 244 The server MUST check its local policy configuration and verify that 245 the authenticated user is allowed to submit messages. The decision 246 MAY be based on the user's credentials, the message contents, past 247 history of the user, or any other criteria the server deems relevant. 248 The server SHOULD take into account any other local policies before 249 it proceeds with further submission. 251 Clients MUST NOT submit a message which is either not marked with the 252 $SubmitPending keyword from [RFC5550], or which is marked with the 253 $Submitted keyword. Servers MUST reject such a command with a tagged 254 NO bearing the SUBMISSIONRACE response code. 256 In the course of submission, servers MUST atomically add the 257 $Submitted flag to the message, as described in LEMONADE [RFC5550]. 258 A transient state where the message is temporarily marked with both 259 $Submitted and $SubmitPending flags MAY be hidden from any IMAP 260 session or it MAY be visible in some or all of them. 262 If the command succeeded, the message MUST be marked with the 263 $Submitted keyword, the $SubmitPending keyword MUST be cleared and a 264 FETCH response containing the message UID and its new flags MUST be 265 sent. 267 If the command fails, the server MUST clear both the $Submitted or 268 $SubmitPending keywords. 270 If the server supports CONDSTORE [RFC4551] or QRESYNC [RFC5172] 271 extensions, any flag changes MUST obey the usual MODSEQ invariants. 272 Any changes in the MODSEQ values MUST be communicated to the clients, 273 as mandated by the relevant extensions. 275 Clients MUST be prepared to handle failing submission at any time. 276 Servers MAY reject message submission for any reason. 278 The server MUST process all specified delivery options and their 279 detailed options. The server MUST respond with a tagged BAD if the 280 client used unrecognized or unannounced option, or if a recognized 281 option is used in an invalid way. If the server cannot honor a 282 recognized and announced option, it MUST respond with a tagged NO 283 with the POLICYDENIED response code and the message MUST NOT be 284 submitted, nor its flags changed. 286 Servers MAY alter the message payload of the outgoing message in 287 conformance with best current practice about Internet mail. 288 Individual recipients MAY receive different versions of the message. 289 In particular, servers MUST change message headers so that the 290 identity of addresses present in the Bcc headers is not revealed to 291 other recipients. This mode of operation is described in [RFC5321] 292 and [RFC5322]. The copy stored on the IMAP server MUST NOT be 293 altered by these modifications. 295 3.3.1. Delivery options 297 The following two delivery options are defined by this extension. 298 These options apply to the message as a whole: 300 3.3.1.1. FROM Delivery Option 302 Syntax: one e-mail address with optional further data 304 The FROM delivery option corresponds to the FROM field of the SMTP 305 envelope. If not present, its value MUST be inferred from the 306 message payload. 308 It is an error if the FROM delivery option is present more than once. 309 Servers MUST reject such commands using the BAD tagged response and 310 the message MUST NOT be submitted. Message flags of the source 311 message MUST NOT be modified. 313 The following per-message submission option is defined by this 314 extensions: 316 3.3.1.1.1. DSN-ENVID Submission Option 318 Syntax: specification of ESMTP Envelope ID 319 This per-message submission option corresponds to the ENVID=... 320 parameter from [RFC3461]. It allows senders to attach a machine- 321 readable ID to be received in the delivery status reports concerning 322 this message. 324 Clients MUST NOT use the DSN-ENVID return option unless the server 325 announces the SUBMIT=DSN capability or a SUBMIT=... capability 326 defined by future extensions which make use of the ENVID ESMTP 327 parameter. 329 3.3.1.2. RECIPIENT Delivery Option 331 Syntax: one e-mail address followed by optional further data 333 The RECIPIENT delivery option corresponds to the RCPT TO field of the 334 SMTP envelope. 336 The RECIPIENT delivery option MAY be present more than once. Servers 337 MAY impose a limit on the number of recipients of a single message. 339 If the RECIPIENT delivery option is present, servers MUST ignore any 340 To, Cc and Bcc headers in the message payload when determining the 341 list of recipients of this message. That is, the final list of 342 recipients of the message MUST consist exactly of those recipients 343 specified in the RECIPIENT delivery options. The server MUST still 344 sanitize the headers of the submitted message to guarantee the 345 privacy of the recipients listed in the Bcc message header. 347 If the RECIPIENT delivery option is missing, servers MUST infer its 348 value from the message payload. For example, each address present in 349 any of To, Cc and Bcc message headers MUST be present in the 350 recipient list. 352 Servers MAY impose a local policy decision about always sending a 353 copy of message to a certain address. This operation MUST NOT remove 354 any addresses from the list of recipients, as obtained either from 355 the user-specified list of recipients passed through the RECIPIENTS 356 delivery options, or inferred from the mail headers. 358 Message submission MUST be atomic -- message is either submitted for 359 delivery to all recipients, or it MUST NOT be submitted for delivery 360 to anyone. Actual delivery MAY still fail for certain recipients, as 361 per usual ESMTP semantics. 363 The following submission options are defined for the RECIPIENT 364 delivery option: 366 3.3.1.2.1. DSN Submission Option 368 Syntax: delivery status notice specification 369 The DSN submission option controls generating of delivery status 370 notifications related to the currently submitted message. When not 371 given, an implementation-defined default value MUST be used. The 372 default value MUST be either (FAILURE) or (DELAY, FAILURE), as 373 mandated by [RFC3461]. 375 It is an error if the DSN submission option is present multiple times 376 for one recipient. 378 Clients MUST NOT specify the DSN submission option unless the server 379 announces the SUBMIT=DSN capability. Support for the SUBMIT=DSN 380 submission option is OPTIONAL. 382 The DSN specification is either "NONE" to deactivate DSNs altogether, 383 or a parenthesized list of any of the following DSN options: 385 SUCCESS requests generating DSNs upon successful delivery of a 386 message 388 DELAY activates generating DSNs when delivery is delayed 390 FAILURE requests generating DSNs when the delivery fails 392 The order of DSN requests is not significant. A single DSN option 393 item MUST NOT be repeated in the DSN specification for one recipient. 395 3.3.1.2.2. DSN-RET Submission Option 397 Syntax: DSN return option specification 399 This per-recipient submission option corresponds to the RET=... 400 parameter from [RFC3461]. Two values are defined, "HDRS" and "FULL", 401 meaning to include only the headers or the full message, 402 respectively, in the generated delivery status reports. 404 Clients MUST NOT use the DSN-RET return option unless the server 405 announces the SUBMIT=DSN capability. 407 4. Example 409 This section contains an example of how message submission over IMAP 410 works. 412 The following example shows how client should submit a message with 413 UID 123 in the current mailbox for delivery. If the message is 414 passed through SMTP, its From address in the SMTP envelope MUST be 415 set to foo@example.org and it MUST be submitted for delivery to two 416 recipients, the a@example.org and b@example.org. The DSN options are 417 set to report about excess delays and failures in message delivery 418 for the first recipient. System's default policy of DSN production 419 is retained for the second recipient. 421 C: x UID SUBMIT 123 (FROM "foo@example.org" 422 RECIPIENT "a@example.org" DSN (delay failure) 423 RECIPIENT "b@example.org" 424 ) 425 S: * 10 FETCH (UID 123 FLAGS ($Submitted)) 426 S: x OK Message passed to the sendmail binary 428 In the following example, a message is delivered to addresses 429 specified in the message payload. No delivery options are given, and 430 therefore the From and To envelope items are inferred from the actual 431 payload. The DSN options, if supported, are set to an 432 implementation-defined default value. 434 C: x UID SUBMIT 123 435 S: * 10 FETCH (UID 123 FLAGS ($Submitted)) 436 S: x OK Message passed to the sendmail binary 438 5. Acknowledgements 440 FIXME 442 6. IANA Considerations 444 IMAP4 capabilities are registered by publishing a standards track or 445 IESG approved experimental RFC. The registry is currently located 446 at: 448 http://www.iana.org/assignments/imap4-capabilities 450 This document defines the following list of IMAP capabilities. IANA 451 will be asked to add them to the registry: 453 o SUBMIT 455 o SUBMIT=DSN 457 FIXME: response codes 459 7. Formal Syntax 461 The following syntax specification uses the Augmented Backus-Naur 462 Form (ABNF) notation as specified in [RFC5234]. 464 Non-terminals referenced but not defined below are as defined by 465 [RFC3501], or [RFC5234]. 467 capability =/ "SUBMIT" / "SUBMIT=DSN" 468 ;; This extension also reserves all further 469 ;; capabilities starting with the "SUBMIT=" 470 ;; prefix for future extensions related to the 471 ;; message submission over IMAP 473 uid =/ "UID" SP sendmail 475 sendmail = "SUBMIT" SP uniqueid [SP delivery-options] 477 delivery-options = "(" delivery-option *( SP delivery-option ) ")" 479 delivery-option = submission-from / submission-recipient 481 submission-from = "FROM" SP one-email-addr [SP mail-from-params] 482 ;; MUST NOT be present more than once 483 ;; in the delivery-options block 485 submission-recipient= "RECIPIENT" SP one-email-addr [SP mail-rcpt-params] 486 ;; MAY be present more than once 488 mail-from-params = "(" mail-from-param *( SP mail-from-param ) ")" 490 mail-from-param = sub-option-dsn-envid / sub-generic-option 492 mail-rcpt-params = "(" mail-rcpt-param *( SP mail-rcpt-param ) ")" 494 mail-rcpt-param = sub-option-rcpt-dsn / sub-option-dsn-ret 495 / sub-generic-option 497 sub-generic-option = string SP string 498 ;; FIXME: do we want to retain this in without any semantics? 500 sub-option-rcpt-dsn = "DSN" SP ( "NONE" / dsn-spec ) 501 ;; MUST NOT be present more than once for each recipient 503 dsn-spec = "(" dsn-spec-item *( SP dsn-spec-item ) ")" 504 ;; an individual dsn-spec-item MUST NOT 505 ;; be present more than once in this list 507 dsn-spec-item = "DELAY" / "FAILURE" / "SUCCESS" 509 sub-option-dsn-ret = "DSN-RET" SP ( "FULL" / "HDRS" ) 510 ;; MUST NOT be present more than once for each recipient 512 sub-option-dsn-envid= "DSN-ENVID" SP xtext 513 ;; MUST NOT be present more than once 514 ;; is defined in [RFC3461], section 4. 515 ;; The allowed syntax is further limited by 516 ;; its section 4.4. 518 one-email-addr = string 519 ;; valid e-mail address as per [RFC5321] 521 8. Security Considerations 523 This extension introduces a new way of allowing authenticated users 524 to submit Internet mail. Servers supporting this extension SHOULD 525 implement the same security measures as other SUBMISSION [RFC4409] 526 servers open to users. 528 The redirect command from SIEVE [RFC5228] already requires some types 529 of IMAP message stores to be able to generate outgoing mail. 530 Security considerations for this extension are similar. 532 For the IMAP-based submission to work, the server operators MUST 533 configure their MTA systems to accept submission requests from their 534 IMAP servers. This change MAY have security implications, even 535 though services supporting the SIEVE filtering are already configured 536 to accept e-mails for submission. 538 The new trust path MAY replace the trust path required for the BURL/ 539 URLAUTH operation required by the LEMONADE extension family. 541 9. References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 547 Extension for Delivery Status Notifications (DSNs)", RFC 548 3461, January 2003. 550 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 551 4rev1", RFC 3501, March 2003. 553 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 554 RFC 4409, April 2006. 556 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - 557 URLAUTH Extension", RFC 4467, May 2006. 559 [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, 560 May 2006. 562 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) 563 CATENATE Extension", RFC 4469, April 2006. 565 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional 566 STORE Operation or Quick Flag Changes Resynchronization", 567 RFC 4551, June 2006. 569 [RFC5172] Varada, S., "Negotiation for IPv6 Datagram Compression 570 Using IPv6 Control Protocol", RFC 5172, March 2008. 572 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 573 Language", RFC 5228, January 2008. 575 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 576 Specifications: ABNF", STD 68, RFC 5234, January 2008. 578 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 579 October 2008. 581 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 582 October 2008. 584 [RFC5550] Cridland, D., Melnikov, A. and S. Maes, "The Internet 585 Email to Support Diverse Service Environments (Lemonade) 586 Profile", RFC 5550, August 2009. 588 Appendix A. FIXME Items 590 IANA and the response codes 592 "if the command fails, server MUST clear both $SubmitPending and 593 $Submitted" -- what to do when there's something like a disk error? 595 Appendix B. Changelog 597 Appendix B.1. Changes in -02 since -01 599 o Clarified priorities of SUBMISSIONRACE and POLICYDENIED 601 o Clarify failover procedure upon seeing a POLICYDENIED 603 o Clarified message flag manipulation 605 o Clarified recipient list mangling 607 o More editorial work 609 Appendix B.2. Changes in -01 since -00 611 o "Delivery options" is the new name for former "submission 612 options"; changed the existing DSN options family to use this new 613 syntax (thanks to Arnt for this suggestion) 615 o Clarified the visibility of the transitional state with both 616 $Submitted and $SubmitPending 618 o Some editorial work 620 o Fixed an error in the example (multiple FROM addresses...) 622 Appendix B.3. Changes in -00 since private-01 624 o Renamed to SUBMIT 626 o DSNs are per-recipient, not per-message 627 o The introduction was rewritten 629 o Miscellaneous clarifications 631 o Changed DSN NIL to DSN NONE 633 o Clarified the semantics of the RECIPIENT submission option to 634 guarantee Bcc privacy 636 o Editorial tweaks, including changes to the required SHOULD/MUST/ 637 ... 639 o DSN's ENVID and RET 641 Appendix B.4. Changes in private-01 since private-00 643 o Removed the superfluous SENDER submission option 645 o Mandating Bcc removal in conformance with RFC 5321 / RFC 5322 647 Author's Address 649 Jan Kundrat 650 Eledrova 558 651 Prague 181 00 652 CZ 654 Email: jkt@flaska.net