doc/rfc3462.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                       G. Vaudreuil
   8 Request for Comments: 3462                           Lucent Technologies
   9 Obsoletes: 1892                                             January 2003
  10 Category: Standards Track
  11
  12
  13                    The Multipart/Report Content Type
  14                          for the Reporting of
  15                   Mail System Administrative Messages
  16
  17 Status 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
  25 Copyright Notice
  26
  27    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  28
  29 Abstract
  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
  58 Vaudreuil                   Standards Track                     [Page 1]
  59 \f
  60 RFC 3462                    Multipart/Report                January 2003
  61
  62
  63 Table 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
  74 Document 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
  81 1. 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
 114 Vaudreuil                   Standards Track                     [Page 2]
 115 \f
 116 RFC 3462                    Multipart/Report                January 2003
 117
 118
 119    The Multipart/Report content-type contains either two or three sub-
 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
 170 Vaudreuil                   Standards Track                     [Page 3]
 171 \f
 172 RFC 3462                    Multipart/Report                January 2003
 173
 174
 175 2. The Text/RFC822-Headers content-type
 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
 200 3. 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
 226 Vaudreuil                   Standards Track                     [Page 4]
 227 \f
 228 RFC 3462                    Multipart/Report                January 2003
 229
 230
 231 4. 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
 282 Vaudreuil                   Standards Track                     [Page 5]
 283 \f
 284 RFC 3462                    Multipart/Report                January 2003
 285
 286
 287 Appendix 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
 296 Author'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
 338 Vaudreuil                   Standards Track                     [Page 6]
 339 \f
 340 RFC 3462                    Multipart/Report                January 2003
 341
 342
 343 Full 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
 371 Acknowledgement
 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
 394 Vaudreuil                   Standards Track                     [Page 7]
 395 \f