idnits 2.17.1 draft-ietf-vpim-pndn-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1050 has weird spacing: '...for the purpo...' -- 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 14, 2000) is 8687 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 section? '1' on line 18 looks like a reference -- Missing reference section? '2' on line 32 looks like a reference -- Missing reference section? '3' on line 873 looks like a reference -- Missing reference section? '4' on line 223 looks like a reference -- Missing reference section? '5' on line 906 looks like a reference -- Missing reference section? '6' on line 97 looks like a reference -- Missing reference section? '7' on line 146 looks like a reference -- Missing reference section? '8' on line 242 looks like a reference -- Missing reference section? '9' on line 275 looks like a reference -- Missing reference section? '10' on line 799 looks like a reference -- Missing reference section? '11' on line 875 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Burger 3 Internet Draft Centigram Communications 4 Document: draft-ietf-vpim-pndn-00.txt July 14, 2000 5 Obsoletes: draft-ema-vpim-pndn-01.txt 6 Category: Standards Track 7 Expires in six months 9 Partial Non-Delivery Notification 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Other documents may update, replace, or obsolete this 21 document at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 31 This document describes the interaction between systems sending 32 multi-part Internet mail [2] to systems that cannot render parts of 33 the sent message. In particular, this document describes an 34 extension to the Delivery Status Notification mechanism described in 35 [3]. 37 An example of partial message delivery failure is the case when a 38 user sends an audio file and a video file to an Internet Voice Mail 39 [4] system. The Internet Voice Mail system can render the audio 40 part but not the video part. In this case, a partial delivery 41 occurs. 43 This document reflects work undertaken in support of the Internet 44 Voice Mail and Voice Profile for Internet Mail [5] initiatives. The 45 VPIM Work Group home page is . 47 Table of Contents 49 1. Abstract .....................................................1 50 2. Conventions used in this document ............................2 51 3. Introduction .................................................3 53 4. Operation ....................................................5 54 5. Contents of the PNDN .........................................6 55 5.1. The message/partial-delivery-status content-type ..........6 56 5.2. Per-Message PNDN Fields ...................................7 57 5.2.1. Fields from RFC 1894 .................................7 58 5.2.2. Original-Message-ID ..................................7 59 5.3. Per-Part PNDN Fields ......................................8 60 5.3.1. Fields from RFC 1894 .................................8 62 5.3.2. Action Field .........................................8 63 5.3.3. Final Recipient Field ................................9 64 5.3.4. Original Content ID Field ............................9 65 5.3.5. Original Content Description Field ...................9 66 5.3.6. Original Content Disposition Field ..................10 67 5.3.7. Original Content Type Field .........................10 68 5.3.8. Status Field ........................................10 70 6. Appendix - Examples .........................................11 71 6.1. PNDN With One Failed Body Part ...........................13 72 6.2. PNDN With Two Failed Body Parts ..........................14 73 6.3. PNDN With One Body Part Failure and Two Recipients .......15 74 6.4. PNDN With One Body Part Failure for One Recipient and 75 Another Body Part Failure for Two Recipients .............16 76 7. Formal Syntax ...............................................17 77 8. Security Considerations .....................................19 79 8.1. Forgery ..................................................19 80 8.2. Confidentiality ..........................................19 81 9. References ..................................................21 82 10. Acknowledgments .............................................21 83 11. Author's Address ............................................22 84 12. Notices and Full Copyright Statement ........................23 86 2. Conventions used in this document 88 This document refers generically to the sender of a message in the 89 masculine (he/him/his) and the recipient of the message in the 90 feminine (she/her/hers). This convention is purely for convenience 91 and makes no assumption about the gender of a message sender or 92 recipient. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 96 this document are to be interpreted as described in RFC-2119 [6]. 98 FORMATTING NOTE: Notes, such at this one, provide additional 99 nonessential information that the reader may skip without missing 100 anything essential. The primary purpose of these non-essential 101 notes is to convey information about the rationale of this document, 102 or to place this document in the proper historical or evolutionary 103 context. Readers whose sole purpose is to construct a conformant 104 implementation may skip such information. However, it may be of use 105 to those who wish to understand why we made certain design choices. 107 3. Introduction 109 This document describes partial non-delivery notifications (PNDN). 110 Partial non-delivery notifications are an extension of the Delivery 111 Status Notification (DSN) described in RFC 1894 [3]. 113 The need for a partial non-delivery notification comes about because 114 of the internetworking of Internet mail systems with legacy 115 messaging systems that do not fulfil all of the semantics of 116 Internet mail. Such legacy systems have a limited ability to render 117 all parts of a given message. This document will use the case of an 118 Internet mail system sending electronic messages a legacy voice 119 messaging system for illustrative purposes. 121 Electronic mail has historically been text-centric. Extensions such 122 as MIME enable the desktop to send and receive multi-part, 123 multimedia messages. Popular multimedia data types include binary 124 word processing documents, binary business presentation graphics, 125 voice, and video. 127 Voice mail has historically been audio-centric. Many voice 128 messaging systems can only render voice. Extensions such as fax 129 enable the voice mail system to send and receive fax images as well 130 as create multi-part voice and fax messages. A few voice mail 131 systems can render text using text-to-speech or text-to-fax 132 technology. Although theoretically possible, none can today render 133 video. 135 An important aspect of the interchange between voice messaging 136 services and desktop e-mail client applications is that the 137 rendering capability of the voice messaging platform is often much 138 less than the rendering capability of a desktop e-mail client. In 139 the e-mail case, the sender has the expectation that the recipient 140 receives all components of a multimedia message. This is so even if 141 the recipient cannot render all body parts. For the most part, the 142 recipient can either find the appropriate rendering tool or tell the 143 sender that she cannot read the particular attachment. 145 This is an important issue. By definition, a MIME-enabled user 146 agent, conforming to [7] will present or make available all of the 147 body parts to the recipient. However, a voice mail system may not 148 be capable of storing non-voice objects. Moreover, the voice mail 149 system may not be capable of notifying the recipient that there were 150 undeliverable message parts. 152 The inability of the receiving system to render a body part is 153 usually a permanent failure. Retransmission of the message will not 154 improve the likelihood of a future successful delivery. Contrast 155 this to the case with normal data delivery. Traditional message 156 failures, such as a garbled message or disabled link will benefit 157 from retransmission. 159 Note that the PNDN does not attempt to address User Agent failures, 160 such as a corruption of a body part. PNDN only addresses the 161 capability of a system to handle the data type by observing the 162 part's metadata. Other mechanisms, such as Message Disposition 163 Notification [8], can address the situation when the recipient 164 system discovers an error in the payload of a body part. 166 This document addresses the need to allow Internet e-mail client 167 applications to send arbitrary multi-part multimedia messages to 168 voice messaging systems, retaining the semantics of delivery 169 notification, while taking into account the limitations of the voice 170 messaging system's rendering capabilities. The method described by 171 this document is applicable to any interface between a full-featured 172 user agent and a recipient mail transfer agent that has less 173 rendering and media type storage capabilities than the sender has. 175 Ideally, the voice mail system would notify the recipient of the 176 undeliverable body parts. Such behavior would satisfy the essential 177 requirements of [8]. In fact, if the voice mail system can notify 178 the recipient there were undeliverable body parts, then there would 179 be no need for this document. However, many voice mail systems are 180 not capable of making this notification. 182 NOTE: Another method of handling partial delivery is to determine 183 what parts of the message the sender considers critical. If the 184 voice mail system could not deliver the critical parts, then the 185 voice mail system would reject the entire message. If the voice 186 mail system could deliver the critical parts, but there were other 187 undeliverable parts, it would silently delete the parts from the 188 delivered message. However, currently there is no method to 189 identify critical parts. In light of the limitations of voice mail 190 systems, we decided to deliver as much of the message as possible, 191 notifying the sender of any parts that the voice mail system fails 192 to deliver. 194 NOTE: The concept of a critical part indicator is still a useful 195 construction. The sender may wish to specify a body part as so 196 important that if the system cannot deliver the specified body part, 197 then the system will not deliver any parts of the message. However, 198 this is beyond the scope of this document. We should revisit this 199 issue once there is an acceptable mechanism for identifying critical 200 parts. 202 4. Operation 204 The sending system sees the Internet Voice Mail system as a peer e- 205 mail client. The only special consideration on the part of the 206 sending system is that it may encode the MIME message following the 207 format specified by VPIM [5] or the Internet Voice Mail Profile [4]. 208 Properly encoding and profiling the message will enhance the 209 receiving system's ability to process and successfully deliver the 210 message. Such considerations include the formatting and encoding of 211 the sender's audio name clip, return address information, out-dial 212 destinations, and other elements. Refer to [5] for more 213 information. 215 The recipient system, on receipt of e-mail destined for a voice mail 216 user, makes a best-efforts attempt to deliver what parts it can to 217 the user. 219 If the recipient system is capable of delivering the entire message, 220 it follows the notification protocols specified in [4]. 222 If the recipient system cannot deliver any part of the message, it 223 will return the non-delivery notification specified in [4]. 225 If the recipient system is capable of delivering only part of the 226 message, it will return a partial non-delivery notification (PNDN) 227 as described below. 229 Delivery failure can occur for all recipients of a message because 230 the recipient system cannot handle a given body part. However, 231 body-part delivery failure can also occur for a subset of recipients 232 of a message. This happens if the recipient system is capable of 233 handling the media type of the body part, but the recipient user 234 does not subscribe to a service that can present the media type. 235 For example, consider an Internet Voice Mail platform that can 236 handle fax. Now consider a service provider that has a class of 237 service that is voice only. If the message recipient user has a 238 voice only class of service, she will not be able to render fax, 239 which is an image. 241 NOTE: We chose Delivery Status Notification (DSN) [3] over Message 242 Disposition Notification (MDN) [8] as a model for PNDN. There was 243 some discussion on this point because an Internet Voice Mail system 244 acts as both a UA and a MTA. The Message Disposition Notification 245 deals with things such as return receipt. The generation of the 246 return receipt can occur long after the receiving system has 247 received the message. On the other hand, the receiving system can 248 know on receipt whether it has the capabilities to deliver all parts 249 of the message. In this case, the recipient acts more like an MTA 250 than a UA. In addition, we decided it was more important for the 251 sender to know the system would never deliver some parts of the 252 message. It would not be desirable to wait for the recipient to 253 attempt to read the message and only at that point generate a 254 notification that the system could not deliver parts of the message. 256 NOTE: This is why the language uses "is capable of delivering" 257 rather than "delivers" in the description above. 259 5. Contents of the PNDN 261 The PNDN informs a human or machine sender that the recipient system 262 could not deliver one or more parts of a message they have sent. 264 The PNDN is a special case of Delivery Status Notification. In the 265 sections that follow, refer to [3] for a full description of the 266 fields. 268 The receiving system transmits a PNDN as a MIME message with a top- 269 level content-type of multipart/report, as defined in [3]. 271 The mail system can use the multipart/report content-type for any of 272 several kinds of reports. For a PNDN, the report-type parameter 273 uses the DSN multipart/report content-type of "delivery-status". 275 As described in [9], the first part of a multipart/report content- 276 type is a human readable explanation of the report. For a PNDN, the 277 second component of the multipart/report is of content-type 278 message/delivery-status. The third component of the 279 multipart/report consists of the original message or some portion 280 thereof. 282 5.1. The message/delivery-status content-type 284 The message/delivery-status content-type definition is as follows: 286 MIME type name: message 287 MIME subtype name: delivery-status 288 Optional parameters: none. 289 Encoding considerations: "7bit" encoding is sufficient and 290 conforming systems MUST use it to 291 maintain readability when viewed 292 by non-MIME mail readers. 293 Security considerations: discussed in section 7 of this memo. 295 The message/delivery-status report type for use in the 296 multipart/report is "delivery-status". 298 The body of a message/delivery-status consists of one or more 299 "fields" formatted according to the ABNF [10] specified below and in 300 [3]. The per-message fields appear first, followed by a blank line. 301 Following the per-message fields are one or more groups of per- 302 recipient/per-body part fields. A blank line precedes each group of 303 per-recipient fields. 305 The syntax of the message/delivery-status content is in section 7. 307 Section 5.2 describes the per-message-fields. Section 5.3 describes 308 the per-part-fields. 310 NOTE: Readers should focus on Section 5.3 as it describes the 311 essential extensions to DSN. 313 5.2. Per-Message PNDN Fields 315 5.2.1. Fields from RFC 1894 317 Except as noted below, the PNDN contains all fields as appropriate 318 from DSN [3]. In particular, Reporting-MTA MUST be present. 320 NOTE: The sender's MTA could generate a DSN. In this case, the 321 Reporting-MTA is optional. However, only receiving systems will 322 generate Partial Non-Delivery Notifications. Thus, the sender needs 323 to know who reported the failure. 325 5.2.2. Original-Message-ID 327 The recipient system MUST generate an Original-Message-ID field if a 328 Message-ID field was present in the original message. 330 NOTE: This is a change from RFC 1894. Few User Agents insert an 331 Envelope-ID. The sender needs to know what message failed. Sending 332 back the original message in a multimedia environment has security 333 implications. In particular, requiring the receiving system to send 334 back large multimedia files would make them vulnerable to denial of 335 service attacks. Moreover, MIME-encoded body parts are in base64. 336 Since we cannot rely on the user recognizing the original text of 337 their message, we must rely on alternative identifying 338 characteristics. 340 5.3. Per-Part PNDN Fields 342 A PNDN contains information about attempts to deliver a message's 343 parts to one or more recipients. A group of contiguous per-message, 344 per-recipient body-part content partial non-delivery notification 345 fields contains delivery information for that recipient. A blank 346 line precedes each group of per-recipient fields. 348 PNDN expands upon DSN by introducing body part indicators to DSN's 349 per-recipient block. This extension allows multiple body part 350 indicators per per-recipient block. A conforming implementation 351 MUST choose to separate each body-part failure into its own per- 352 recipient block. 354 For example, take a message sent to two users, A and B. In 355 addition, let's say that Part 1 fails for the same reason for both 356 users, and Part 2 fails only for user B for the same reason Part 1 357 failed. Here is the way of rendering the per-recipient block. 359 Recipient A Failure 360 Part 1 Failure 362 Recipient B Failure 363 Part 1 Failure 364 Part 2 Failure 366 NOTE: This RFC could have allowed splitting the report by body- 367 parts. However, this would break other NDN implementations, 368 especially MIXER. 370 5.3.1. Fields from RFC 1894 372 Except as noted below, the PNDN contains all fields as appropriate 373 from DSN [3]. The Original-Recipient, Final-Recipient, Last- 374 Attempt-Date, and Final-Log-ID fields follow their meaning and 375 requirements set forth in DSN. The Will-Retry-Until field is not 376 relevant, as the PNDN is not a delayed delivery notification. 378 5.3.2. Action Field 380 The action field reflects the disposition of the message. Since the 381 receiving system can deliver at least part of the message, the 382 action value SHOULD be "delivered". If the recipient system did not 383 deliver any parts of the message, then it would perform the normal 384 undeliverable message processing described by DSN [3]. 386 NOTE: Considering partial delivery a failure or a success is a 387 matter of many debates. There is work ongoing in the IETF to 388 develop an indicator for identifying critical body parts. With a 389 critical body part indicator, the recipient system can return to the 390 sender a success or failure indication based on whether or not the 391 system succeeded in delivering the critical parts. 393 Without critical part indicators, one may chose to err on the side 394 of failing the entire message. However, from a practical point of 395 view, the sender probably will have some idea of the capabilities of 396 the recipient. Moreover, experience shows that users do not take 397 well to being bombarded with failure notices they believe should be 398 warnings. 400 Therefore, until such a time as we have a critical body part 401 indicator, the best practice is to return a delivered notice to the 402 sender, with the appropriate warning and explanation message for the 403 body part(s) not delivered. 405 5.3.3. Final Recipient Field 407 The Final-Recipient field indicates the recipient for which this set 408 of per-part fields applies. The definition of the final recipient 409 field is as described by DSN [3]. However, for security reasons, 410 the PNDN relaxes the imperative for including this field. That is, 411 the per-part data MAY include the final recipient field 413 NOTE: The change in imperative from [3], from MUST to MAY, comes 414 from the Internet Voice Mail environment. One can envision Internet 415 Voice Mail implementations where the service provider wishes to keep 416 the actual host name of the voice mail system hidden yet in the 417 Internet name space. Reporting the final recipient field may 418 include the actual host name of a voice mail node. Making that 419 information public through a PNDN may enable attacks on that node. 421 5.3.4. Original Content ID Field 423 The Original-Content-ID field MUST be present in the PNDN if a 424 Content-ID field is present in the original message. This field 425 aids the sender in understanding exactly which body part the 426 receiving system is not capable of delivering. 428 5.3.5. Original Content Description Field 430 The Original-Content-Description field MUST be present in the PNDN 431 if a Content-Description field is present in the original message. 433 This field aids the sender in understanding exactly which body part 434 the receiving system is not capable of delivering. This field will 435 be much more useful than the Original-Content-ID field to a human 436 sender. However, few User Agents insert the Content-Description 437 field in a message. 439 5.3.6. Original Content Disposition Field 441 The Original-Content-Disposition field MAY be present in the PNDN if 442 a Content-Disposition field is present in the original message. 444 If the original message does not have a Content-Type field, the 445 Original-Content-Disposition field MUST be present in the PNDN if a 446 Content-Disposition field is present in the original message. 448 The Original-Content-Disposition field aids the sender in 449 understanding exactly which body part the receiving system is not 450 capable of delivering. This field will be more useful than the 451 Original-Content-ID field to a human sender. It will let the human 452 know the file name of the part the receiving system is not capable 453 of handling. 455 5.3.7. Original Content Type Field 457 The Original-Content-Type field MUST be present in the PNDN if a 458 Content-Type field is present in the original message. This field 459 aids the sender in understanding exactly which body part the 460 receiving system is not capable of delivering. This field will be 461 much more useful than the Original-Content-ID field to a human 462 sender. It will let the human know the MIME types that the 463 receiving system is not capable of handling. In addition, the 464 sender will get a clue as to what body part the receiving system is 465 not capable of handling from the filename sub-field, if present. 467 5.3.8. Status Field 469 Message Transfer Agents (MTAs) are free to generate standard status 470 codes from [11]. This section describes status codes that have 471 special meaning for PNDN. 473 All of these status codes are of type "permanent failures of media", 474 type 5. 476 Receiving systems that generate Partial Non-Delivery Notifications 477 MUST insert descriptive text in the comment field of the status code 478 so a human sender can understand why his message failed. 480 Sending systems that automatically process returned status codes 481 MUST use the numeric status code and MUST NOT use the comment. 483 5.3.8.1. Media not Supported 485 If the recipient system is not capable of delivering a part of a 486 message because it does not support a given media type, it MUST 487 return the Media not Supported status code. For example, if an 488 Internet Voice Mail system receives an AutoCAD document and it can 489 only render voice, the Internet Voice Mail system will return a 490 Media not Supported status code. 492 The Media not Supported status code is 5.6.1 [11]. 494 5.3.8.2. Conversion With Loss Performed 496 If the recipient system can deliver the part, but only with a lossy 497 conversion, the receiving system SHOULD NOT return Conversion With 498 Loss Performed. 500 NOTE: We considered the optional return code of Conversion With 501 Loss Performed, Status 5.6.4. However, we realized two things. 502 First, few Internet Voice Mail systems would necessarily have the 503 capability of generating this warning. Second, there is dubious 504 value to the sender of receiving this warning. If the receiver has 505 trouble understanding the rendering of the body part, she can always 506 send a message to the sender. On the other hand, we could foresee 507 confusion on the part of the sender if he constantly received 508 warning messages every time he sends a message to the particular 509 recipient. 511 6. Appendix - Examples 513 NOTE: These examples are for illustrative purposes only and are not 514 a normative part of the PNDN definition. If an example conflicts 515 with the normative description of sections 3 through 5, the example 516 is wrong. 518 The examples in this appendix use the following MIME-Encoded message 519 for the original sent message. 521 The message has three parts. The first part is a text message. The 522 second part is a voice message. The third part is a fax message. 523 Here is the sample message. 525 Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com 526 From: "Eric Burger" 527 To: "Eric Burger" 528 Subject: Three-part Message 529 Date: Mon, 22 Nov 1999 12:02:30 -0500 530 MIME-Version: 1.0 531 Content-Type: multipart/mixed; 532 boundary="----=_NextPart_000_0007_01BF34E1.74123720" 533 X-Priority: 3 534 X-Mailer: The One And Only Test Platform V8.1222.974B 536 This is a multi-part message in MIME format. 538 ------=_NextPart_000_0007_01BF34E1.74123720 539 Content-Type: text/plain; 540 charset="iso-8859-1" 541 Content-Transfer-Encoding: 7bit 542 Content-ID: TextPart0AFF8B 544 Here is a three-part message. The first part is text (this one). 545 The second part is voice. The third part is fax. 547 ------=_NextPart_000_0007_01BF34E1.74123720 548 Content-Type: audio/wav; 549 name="Voice Message.wav" 550 Content-Transfer-Encoding: base64 551 Content-Disposition: attachment; 552 filename="Voice Message.wav" 554 UklGRjgRAABXQVZFZm10IBQAAAAxAAEAQB8AAFkGAABBAAAAAgBAAWZhY3QEAAAAwFMA 555 EQAASfYQFoWCEkuSTST3JGyiTbIfDybr9hltilsnh+uBo/OEpE1iTFGWuFEcFJFuVAxk 556 ... 557 0TIT1twS7JVeyYHHFDaWIEN1mcYMlvLNgGoakdxbL2ErxZprJS+htNhu4ozNYKmwCGvT 558 wErbIgazEvRAGn5hMxhcqGS59UE1cHEjR08A 560 ------=_NextPart_000_0007_01BF34E1.74123720 561 Content-Type: image/tiff; 562 name="My House.tif" 563 Content-Transfer-Encoding: base64 564 Content-Disposition: attachment; 565 filename="My House.tif" 566 Content-Description: Picture of My House 568 SUkqABhSAAAAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFN 569 AU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAGRqDuH4JefU8/YSwd8/xdn7CKC4PMW 570 ... 571 UAAAGgEFAAEAAAAIUgAAGwEFAAEAAAAQUgAAJAEEAAEAAAAEAAAAKAEDAAEAAAACAAAA 572 AAAAAAEARgEDAAEAAAAAAAAARwEDAAEAAAAAAAAAAAAAAA== 574 ------=_NextPart_000_0007_01BF34E1.74123720-- 576 6.1. PNDN With One Failed Body Part 578 This example shows a PNDN for a system that does not handle text, 579 but does handle voice and fax. 581 Date: Thu, 22 Nov 1999 09:05:15 -0800 582 From: Mail Delivery Subsystem 583 Message-Id: <199407072116.RAA14128@TELECNNCT> 584 Subject: WARNING: Could Not Delivery Body Part 585 To: 586 MIME-Version: 1.0 587 Content-Type: multipart/report; report-type=delivery-status; 588 boundary="RAA14128.773615765/CENTIGRAM.COM" 590 --RAA14128.773615765/CENTIGRAM.COM 592 The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 593 from root@localhost 595 ----- The following addresses had delivery problems ----- 596 (warning) 598 ----- Transcript of session follows ----- 599 Could Not Deliver Text Part to < eric.burger@centigram.com > 601 Body part will be deleted from queue 603 --RAA14128.773615765/CENTIGRAM.COM 604 content-type: message/delivery-status 606 Original-Message-ID: 607 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com 608 Reporting-MTA: dns; telecnnct.com 610 Action: delivered 611 Status: 5.6.1 (Media not Supported) 612 Original-Recipient: rfc822;eric.burger@centigram.com 613 Original-Content-ID: TextPart0AFF8B 615 --RAA14128.773615765/CENTIGRAM.COM 616 content-type: message/rfc822 618 Here is a three-part message. The first part is text (this one). 619 The second part is voice. The third part is fax. 621 --RAA14128.773615765/CENTIGRAM.COM-- 623 6.2. PNDN With Two Failed Body Parts 625 This example shows a PNDN for a system that does not handle text or 626 fax. 628 Date: Thu, 22 Nov 1999 09:05:15 -0800 629 From: Mail Delivery Subsystem 630 Message-Id: <199407072116.RAA14128@TELECNNCT> 631 Subject: WARNING: Could Not Delivery Body Part 632 To: 633 MIME-Version: 1.0 634 Content-Type: multipart/report; report-type=delivery-status; 635 boundary="RAA14128.773615765/CENTIGRAM.COM" 637 --RAA14128.773615765/CENTIGRAM.COM 639 The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 640 from root@localhost 642 ----- The following addresses had delivery problems ----- 643 (warning) 645 ----- Transcript of session follows ----- 646 Could Not Deliver Text Part to < eric.burger@centigram.com > 647 Could Not Deliver Fax Part to < eric.burger@centigram.com > 649 Body parts will be deleted from queue 651 --RAA14128.773615765/CENTIGRAM.COM 652 content-type: message/delivery-status 654 Original-Message-ID: 655 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com 656 Reporting-MTA: dns; telecnnct.com 658 Original-Recipient: rfc822;eric.burger@centigram.com 659 Status: 5.6.1 (Media not Supported) 660 Action: delivered 661 Original-Content-Description: Picture of My House 662 Original-Content-Type: image/tiff; name="My House.tif" 663 Original-Content-Disposition: attachment; filename="My House.tif" 664 Status: 5.6.1 (Media not Supported) 665 Action: delivered 666 Original-Content-ID: TextPart0AFF8B 668 --RAA14128.773615765/CENTIGRAM.COM 669 content-type: message/rfc822 670 Here is a three-part message. The first part is text (this one). 671 The second part is voice. The third part is fax. 673 --RAA14128.773615765/CENTIGRAM.COM-- 675 6.3. PNDN With One Body Part Failure and Two 676 Recipients 678 This example shows a PNDN for a system that does not handle text, 679 but does handle voice and fax. Assume the original message was sent 680 to and <8005551212@vm.sp.net>. 682 Date: Thu, 22 Nov 1999 09:05:15 -0800 683 From: Mail Delivery Subsystem 684 Message-Id: <199407072116.RAA14128@TELECNNCT> 685 Subject: WARNING: Could Not Delivery Body Part 686 To: 687 MIME-Version: 1.0 688 Content-Type: multipart/report; report-type=delivery-status; 689 boundary="RAA14128.773615765/CENTIGRAM.COM" 691 --RAA14128.773615765/CENTIGRAM.COM 693 The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 694 from root@localhost 696 ----- The following addresses had delivery problems ----- 697 (warning) 698 <8005551212@vm.sp.net> (warning) 700 ----- Transcript of session follows ----- 701 Could Not Deliver Text Part to < eric.burger@centigram.com > 702 Could Not Deliver Text Part to < 8005551212@vm.sp.net > 704 Body part will be deleted from queue 706 --RAA14128.773615765/CENTIGRAM.COM 707 content-type: message/delivery-status 709 Original-Message-ID: 710 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com 711 Reporting-MTA: dns; telecnnct.com 713 Action: delivered 714 Status: 5.6.1 (Media not Supported) 715 Original-Recipient: rfc822;eric.burger@centigram.com 716 Final-Recipient: rfc822;eburger@vmail27.sp.net 717 Original-Content-ID: TextPart0AFF8B 718 Action: delivered 719 Status: 5.6.1 (Media not Supported) 720 Original-Recipient: rfc822;8005551212@vm.sp.net 721 Final-Recipient: rfc822;eburger@vmail27.sp.net 722 Original-Content-ID: TextPart0AFF8B 724 --RAA14128.773615765/CENTIGRAM.COM 725 content-type: message/rfc822 727 Here is a three-part message. The first part is text (this one). 728 The second part is voice. The third part is fax. 730 --RAA14128.773615765/CENTIGRAM.COM-- 732 6.4. PNDN With One Body Part Failure for One Recipient 733 and Another Body Part Failure for Two Recipients 735 This example shows a PNDN for a system that does not handle text, 736 but does handle voice and fax. However, the recipient at 737 ericb@mtc.telecnnct.com does not subscribe to a fax service. Assume 738 the original message was sent to and 739 <8005551212@vm.sp.net>. 741 Date: Thu, 22 Nov 1999 09:05:15 -0800 742 From: Mail Delivery Subsystem 743 Message-Id: <199407072116.RAA14128@TELECNNCT> 744 Subject: WARNING: Could Not Delivery Body Part 745 To: 746 MIME-Version: 1.0 747 Content-Type: multipart/report; report-type=delivery-status; 748 boundary="RAA14128.773615765/CENTIGRAM.COM" 750 --RAA14128.773615765/CENTIGRAM.COM 752 The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 753 from root@localhost 755 ----- The following addresses had delivery problems ----- 756 (warning) 757 <8005551212@vm.sp.net> (warning) 759 ----- Transcript of session follows ----- 760 Could Not Deliver Text Part to < eric.burger@centigram.com > 761 Could Not Deliver Text Part to < 8005551212@vm.sp.net > 762 Could Not Deliver Fax Part to < eric.burger@centigram.com > 763 Body part will be deleted from queue 765 --RAA14128.773615765/CENTIGRAM.COM 766 content-type: message/delivery-status 768 Original-Message-ID: 769 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com 770 Reporting-MTA: dns; telecnnct.com 772 Action: delivered 773 Status: 5.6.1 (Media not Supported) 774 Original-Recipient: rfc822;eric.burger@centigram.com 775 Final-Recipient: rfc822;eburger@vmail27.sp.net 776 Original-Content-ID: TextPart0AFF8B 777 Action: delivered 778 Status: 5.6.1 (Media not Supported) 779 Original-Content-Description: Picture of My House 780 Original-Content-Type: image/tiff; name="My House.tif" 781 Original-Content-Disposition: attachment; filename="My House.tif" 783 Action: delivered 784 Status: 5.6.1 (Media not Supported) 785 Original-Recipient: rfc822;8005551212@vm.sp.net 786 Original-Content-ID: TextPart0AFF8B 788 --RAA14128.773615765/CENTIGRAM.COM 789 content-type: message/rfc822 791 Here is a three-part message. The first part is text (this one). 792 The second part is voice. The third part is fax. 794 --RAA14128.773615765/CENTIGRAM.COM-- 796 7. Formal Syntax 798 The following syntax specification uses the augmented Backus-Naur 799 Form (BNF) as described in RFC-2234 [10]. 801 delivery-status-content = 802 per-message-fields 1*( CRLF per-part-fields) 804 7.1. Syntax of Per-Message Fields 806 per-message-fields = 807 [ original-message-id-field CRLF ] 808 [ original-envelope-id-field CRLF ] 809 reporting-mta-field CRLF 811 [ dsn-gateway-field CRLF ] 812 [ received-from-mta-field CRLF ] 813 [ arrival-date-field CRLF ] 814 *( extension-field CRLF ) 816 original-message-id-field = 817 "Original-Message-ID" ":" message-id 819 message-id = *text 821 Original-envelope-id-field, reporting-mta-field, dsn-gateway-field, 822 received-from-mta-field, arrival-date-field, and extension-field are 823 all as defined in DSN [3]. 825 7.2. Syntax of Per-Part Fields 827 per-part-fields = 828 1*( [ original-content-description-field CRLF ] 829 [ original-content-id-field CRLF ] 830 [ original-content-disposition-field CRLF ] 831 [ original-content-type-field CRLF ] ) 832 1*( [ original-recipient-field CRLF ] 833 final-recipient-field CRLF ) 834 action-field CRLF 835 status-field CRLF 836 [ remote-mta-field CRLF ] 837 [ diagnostic-code-field CRLF ] 838 [ last-attempt-date-field CRLF ] 839 *( extension-field CRLF ) 841 action-field = 842 "Action: delivered" 844 original-content-id-field = 845 "Original-Content-ID" ":" content-id 847 content-id = *text 849 original-content-description-field = 850 "Original-Content-Description" ":" content-description 852 content-description = *text 854 original-content-disposition-field = 855 "Original-Content-Disposition" ":" content-disposition 857 content-disposition = *text 858 original-content-type-field = 859 "Original-Content-Type" ":" content-type 861 content-type = *text 863 status-field = 864 "Status" ":" status-code "(" comment ")" 866 status-code = 867 DIGIT "." 1*3DIGIT "." 1*3DIGIT 869 comment = *text 871 Original-recipient-field, final-recipient-field, remote-mta-field, 872 diagnostic-code-field, last-attempt-date-field, and extension-field 873 are as defined in DSN [3]. 875 Status-code is defined in [11]. 877 8. Security Considerations 879 The following security considerations apply when using PNDNs. 881 8.1. Forgery 883 One can forge a PNDN as easily as ordinary Internet electronic mail. 884 User agents and automatic mail handling facilities (such as 885 automatic voice mail forwarding agents) that wish to make use of 886 PNDNs should take appropriate precautions to minimize the potential 887 damage from denial-of-service attacks. 889 Security threats related to forged PNDNs include the sending of: 891 (a) A falsified delivery notification when the message is 892 not delivered to the indicated recipient, 893 (b) A falsified Final-Recipient address, or 894 (c) A falsified Remote-MTA identification. 896 8.2. Confidentiality 898 Another dimension of security is confidentiality. For example, a 899 message recipient can be autoforwarding messages. However, she does 900 not wish to divulge her autoforward address. The desire for such 901 confidentiality will probably be heightened as "wireless mailboxes", 902 such as pagers, become more widely used as autoforward addresses. 904 Confidentiality also applies to the service provider. For example, 905 in an Internet Voice Mail scenario, one can envision implementations 906 of protocols such as VPIM [5] where reporting the actual Internet 907 host name can open the system to attack. 909 MTA authors are encouraged to provide a mechanism that enables the 910 end user to preserve the confidentiality of a forwarding address. 911 Depending on the degree of confidentiality required, and the nature 912 of the environment to which a message were being forwarded, this 913 might be accomplished by one or more of: 915 (a) omitting the "Final-Recipient" field, as it has 916 little use to the sender, 918 (b) omitting "Remote-*" or extension fields of a PNDN 919 whenever they would otherwise contain confidential 920 information (such as a confidential forwarding address), 922 (c) for messages forwarded to a confidential address, 923 setting the envelope return address (e.g. SMTP MAIL FROM 924 address) to the NULL reverse-path ("<>") (so that no 925 PNDNs would be sent from a downstream MTA to the 926 original sender), or 928 (d) when forwarding mail to a confidential address, having 929 the forwarding MTA rewrite the envelope return address 930 for the forwarded message and attempt delivery of that 931 message as if the forwarding MTA were the originator. 932 On its receipt of final delivery status, the forwarding 933 MTA would issue a PNDN to the original sender. 935 In general, the Reporting MTA site can omit any optional PNDN field 936 that it determines inclusion of the field would impose too great a 937 compromise of site confidentiality. The need for such 938 confidentiality must be balanced against the utility of the omitted 939 information in trouble reports. 941 Implementers are cautioned that many existing MTAs will send non- 942 delivery notifications to a return address in the message header 943 (rather than to the one in the envelope), in violation of SMTP and 944 other protocols. If a message is forwarded through such an MTA, no 945 reasonable action on the part of the forwarding MTA will prevent the 946 downstream MTA from compromising the forwarding address. Likewise, 947 if the recipient's MTA automatically responds to messages based on a 948 request in the message header (such as the nonstandard, but widely 949 used, Return-Receipt-To extension header), it will also compromise 950 the forwarding address. 952 9. References 954 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 955 9, RFC 2026, October 1996. 957 2 Freed, N. and Borenstein, N, "Multipurpose Internet Mail 958 Extensions (MIME) Part One: Format of Internet Message Bodies", 959 RFC 2045, Innosoft and First Virtual, November 1996. 961 3 Moore, K. and Vaudreuil, G., "An Extensible Message Format for 962 Delivery Status Notifications", RFC 1894, U. Tennessee and Octel 963 Network Services, January 1996. 965 4 a.k.a. VPIMv3 967 5 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - 968 version 2", Lucent Technologies and Nortel Networks, RFC 2421, 969 September 1998. 971 6 Bradner, S., "Key words for use in RFCs to Indicate Requirement 972 Levels", BCP 14, RFC 2119, March 1997. 974 7 Freed, N. and Borenstein, N, "Multipurpose Internet Mail 975 Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and 976 First Virtual, November 1996. 978 8 Fajman, R., "An Extensible Message Format for Message Disposition 979 Notifications", RFC 2298, National Institutes of Health, March 980 1998. 982 9 Vaudreuil, G., "The Multipart/Report Content Type for the 983 Reporting of Mail System Administrative Messages", RFC 1892, 984 Octel Network Services, January 1996. 986 10 Crocker, D. and Overell, P., "Augmented BNF for Syntax 987 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 988 Demon Internet Ltd., November 1997. 990 11 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 991 Octel Network Systems, January 1996. 993 10. Acknowledgments 995 I'd like to thank Graham Klyne and Keith Moore for valuable insights 996 into the mechanics of DSN. Graham Klyne also helped me put this 997 document into English. However, any bizarre language is my own 998 fault. 1000 Ned Freed and Herman R. Silbiger both had valuable experience 1001 corroborating the assertion that users do not like to receive 1002 failure notices unless there is a real failure. Carl-Uno Mauros was 1003 able to put into words much better than I did in a prior draft the 1004 differences between a system that cannot render a particular part 1005 versus a transmission failure. 1007 11. Author's Address 1009 Eric W. Burger 1010 Centigram Communications Corporation 1011 Maryland Technology Center 1012 1375 Piccard Dr., MS 150 R 1013 Rockville, MD 20850-4311 1014 USA 1015 Phone: +1 301/212-3320 1016 Email: e.burger@ieee.org 1018 12. Notices and Full Copyright Statement 1020 The IETF takes no position regarding the validity or scope of any 1021 intellectual property or other rights that might be claimed to 1022 pertain to the implementation or use of the technology described in 1023 this document or the extent to which any license under such rights 1024 might or might not be available; neither does it represent that it 1025 has made any effort to identify any such rights. Information on the 1026 IETF's procedures with respect to rights in standards-track and 1027 standards-related documentation can be found in BCP-11. Copies of 1028 claims of rights made available for publication and any assurances 1029 of licenses to be made available, or the result of an attempt made 1030 to obtain a general license or permission for the use of such 1031 proprietary rights by implementors or users of this specification 1032 can be obtained from the IETF Secretariat. 1034 The IETF invites any interested party to bring to its attention any 1035 copyrights, patents or patent applications, or other proprietary 1036 rights which may cover technology that may be required to practice 1037 this standard. Please address the information to the IETF Executive 1038 Director. 1040 Copyright (C) 1999, 2000 The Internet Society. All Rights Reserved. 1042 This document and translations of it may be copied and furnished to 1043 others, and derivative works that comment on or otherwise explain it 1044 or assist in its implmentation may be prepared, copied, published 1045 and distributed, in whole or in part, without restriction of any 1046 kind, provided that the above copyright notice and this paragraph 1047 are included on all such copies and derivative works. However, this 1048 document itself may not be modified in any way, such as by removing 1049 the copyright notice or references to the Internet Society or other 1050 Internet organizations, except as needed for the purpose of 1051 developing Internet standards in which case the procedures for 1052 copyrights defined in the Internet Standards process must be 1053 followed, or as required to translate it into languages other than 1054 English. 1056 The limited permissions granted above are perpetual and will not be 1057 revoked by the Internet Society or its successors or assigns. 1059 This document and the information contained herein is provided on an 1060 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1061 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1062 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1063 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1064 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.