1
2
3
4
5
6
7Network Working Group K. Moore
8Request for Comments: 3464 University of Tennessee
9Obsoletes: 1894 G. Vaudreuil
10Category: Standards Track Lucent Technologies
11 January 2003
12
13
14 An Extensible Message Format for Delivery Status Notifications
15
16Status of this Memo
17
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
23
24Copyright Notice
25
26 Copyright (C) The Internet Society (2003). All Rights Reserved.
27
28Abstract
29
30 This memo defines a Multipurpose Internet Mail Extensions (MIME)
31 content-type that may be used by a message transfer agent (MTA) or
32 electronic mail gateway to report the result of an attempt to deliver
33 a message to one or more recipients. This content-type is intended
34 as a machine-processable replacement for the various types of
35 delivery status notifications currently used in Internet electronic
36 mail.
37
38 Because many messages are sent between the Internet and other
39 messaging systems (such as X.400 or the so-called "Local Area Network
40 (LAN)-based" systems), the Delivery Status Notification (DSN)
41 protocol is designed to be useful in a multi-protocol messaging
42 environment. To this end, the protocol described in this memo
43 provides for the carriage of "foreign" addresses and error codes, in
44 addition to those normally used in Internet mail. Additional
45 attributes may also be defined to support "tunneling" of foreign
46 notifications through Internet mail.
47
48
49
50
51
52
53
54
55
56
57
58Moore & Vaudreuil Standards Track [Page 1]
59
60RFC 3464 Delivery Status Notifications January 2003
61
62
63Table of Contents
64
65 1. Introduction ....................................................3
66 1.1 Purposes .....................................................3
67 1.2 Requirements .................................................4
68 1.3 Terminology ..................................................5
69 2. Format of a Delivery Status Notification ........................7
70 2.1 The message/delivery-status content-type .....................9
71 2.1.1 General conventions for DSN fields ........................9
72 2.1.2 "*-type" sub-fields .......................................9
73 2.1.3 Lexical tokens imported from RFC 822 .....................10
74 2.2 Per-Message DSN Fields ......................................11
75 2.2.1 The Original-Envelope-Id field ...........................11
76 2.2.2 The Reporting-MTA DSN field ..............................12
77 2.2.3 The DSN-Gateway field ....................................13
78 2.2.4 The Received-From-MTA DSN field ..........................14
79 2.2.5 The Arrival-Date DSN field ...............................14
80 2.3 Per-Recipient DSN fields ....................................14
81 2.3.1 Original-Recipient field .................................15
82 2.3.2 Final-Recipient field ....................................15
83 2.3.3 Action field .............................................16
84 2.3.4 Status field .............................................18
85 2.3.5 Remote-MTA field .........................................19
86 2.3.6 Diagnostic-Code field ....................................19
87 2.3.7 Last-Attempt-Date field ..................................20
88 2.3.8 final-log-id field .......................................20
89 2.3.9 Will-Retry-Until field ...................................20
90 2.4 Extension fields ............................................21
91 3. Conformance and Usage Requirements .............................22
92 4. Security Considerations ........................................23
93 4.1 Forgery .....................................................23
94 4.2 Confidentiality .............................................23
95 4.3 Non-Repudiation .............................................25
96 5. References .....................................................25
97 6. Acknowledgments ................................................26
98 Appendix A - Collected Grammar ....................................27
99 Appendix B - Guidelines for Gatewaying DSNS .......................29
100 Gatewaying from other mail systems to DSNs ......................29
101 Gatewaying from DSNs to other mail systems ......................30
102 Appendix C - Guidelines for Use of DSNS By Mailing List Exploders .30
103 Appendix D - IANA Registration Forms for DSN Types ................31
104 IANA registration form for address-type .........................32
105 IANA registration form for diagnostic-type ......................32
106 IANA registration form for MTA-name-type ........................32
107 Appendix E - Examples .............................................33
108 Simple DSN ......................................................34
109 Multi-Recipient DSN .............................................35
110 DSN from gateway to foreign system ..............................36
111
112
113
114Moore & Vaudreuil Standards Track [Page 2]
115
116RFC 3464 Delivery Status Notifications January 2003
117
118
119 Delayed DSN .....................................................37
120 Appendix F - Changes from RFC 1894 ................................38
121 Authors' Addresses ................................................39
122 Full Copyright Statement ..........................................40
123
1241. Introduction
125
126 This memo defines a Multipurpose Internet Mail Extensions (MIME)
127 [MIME1] content-type for Delivery Status Notifications (DSNs). A DSN
128 can be used to notify the sender of a message of any of several
129 conditions: failed delivery, delayed delivery, successful delivery,
130 or the gatewaying of a message into an environment that may not
131 support DSNs. The "message/delivery-status" content-type defined
132 herein is intended for use within the framework of the
133 "multipart/report" content type defined in [REPORT].
134
135 This memo defines only the format of the notifications. An extension
136 to the Simple Message Transfer Protocol (SMTP) [SMTP] to fully
137 support such notifications is the subject of a separate memo [DRPT].
138
139 Document Conventions
140
141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
143 document are to be interpreted as described in BCP 14, RFC 2119
144 [RFC2119].
145
1461.1 Purposes
147
148 The DSNs defined in this memo are expected to serve several purposes:
149
150 (a) Inform human beings of the status of message delivery processing,
151 as well as the reasons for any delivery problems or outright
152 failures, in a manner that is largely independent of human
153 language and media;
154
155 (b) Allow mail user agents to keep track of the delivery status of
156 messages sent, by associating returned DSNs with earlier message
157 transmissions;
158
159 (c) Allow mailing list exploders to automatically maintain their
160 subscriber lists when delivery attempts repeatedly fail;
161
162 (d) Convey delivery and non-delivery notifications resulting from
163 attempts to deliver messages to "foreign" mail systems via a
164 gateway;
165
166
167
168
169
170Moore & Vaudreuil Standards Track [Page 3]
171
172RFC 3464 Delivery Status Notifications January 2003
173
174
175 (e) Allow "foreign" notifications to be tunneled through a MIME-
176 capable message system and back into the original messaging
177 system that issued the original notification, or even to a third
178 messaging system;
179
180 (f) Allow language-independent and medium-independent, yet reasonably
181 precise, indications of the reason for the failure of a message
182 to be delivered; and
183
184 (g) Provide sufficient information to remote MTA maintainers (via
185 "trouble tickets") so that they can understand the nature of
186 reported errors. This feature is used in the case that failure
187 to deliver a message is due to the malfunction of a remote MTA
188 and the sender wants to report the problem to the remote MTA
189 administrator.
190
1911.2 Requirements
192
193 These purposes place the following constraints on the notification
194 protocol:
195
196 (a) It must be readable by humans as well as being machine-parsable.
197
198 (b) It must provide enough information to allow message senders (or
199 the user agents) to unambiguously associate a DSN with the
200 message that was sent and the original recipient address for
201 which the DSN is issued (if such information is available), even
202 if the message was forwarded to another recipient address.
203
204 (c) It must be able to preserve the reason for the success or failure
205 of a delivery attempt in a remote messaging system, using the
206 "language" (mailbox addresses and status codes) of that remote
207 system.
208
209 (d) It must also be able to describe the reason for the success or
210 failure of a delivery attempt, independent of any particular
211 human language or of the "language" of any particular mail
212 system.
213
214 (e) It must preserve enough information to allow the maintainer of a
215 remote MTA to understand (and if possible, reproduce) the
216 conditions that caused a delivery failure at that MTA.
217
218 (f) For any notifications issued by foreign mail systems, which are
219 translated by a mail gateway to the DSN format, the DSN must
220 preserve the "type" of the foreign addresses and error codes, so
221 that these may be correctly interpreted by gateways.
222
223
224
225
226Moore & Vaudreuil Standards Track [Page 4]
227
228RFC 3464 Delivery Status Notifications January 2003
229
230
231 A DSN contains a set of per-message fields that identify the message
232 and the transaction during which the message was submitted, along
233 with other fields that apply to all delivery attempts described by
234 the DSN. The DSN also includes a set of per-recipient fields to
235 convey the result of the attempt to deliver the message to each of
236 one or more recipients.
237
2381.3 Terminology
239
240 A message may be transmitted through several message transfer agents
241 (MTAs) on its way to a recipient. For a variety of reasons,
242 recipient addresses may be rewritten during this process, so each MTA
243 may potentially see a different recipient address. Depending on the
244 purpose for which a DSN is used, different formats of a particular
245 recipient address will be needed.
246
247 Several DSN fields are defined in terms of the view from a particular
248 MTA in the transmission. The MTAs are assigned the following names:
249
250 (a) Original MTA
251
252 The Original MTA is the one to which the message is submitted for
253 delivery by the sender of the message.
254
255 (b) Reporting MTA
256
257 For any DSN, the Reporting MTA is the one which is reporting the
258 results of delivery attempts described in the DSN.
259
260 If the delivery attempts described occurred in a "foreign" (non-
261 Internet) mail system, and the DSN was produced by translating
262 the foreign notice into DSN format, the Reporting MTA will still
263 identify the "foreign" MTA where the delivery attempts occurred.
264
265 (c) Received-From MTA
266
267 The Received-From MTA is the MTA from which the Reporting MTA
268 received the message, and accepted responsibility for delivery of
269 the message.
270
271 (d) Remote MTA
272
273 If an MTA determines that it must relay a message to one or more
274 recipients, but the message cannot be transferred to its "next
275 hop" MTA, or if the "next hop" MTA refuses to accept
276 responsibility for delivery of the message to one or more of its
277 intended recipients, the relaying MTA may need to issue a DSN on
278 behalf of the recipients for whom the message cannot be
279
280
281
282Moore & Vaudreuil Standards Track [Page 5]
283
284RFC 3464 Delivery Status Notifications January 2003
285
286
287 delivered. In this case the relaying MTA is the Reporting MTA,
288 and the "next hop" MTA is known as the Remote MTA.
289
290 Figure 1 illustrates the relationship between the various MTAs.
291
292+-----+ +--------+ +---------+ +---------+ +------+
293| | | | |Received-| | | | |
294| | => |Original| => ... => | From | => |Reporting| ===> |Remote|
295| user| | MTA | | MTA | | MTA | <No! | MTA |
296|agent| +--------+ +---------+ +----v----+ +------+
297| | |
298| | <-------------------------------------------+
299+-----+ (DSN returned to sender by Reporting MTA)
300
301 Figure 1. Original, Received-From, Reporting and Remote MTAs
302
303 Each of these MTAs may provide information that is useful in a DSN:
304
305 + Ideally, the DSN will contain the address of each recipient as
306 originally specified to the Original MTA by the sender of the
307 message.
308
309 This version of the address is needed (rather than a forwarding
310 address or some modified version of the original address) so that
311 the sender may compare the recipient address in the DSN with the
312 address in the sender's records (e.g., an address book for an
313 individual, the list of subscribers for a mailing list) and take
314 appropriate action.
315
316 Similarly, the DSN might contain an "envelope identifier" that was
317 known to both the sender's user agent and the Original MTA at the
318 time of message submission, and which, if included in the DSN, can
319 be used by the sender to keep track of which messages were or were
320 not delivered.
321
322 + If a message was (a) forwarded to a different address than that
323 specified by the sender, (b) gatewayed to a different mail system
324 than that used by the sender, or (c) subjected to address rewriting
325 during transmission, the "final" form of the recipient address
326 (i.e., the one seen by the Reporting MTA) will be different than
327 the original (sender-specified) recipient address. Just as the
328 sender's user agent (or the sender) prefers the original recipient
329 address, so the "final" address is needed when reporting a problem
330 to the postmaster of the site where message delivery failed,
331 because only the final recipient address will allow her to
332 reproduce the conditions that caused the failure.
333
334
335
336
337
338Moore & Vaudreuil Standards Track [Page 6]
339
340RFC 3464 Delivery Status Notifications January 2003
341
342
343 + A "failed" DSN should contain the most accurate explanation for the
344 delivery failure that is available. For ease of interpretation,
345 this information should be a format that is independent of the mail
346 transport system that issued the DSN. However, if a foreign error
347 code is translated into some transport-independent format, some
348 information may be lost. It is therefore desirable to provide both
349 a transport-independent status code and a mechanism for reporting
350 transport-specific codes. Depending on the circumstances that
351 produced delivery failure, the transport-specific code might be
352 obtained from either the Reporting MTA or the Remote MTA.
353
354 Since different values for "recipient address" and "delivery status
355 code" are needed according to the circumstance in which a DSN will be
356 used, and since the MTA that issues the DSN cannot anticipate those
357 circumstances, the DSN format described here may contain both the
358 original and final forms of a recipient address, and both a
359 transport-independent and a transport-specific indication of delivery
360 status.
361
362 Extension fields may also be added by the Reporting MTA as needed to
363 provide additional information for use in a trouble ticket or to
364 preserve information for tunneling of foreign delivery reports
365 through Internet DSNs.
366
367 The Original, Reporting, and Remote MTAs may exist in very different
368 environments and use dissimilar transport protocols, MTA names,
369 address formats, and delivery status codes. DSNs therefore do not
370 assume any particular format for mailbox addresses, MTA names, or
371 transport-specific status codes. Instead, the various DSN fields
372 that carry such quantities consist of a "type" sub-field followed by
373 a sub-field whose contents are ordinary text characters, and the
374 format of which is indicated by the "type" sub-field. This allows a
375 DSN to convey these quantities regardless of format.
376
3772. Format of a Delivery Status Notification ../dsn/dsn.go:141
378
379 A DSN is a MIME message with a top-level content-type of
380 multipart/report (defined in [REPORT]). When a multipart/report
381 content is used to transmit a DSN:
382
383 (a) The report-type parameter of the multipart/report content is
384 "delivery-status".
385
386 (b) The first component of the multipart/report contains a human-
387 readable explanation of the DSN, as described in [REPORT].
388
389
390
391
392
393
394Moore & Vaudreuil Standards Track [Page 7]
395
396RFC 3464 Delivery Status Notifications January 2003
397
398
399 (c) The second component of the multipart/report is of content-type
400 message/delivery-status, described in section 2.1 of this
401 document.
402
403 (d) If the original message or a portion of the message is to be
404 returned to the sender, it appears as the third component of the
405 multipart/report.
406
407 NOTE: For delivery status notifications gatewayed from foreign
408 systems, the headers of the original message may not be available.
409 In this case the third component of the DSN may be omitted, or it may
410 contain "simulated" RFC 822 headers that contain equivalent
411 information. In particular, it is very desirable to preserve the
412 subject, date, and message-id (or equivalent) fields from the
413 original message.
414
415 The DSN MUST be addressed (in both the message header and the ../dsn/dsn.go:38
416 transport envelope) to the return address from the transport envelope
417 which accompanied the original message for which the DSN was
418 generated. (For a message that arrived via SMTP, the envelope return
419 address appears in the MAIL FROM command.)
420
421 The From field of the message header of the DSN SHOULD contain the ../dsn/dsn.go:33
422 address of a human who is responsible for maintaining the mail system
423 at the Reporting MTA site (e.g., Postmaster), so that a reply to the
424 DSN will reach that person. Exception: if a DSN is translated from a
425 foreign delivery report, and the gateway performing the translation
426 cannot determine the appropriate address, the From field of the DSN
427 MAY be the address of a human who is responsible for maintaining the
428 gateway.
429
430 The envelope sender address of the DSN SHOULD be chosen to ensure
431 that no delivery status reports will be issued in response to the DSN
432 itself, and MUST be chosen so that DSNs will not generate mail loops.
433 Whenever an SMTP transaction is used to send a DSN, the MAIL FROM ../smtpserver/dsn.go:50
434 command MUST use a NULL return address, i.e., "MAIL FROM:<>".
435
436 A particular DSN describes the delivery status for exactly one ../dsn/dsn.go:72 ../smtpserver/server.go:2626
437 message. However, an MTA MAY report on the delivery status for
438 several recipients of the same message in a single DSN. Due to the
439 nature of the mail transport system (where responsibility for
440 delivery of a message to its recipients may be split among several
441 MTAs, and delivery to any particular recipient may be delayed),
442 multiple DSNs may still be issued in response to a single message
443 submission.
444
445
446
447
448
449
450Moore & Vaudreuil Standards Track [Page 8]
451
452RFC 3464 Delivery Status Notifications January 2003
453
454
4552.1 The message/delivery-status content-type ../dsn/dsn.go:201
456
457 The message/delivery-status content-type is defined as follows:
458
459 MIME type name: message
460 MIME subtype name: delivery-status
461 Optional parameters: none
462 Encoding considerations: "7bit" encoding is sufficient and
463 MUST be used to maintain readability
464 when viewed by non-MIME mail readers.
465 Security considerations: discussed in section 4 of this memo.
466
467 The message/delivery-status report type for use in the
468 multipart/report is "delivery-status".
469
470 The body of a message/delivery-status consists of one or more ../dsn/dsn.go:216
471 "fields" formatted according to the ABNF of RFC 822 header "fields"
472 (see [RFC822]). The per-message fields appear first, followed by a
473 blank line. Following the per-message fields are one or more groups
474 of per-recipient fields. Each group of per-recipient fields is
475 preceded by a blank line. Using the ABNF of RFC 822, the syntax of
476 the message/delivery-status content is as follows:
477
478 delivery-status-content = per-message-fields 1*
479 ( CRLF per-recipient-fields )
480
481 The per-message fields are described in section 2.2. The
482 per-recipient fields are described in section 2.3.
483
4842.1.1 General conventions for DSN fields
485
486 Since these fields are defined according to the rules of RFC 822, the ../dsn/parse.go:119
487 same conventions for continuation lines and comments apply.
488 Notification fields may be continued onto multiple lines by beginning
489 each additional line with a SPACE or HTAB. Text that appears in
490 parentheses is considered a comment and not part of the contents of
491 that notification field. Field names are case-insensitive, so the
492 names of notification fields may be spelled in any combination of
493 upper and lower case letters. Comments in DSN fields may use the
494 "encoded-word" construct defined in [MIME3].
495
4962.1.2 "*-type" sub-fields
497
498 Several DSN fields consist of a "-type" sub-field, followed by a
499 semicolon, followed by "*text". For these fields, the keyword used
500 in the address-type, diagnostic-type, or MTA-name-type sub-field
501 indicates the expected format of the address, status-code, or
502 MTA-name which follows.
503
504
505
506Moore & Vaudreuil Standards Track [Page 9]
507
508RFC 3464 Delivery Status Notifications January 2003
509
510
511 The "-type" sub-fields are defined as follows:
512
513 (a) An "address-type" specifies the format of a mailbox address. For 6533:250 ../dsn/parse.go:305
514 example, Internet mail addresses use the "rfc822" address-type. ../dsn/dsn.go:246
515
516 address-type = atom
517
518 (b) A "diagnostic-type" specifies the format of a status code. For ../dsn/parse.go:244
519 example, when a DSN field contains a reply code reported via the
520 Simple Mail Transfer Protocol [SMTP], the "smtp" diagnostic-type
521 is used.
522
523 diagnostic-type = atom
524
525 (c) An "MTA-name-type" specifies the format of an MTA name. For ../dsn/parse.go:283
526 example, for an SMTP server on an Internet host, the MTA name is
527 the domain name of that host, and the "dns" MTA-name-type is
528 used.
529
530 mta-name-type = atom
531
532 Values for address-type, diagnostic-type, and MTA-name-type are
533 case-insensitive. Thus address-type values of "RFC822" and "rfc822"
534 are equivalent.
535
536 The Internet Assigned Numbers Authority (IANA) will maintain a ../dsn/dsn.go:218
537 registry of address-types, diagnostic-types, and MTA-name-types,
538 along with descriptions of the meanings and acceptable values of
539 each, or a reference to one or more specifications that provide such
540 descriptions. (The "rfc822" address-type, "smtp" diagnostic-type,
541 and "dns" MTA-name-type are defined in [DRPT].) Registration forms
542 for address-type, diagnostic-type, and MTA-name-type appear in
543 Appendix D.
544
545 IANA will not accept registrations for any address-type,
546 diagnostic-type, or MTA-name-type name that begins with "X-". These
547 type names are reserved for experimental use.
548
5492.1.3 Lexical tokens imported from RFC 822
550
551 The following lexical tokens, defined in [RFC822], are used in the
552 ABNF grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF,
553 linear-white-space, SPACE, text. The date-time lexical token is
554 defined in [HOSTREQ].
555
556
557
558
559
560
561
562Moore & Vaudreuil Standards Track [Page 10]
563
564RFC 3464 Delivery Status Notifications January 2003
565
566
5672.2 Per-Message DSN Fields
568
569 Some fields of a DSN apply to all of the delivery attempts described
570 by that DSN. At most, these fields may appear once in any DSN.
571 These fields are used to correlate the DSN with the original message
572 transaction and to provide additional information which may be useful
573 to gateways.
574
575 per-message-fields = ../dsn/dsn.go:224
576 [ original-envelope-id-field CRLF ]
577 reporting-mta-field CRLF
578 [ dsn-gateway-field CRLF ]
579 [ received-from-mta-field CRLF ]
580 [ arrival-date-field CRLF ]
581 *( extension-field CRLF )
582
5832.2.1 The Original-Envelope-Id field 3461:1139 todo future: ../dsn/dsn.go:225
584
585 The optional Original-Envelope-Id field contains an "envelope
586 identifier" that uniquely identifies the transaction during which the
587 message was submitted, and was either (a) specified by the sender and
588 supplied to the sender's MTA, or (b) generated by the sender's MTA
589 and made available to the sender when the message was submitted. Its
590 purpose is to allow the sender (or her user agent) to associate the
591 returned DSN with the specific transaction in which the message was
592 sent.
593
594 If such an envelope identifier was present in the envelope that
595 accompanied the message when it arrived at the Reporting MTA, it
596 SHOULD be supplied in the Original-Envelope-Id field of any DSNs
597 issued as a result of an attempt to deliver the message. Except when
598 a DSN is issued by the sender's MTA, an MTA MUST NOT supply this
599 field unless there is an envelope-identifier field in the envelope
600 that accompanied this message on its arrival at the Reporting MTA.
601
602 The Original-Envelope-Id field is defined as follows:
603
604 original-envelope-id-field =
605 "Original-Envelope-Id" ":" envelope-id
606
607 envelope-id = *text
608
609 There may be at most one Original-Envelope-Id field per DSN.
610
611 The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the
612 original case and spelling of the envelope-id.
613
614
615
616
617
618Moore & Vaudreuil Standards Track [Page 11]
619
620RFC 3464 Delivery Status Notifications January 2003
621
622
623 NOTE: The Original-Envelope-Id is NOT the same as the
624 Message-Id from the message header. The Message-Id identifies
625 the content of the message, while the Original-Envelope-Id
626 identifies the transaction in which the message is sent.
627
6282.2.2 The Reporting-MTA DSN field ../dsn/dsn.go:229
629
630 reporting-mta-field =
631 "Reporting-MTA" ":" mta-name-type ";" mta-name
632
633 mta-name = *text
634
635 The Reporting-MTA field is defined as follows:
636
637 A DSN describes the results of attempts to deliver, relay, or gateway
638 a message to one or more recipients. In all cases, the Reporting-MTA
639 is the MTA that attempted to perform the delivery, relay, or gateway
640 operation described in the DSN. This field is required.
641
642 Note that if an SMTP client attempts to relay a message to an SMTP
643 server and receives an error reply to a RCPT command, the client is
644 responsible for generating the DSN, and the client's domain name will
645 appear in the Reporting-MTA field. (The server's domain name will
646 appear in the Remote-MTA field.)
647
648 Note that the Reporting-MTA is not necessarily the MTA which actually
649 issued the DSN. For example, if an attempt to deliver a message
650 outside of the Internet resulted in a non-delivery notification which
651 was gatewayed back into Internet mail, the Reporting-MTA field of the
652 resulting DSN would be that of the MTA that originally reported the
653 delivery failure, not that of the gateway which converted the foreign
654 notification into a DSN. See Figure 2.
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674Moore & Vaudreuil Standards Track [Page 12]
675
676RFC 3464 Delivery Status Notifications January 2003
677
678
679 sender's environment recipient's environment
680 ............................ ..........................................
681 : :
682 (1) : : (2)
683 +-----+ +--------+ +--------+ +---------+ +---------+ +------+
684 | | | | | | |Received-| | | | |
685 | |=>|Original|=>| |->| From |->|Reporting|-->|Remote|
686 | user| | MTA | | | | MTA | | MTA |<No| MTA |
687 |agent| +--------+ |Gateway | +---------+ +----v----+ +------+
688 | | | | |
689 | | <============| |<-------------------+
690 +-----+ | |(4) (3)
691 +--------+
692 : :
693 ...........................: :.........................................
694
695 Figure 2. DSNs in the presence of gateways
696
697 (1) message is gatewayed into recipient's environment
698 (2) attempt to relay message fails
699 (3) reporting-mta (in recipient's environment) returns non-delivery
700 notification
701 (4) gateway translates foreign notification into a DSN
702
703 The mta-name portion of the Reporting-MTA field is formatted
704 according to the conventions indicated by the mta-name-type
705 sub-field. If an MTA functions as a gateway between dissimilar mail
706 environments and thus is known by multiple names depending on the
707 environment, the mta-name sub-field SHOULD contain the name used by
708 the environment from which the message was accepted by the
709 Reporting-MTA.
710
711 Because the exact spelling of an MTA name may be significant in a
712 particular environment, MTA names are CASE-SENSITIVE.
713
7142.2.3 The DSN-Gateway field ../dsn/dsn.go:231
715
716 The DSN-Gateway field indicates the name of the gateway or MTA that
717 translated a foreign (non-Internet) delivery status notification into
718 this DSN. This field MUST appear in any DSN that was translated by a
719 gateway from a foreign system into DSN format, and MUST NOT appear
720 otherwise.
721
722 dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
723
724 For gateways into Internet mail, the MTA-name-type will normally be
725 "dns", and the mta-name will be the Internet domain name of the
726 gateway.
727
728
729
730Moore & Vaudreuil Standards Track [Page 13]
731
732RFC 3464 Delivery Status Notifications January 2003
733
734
7352.2.4 The Received-From-MTA DSN field ../dsn/dsn.go:235
736
737 The optional Received-From-MTA field indicates the name of the MTA
738 from which the message was received.
739
740 received-from-mta-field =
741 "Received-From-MTA" ":" mta-name-type ";" mta-name
742
743 If the message was received from an Internet host via SMTP, the
744 contents of the mta-name sub-field SHOULD be the Internet domain name
745 supplied in the HELO or EHLO command, and the network address used by
746 the SMTP client SHOULD be included as a comment enclosed in
747 parentheses. (In this case, the MTA-name-type will be "dns".)
748
749 The mta-name portion of the Received-From-MTA field is formatted
750 according to the conventions indicated by the MTA-name-type sub-
751 field.
752
753 Since case is significant in some mail systems, the exact spelling,
754 including case, of the MTA name SHOULD be preserved.
755
7562.2.5 The Arrival-Date DSN field
757
758 The optional Arrival-Date field indicates the date and time at which ../dsn/dsn.go:238
759 the message arrived at the Reporting MTA. If the Last-Attempt-Date
760 field is also provided in a per-recipient field, this can be used to
761 determine the interval between when the message arrived at the
762 Reporting MTA and when the report was issued for that recipient.
763
764 arrival-date-field = "Arrival-Date" ":" date-time
765
766 The date and time are expressed in RFC 822 'date-time' format, as
767 modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be
768 used.
769 ../dsn/dsn.go:244
7702.3 Per-Recipient DSN fields
771
772 A DSN contains information about attempts to deliver a message to one
773 or more recipients. The delivery information for any particular
774 recipient is contained in a group of contiguous per-recipient fields.
775 Each group of per-recipient fields is preceded by a blank line.
776
777
778
779
780
781
782
783
784
785
786Moore & Vaudreuil Standards Track [Page 14]
787
788RFC 3464 Delivery Status Notifications January 2003
789
790
791 The syntax for the group of per-recipient fields is as follows:
792
793 per-recipient-fields =
794 [ original-recipient-field CRLF ]
795 final-recipient-field CRLF
796 action-field CRLF
797 status-field CRLF
798 [ remote-mta-field CRLF ]
799 [ diagnostic-code-field CRLF ]
800 [ last-attempt-date-field CRLF ]
801 [ final-log-id-field CRLF ]
802 [ will-retry-until-field CRLF ]
803 *( extension-field CRLF )
804
8052.3.1 Original-Recipient field
806
807 The Original-Recipient field indicates the original recipient address ../dsn/dsn.go:256
808 as specified by the sender of the message for which the DSN is being
809 issued.
810
811 original-recipient-field =
812 "Original-Recipient" ":" address-type ";" generic-address
813
814 generic-address = *text
815
816 The address-type field indicates the type of the original recipient
817 address. If the message originated within the Internet, the
818 address-type field will normally be "rfc822", and the address will be
819 according to the syntax specified in [RFC822]. The value "unknown" todo: ../dsn/dsn.go:245
820 should be used if the Reporting MTA cannot determine the type of the
821 original recipient address from the message envelope.
822
823 This field is optional. It should be included only if the sender-
824 specified recipient address was present in the message envelope, such
825 as by the SMTP extensions defined in [DRPT]. This address is the
826 same as that provided by the sender and can be used to automatically
827 correlate DSN reports and message transactions.
828
8292.3.2 Final-Recipient field ../dsn/dsn.go:259
830
831 The Final-Recipient field indicates the recipient for which this set
832 of per-recipient fields applies. This field MUST be present in each
833 set of per-recipient data.
834
835
836
837
838
839
840
841
842Moore & Vaudreuil Standards Track [Page 15]
843
844RFC 3464 Delivery Status Notifications January 2003
845
846
847 The syntax of the field is as follows:
848
849 final-recipient-field =
850 "Final-Recipient" ":" address-type ";" generic-address
851
852 The generic-address sub-field of the Final-Recipient field MUST
853 contain the mailbox address of the recipient (from the transport
854 envelope), as it was when the Reporting MTA accepted the message for
855 delivery.
856
857 The Final-Recipient address may differ from the address originally
858 provided by the sender, because it may have been transformed during
859 forwarding and gatewaying into a totally unrecognizable mess.
860 However, in the absence of the optional Original-Recipient field, the
861 Final-Recipient field and any returned content may be the only
862 information available with which to correlate the DSN with a
863 particular message submission.
864
865 The address-type sub-field indicates the type of address expected by
866 the reporting MTA in that context. Recipient addresses obtained via
867 SMTP will normally be of address-type "rfc822".
868
869 NOTE: The Reporting MTA is not expected to ensure that the address
870 actually conforms to the syntax conventions of the address-type.
871 Instead, it MUST report exactly the address received in the envelope,
872 unless that address contains characters such as CR or LF which are
873 not allowed in a DSN field.
874
875 Since mailbox addresses (including those used in the Internet) may be
876 case sensitive, the case of alphabetic characters in the address MUST
877 be preserved.
878
8792.3.3 Action field ../dsn/dsn.go:260
880
881 The Action field indicates the action performed by the Reporting-MTA
882 as a result of its attempt to deliver the message to this recipient
883 address. This field MUST be present for each recipient named in the
884 DSN.
885
886 The syntax for the action-field is:
887
888 action-field = "Action" ":" action-value
889
890 action-value = ../dsn/dsn.go:83
891 "failed" / "delayed" / "delivered" / "relayed" / "expanded"
892
893 The action-value may be spelled in any combination of upper and lower
894 case characters.
895
896
897
898Moore & Vaudreuil Standards Track [Page 16]
899
900RFC 3464 Delivery Status Notifications January 2003
901
902
903 "failed" indicates that the message could not be delivered to the
904 recipient. The Reporting MTA has abandoned any attempts
905 to deliver the message to this recipient. No further
906 notifications should be expected.
907
908 "delayed" indicates that the Reporting MTA has so far been unable
909 to deliver or relay the message, but it will continue to
910 attempt to do so. Additional notification messages may
911 be issued as the message is further delayed or
912 successfully delivered, or if delivery attempts are later
913 abandoned.
914
915 "delivered" indicates that the message was successfully delivered to
916 the recipient address specified by the sender, which
917 includes "delivery" to a mailing list exploder. It does
918 not indicate that the message has been read. This is a
919 terminal state and no further DSN for this recipient
920 should be expected.
921
922
923 "relayed" indicates that the message has been relayed or gatewayed
924 into an environment that does not accept responsibility
925 for generating DSNs upon successful delivery. This
926 action-value SHOULD NOT be used unless the sender has
927 requested notification of successful delivery for this
928 recipient.
929
930 "expanded" indicates that the message has been successfully
931 delivered to the recipient address as specified by the
932 sender, and forwarded by the Reporting-MTA beyond that
933 destination to multiple additional recipient addresses.
934 An action-value of "expanded" differs from "delivered" in
935 that "expanded" is not a terminal state. Further
936 "failed" and/or "delayed" notifications may be provided.
937
938 Using the terms "mailing list" and "alias" as defined in [DRPT],
939 section 7.2.7: An action-value of "expanded" is only to be used when
940 the message is delivered to a multiple-recipient "alias". An
941 action-value of "expanded" SHOULD NOT be used with a DSN issued on
942 delivery of a message to a "mailing list".
943
944 NOTE ON ACTION VS. STATUS CODES: Although the 'action' field ../dsn/dsn.go:263
945 might seem to be redundant with the 'status' field, this is not
946 the case. In particular, a "temporary failure" ("4") status code
947 could be used with an action-value of either "delayed" or
948 "failed". For example, assume that an SMTP client repeatedly
949 tries to relay a message to the mail exchanger for a recipient,
950 but fails because a query to a domain name server timed out.
951
952
953
954Moore & Vaudreuil Standards Track [Page 17]
955
956RFC 3464 Delivery Status Notifications January 2003
957
958
959 After a few hours, it might issue a "delayed" DSN to inform the
960 sender that the message had not yet been delivered. After a few
961 days, the MTA might abandon its attempt to deliver the message
962 and return a "failed" DSN. The status code (which would begin
963 with a "4" to indicate "temporary failure") would be the same for
964 both DSNs.
965
966 Another example for which the action and status codes may appear
967 contradictory: If an MTA or mail gateway cannot deliver a message
968 because doing so would entail conversions resulting in an
969 unacceptable loss of information, it would issue a DSN with the
970 'action' field of "failure" and a status code of 'XXX'. If the
971 message had instead been relayed, but with some loss of
972 information, it might generate a DSN with the same XXX status-
973 code, but with an action field of "relayed".
974
9752.3.4 Status field ../dsn/dsn.go:279
976
977 The per-recipient Status field contains a transport-independent
978 status code that indicates the delivery status of the message to that
979 recipient. This field MUST be present for each delivery attempt
980 which is described by a DSN.
981
982 The syntax of the status field is:
983
984 status-field = "Status" ":" status-code
985
986 status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
987
988 ; White-space characters and comments are NOT allowed within
989 ; a status-code, though a comment enclosed in parentheses
990 ; MAY follow the last numeric sub-field of the status-code.
991 ; Each numeric sub-field within the status-code MUST be
992 ; expressed without leading zero digits.
993
994 Status codes thus consist of three numerical fields separated by ".".
995 The first sub-field indicates whether the delivery attempt was
996 successful (2= success, 4 = persistent temporary failure, 5 =
997 permanent failure). The second sub-field indicates the probable
998 source of any delivery anomalies, and the third sub-field denotes a
999 precise error condition, if known.
1000
1001 The initial set of status-codes is defined in [STATUS].
1002
1003
1004
1005
1006
1007
1008
1009
1010Moore & Vaudreuil Standards Track [Page 18]
1011
1012RFC 3464 Delivery Status Notifications January 2003
1013
1014
10152.3.5 Remote-MTA field ../dsn/dsn.go:281
1016
1017 The value associated with the Remote-MTA DSN field is a printable
1018 ASCII representation of the name of the "remote" MTA that reported
1019 delivery status to the "reporting" MTA.
1020
1021 remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
1022
1023 NOTE: The Remote-MTA field preserves the "while talking to"
1024 information that was provided in some pre-existing nondelivery
1025 reports.
1026
1027 This field is optional. It MUST NOT be included if no remote MTA was ../queue/queue.go:1390
1028 involved in the attempted delivery of the message to that recipient.
1029
10302.3.6 Diagnostic-Code field
1031
1032 For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field
1033 contains the actual diagnostic code issued by the mail transport.
1034 Since such codes vary from one mail transport to another, the
1035 diagnostic-type sub-field is needed to specify which type of
1036 diagnostic code is represented.
1037
1038 diagnostic-code-field =
1039 "Diagnostic-Code" ":" diagnostic-type ";" *text
1040
1041 NOTE: The information in the Diagnostic-Code field may be somewhat
1042 redundant with that from the Status field. The Status field is
1043 needed so that any DSN, regardless of origin, may be understood by
1044 any user agent or gateway that parses DSNs. Since the Status code
1045 will sometimes be less precise than the actual transport diagnostic
1046 code, the Diagnostic-Code field is provided to retain the latter
1047 information. Such information may be useful in a trouble ticket sent
1048 to the administrator of the Reporting MTA, or when tunneling foreign
1049 non-delivery reports through DSNs.
1050
1051 If the Diagnostic Code was obtained from a Remote MTA during an
1052 attempt to relay the message to that MTA, the Remote-MTA field should
1053 be present. When interpreting a DSN, the presence of a Remote-MTA ../dsn/dsn.go:288
1054 field indicates that the Diagnostic Code was issued by the Remote
1055 MTA. The absence of a Remote-MTA indicates that the Diagnostic Code
1056 was issued by the Reporting MTA.
1057
1058 In addition to the Diagnostic-Code itself, additional textual
1059 description of the diagnostic, MAY appear in a comment enclosed in
1060 parentheses.
1061
1062
1063
1064
1065
1066Moore & Vaudreuil Standards Track [Page 19]
1067
1068RFC 3464 Delivery Status Notifications January 2003
1069
1070
1071 This field is optional, because some mail systems supply no
1072 additional information beyond that which is returned in the 'action'
1073 and 'status' fields. However, this field SHOULD be included if
1074 transport-specific diagnostic information is available.
1075
10762.3.7 Last-Attempt-Date field ../dsn/dsn.go:294
1077
1078 The Last-Attempt-Date field gives the date and time of the last
1079 attempt to relay, gateway, or deliver the message (whether successful
1080 or unsuccessful) by the Reporting MTA. This is not necessarily the
1081 same as the value of the Date field from the header of the message
1082 used to transmit this delivery status notification: In cases where
1083 the DSN was generated by a gateway, the Date field in the message
1084 header contains the time the DSN was sent by the gateway and the DSN
1085 Last-Attempt-Date field contains the time the last delivery attempt
1086 occurred.
1087
1088 last-attempt-date-field = "Last-Attempt-Date" ":" date-time
1089
1090 This field is optional. It MUST NOT be included if the actual date
1091 and time of the last delivery attempt are not available (which might
1092 be the case if the DSN were being issued by a gateway).
1093
1094 The date and time are expressed in RFC 822 'date-time' format, as
1095 modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be
1096 used.
1097
10982.3.8 final-log-id field ../dsn/dsn.go:298
1099
1100 The "final-log-id" field gives the final-log-id of the message that
1101 was used by the final-mta. This can be useful as an index to the
1102 final-mta's log entry for that delivery attempt.
1103
1104 final-log-id-field = "Final-Log-ID" ":" *text
1105
1106 This field is optional.
1107
11082.3.9 Will-Retry-Until field ../dsn/dsn.go:301
1109
1110 For DSNs of type "delayed", the Will-Retry-Until field gives the date
1111 after which the Reporting MTA expects to abandon all attempts to
1112 deliver the message to that recipient. The Will-Retry-Until field is
1113 optional for "delay" DSNs, and MUST NOT appear in other DSNs.
1114
1115 will-retry-until-field = "Will-Retry-Until" ":" date-time
1116
1117
1118
1119
1120
1121
1122Moore & Vaudreuil Standards Track [Page 20]
1123
1124RFC 3464 Delivery Status Notifications January 2003
1125
1126
1127 The date and time are expressed in RFC 822 'date-time' format, as
1128 modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be
1129 used.
1130
11312.4 Extension fields
1132
1133 Additional per-message or per-recipient DSN fields may be defined in
1134 the future by later revisions or extensions to this specification.
1135 Extension-field names beginning with "X-" will never be defined as
1136 standard fields; such names are reserved for experimental use. DSN
1137 field names NOT beginning with "X-" MUST be registered with the
1138 Internet Assigned Numbers Authority (IANA) and published in an RFC.
1139
1140 Extension DSN fields may be defined for the following reasons:
1141
1142 (a) To allow additional information from foreign delivery status
1143 reports to be tunneled through Internet DSNs. The names of such
1144 DSN fields should begin with an indication of the foreign
1145 environment name (e.g., X400-Physical-Forwarding-Address).
1146
1147 (b) To allow the transmission of diagnostic information which is
1148 specific to a particular mail transport protocol. The names of
1149 such DSN fields should begin with an indication of the mail
1150 transport being used (e.g., SMTP-Remote-Recipient-Address). Such
1151 fields should be used for diagnostic purposes only and not by
1152 user agents or mail gateways.
1153
1154 (c) To allow transmission of diagnostic information which is specific
1155 to a particular message transfer agent (MTA). The names of such
1156 DSN fields should begin with an indication of the MTA
1157 implementation that produced the DSN. (e.g., Foomail-Queue-ID).
1158
1159 MTA implementers are encouraged to provide adequate information, via
1160 extension fields if necessary, to allow an MTA maintainer to
1161 understand the nature of correctable delivery failures and how to fix
1162 them. For example, if message delivery attempts are logged, the DSN
1163 might include information that allows the MTA maintainer to easily
1164 find the log entry for a failed delivery attempt.
1165
1166 If an MTA developer does not wish to register the meanings of such
1167 extension fields, "X-" fields may be used for this purpose. To avoid
1168 name collisions, the name of the MTA implementation should follow the
1169 "X-", (e.g., "X-Foomail-Log-ID").
1170
1171
1172
1173
1174
1175
1176
1177
1178Moore & Vaudreuil Standards Track [Page 21]
1179
1180RFC 3464 Delivery Status Notifications January 2003
1181
1182
11833. Conformance and Usage Requirements
1184
1185 An MTA or gateway conforms to this specification if it generates DSNs
1186 according to the protocol defined in this memo. For MTAs and
1187 gateways that do not support requests for positive delivery
1188 notification (such as in [DRPT]), it is sufficient that delivery
1189 failure reports use this protocol.
1190
1191 A minimal implementation of this specification need generate only the
1192 Reporting-MTA per-message field, and the Final-Recipient, Action, and
1193 Status fields for each attempt to deliver a message to a recipient
1194 described by the DSN. Generation of the other fields, when
1195 appropriate, is strongly recommended.
1196
1197 MTAs and gateways MUST NOT generate the Original-Recipient field of a ../dsn/dsn.go:110
1198 DSN unless the mail transfer protocol provides the address originally
1199 specified by the sender at the time of submission. (Ordinary SMTP
1200 does not make that guarantee, but the SMTP extension defined in
1201 [DRPT] permits such information to be carried in the envelope if it
1202 is available.)
1203
1204 Each sender-specified recipient address SHOULD result in at most one
1205 "delivered" or "failed" DSN for that recipient. If a positive DSN is
1206 requested (e.g., one using NOTIFY=SUCCESS in SMTP) for a recipient
1207 that is forwarded to multiple recipients of an "alias" (as defined in
1208 [DRPT], section 7.2.7), the forwarding MTA SHOULD normally issue a
1209 "expanded" DSN for the originally-specified recipient and not
1210 propagate the request for a DSN to the forwarding addresses.
1211 Alternatively, the forwarding MTA MAY relay the request for a DSN to
1212 exactly one of the forwarding addresses and not propagate the request
1213 to the others.
1214
1215 By contrast, successful submission of a message to a mailing list
1216 exploder is considered final delivery of the message. Upon delivery
1217 of a message to a recipient address corresponding to a mailing list
1218 exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly
1219 as if the recipient address were that of an ordinary mailbox.
1220
1221 NOTE: This is actually intended to make DSNs usable by mailing
1222 lists themselves. Any message sent to a mailing list subscriber
1223 should have its envelope return address pointing to the list
1224 maintainer [see RFC 1123, section 5.3.7(E)]. Since DSNs are sent
1225 to the envelope return address, all DSNs resulting from delivery
1226 to the recipients of a mailing list will be sent to the list
1227 maintainer. The list maintainer may elect to mechanically
1228 process DSNs upon receipt, and thus automatically delete invalid
1229 addresses from the list. (See section 7 of this memo.)
1230
1231
1232
1233
1234Moore & Vaudreuil Standards Track [Page 22]
1235
1236RFC 3464 Delivery Status Notifications January 2003
1237
1238
1239 This specification places no restrictions on the processing of DSNs
1240 received by user agents or distribution lists.
1241
12424. Security Considerations
1243
1244 The following security considerations apply when using DSNs:
1245
12464.1 Forgery
1247
1248 DSNs may be forged as easily as ordinary Internet electronic mail.
1249 User agents and automatic mail handling facilities (such as mail
1250 distribution list exploders) that wish to make automatic use of DSNs
1251 should take appropriate precautions to minimize the potential damage
1252 from denial-of-service attacks.
1253
1254 Security threats related to forged DSNs include the sending of:
1255
1256 (a) A falsified delivery notification when the message is not
1257 delivered to the indicated recipient,
1258
1259 (b) A falsified non-delivery notification when the message was in
1260 fact delivered to the indicated recipient,
1261
1262 (c) A falsified Final-Recipient address,
1263
1264 (d) A falsified Remote-MTA identification,
1265
1266 (e) A falsified relay notification when the message is "dead ended".
1267
1268 (f) Unsolicited DSNs
1269
12704.2 Confidentiality
1271
1272 Another dimension of security is confidentiality. There may be cases
1273 in which a message recipient is autoforwarding messages but does not
1274 wish to divulge the address to which the messages are autoforwarded.
1275 The desire for such confidentiality will probably be heightened as
1276 "wireless mailboxes", such as pagers, become more widely used as
1277 autoforward addresses.
1278
1279 MTA authors are encouraged to provide a mechanism which enables the
1280 end user to preserve the confidentiality of a forwarding address.
1281 Depending on the degree of confidentiality required, and the nature
1282 of the environment to which a message were being forwarded, this
1283 might be accomplished by one or more of:
1284
1285
1286
1287
1288
1289
1290Moore & Vaudreuil Standards Track [Page 23]
1291
1292RFC 3464 Delivery Status Notifications January 2003
1293
1294
1295 (a) issuing a "relayed" DSN (if a positive DSN was requested) when a
1296 message is forwarded to a confidential forwarding address, and
1297 disabling requests for positive DSNs for the forwarded message,
1298
1299 (b) declaring the message to be delivered, issuing a "delivered" DSN,
1300 re-sending the message to the confidential forwarding address,
1301 and arranging for no DSNs to be issued for the re-sent message,
1302
1303 (c) omitting "Remote-*" or extension fields of a DSN whenever they
1304 would otherwise contain confidential information (such as a
1305 confidential forwarding address),
1306
1307 (d) for messages forwarded to a confidential address, setting the
1308 envelope return address (e.g., SMTP MAIL FROM address) to the
1309 NULL reverse-path ("<>") (so that no DSNs would be sent from a
1310 downstream MTA to the original sender),
1311
1312 (e) for messages forwarded to a confidential address, disabling
1313 delivery notifications for the forwarded message (e.g., if the
1314 "next-hop" MTA uses ESMTP and supports the DSN extension, by
1315 using the NOTIFY=NEVER parameter to the RCPT command), or
1316
1317 (f) when forwarding mail to a confidential address, having the
1318 forwarding MTA rewrite the envelope return address for the
1319 forwarded message and attempt delivery of that message as if the
1320 forwarding MTA were the originator. On its receipt of final
1321 delivery status, the forwarding MTA would issue a DSN to the
1322 original sender.
1323
1324 In general, any optional DSN field may be omitted if the Reporting
1325 MTA site determines that inclusion of the field would impose too
1326 great a compromise of site confidentiality. The need for such
1327 confidentiality must be balanced against the utility of the omitted
1328 information in trouble reports and DSNs gatewayed to foreign
1329 environments.
1330
1331 Implementers are cautioned that many existing MTAs will send non-
1332 delivery notifications to a return address in the message header
1333 (rather than to the one in the envelope), in violation of SMTP and
1334 other protocols. If a message is forwarded through such an MTA, no
1335 reasonable action on the part of the forwarding MTA will prevent the
1336 downstream MTA from compromising the forwarding address. Likewise,
1337 if the recipient's MTA automatically responds to messages based on a
1338 request in the message header (such as the nonstandard, but widely
1339 used, Return-Receipt-To extension header), it will also compromise
1340 the forwarding address.
1341
1342
1343
1344
1345
1346Moore & Vaudreuil Standards Track [Page 24]
1347
1348RFC 3464 Delivery Status Notifications January 2003
1349
1350
13514.3 Non-Repudiation
1352
1353 Within the framework of today's internet mail, the DSNs defined in
1354 this memo provide valuable information to the mail user; however,
1355 even a "failed" DSN can not be relied upon as a guarantee that a
1356 message was not received by the recipient. Even if DSNs are not
1357 actively forged, conditions exist under which a message can be
1358 delivered despite the fact that a failure DSN was issued.
1359
1360 For example, a race condition in the SMTP protocol allows for the
1361 duplication of messages if the connection is dropped following a
1362 completed DATA command, but before a response is seen by the SMTP
1363 client.
1364
1365 This will cause the SMTP client to retransmit the message, even
1366 though the SMTP server has already accepted it [SMTPDUP]. If one of
1367 those delivery attempts succeeds and the other one fails, a "failed"
1368 DSN could be issued even though the message actually reached the
1369 recipient.
1370
13715. Normative References
1372
1373 [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
1374 Notifications", RFC 3461, January 2003.
1375
1376 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
1377 for Delivery Status Notifications", RFC 1894, January 1996.
1378
1379 [HOSTREQ] Braden, R. (ed.), "Requirements for Internet Hosts -
1380 Application and Support", STD 3, RFC 1123, October 1989.
1381
1382 [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1383 Extensions (MIME) Part One: Format of Internet Message
1384 Bodies", RFC 2045, November 1996.
1385
1386 [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
1387 Part Three: Message Header Extensions for Non-ASCII Text",
1388 RFC 2047, November 1996.
1389
1390 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
1391 Reporting of Mail System Administrative Messages", RFC
1392 3462, January 2003.
1393
1394 [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
1395 Messages", STD 11, RFC 822, August 1982.
1396
1397 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
1398 821, August 1982.
1399
1400
1401
1402Moore & Vaudreuil Standards Track [Page 25]
1403
1404RFC 3464 Delivery Status Notifications January 2003
1405
1406
1407 [SMTPDUP] Partridge, C., "Duplicate Messages and SMTP", RFC 1047,
1408 February 1988.
1409
1410 [STATUS] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
1411 3463, January 2003.
1412
1413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1414 Requirement Levels", BCP 14, RFC 2119, March 1997.
1415
14166. Acknowledgments
1417
1418 The authors wish to thank the following people for their reviews of
1419 early drafts of RFC 1894, of which this document is a revision, and
1420 their suggestions for improvement: Eric Allman, Harald Alvestrand,
1421 Allan Cargille, Jim Conklin, Peter Cowen, Dave Crocker, Roger Fajman,
1422 Ned Freed, Marko Kaittola, Steve Kille, John Klensin, John Gardiner
1423 Myers, Mark Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy,
1424 and Gregory Sheehan.
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458Moore & Vaudreuil Standards Track [Page 26]
1459
1460RFC 3464 Delivery Status Notifications January 2003
1461
1462
1463Appendix A - collected grammar
1464
1465 NOTE: The following lexical tokens are defined in RFC 822: atom,
1466 CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text.
1467 The date-time lexical token is defined in [HOSTREQ].
1468
1469 action-field = "Action" ":" action-value
1470
1471 action-value = "failed" / "delayed" / "delivered"
1472 / "relayed" / "expanded"
1473
1474 address-type = atom
1475
1476 arrival-date-field = "Arrival-Date" ":" date-time
1477
1478 delivery-status-content = per-message-fields
1479 1*( CRLF per-recipient-fields )
1480
1481 diagnostic-code-field = "Diagnostic-Code" ":"
1482 diagnostic-type ";" *text
1483
1484 diagnostic-type = atom
1485
1486 dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
1487
1488 envelope-id = *text
1489
1490 extension-field = extension-field-name ":" *text
1491
1492 extension-field-name = atom
1493
1494 final-recipient-field =
1495 "Final-Recipient" ":" address-type ";" generic-address
1496
1497 final-log-id-field = "Final-Log-ID" ":" *text
1498
1499 generic-address = *text
1500
1501 last-attempt-date-field = "Last-Attempt-Date" ":" date-time
1502
1503 mta-name = *text
1504
1505 mta-name-type = atom
1506
1507 original-envelope-id-field =
1508 "Original-Envelope-Id" ":" envelope-id
1509
1510
1511
1512
1513
1514Moore & Vaudreuil Standards Track [Page 27]
1515
1516RFC 3464 Delivery Status Notifications January 2003
1517
1518
1519 original-recipient-field =
1520 "Original-Recipient" ":" address-type ";" generic-address
1521
1522 per-message-fields = 6533:366 ../dsn/parse.go:124
1523 [ original-envelope-id-field CRLF ]
1524 reporting-mta-field CRLF
1525 [ dsn-gateway-field CRLF ]
1526 [ received-from-mta-field CRLF ]
1527 [ arrival-date-field CRLF ]
1528 *( extension-field CRLF )
1529
1530 per-recipient-fields = 6533:370 ../dsn/dsn.go:93 ../dsn/parse.go:197
1531 [ original-recipient-field CRLF ]
1532 final-recipient-field CRLF
1533 action-field CRLF
1534 status-field CRLF
1535 [ remote-mta-field CRLF ]
1536 [ diagnostic-code-field CRLF ]
1537 [ last-attempt-date-field CRLF ]
1538 [ final-log-id-field CRLF ]
1539 [ will-retry-until-field CRLF ]
1540 *( extension-field CRLF )
1541
1542 received-from-mta-field =
1543 "Received-From-MTA" ":" mta-name-type ";" mta-name
1544
1545 remote-mta-field =
1546 "Remote-MTA" ":" mta-name-type ";" mta-name
1547
1548 reporting-mta-field =
1549 "Reporting-MTA" ":" mta-name-type ";" mta-name
1550
1551 status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
1552
1553 ; White-space characters and comments are NOT allowed within a
1554 ; a status-code, though a comment enclosed in parentheses
1555 ; MAY follow the last numeric sub-field of the status-code.
1556 ; Each numeric sub-field within the status-code MUST be
1557 ; expressed without leading zero digits.
1558
1559 status-field = "Status" ":" status-code
1560
1561 will-retry-until-field = "Will-Retry-Until" ":" date-time
1562
1563
1564
1565
1566
1567
1568
1569
1570Moore & Vaudreuil Standards Track [Page 28]
1571
1572RFC 3464 Delivery Status Notifications January 2003
1573
1574
1575Appendix B - Guidelines for gatewaying DSNs
1576
1577 NOTE: This section provides non-binding recommendations for the
1578 construction of mail gateways that wish to provide semi-transparent
1579 delivery reports between the Internet and another electronic mail
1580 system. Specific DSN gateway requirements for a particular pair of
1581 mail systems may be defined by other documents.
1582
1583Gatewaying from other mail systems to DSNs
1584
1585 A mail gateway may issue a DSN to convey the contents of a "foreign"
1586 delivery or non-delivery notification over Internet mail. When there
1587 are appropriate mappings from the foreign notification elements to
1588 DSN fields, the information may be transmitted in those DSN fields.
1589 Additional information (such as might be useful in a trouble ticket
1590 or needed to tunnel the foreign notification through the Internet)
1591 may be defined in extension DSN fields. (Such fields should be given
1592 names that identify the foreign mail protocol, e.g., X400-* for X.400
1593 NDN or DN protocol elements)
1594
1595 The gateway must attempt to supply reasonable values for the
1596 Reporting-MTA, Final-Recipient, Action, and Status fields. These
1597 will normally be obtained by translating the values from the remote
1598 delivery or non-delivery notification into their Internet-style
1599 equivalents. However, some loss of information is to be expected.
1600 For example, the set of status-codes defined for DSNs may not be
1601 adequate to fully convey the delivery diagnostic code from the
1602 foreign system. The gateway should assign the most precise code
1603 which describes the failure condition, falling back on "generic"
1604 codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0
1605 (permanent failure) when necessary. The actual foreign diagnostic
1606 code should be retained in the Diagnostic-Code field (with an
1607 appropriate diagnostic-type value) for use in trouble tickets or
1608 tunneling.
1609
1610 The sender-specified recipient address, and the original envelope-id,
1611 if present in the foreign transport envelope, should be preserved in
1612 the Original-Recipient and Original-Envelope-ID fields.
1613
1614 The gateway should also attempt to preserve the "final" recipient
1615 addresses and MTA names from the foreign system. Whenever possible,
1616 foreign protocol elements should be encoded as meaningful printable
1617 ASCII strings.
1618
1619 For DSNs produced from foreign delivery or nondelivery notifications,
1620 the name of the gateway MUST appear in the DSN-Gateway field of the
1621 DSN.
1622
1623
1624
1625
1626Moore & Vaudreuil Standards Track [Page 29]
1627
1628RFC 3464 Delivery Status Notifications January 2003
1629
1630
1631Gatewaying from DSNs to other mail systems
1632
1633 It may be possible to gateway DSNs from the Internet into a foreign
1634 mail system. The primary purpose of such gatewaying is to convey
1635 delivery status information in a form that is usable by the
1636 destination system. A secondary purpose is to allow "tunneling" of
1637 DSNs through foreign mail systems, in case the DSN may be gatewayed
1638 back into the Internet.
1639
1640 In general, the recipient of the DSN (i.e., the sender of the
1641 original message) will want to know, for each recipient: the closest
1642 available approximation to the original recipient address, the
1643 delivery status (success, failure, or temporary failure), and for
1644 failed deliveries, a diagnostic code that describes the reason for
1645 the failure.
1646
1647 If possible, the gateway should attempt to preserve the Original-
1648 Recipient address and Original-Envelope-ID (if present), in the
1649 resulting foreign delivery status report.
1650
1651 When reporting delivery failures, if the diagnostic-type sub-field of
1652 the Diagnostic-Code field indicates that the original diagnostic code
1653 is understood by the destination environment, the information from
1654 the Diagnostic-Code field should be used. Failing that, the
1655 information in the Status field should be mapped into the closest
1656 available diagnostic code used in the destination environment.
1657
1658 If it is possible to tunnel a DSN through the destination
1659 environment, the gateway specification may define a means of
1660 preserving the DSN information in the delivery status reports used by
1661 that environment.
1662
1663Appendix C - Guidelines for use of DSNs by mailing list exploders
1664
1665 This section pertains only to the use of DSNs by "mailing lists" as
1666 defined in [4], section 7.2.7.
1667
1668 DSNs are designed to be used by mailing list exploders to allow them
1669 to detect and automatically delete recipients for whom mail delivery
1670 fails repeatedly.
1671
1672 When forwarding a message to list subscribers, the mailing list
1673 exploder should always set the envelope return address (e.g., SMTP
1674 MAIL FROM address) to point to a special address which is set up to
1675 receive non-delivery reports. A "smart" mailing list exploder can
1676 therefore intercept such non-delivery reports, and if they are in the
1677 DSN format, automatically examine them to determine for which
1678 recipients a message delivery failed or was delayed.
1679
1680
1681
1682Moore & Vaudreuil Standards Track [Page 30]
1683
1684RFC 3464 Delivery Status Notifications January 2003
1685
1686
1687 The Original-Recipient field should be used if available, since it
1688 should exactly match the subscriber address known to the list. If
1689 the Original-Recipient field is not available, the recipient field
1690 may resemble the list subscriber address. Often, however, the list
1691 subscriber will have forwarded his mail to a different address, or
1692 the address may be subject to some re-writing, so heuristics may be
1693 required to successfully match an address from the recipient field.
1694 Care is needed in this case to minimize the possibility of false
1695 matches.
1696
1697 The reason for delivery failure can be obtained from the Status and
1698 Action fields, and from the Diagnostic-Code field (if the status-type
1699 is recognized). Reports for recipients with action values other than
1700 "failed" can generally be ignored; in particular, subscribers should
1701 not be removed from a list due to "delayed" reports.
1702
1703 In general, almost any failure status code (even a "permanent" one)
1704 can result from a temporary condition. It is therefore recommended
1705 that a list exploder not delete a subscriber based on any single
1706 failure DSN (regardless of the status code), but only on the
1707 persistence of delivery failure over a period of time.
1708
1709 However, some kinds of failures are less likely than others to have
1710 been caused by temporary conditions, and some kinds of failures are
1711 more likely to be noticed and corrected quickly than others. Once
1712 more precise status codes are defined, it may be useful to
1713 differentiate between the status codes when deciding whether to
1714 delete a subscriber. For example, on a list with a high message
1715 volume, it might be desirable to temporarily suspend delivery to a
1716 recipient address which causes repeated "temporary" failures, rather
1717 than simply deleting the recipient. The duration of the suspension
1718 might depend on the type of error. On the other hand, a "user
1719 unknown" error that persisted for several days could be considered a
1720 reliable indication that address were no longer valid.
1721
1722Appendix D - IANA registration forms for DSN types
1723
1724 The forms below are for use when registering a new address-type,
1725 diagnostic-type, or MTA-name-type with the Internet Assigned Numbers
1726 Authority (IANA). Each piece of information requested by a
1727 registration form may be satisfied either by providing the
1728 information on the form itself, or by including a reference to a
1729 published, publicly available specification which includes the
1730 necessary information. IANA MAY reject DSN type registrations
1731 because of incomplete registration forms, imprecise specifications,
1732 or inappropriate type names.
1733
1734
1735
1736
1737
1738Moore & Vaudreuil Standards Track [Page 31]
1739
1740RFC 3464 Delivery Status Notifications January 2003
1741
1742
1743 To register a DSN type, complete the applicable form below and send
1744 it via Internet electronic mail to <IANA@IANA.ORG>.
1745
1746IANA registration form for address-type
1747
1748 A registration for a DSN address-type MUST include the following
1749 information:
1750
1751 (a) The proposed address-type name.
1752
1753 (b) The syntax for mailbox addresses of this type, specified using
1754 BNF, regular expressions, ASN.1, or other non-ambiguous language.
1755
1756 (c) If addresses of this type are not composed entirely of graphic
1757 characters from the US-ASCII repertoire, a specification for how
1758 they are to be encoded as graphic US-ASCII characters in a DSN
1759 Original-Recipient or Final-Recipient DSN field.
1760
1761 (d) [optional] A specification for how addresses of this type are to
1762 be translated to and from Internet electronic mail addresses.
1763
1764IANA registration form for diagnostic-type
1765
1766 A registration for a DSN address-type MUST include the following
1767 information:
1768
1769 (a) The proposed diagnostic-type name.
1770
1771 (b) A description of the syntax to be used for expressing diagnostic
1772 codes of this type as graphic characters from the US-ASCII
1773 repertoire.
1774
1775 (c) A list of valid diagnostic codes of this type and the meaning of
1776 each code.
1777
1778 (d) [optional] A specification for mapping from diagnostic codes of
1779 this type to DSN status codes (as defined in [5]).
1780
1781IANA registration form for MTA-name-type
1782
1783 A registration for a DSN MTA-name-type must include the following
1784 information:
1785
1786 (a) The proposed MTA-name-type name.
1787
1788 (b) A description of the syntax of MTA names of this type, using BNF,
1789 regular expressions, ASN.1, or other non-ambiguous language.
1790
1791
1792
1793
1794Moore & Vaudreuil Standards Track [Page 32]
1795
1796RFC 3464 Delivery Status Notifications January 2003
1797
1798
1799 (c) If MTA names of this type do not consist entirely of graphic
1800 characters from the US-ASCII repertoire, a specification for how
1801 an MTA name of this type should be expressed as a sequence of
1802 graphic US-ASCII characters.
1803
1804Appendix E - Examples
1805
1806 These examples are provided as illustration only, and are not
1807 considered part of the DSN protocol specification. If an example
1808 conflicts with the protocol definition above, the example is wrong.
1809
1810 Likewise, the use of *-type sub-field names or extension fields in
1811 these examples is not to be construed as a definition for those type
1812 names or extension fields.
1813
1814 These examples were manually translated from bounced messages using
1815 whatever information was available.
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850Moore & Vaudreuil Standards Track [Page 33]
1851
1852RFC 3464 Delivery Status Notifications January 2003
1853
1854
1855Simple DSN ../dsn/dsn.go:217
1856
1857 This is a simple DSN issued after repeated attempts to deliver a
1858 message failed. In this case, the DSN is issued by the same MTA from
1859 which the message was originated.
1860
1861 Date: Thu, 7 Jul 1994 17:16:05 -0400 From: Mail Delivery Subsystem
1862 <MAILER-DAEMON@CS.UTK.EDU> Message-Id:
1863 <199407072116.RAA14128@CS.UTK.EDU> Subject: Returned mail: Cannot
1864 send message for 5 days To: <owner-info-mime@cs.utk.edu> MIME-
1865 Version: 1.0 Content-Type: multipart/report; report-type=delivery-
1866 status;
1867 boundary="RAA14128.773615765/CS.UTK.EDU"
1868
1869 --RAA14128.773615765/CS.UTK.EDU
1870
1871 The original message was received at Sat, 2 Jul 1994 17:10:28 -0400
1872 from root@localhost
1873
1874 ----- The following addresses had delivery problems -----
1875 <louisl@larry.slip.umd.edu> (unrecoverable error)
1876
1877 ----- Transcript of session follows -----
1878 <louisl@larry.slip.umd.edu>... Deferred: Connection timed out
1879 with larry.slip.umd.edu.
1880 Message could not be delivered for 5 days
1881 Message will be deleted from queue
1882
1883 --RAA14128.773615765/CS.UTK.EDU
1884 content-type: message/delivery-status
1885
1886 Reporting-MTA: dns; cs.utk.edu
1887
1888 Original-Recipient: rfc822;louisl@larry.slip.umd.edu
1889 Final-Recipient: rfc822;louisl@larry.slip.umd.edu
1890 Action: failed
1891 Status: 4.0.0
1892 Diagnostic-Code: smtp; 426 connection timed out
1893 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
1894
1895 --RAA14128.773615765/CS.UTK.EDU
1896 content-type: message/rfc822
1897
1898 [original message goes here]
1899
1900 --RAA14128.773615765/CS.UTK.EDU--
1901
1902
1903
1904
1905
1906Moore & Vaudreuil Standards Track [Page 34]
1907
1908RFC 3464 Delivery Status Notifications January 2003
1909
1910
1911Multi-Recipient DSN
1912
1913 This is another DSN issued by the sender's MTA, which contains
1914 details of multiple delivery attempts. Some of these were detected
1915 locally, and others by a remote MTA.
1916
1917 Date: Fri, 8 Jul 1994 09:21:47 -0400
1918 From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
1919 Subject: Returned mail: User unknown
1920 To: <owner-ups-mib@CS.UTK.EDU>
1921 MIME-Version: 1.0
1922 Content-Type: multipart/report; report-type=delivery-status;
1923 boundary="JAA13167.773673707/CS.UTK.EDU"
1924
1925 --JAA13167.773673707/CS.UTK.EDU
1926 content-type: text/plain; charset=us-ascii
1927
1928 ----- The following addresses had delivery problems -----
1929 <arathib@vnet.ibm.com> (unrecoverable error)
1930 <wsnell@sdcc13.ucsd.edu> (unrecoverable error)
1931
1932 --JAA13167.773673707/CS.UTK.EDU
1933 content-type: message/delivery-status
1934
1935 Reporting-MTA: dns; cs.utk.edu
1936
1937 Original-Recipient: rfc822;arathib@vnet.ibm.com
1938 Final-Recipient: rfc822;arathib@vnet.ibm.com
1939 Action: failed
1940 Status: 5.0.0 (permanent failure)
1941 Diagnostic-Code: smtp; 550 'arathib@vnet.IBM.COM' is not a
1942 registered gateway user
1943 Remote-MTA: dns; vnet.ibm.com
1944
1945 Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com
1946 Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com
1947 Action: delayed
1948 Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)
1949
1950 Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
1951 Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
1952 Action: failed
1953 Status: 5.0.0
1954 Diagnostic-Code: smtp; 550 user unknown
1955 Remote-MTA: dns; sdcc13.ucsd.edu
1956
1957 --JAA13167.773673707/CS.UTK.EDU
1958 content-type: message/rfc822
1959
1960
1961
1962Moore & Vaudreuil Standards Track [Page 35]
1963
1964RFC 3464 Delivery Status Notifications January 2003
1965
1966
1967 [original message goes here]
1968
1969 --JAA13167.773673707/CS.UTK.EDU--
1970
1971DSN from gateway to foreign system
1972
1973 A delivery report generated by Message Router (MAILBUS) and gatewayed
1974 by PMDF_MR to a DSN. In this case the gateway did not have
1975 sufficient information to supply an original-recipient address.
1976
1977 Disclose-recipients: prohibited
1978 Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT)
1979 From: Message Router Submission Agent <AMMGR@corp.timeplex.com>
1980 Subject: Status of: Re: Battery current sense
1981 To: owner-ups-mib@CS.UTK.EDU
1982 Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com>
1983 MIME-version: 1.0
1984 content-type: multipart/report;
1985 report-type=delivery-status;
1986 boundary="84229080704991.122306.SYS30"
1987
1988 --84229080704991.122306.SYS30
1989 content-type: text/plain
1990
1991 Invalid address - nair_s
1992 %DIR-E-NODIRMTCH, No matching Directory Entry
1993 Entry found
1994
1995 --84229080704991.122306.SYS30
1996 content-type: message/delivery-status
1997
1998 Reporting-MTA: mailbus; SYS30
1999
2000 Final-Recipient: unknown; nair_s
2001 Status: 5.0.0 (unknown permanent failure)
2002 Action: failed
2003
2004 --84229080704991.122306.SYS30--
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018Moore & Vaudreuil Standards Track [Page 36]
2019
2020RFC 3464 Delivery Status Notifications January 2003
2021
2022
2023Delayed DSN
2024
2025 A delay report from a multiprotocol MTA. Note that there is no
2026 returned content, so no third body part appears in the DSN.
2027
2028 MIME-Version: 1.0
2029 From: <postmaster@nsfnet-relay.ac.uk>
2030 Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
2031 Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
2032 id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
2033 Sun, 10 Jul 1994 00:36:51 +0100
2034 To: owner-info-mime@cs.utk.edu
2035 Date: Sun, 10 Jul 1994 00:36:51 +0100
2036 Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
2037 content-type: multipart/report; report-type=delivery-status;
2038 boundary=foobar
2039
2040 --foobar
2041 content-type: text/plain
2042
2043 The following message:
2044
2045 UA-ID: Reliable PC (...
2046 Q-ID: sun2.nsf:77/msg.11820-0
2047
2048 has not been delivered to the intended recipient:
2049
2050 thomas@de-montfort.ac.uk
2051
2052 despite repeated delivery attempts over the past 24 hours.
2053
2054 The usual cause of this problem is that the remote system is
2055 temporarily unavailable.
2056
2057 Delivery will continue to be attempted up to a total elapsed time of
2058 168 hours, i.e., 7 days.
2059
2060 You will be informed if delivery proves to be impossible within this
2061 time.
2062
2063 Please quote the Q-ID in any queries regarding this mail.
2064
2065 --foobar
2066 content-type: message/delivery-status
2067
2068 Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk
2069
2070 Final-Recipient: rfc822;thomas@de-montfort.ac.uk
2071
2072
2073
2074Moore & Vaudreuil Standards Track [Page 37]
2075
2076RFC 3464 Delivery Status Notifications January 2003
2077
2078
2079 Status: 4.0.0 (unknown temporary failure)
2080 Action: delayed
2081
2082 --foobar--
2083
2084Appendix F - Changes from RFC 1894
2085
2086 Changed Authors contact information
2087
2088 Updated required standards boilerplate
2089
2090 Edited the text to make it spell-checker and grammar checker
2091 compliant
2092
2093 Updated references to point to later, more mature documents, changed
2094 reference enumeration scheme.
2095
2096 Fixed paragraph numbering on page 20
2097
2098 Fixed Delayed DSN example
2099
2100 Added Table of Contents
2101
2102 Moved Appendices to the end of the document
2103
2104 Changed the MTA-name-Type for gateways into Internet mail, the
2105 MTA-name-type from "SMTP" to "dns".
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130Moore & Vaudreuil Standards Track [Page 38]
2131
2132RFC 3464 Delivery Status Notifications January 2003
2133
2134
2135Authors' Addresses
2136
2137 Keith Moore
2138 University of Tennessee
2139 1122 Volunteer Blvd, Suite 203
2140 Knoxville TN 37996-3450
2141 USA
2142
2143 Phone: +1-865-974-3126
2144 Fax: +1-865-974-8296
2145 EMail: moore@cs.utk.edu
2146
2147
2148 Gregory M. Vaudreuil
2149 Lucent Technologies
2150 7291 Williamson Rd
2151 Dallas, Tx. 75214
2152 USA
2153
2154 Phone: +1 214 823 9325
2155 EMail: GregV@ieee.org
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186Moore & Vaudreuil Standards Track [Page 39]
2187
2188RFC 3464 Delivery Status Notifications January 2003
2189
2190
2191Full Copyright Statement
2192
2193 Copyright (C) The Internet Society (2003). All Rights Reserved.
2194
2195 This document and translations of it may be copied and furnished to
2196 others, and derivative works that comment on or otherwise explain it
2197 or assist in its implementation may be prepared, copied, published
2198 and distributed, in whole or in part, without restriction of any
2199 kind, provided that the above copyright notice and this paragraph are
2200 included on all such copies and derivative works. However, this
2201 document itself may not be modified in any way, such as by removing
2202 the copyright notice or references to the Internet Society or other
2203 Internet organizations, except as needed for the purpose of
2204 developing Internet standards in which case the procedures for
2205 copyrights defined in the Internet Standards process must be
2206 followed, or as required to translate it into languages other than
2207 English.
2208
2209 The limited permissions granted above are perpetual and will not be
2210 revoked by the Internet Society or its successors or assigns.
2211
2212 This document and the information contained herein is provided on an
2213 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2214 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2215 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2216 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2217 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2218
2219Acknowledgement
2220
2221 Funding for the RFC Editor function is currently provided by the
2222 Internet Society.
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242Moore & Vaudreuil Standards Track [Page 40]
2243
2244