WDIFF

draft-shafranovich-feedback-report-05.txt --> draft-shafranovich-feedback-report-06.txt

Network Working Group

Individual submission Y. Shafranovich
Internet-Draft SolidMatrix Technologies, Inc. ShafTek Enterprises
Intended status: Informational Standards Track J. Levine
Expires: December 18, 2008 P. Hoffman July 6, 2009 Domain Assurance Council
M. Kucherawy
Sendmail, Inc.
June 16, 2008
January 2, 2009

An Extensible Format for Email Feedback Reports
draft-shafranovich-feedback-report-05
draft-shafranovich-feedback-report-06

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she

This Internet-Draft is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
provisions of BCP 78 and 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 December 18, 2008. July 6, 2009.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.

Shafranovich, et al. Expires July 6, 2009 [Page 1]

Internet-Draft Format for Feedback Reports January 2009

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 machine-readable
replacement for various existing report formats currently used in

Shafranovich, et al. Expires December 18, 2008 [Page 1]

Internet-Draft Format for Feedback Reports June 2008
Internet email.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Intent . . .
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Format of Email Feedback Reports .
1.3. Definitions . . . . . . . . . . . . . . 4
5. Format of 'message/feedback-report' Content Type . . . . . . . 5
5.1. Required Fields . . 4
1.3.1. General . . . . . . . . . . . . . . . . . . . 5
5.2. Optional Fields Appearing Once . . . . 4
1.3.2. E-mail Specific . . . . . . . . . . 6
5.3. Optional Fields Appearing Multiple Times . . . . . . . . . 7
6. MIME Type Registration 4
2. Format of message/feedback-report Email Feedback Reports . . . . . . 8
7. Extensibility . . . . . . . . . 5
3. The 'message/feedback-report' Content Type . . . . . . . . . . 6
3.1. Required Fields . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . 6
3.2. Optional Fields Appearing Once . . . . . 9
8.1. Initial Values for the Header Names Registry . . . . . . . 10
8.2. Initial values for the "Feedback-Type" registry . . 7
3.3. Optional Fields Appearing Multiple Times . . . 12
8.3. Initial values for the "DKIM Failure Type" registry . . . 13
9. Security Considerations . . . 8
3.4. Formal Definition . . . . . . . . . . . . . . . . 13
9.1. Inherited from RFC3462 . . . . 8
4. Extensibility . . . . . . . . . . . . . . 14
9.2. Interpretation . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . 14
9.3. Envelope Sender Selection . . . . . . . . . 13
5.1. MIME Type Registration of 'message/feedback-report' . . . 13
5.2. Feedback Report Header Fields . . . . 14
10. Acknowledgments . . . . . . . . . . 14
5.3. Feedback Report Type Values . . . . . . . . . . . . . 14
11. References . . 17
5.4. Feedback Report DKIM Failure Values . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . 21
6.1. Inherited from RFC3462 . . . . . . . . . . . . . 14
11.2. Informative References . . . . . 21
6.2. Interpretation . . . . . . . . . . . . . 15
Appendix A. Appendix A - Sample Feedback . . . . . . . . . 21
6.3. Envelope Sender Selection . . . . . . . . . . . . . . . . 21
6.4. Attacks Against Authentication Methods . . . . . . . . . . 21
6.5. Intentionally Malformed Reports . . . . . . . . 16
A.1. Simple Report for Email Abuse without Optional Headers . . 16
A.2. Opt-Out Report without Message Body . . . 22
7. References . . . . . . . . . . 18
A.3. Full Report for Email Abuse with All Headers . . . . . . . 19
Appendix B. Status of This Document [To Be Removed Upon
Publication] . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . 20
B.1. Discussion Venue . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix B. Sample Feedback Reports . . . . . . . . . . . . . . 20 . 26
B.1. Simple Report for Email Abuse without Optional Headers . . 26
B.2. Document Repository and Public Website Opt-Out Report without Message Body . . . . . . . . . . 20 . 28
B.3. Document History Full Report for Email Abuse with All Headers . . . . . . . 29
B.4. Sample DKIM Failure Report . . . . . . . . . . . . . . 20
Authors' Addresses . . 30
Appendix C. Public Discussion, History and Support . . . . . . . 31
Appendix D. Document History . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 . . . 36

Shafranovich, et al. Expires December 18, 2008 July 6, 2009 [Page 2]

Internet-Draft Format for Feedback Reports June 2008 January 2009

1. Introduction

As the spam problem continues to expand and potential solutions
evolve, network operators are increasingly exchanging abuse reports
among themselves and other parties. However, different operators
have defined their own formats, and thus the receivers of these
reports are forced to write custom software to interpret each. In
addition, many operators use various other report formats to provide
non-abuse-related feedback about processed email. This memo seeks to
define a standard extensible format and by creating the "message/feedback-report"
MIME "message/
feedback-report" [MIME] type for these reports.

This format and content type are intended to be used within the scope
of the framework of the "multipart/report" content type defined in
[RFC3462].
[REPORT]. While there has been previous work in this area
([STRADS_BCP] (e.g.
[STRADS-BCP] and [ASRG_ABUSE]), [ASRG-ABUSE]), none of them have yet been
sucessful.
successful. 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 direct
feedback via end user mail clients, reports of some types of virus
activity, and some similar issues. It also has the capacity to
support message authentication failure reporting, in particular DKIM
[RFC4871].
[DKIM].

