WDIFF

draft-shafranovich-feedback-report-00.txt --> draft-shafranovich-feedback-report-01.txt

Network Working Group Y. Shafranovich
Internet-Draft SolidMatrix Technologies, Inc.
Expires: September 2, November 14, 2005 March May 13, 2005

An Extensible Format for Email Feedback Reports
draft-shafranovich-feedback-report-00.txt
draft-shafranovich-feedback-report-01.txt

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667.

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she become becomes
aware will be disclosed, in accordance with
RFC 3668. Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 2, November 14, 2005.

Abstract

This document defines an extensible format and MIME type that may be
used by network operators to report feedback about received email to
other parties. This format is intended as a machine readable
replacement for various existing report formats currently used in
Internet email.

Shafranovich Expires September 2, November 14, 2005 [Page 1]

Internet-Draft Format for Feedback Reports March May 2005

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 4
4. Format of Email Feedback Reports . . . . . . . . . . . . . . 4
5. Format of 'message/feedback-report' Content Type . . . . . . 4 5
5.1 Required Fields . . . . . . . . . . . . . . . . . . . . . 5
5.2 Optional Fields Appearing Once . . . . . . . . . . . . . . 6
5.3 Optional Fields Appearing Multiple Times . . . . . . . . . 6
6. MIME Type Registration of message/feedback-report . . . . . 5 7
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
8. 8
8.1 Initial Values for the Header Names Registry . . . . . . . 9
8.2 Initial values for the "Feedback-Type" registry . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . 6
9. 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 6
10. 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1 11
11.1 Normative References . . . . . . . . . . . . . . . . . . 7
10.2 11
11.2 Informative References . . . . . . . . . . . . . . . . . 7 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 12
A. Appendix A - An Sample Feedback Reports . . . . . . . . . . . . 12
A.1 Simple Report for Email Abuse without Optional Headers . . 12
A.2 Opt-Out Report without Message Body . . . . . . . . . . . 13
A.3 Full Report for Email Abuse with All Headers . . . 8 . . . . 14
B. Status of This Document [To Be Removed Upon Publication] . . 9 16
B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9 16
B.2 Document Repository and Public Website . . . . . . . . . . 16
B.3 Document History . . . . . . . . . . . . 9
B.3 Document History . . . . . . . . . 16
B.4 Outstanding Issues . . . . . . . . . . . . 9 . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . 10 19

Shafranovich Expires September 2, November 14, 2005 [Page 2]

Internet-Draft Format for Feedback Reports March May 2005

1. Introduction

As the spam problem has grown in the past few years, network
operators have begun to exchange abuse reports among themselves and
other parties to combat this problem. However, different operators
define their own formats and the receivers are forced to write custom
software to interpret the many types of them. In addition, many
operators use various other report formats to provide non-abuse
feedback about processed email. This memo seeks to define a standard
extensible format and the "message/feedback-report" MIME type for
these reports in accordance with RFC 2048 [4]. [11]. This format and
content type is intended to be used within the scope of the framework
of the "multipart/report" content type defined in RFC 3462 [1].
While there have been previous work in this area([12] and [13]), none
of them have yet been sucessful. It is hoped that this document will
have a better fate.

This format is intended primarily as an Abuse Reporting Format (ARF)
for reporting email abuse but also includes support for feedback
loops, virus reports and other similar activities.

This document only defines the format and content type to be used for
these reports. Determination of where these reports should be sent sent,
how trust among report senders and receivers is established, and
reports related to more than one message are outside the scope of
this document.

NOTE: This document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].

NOTE: This document may be incomplete and is intented to evolve based
on public discussion and feedback feedback. Readers are encourages to submit
their comments and suggestions.

2. Intent

The reports defined in this document are intended for several
purposes:

o To inform ISPs about email abuse originating from or related to
their networks

o To provide feedback about abuse complaints to email service
providers about abuse
complaints

c. and relevant third parties (such as reputation
providers)

Shafranovich Expires November 14, 2005 [Page 3]

Internet-Draft Format for Feedback Reports May 2005

o To inform the author of the message that the receiver wants to
opt out.

Note email service provides about opt-out requests

Please note that while the reports parent "multipart/report" content type
defined in RFC 3462 [1] is used for all kinds of administrative
messages, this document are limited to
providing feedback about format is intended specifically for communications
among providers regarding email only. abuse and related issues, and SHOULD
NOT be used for other reports.

