idnits 2.17.1 draft-leiba-morg-message-recall-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3464, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3464, updated by this document, for RFC5378 checks: 2001-06-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2009) is 5406 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) == Missing Reference: 'CFWS' is mentioned on line 556, but not defined ** Obsolete normative reference: RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 3462 (ref. 'Report') (Obsoleted by RFC 6522) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Message ORGanization Working Group B. Leiba 3 Internet-Draft Huawei Technologies 4 Updates: 3464 (if approved) July 6, 2009 5 Intended status: Standards Track 6 Expires: January 7, 2010 8 SMTP Service Extension for Message Recall 9 draft-leiba-morg-message-recall-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 7, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 End users occasionally send email messages that they later want to 48 recall, perhaps because they sent incorrect information, or had 49 second thoughts about what they said in the message. Proprietary 50 email systems often provide such a recall function. This document 51 specifies a standard mechanism for providing it with Internet email. 53 Note 55 A revised version of this draft document will be submitted to the RFC 56 editor as a Proposed Standard for the Internet Community. Discussion 57 and suggestions for improvement are requested, and should be sent to 58 morg@ietf.org. 60 Table of Contents 62 1. Introduction and Informative Discussion . . . . . . . . . . 4 64 2. Conventions used in this document . . . . . . . . . . . . . 6 66 3. SMTP service extension keyword . . . . . . . . . . . . . . . 6 68 4. The Message-Verification header field . . . . . . . . . . . 6 70 5. The SMTP RECL command . . . . . . . . . . . . . . . . . . . 7 71 5.1. RECL HOLD . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.2. RECL RELEASE . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.3. RECL RECALL . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6. Delivery Status Notifications (DSNs) . . . . . . . . . . . . 10 77 7. Timing issues with holding messages . . . . . . . . . . . . 11 79 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Example of a Message-Verification header field . . . . . . . 11 81 8.2. Example of a SMTP RECL transaction . . . . . . . . . . . . . 12 82 8.3. Example of a message recall DSN . . . . . . . . . . . . . . 12 84 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 13 86 10. Security Considerations . . . . . . . . . . . . . . . . . . 14 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 89 11.1. SMTP service extension registration . . . . . . . . . . . . 15 90 11.2. Message header field registration . . . . . . . . . . . . . 15 91 11.3. DSN actions registry creation . . . . . . . . . . . . . . . 15 92 11.4. DSN actions value registrations . . . . . . . . . . . . . . 16 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 95 13. Normative References . . . . . . . . . . . . . . . . . . . . 16 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction and Informative Discussion 101 End users occasionally send email messages that they later want to 102 recall, perhaps because they sent incorrect information, or had 103 second thoughts about what they said in the message. Proprietary 104 email systems often provide such a recall function, but providing it 105 on the Internet, with a diversity of software, administrative 106 domains, and policies, presents a different set of difficulties. 107 This section will describe some of those difficulties, to help in 108 understanding the reasoning behind the protocol that follows. 110 By "recall", here, we mean that the sender wants to withdraw the 111 message from the inbox of one or more recipients, such that those 112 recipients no longer have access to the message, nor knowledge of its 113 existence. We assume that a message already seen by a recipient can 114 not be recalled from that recipient. 116 A system that resides within one administrative domain can easily do 117 record keeping and authentication that will allow it to identify 118 messages and users, and to determine authorization to recall a 119 particular message. It is much harder to do that on the Internet, 120 when the sender is not known to the receiving domain, and when the 121 sending and receiving domains do not have a mutual trust 122 relationship. A protocol that allows the sender to act on messages 123 that have already arrived at the receiving domain must satisfactorily 124 resolve the question of authorization to act on those messages. 126 Proprietary systems often request message recall by sending a special 127 message. Doing it in that way on the Internet is problematic, 128 because there's no way to determine in advance that the receiving 129 server supports the protocol and will understand the special message. 130 If it does not, the message will likely be delivered to the actual 131 recipient in addition to the original message that was meant to be 132 recalled. 134 Further, a new end-to-end protocol to perform this function is not 135 practical. Because Internet email [SMTP] uses a store-and-forward 136 mechanism to transfer email messages, it might not be possible for 137 the sender to contact the receiving server directly. Indeed, it's 138 often the case that it's not even possible for the sender to identify 139 the receiving server at all. 141 By defining this protocol as an extension to SMTP, we fit on top of 142 the existing store-and-forward mechanism, and we detect when a server 143 in the store-and-forward chain does not support this function. We 144 then report the status back to the requester asynchronously, using 145 delivery status notifications [DSN]. 147 A single email message can be sent to a large number of recipients, 148 possibly all at different domains. Some of the recipients might have 149 already seen the message at the time it's being recalled. These can 150 make the process of recalling the message rather difficult. While 151 it's certainly an easy matter to send a recall request to all the 152 receiving domains and have the message recalled from only some of 153 them, depending upon support for this extension and "seen" status of 154 the message by each recipient, this might not be what the sender 155 wants. 157 It's easy to come up with scenarios where it would be very bad to 158 recall it from some, but not from all recipients -- perhaps doing so 159 would cause confusion, or even embarrassment. It's also easy to come 160 up with scenarios where it would be awkward or embarrassing for 161 anyone to know you were trying to recall the message, in a case where 162 the request is ultimately unsuccessful. 164 To solve that, we define a two-step process, first putting a "hold" 165 on the message, and then either rescinding that hold (if we don't get 166 the desired result) or proceeding with the recall. The "hold" step 167 is optional, and will not always be needed. Of course, any 168 asynchronous multi-step process must have a mechanism for resolving 169 hanging requests and missing responses. The protocol suggests using 170 timeouts for those. 172 Expectations have to be kept reasonable, given the likelihood that 173 most recalls will not be fully successful, and especially not so at 174 first. Initially, most systems won't support this. Even when more 175 do, the success will be lower the more recipients a message has, and 176 the longer the time between send and recall. The limitations will 177 have to be explained to the users as part of the interface they get 178 when they press the "recall this message" button (or whatever the UI 179 mechanism is). If the user is given the choice of "recall what you 180 can" (that is, skip the optional "hold" step) and "all or nothing" 181 (do the hold, and only recall if all holds work), that choice must be 182 simply put and easy to select. Most users will have a hard time 183 understanding the finer points here. 185 It's probably also a good idea to give the user a summary, probably 186 in the form of an email message, when the recall process is done: a 187 message saying something like, "Of the 10 recipients, the messages 188 appears to have been recalled from 5. 2 appear to have already seen 189 the message, and 3 of the mail systems do not support the recall 190 option." The message might also include the response given for each 191 recipient, in detail. By wording things in terms of "appear to", or 192 the like, and avoiding absolute "was recalled" statements, we can 193 avoid troubles in the case of improper implementations -- perhaps 194 intentionally so (see Section 10). 196 Finally, the Security Considerations section describes issues that 197 need to be considered when implementing and deploying this protocol. 199 2. Conventions used in this document 201 In examples, "C:" indicates lines sent by a client that is connected 202 to a server. "S:" indicates lines sent by the server to the client. 203 In this protocol, both client and server will often be Message 204 Transfer Agents (MTAs), but one will be acting as the client and one 205 as the server for the transaction. 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [Kwds]. 211 3. SMTP service extension keyword 213 An SMTP server that supports this extension includes the extension 214 keyword "RECL" in its EHLO response. 216 4. The Message-Verification header field 218 If the sending side supports this protocol and wants a message to be 219 recallable, it MUST include a Message-ID header field [Format] in the 220 message. It MUST also include a Message-Verification header field. 221 The Message-Verification header field contains the following required 222 tags, separated by semicolons (with no white space within): 224 hash=[string] -- the algorithm used to produce the hash value in the 225 "guid" tag. Current valid values are "SHA1" and 226 "SHA256" [SHA]. 228 guid=[base64] -- the base64 encoding [Base64] of the hash of a 229 globally unique ID (GUID) for the message, using the 230 hash algorithm specified in the "hash" tag. The 231 actual GUID (the pre-image of the hash) is kept 232 secret by the sending side. 234 See Section 9 for the formal syntax of the Message-Verification 235 field. 237 The Message-Verification header field may be put there by the sender 238 or by the sender's domain. The unhashed GUID MUST be retained and 239 associated with the message, and available to the recalling entity, 240 in order for a recall request to be sent later. To simplify 241 bookkeeping, the GUID MAY be discarded at some time, after which the 242 message can no longer be recalled. 244 Recall requests will be accompanied by the target message's 245 Message-ID header field value and the unhashed GUID of the message. 246 The receiving server will locate the message using the Message-ID, 247 retrieve the message's Message-Verification header field, hash the 248 GUID using the hash algorithm specified in that header field, and 249 compare the new hashed value with the hashed value in that header 250 field. The receiving server considers the message to have been 251 identified ONLY if these tests match. If they do not match, the 252 receiving server MUST consider the message as not found. 254 5. The SMTP RECL command 256 When a message is to be recalled, the recalling entity obtains the 257 Message-ID and (unhashed) GUID of the message. If the recalling 258 entity is not the requester (the end user, in most cases), it is the 259 responsibility of the recalling entity to determine the requester's 260 authorization to recall the message. 262 The recalling entity then initiates a recall request using SMTP 263 [SMTP]. The recall request is propagated through SMTP's store-and- 264 forward mechanism, just as a normal SMTP mail transfer is. 266 A recall request starts with EHLO, MAIL FROM, and RCPT TO, as for the 267 original message. The recall session MUST use EHLO, and the 268 extension list returned MUST be checked to determine that this 269 protocol is supported by the downstream server. If it is not, and 270 the recall request verb is not RELEASE, the current server MUST send 271 back a "BAD" DSN (see Section 6). DSNs MUST NOT be returned for 272 RELEASE requests. 274 In place of the DATA command, the recall request uses the new RECL 275 command, as one of the following: 277 RECL HOLD Message-ID GUID 279 RECL RELEASE Message-ID GUID 281 RECL RECALL INFORM [NO | FAILURE | SUCCESS | ALL] Message-ID GUID 283 "Message-ID", above, is the value of the Message-ID field of the 284 original message, including the angle-brackets. "GUID" is the 285 unhashed GUID of the original message. See Section 9 for the formal 286 syntax of the RECL command. 288 The RECL command ends the recall request, and is followed by a QUIT 289 command, to terminate the SMTP session, or an RSET command, to start 290 a new SMTP transaction. 292 5.1. RECL HOLD 294 RECL HOLD requests a hold on the message. For each recipient, a DSN 295 is sent back with a status of "OK", "NO", or "BAD" (see Section 6). 296 Note that a receiving server might choose not to implement RECL HOLD 297 (see item 1, below). 299 When a RECL HOLD arrives at the receiving server for a particular 300 recipient, the receiving server MUST do one of the following: 302 1. Respond with a "NO" DSN because it does not implement RECL HOLD. 304 2. Determine that the target message is not found, and respond with 305 a "NO" DSN. 307 3. Determine that the message is already on hold, and respond with 308 an "OK" DSN. Timeouts associated with the held message (see 309 Section 7) SHOULD be reset the first time this happens. 311 4. Determine that local policy forbids a hold on the target message, 312 and respond with a "NO" DSN. If policy permits a hold, it MUST 313 also permit a subsequent recall. 315 5. Determine that the message is already marked as seen, and respond 316 with a "NO" DSN. 318 6. Determine that for some other reason, the message can not be 319 held, and respond with a "NO" DSN. 321 7. If none of the above apply, hold the message and respond with an 322 "OK" DSN. Holding the message means putting it in a state where 323 neither the contents of the message nor its presence can be seen 324 by the user, but where it can be restored to its original state 325 when needed. 327 By holding the message and responding with an "OK" DSN, the receiving 328 server MUST guarantee that the message will be successfully recalled 329 if a subsequent RECL RECALL is received in a timely manner. 331 5.2. RECL RELEASE 333 RECL RELEASE is used to rescind a HOLD, perhaps because they didn't 334 all come back as OK. 336 When a RECL RELEASE arrives at the receiving server for a particular 337 recipient, the receiving server MUST do one of the following: 339 1. Determine that the target message is on hold, and restore it to 340 its original, state. 342 2. Otherwise, ignore the request. 344 No DSNs are returned for RECL RELEASE. 346 5.3. RECL RECALL 348 RECL RECALL requests that the message be recalled. The recall may 349 fail because of policy, because the message has already been seen by 350 the recipient, and perhaps for other reasons. The recipient may have 351 been notified of the message, but not actually seen the message yet 352 (perhaps through Sieve notifications, or some other mechanism). 353 Whether such a message is recallable is a matter of policy. 355 The value of the INFORM option works thus: 357 NO -- Never inform the recipient that a recall was requested. 359 FAILURE -- Inform the recipient that a recall was requested only if 360 the recall fails. This can advise the recipient that the 361 sender wants to withdraw the message, in the event that it 362 could not actually be withdrawn. 364 SUCCESS -- Inform the recipient that a recall was requested only if 365 the recall succeeds. This can have the effect of 366 replacing the recalled message with a notification that 367 the message was withdrawn. 369 ALL -- Always inform the recipient that a recall was requested, 370 whether it succeeded or not. 372 The mechanism used to inform the recipient is up to the 373 implementation. It MAY use an email message, but MAY use other 374 locally available notification mechanisms. 376 When a RECL RECALL arrives at the receiving server for a particular 377 recipient, the receiving server MUST do one of the following: 379 1. Determine that the target message is not found, and respond with 380 a "NO" DSN. 382 2. Determine that the message is already on hold (see above), delete 383 it, and respond with an "OK" DSN. 385 3. Determine that local policy forbids recalling this message, and 386 respond with a "NO" DSN. 388 4. Determine that the message is already marked as seen, and respond 389 with a "NO" DSN. 391 5. Determine that for some other reason, the message can not be 392 recalled, and respond with a "NO" DSN. 394 6. If none of the above apply, delete the message and respond with 395 an "OK" DSN. 397 If the server responds with an "OK" DSN, it MUST remove the message 398 from the recipient's mailbox, and never put it back. However, no 399 guarantee is made for any other recipients of the message, and it is, 400 of course, possible that one of them might re-send the message to 401 this recipient. Such action would be independent of the recall 402 process. 404 6. Delivery Status Notifications (DSNs) 406 Because the recall protocol is fully asynchronous, all responses come 407 in the form of Delivery Status Notifications [DSN], which are sent 408 back to the MAIL FROM address in the recall request. These DSNs 409 contain action and status codes, as described below, which inform the 410 requesting entity of the success status of the request. When 411 constructing the DSN multipart/report [Report], only sections 1 412 (human-readable message) and 2 (machine parsable report) are used. 413 The optional section 3 (returned message) MUST NOT be included. 415 The action code is placed in the "Action" field of section 2, and 416 comprises the recall verb ("HOLD" or "RECALL"; DSNs are not sent for 417 RELEASE commands), one space character (ASCII 0x20), and one of the 418 following: 420 OK -- The request was successful. The message has been held or 421 recalled. 423 NO -- The request was not successful. The DSN MAY include human- 424 readable text in section 1 that further explains the 425 problem. 427 BAD -- A server in the SMTP store-and-forward path does not support 428 the RECL protocol. 430 See Section 9 for the formal syntax of the Action field. 432 The status code [Codes] is placed in the "Status" field of section 2, 433 and relates to the action code as follows: 435 2.0.0 -- for "OK" actions. 437 5.0.0 -- for "NO" actions. 439 5.3.3 -- for "BAD" actions. 441 7. Timing issues with holding messages 443 [[anchor9: Should we suggest "reasonable" time values here? If so, 444 what? One suggestion is that we suggest defaults, and include a 445 mechanism in the protocol to specify times -- a time-stamp on the 446 HOLD request, asking for a hold until that time; a time-stamp on the 447 response, saying "I'll hold at least until this time." There'd have 448 to be a tolerance for out-of-sync clocks... in other words, the times 449 would be approximate, not held to the second.]] 451 If the requesting entity uses RECL HOLD, it MUST keep track of the 452 asynchronous DSNs and decide in a timely manner to RELEASE or RECALL 453 the message. This means having a notion of a timeout period for 454 missing DSNs. A requesting entity MAY selectively re-issue a RECL 455 HOLD once, to those recipients for which no DSN is received within a 456 reasonable time, but it MUST NOT continue doing so repeatedly. 458 Similarly, an OK response to a HOLD gives the recipient side the 459 responsibility of determining how long to wait for further action. 460 The message SHOULD [[anchor10: MUST?]] automatically be released from 461 hold after a reasonable time if no RELEASE or RECALL is received. 463 8. Examples 465 8.1. Example of a Message-Verification header field 467 This shows an example of partial message headers, with a Message-ID 468 field and a Message-Verification field. The message's unhashed GUID 469 is "G9Kw8iJ37Q1027msa4NbU". 471 From: alice@example.org 472 To: bob@example.com 473 Subject: Save the date! 474 Message-ID: <411699893-1246577932-871827273@example.org> 475 Message-Verification: hash=SHA1;guid=BAv9A56z4M0FU3T/Qn+dw7ck9bA= 477 8.2. Example of a SMTP RECL transaction 479 This will request a recall of a message with the above headers. Note 480 that we use the Message-ID value as specified in the original header, 481 and the unhashed GUID. Also note that the final "250 2.0.0 OK" does 482 NOT mean that the message has been recalled, but only that the recall 483 REQUEST was transmitted successfully. A DSN will be sent back to 484 alice@example.org with the actual recall status. 486 C: [connects to mail.example.com] 487 S: 220 mail.example.com -- ESMTP (Messaging Server version 1.7a) 488 C: EHLO example.org 489 S: 250-mail.example.com 490 S: 250-PIPELINING 491 S: 250-RECL 492 S: 250-DSN 493 S: 250 ENHANCEDSTATUSCODES 494 C: MAIL FROM: 495 S: 250 2.5.0 OK 496 C: RCPT TO: 497 S: 250 2.1.5 OK 498 C: RECL RECALL <411699893-1246577932-871827273@example.org> 499 G9Kw8iJ37Q1027msa4NbU 500 S: 250 2.0.0 OK 501 C: QUIT 502 S: 221 2.3.0 Goodbye. 504 8.3. Example of a message recall DSN 506 This might be a response to the example recall request above. 508 To: alice@example.org 509 From: postmaster@mail.example.com 510 Subject: Recall Notification (RECALL OK) for bob@example.com 511 Content-Type: multipart/report; report-type=delivery-status; 512 boundary=abcde 513 MIME-Version: 1.0 515 --abcde 516 Content-type: text/plain; charset=us-ascii 518 Your message (guid G9Kw8iJ37Q1027msa4NbU) 519 was successfully recalled from bob@example.com. 521 --abcde 522 Content-type: message/delivery-status 524 Reporting-MTA: dns; mail.example.com 525 Original-Envelope-ID: G9Kw8iJ37Q1027msa4NbU 527 Original-Recipient: rfc822;bob@example.com 528 Final-Recipient: rfc822;bob@example.com 529 Action: RECALL OK 530 Status: 2.0.0 532 --abcde-- 534 9. Formal Syntax 536 The following syntax specification uses the augmented Backus-Naur 537 Form (BNF) as described in [ABNF]. Terms not defined here are taken 538 from the Simple Mail Transfer Protocol [SMTP] and Internet Message 539 Format [Format] specifications. 541 action-hold = "HOLD" SP ("OK" / "NO" / "BAD") 543 action-recall = "RECALL" SP ("OK" / "NO" / "BAD") 545 action-value /= action-hold / action-recall 546 ; extends "action-value" from RFC 3464 [DSN] 548 base64string = 1*(ALPHA / DIGIT / "+" / "/") [ "=" [ "=" ] ] CRLF 550 guid = dot-atom-text 551 guid-hash = "guid=" base64string 553 hash-alg = "hash=" ("SHA1" / "SHA256") 555 message-verification = "Message-Verification:" [CFWS] hash-alg ";" 556 guid-hash [CFWS] CRLF 558 recl = "RECL" SP recl-verb SP message-id SP guid 560 recl-hold = "HOLD" 562 recl-recall = "RECALL" SP "INFORM" SP ("NO" / "FAIL" / "ALL") 564 recl-release = "RELEASE" 566 recl-verb = recl-hold / recl-release / recl-recall 568 10. Security Considerations 570 It's possible for an intermediate MTA to add or replace a Message- 571 Verification header field during the transmission of an original 572 message, which could later allow an unauthorized party to recall the 573 message. Since intermediate MTAs can do plenty of other nasty 574 things, including not relaying the message in the first place (but 575 saying they did), this is probably not a real issue. 577 If the sending domain (as opposed to the sending user agent) creates 578 the Message-Verification header field, it will also be the sending 579 domain that will have to supply the GUID on the RECL command. There 580 will then be no in-band authentication of the user requesting the 581 recall. In this case, it's the responsibility of the sending domain 582 to ensure that the user is authorized to do this. 584 Timeouts are required, as noted above (see Section 7). 586 It's possible for the receiving end to ignore the INFORM option, and 587 to inform the recipient when the sender would not want that. It's 588 possible for the receiving end to send an "OK" DSN but fail to recall 589 the message (perhaps also informing the recipient of this). While 590 these behaviours are contrary to this specification, they are a fact 591 of life when asking for such things on the Wild, Wild Internet. 592 Those who would try to recall messages quietly should bear this in 593 mind. 595 11. IANA Considerations 597 11.1. SMTP service extension registration 599 This document defines an SMTP service extension, and IANA is asked to 600 add an entry to the SMTP Service Extensions registry, as follows: 602 Keyword: RECL 603 Description: Message recall 604 Reference: [[IANA: Insert this RFC number.]] 605 Parameters: (none) 607 11.2. Message header field registration 609 This document defines a new message header field, and IANA is asked 610 to add an entry to the Permanent Message Header Field Names registry, 611 as follows: 613 Header field name: Message-Verification 614 Protocol: mail 615 Status: standard 616 Reference: [[IANA: Insert this RFC number.]] 618 11.3. DSN actions registry creation 620 This document defines a new DSN action field value, and there is 621 currently no registry for those values. IANA is asked to create a 622 "DSN Actions" sub-registry in the Mail Parameters registry ( 623 http://www.iana.org/assignments/mail-parameters ). New values will 624 be registered using the "Specification Required" policy [IANA]. The 625 template to be used to register new values is as follows: 627 To: iana@iana.org 628 Subject: Registration of new DSN action field value 629 Value: [the text value of the field] 630 Reference: [identifies the specification that defines this value] 632 IANA is asked to enter the following initial values in this registry, 633 all taken from RFC 3464: 635 Value: failed 636 Reference: RFC 3464 638 Value: delayed 639 Reference: RFC 3464 640 Value: delivered 641 Reference: RFC 3464 643 Value: relayed 644 Reference: RFC 3464 646 Value: expanded 647 Reference: RFC 3464 649 11.4. DSN actions value registrations 651 This document defines new DSN action field values, and IANA is asked 652 to add the following entries to the DSN Actions registry, created 653 above: 655 Value: hold [ok/no/bad] 656 Reference: [[IANA: Insert this RFC number.]] 658 Value: recall [ok/no/bad] 659 Reference: [[IANA: Insert this RFC number.]] 661 12. Acknowledgements 663 The author gratefully acknowledges feedback provided by Ned Freed and 664 Nathaniel Borenstein on the initial version of this specification. 666 13. Normative References 668 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 669 Specifications: ABNF", RFC 5234, January 2008. 671 [Base64] Josefsson, S., "The Base16, Base32, and Base64 Data 672 Encodings", RFC 4648, October 2006. 674 [Codes] Vaudreuil, G., "Enhanced Mail System Status Codes", 675 RFC 3463, January 2003. 677 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 678 for Delivery Status Notifications", RFC 3464, January 2003. 680 [Format] Resnick, P., Ed., "Internet Message Format", RFC 5322, 681 October 2008. 683 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 684 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 685 May 2008. 687 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", RFC 2119, March 1997. 690 [Report] Vaudreuil, G., "The Multipart/Report Content Type for the 691 Reporting of Mail System Administrative Messages", 692 RFC 3462, January 2003. 694 [SHA] U.S. Department of Commerce, "Secure Hash Standard", 695 FIPS PUB 180-3, October 2008. 697 [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", 698 RFC 5321, October 2008. 700 Author's Address 702 Barry Leiba 703 Huawei Technologies 705 Phone: +1 646 827 0648 706 Email: barryleiba@computer.org