This document only defines the format and [MIME] content type to be
used for these reports. Determination of where these reports should
be sent, how trust among report generators and report recipients is
established, and reports related to more than one message are outside
the scope of this document. It is assumed that best practices will
evolve over time, and will be codified in future documents.

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 [RFC2119].

2. Intent

1.1. Purpose

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 networks;

o To inform email service providers or other primarily outbound
senders that there may be issues regarding their mail. These mail; these
issues include (but are not limited to) reports that the mail may

Shafranovich, et al. Expires December 18, 2008 [Page 3]

Internet-Draft Format for Feedback Reports June 2008
be considered to be "spam" by a recipient of the message. message;

o To inform email service provides about opt-out requests requests;

Shafranovich, et al. Expires July 6, 2009 [Page 3]

Internet-Draft Format for Feedback Reports January 2009

o To advise providers that certify or otherwise make assertions
about mail of recipient disagreement with the assertions.

Please note that while the parent "multipart/report" content type
defined in [RFC3462] [REPORT] is used for all kinds of administrative messages,
this format is intended specifically for communications among
providers regarding email abuse and related issues, and SHOULD NOT be
used for other reports.

1.2. Requirements

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

o They must be both human and machine readable readable;

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

o The machine readable section must provide ability for the report
generators to share metadata meta-data with receivers, receivers;

o The format must be extensible.

1.3. Definitions

This section defines various terms used throughout this document.

1.3.1. General

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 [KEYWORDS].

1.3.2. E-mail Specific

See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail
system architecture.

Shafranovich, et al. Expires July 6, 2009 [Page 4]

Internet-Draft Format for Feedback Reports January 2009

2. Format of Email Feedback Reports

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

a. The "report-type" parameter of the "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 is a machine-readable section
with the content type of "message/feedback-report" (defined later
on
in this document) memo) and MUST be included. This section is intended to
convey metadata meta-data about the report in question that may not be
readily available from the included email message itself.

Shafranovich, et al. Expires December 18, 2008 [Page 4]

Internet-Draft Format for Feedback Reports June 2008

d. The third MIME part of the message contains is either a full copy of type "message/
rfc822" (as defined in [MIME-TYPES] and contains the original
message with a MIME content type in its entirety, OR is of "message/rfc822" type "text/rfc822-headers" (as
defined in [RFC2046]) OR [REPORT] and contains a copy of the headers entire header
block from the
original message with MIME content type of "text/rfc822-headers"
(as defined in [RFC3462]). orignal message. This part MUST be included (unlike
[RFC3462]).
(contrary to [REPORT]). While some operators may choose to
modify or redact this portion for privacy or legal reasons, it is
RECOMMENDED that the entire original email message be included
without any
modification. modification as such modifications can impede
forensic work by the recipient of this report.

e. Each Except as discussed below, each feedback report MUST be related
to only a SINGLE single email message. Summary and aggregate formats
are outside of the scope of this specification.

f. The subject line Subject header field of the feedback report SHOULD be the
same as the included email message about which the report is
being generated and MAY include only the standard forwarding
prefix used by MUAs such as "FW:". (Many smaller operators using
MUAs for abuse handling rely on the subject lines for
processing.)

Shafranovich, et al. Expires July 6, 2009 [Page 5]

Internet-Draft Format of for Feedback Reports January 2009

3. The 'message/feedback-report' Content Type

A new [MIME] content type called "message/feedback-report" is
defined. This content type provides a machine-readable section
intended to let the report generator convey metadata meta-data to the report
receiver. The intent of this section is to convey information which
may not be obvious or may not be easily extracted from the original
email message or headers.

The body of this content type consists of multiple "fields" formatted
according to the ABNF of [RFC2822] [MAIL] header "fields". fields. This section defines
the initial set of fields provided by this specification. Additional
fields may be registered according to the procedure described later on
in this document. Altough memo. Although these fields have a syntax similar to those
of mail message headers, header fields, they are semantically distinct; hence
they SHOULD NOT be repeated in the header area of the message
containing the report. 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 accurate.

5.1.

3.1. Required Fields

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

o "Feedback-Type:" - "Feedback-Type" contains the type of feedback report (as defined
in the corresponding IANA registry). registry and later in this memo). This
is intended to let report generators parsers distinguish among different
types of

Shafranovich, et al. Expires December 18, 2008 [Page 5]

Internet-Draft Format for Feedback Reports June 2008 reports.

o "User-Agent:" - "User-Agent" indicates the name and version of the software
program that generated the report. The format of this field MUST
follow section 14.43 of [RFC2616]. [HTTP]. This field is for documentation
only; there is no registry of user agent names or versions, and
report receivers SHOULD NOT expect user agent names to belong to a
known set.

o "Version:" - "Version" indicates the version of specification that the report
generator is using to generate the report. The version number in
this specification is set to "0.1". [NOTE TO RFC EDITOR: This
should be changed to "1" at time of publication.]

The following report header field SHOULD fields MUST appear exactly once in a DKIM failure
report:

o "DKIM-Failure:" - the type of DKIM verification failure that
occurred; MUST be included for "dkim"
[DKIM] failure reports report (defined below) and MUST NOT
be included otherwise.

5.2. appear in other
reports:

Shafranovich, et al. Expires July 6, 2009 [Page 6]

Internet-Draft Format for Feedback Reports January 2009

o "DKIM-Failure" names the type of DKIM verification failure that
occurred.

3.2. Optional Fields Appearing Once

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

