As per Relevance of the word security, we have this rfc below:
Network Working Group G.
Request for Comments: 1892 Octel Network
Category: Standards Track January 1996
The Multipart/Report Content
for the Reporting
Mail System Administrative
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1. The Multipart/Report MIME content-
The Multipart/Report MIME content-type is a general "family"
"container" type for electronic mail reports of any kind.
this memo defines only the use of the Multipart/Report content-
with respect to delivery status reports, mail processing
will benefit if a single content-type is used to for all kinds
reports
The Multipart/Report content-type is defined as follows
MIME type name:
MIME subtype name:
Required parameters: boundary, report-
Optional parameters:
Encoding considerations: 7bit should always be
Security considerations: see section 4 of this memo
The syntax of Multipart/Report is identical to the Multipart/
content type defined in [MIME]. When used to send a report,
Multipart/Report content-type must be the top-level MIME content
for any report message. The report-type parameter identifies
type of report. The parameter is the MIME content sub-type of
second body part of the Multipart/Report
User agents and gateways must be able to automatically
that a message is a mail system report and should be processed
such. Placing the Multipart/Report as the outermost
provides a mechanism whereby an auto-processor may detect
parsing the RFC 822 headers that the message is a report
Vaudreuil Standards Track [Page 1]
RFC 1892 Multipart/Report January 1996
The Multipart/Report content-type contains either two or three sub
parts, in the following order
(1) [required] The first body part contains human readable message
The purpose of this message is to provide an easily-
description of the condition(s) that caused the report to
generated, for a human reader who may not have an user
capable of interpreting the second section of
Multipart/Report
The text in the first section may be in any MIME standards-
content-type, charset, or language. Where a description of
error is desired in several languages or several media,
Multipart/Alternative construct may be used
This body part may also be used to send detailed
that cannot be easily formatted into a Message/Report body part
(2) [required] A machine parsable body part containing an
of the reported message handling event. The purpose of this
part is to provide a machine-readable description of
condition(s) which caused the report to be generated, along
details not present in the first body part that may be useful
human experts. An initial body part, Message/delivery-status
defined in [DSN
(3) [optional] A body part containing the returned message or
portion thereof. This information may be useful to aid
experts in diagnosing problems. (Although it may also be
to allow the sender to identify the message which the report
issued, it is hoped that the envelope-id and original-recipient
address returned in the Message/Report body part will
the traditional use of the returned content for this purpose.)
Return of content may be wasteful of network bandwidth and a
of implementation strategies can be used. Generally the
should choose the appropriate strategy and inform the recipient
the required level of returned content required. In the absence
an explicit request for level of return of content such as
provided in [DRPT], the agent which generated the delivery
report should return the full message content
When data not encoded in 7 bits is to be returned, and the
path is not guaranteed to be 8-bit capable, two options
available. The origional message MAY be reencoded into a legal 7
MIME message or the Text/RFC822-Headers content-type MAY be used
return only the origional message headers
Vaudreuil Standards Track [Page 2]
RFC 1892 Multipart/Report January 1996
2. The Text/RFC822-Headers MIME content-
The Text/RFC822-Headers MIME content-type provides a mechanism
label and return only the RFC 822 headers of a failed message.
headers are not the complete message and should not be returned as
Message/RFC822. The returned headers are useful for identifying
failed message and for diagnostics based on the received: lines
The Text/RFC822-Headers content-type is defined as follows
MIME type name:
MIME subtype name: RFC822-
Required parameters:
Optional parameters:
Encoding considerations: 7 bit is sufficient for normal RFC822
headers, however, if the headers are broken and
encoding, they may be encoded in quoted-printable
Security considerations: see section 4 of this memo
The Text/RFC822-headers body part should contain all the RFC822
header lines from the message which caused the report. The RFC822
headers include all lines prior to the blank line in the message
They include the MIME-Version and MIME Content- headers
3.
[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format
Delivery Status Notifications", RFC 1894, University
Tennessee, Octel Network Services, January 1996.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet
Messages", STD 11, RFC 822, UDEL, August 1982.
[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet
Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
[DRPT] Moore, K., "SMTP Service Extension for Delivery
Notifications", RFC 1891, University of Tennessee, January 1996.
4. Security
Automated use of report types without authentication presents
security issues. Forging negative reports presents the
for denial-of-service attacks when the reports are used for
maintenance of directories or mailing lists. Forging
reports may cause the sender to incorrectly believe a message
delivered when it was not
Vaudreuil Standards Track [Page 3]
RFC 1892 Multipart/Report January 1996
5. Author's
Gregory M.
Octel Network
17060 Dallas
Dallas, TX 75248-1905
Phone: +1-214-733-2722
EMail: Greg.Vaudreuil@Octel.
Vaudreuil Standards Track [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