3. Requirements

The following requirements are necessary for feedback reports (the
actual standard is defined in the next sections) :

o They must be both human and machine readable

b. Copy

o A copy of the original email message (body and headers) or email the
message headers must be enclosed in order to allow the receiver to
properly handle the report.

Shafranovich Expires September 2, 2005 [Page 3]

Internet-Draft Format

o The machine readable section must provide ability for Feedback Reports March 2005 the report
generators to share metadata with receivers,

o The format must be extensible.

4. Format of Email Feedback Reports

To satisfy the requirements, an email feedback report is defined as a
MIME message with a top level MIME content type of "multipart/report"
(as defined in RFC 3462 [1]). The following apply:

a. The "report-type" parameter of "multipart/report" type is set to
"feedback-report".
"feedback-report"

b. The first MIME part of the message contains a human readable
description of the report and MUST be included.

c. The second MIME part of the message contains is a machine readable
abuse report machine-readable section
with the content type of "message/feedback-report" (defined later
on in this document). document) and MUST be included. This section is
intended to convey metadata about the report in question that may
not be readily available from the included email message itself.

d. The third MIME part of the message contains either a full copy of
the original message with a MIME content type of "message/rfc822"
(as defined in RFC 2046 [1]) [3]) OR a copy of the headers from the
original message with MIME content type of "text/rfc822-headers"
(as defined in RFC 3462 [1]). This part MUST BE included (unlike

Shafranovich Expires November 14, 2005 [Page 4]

Internet-Draft Format for Feedback Reports May 2005

RFC 3462 [1]). While some operators may choose to modify or
munge this portion for privacy or legal reasons, it is
RECOMMENDED that the entire original email message be included
without any modification.

e. Each abuse feedback report should MUST be related to only a single originating SINGLE email
message. Summary and aggregate formats are outside the scope of
this specification.

f. The subject line of the abuse feedback report should read SHOULD be the same as "Email
Feedback Report for IP X.X.X.X" where "X.X.X.X" is the source IP
of
included email message and MAY include only the MTA from which the original message was received. If
email authentication is used, the sender may substitute the text
"for domain YYYYY.ZZZZ" where "YYYYY.ZZZZ" is the authenticated
domain.

g. It is preferable that all original email headers are included
even though they are defined standard
forwarding prefix used by MUAs such as optional in RFC 3462 [1]. "FW:" (many smaller
operators using MUAs for abuse handling rely on the subject lines
for processing).

5. Format of 'message/feedback-report' Content Type

The message/feedback-report

This content type consists provides a machine-readable section intended to let
the report generator convey metadata to the report receiver. The
intent of several header
fields as follows:

a. "Source-IP:" - contains an IPv4 this section is it allow report generators to convey
metadata to report receivers that may not available or IPv6 address of the MTA may not be
readily available from
which the original message was received.

b. "Received-Date:" - date the original originating email message was received. This
field is or headers.

The body of this content type consists of multiple "fields" formatted in
according to the definition in section 3.3 ABNF of RFC 2822 [2]

Shafranovich Expires September 2, 2005 [Page 4]

Internet-Draft Format for Feedback Reports March 2005

c. "Original-Message-ID:" - contains 822 [14] header "fields". This section
defines the RFC 2822 [2] Message-ID initial set of fields provided by this specification.
Additional fields maybe registered according to the original message

d. procedure
described later on in this document. Note that these fields
represent information that the receiver is asserting about the report
in question, but are not necessarily verifiable. Report receivers
MUST NOT assume that these assertions are always true.

5.1 Required Fields

The following header fields are REQUIRED and MUST only appear once:

o "Feedback-Type:" - contains the type of feedback as report (as
defined in the corresponding IANA registry.

e. "Authenticated-Domain:" and "Authenticated-Domain-Method:" registry). This is intended to
let report generators distinguish among different types of
reports.

o "User-Agent:" -
defines indicates the authenticated domain name and method used for perform that
authentication. The list version of method tokens is contained in the
corresponding IANA registry. Note software
program that generated the actual type of
authentication used is outside the scope report. The format of this document.

6. MIME Type Registration field MUST
follow section 14.43 of message/feedback-report RFC 2616 [4].