o "Original-Envelope-Id:" - "Original-Envelope-Id" contains the envelope ID string used in the
original
SMTP [SMTP] transaction (see section 2.2.1 of [RFC3464]. [DSN]).

o "Original-Mail-From:" - "Original-Mail-From" contains a 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 [RFC2821]. [SMTP].

o "Arrival-Date:" - "Arrival-Date" indicates the date and time at which the original
message was received by recipient system's MTA. This field MUST
be formatted as per section 3.3 of [RFC2822]. [MAIL].

o "Reporting-MTA:" - "Reporting-MTA" indicates the name of the MTA generating this
feedback report. This field is defined in section 2.2.2 of
[RFC3464], [DSN],
except that it is an optional field in this report.

o "Source-IP:" - "Source-IP" contains an IPv4 or IPv6 address of the MTA from which
the original message was received. Addresses MUST be formatted as
per section 4.1.3 of [RFC2821]. [SMTP].

o "Incidents:" - "Incidents" contains an integer indicating the number of incidents
this report represents. The absence of this field implies the
report covers a single incident.

Shafranovich, et al. Expires December 18, 2008 [Page 6]

Internet-Draft Format This field MUST NOT be used for Feedback Reports June 2008
report types other than "dkim".

The historic field "Received-Date:" "Received-Date" SHOULD also be accepted and
interpreted identically to "Arrival-Date:". "Arrival-Date".

The following header fields are OPTIONAL and MAY may each appear once in
a DKIM [DKIM] failure report:

o "DKIM-Canonicalized-Body:" - "DKIM-Canonicalized-Body" contains the canonicalized message body
of a message which failed DKIM verification, base64-encoded and line-
wrapped
line-wrapped to remain inside [RFC2822] limits ("dkim" reports only). [MAIL] limits. base64 encoding is
defined in [RFC2045]. [MIME].

o "DKIM-Canonicalized-Header:" - DKIM-Canonicalized-Header" contains the canonicalized message
header block of a message which failed DKIM verification, base64-encoded base64-
encoded and line-wrapped to remain inside [RFC2822] limits; ("dkim"
reports only; [MAIL] limits. This
filed SHOULD be present included for those reports). DKIM reports.

Shafranovich, et al. Expires July 6, 2009 [Page 7]

Internet-Draft Format for Feedback Reports January 2009

o "DKIM-Domain:" - "DKIM-Domain" contains the domain whose private key was used to
sign a message, taken from the signature's "d=" tag ("dkim" reports
only). tag.

o "DKIM-Identity:" - "DKIM-Identity" contains the signing agent's identity, taken from
the signature's "i=" tag ("dkim" reports only). tag.

o "DKIM-Selector:" - "DKIM-Selector" contains the selector referenced by a DKIM
signature, taken from the signature's "s=" tag ("dkim" reports only).

5.3. tag.

3.3. Optional Fields Appearing Multiple Times

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

o "Authentication-Results:" - "Authentication-Results" indicates the result of an one or more
authentication check checks run by the report generator. The format of
this field is is defined in [AUTH-HEADER].
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER]. Report receivers should
note that this field only indicates an assertion made by the
report generator.

o "Original-Rcpt-To:" - "Original-Rcpt-To" includes a copy of the email address used in
the RCPT TO portion of the original SMTP [SMTP] transaction. The
format of this field is defined in section 4.1.1.3 of RFC 2821. that memo.
This field SHOULD be repeated for every SMTP recipient seen by the
report generator.

o "Reported-Domain:" - "Removal-Recipient" indicates the email address to be removed from
the mailing list (MUST NOT be used with report types other than
"opt-out"). The format of this field is defined in section 3.4.1
of [MAIL].

o "Reported-Domain" includes a domain name that the report generator
believes to be relevant to the report, e.g. the domain whose
apparent actions provoked the generation of the report. Domain
format is defined in section 2.3.1 of [RFC1035]. [DNS].

o "Reported-URI:" - "Reported-URI" indicates a URI that the report generator believes
to be relevant to the report. report, e.g. a URI to which the report
recipient can go for further details. URI format is defined in
[RFC3986].
[URI].

3.4. Formal Definition

The formal definition of the contents of a "message/feedback-report"
media type using [ABNF] is as follows:

feedback-report = *( feedback-type / user-agent / version )

Shafranovich, et al. Expires December 18, 2008 July 6, 2009 [Page 7] 8]

Internet-Draft Format for Feedback Reports June 2008

o "Removal-Recipient:" - indicates January 2009

[ dkim-failure ]
opt-fields-once
dkim-fields-once
*( opt-fields-many )

feedback-type = "Feedback-Type:" [CFWS] token [CFWS] CRLF
; the email address to "token" must be removed
from a registered feedback type as
; described elsewhere in this document

user-agent = "User-Agent:" [CFWS] product [CFWS] CRLF

version = "Version:" [CFWS] token [CFWS] CRLF
; as described above

dkim-failure = "DKIM-Failure:" [CFWS] token [CFWS] CRLF
; the mailing list (MUST only "token" must be used with "opt-out"). The
format of this field is defined a registered DKIM failure type
; as described elsewhere in section 3.4.1 of RFC 2822.

6. MIME Type Registration of message/feedback-report

This section provides the media type registration application from
[RFC4288].

To: ietf-types@iana.org

Subject: Registration this document

opt-fields-once = [ arrival-date ]
[ dkim-failure ]
[ incidents ]
[ original-envelope-id ]
[ original-mail-from ]
[ reporting-mta ]
[ source-ip ]

