Network Working Group Y. Shafranovich
Internet-Draft SolidMatrix Technologies, Inc.
Intended status: Informational J. Levine
Expires: September 12, 2008 P. Hoffman
Domain Assurance Council
M. Kucherawy
Sendmail, Inc.
March 12, 2008
An Extensible Format for Email Feedback Reports
draft-shafranovich-feedback-report-04
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 is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with 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 August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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
Shafranovich, et al. Expires August 28, 2008 [Page 1]
Internet-Draft Format for Feedback Reports February 2008
Internet email.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Format of Email Feedback Reports . . . . . . . . . . . . . . . 4
5. Format of 'message/feedback-report' Content Type . . . . . . . 5
5.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 5
5.2. Optional Fields Appearing Once . . . . . . . . . . . . . . 6
5.3. Optional Fields Appearing Multiple Times . . . . . . . . . 7
6. MIME Type Registration of message/feedback-report . . . . . . 8
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Initial Values for the Header Names Registry . . . . . . . 10
8.2. Initial values for the "Feedback-Type" registry . . . . . 12
8.3. Initial values for the "DKIM Failure Type" registry . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Inherited from RFC3462 . . . . . . . . . . . . . . . . . . 13
9.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 13
9.3. Envelope Sender Selection . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Appendix A - Sample Feedback Reports . . . . . . . . 16
A.1. Simple Report for Email Abuse without Optional Headers . . 16
A.2. Opt-Out Report without Message Body . . . . . . . . . . . 17
A.3. Full Report for Email Abuse with All Headers . . . . . . . 18
Appendix B. Status of This Document [To Be Removed Upon
Publication] . . . . . . . . . . . . . . . . . . . . 19
B.1. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 19
B.2. Document Repository and Public Website . . . . . . . . . . 19
B.3. Document History . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Shafranovich, et al. Expires August 28, 2008 [Page 2]
Internet-Draft Format for Feedback Reports February 2008
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 the "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]. While there has been previous work in this area
([STRADS_BCP] and [ASRG_ABUSE]), 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 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].
This document only defines the format and 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
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 inform email service providers or other primarily outbound
senders that there may be issues regarding their mail. These
issues include (but are not limited to) reports that the mail may
Shafranovich, et al. Expires August 28, 2008 [Page 3]
Internet-Draft Format for Feedback Reports February 2008
be considered to be "spam" by a recipient of the message.
o To inform email service provides about opt-out requests
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] 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.
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
o A copy of the original email message (body and headers) or the
message headers must be enclosed in order to allow the receiver to
properly handle the report.
o The machine readable section must provide ability for 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 [RFC3462]). The following apply:
a. The "report-type" parameter of "multipart/report" type is set to
"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) 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.
Shafranovich, et al. Expires August 28, 2008 [Page 4]
Internet-Draft Format for Feedback Reports February 2008
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 [RFC2046]) OR a copy of the headers from the
original message with MIME content type of "text/rfc822-headers"
(as defined in [RFC3462]). This part MUST be included (unlike
[RFC3462]). 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.
e. Each feedback report MUST be related to only a SINGLE email
message. Summary and aggregate formats are outside the scope of
this specification.
f. The subject line of the feedback report SHOULD be the same as the
included email message 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.)
5. Format of 'message/feedback-report' Content Type
This content type provides a machine-readable section intended to let
the report generator convey metadata 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] header "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 these fields have a
syntax similar to those of mail message headers, 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. Required Fields
The following header fields are REQUIRED and MUST only appear once:
o "Feedback-Type:" - contains the type of feedback report (as
defined in the corresponding IANA registry). This is intended to
let report generators distinguish among different types of
Shafranovich, et al. Expires August 28, 2008 [Page 5]
Internet-Draft Format for Feedback Reports February 2008
reports.
o "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]. 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:" - 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".
The following header field SHOULD appear once in a DKIM failure
report:
o "DKIM-Failure:" - the type of DKIM verification failure that
occurred; MUST be included for "dkim" failure reports and MUST NOT
be included otherwise.
5.2. Optional Fields Appearing Once
The following header fields are OPTIONAL and MUST NOT appear more
than once:
o "Original-Envelope-Id:" - envelope ID string used in the original
SMTP transaction (see section 2.2.1 of [RFC3464].
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 [RFC2821].
o "Arrival-Date:" - indicates the date the original message was
received by recipient system's MTA. This field MUST be formatted
as per section 3.3 of [RFC2822].
o "Reporting-MTA:" - indicates the name of the MTA generating this
feedback report. This field is defined in section 2.2.2 of
[RFC3464], except that it is an optional field in this report.
o "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].
The historic field "Received-Date:" SHOULD also be accepted and
interpreted identically to "Arrival-Date:".
The following header fields are OPTIONAL and MAY each appear once in
Shafranovich, et al. Expires August 28, 2008 [Page 6]
Internet-Draft Format for Feedback Reports February 2008
a DKIM failure report:
o "DKIM-Canonicalized-Body:" - the canonicalized message body of a
message which failed DKIM verification, base64-encoded and line-
wrapped to remain inside [RFC2822] limits ("dkim" reports only).
base64 encoding is defined in [RFC2045].
o "DKIM-Canonicalized-Header:" - the canonicalized message header
block of a message which failed DKIM verification, base64-encoded
and line-wrapped to remain inside [RFC2822] limits; ("dkim"
reports only; SHOULD be present for those reports).
o "DKIM-Domain:" - the domain whose private key was used to sign a
message, taken from the signature's "d=" tag ("dkim" reports
only).
o "DKIM-Identity:" - the signing agent's identity, taken from the
signature's "i=" tag ("dkim" reports only).
o "DKIM-Selector:" - the selector referenced by a DKIM signature,
taken from the signature's "s=" tag ("dkim" reports only).
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 [AUTH-HEADER]. Report receivers
should note that this field only indicates an assertion made by
the report generator.
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.
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 [RFC1035].
o "Reported-URI:" - indicates a URI that the report generator
believes to be relevant to the report. URI format is defined in
[RFC3986].
o "Removal-Recipient:" - indicates the email address to be removed
from the mailing list (MUST only be used with "opt-out"). The
format of this field is defined in section 3.4.1 of RFC 2822.
Shafranovich, et al. Expires August 28, 2008 [Page 7]
Internet-Draft Format for Feedback Reports February 2008
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 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 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, and similar
organizations
Additional information: none
Person and email address to contact for further information: Yakov
Shafranovich <ietf@shaftek.org>
Intended usage: COMMON
Author: Yakov Shafranovich, John Levine, Paul Hoffman
Change controller: IESG
Shafranovich, et al. Expires August 28, 2008 [Page 8]
Internet-Draft Format for Feedback Reports February 2008
7. 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 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 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.
8. IANA Considerations
IANA is requested to register MIME type "message/feedback-report"
using the application provided in this document and setup three
registries: one for header field names, a second for "Feedback-Type"
values, and a third for "DKIM-Failure" values. This section contains
the templates used for registration of new entries in these
registries and their initial values. New registrations to these
registries MUST have approval by a Designated Expert in accordance
with the Expert Review guidelines as described in [RFC2434] (the
expert should be 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 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
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
Shafranovich, et al. Expires August 28, 2008 [Page 9]
Internet-Draft Format for Feedback Reports February 2008
If the header field being registered requires its own IANA registry,
than the appropriate registry MUST be properly defined.
For the feedback type registry, 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
for registration of these values is this document.
Field Name: Authentication-Results
Description: results of authentication check
Multiple Appearances: Yes
Related "Feedback-Type": any
Field Name: DKIM-Canonicalized-Body
Description: Canonicalized body, per DKIM, base64-encoded
Multiple Appearances: No
Related "Feedback-Type": dkim
Field Name: DKIM-Canonicalized-Header
Description: Canonicalized header block, per DKIM, base64-encoded
Multiple Appearances: No
Related "Feedback-Type": dkim
Field Name: DKIM-Domain
Description: selector from DKIM signature ("d=" signature tag value)
Multiple Appearances: No
Related "Feedback-Type": dkim
Shafranovich, et al. Expires August 28, 2008 [Page 10]
Internet-Draft Format for Feedback Reports February 2008
Field Name: DKIM-Failure
Description: registered DKIM failure type
Multiple Appearances: No
Related "Feedback-Type": dkim
Field Name: DKIM-Identity
Description: DKIM signing identity ("i=" signature tag value)
Multiple Appearances: No
Related "Feedback-Type": dkim
Field Name: DKIM-Selector
Description: selector from DKIM signature ("s=" signature tag value)
Multiple Appearances: No
Related "Feedback-Type": dkim
Field Name: Feedback-Type
Description: type of feedback report
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
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
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
Field Name: Arrival-Date
Description: date the original message was received
Multiple Appearances: No
Related "Feedback-Type": any
Field Name: Received-Date
Description: date the original message was received (historic;
deprecated)
Multiple Appearances: No
Related "Feedback-Type": any
Shafranovich, et al. Expires August 28, 2008 [Page 11]
Internet-Draft Format for Feedback Reports February 2008
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: 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
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 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 descriptions are provided below. The RFC
number used for registration of these values is this document.
o abuse - spam or some other kind of email abuse
o dkim - a DKIM signature verification error
o fraud - indicates some kind of fraud or phishing activity.
Shafranovich, et al. Expires August 28, 2008 [Page 12]
Internet-Draft Format for Feedback Reports February 2008
o miscategorized - indicates that the content categorization applied
in connection with a certification or reputation system was
incorrect
o not-spam - indicates that a message that was tagged or categorized
as spam (such as by an ISP) is not spam
o opt-out - a request to opt out from mailings from this provider.
o virus - report of a virus found in the originating message
o other - any other feedback that doesn't fit into other types.
8.3. Initial values for the "DKIM Failure Type" registry
The initial names and descriptions are provided below. The RFC
number used for registration of these values is this document.
o bodyhash - The body hash in the signature and the body hash
computed by the verifier did not match.
o granularity - The key referenced by the signature on the message
was not authorized for use by the sending user.
o other - The signature verification process failed for a reason not
enumerated by some other registered DKIM failure type.
o revoked - The key referenced by the signature on the message has
been revoked.
o signature - The signature on the message did not successfully
verify against the header hash and public key.
o syntax - The key referenced by the signature on the message, or
the signature itself, contained a syntax error.
9. Security Considerations
9.1. Inherited from RFC3462
All of the Security Considerations from [RFC3462] are inherited here.
9.2. Interpretation
This specification describes a report format. This document does not
say what a recipient of such a report must, should, or even may do
with any report in the format described here.
Shafranovich, et al. Expires August 28, 2008 [Page 13]
Internet-Draft Format for Feedback Reports February 2008
9.3. Envelope Sender Selection
When generating an ARF message, it is necessary to construct the
message so as to avoid amplification attacks, deliberate or
otherwise. Thus, per Section 2 of [RFC1894], the envelope sender
address of the ARF message SHOULD be chosen to ensure that no
delivery status reports will be issued in response to the ARF message
itself, and 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 use a NULL return address, i.e.
"MAIL FROM:<>".
10. Acknowledgments
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.
11. References
11.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 1894,
January 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] 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, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
Shafranovich, et al. Expires August 28, 2008 [Page 14]
Internet-Draft Format for Feedback Reports February 2008
April 2001.
[RFC3462] 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. Informative References
[ASRG_ABUSE]
Anti-Spam Research Group (ASRG) of the Internet Research
Task Force (IRTF), "Abuse Reporting Standards Subgroup of
the ASRG", May 2005,
<http://asrg.sp.am/subgroups/abuse_reports.shtml>.
[]
Kucherawy, M., "Message Header for Indicating Sender
Authentication Status",
draft-kucherawy-sender-auth-header-10 (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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[STRADS_BCP]
Crissman, G., "Proposed Spam Reporting BCP Document",
May 2005, <http://www.tmisnet.com/~strads/spam/bcp.html>.
Shafranovich, et al. Expires August 28, 2008 [Page 15]
Internet-Draft Format for Feedback Reports February 2008
Appendix A. Appendix A - Sample Feedback Reports
A.1. Simple Report for Email Abuse without Optional Headers
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
Shafranovich, et al. Expires August 28, 2008 [Page 16]
Internet-Draft Format for Feedback Reports February 2008
--part1_13d.2e68ed54_boundary--
A.2. Opt-Out Report without Message Body
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 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
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
--part1_13d.2e68ed54_boundary--
Shafranovich, et al. Expires August 28, 2008 [Page 17]
Internet-Draft Format for Feedback Reports February 2008
A.3. Full Report for Email Abuse with All Headers
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
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
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 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 August 28, 2008 [Page 18]
Internet-Draft Format for Feedback Reports February 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--
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 authors are always welcome (you can
send them via email to <ietf@shaftek.org> and
<drafts@domain-assurance.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:
Shafranovich, et al. Expires August 28, 2008 [Page 19]
Internet-Draft Format for Feedback Reports February 2008
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
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 left intact. Removed the convention for subject
lines that was defined in the previous version
o Added text to the 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 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.
Changes from draft-shafranovich-feedback-report-00 to
Shafranovich, et al. Expires August 28, 2008 [Page 20]
Internet-Draft Format for Feedback Reports February 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 and 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
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
Shafranovich, et al. Expires August 28, 2008 [Page 21]
Internet-Draft Format for Feedback Reports February 2008
Authors' Addresses
Yakov Shafranovich
SolidMatrix Technologies, Inc.
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.
Email: msk+ietf@sendmail.com
Shafranovich, et al. Expires August 28, 2008 [Page 22]
Internet-Draft Format for Feedback Reports February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 August 28, 2008 [Page 23]