o "Version" - indicates the version of specification that the report
generator is using to generate the report. The version number in

Shafranovich Expires November 14, 2005 [Page 5]

Internet-Draft Format for Feedback Reports May 2005

this specification is set to "0.1".

5.2 Optional Fields Appearing Once

The following header fields are OPTIONAL and MUST NOT appear more
than once:

o "Original-Mail-From:" - copy of the email address used in the MAIL
FROM portion of the original SMTP transaction. The format of this
field is defined in section 4.1.1.2 of RFC 2821 [5].

o "Original-Rcpt-To:" - copy of the email address used in the RCPT
TO portion of the original SMTP transaction. The format of this
field is defined in section 4.1.1.3 of RFC 2821 [5].

o "Received-Date:" - indicates the date the original message was
received by the report generator. This field MUST BE formatted as
per section 3.3 of RFC 2822 [6].

o "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from
which the original message was received. IPv4 addresses are to be
formatted in dot-decimal notation as currently used by the
community. IPv6 addresses MUST BE formatted as per section 2.2 of
RFC 2373 [7].

5.3 Optional Fields Appearing Multiple Times

The following set of header fields are OPTIONAL and MAY appear more
than once:

o "Authentication-Results:" - indicates the result of an
authentication check run by the report generator. The format of
this field is is defined in draft-kucherawy-sender-auth-header
[8]. Report receivers should note that this field only indicates
an assertion made by the report generator.

o "Reported-Domain:" - indicates a domain name that the report
generator believes to be relevant to the report. Domain format is
defined in section 2.3.1 of RFC 1035 [9].

o "Reported-URI:" - indicates a URI that the report generator
believes to be relevant to the report. URI format is defined in
RFC 2396 [15].