arrival-date = "Arrival-Date:" [CFWS] date-time [CFWS] CRLF

incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF

original-envelope-id = "Original-Envelope-Id:" [CFWS]
envelope-id [CFWS] CRLF

original-mail-from = "Original-Mail-From:" [CFWS]
reverse-path [CFWS] CRLF

reporting-mta = "Reporting-MTA:" [CFWS] mta-name [CFWS] CRLF

source-ip = "Source-IP:" [CFWS]
( IPv4-address-literal /
IPv6-address-literal ) [CFWS] CRLF

dkim-fields-once = [ dkim-canon-body ]
[ dkim-canon-header ]
[ dkim-domain ]
[ dkim-identity ]
[ dkim-selector ]

Shafranovich, et al. Expires July 6, 2009 [Page 9]

Internet-Draft Format for Feedback Reports January 2009

dkim-canon-body = "DKIM-Canonicalized-Body:" [CFWS]
base64string [CFWS] CRLF

dkim-canon-header = "DKIM-Canonicalized-Header:" [CFWS]
base64string [CFWS] CRLF

dkim-domain = "DKIM-Domain:" [CFWS] domain-name [CFWS] CRLF

dkim-identity = "DKIM-Domain:" [CFWS] [ local-part ] "@"
domain-name [CFWS] CRLF

dkim-selector = "DKIM-Selector:" [CFWS] selector [CFWS] CRLF

opt-fields-many = [ authres-header ]
[ original-rcpt-to ]
[ removal-recipient ]
[ reported-domain ]
[ reported-uri ]

original-rcpt-to = "Original-Rcpt-To:" [CFWS]
forward-path [CFWS] CRLF

removal-recipient = "Removal-Recipient:" [CFWS]
mailbox [CFWS] CRLF

reported-domain = "Reported-Domain:" [CFWS]
domain-name [CFWS] CRLF

reported-uri = "Reported-Domain:" [CFWS] URI [CFWS] CRLF

A set of media type message/feedback-report

Type name: fields satisfying this ABNF may appear in the transmitted
message

Subtype name: feedback-report

Required parameters: none

Optional parameters: none

Encoding considerations:

"7bit" encoding in any order.

"CRLF" is sufficient imported from [ABNF].

"token" is imported from [MIME].

"product" is imported from [HTTP].

"mailbox", "CFWS" and MUST be used to maintain
readability when viewed by non-MIME mail readers.

Security considerations:

See the "Security Considerations" of
draft-shafranovich-feedback-report-04.txt.

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

Published specification: draft-shafranovich-feedback-report-04.txt

Applications which use this media type: Abuse helpdesk software for
ISPs, mail service bureaus, mail certifiers, "date-time" are imported from [MAIL].

"envelope-id" and similar
organizations

Additional information: none

Person "mta-name" are imported from [DSN].

"reverse-path", "forward-path", "local-part", "IPv4-address-literal"
and email address to contact for further information: Yakov
Shafranovich <ietf@shaftek.org>

Intended usage: COMMON "IPv6-address-literal" are imported from [SMTP].

"base64string", "domain-name" and "selector" are imported from
[DKIM]. Furthermore, a "base64string" SHOULD be line-wrapped as

Shafranovich, et al. Expires December 18, 2008 July 6, 2009 [Page 8] 10]

Internet-Draft Format for Feedback Reports June 2008

Author: Yakov January 2009

described in section 6.8 of [MIME].

"URI" is imported from [URI].

"authres-header" is imported from
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER].

Shafranovich, John Levine, Paul Hoffman

Change controller: IESG

7. et al. Expires July 6, 2009 [Page 11]

Internet-Draft Format for Feedback Reports January 2009

4. Extensibility

Like many other formats and protocols, this format may need to be
extended over time to fit the ever changing landscape of the
Internet. Therefore, extensibility is provided via two IANA
registries: one for feedback types and a second for report 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 meta-data 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 may only be registered as 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 MUST ignore any fields they do not support.

Shafranovich, et al. Expires July 6, 2009 [Page 12]

Internet-Draft Format for Feedback Reports January 2009

5. IANA Considerations

IANA is requested to register MIME a new [MIME] type "message/feedback-report"
using the application provided in this document and setup create three
registries: one for header field names, a second for "Feedback-Type"
values, and a third for "DKIM-Failure" values. new
registries, as described below.

5.1. MIME Type Registration of 'message/feedback-report'

This section contains provides the templates used for media type registration of new entries in these
registries application from
[MIME-REG] for processing by IANA:

To: ietf-types@iana.org

Subject: Registration of media type message/feedback-report

Type name: message

Subtype name: feedback-report

Required parameters: none

Optional parameters: none

Encoding considerations: "7bit" encoding is sufficient and their initial values. MUST be
used to maintain readability when viewed by non-MIME mail readers.

Security considerations: See the Security Considerations section 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, mail service bureaus, mail certifiers, and similar
organizations

Additional information: none

Person and email address to contact for further information:

Yakov Shafranovich <ietf@shaftek.org>

Murray S. Kucherawy <msk@sendmail.com>

Shafranovich, et al. Expires July 6, 2009 [Page 13]

Internet-Draft Format for Feedback Reports January 2009

Intended usage: COMMON

Author:

Yakov Shafranovich

John Levine

Murray S. Kucherawy

Change controller: IESG

5.2. Feedback Report Header Fields

