Tentative test to prove JSIEVE-19.
[james-jsieve.git] / src / site / resources / rfc2298.txt
1 \r
2 \r
3 \r
4 \r
5 \r
6 Network Working Group                                          R. Fajman\r
7 Request for Comments: 2298                 National Institutes of Health\r
8 Category: Standards Track                                     March 1998\r
9 \r
10 \r
11                       An Extensible Message Format\r
12                  for Message Disposition Notifications\r
13 \r
14 Status of this Memo\r
15 \r
16    This document specifies an Internet standards track protocol for the\r
17    Internet community, and requests discussion and suggestions for\r
18    improvements.  Please refer to the current edition of the "Internet\r
19    Official Protocol Standards" (STD 1) for the standardization state\r
20    and status of this protocol.  Distribution of this memo is unlimited.\r
21 \r
22 Copyright Notice\r
23 \r
24    Copyright (C) The Internet Society (1998).  All Rights Reserved.\r
25 \r
26 Abstract\r
27 \r
28    This memo defines a MIME content-type that may be used by a mail user\r
29    agent (UA) or electronic mail gateway to report the disposition of a\r
30    message after it has been sucessfully delivered to a recipient.  This\r
31    content-type is intended to be machine-processable.  Additional\r
32    message headers are also defined to permit Message Disposition\r
33    Notifications (MDNs) to be requested by the sender of a message.  The\r
34    purpose is to extend Internet Mail to support functionality often\r
35    found in other messaging systems, such as X.400 and the proprietary\r
36    "LAN-based" systems, and often referred to as "read receipts,"\r
37    "acknowledgements," or "receipt notifications."  The intention is to\r
38    do this while respecting the privacy concerns that have often been\r
39    expressed when such functions have been discussed in the past.\r
40 \r
41    Because many messages are sent between the Internet and other\r
42    messaging systems (such as X.400 or the proprietary "LAN-based"\r
43    systems), the MDN protocol is designed to be useful in a multi-\r
44    protocol messaging environment.  To this end, the protocol described\r
45    in this memo provides for the carriage of "foreign" addresses, in\r
46    addition to those normally used in Internet Mail.  Additional\r
47    attributes may also be defined to support "tunneling" of foreign\r
48    notifications through Internet Mail.\r
49 \r
50 \r
51 \r
52 \r
53 \r
54 \r
55 \r
56 \r
57 Fajman                      Standards Track                     [Page 1]\r
58 \f\r
59 RFC 2298           Message Disposition Notifications          March 1998\r
60 \r
61 \r
62 Table of Contents\r
63 \r
64    1.   Introduction ............................................  2\r
65    2.   Requesting Message Disposition Notifications ............  3\r
66    3.   Format of a Message Disposition Notification ............  7\r
67    4.   Timeline of events ...................................... 17\r
68    5.   Conformance and Usage Requirements ...................... 18\r
69    6.   Security Considerations ................................. 19\r
70    7.   Collected Grammar ....................................... 20\r
71    8.   Guidelines for Gatewaying MDNs .......................... 22\r
72    9.   Example ................................................. 24\r
73    10.  IANA Registration Forms ................................. 25\r
74    11.  Acknowledgments ......................................... 26\r
75    12.  References .............................................. 26\r
76    13.  Author's Address ........................................ 27\r
77    14.  Copyright ............................................... 28\r
78 \r
79 1.  Introduction\r
80 \r
81    This memo defines a MIME content-type [5] for message disposition\r
82    notifications (MDNs).  An MDN can be used to notify the sender of a\r
83    message of any of several conditions that may occur after successful\r
84    delivery, such as display of the message contents, printing of the\r
85    message, deletion (without display) of the message, or the\r
86    recipient's refusal to provide MDNs.  The "message/disposition-\r
87    notification" content-type defined herein is intended for use within\r
88    the framework of the "multipart/report" content type defined in RFC\r
89    1892 [7].\r
90 \r
91    This memo defines the format of the notifications and the RFC 822\r
92    headers used to request them.\r
93 \r
94    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
95    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
96    document are to be interpreted as described in RFC 2119.\r
97 \r
98 1.1 Purposes\r
99 \r
100    The MDNs defined in this memo are expected to serve several purposes:\r
101 \r
102    (a)  Inform human beings of the disposition of messages after\r
103         succcessful delivery, in a manner which is largely independent\r
104         of human language;\r
105 \r
106    (b)  Allow mail user agents to keep track of the disposition of\r
107         messages sent, by associating returned MDNs with earlier message\r
108         transmissions;\r
109 \r
110 \r
111 \r
112 \r
113 Fajman                      Standards Track                     [Page 2]\r
114 \f\r
115 RFC 2298           Message Disposition Notifications          March 1998\r
116 \r
117 \r
118    (c)  Convey disposition notification requests and disposition\r
119         notifications between Internet Mail and "foreign" mail systems\r
120         via a gateway;\r
121 \r
122    (d)  Allow "foreign" notifications to be tunneled through a MIME-\r
123         capable message system and back into the original messaging\r
124         system that issued the original notification, or even to a third\r
125         messaging system;\r
126 \r
127    (e)  Allow language-independent, yet reasonably precise, indications\r
128         of the disposition of a message to be delivered.\r
129 \r
130 1.2 Requirements\r
131 \r
132    These purposes place the following constraints on the notification\r
133    protocol:\r
134 \r
135    (a)  It must be readable by humans, as well as being machine-\r
136         parsable.\r
137 \r
138    (b)  It must provide enough information to allow message senders (or\r
139         their user agents) to unambiguously associate an MDN with the\r
140         message that was sent and the original recipient address for\r
141         which the MDN is issued (if such information is available), even\r
142         if the message was forwarded to another recipient address.\r
143 \r
144    (c)  It must also be able to describe the disposition of a message\r
145         independent of any particular human language or of the\r
146         terminology of any particular mail system.\r
147 \r
148    (d)  The specification must be extensible in order to accomodate\r
149         future requirements.\r
150 \r
151 2.  Requesting Message Disposition Notifications\r
152 \r
153    Message disposition notifications are requested by including a\r
154    Disposition-Notification-To header in the message.  Further\r
155    information to be used by the recipient's UA in generating the MDN\r
156    may be provided by including Original-Recipient and/or Disposition-\r
157    Notification-Options headers in the message.\r
158 \r
159 2.1 The Disposition-Notification-To Header\r
160 \r
161    A request that the receiving user agent issue message disposition\r
162    notifications is made by placing a Disposition-Notification-To header\r
163    into the message.  The syntax of the header, using the ABNF of RFC\r
164    822 [2], is\r
165 \r
166 \r
167 \r
168 \r
169 Fajman                      Standards Track                     [Page 3]\r
170 \f\r
171 RFC 2298           Message Disposition Notifications          March 1998\r
172 \r
173 \r
174      mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox\r
175 \r
176    The mailbox token is as specified in RFC 822 [2].\r
177 \r
178    The presence of a Disposition-Notification-To header in a message is\r
179    merely a request for an MDN.  The recipients' user agents are always\r
180    free to silently ignore such a request.  Alternatively, an explicit\r
181    denial of the request for information about the disposition of the\r
182    message may be sent using the "denied" disposition in an MDN.\r
183 \r
184    An MDN MUST NOT itself have a Disposition-Notification-To header.\r
185    An MDN MUST NOT be generated in response to an MDN.\r
186 \r
187    At most one MDN may be issued on behalf of each particular recipient\r
188    by their user agent.  That is, once an MDN has been issued on behalf\r
189    of a recipient, no further MDNs may be issued on behalf of that\r
190    recipient, even if another disposition is performed on the message.\r
191    However, if a message is forwarded, an MDN may been issued for the\r
192    recipient doing the forwarding and the recipient of the forwarded\r
193    message may also cause an MDN to be generated.\r
194 \r
195    While Internet standards normally do not specify the behavior of user\r
196    interfaces, it is strongly recommended that the user agent obtain the\r
197    user's consent before sending an MDN.  This consent could be obtained\r
198    for each message through some sort of prompt or dialog box, or\r
199    globally through the user's setting of a preference.  The user might\r
200    also indicate globally that MDNs are never to be sent or that a\r
201    "denied" MDN is always sent in response to a request for an MDN.\r
202 \r
203    MDNs SHOULD NOT be sent automatically if the address in the\r
204    Disposition-Notification-To header differs from the address in the\r
205    Return-Path header (see RFC 822 [2]).  In this case, confirmation\r
206    from the user SHOULD be obtained, if possible.  If obtaining consent\r
207    is not possible (e.g., because the user is not online at the time),\r
208    then an MDN SHOULD NOT be sent.\r
209 \r
210    Confirmation from the user SHOULD be obtained (or no MDN sent) if\r
211    there is no Return-Path header in the message, or if there is more\r
212    than one distinct address in the Disposition-Notification-To header.\r
213 \r
214    The comparison of the addresses should be done using only the addr-\r
215    spec (local-part "@" domain) portion, excluding any phrase and route.\r
216    The comparison MUST be case-sensitive for the local-part and case-\r
217    insensitive for the domain part.\r
218 \r
219    If the message contains more than one Return-Path header, the\r
220    implementation may pick one to use for the comparison, or treat the\r
221    situation as a failure of the comparison.\r
222 \r
223 \r
224 \r
225 Fajman                      Standards Track                     [Page 4]\r
226 \f\r
227 RFC 2298           Message Disposition Notifications          March 1998\r
228 \r
229 \r
230    The reason for not automatically sending an MDN if the comparison\r
231    fails or more than one address is specified is to reduce the\r
232    possibilities for mail loops and use of MDNs for mail bombing.\r
233 \r
234    A message that contains a Disposition-Notification-To header SHOULD\r
235    also contain a Message-ID header as specified in RFC 822 [2].  This\r
236    will permit automatic correlation of MDNs with original messages by\r
237    user agents.\r
238 \r
239    If it is desired to request message disposition notifications for\r
240    some recipients and not others, two copies of the message should be\r
241    sent, one with an Disposition-Notification-To header and one without.\r
242    Many of the other headers of the message (e.g., To, cc) will be the\r
243    same in both copies.  The recipients in the respective message\r
244    envelopes determine for whom message disposition notifications are\r
245    requested and for whom they are not.  If desired, the Message-ID\r
246    header may be the same in both copies of the message.  Note that\r
247    there are other situations (e.g., bcc) in which it is necessary to\r
248    send multiple copies of a message with slightly different headers.\r
249    The combination of such situations and the need to request MDNs for a\r
250    subset of all recipients may result in more than two copies of a\r
251    message being sent, some with a Disposition- Notification-To header\r
252    and some without.\r
253 \r
254    Messages posted to newsgroups SHOULD NOT have a Disposition-\r
255    Notification-To header.\r
256 \r
257 2.2 The Disposition-Notification-Options Header\r
258 \r
259    Future extensions to this specification may require that information\r
260    be supplied to the recipient's UA for additional control over how and\r
261    what MDNs are generated.  The Disposition-Notification-Options header\r
262    provides an extensible mechanism for such information.  The syntax of\r
263    this header, using the ABNF of RFC 822 [2], is\r
264 \r
265      Disposition-Notification-Options =\r
266           "Disposition-Notification-Options" ":"\r
267           disposition-notification-parameters\r
268 \r
269      disposition-notification-parameters = parameter *(";" parameter)\r
270 \r
271      parameter = attribute "=" importance "," 1#value\r
272 \r
273      importance = "required" / "optional"\r
274 \r
275    The definitions of attribute and value are as in the definition of\r
276    the Content-Type header in RFC 2045 [4].\r
277 \r
278 \r
279 \r
280 \r
281 Fajman                      Standards Track                     [Page 5]\r
282 \f\r
283 RFC 2298           Message Disposition Notifications          March 1998\r
284 \r
285 \r
286    An importance of "required" indicates that interpretation of the\r
287    parameter is necessary for proper generation of an MDN in response to\r
288    this request.  If a UA does not understand the meaning of the\r
289    parameter, it MUST NOT generate an MDN with any disposition type\r
290    other than "failed" in response to the request.  An importance of\r
291    "optional" indicates that a UA that does not understand the meaning\r
292    of this parameter MAY generate an MDN in response anyway, ignoring\r
293    the value of the parameter.\r
294 \r
295    No parameters are defined in this specification.  Parameters may be\r
296    defined in the future by later revisions or extensions to this\r
297    specification.  Parameter attribute names beginning with "X-" will\r
298    never be defined as standard names; such names are reserved for\r
299    experimental use.  MDN parameter names not beginning with "X-" MUST\r
300    be registered with the Internet Assigned Numbers Authority (IANA) and\r
301    described in a standards-track RFC or an experimental RFC approved by\r
302    the IESG.  See Section 10 for a registration form.\r
303 \r
304    If a required parameter is not understood or contains some sort of\r
305    error, the receiving UA SHOULD issue an MDN with a disposition type\r
306    of "failed" (see Section 3.2.6) and include a Failure field (see\r
307    Section 3.2.7) that further describes the problem.  MDNs with the a\r
308    disposition type of "failed" and a "Failure" field MAY also be\r
309    generated when other types of errors are detected in the parameters\r
310    of the Disposition-Notification-Options header.\r
311 \r
312    However, an MDN with a disposition type of "failed" MUST NOT be\r
313    generated if the user has indicated a preferance that MDNs are not to\r
314    be sent.  If user consent would be required for an MDN of some other\r
315    disposition type to be sent, user consent SHOULD also be obtained\r
316    before sending an MDN with a disposition type of "failed".\r
317 \r
318 2.3 The Original-Recipient Header\r
319 \r
320    Since electronic mail addresses may be rewritten while the message is\r
321    in transit, it is useful for the original recipient address to be\r
322    made available by the delivering MTA.  The delivering MTA may be able\r
323    to obtain this information from the ORCPT parameter of the SMTP RCPT\r
324    TO command, as defined in RFC 1891 [8].  If this information is\r
325    available, the delivering MTA SHOULD insert an Original-Recipient\r
326    header at the beginning of the message (along with the Return-Path\r
327    header).  The delivering MTA MAY delete any other Original-Recipient\r
328    headers that occur in the message.  The syntax of this header, using\r
329    the ABNF of RFC 822 [2], is as follows\r
330 \r
331      original-recipient-header =\r
332           "Original-Recipient" ":" address-type ";" generic-address\r
333 \r
334 \r
335 \r
336 \r
337 Fajman                      Standards Track                     [Page 6]\r
338 \f\r
339 RFC 2298           Message Disposition Notifications          March 1998\r
340 \r
341 \r
342    The address-type and generic-address token are as as specified in the\r
343    description of the Original-Recipient field in section 3.2.3.\r
344 \r
345    The purpose of carrying the original recipient information and\r
346    returning it in the MDN is to permit automatic correlation of MDNs\r
347    with the original message on a per-recipient basis.\r
348 \r
349 2.4 Use with the Message/Partial Content Type\r
350 \r
351    The use of the headers Disposition-Notification-To, Disposition-\r
352    Notification-Options, and Original-Recipient with the MIME\r
353    Message/partial content type (RFC 2046 [5]) requires further\r
354    definition.\r
355 \r
356    When a message is segmented into two or more message/partial\r
357    fragments, the three headers mentioned in the above paragraph SHOULD\r
358    be placed in the "inner" or "enclosed" message (using the terms of\r
359    RFC 2046 [5]).  These headers SHOULD NOT be used in the headers of\r
360    any of the fragments themselves.\r
361 \r
362    When the multiple message/partial fragments are reassembled, the\r
363    following applies.  If these headers occur along with the other\r
364    headers of a message/partial fragment message, they pertain to an MDN\r
365    to be generated for the fragment.  If these headers occur in the\r
366    headers of the "inner" or "enclosed" message (using the terms of RFC\r
367    2046 [5]), they pertain to an MDN to be generated for the reassembled\r
368    message.  Section 5.2.2.1 of RFC 2046 [5]) is amended to specify\r
369    that, in addition to the headers specified there, the three headers\r
370    described in this specification are to be appended, in order, to the\r
371    headers of the reassembled message.  Any occurances of the three\r
372    headers defined here in the headers of the initial enclosing message\r
373    must not be copied to the reassembled message.\r
374 \r
375 3.  Format of a Message Disposition Notification\r
376 \r
377    A message disposition notification is a MIME message with a top-\r
378    level content-type of multipart/report (defined in RFC 1892 [7]).\r
379    When a multipart/report content is used to transmit an MDN:\r
380 \r
381    (a)  The report-type parameter of the multipart/report content is\r
382         "disposition-notification".\r
383 \r
384    (b)  The first component of the multipart/report contains a human-\r
385         readable explanation of the MDN, as described in RFC 1892 [7].\r
386 \r
387    (c)  The second component of the multipart/report is of content-type\r
388         message/disposition-notification, described in section 3.1 of\r
389         this document.\r
390 \r
391 \r
392 \r
393 Fajman                      Standards Track                     [Page 7]\r
394 \f\r
395 RFC 2298           Message Disposition Notifications          March 1998\r
396 \r
397 \r
398    (d)  If the original message or a portion of the message is to be\r
399         returned to the sender, it appears as the third component of the\r
400         multipart/report.  The decision of whether or not to return the\r
401         message or part of the message is up to the UA generating the\r
402         MDN.  However, in the case of encrypted messages requesting\r
403         MDNs, encrypted message text MUST be returned, if it is returned\r
404         at all, only in its original encrypted form.\r
405 \r
406         NOTE:  For message dispostion notifications gatewayed from\r
407         foreign systems, the headers of the original message may not be\r
408         available.  In this case the third component of the MDN may be\r
409         omitted, or it may contain "simulated" RFC 822 headers which\r
410         contain equivalent information.  In particular, it is very\r
411         desirable to preserve the subject and date fields from the\r
412         original message.\r
413 \r
414    The MDN MUST be addressed (in both the message header and the\r
415    transport envelope) to the address(es) from the Disposition-\r
416    Notification-To header from the original message for which the MDN is\r
417    being generated.\r
418 \r
419    The From field of the message header of the MDN MUST contain the\r
420    address of the person for whom the message disposition notification\r
421    is being issued.\r
422 \r
423    The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be\r
424    null (<>), specifying that no Delivery Status Notification messages\r
425    or other messages indicating successful or unsuccessful delivery are\r
426    to be sent in response to an MDN.\r
427 \r
428    A message disposition notification MUST NOT itself request an MDN.\r
429    That is, it MUST NOT contain a Disposition-Notification-To header.\r
430 \r
431    The Message-ID header (if present) for an MDN MUST be different from\r
432    the Message-ID of the message for which the MDN is being issued.\r
433 \r
434    A particular MDN describes the disposition of exactly one message for\r
435    exactly one recipient.  Multiple MDNs may be generated as a result of\r
436    one message submission, one per recipient.  However, due to the\r
437    circumstances described in Section 2.1, MDNs may not be generated for\r
438    some recipients for which MDNs were requested.\r
439 \r
440 3.1 The message/disposition-notification content-type\r
441 \r
442    The message/disposition-notification content-type is defined as\r
443    follows:\r
444 \r
445      MIME type name:                message\r
446 \r
447 \r
448 \r
449 Fajman                      Standards Track                     [Page 8]\r
450 \f\r
451 RFC 2298           Message Disposition Notifications          March 1998\r
452 \r
453 \r
454      MIME subtype name:             disposition-notification\r
455      Optional parameters:           none\r
456      Encoding considerations:       "7bit" encoding is sufficient and\r
457                                     MUST be used to maintain readability\r
458                                     when viewed by non-MIME mail\r
459                                     readers.\r
460      Security considerations:       discussed in section 6 of this memo.\r
461 \r
462    The message/disposition-notification report type for use in the\r
463    multipart/report is "disposition-notification".\r
464 \r
465    The body of a message/disposition-notification consists of one or\r
466    more "fields" formatted according to the ABNF of RFC 822 header\r
467    "fields" (see [2]).  Using the ABNF of RFC 822, the syntax of the\r
468    message/disposition-notification content is as follows:\r
469 \r
470      disposition-notification-content = [ reporting-ua-field CRLF ]\r
471           [ mdn-gateway-field CRLF ]\r
472           [ original-recipient-field CRLF ]\r
473           final-recipient-field CRLF\r
474           [ original-message-id-field CRLF ]\r
475           disposition-field CRLF\r
476           *( failure-field CRLF )\r
477           *( error-field CRLF )\r
478           *( warning-field CRLF )\r
479           *( extension-field CRLF )\r
480 \r
481 3.1.1 General conventions for fields\r
482 \r
483    Since these fields are defined according to the rules of RFC 822 [2],\r
484    the same conventions for continuation lines and comments apply.\r
485    Notification fields may be continued onto multiple lines by beginning\r
486    each additional line with a SPACE or HTAB.  Text which appears in\r
487    parentheses is considered a comment and not part of the contents of\r
488    that notification field.  Field names are case-insensitive, so the\r
489    names of notification fields may be spelled in any combination of\r
490    upper and lower case letters.  Comments in notification fields may\r
491    use the "encoded-word" construct defined in RFC 2047 [6].\r
492 \r
493 3.1.2 "*-type" subfields\r
494 \r
495    Several fields consist of a "-type" subfield, followed by a semi-\r
496    colon, followed by "*text".  For these fields, the keyword used in\r
497    the address-type or MTA-type subfield indicates the expected format\r
498    of the address or MTA-name that follows.\r
499 \r
500    The "-type" subfields are defined as follows:\r
501 \r
502 \r
503 \r
504 \r
505 Fajman                      Standards Track                     [Page 9]\r
506 \f\r
507 RFC 2298           Message Disposition Notifications          March 1998\r
508 \r
509 \r
510    (a)  An "address-type" specifies the format of a mailbox address.\r
511         For example, Internet Mail addresses use the "rfc822" address-\r
512         type.\r
513 \r
514          address-type = atom\r
515 \r
516    (b)  An "MTA-name-type" specifies the format of a mail transfer\r
517         agent name.  For example, for an SMTP server on an Internet\r
518         host, the MTA name is the domain name of that host, and the\r
519         "dns" MTA-name-type is used.\r
520 \r
521          mta-name-type = atom\r
522 \r
523    Values for address-type and mta-name-type are case-insensitive.  Thus\r
524    address-type values of "RFC822" and "rfc822" are equivalent.\r
525 \r
526    The Internet Assigned Numbers Authority (IANA) will maintain a\r
527    registry of address-type and mta-name-type values, along with\r
528    descriptions of the meanings of each, or a reference to a one or more\r
529    specifications that provide such descriptions.  (The "rfc822"\r
530    address-type is defined in RFC 1891 [8].) Registration forms for\r
531    address-type and mta-name-type appear in RFC 1894 [9].\r
532 \r
533    IANA will not accept registrations for any address-type name that\r
534    begins with "X-".  These type names are reserved for experimental\r
535    use.\r
536 \r
537 3.1.3 Lexical tokens imported from RFC 822\r
538 \r
539    The following lexical tokens, defined in RFC 822 [2], are used in the\r
540    ABNF grammar for MDNs:  atom, CRLF, mailbox, msg-id, text.\r
541 \r
542 3.2 Message/disposition-notification Fields\r
543 \r
544 3.2.1 The Reporting-UA field\r
545 \r
546      reporting-ua-field = "Reporting-UA" ":" ua-name\r
547                           [ ";" ua-product ]\r
548 \r
549      ua-name = *text\r
550 \r
551      ua-product = *text\r
552 \r
553    The Reporting-UA field is defined as follows:\r
554 \r
555    A MDN describes the disposition of a message after it has been\r
556    delivered to a recipient.  In all cases, the Reporting-UA is the UA\r
557    that performed the disposition described in the MDN.  This field is\r
558 \r
559 \r
560 \r
561 Fajman                      Standards Track                    [Page 10]\r
562 \f\r
563 RFC 2298           Message Disposition Notifications          March 1998\r
564 \r
565 \r
566    optional, but recommended.  For Internet Mail user agents, it is\r
567    recommended that this field contain both the DNS name of the\r
568    particular instance of the UA that generated the MDN and the name of\r
569    the product.  For example,\r
570 \r
571      Reporting-UA:  rogers-mac.dcrt.nih.gov; Foomail 97.1\r
572 \r
573    If the reporting UA consists of more than one component (e.g., a base\r
574    program and plug-ins), this may be indicated by including a list of\r
575    product names.\r
576 \r
577 3.2.2 The MDN-Gateway field\r
578 \r
579    The MDN-Gateway field indicates the name of the gateway or MTA that\r
580    translated a foreign (non-Internet) message disposition notification\r
581    into this MDN.  This field MUST appear in any MDN which was\r
582    translated by a gateway from a foreign system into MDN format, and\r
583    MUST NOT appear otherwise.\r
584 \r
585         mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name\r
586 \r
587         mta-name = *text\r
588 \r
589    For gateways into Internet Mail, the MTA-name-type will normally be\r
590    "smtp", and the mta-name will be the Internet domain name of the\r
591    gateway.\r
592 \r
593 3.2.3 Original-Recipient field\r
594 \r
595    The Original-Recipient field indicates the original recipient address\r
596    as specified by the sender of the message for which the MDN is being\r
597    issued.  For Internet Mail messages the value of the\r
598 \r
599    Original-Recipient field is obtained from the Original-Recipient\r
600    header from the message for which the MDN is being generated.  If\r
601    there is no Original-Recipient header in the message, then the\r
602    Original-Recipient field MUST be omitted, unless the same information\r
603    is reliably available some other way.  If there is an Original-\r
604    Recipient header in the original message (or original recipient\r
605    information is reliably available some other way), then the\r
606    Original-Recipient field must be supplied.  If there is more than one\r
607    Original-Recipient header in the message, the UA may choose the one\r
608    to use or act as if no Original-Recipient header is present.\r
609 \r
610      original-recipient-field =\r
611           "Original-Recipient" ":" address-type ";" generic-address\r
612 \r
613      generic-address = *text\r
614 \r
615 \r
616 \r
617 Fajman                      Standards Track                    [Page 11]\r
618 \f\r
619 RFC 2298           Message Disposition Notifications          March 1998\r
620 \r
621 \r
622    The address-type field indicates the type of the original recipient\r
623    address.  If the message originated within the Internet, the\r
624    address-type field field will normally be "rfc822", and the address\r
625    will be according to the syntax specified in RFC 822 [2].  The value\r
626    "unknown" should be used if the Reporting UA cannot determine the\r
627    type of the original recipient address from the message envelope.\r
628    This address is the same as that provided by the sender and can be\r
629    used to automatically correlate MDN reports with original messages on\r
630    a per recipient basis.\r
631 \r
632 3.2.4 Final-Recipient field\r
633 \r
634    The Final-Recipient field indicates the recipient for which the MDN\r
635    is being issued.  This field MUST be present.\r
636 \r
637    The syntax of the field is as follows:\r
638 \r
639      final-recipient-field =\r
640           "Final-Recipient" ":" address-type ";" generic-address\r
641 \r
642    The generic-address subfield of the Final-Recipient field MUST\r
643    contain the mailbox address of the recipient (from the From header of\r
644    the MDN) as it was when the MDN was generated by the UA.\r
645 \r
646    The Final-Recipient address may differ from the address originally\r
647    provided by the sender, because it may have been transformed during\r
648    forwarding and gatewaying into an totally unrecognizable mess.\r
649    However, in the absence of the optional Original-Recipient field, the\r
650    Final-Recipient field and any returned content may be the only\r
651    information available with which to correlate the MDN with a\r
652    particular message recipient.\r
653 \r
654    The address-type subfield indicates the type of address expected by\r
655    the reporting MTA in that context.  Recipient addresses obtained via\r
656    SMTP will normally be of address-type "rfc822".\r
657 \r
658    Since mailbox addresses (including those used in the Internet) may be\r
659    case sensitive, the case of alphabetic characters in the address MUST\r
660    be preserved.\r
661 \r
662 3.2.5 Original-Message-ID field\r
663 \r
664    The Original-Message-ID field indicates the message-ID of the message\r
665    for which the MDN is being issued.  It is obtained from the Message-\r
666    ID header of the message for which the MDN is issued.  This field\r
667    MUST be present if the original message contained a Message-ID\r
668    header.  The syntax of the field is\r
669 \r
670 \r
671 \r
672 \r
673 Fajman                      Standards Track                    [Page 12]\r
674 \f\r
675 RFC 2298           Message Disposition Notifications          March 1998\r
676 \r
677 \r
678         original-message-id-field = "Original-Message-ID" ":" msg-id\r
679 \r
680    The msg-id token is as specified in RFC 822 [2].\r
681 \r
682 3.2.6 Disposition field\r
683 \r
684    The Disposition field indicates the action performed by the\r
685    Reporting-UA on behalf of the user.  This field MUST be present.\r
686 \r
687    The syntax for the Disposition field is:\r
688 \r
689      disposition-field = "Disposition" ":" disposition-mode ";"\r
690                          disposition-type\r
691                          [ '/' disposition-modifier\r
692                            *( "," dispostion-modifier ) ]\r
693 \r
694      disposition-mode = action-mode "/" sending-mode\r
695 \r
696      action-mode = "manual-action" / "automatic-action"\r
697 \r
698      sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"\r
699 \r
700      disposition-type = "displayed"\r
701                       / "dispatched"\r
702                       / "processed"\r
703                       / "deleted"\r
704                       / "denied"\r
705                       / "failed"\r
706 \r
707      disposition-modifier = ( "error" / "warning" )\r
708                           / ( "superseded" / "expired" /\r
709                               "mailbox-terminated" )\r
710                           / disposition-modifier-extension\r
711 \r
712      disposition-modifier-extension = atom\r
713 \r
714    The disposition-mode, disposition-type and disposition-modifier may\r
715    be spelled in any combination of upper and lower case characters.\r
716 \r
717 3.2.6.1 Disposition modes\r
718 \r
719    The following disposition modes are defined:\r
720 \r
721    "manual-action"            The disposition described by the\r
722                               disposition type was a result of an\r
723                               explicit instruction by the user rather\r
724                               than some sort of automatically performed\r
725                               action.\r
726 \r
727 \r
728 \r
729 Fajman                      Standards Track                    [Page 13]\r
730 \f\r
731 RFC 2298           Message Disposition Notifications          March 1998\r
732 \r
733 \r
734    "automatic-action"         The disposition described by the\r
735                               disposition type was a result of an\r
736                               automatic action, rather than an explicit\r
737                               instruction by the user for this message.\r
738 \r
739                               "Manual-action" and "automatic-action" are\r
740                               mutually exclusive.  One or the other must\r
741                               be specified.\r
742 \r
743    "MDN-sent-manually"        The user explicity gave permission for\r
744                               this particular MDN to be sent.\r
745 \r
746    "MDN-sent-automatically"   The MDN was sent because the UA had\r
747                               previously been configured to do so\r
748                               automatically.\r
749 \r
750                               "MDN-sent-manually" and "MDN-sent-\r
751                               automatically" are mutually exclusive.\r
752                               One or the other must be specified.\r
753 \r
754 3.2.6.2 Disposition types\r
755 \r
756    The following disposition-types are defined:\r
757 \r
758    "displayed"    The message has been displayed by the UA to someone\r
759                               reading the recipient's mailbox.  There is\r
760                               no guarantee that the content has been\r
761                               read or understood.\r
762 \r
763 \r
764    "dispatched"   The message has been sent somewhere in some manner\r
765                               (e.g., printed, faxed, forwarded) without\r
766                               necessarily having been previously\r
767                               displayed to the user.  The user may or\r
768                               may not see the message later.\r
769 \r
770    "processed"    The message has been processed in some manner (i.e.,\r
771                               by some sort of rules or server) without\r
772                               being displayed to the user.  The user may\r
773                               or may not see the message later, or there\r
774                               may not even be a human user associated\r
775                               with the mailbox.\r
776 \r
777    "deleted"      The message has been deleted.  The recipient may or\r
778                               may not have seen the message.  The\r
779                               recipient might "undelete" the message at\r
780                               a later time and read the message.\r
781 \r
782 \r
783 \r
784 \r
785 Fajman                      Standards Track                    [Page 14]\r
786 \f\r
787 RFC 2298           Message Disposition Notifications          March 1998\r
788 \r
789 \r
790    "denied"       The recipient does not wish the sender to be informed\r
791                               of the message's disposition.  A UA may\r
792                               also siliently ignore message disposition\r
793                               requests in this situation.\r
794 \r
795    "failed"       A failure occurred that prevented the proper\r
796                               generation of an MDN.  More information\r
797                               about the cause of the failure may be\r
798                               contained in a Failure field.  The\r
799                               "failed" disposition type is not to be\r
800                               used for the situation in which there is\r
801                               is some problem in processing the message\r
802                               other than interpreting the request for an\r
803                               MDN.  The "processed" or other disposition\r
804                               type with appropriate disposition\r
805                               modifiers is to be used in such\r
806                               situations.\r
807 \r
808 3.2.6.3 Disposition modifiers\r
809 \r
810    The following disposition modifiers are defined:\r
811 \r
812    "error"                            An error of some sort occurred\r
813                                       that prevented successful\r
814                                       processing of the message.\r
815                                       Further information is contained\r
816                                       in an Error field.\r
817 \r
818    "warning"                          The message was successfully\r
819                                       processed but some sort of\r
820                                       exceptional condition occurred.\r
821                                       Further information is contained\r
822                                       in a Warning field.\r
823 \r
824    "superseded"                       The message has been\r
825                                       automatically rendered obsolete by\r
826                                       another message received.  The\r
827                                       recipient may still access and\r
828                                       read the message later.\r
829 \r
830    "expired"                          The message has reached its\r
831                                       expiration date and has been\r
832                                       automatically removed from the\r
833                                       recipient's mailbox.\r
834 \r
835    "mailbox-terminated"               The recipient's mailbox has been\r
836                                       terminated and all message in it\r
837                                       automatically removed.\r
838 \r
839 \r
840 \r
841 Fajman                      Standards Track                    [Page 15]\r
842 \f\r
843 RFC 2298           Message Disposition Notifications          March 1998\r
844 \r
845 \r
846                                       "Obsoleted", "expired", and\r
847                                       "terminated" are to be used with\r
848                                       the "deleted" disposition type and\r
849                                       the "autoaction" and "autosent"\r
850                                       disposition modifiers.\r
851 \r
852    disposition-modifier-extension     Additional disposition modifiers\r
853                                       may be defined in the future by\r
854                                       later revisions or extensions to\r
855                                       this specification.  Disposition\r
856                                       value names beginning with "X-"\r
857                                       will never be defined as standard\r
858                                       values; such names are reserved\r
859                                       for experimental use.  MDN\r
860                                       disposition value names NOT\r
861                                       beginning with "X-" MUST be\r
862                                       registered with the Internet\r
863                                       Assigned Numbers Authority (IANA)\r
864                                       and described in a standards-\r
865                                       track RFC or an experimental RFC\r
866                                       approved by the IESG.  See Section\r
867                                       10 for a registration form.  MDNs\r
868                                       with disposition modifier names\r
869                                       not understood by the receiving UA\r
870                                       MAY be silently ignored or placed\r
871                                       in the user's mailbox without\r
872                                       special inter- pretation.  They\r
873                                       MUST not cause any error message\r
874                                       to be sent to the sender of the\r
875                                       MDN.\r
876 \r
877                                       If an UA developer does not wish\r
878                                       to register the meanings of such\r
879                                       disposition modifier extensions,\r
880                                       "X-" modifiers may be used for\r
881                                       this purpose.  To avoid name\r
882                                       collisions, the name of the UA\r
883                                       implementation should follow the\r
884                                       "X-", (e.g. "X-Foomail-fratzed").\r
885 \r
886    It is not required that a UA be able to generate all of the possible\r
887    values of the Disposition field.\r
888 \r
889    One and only one MDN may be issued on behalf of each particular\r
890    recipient by their user agent.  That is, once an MDN has been issued\r
891    on behalf of a recipient, no further MDNs may be issued on behalf of\r
892    that recipient, even if another disposition is performed on the\r
893    message.  However, if a message is forwarded, a "dispatched" MDN may\r
894 \r
895 \r
896 \r
897 Fajman                      Standards Track                    [Page 16]\r
898 \f\r
899 RFC 2298           Message Disposition Notifications          March 1998\r
900 \r
901 \r
902    been issued for the recipient doing the forwarding and the recipient\r
903    of the forwarded message may also cause an MDN to be generated.\r
904 \r
905 3.2.7 Failure, Error and Warning fields\r
906 \r
907    The Failure, Error and Warning fields are used to supply additional\r
908    information in the form of text messages when the "failure"\r
909    disposition type, "error" disposition modifier, and/or the "warning"\r
910    disposition modifer appear.  The syntax is\r
911 \r
912      failure-field = "Failure" ":" *text\r
913 \r
914      error-field = "Error" ":" *text\r
915 \r
916      warning-field = "Warning" ":" *text\r
917 \r
918 3.3 Extension fields\r
919 \r
920    Additional MDN fields may be defined in the future by later revisions\r
921    or extensions to this specification.  Extension-field names beginning\r
922    with "X-" will never be defined as standard fields; such names are\r
923    reserved for experimental use.  MDN field names NOT beginning with\r
924    "X-" MUST be registered with the Internet Assigned Numbers Authority\r
925    (IANA) and described in a standards-track RFC or an experimental RFC\r
926    approved by the IESG.  See Section 10 for a registration form.\r
927 \r
928    Extension MDN fields may be defined for the following reasons:\r
929 \r
930    (a)  To allow additional information from foreign disposition\r
931         reports to be tunneled through Internet MDNs.  The names of such\r
932         MDN fields should begin with an indication of the foreign\r
933         environment name (e.g. X400-Physical-Forwarding-Address).\r
934 \r
935    (b)  To allow transmission of diagnostic information which is\r
936         specific to a particular user agent (UA).  The names of such MDN\r
937         fields should begin with an indication of the UA implementation\r
938         which produced the MDN.  (e.g. Foomail-information).\r
939 \r
940    If an application developer does not wish to register the meanings of\r
941    such extension fields, "X-" fields may be used for this purpose.  To\r
942    avoid name collisions, the name of the application implementation\r
943    should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-EDI-info").\r
944 \r
945 4.  Timeline of events\r
946 \r
947    The following timeline shows when various events in the processing of\r
948    a message and generation of MDNs take place:\r
949 \r
950 \r
951 \r
952 \r
953 Fajman                      Standards Track                    [Page 17]\r
954 \f\r
955 RFC 2298           Message Disposition Notifications          March 1998\r
956 \r
957 \r
958    -- User composes message\r
959 \r
960    -- User tells UA to send message\r
961 \r
962    -- UA passes message to MTA (original recipient information\r
963       passed along)\r
964 \r
965    -- MTA sends message to next MTA\r
966 \r
967    -- Final MTA receives message\r
968 \r
969    -- Final MTA delivers message to UA (possibily generating DSN)\r
970 \r
971    -- UA performs automatic processing and generates corresponding\r
972       MDNs ("dispatched", "processed", "deleted", "denied" or "failed"\r
973       disposition type with "automatic-action" and "MDN-sent-\r
974       automatically" disposition modes)\r
975 \r
976    -- UA displays list of messages to user\r
977 \r
978    -- User selects a message and requests that some action be\r
979       performed on it.\r
980 \r
981    -- UA performs requested action and, with user's permission,\r
982       sends appropriate MDN ("displayed", "dispatched", "processed",\r
983       "deleted", "denied" or "failed" disposition type with "manual-\r
984       action" and "MDN-sent-manually" or "MDN-sent-automatically"\r
985       disposition mode).\r
986 \r
987    -- User possibly performs other actions on message, but no\r
988       further MDNs are generated.\r
989 \r
990 5.  Conformance and Usage Requirements\r
991 \r
992    A UA or gateway conforms to this specification if it generates MDNs\r
993    according to the protocol defined in this memo.  It is not necessary\r
994    to be able to generate all of the possible values of the Disposition\r
995    field.\r
996 \r
997    UAs and gateways MUST NOT generate the Original-Recipient field of an\r
998    MDN unless the mail protocols provide the address originally\r
999    specified by the sender at the time of submission.  Ordinary SMTP\r
1000    does not make that guarantee, but the SMTP extension defined in RFC\r
1001    1891 [8] permits such information to be carried in the envelope if it\r
1002    is available.  The Original-Recipient header defined in this document\r
1003    provides a way for the MTA to pass the original recipient address to\r
1004    the UA.\r
1005 \r
1006 \r
1007 \r
1008 \r
1009 Fajman                      Standards Track                    [Page 18]\r
1010 \f\r
1011 RFC 2298           Message Disposition Notifications          March 1998\r
1012 \r
1013 \r
1014    Each sender-specified recipient address may result in more than one\r
1015    MDN.  If an MDN is requested for a recipient that is forwarded to\r
1016    multiple recipients of an "alias" (as defined in RFC 1891 [8],\r
1017    section 6.2.7.3), each of the recipients may issue an MDN.\r
1018 \r
1019    Successful distribution of a message to a mailing list exploder\r
1020    SHOULD be considered final disposition of the message.  A mailing\r
1021    list exploder may issue an MDN with a disposition type of "processed"\r
1022    and disposition modes of "automatic-action" and "MDN- sent-\r
1023    automatically" indicating that the message has been forwarded to the\r
1024    list.  In this case, the request for MDNs is not propogated to the\r
1025    members of the list.\r
1026 \r
1027    Alternaively, the mailing list exploder may issue no MDN and\r
1028    propogate the request for MDNs to all members of the list.  The\r
1029    latter behavior is not recommended for any but small, closely knit\r
1030    lists, as it might cause large numbers of MDNs to be generated and\r
1031    may cause confidential subscribers to the list to be revealed.  It is\r
1032    also permissible for the mailing list exploder to direct MDNs to\r
1033    itself, correlate them, and produce a report to the original sender\r
1034    of the message.\r
1035 \r
1036    This specification places no restrictions on the processing of MDNs\r
1037    received by user agents or mailing lists.\r
1038 \r
1039 6.  Security Considerations\r
1040 \r
1041    The following security considerations apply when using MDNs:\r
1042 \r
1043 6.1 Forgery\r
1044 \r
1045    MDNs may be forged as easily as ordinary Internet electronic mail.\r
1046    User agents and automatic mail handling facilities (such as mail\r
1047    distribution list exploders) that wish to make automatic use of MDNs\r
1048    should take appropriate precautions to minimize the potential damage\r
1049    from denial-of-service attacks.\r
1050 \r
1051    Security threats related to forged MDNs include the sending of:\r
1052 \r
1053    (a)  A falsified disposition notification when the indicated\r
1054         disposition of the message has not actually ocurred,\r
1055 \r
1056    (b)  Unsolicited MDNs\r
1057 \r
1058 6.2 Confidentiality\r
1059 \r
1060    Another dimension of security is confidentiality.  There may be cases\r
1061    in which a message recipient does not wish the disposition of\r
1062 \r
1063 \r
1064 \r
1065 Fajman                      Standards Track                    [Page 19]\r
1066 \f\r
1067 RFC 2298           Message Disposition Notifications          March 1998\r
1068 \r
1069 \r
1070    messages addressed to him to be known or is concerned that the\r
1071    sending of MDNs may reveal other confidential information (e.g., when\r
1072    the message was read).  In this situation, it is acceptable for the\r
1073    UA to issue "denied" MDNs or to silently ignore requests for MDNs.\r
1074 \r
1075    If the Disposition-Notification-To header is passed on unmodified\r
1076    when a message is distributed to the subscribers of a mailing list,\r
1077    the subscribers to the list may be revealed to the sender of the\r
1078    original message by the generation of MDNs.\r
1079 \r
1080    Headers of the original message returned in part 3 of the\r
1081    multipart/report could reveal confidential information about host\r
1082    names and/or network topology inside a firewall.\r
1083 \r
1084    An unencrypted MDN could reveal confidential information about an\r
1085    encrypted message, especially if all or part of the original message\r
1086    is returned in part 3 of the multipart/report.  Encrypted MDNs are\r
1087    not defined in this specification.\r
1088 \r
1089    In general, any optional MDN field may be omitted if the Reporting UA\r
1090    site or user determines that inclusion of the field would impose too\r
1091    great a compromise of site confidentiality.  The need for such\r
1092    confidentiality must be balanced against the utility of the omitted\r
1093    information in MDNs.\r
1094 \r
1095 6.3 Non-Repudiation\r
1096 \r
1097    Within the framework of today's Internet Mail, the MDNs defined in\r
1098    this document provide valuable information to the mail user; however,\r
1099    MDNs can not be relied upon as a guarantee that a message was or was\r
1100    not not seen by the recipient.  Even if MDNs are not actively forged,\r
1101    they may be lost in transit.  The MDN issuing mechanism may be\r
1102    bypassed in some manner by the recipient.\r
1103 \r
1104 7.  Collected Grammar\r
1105 \r
1106    NOTE:  The following lexical tokens are defined in RFC 822:  atom,\r
1107    CRLF, mailbox, msg-id, text.  The definitions of attribute and value\r
1108    are as in the definition of the Content-Type header in RFC 2045 [4].\r
1109 \r
1110    Message headers:\r
1111 \r
1112    mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox\r
1113 \r
1114    Disposition-Notification-Options =\r
1115         "Disposition-Notification-Options" ":"\r
1116         disposition-notification-parameters\r
1117 \r
1118 \r
1119 \r
1120 \r
1121 Fajman                      Standards Track                    [Page 20]\r
1122 \f\r
1123 RFC 2298           Message Disposition Notifications          March 1998\r
1124 \r
1125 \r
1126    disposition-notification-parameters = parameter *(";" parameter)\r
1127 \r
1128    parameter = attribute "=" importance "," 1#value\r
1129 \r
1130    importance = "required" / "optional"\r
1131 \r
1132    original-recipient-header =\r
1133         "Original-Recipient" ":" address-type ";" generic-address\r
1134 \r
1135 \r
1136    Report content:\r
1137 \r
1138    disposition-notification-content = [ reporting-ua-field CRLF ]\r
1139         [ mdn-gateway-field CRLF ]\r
1140         [ original-recipient-field CRLF ]\r
1141         final-recipient-field CRLF\r
1142         [ original-message-id-field CRLF ]\r
1143         disposition-field CRLF\r
1144         *( failure-field CRLF )\r
1145         *( error-field CRLF )\r
1146         *( warning-field CRLF )\r
1147         *( extension-field CRLF )\r
1148 \r
1149    address-type = atom\r
1150 \r
1151    mta-name-type = atom\r
1152 \r
1153    reporting-ua-field = "Reporting-UA" ":" ua-name\r
1154                         [ ";" ua-product ]\r
1155 \r
1156    ua-name = *text\r
1157 \r
1158    ua-product = *text\r
1159 \r
1160    mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name\r
1161 \r
1162    mta-name = *text\r
1163 \r
1164    original-recipient-field =\r
1165         "Original-Recipient" ":" address-type ";" generic-address\r
1166 \r
1167    generic-address = *text\r
1168 \r
1169    final-recipient-field =\r
1170         "Final-Recipient" ":" address-type ";" generic-address\r
1171 \r
1172    disposition-field = "Disposition" ":" disposition-mode ";"\r
1173                        disposition-type\r
1174 \r
1175 \r
1176 \r
1177 Fajman                      Standards Track                    [Page 21]\r
1178 \f\r
1179 RFC 2298           Message Disposition Notifications          March 1998\r
1180 \r
1181 \r
1182                        [ '/' disposition-modifier\r
1183                          *( "," dispostion-modifier ) ]\r
1184 \r
1185    disposition-mode = action-mode "/" sending-mode\r
1186 \r
1187    action-mode = "manual-action" / "automatic-action"\r
1188 \r
1189    sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"\r
1190 \r
1191    disposition-type = "displayed"\r
1192                     / "dispatched"\r
1193                     / "processed"\r
1194                     / "deleted"\r
1195                     / "denied"\r
1196                     / "failed"\r
1197 \r
1198    disposition-modifier = ( "error" / "warning" )\r
1199                         / ( "superseded" / "expired" /\r
1200                             "mailbox-terminated" )\r
1201                         / disposition-modifier-extension\r
1202 \r
1203    disposition-modifier-extension = atom\r
1204 \r
1205    original-message-id-field = "Original-Message-ID" ":" msg-id\r
1206 \r
1207    failure-field = "Failure" ":" *text\r
1208 \r
1209    error-field = "Error" ":" *text\r
1210 \r
1211    warning-field = "Warning" ":" *text\r
1212 \r
1213    extension-field = extension-field-name ":" *text\r
1214 \r
1215    extension-field-name = atom\r
1216 \r
1217 8.  Guidelines for Gatewaying MDNs\r
1218 \r
1219    NOTE:  This section provides non-binding recommendations for the\r
1220    construction of mail gateways that wish to provide semi-transparent\r
1221    disposition notifications between the Internet and another electronic\r
1222    mail system.  Specific MDN gateway requirements for a particular pair\r
1223    of mail systems may be defined by other documents.\r
1224 \r
1225 8.1 Gatewaying from other mail systems to MDNs\r
1226 \r
1227    A mail gateway may issue an MDN to convey the contents of a "foreign"\r
1228    disposition notification over Internet Mail.  When there are\r
1229    appropriate mappings from the foreign notification elements to MDN\r
1230 \r
1231 \r
1232 \r
1233 Fajman                      Standards Track                    [Page 22]\r
1234 \f\r
1235 RFC 2298           Message Disposition Notifications          March 1998\r
1236 \r
1237 \r
1238    fields, the information may be transmitted in those MDN fields.\r
1239    Additional information (such as might be needed to tunnel the foreign\r
1240    notification through the Internet) may be defined in extension MDN\r
1241    fields.  (Such fields should be given names that identify the foreign\r
1242    mail protocol, e.g. X400-* for X.400 protocol elements)\r
1243 \r
1244    The gateway must attempt to supply reasonable values for the\r
1245    Reporting-UA, Final-Recipient, and Disposition fields.  These will\r
1246    normally be obtained by translating the values from the foreign\r
1247    notification into their Internet-style equivalents.  However, some\r
1248    loss of information is to be expected.\r
1249 \r
1250    The sender-specified recipient address, and the original message-id,\r
1251    if present in the foreign notification, should be preserved in the\r
1252    Original-Recipient and Original-Message-ID fields.\r
1253 \r
1254    The gateway should also attempt to preserve the "final" recipient\r
1255    address from the foreign system.  Whenever possible, foreign protocol\r
1256    elements should be encoded as meaningful printable ASCII strings.\r
1257 \r
1258    For MDNs produced from foreign disposition notifications, the name of\r
1259    the gateway MUST appear in the MDN-Gateway field of the MDN.\r
1260 \r
1261 8.2 Gatewaying from MDNs to other mail systems\r
1262 \r
1263    It may be possible to gateway MDNs from the Internet into a foreign\r
1264    mail system.  The primary purpose of such gatewaying is to convey\r
1265    disposition information in a form that is usable by the destination\r
1266    system.  A secondary purpose is to allow "tunneling" of MDNs through\r
1267    foreign mail systems, in case the MDN may be gatewayed back into the\r
1268    Internet.\r
1269 \r
1270    In general, the recipient of the MDN (i.e., the sender of the\r
1271    original message) will want to know, for each recipient:  the closest\r
1272    available approximation to the original recipient address, and the\r
1273    disposition (displayed, printed, etc.).\r
1274 \r
1275    If possible, the gateway should attempt to preserve the Original-\r
1276    Recipient address and Original-Message-ID (if present), in the\r
1277    resulting foreign disposition report.\r
1278 \r
1279    If it is possible to tunnel an MDN through the destination\r
1280    environment, the gateway specification may define a means of\r
1281    preserving the MDN information in the disposition reports used by\r
1282    that environment.\r
1283 \r
1284 \r
1285 \r
1286 \r
1287 \r
1288 \r
1289 Fajman                      Standards Track                    [Page 23]\r
1290 \f\r
1291 RFC 2298           Message Disposition Notifications          March 1998\r
1292 \r
1293 \r
1294 9.  Example\r
1295 \r
1296    NOTE:  This example is provided as illustration only, and is not\r
1297    considered part of the MDN protocol specification.  If the example\r
1298    conflicts with the protocol definition above, the example is wrong.\r
1299 \r
1300    Likewise, the use of *-type subfield names or extension fields in\r
1301    this example is not to be construed as a definition for those type\r
1302    names or extension fields.\r
1303 \r
1304 9.1 This is an MDN issued after a message has been displayed to the user\r
1305    of an Internet Mail user agent.\r
1306 \r
1307    Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400\r
1308    From: Joe Recipient <Joe_Recipient@mega.edu>\r
1309    Message-Id: <199509200019.12345@mega.edu>\r
1310    Subject: Disposition notification\r
1311    To: Jane Sender <Jane_Sender@huge.com>\r
1312    MIME-Version: 1.0\r
1313    Content-Type: multipart/report; report-type=disposition-notification;\r
1314          boundary="RAA14128.773615765/mega.edu"\r
1315 \r
1316    --RAA14128.773615765/mega.edu\r
1317 \r
1318    The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe\r
1319    Recipient <Joe_Recipient@mega.edu> with subject "First draft of\r
1320    report" has been displayed.  This is no guarantee that the message\r
1321    has been read or understood.\r
1322 \r
1323    --RAA14128.773615765/mega.edu\r
1324    content-type: message/disposition-notification\r
1325 \r
1326    Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1\r
1327    Original-Recipient: rfc822;Joe_Recipient@mega.edu\r
1328    Final-Recipient: rfc822;Joe_Recipient@mega.edu\r
1329    Original-Message-ID: <199509192301.23456@huge.com>\r
1330    Disposition: manual-action/MDN-sent-manually; displayed\r
1331 \r
1332    --RAA14128.773615765/mega.edu\r
1333    content-type: message/rfc822\r
1334 \r
1335    [original message goes here]\r
1336 \r
1337    --RAA14128.773615765/mega.edu--\r
1338 \r
1339 \r
1340 \r
1341 \r
1342 \r
1343 \r
1344 \r
1345 Fajman                      Standards Track                    [Page 24]\r
1346 \f\r
1347 RFC 2298           Message Disposition Notifications          March 1998\r
1348 \r
1349 \r
1350 10.  IANA Registration Forms\r
1351 \r
1352    The forms below are for use when registering a new parameter name for\r
1353    the Disposition-Notification-Options header, a new disposition\r
1354    modifier name, or a new MDN extension field.  Each piece of\r
1355    information required by a registration form may be satisfied either\r
1356    by providing the information on the form itself, or by including a\r
1357    reference to a published, publicly available specification that\r
1358    includes the necessary information.  IANA MAY reject registrations\r
1359    because of incomplete registration forms, imprecise specifications,\r
1360    or inappropriate names.\r
1361 \r
1362    To register, complete the applicable form below and send it via\r
1363    electronic mail to <IANA@IANA.ORG>.\r
1364 \r
1365 10.1 IANA registration form for Disposition-Notification-Options header\r
1366    parameter names\r
1367 \r
1368    A registration for a Disposition-Notification-Options header\r
1369    parameter name MUST include the following information:\r
1370 \r
1371    (a) The proposed parameter name.\r
1372 \r
1373    (b) The syntax for parameter values, specified using BNF, ABNF,\r
1374    regular expressions, or other non-ambiguous language.\r
1375 \r
1376    (c) If parameter values are not composed entirely of graphic\r
1377    characters from the US-ASCII repertoire, a specification for how they\r
1378    are to be encoded as graphic US-ASCII characters in a Disposition-\r
1379    Notification-Options header.\r
1380 \r
1381    (d) A reference to a standards track RFC or experimental RFC approved\r
1382    by the IESG that describes the semantics of the parameter values.\r
1383 \r
1384 10.2 IANA registration form for disposition modifer names\r
1385 \r
1386    A registration for a disposition-modifier name MUST include the\r
1387    following information:\r
1388 \r
1389    (a) The proposed disposition-modifier name.\r
1390 \r
1391    (b) A reference to a standards track RFC or experimental RFC approved\r
1392    by the IESG that describes the semantics of the disposition modifier.\r
1393 \r
1394 10.3 IANA registration form for MDN extension field names\r
1395 \r
1396    A registration for an MDN extension field name MUST include the\r
1397    following information:\r
1398 \r
1399 \r
1400 \r
1401 Fajman                      Standards Track                    [Page 25]\r
1402 \f\r
1403 RFC 2298           Message Disposition Notifications          March 1998\r
1404 \r
1405 \r
1406    (a) The proposed extension field name.\r
1407 \r
1408    (b) The syntax for extension values, specified using BNF, ABNF,\r
1409    regular expressions, or other non-ambiguous language.\r
1410 \r
1411    (c) If extension field values are not composed entirely of graphic\r
1412    characters from the US-ASCII repertoire, a specification for how they\r
1413    are to be encoded as graphic US-ASCII characters in a Disposition-\r
1414    Notification-Options header.\r
1415 \r
1416    (d) A reference to a standards track RFC or experimental RFC approved\r
1417    by the IESG that describes the semantics of the extension field.\r
1418 \r
1419 11.  Acknowledgments\r
1420 \r
1421    This document is based on the Delivery Status Notifications document,\r
1422    RFC 1894 [9], by Keith Moore and Greg Vaudreuil.  Contributions were\r
1423    made by members of the IETF Receipt Working Group, including Harald\r
1424    Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned\r
1425    Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell,\r
1426    Pete Resnick, Chuck Shih.\r
1427 \r
1428 12.  References\r
1429 \r
1430    [1]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,\r
1431          August 1982.\r
1432 \r
1433    [2]   Crocker, D., "Standard for the Format of ARPA Internet Text\r
1434          Messages", STD 11, RFC 822, August 1982.\r
1435 \r
1436    [3]   Braden, R. (ed.), "Requirements for Internet Hosts -\r
1437          Application and Support", STD 3, RFC 1123, October 1989.\r
1438 \r
1439    [4]   Freed, N., and N. Borenstein, "Multipurpose Internet Mail\r
1440          Extensions (MIME) Part One:  Format of Internet Message\r
1441          Bodies", RFC 2045, November 1996.\r
1442 \r
1443    [5]   Freed, N., and N. Borenstein, "Multipurpose Internet Mail\r
1444          Extensions (MIME) Part Two:  Media Types", RFC 2046, November\r
1445          1996.\r
1446 \r
1447    [6]   Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part\r
1448          Three:  Message Header Extensions for Non-Ascii Text", RFC\r
1449          2047, November 1996.\r
1450 \r
1451    [7]   Vaudreuil, G., "The Multipart/Report Content Type for the\r
1452          Reporting of Mail System Administrative Messages", RFC 1892,\r
1453          January 1996.\r
1454 \r
1455 \r
1456 \r
1457 Fajman                      Standards Track                    [Page 26]\r
1458 \f\r
1459 RFC 2298           Message Disposition Notifications          March 1998\r
1460 \r
1461 \r
1462    [8]   Moore, K., "SMTP Service Extension for Delivery Status\r
1463          Notifications", RFC 1891, January 1996.\r
1464 \r
1465    [9]   Moore, K., and G. Vaudreuil, "An Extensible Format for\r
1466          Delivery Status Notifications, RFC 1894, January 1996.\r
1467 \r
1468    [10]  Bradner, S., "Key Words for Use in RFCs to Indicate\r
1469          Requirement Levels", BCP 14, RFC 2119, March 1997.\r
1470 \r
1471 13.  Author's Address\r
1472 \r
1473    Roger Fajman\r
1474    National Institutes of Health\r
1475    Building 12A, Room 3063\r
1476    12 South Drive MSC 5659\r
1477    Bethesda, Maryland 20892-5659\r
1478    USA\r
1479 \r
1480    EMail:  raf@cu.nih.gov\r
1481    Phone:  +1 301 402 4265\r
1482    Fax:    +1 301 480 6241\r
1483 \r
1484 \r
1485 \r
1486 \r
1487 \r
1488 \r
1489 \r
1490 \r
1491 \r
1492 \r
1493 \r
1494 \r
1495 \r
1496 \r
1497 \r
1498 \r
1499 \r
1500 \r
1501 \r
1502 \r
1503 \r
1504 \r
1505 \r
1506 \r
1507 \r
1508 \r
1509 \r
1510 \r
1511 \r
1512 \r
1513 Fajman                      Standards Track                    [Page 27]\r
1514 \f\r
1515 RFC 2298           Message Disposition Notifications          March 1998\r
1516 \r
1517 \r
1518 14.  Full Copyright Statement\r
1519 \r
1520    Copyright (C) The Internet Society (1998).  All Rights Reserved.\r
1521 \r
1522    This document and translations of it may be copied and furnished to\r
1523    others, and derivative works that comment on or otherwise explain it\r
1524    or assist in its implementation may be prepared, copied, published\r
1525    and distributed, in whole or in part, without restriction of any\r
1526    kind, provided that the above copyright notice and this paragraph are\r
1527    included on all such copies and derivative works.  However, this\r
1528    document itself may not be modified in any way, such as by removing\r
1529    the copyright notice or references to the Internet Society or other\r
1530    Internet organizations, except as needed for the purpose of\r
1531    developing Internet standards in which case the procedures for\r
1532    copyrights defined in the Internet Standards process must be\r
1533    followed, or as required to translate it into languages other than\r
1534    English.\r
1535 \r
1536    The limited permissions granted above are perpetual and will not be\r
1537    revoked by the Internet Society or its successors or assigns.\r
1538 \r
1539    This document and the information contained herein is provided on an\r
1540    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
1541    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
1542    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
1543    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
1544    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
1545 \r
1546 \r
1547 \r
1548 \r
1549 \r
1550 \r
1551 \r
1552 \r
1553 \r
1554 \r
1555 \r
1556 \r
1557 \r
1558 \r
1559 \r
1560 \r
1561 \r
1562 \r
1563 \r
1564 \r
1565 \r
1566 \r
1567 \r
1568 \r
1569 Fajman                      Standards Track                    [Page 28]\r
1570 \f\r