o "Removal-Recipient:" - indicates the email address to be removed
from the mailing list (MUST only be used with "opt-out" and "opt-

Shafranovich Expires November 14, 2005 [Page 6]

Internet-Draft Format for Feedback Reports May 2005

out-list" types). The format of this field is defined in section
3.4.1 of RFC 2822 [6].

6. MIME Type Registration of message/feedback-report

This section provides the media type registration application (as per
RFC 2048 [11], which will be submitted to IANA after IESG approval of
this document.

To: ietf-types@iana.org

Subject: Registration of MIME media types message/feedback-report

MIME media type name: message

MIME subtype name: feedback-report

Required parameters: none

Optional parameters: none

Encoding considerations:

"7bit" encoding is sufficient and MUST be used to maintain
readability when viewed by non-MIME mail readers.

Security considerations:

See the "Security Considerations" of this document.

Interoperability considerations: implementors MUST ignore any fields
they do not support

Published specification: this document

Applications which use this media type: Abuse helpdesk software for
ISPs

Additional information:

Magic number(s): none

File extension(s): none

Macintosh File Type Code(s): none

Person and email address to contact for further information:

Shafranovich Expires November 14, 2005 [Page 7]

Internet-Draft Format for Feedback Reports May 2005

Yakov Shafranovich <ietf@shaftek.org>

Intended usage: COMMON

Author/Change controller: IESG

7. Extensibility

Like many other formats and protocols, this format may need to be
extended overtime to fit the ever changing landscape of the Internet.
Therefore, extensibility is being provided via two IANA registries:
one for feedback types and a second for header fields. The feedback
type registry is to be used in conjunction with the "Feedback-Type"
field above. The header name registry is intended for registration
of new metadata fields to be used in the machine readable portion
(part 2) of this format. Please note that version numbers do not
change with new field registrations unless a new specification of
this format is published. Also note that all new field registrations
can only registered OPTIONAL fields. Any new required fields REQUIRE
a new version of this specification to be published.

In order to encourage extensibility and interoperability of this
format, implementors SHOULD ignore any fields they do not support.

8. IANA Considerations

After IESG approval, IANA is expected to register MIME type "message/
feedback-report" using the application provided in this document and
setup two registries: one for header field names and a second for
"Feedback-Type" values. This section provides contains the media type templates used for
registration application (as per of new entries in these registries and initial values.
New registrations to these two registries MUST have approval by an
Designated Expert in accordance with the Expert Review guidelines as
described in RFC 2048 [4], which will 2434 [10] (the expert should be submitted appointed by the
Area Directors of the Applications Area). Any new field registered
is considered OPTIONAL unless a new version of this specification is
published.

For the header name registry, the following MUST be provided in an
RFC publication (or Internet draft with IETF consensus or IESG
approval) in order to register a new header field name:

1. Name of the field being registered

2. Short description of the field

3. Whether the field can appear more than once

Shafranovich Expires November 14, 2005 [Page 8]

Internet-Draft Format for Feedback Reports May 2005

4. Which "Feedback-Type" types does this field apply to (or "any")

5. The RFC number (or Internet draft name) in which this header is
registered

If the header field being registered requires its own IANA after registry,
than the appropriate registry MUST be properly defined.

For the feedback type registry, the following MUST be provided in an
RFC publication (or Internet draft with IETF consensus or IESG approval
approval) in order to register a new header field name:

1. Name of the feedback type being registered

2. Short description

3. The RFC number (or Internet draft name) in which this feedback
type is registered

8.1 Initial Values for the Header Names Registry

The data below is populated from this document.

To: ietf-types@iana.org

Subject: Registration The RFC number used
for registration of MIME media types message/feedback-report

MIME media type name: message

MIME subtype name: feedback-report

Required parameters: none

Optional parameters: none

Encoding considerations:

"7bit" encoding these values is sufficient and MUST be this document.

Field Name: Authentication-Results
Description: results of authentication check
Multiple Appearances: Yes
Related "Feedback-Type": any

Field Name: Feedback-Type
Description: type of feedback report
Multiple Appearances: No
Related "Feedback-Type": N/A

Field Name: Original-Mail-From
Description: email address used to maintain
readability when viewed by non-MIME mail readers.

Security considerations:

See section 3 in the MAIL FROM portion of the
original SMTP transaction
Multiple Appearances: No
Related "Feedback-Type": any

Field Name: Original-Rcpt-To
Description: copy of RFC 3462 [1]

Interoperability considerations: none

Published specification: this document

Applications which use this media type: Abuse helpdesk software for
ISPs

Additional information: the email address used in the RCPT TO portion of
the original SMTP transaction
Multiple Appearances: No
Related "Feedback-Type": any

Field Name: Received-Date

Shafranovich Expires September 2, November 14, 2005 [Page 5] 9]

Internet-Draft Format for Feedback Reports March May 2005

Magic number(s): none

File extension(s): none

Macintosh File Type Code(s): none

Person and

Description: date the original message was received
Multiple Appearances: No
Related "Feedback-Type": any

Field Name: Reported-Domain
Description: relevant domain name
Multiple Appearances: Yes
Related "Feedback-Type": any

Field Name: Reported-URI
Description: relevant URI
Multiple Appearances: Yes
Related "Feedback-Type": any

Field Name: Removal-Recipient
Description: email address to contact for further information:

Yakov Shafranovich <ietf@shaftek.org>

Intended usage: COMMON

Author/Change controller: IESG

7. IANA Considerations

After IESG approval, IANA is expected to register MIME type "message/
feedback-report" using be removed from the application provided in this document mailing list
Multiple Appearances: Yes
Related "Feedback-Type": opt-out, opt-out-list

Field Name: Source-IP
Description: IPv4 or IPv6 address from which the original message was
received
Multiple Appearances: No
Related "Feedback-Type": any

Field Name: User-Agent
Description: name and
setup two registries version of the program used
Multiple Appearances: No
Related "Feedback-Type": any

Field Name: Version
Description: version of specification used
Multiple Appearances: No
Related "Feedback-Type": any

8.2 Initial values for the "Feedback-Type" registry

The initial names and "Authentication-Domain-
Method" headers. Below descriptions are the initial values provided below. The RFC
number used for registration of these registries.

Initial values for the "Feedback-Type" registry: is this document.

o abuse - spam or some other kind of email abuse

o fraud - indicates some kind of fraud or phishing activity.

o opt-out - a request to opt out from ALL mailing lists from this
provider.

Shafranovich Expires November 14, 2005 [Page 10]

Internet-Draft Format for Feedback Reports May 2005

o opt-out-list - a request to opt out from THIS mailing list. list ONLY.

o other - any other feedback that doesn't fit into other types.

o virus - report of a virus found in the originating message

Initial values for the "Authentication-Domain-Method" registry:

domainkeys - as defined in delany-domainkeys-base [5]

iim - as defined in fenton-identified-mail [6]

sender-id - as defined in lyon-senderid-core [7]

spf - as defined in schlitt-spf-classic [8]

9. Security Considerations

See section 3 of RFC 3462 [1]

10. Acknowledgments

The author would like to thank many of the members of the email
community who provided helpful comments and suggestions for this

Shafranovich Expires September 2, 2005 [Page 6]

Internet-Draft Format for Feedback Reports March 2005
document including many of the participants in ASRG, IETF and MAAWG
activities.

10.
activities, and all of the members of the abuse-feedback-report
public mailing list.

11. References

10.1

11.1 Normative References

[1] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 3462,
January 2003.

[2] Resnick, P., "Internet Message Format", Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2822, April 2001. 2119, March 1997.

[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.

10.2

[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.

[5] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.

[6] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[7] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.

[8] Kucherawy, M., "Message Header for Indicating Sender
Authentication Status", draft-kucherawy-sender-auth-header-02

Shafranovich Expires November 14, 2005 [Page 11]

Internet-Draft Format for Feedback Reports May 2005

(work in progress), May 2005.

[9] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.

11.2 Informative References

[4]

[11] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996.

[5] Delany, M., "Domain-based Email Authentication Using Public-Keys
Advertised in

[12] Crissman, G., "Proposed Spam Reporting BCP Document", May 2005,
<http://www.tmisnet.com/~strads/spam/bcp.html>.

[13] Anti-Spam Research Group (ASRG) of the DNS (DomainKeys)",
draft-delany-domainkeys-base-02 (work in progress), March 2005.

[6] Fenton, J. and M. Thomas, "Identified Internet Mail",
draft-fenton-identified-mail-01 (work in progress),
October 2004.

[7] Lyon, J., "Sender ID: Authenticating E-Mail",
draft-lyon-senderid-core-00 (work in progress), November 2004.

[8] Wong, M., "Sender Policy Framework: Authorizing Use Research Task
Force (IRTF), "Abuse Reporting Standards Subgroup of Domains
in E-MAIL", draft-schlitt-spf-classic-00 (work in progress),
January 2005. the ASRG",
May 2005, <http://asrg.sp.am/subgroups/abuse_reports.shtml>.

[14] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.

[15] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.

Author's Address

Yakov Shafranovich
SolidMatrix Technologies, Inc.

Email: ietf@shaftek.org
URI: http://www.shaftek.org

Appendix A. Appendix A - Sample Feedback Reports

A.1 Simple Report for Email Abuse without Optional Headers

Shafranovich Expires September 2, November 14, 2005 [Page 7] 12]

Internet-Draft Format for Feedback Reports March May 2005

Appendix A. Appendix A - An Sample Abuse

From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report; boundary="part1_13d.2e68ed54_boundary"

--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This is an email abuse report for an email message received from IP 10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT.
For more information about this format please see http://www.mipassoc.org/arf/.

--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 0.1

--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline

From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net [10.67.41.167])
by example.com with ESMTP id M63d4137594e46; Thu, 08 Mar 2005 14:00:00 -0400
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500

Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
--part1_13d.2e68ed54_boundary--

A.2 Opt-Out Report without Message Body

Shafranovich Expires November 14, 2005 [Page 13]

Internet-Draft Format for Feedback Reports May 2005

From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: Email Abuse Report FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report; boundary="part1_13d.2e68ed54_boundary"

--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This is an opt-out report for an email message received from IP 10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT.
For more information about this format please see http://www.mipassoc.org/arf/.

--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report

Feedback-Type: opt-out
User-Agent: SomeGenerator/1.0
Version: 0.1
Removal-Recipient: user@example.com

--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822-headers
Content-Disposition: inline

A.3 Full Report for Email Abuse with All Headers

Shafranovich Expires November 14, 2005 [Page 14]

Internet-Draft Format for Feedback Reports May 2005

--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This is an email abuse report for an email message received from IP 10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT.
For more information about this format please see http://www.mipassoc.org/arf/.

--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report

Source-IP: 10.67.41.167

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 0.1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
Original-Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Feedback-Type: abuse
Source-IP: 10.67.41.167
Authentication-Results: mail.example.com
smtp.mail=somespammer@example.com;
spf=fail
Reported-Domain: example.net
Reported-Uri: http://example.net/earn_money.html
Reported-Uri: mailto:user@example.com
Removal-Recipient: user@example.com

--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline

Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
--part1_13d.2e68ed54_boundary--

Shafranovich Expires September 2, November 14, 2005 [Page 15]

Internet-Draft Format for Feedback Reports May 2005

Appendix B. Status of This Document [To Be Removed Upon Publication]

B.1 Discussion Venue

Discussion about this document should be directed to the ABUSE-
FEEDBACK-REPORT mailing list
<http://mipassoc.org/mailman/listinfo/abuse-feedback-report> which is
also reachable via <mailto:abuse-feedback-report@mipassoc.org>. Of
course, comments directly to the author are always welcome (you can
send them via email to <ietf@shaftek.org>).

B.2 Document Repository and Public Website

Copies of this and earlier versions including multiple formats can be
found at <http://www.shaftek.org/publications/drafts/abuse-report/>.
A public website regarding this draft and related efforts is located
at <http://mipassoc.org/arf/>.

B.3 Document History

Changes from draft-shafranovich-feedback-report-01-pre1 to
draft-shafranovich-feedback-report-01:

o Added an "Outstanding Issues" section.

o Minor spelling mistakes and clarifications.

o Added links to previous work and more examples.

o Added three new types: "fraud" for phishing, "opt-out-list" for a
single list opt out, and "other" as a catch-all.

Changes from draft-shafranovich-feedback-report-00 to
draft-shafranovich-feedback-report-01-pre1:

o Changed the introduction section to clarify specific points that
are out of scope for this document

o Added pointers to a public mailing list for discussion and public
web page

o Clarified the intent section and added some extra points to it

o Added a reference to RFC 2119 and changed the document to comply

o Made it clear that the requirements section) is not the one
defining the standard

Shafranovich Expires November 14, 2005 [Page 8] 16]