IANA is requested to create the "Feedback Report Header Fields"
registry. This registry will contain header fields for use in
feedback reports, defined by this memo.

New registrations to these
registries this registry MUST have approval by a Designated
Expert in accordance with the Expert Review guidelines as described
in [RFC5226] (the [IANA-CONSIDERATIONS]. The expert should be appointed by the Area Directors of
Director for the Applications
Area). Area. Any new field registered is
considered OPTIONAL by this specification unless a new version of
this specification memo is published.

For the header name registry,

New registrations MUST contain the following MUST be provided in order
to register a new header field name: information:

1. Name of the field being registered

2. Short description of the field

3. Whether the field can appear more than once

Shafranovich, et al. Expires December 18, 2008 [Page 9]

Internet-Draft Format for Feedback Reports June 2008

4. Which "Feedback-Type" types does To which feedback type(s) this field apply to applies (or "any")

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

If the header field being registered requires its own IANA registry,
than specification of the appropriate field is published

The initial registry MUST be properly defined.

For the feedback type registry, should contain these values:

Field Name: Arrival-Date
Description: date/time the following MUST be provided 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

For the DKIM failure registry, the following MUST be provided in
order to register a new header field name:

1. Name of the DKIM failure 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 are populated from this document. The RFC number used original message was received
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]

Shafranovich, et al. Expires July 6, 2009 [Page 14]

Internet-Draft Format for registration of these values is this document. Feedback Reports January 2009

Field Name: Authentication-Results
Description: results of authentication check check(s)
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [this document]

Field Name: DKIM-Canonicalized-Body
Description: Canonicalized body, per DKIM, base64-encoded
Multiple Appearances: No
Related "Feedback-Type": dkim
Published in: [this document]

Field Name: DKIM-Canonicalized-Header
Description: Canonicalized header block, blcok, per DKIM, base64-encoded
Multiple Appearances: No
Related "Feedback-Type": dkim

Shafranovich, et al. Expires December 18, 2008 [Page 10]

Internet-Draft Format for Feedback Reports June 2008
Published in: [this document]

Field Name: DKIM-Domain
Description: selector from DKIM signature ("d=" signature tag
value)
Multiple Appearances: No
Related "Feedback-Type": dkim
Published in: [this document]

Field Name: DKIM-Failure
Description: registered DKIM failure type
Multiple Appearances: No
Related "Feedback-Type": dkim
Published in: [this document]

Field Name: DKIM-Identity
Description: DKIM signing identity ("i=" signature tag value)
Multiple Appearances: No
Related "Feedback-Type": dkim
Published in: [this document]

Field Name: DKIM-Selector
Description: selector from DKIM signature ("s=" signature tag
value)
Multiple Appearances: No
Related "Feedback-Type": dkim

Shafranovich, et al. Expires July 6, 2009 [Page 15]

Internet-Draft Format for Feedback Reports January 2009

Published in: [this document]

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

Field Name: Original-Envelope-Id
Description: envelope ID string used in the original SMTP transaction
(see section 2.2.1 of [RFC3464]
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]

Field Name: Original-Mail-From
Description: email address used in the MAIL FROM portion of the
original SMTP transaction
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]

Field Name: Original-Rcpt-To
Description: copy of the email address used in the RCPT TO portion of the
original SMTP transaction
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [this document]

Field Name: Arrival-Date Received-Date
Description: date date/time the original message was received
(historic; deprecated)
Multiple Appearances: No
Related "Feedback-Type": any

Shafranovich, et al. Expires December 18, 2008 [Page 11]

Internet-Draft Format for Feedback Reports June 2008
Published in: [this document]

Field Name: Received-Date Removal-Recipient
Description: date email address to be removed from the original message was received (historic;
deprecated) mailing list
Multiple Appearances: No Yes
Related "Feedback-Type": any opt-out
Published in: [this document]

Field Name: Reported-Domain
Description: relevant domain name
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [this document]

Shafranovich, et al. Expires July 6, 2009 [Page 16]

Internet-Draft Format for Feedback Reports January 2009

Field Name: Reported-URI
Description: relevant URI
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [this document]

Field Name: Reporting-MTA
Description: MTA generating this report
Multiple Appearances: No
Related "Feedback-Type": any

Field Name: Removal-Recipient
Description: email address to be removed from the mailing list
Multiple Appearances: Yes
Related "Feedback-Type": opt-out
Published in: [this document]

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

Field Name: User-Agent
Description: name and version of the program used
Multiple generating the
report
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]

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

8.2. Initial values for
Published in: [this document]

5.3. Feedback Report Type Values

IANA is requested to create the "Feedback-Type" "Feedback Report Type Values"
registry. This registry will contain feedback types for use in
feedback reports, defined by this memo.

New registrations to this registry MUST have approval by a Designated
Expert in accordance with the Expert Review guidelines as described
in [IANA-CONSIDERATIONS]. The initial names and descriptions are provided below. The RFC
number used expert should be appointed by the Area
Director for registration of these values the Applications Area. Any new field registered is
considered OPTIONAL by this document. specification unless a new version of
this memo is published.

Shafranovich, et al. Expires December 18, 2008 July 6, 2009 [Page 12] 17]

Internet-Draft Format for Feedback Reports June 2008

o January 2009

New registrations MUST contain the following information:

1. Name of the feedback type being registered

2. Short description of the feedback type

3. The document in which the specification of the field is published

The initial registry should contain these values:

Feedback Type Name: abuse -
Description: spam or some other kind of email abuse

o
Published in: [this document]

