Network Working Group E. Burger Internet Draft Centigram Communications Corporation Document: draft-ema-vpim-pndn-01.txt March 1, 2000 Category: Standards Track Expires in six months Partial Non-Delivery Notification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Other documents may update, replace, or obsolete this document at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document describes the interaction between systems sending multi-part Internet mail [2] to systems that cannot render parts of the sent message. In particular, this document describes an extension to the Delivery Status Notification mechanism described in [3]. An example of partial message delivery failure is the case when a user sends an audio file and a video file to an Internet Voice Mail [4] system. The Internet Voice Mail system can render the audio part but not the video part. In this case, a partial delivery occurs. This document reflects work undertaken in support of the Internet Voice Mail and Voice Profile for Internet Mail [5] initiatives. The VPIM Work Group home page is . Burger Expires 9/1/2000 [Page 1] Partial Non-Delivery Notification March 1, 2000 Table of Contents 1. Abstract .....................................................1 2. Conventions used in this document ............................2 3. Introduction .................................................3 4. Operation ....................................................5 5. Contents of the PNDN .........................................6 5.1. The message/partial-delivery-status content-type ..........6 5.2. Per-Message PNDN Fields ...................................7 5.2.1. Fields from RFC 1894 .................................7 5.2.2. Original-Message-ID ..................................7 5.3. Per-Part PNDN Fields ......................................8 5.3.1. Fields from RFC 1894 .................................9 5.3.2. Action Field .........................................9 5.3.3. Final Recipient Field ...............................10 5.3.4. Original Content ID Field ...........................10 5.3.5. Original Content Description Field ..................10 5.3.6. Original Content Disposition Field ..................10 5.3.7. Original Content Type Field .........................11 5.3.8. Status Field ........................................11 6. Appendix - Examples .........................................12 6.1. PNDN With One Failed Body Part ...........................13 6.2. PNDN With Two Failed Body Parts ..........................14 6.3. PNDN With One Body Part Failure and Two Recipients .......15 6.4. PNDN With One Body Part Failure for One Recipient and Another Body Part Failure for Two Recipients .............16 7. Formal Syntax ...............................................18 8. Security Considerations .....................................19 8.1. Forgery ..................................................20 8.2. Confidentiality ..........................................20 9. References ..................................................21 10. Acknowledgments .............................................22 11. Author's Address ............................................22 12. Notices and Full Copyright Statement ........................23 2. Conventions used in this document This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient. Burger Internet Draft - Expires 9/1/2000 [Page 2] Partial Non-Delivery Notification March 1, 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [6]. FORMATTING NOTE: Notes, such at this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices. 3. Introduction This document describes partial non-delivery notifications (PNDN). Partial non-delivery notifications are an extension of the Delivery Status Notification (DSN) described in RFC 1894 [3]. The need for a partial non-delivery notification comes about because of the internetworking of Internet mail systems with legacy messaging systems that do not fulfil all of the semantics of Internet mail. Such legacy systems have a limited ability to render all parts of a given message. This document will use the case of an Internet mail system sending electronic messages a legacy voice messaging system for illustrative purposes. Electronic mail has historically been text-centric. Extensions such as MIME enable the desktop to send and receive multi-part, multimedia messages. Popular multimedia data types include binary word processing documents, binary business presentation graphics, voice, and video. Voice mail has historically been audio-centric. Many voice messaging systems can only render voice. Extensions such as fax enable the voice mail system to send and receive fax images as well as create multi-part voice and fax messages. A few voice mail systems can render text using text-to-speech or text-to-fax technology. Although theoretically possible, none can today render video. An important aspect of the interchange between voice messaging services and desktop e-mail client applications is that the rendering capability of the voice messaging platform is often much less than the rendering capability of a desktop e-mail client. In the e-mail case, the sender has the expectation that the recipient receives all components of a multimedia message. This is so even if the recipient cannot render all body parts. For the most part, the Burger Internet Draft - Expires 9/1/2000 [Page 3] Partial Non-Delivery Notification March 1, 2000 recipient can either find the appropriate rendering tool or tell the sender that she cannot read the particular attachment. This is an important issue. By definition, a MIME-enabled user agent, conforming to [7] will present or make available all of the body parts to the recipient. However, a voice mail system may not be capable of storing non-voice objects. Moreover, the voice mail system may not be capable of notifying the recipient that there were undeliverable message parts. The inability of the receiving system to render a body part is usually a permanent failure. Retransmission of the message will not improve the likelihood of a future successful delivery. Contrast this to the case with normal data delivery. Traditional message failures, such as a garbled message or disabled link will benefit from retransmission. Note that the PNDN does not attempt to address User Agent failures, such as a corruption of a body part. PNDN only addresses the capability of a system to handle the data type by observing the part's metadata. Other mechanisms, such as Message Disposition Notification [8], can address the situation when the recipient system discovers an error in the payload of a body part. This document addresses the need to allow Internet e-mail client applications to send arbitrary multi-part multimedia messages to voice messaging systems, retaining the semantics of delivery notification, while taking into account the limitations of the voice messaging system's rendering capabilities. The method described by this document is applicable to any interface between a full-featured user agent and a recipient mail transfer agent that has less rendering and media type storage capabilities than the sender has. Ideally, the voice mail system would notify the recipient of the undeliverable body parts. Such behavior would satisfy the essential requirements of [8]. In fact, if the voice mail system can notify the recipient there were undeliverable body parts, then there would be no need for this document. However, many voice mail systems are not capable of making this notification. NOTE: Another method of handling partial delivery is to determine what parts of the message the sender considers critical. If the voice mail system could not deliver the critical parts, then the voice mail system would reject the entire message. If the voice mail system could deliver the critical parts, but there were other undeliverable parts, it would silently delete the parts from the delivered message. However, currently there is no method to identify critical parts. In light of the limitations of voice mail systems, we decided to deliver as much of the message as possible, notifying the sender of any parts that the voice mail system fails to deliver. Burger Internet Draft - Expires 9/1/2000 [Page 4] Partial Non-Delivery Notification March 1, 2000 NOTE: The concept of a critical part indicator is still a useful construction. The sender may wish to specify a body part as so important that if the system cannot deliver the specified body part, then the system will not deliver any parts of the message. However, this is beyond the scope of this document. We should revisit this issue once there is an acceptable mechanism for identifying critical parts. 4. Operation The sending system sees the Internet Voice Mail system as a peer e- mail client. The only special consideration on the part of the sending system is that it may encode the MIME message following the format specified by VPIM [5] or the Internet Voice Mail Profile [4]. Properly encoding and profiling the message will enhance the receiving system's ability to process and successfully deliver the message. Such considerations include the formatting and encoding of the sender's audio name clip, return address information, out-dial destinations, and other elements. Refer to [5] for more information. The recipient system, on receipt of e-mail destined for a voice mail user, makes a best-efforts attempt to deliver what parts it can to the user. If the recipient system is capable of delivering the entire message, it follows the notification protocols specified in [4]. If the recipient system cannot deliver any part of the message, it will return the non-delivery notification specified in [4]. If the recipient system is capable of delivering only part of the message, it will return a partial non-delivery notification (PNDN) as described below. Delivery failure can occur for all recipients of a message because the recipient system cannot handle a given body part. However, body-part delivery failure can also occur for a subset of recipients of a message. This happens if the recipient system is capable of handling the media type of the body part, but the recipient user does not subscribe to a service that can present the media type. For example, consider an Internet Voice Mail platform that can handle fax. Now consider a service provider that has a class of service that is voice only. If the message recipient user has a voice only class of service, she will not be able to render fax, which is an image. NOTE: We chose Delivery Status Notification (DSN) [3] over Message Disposition Notification (MDN) [8] as a model for PNDN. There was Burger Internet Draft - Expires 9/1/2000 [Page 5] Partial Non-Delivery Notification March 1, 2000 some discussion on this point because an Internet Voice Mail system acts as both a UA and a MTA. The Message Disposition Notification deals with things such as return receipt. The generation of the return receipt can occur long after the receiving system has received the message. On the other hand, the receiving system can know on receipt whether it has the capabilities to deliver all parts of the message. In this case, the recipient acts more like an MTA than a UA. In addition, we decided it was more important for the sender to know the system would never deliver some parts of the message. It would not be desirable to wait for the recipient to attempt to read the message and only at that point generate a notification that the system could not deliver parts of the message. NOTE: This is why the language uses "is capable of delivering" rather than "delivers" in the description above. 5. Contents of the PNDN The PNDN informs a human or machine sender that the recipient system could not deliver one or more parts of a message they have sent. The PNDN is a special case of Delivery Status Notification. In the sections that follow, refer to [3] for a full description of the fields. The receiving system transmits a PNDN as a MIME message with a top- level content-type of multipart/report, as defined in [3]. The mail system can use the multipart/report content-type for any of several kinds of reports. For a PNDN, the report-type parameter uses the DSN multipart/report content-type of "delivery-status". As described in [9], the first part of a multipart/report content- type is a human readable explanation of the report. For a PNDN, the second component of the multipart/report is of content-type message/delivery-status. The third component of the multipart/report consists of the original message or some portion thereof. 5.1. The message/delivery-status content-type The message/delivery-status content-type definition is as follows: MIME type name: message MIME subtype name: delivery-status Optional parameters: none. Encoding considerations: "7bit" encoding is sufficient and Burger Internet Draft - Expires 9/1/2000 [Page 6] Partial Non-Delivery Notification March 1, 2000 conforming systems MUST use it to maintain readability when viewed by non-MIME mail readers. Security considerations: discussed in section 7 of this memo. The message/delivery-status report type for use in the multipart/report is "delivery-status". The body of a message/delivery-status consists of one or more "fields" formatted according to the ABNF [10] specified below and in [3]. The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per- recipient/per-body part fields. A blank line precedes each group of per-recipient fields. The syntax of the message/delivery-status content is in section 7. Section 5.2 describes the per-message-fields. Section 5.3 describes the per-part-fields. NOTE: Readers should focus on Section 5.3 as it describes the essential extensions to DSN. 5.2. Per-Message PNDN Fields 5.2.1. Fields from RFC 1894 Except as noted below, the PNDN contains all fields as appropriate from DSN [3]. In particular, Reporting-MTA MUST be present. NOTE: The sender's MTA could generate a DSN. In this case, the Reporting-MTA is optional. However, only receiving systems will generate Partial Non-Delivery Notifications. Thus, the sender needs to know who reported the failure. 5.2.2. Original-Message-ID The recipient system MUST generate an Original-Message-ID field if a Message-ID field was present in the original message. NOTE: This is a change from RFC 1894. Few User Agents insert an Envelope-ID. The sender needs to know what message failed. Sending back the original message in a multimedia environment has security implications. In particular, requiring the receiving system to send back large multimedia files would make them vulnerable to denial of service attacks. Moreover, MIME-encoded body parts are in base64. Since we cannot rely on the user recognizing the original text of Burger Internet Draft - Expires 9/1/2000 [Page 7] Partial Non-Delivery Notification March 1, 2000 their message, we must rely on alternative identifying characteristics. 5.3. Per-Part PNDN Fields A PNDN contains information about attempts to deliver a message's parts to one or more recipients. A group of contiguous per-message, per-recipient body-part content partial non-delivery notification fields contains delivery information for that body-part. A blank line precedes each group of per-part fields. PNDN expands upon DSN by introducing body part indicators to DSN's per-recipient block. This extension allows multiple recipients per per-recipient block and multiple body part indicators per per- recipient block. A conforming implementation may choose to separate each body-part / recipient failure into its own per-recipient block. A conforming PNDN parser MUST be able to digest each of the three reporting types. For example, take a message sent to two users, A and B. In addition, let's say that Part 1 fails for the same reason for both users, and Part 2 fails only for user B for the same reason Part 1 failed. Here are three, equivalent ways of rendering the per- recipient block. 1. Enumerate all failures individually: Recipient A Failure Part 1 Failure Recipient B Failure Part 1 Failure Recipient B Failure Part 2 Failure 2. Group by recipient: Recipient A Failure Part 1 Failure Recipient B Failure Part 1 Failure Part 2 Failure 3. Group by part: Recipient A Failure Recipient B Failure Burger Internet Draft - Expires 9/1/2000 [Page 8] Partial Non-Delivery Notification March 1, 2000 Part 1 Failure Recipient B Failure Part 2 Failure NOTE: This RFC could have required enumeration as the only way to report failures. This makes for a cleaner standard. However, consider the case of a message sent to a large number of recipients. Assuming each recipient / part combination has the same failure mode, expanding all of the redundant information, such as the part identification, for each recipient greatly increases the size of the PNDN. 5.3.1. Fields from RFC 1894 Except as noted below, the PNDN contains all fields as appropriate from DSN [3]. The Original-Recipient, Final-Recipient, Last- Attempt-Date, and Final-Log-ID fields follow their meaning and requirements set forth in DSN. The Will-Retry-Until field is not relevant, as the PNDN is not a delayed delivery notification. 5.3.2. Action Field The action field reflects the disposition of the message. Since the receiving system can deliver at least part of the message, the action value SHOULD be "delivered". If the recipient system did not deliver any parts of the message, then it would perform the normal undeliverable message processing described by DSN [3]. NOTE: Considering partial delivery a failure or a success is a matter of many debates. There is work ongoing in the IETF to develop an indicator for identifying critical body parts. With a critical body part indicator, the recipient system can return to the sender a success or failure indication based on whether or not the system succeeded in delivering the critical parts. Without critical part indicators, one may chose to err on the side of failing the entire message. However, from a practical point of view, the sender probably will have some idea of the capabilities of the recipient. Moreover, experience shows that users do not take well to being bombarded with failure notices they believe should be warnings. Therefore, until such a time as we have a critical body part indicator, the best practice is to return a delivered notice to the sender, with the appropriate warning and explanation message for the body part(s) not delivered. Burger Internet Draft - Expires 9/1/2000 [Page 9] Partial Non-Delivery Notification March 1, 2000 5.3.3. Final Recipient Field The Final-Recipient field indicates the recipient for which this set of per-part fields applies. The definition of the final recipient field is as described by DSN [3]. However, for security reasons, the PNDN relaxes the imperative for including this field. That is, the per-part data MAY include the final recipient field NOTE: The change in imperative from [3], from MUST to MAY, comes from the Internet Voice Mail environment. One can envision Internet Voice Mail implementations where the service provider wishes to keep the actual host name of the voice mail system hidden yet in the Internet name space. Reporting the final recipient field may include the actual host name of a voice mail node. Making that information public through a PNDN may enable attacks on that node. 5.3.4. Original Content ID Field The Original-Content-ID field MUST be present in the PNDN if a Content-ID field is present in the original message. This field aids the sender in understanding exactly which body part the receiving system is not capable of delivering. 5.3.5. Original Content Description Field The Original-Content-Description field MUST be present in the PNDN if a Content-Description field is present in the original message. This field aids the sender in understanding exactly which body part the receiving system is not capable of delivering. This field will be much more useful than the Original-Content-ID field to a human sender. However, few User Agents insert the Content-Description field in a message. 5.3.6. Original Content Disposition Field The Original-Content-Disposition field MAY be present in the PNDN if a Content-Disposition field is present in the original message. If the original message does not have a Content-Type field, the Original-Content-Disposition field MUST be present in the PNDN if a Content-Disposition field is present in the original message. The Original-Content-Disposition field aids the sender in understanding exactly which body part the receiving system is not capable of delivering. This field will be more useful than the Original-Content-ID field to a human sender. It will let the human know the file name of the part the receiving system is not capable of handling. Burger Internet Draft - Expires 9/1/2000 [Page 10] Partial Non-Delivery Notification March 1, 2000 5.3.7. Original Content Type Field The Original-Content-Type field MUST be present in the PNDN if a Content-Type field is present in the original message. This field aids the sender in understanding exactly which body part the receiving system is not capable of delivering. This field will be much more useful than the Original-Content-ID field to a human sender. It will let the human know the MIME types that the receiving system is not capable of handling. In addition, the sender will get a clue as to what body part the receiving system is not capable of handling from the filename sub-field, if present. 5.3.8. Status Field Message Transfer Agents (MTAs) are free to generate standard status codes from [11]. This section describes status codes that have special meaning for PNDN. All of these status codes are of type "permanent failures of media", type 5. Receiving systems that generate Partial Non-Delivery Notifications MUST insert descriptive text in the comment field of the status code so a human sender can understand why his message failed. Sending systems that automatically process returned status codes MUST use the numeric status code and MUST NOT use the comment. 5.3.8.1. Media not Supported If the recipient system is not capable of delivering a part of a message because it does not support a given media type, it MUST return the Media not Supported status code. For example, if an Internet Voice Mail system receives an AutoCAD document and it can only render voice, the Internet Voice Mail system will return a Media not Supported status code. The Media not Supported status code is 5.6.1 [11]. 5.3.8.2. Conversion With Loss Performed If the recipient system can deliver the part, but only with a lossy conversion, the receiving system SHOULD NOT return Conversion With Loss Performed. NOTE: We considered the optional return code of Conversion With Loss Performed, Status 5.6.4. However, we realized two things. First, few Internet Voice Mail systems would necessarily have the Burger Internet Draft - Expires 9/1/2000 [Page 11] Partial Non-Delivery Notification March 1, 2000 capability of generating this warning. Second, there is dubious value to the sender of receiving this warning. If the receiver has trouble understanding the rendering of the body part, she can always send a message to the sender. On the other hand, we could foresee confusion on the part of the sender if he constantly received warning messages every time he sends a message to the particular recipient. 6. Appendix - Examples NOTE: These examples are for illustrative purposes only and are not a normative part of the PNDN definition. If an example conflicts with the normative description of sections 3 through 5, the example is wrong. The examples in this appendix use the following MIME-Encoded message for the original sent message. The message has three parts. The first part is a text message. The second part is a voice message. The third part is a fax message. Here is the sample message. Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com From: "Eric Burger" To: "Eric Burger" Subject: Three-part Message Date: Mon, 22 Nov 1999 12:02:30 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01BF34E1.74123720" X-Priority: 3 X-Mailer: The One And Only Test Platform V8.1222.974B This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF34E1.74123720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-ID: TextPart0AFF8B Here is a three-part message. The first part is text (this one). The second part is voice. The third part is fax. ------=_NextPart_000_0007_01BF34E1.74123720 Burger Internet Draft - Expires 9/1/2000 [Page 12] Partial Non-Delivery Notification March 1, 2000 Content-Type: audio/wav; name="Voice Message.wav" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Voice Message.wav" UklGRjgRAABXQVZFZm10IBQAAAAxAAEAQB8AAFkGAABBAAAAAgBAAWZhY3QEAAAAwFMA EQAASfYQFoWCEkuSTST3JGyiTbIfDybr9hltilsnh+uBo/OEpE1iTFGWuFEcFJFuVAxk ... 0TIT1twS7JVeyYHHFDaWIEN1mcYMlvLNgGoakdxbL2ErxZprJS+htNhu4ozNYKmwCGvT wErbIgazEvRAGn5hMxhcqGS59UE1cHEjR08A ------=_NextPart_000_0007_01BF34E1.74123720 Content-Type: image/tiff; name="My House.tif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="My House.tif" Content-Description: Picture of My House SUkqABhSAAAAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFN AU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAGRqDuH4JefU8/YSwd8/xdn7CKC4PMW ... UAAAGgEFAAEAAAAIUgAAGwEFAAEAAAAQUgAAJAEEAAEAAAAEAAAAKAEDAAEAAAACAAAA AAAAAAEARgEDAAEAAAAAAAAARwEDAAEAAAAAAAAAAAAAAA== ------=_NextPart_000_0007_01BF34E1.74123720-- 6.1. PNDN With One Failed Body Part This example shows a PNDN for a system that does not handle text, but does handle voice and fax. Date: Thu, 22 Nov 1999 09:05:15 -0800 From: Mail Delivery Subsystem Message-Id: <199407072116.RAA14128@TELECNNCT> Subject: WARNING: Could Not Delivery Body Part To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="RAA14128.773615765/CENTIGRAM.COM" --RAA14128.773615765/CENTIGRAM.COM The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 from root@localhost ----- The following addresses had delivery problems ----- Burger Internet Draft - Expires 9/1/2000 [Page 13] Partial Non-Delivery Notification March 1, 2000 (warning) ----- Transcript of session follows ----- Could Not Deliver Text Part to < eric.burger@centigram.com > Body part will be deleted from queue --RAA14128.773615765/CENTIGRAM.COM content-type: message/delivery-status Original-Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com Reporting-MTA: dns; telecnnct.com Action: delivered Status: 5.6.1 (Media not Supported) Original-Recipient: rfc822;eric.burger@centigram.com Original-Content-ID: TextPart0AFF8B --RAA14128.773615765/CENTIGRAM.COM content-type: message/rfc822 Here is a three-part message. The first part is text (this one). The second part is voice. The third part is fax. --RAA14128.773615765/CENTIGRAM.COM-- 6.2. PNDN With Two Failed Body Parts This example shows a PNDN for a system that does not handle text or fax. Date: Thu, 22 Nov 1999 09:05:15 -0800 From: Mail Delivery Subsystem Message-Id: <199407072116.RAA14128@TELECNNCT> Subject: WARNING: Could Not Delivery Body Part To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="RAA14128.773615765/CENTIGRAM.COM" --RAA14128.773615765/CENTIGRAM.COM The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 from root@localhost ----- The following addresses had delivery problems ----- Burger Internet Draft - Expires 9/1/2000 [Page 14] Partial Non-Delivery Notification March 1, 2000 (warning) ----- Transcript of session follows ----- Could Not Deliver Text Part to < eric.burger@centigram.com > Could Not Deliver Fax Part to < eric.burger@centigram.com > Body parts will be deleted from queue --RAA14128.773615765/CENTIGRAM.COM content-type: message/delivery-status Original-Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com Reporting-MTA: dns; telecnnct.com Original-Recipient: rfc822;eric.burger@centigram.com Status: 5.6.1 (Media not Supported) Action: delivered Original-Content-ID: TextPart0AFF8B Original-Recipient: rfc822;eric.burger@centigram.com Status: 5.6.1 (Media not Supported) Action: delivered Original-Content-Description: Picture of My House Original-Content-Type: image/tiff; name="My House.tif" Original-Content-Disposition: attachment; filename="My House.tif" --RAA14128.773615765/CENTIGRAM.COM content-type: message/rfc822 Here is a three-part message. The first part is text (this one). The second part is voice. The third part is fax. --RAA14128.773615765/CENTIGRAM.COM-- 6.3. PNDN With One Body Part Failure and Two Recipients This example shows a PNDN for a system that does not handle text, but does handle voice and fax. Assume the original message was sent to and <8005551212@vm.sp.net>. Date: Thu, 22 Nov 1999 09:05:15 -0800 From: Mail Delivery Subsystem Message-Id: <199407072116.RAA14128@TELECNNCT> Subject: WARNING: Could Not Delivery Body Part To: MIME-Version: 1.0 Burger Internet Draft - Expires 9/1/2000 [Page 15] Partial Non-Delivery Notification March 1, 2000 Content-Type: multipart/report; report-type=delivery-status; boundary="RAA14128.773615765/CENTIGRAM.COM" --RAA14128.773615765/CENTIGRAM.COM The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 from root@localhost ----- The following addresses had delivery problems ----- (warning) <8005551212@vm.sp.net> (warning) ----- Transcript of session follows ----- Could Not Deliver Text Part to < eric.burger@centigram.com > Could Not Deliver Text Part to < 8005551212@vm.sp.net > Body part will be deleted from queue --RAA14128.773615765/CENTIGRAM.COM content-type: message/delivery-status Original-Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com Reporting-MTA: dns; telecnnct.com Action: delivered Status: 5.6.1 (Media not Supported) Original-Recipient: rfc822;eric.burger@centigram.com Original-Recipient: rfc822;8005551212@vm.sp.net Final-Recipient: rfc822;eburger@vmail27.sp.net Original-Content-ID: TextPart0AFF8B --RAA14128.773615765/CENTIGRAM.COM content-type: message/rfc822 Here is a three-part message. The first part is text (this one). The second part is voice. The third part is fax. --RAA14128.773615765/CENTIGRAM.CO