1
2
3
4
5
6
7Network Working Group G. Vaudreuil
8Request for Comments: 3462 Lucent Technologies
9Obsoletes: 1892 January 2003
10Category: Standards Track
11
12
13 The Multipart/Report Content Type
14 for the Reporting of
15 Mail System Administrative Messages
16
17Status of this Memo
18
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
24
25Copyright Notice
26
27 Copyright (C) The Internet Society (2003). All Rights Reserved.
28
29Abstract
30
31 The Multipart/Report Multipurpose Internet Mail Extensions (MIME)
32 content-type is a general "family" or "container" type for electronic
33 mail reports of any kind. Although this memo defines only the use of
34 the Multipart/Report content-type with respect to delivery status
35 reports, mail processing programs will benefit if a single content-
36 type is used to for all kinds of reports.
37
38 This document is part of a four document set describing the delivery
39 status report service. This collection includes the Simple Mail
40 Transfer Protocol (SMTP) extensions to request delivery status
41 reports, a MIME content for the reporting of delivery reports, an
42 enumeration of extended status codes, and a multipart container for
43 the delivery report, the original message, and a human-friendly
44 summary of the failure.
45
46
47
48
49
50
51
52
53
54
55
56
57
58Vaudreuil Standards Track [Page 1]
59
60RFC 3462 Multipart/Report January 2003
61
62
63Table of Contents
64
65 Document Conventions................................................2
66 1. The Multipart/Report Content Type................................2
67 2. The Text/RFC822-Headers..........................................4
68 3. Security Considerations..........................................4
69 4. Normative References.............................................5
70 Appendix A - Changes from RFC 1893..................................6
71 Author's Address....................................................6
72 Full Copyright Statement............................................7
73
74Document Conventions
75
76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
78 document are to be interpreted as described in BCP 14, RFC 2119
79 [RFC2119].
80
811. The Multipart/Report Content Type
82
83 The Multipart/Report MIME content-type is a general "family" or
84 "container" type for electronic mail reports of any kind. Although
85 this memo defines only the use of the Multipart/Report content-type
86 with respect to delivery status reports, mail processing programs
87 will benefit if a single content-type is used to for all kinds of
88 reports.
89
90 The Multipart/Report content-type is defined as follows:
91
92 MIME type name: multipart
93 MIME subtype name: report
94 Required parameters: boundary, report-type
95 Optional parameters: none
96 Encoding considerations: 7bit should always be adequate
97 Security considerations: see section 3 of this memo
98
99 The syntax of Multipart/Report is identical to the Multipart/Mixed
100 content type defined in [MIME]. When used to send a report, the
101 Multipart/Report content-type must be the top-level MIME content type
102 for any report message. The report-type parameter identifies the
103 type of report. The parameter is the MIME content sub-type of the
104 second body part of the Multipart/Report.
105
106 User agents and gateways must be able to automatically determine that
107 a message is a mail system report and should be processed as such.
108 Placing the Multipart/Report as the outermost content provides a
109 mechanism whereby an auto-processor may detect through parsing the
110 RFC 822 headers that the message is a report.
111
112
113
114Vaudreuil Standards Track [Page 2]
115
116RFC 3462 Multipart/Report January 2003
117
118
119 The Multipart/Report content-type contains either two or three sub- ../dsn/dsn.go:134
120 parts, in the following order:
121
122 1) [Required] The first body part contains human readable message.
123 The purpose of this message is to provide an easily understood
124 description of the condition(s) that caused the report to be
125 generated, for a human reader who may not have a user agent capable
126 of interpreting the second section of the Multipart/Report.
127
128 The text in the first section may be in any MIME standards-track
129 content-type, charset, or language. Where a description of the error
130 is desired in several languages or several media, a
131 Multipart/Alternative construct may be used.
132
133 This body part may also be used to send detailed information that
134 cannot be easily formatted into a Message/Report body part.
135
136 (2) [Required] A machine parsable body part containing an account of
137 the reported message handling event. The purpose of this body part is
138 to provide a machine-readable description of the condition(s) that
139 caused the report to be generated, along with details not present in
140 the first body part that may be useful to human experts. An initial
141 body part, Message/delivery-status is defined in [DSN].
142
143 (3) [Optional] A body part containing the returned message or a
144 portion thereof. This information may be useful to aid human experts
145 in diagnosing problems. (Although it may also be useful to allow the
146 sender to identify the message which the report was issued, it is
147 hoped that the envelope-id and original-recipient-address returned in
148 the Message/Report body part will replace the traditional use of the
149 returned content for this purpose.)
150
151 Return of content may be wasteful of network bandwidth and a variety
152 of implementation strategies can be used. Generally the sender
153 should choose the appropriate strategy and inform the recipient of
154 the required level of returned content required. In the absence of
155 an explicit request for level of return of content such as that
156 provided in [DRPT], the agent that generated the delivery service
157 report should return the full message content.
158
159 When 8-bit or binary data not encoded in a 7 bit form is to be
160 returned, and the return path is not guaranteed to be 8-bit or binary
161 capable, two options are available. The original message MAY be re-
162 encoded into a legal 7-bit MIME message or the Text/RFC822-Headers
163 content-type MAY be used to return only the original message headers.
164
165
166
167
168
169
170Vaudreuil Standards Track [Page 3]
171
172RFC 3462 Multipart/Report January 2003
173
174
1752. The Text/RFC822-Headers content-type ../dsn/dsn.go:321
176
177 The Text/RFC822-Headers MIME content-type provides a mechanism to
178 label and return only the RFC 822 headers of a failed message. These
179 headers are not the complete message and should not be returned as a
180 Message/RFC822. The returned headers are useful for identifying the
181 failed message and for diagnostics based on the received lines.
182
183 The Text/RFC822-Headers content-type is defined as follows:
184
185 MIME type name: Text
186 MIME subtype name: RFC822-Headers
187 Required parameters: None
188 Optional parameters: None
189 Encoding considerations: 7 bit is sufficient for normal RFC822
190 headers, however, if the headers are broken and require
191 encoding to make them legal 7 bit content, they may be
192 encoded in quoted-printable.
193 Security considerations: See section 3 of this memo.
194
195 The Text/RFC822-Headers body part should contain all the RFC822
196 header lines from the message which caused the report. The RFC822
197 headers include all lines prior to the blank line in the message.
198 They include the MIME-Version and MIME Content-Headers.
199
2003. Security Considerations
201
202 Automated use of report types without authentication presents several
203 security issues. Forging negative reports presents the opportunity
204 for denial-of-service attacks when the reports are used for automated
205 maintenance of directories or mailing lists. Forging positive
206 reports may cause the sender to incorrectly believe a message was
207 delivered when it was not.
208
209 A signature covering the entire multipart/report structure could be
210 used to prevent such forgeries; such a signature scheme is, however,
211 beyond the scope of this document.
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226Vaudreuil Standards Track [Page 4]
227
228RFC 3462 Multipart/Report January 2003
229
230
2314. Normative References
232
233 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
234 821, August 1982.
235
236 [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format
237 for Delivery Status Notifications", RFC 3464, January
238 2003.
239
240 [RFC822] Crocker, D., "Standard for the format of ARPA Internet
241 Text Messages", STD 11, RFC 822, August 1982.
242
243 [MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail
244 Extensions (MIME) Part Two: Media Types", RFC 2046,
245 November 1996.
246
247 [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
248 Notifications", RFC 3461, January 2003.
249
250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
251 Requirement Levels", BCP 14, RFC 2119, March 1997.
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Vaudreuil Standards Track [Page 5]
283
284RFC 3462 Multipart/Report January 2003
285
286
287Appendix A - Changes from RFC 1892
288
289 Changed Authors contact information
290
291 Updated required standards boilerplate
292
293 Edited the text to make it spell-checker and grammar checker
294 compliant
295
296Author's Address
297
298 Gregory M. Vaudreuil
299 Lucent Technologies
300 7291 Williamson Rd
301 Dallas Tx, 75214
302
303 Phone: +1 214 823 9325
304 EMail: GregV@ieee.org
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338Vaudreuil Standards Track [Page 6]
339
340RFC 3462 Multipart/Report January 2003
341
342
343Full Copyright Statement
344
345 Copyright (C) The Internet Society (2003). All Rights Reserved.
346
347 This document and translations of it may be copied and furnished to
348 others, and derivative works that comment on or otherwise explain it
349 or assist in its implementation may be prepared, copied, published
350 and distributed, in whole or in part, without restriction of any
351 kind, provided that the above copyright notice and this paragraph are
352 included on all such copies and derivative works. However, this
353 document itself may not be modified in any way, such as by removing
354 the copyright notice or references to the Internet Society or other
355 Internet organizations, except as needed for the purpose of
356 developing Internet standards in which case the procedures for
357 copyrights defined in the Internet Standards process must be
358 followed, or as required to translate it into languages other than
359 English.
360
361 The limited permissions granted above are perpetual and will not be
362 revoked by the Internet Society or its successors or assigns.
363
364 This document and the information contained herein is provided on an
365 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
366 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
367 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
368 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
369 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
370
371Acknowledgement
372
373 Funding for the RFC Editor function is currently provided by the
374 Internet Society.
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394Vaudreuil Standards Track [Page 7]
395
396