Feedback Type Name: dkim -
Description: a DKIM signature verification or policy violation
error

o
Published in: [this document]

Feedback Type Name: fraud -
Description: indicates some kind of fraud or phishing activity.

o activity
Published in: [this document]

Feedback Type Name: miscategorized -
Description: indicates that the content categorization applied
in connection with a certification or reputation
system was incorrect

o
Published in: [this document]

Feedback Type Name: not-spam -
Description: indicates that a message that was tagged or
categorized as spam (such as by an ISP) is not spam

o
Published in: [this document]

Feedback Type Name: opt-out -
Description: a request to opt out from mailings from this provider.

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

o
provider
Published in: [this document]

Feedback Type Name: other -
Description: any other feedback that doesn't does not fit into other types.

8.3. Initial values
registered types

Shafranovich, et al. Expires July 6, 2009 [Page 18]

Internet-Draft Format for Feedback Reports January 2009

Published in: [this document]

Feedback Type Name: virus
Description: report of a virus found in the "DKIM originating message
Published in: [this document]

5.4. Feedback Report DKIM Failure Type" registry

The initial names and descriptions are provided below. The RFC
number used for registration of these values Values

IANA is this document.

o bodyhash - The body hash in requested to create the signature "Feedback Report Header Fields"
registry. This registry will contain header fields for use in
feedback reports, defined by this memo.

New registrations to this registry MUST have approval by a Designated
Expert in accordance with the Expert Review guidelines as described
in [IANA-CONSIDERATIONS]. The expert should be appointed by the Area
Director for the Applications Area. Any new field registered is
considered OPTIONAL by this specification unless a new version of
this memo is published.

New registrations MUST contain the following information:

1. Name of the DKIM failure type being registered

2. Short description of the failure type

3. The document in which the specification of the field is published

The initial registry should contain these values:

DKIM Failure Type: bodyhash
Description: The body hash in the signature and the body hash
computed by the verifier did not match.

o
Published in: [this document]

DKIM Failure Type: granularity -
Description: The key referenced by the signature on the message
was not authorized for use by the sending user.

o
Published in: [this document]

DKIM Failure Type: other -
Description: The signature verification process failed for a
reason not enumerated by some other registered DKIM
failure type.

o
Published in: [this document]

Shafranovich, et al. Expires July 6, 2009 [Page 19]

Internet-Draft Format for Feedback Reports January 2009

DKIM Failure Type: policy
Description: The DKIM Author Domain Signing Practises (ADSP)
evaluation failed.
Published in: [this document]

DKIM Failure Type: revoked -
Description: The key referenced by the signature on the message
has been revoked.

o
Published in: [this document]

DKIM Failure Type: signature -
Description: The signature on the message did not successfully
verify against the header hash and public key.

o
Published in: [this document]

DKIM Failure Type: syntax -
Description: The key referenced by the signature on the message,
or the signature itself, contained a syntax error.

9. Security Considerations
Published in: [this document]

Shafranovich, et al. Expires December 18, 2008 July 6, 2009 [Page 13] 20]

Internet-Draft Format for Feedback Reports June 2008

9.1. January 2009

6. Security Considerations

The following security considerations apply when generating or
processing a feedback report:

6.1. Inherited from RFC3462

All of the Security Considerations from [RFC3462] [REPORT] are inherited here.

9.2.

6.2. Interpretation

This specification describes a report format. This document does not
say what a recipient memo makes no
normative assertions of such a report must, should, or even may do
with any report kind about actions to be taken by
recipients of these reports. Actions taken by recipients are done
entirely at their own discretion.

There will be some desire to perform some actions in the format described here.

9.3. Envelope Sender Selection

When generating an ARF message, it is necessary automated
fashion in order to construct the
message so enact timely responses to common feedback
reports. Caution must be taken, however, as there is no substantial
security around the content of these reports. An attacker could
craft a report meant to avoid amplification attacks, generate undesirable actions on the part of a
report recipient.

It is recommended that ARF reports be vetted using common message
authentication schemes such as [DKIM], [SPF] or [SENDERID] to confirm
that they represent a valid message from the purported sender of the
report prior to the undertaking of any kind of automated action in
response to receipt of the report.

6.3. Envelope Sender Selection

When generating an ARF message, it is necessary to construct the
message so as to avoid amplification or backscatter attacks,
deliberate or otherwise. Thus, per Section 2 of [RFC3464], [DSN], the envelope
sender address of the ARF message SHOULD should be chosen to ensure that no
delivery status reports will be issued in response to the ARF message
itself, and MUST must be chosen so that these reports will not generate
mail loops. Whenever an SMTP transaction is used to send an ARF
message, the MAIL FROM command MUST must use a NULL return address, i.e.
"MAIL FROM:<>".

10. Acknowledgments

The authors would like to thank many of

6.4. Attacks Against Authentication Methods

If an attack becomes known against an authentication method, clearly
then the members agent verifying that method can be fooled into thinking an
inauthentic message is authentic, and thus the value of this header
field can be misleading. It follows that any attack against the email
community who provided helpful comments and suggestions for
authentication methods supported by this document including many of the participants (and later

Shafranovich, et al. Expires July 6, 2009 [Page 21]

Internet-Draft Format for Feedback Reports January 2009

amendments to it) is also a security consideration here.

6.5. Intentionally Malformed Reports