Internet-Draft Format for Feedback Reports March May 2005

Appendix B. Status of This Document [To Be Removed Upon Publication]

B.1 Discussion Venue

Comments about this document

o Clarified the main format section to make all three parts
mandatory

o Changed section 4f regarding subject lines to mandate that subject
lines should be sent directly left intact. Removed the convention for subject
lines that was defined in the previous version

o Added text to the author at
via <ietf@shaftek.org>.

B.2 Document Repository

Copies of this and earlier versions including multiple formats the machine readable section clarifying its
intent. Also added RFC 2119 references, reorganized fields,
indicated whether specific header fields can appear more than once
and provided references as to how they should be
found at <http://www.shaftek.org/publications/drafts/abuse-report/>.

B.3 Document History formatted.

o Removed "Original-Message-ID", "Authenticated-Domain:" and
"Authenticated-Domain-Method" from the draft including related
IANA registries. Added "Version", "User-Agent", Original-Mail-
From", "Original-Rcpt-To", "Reported-Uri", "Reported-Domain" and
"Authentication-Results".

o Example has been updated to reflect new headers.

o Added a new section on extensibility and changed the IANA section
to reflect that.

Changes from draft-shafranovich-abuse-report-00 to
draft-shafranovich-feedback-report-00:

o Name of the format and report changed to 'feedback-report'

o Minor spelling corrections

o Added authentication headers and registry

o Added feedback-type header and registry.

B.4 Outstanding Issues

Here is a list of some outstanding issues for this document that have
not been finalized:

o Whether encoding of the machine readable part should be limited to
7-bit

o Whether there is a need for both "opt-out" and "opt-out-list", and
whether this format should be used for opt-outs at all.

o Whether the "from" address should be required to be a human just
like other RFCs in the "message/report" family.

Shafranovich Expires September 2, November 14, 2005 [Page 9] 17]

Internet-Draft Format for Feedback Reports March May 2005

o Whether there is a need for a new header to indicate munging of
the included email message.

o Whether different type of convention should be allowed for subject
lines.

o Whether there should be different types defined for "Reported-Uri"
to better indicate to the report receiver how they are related to
the email message in question.

Shafranovich Expires November 14, 2005 [Page 18]

Internet-Draft Format for Feedback Reports May 2005

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Shafranovich Expires September 2, November 14, 2005 [Page 10] 19]

----