It is possible for an attacker to generate an ARF message field which
is extraordinarily large or otherwise malformed in ASRG, IETF and MAAWG
activities, and an attempt to
discover or exploit weaknesses in recipient parsing code.
Implementors must thoroughly verify all of the members of the abuse-feedback-report
public mailing list.

11. such messages and be robust
against intentionally as well as unintentionally malformed messages.

Shafranovich, et al. Expires July 6, 2009 [Page 22]

Internet-Draft Format for Feedback Reports January 2009

7. References

11.1.

7.1. Normative References

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

[RFC2046] Freed, N.

[ABNF] Crocker, D. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2046,
November 1996.

[RFC2119] 5234, January 2008.

[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach,

[MAIL] Resnick, P., "Internet Message Format", RFC 5322,
October 2008.

[MIME] Freed, N. and T. Berners-Lee, "Hypertext

Shafranovich, et al. Expires December 18, 2008 [Page 14]

Internet-Draft N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format for Feedback Reports June 2008

Transfer Protocol -- HTTP/1.1", of Internet Message
Bodies", RFC 2616, June 1999.

[RFC2821] 2045, November 1996.

[MIME-REG]
Freed, N. and J. Klensin, J., "Simple Mail Transfer Protocol", "Media Type Specifications and
Registration Procedures", RFC 2821,
April 2001.

[RFC2822] Resnick, P., "Internet Message Format", 4288, December 2005.

[MIME-TYPES]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2822,
April 2001.

[RFC3462] 2046,
November 1996.

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

[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464,
January 2003.

11.2.

7.2. Informative References

[ASRG_ABUSE]

[ASRG-ABUSE]
Anti-Spam Research Group (ASRG) of the Internet Research
Task Force (IRTF), "Abuse Reporting Standards Subgroup of oof
the ASRG", May 2005,
<http://asrg.sp.am/subgroups/abuse_reports.shtml>.

[AUTH-HEADER]
Kucherawy, M., "Message Header for Indicating Sender
Authentication Status",
draft-kucherawy-sender-auth-header-14 (work in progress).

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4871]

[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.

[RFC5226]

[DNS] Mockapetris, P., "Domain Names -- Implementation and
Specification", RFC 1035, November 1987.

[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464,
January 2003.

Shafranovich, et al. Expires July 6, 2009 [Page 23]

Internet-Draft Format for Feedback Reports January 2009

[HTTP] 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.

[I-D.DRAFT-CROCKER-EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture",
draft-crocker-email-arch (work in progress), May 2007.

[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status",
draft-kucherawy-sender-auth-header-18 (work in progress),
December 2008.

[IANA-CONSIDERATIONS]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

Shafranovich, et al. Expires December 18, 2008 [Page 15]

Internet-Draft Format for Feedback Reports June 2008

[STRADS_BCP]
Crissman, G., "Proposed Spam Reporting

[SENDERID]
Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.

[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.

[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.

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

[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986,
January 2005.

Shafranovich, et al. Expires July 6, 2009 [Page 24]

Internet-Draft Format for Feedback Reports January 2009

Appendix A. Acknowledgements

The authors would like to thank many of the members of the email
community who provided helpful comments and suggestions for this
document including many of the participants in ASRG, IETF and MAAWG
activities, and all of the members of the abuse-feedback-report
public mailing list.

Shafranovich, et al. Expires July 6, 2009 [Page 25]

Internet-Draft Format for Feedback Reports January 2009

Appendix A - B. Sample Feedback Reports

A.1.

This section presents some examples of the use of this message format
to report feedback about an arriving message.

B.1. Simple Report for Email Abuse without Optional Headers

Simple report:

Shafranovich, et al. Expires December 18, 2008 July 6, 2009 [Page 16] 26]

Internet-Draft Format for Feedback Reports June 2008 January 2009

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
192.0.2.1 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]) [192.0.2.1])
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--

Example 1: Required fields only

Illustration of a feedback report generated according to this

Shafranovich, et al. Expires December 18, 2008 July 6, 2009 [Page 17] 27]

Internet-Draft Format for Feedback Reports June 2008

A.2. January 2009

specification. Only the required fields are used.

B.2. Opt-Out Report without Message Body

A sample opt-out report

--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
192.0.2.1 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 text/rfc822-header

Example 2: An opt-out feedback report, which indicates the address of
a user who wishes to opt out of a mailing list

Shafranovich, et al. Expires December 18, 2008 July 6, 2009 [Page 18] 28]

Internet-Draft Format for Feedback Reports June 2008

A.3. January 2009

The report is generated as a result of a user indicating to its ISP
that it does not wish to receive further messages of this kind. The
report returned only the header block from the original message. The
report's recipient receives the address of the requesting user and
can use the header block and its own records to determine from which
distribution list the requesting user should be removed.

B.3. Full Report for Email Abuse with All Headers

A full email abuse report:

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

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

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
Source-IP: 10.67.41.167 192.0.2.1
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

From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
[10.67.41.167]) by

Shafranovich, et al. Expires July 6, 2009 [Page 29]

Internet-Draft Format for Feedback Reports January 2009

From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
[192.0.2.1]) 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

Shafranovich, et al. Expires December 18, 2008 [Page 19]

Internet-Draft Format for Feedback Reports June 2008
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--

Example 3: Generic abuse report with maximum returned information

A contrived example in which the report generator has returned all
possible information about an abuse incident.

B.4. Sample DKIM Failure Report

[TBD]

Shafranovich, et al. Expires July 6, 2009 [Page 30]

Internet-Draft Format for Feedback Reports January 2009

Appendix B. Status C. Public Discussion, History and Support

[REMOVE BEFORE PUBLICATION]

Public discussion of This Document [To Be Removed Upon Publication]

B.1. Discussion Venue

Discussion about this document should be directed to proposed specification is handled via the ABUSE-
FEEDBACK-REPORT
abuse-feedback-report@mipassoc.org mailing list. The 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 authors are always welcome (you can
send them via email open.
Access to <ietf@shaftek.org> and
<drafts@domain-assurance.org>).

B.2. Document Repository subscription forms and Public Website to list archives can be found at
http://mipassoc.org/mailman/listinfo/abuse-feedback-report. Active
participation has included such sectors as messaging software
vendors, messaging service providers, messaging consultants, anti-
spam vendors, large Internet service providers, etc.

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.

(impetus for the work should be discussed here)

(MAAWG activity should be discussed here)

Several companies have already adopted use of this proposal,
including large-scale e-mail hosting providers and Internet service
providers. For a list of these, see the PROTO document supporting
this draft.

Shafranovich, et al. Expires July 6, 2009 [Page 31]

Internet-Draft Format for Feedback Reports January 2009

Appendix D. 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:

Shafranovich, et al. Expires December 18, 2008 [Page 20]

Internet-Draft Format for Feedback Reports June 2008

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

o Added pointers to a public mailing list for discussion and public
web page 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 it.

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

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

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

o Added text to the the machine readable section clarifying its
intent. Also added RFC 2119 RFC2119 references, reorganized fields,
indicated whether specific header fields can appear more than once
and provided references as to how they should be formatted.

o Removed "Original-Message-ID", "Authenticated-Domain:" "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-URI", "Reported-Domain" and
"Authentication-Results".

o Example has been updated to reflect new headers. fields.

Shafranovich, et al. Expires July 6, 2009 [Page 32]

Internet-Draft Format for Feedback Reports January 2009

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. registry

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

Shafranovich, et al. Expires December 18, 2008 [Page 21]

Internet-Draft Format for Feedback Reports June 2008
draft-shafranovich-feedback-report-01:

o None significant (just a freshening)

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

o Much editorial cleanup

o Added John Levine and Paul Hoffman as co-authors

o Made the line lengths in Appendix A appropriate for RFCs

o Switched to symbolic names for references

o Reduced duplication of reference calls

o Removed text that specified the type of RFC and approval type that
is expected

o Removed the requirement for an RFC to update the IANA registries;
both are now designated expert approval only

o Added two new categories to the initial values for the "Feedback-
Type" registry: miscategorized "miscategorized" and not-spam "not-spam"

Changes from draft-shafranovich-feedback-report-02 to
draft-shafranovich-feedback-report-03:

o Added a bit to the Security Considerations section

o Updated obsolete references

Shafranovich, et al. Expires July 6, 2009 [Page 33]

Internet-Draft Format for Feedback Reports January 2009

o Resolved all items in the outstanding issues list and therefore
removed it

Changes from draft-shafranovich-feedback-report-03 to
draft-shafranovich-feedback-report-04:

o Added Murray Kucherawy as co-author

o Added support for DKIM reporting

o Cleaned up XML a lot

Changes from draft-shafranovich-feedback-report-04 to
draft-shafranovich-feedback-report-05:

Shafranovich, et al. Expires December 18, 2008 [Page 22]

Internet-Draft Format for Feedback Reports June 2008

o Add "Incidents" header

o RFC3464 replaces RFC1894

o RFC5226 replaces RFC2434

Still

Changes from draft-shafranovich-feedback-report-05 to be done:

o Add DKIM examples
draft-shafranovich-feedback-report-06:

o Add Remove Paul Hoffman as co-author, per his request

o Add ABNF specifications section

o Move MIME registration stuff from the earlier sections to the IANA
Considerations section

o Some other minor re-organization

o Add more stuff to Security Considerations

o Add more project history

o Overhaul the XML

o Add and update several references; use symbolic references instead
of numbered ones

o Use RFC3330 "TEST-NET" addresses in examples

o Fix some typos

Still to be done:

Shafranovich, et al. Expires July 6, 2009 [Page 34]

Internet-Draft Format for Feedback Reports January 2009

o Add a DKIM example

o Add explicit extension field and type support

Shafranovich, et al. Expires July 6, 2009 [Page 35]

Internet-Draft Format for Feedback Reports January 2009

Authors' Addresses

Yakov Shafranovich
SolidMatrix Technologies, Inc.
ShafTek Enterprises
4014 Labyrinth Rd.
Baltimore, MD 21215

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

John Levine
Domain Assurance Council
PO Box 727
Trumansburg, NY 14886

Phone: +1 831 480 2300
Email: john.levine@domain-assurance.org
URI: http://www.domain-assurance.org

Paul Hoffman
Domain Assurance Council

Email: paul.hoffman@domain-assurance.org
URI: http://www.domain-assurance.org

Murray S. Kucherawy
Sendmail, Inc.
6475 Christie Ave., Suite 350
Emeryville, CA 94608
US

Phone: +1 510 594 5400
Email: msk+ietf@sendmail.com

Shafranovich, et al. Expires December 18, 2008 [Page 23]

Internet-Draft Format for Feedback Reports June 2008

Full Copyright Statement

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.

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, THE IETF TRUST 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.

Intellectual Property

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.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Shafranovich, et al. Expires December 18, 2008 July 6, 2009 [Page 24] 36]

----