An Extensible Format for Email Feedback Reports
draft-ietf-marf-base-06
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5965.
|
|
|---|---|---|---|
| Authors | Murray Kucherawy , Yakov Shafranovich , John R. Levine | ||
| Last updated | 2020-01-21 (Latest revision 2010-05-21) | ||
| Replaces | draft-shafranovich-feedback-report | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5965 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Alexey Melnikov | ||
| Send notices to | ietf@cybernothing.org |
draft-ietf-marf-base-06
MARF Working Group Y. Shafranovich
Internet-Draft ShafTek Enterprises
Intended status: Standards Track J. Levine
Expires: November 22, 2010 Taughannock Networks
M. Kucherawy
Cloudmark
May 21, 2010
An Extensible Format for Email Feedback Reports
draft-ietf-marf-base-06
Abstract
This document defines an extensible format and MIME type that may be
used by mail operators to report feedback about received email to
other parties. This format is intended as a machine-readable
replacement for various existing report formats currently used in
Internet email.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 22, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Code Components extracted from this document must
Shafranovich, et al. Expires November 22, 2010 [Page 1]
Internet-Draft Format for Feedback Reports May 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2. E-mail Specific . . . . . . . . . . . . . . . . . . . 4
2. Format of Email Feedback Reports . . . . . . . . . . . . . . . 5
3. The 'message/feedback-report' Content Type . . . . . . . . . . 7
3.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 7
3.2. Optional Fields Appearing Once . . . . . . . . . . . . . . 8
3.3. Optional Fields Appearing Multiple Times . . . . . . . . . 8
3.4. Notes About URIs . . . . . . . . . . . . . . . . . . . . . 9
3.5. Formal Definition . . . . . . . . . . . . . . . . . . . . 9
4. Handling Malformed Reports . . . . . . . . . . . . . . . . . . 12
5. Transport Considerations . . . . . . . . . . . . . . . . . . . 13
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. MIME Type Registration of 'message/feedback-report' . . . 15
7.2. Feedback Report Header Fields . . . . . . . . . . . . . . 16
7.3. Feedback Report Type Values . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. Inherited from RFC3462 . . . . . . . . . . . . . . . . . . 21
8.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 21
8.3. Attacks Against Authentication Methods . . . . . . . . . . 21
8.4. Intentionally Malformed Reports . . . . . . . . . . . . . 22
8.5. Omitting Data from ARF Reports . . . . . . . . . . . . . . 22
8.6. Automatically Generated ARF Reports . . . . . . . . . . . 22
8.7. Attached Malware . . . . . . . . . . . . . . . . . . . . . 22
8.8. The User-Agent Field . . . . . . . . . . . . . . . . . . . 22
8.9. Malformed Messages . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Appendix B. Sample Feedback Reports . . . . . . . . . . . . . . . 27
B.1. Simple Report for Email Abuse without Optional Headers . . 27
B.2. Full Report for Email Abuse with All Headers . . . . . . . 29
Appendix C. Public Discussion, History and Support . . . . . . . 31
Appendix D. Document History . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Shafranovich, et al. Expires November 22, 2010 [Page 2]
Internet-Draft Format for Feedback Reports May 2010
1. Introduction
As the spam problem continues to expand and potential solutions
evolve, mail 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 uses the
"multipart/report" content type defined in [REPORT], and in that
context defines a standard extensible format by creating the
"message/feedback-report" [MIME] type for these reports.
While there has been previous work in this area (e.g. [STRADS-BCP]
and [ASRG-ABUSE]), none of them have yet been 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. This memo also contains provision
for extensions should other specific types of reports be desirable in
the future.
This document only defines the format and [MIME] content type to be
used for these reports. Determination of where these reports should
be sent, validation of their contents and how trust among report
generators and report recipients is established are outside the scope
of this document. It is assumed that best practices will evolve over
time, and will be codified in future documents.
1.1. Purpose
The reports defined in this document are intended to inform mail
operators about:
o email abuse originating from their networks;
o potential issues with the perceived quality of outbound mail, such
as email service providers sending mail that attracts the
attention of automated abuse detection systems.
Please note that while the parent "multipart/report" content type
defined in [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.
Shafranovich, et al. Expires November 22, 2010 [Page 3]
Internet-Draft Format for Feedback Reports May 2010
1.2. Requirements
The following requirements are necessary for feedback reports (the
actual specification is defined later in this document):
o They must be both human and machine readable;
o A copy of the original email message (both body and header) or the
message header must be enclosed in order to allow the receiver to
handle the report properly;
o The machine readable section must provide ability for the report
generators to share meta-data with 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
[EMAIL-ARCH] introduces several terms and concepts that are used in
this memo, and thus readers are advised to become familiar with it as
well.
Shafranovich, et al. Expires November 22, 2010 [Page 4]
Internet-Draft Format for Feedback Reports May 2010
2. 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 [REPORT]). The following apply:
a. The "report-type" parameter of the "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
in this memo) and MUST be included. This section is intended to
convey meta-data about the report in question that may not be
readily available from the included email message itself.
d. The third MIME part of the message is either of type "message/
rfc822" (as defined in [MIME-TYPES] and contains the original
message in its entirety, OR is of type "text/rfc822-headers" (as
defined in [REPORT] and contains a copy of the entire header
block from the original message. This part MUST be included
(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 as such modifications can impede
forensic work by the recipient of this report. See Section 8 for
further discussion.
e. Except as discussed below, each feedback report MUST be related
to only a single email message. Summary and aggregate formats
are outside of the scope of this specification.
f. The Subject header field of the feedback report SHOULD be the
same as the included email message about which the report is
being generated. If it differs, the difference MUST be limited
to only a typical forwarding prefix used by MUAs such as "FW:".
(Many smaller operators using MUAs for abuse handling rely on the
subject lines for processing.)
g. The primary evidence of the abuse being reported is found in the
third part of the report, which contains the original message.
The second part contains additional derived data that may help
the receiver, but in terms of selecting actionable report data,
report recipients SHOULD use the content of the third part first,
then data from the second part. The first part is meant to
contain explanantory text for human use but is not itself a part
Shafranovich, et al. Expires November 22, 2010 [Page 5]
Internet-Draft Format for Feedback Reports May 2010
of the report, and SHOULD NOT be used if it is in conflict with
the other parts.
Shafranovich, et al. Expires November 22, 2010 [Page 6]
Internet-Draft Format for Feedback Reports May 2010
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 meta-data to the report
receiver. The intent of this section is to convey information that
may not be obvious or may not be easily extracted from the original
email message body or header.
The body of this content type consists of multiple "fields" formatted
according to the ABNF of [MAIL] 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
in this memo. Although these fields have a syntax similar to those
of mail message header fields, they are semantically distinct; hence
they SHOULD NOT be repeated as header fields 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.
Note that the above limitation in no way restricts the use of message
header fields that are registered in the IANA header field registry
with the same field names.
3.1. Required Fields
The following report header fields MUST appear exactly once:
o "Feedback-Type" contains the type of feedback report (as defined
in the corresponding IANA registry and later in this memo). This
is intended to let report parsers distinguish among different
types of 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 [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" 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.]
Shafranovich, et al. Expires November 22, 2010 [Page 7]
Internet-Draft Format for Feedback Reports May 2010
3.2. Optional Fields Appearing Once
The following header fields are optional and MUST NOT appear more
than once:
o "Original-Envelope-Id" contains the envelope ID string used in the
original [SMTP] transaction (see section 2.2.1 of [DSN]).
o "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.2 of [SMTP] as
"Reverse-path".
o "Arrival-Date" indicates the date and time at which the original
message was received by the MTA of the generating ADMD
(Administrative Management Domain). This field MUST be formatted
as per section 3.3 of [MAIL].
o "Reporting-MTA" indicates the name of the MTA generating this
feedback report. This field is defined in section 2.2.2 of [DSN],
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 [SMTP].
o "Incidents" contains an unsigned 32-bit integer indicating the
number of incidents this report represents. The absence of this
field implies the report covers a single incident.
The historic field "Received-Date" SHOULD also be accepted and
interpreted identically to "Arrival-Date". However, if both are
present, the report is malformed and SHOULD be treated as described
in Section 4.
3.3. Optional Fields Appearing Multiple Times
The following set of header fields are optional and may appear any
number of times as appropriate:
o "Authentication-Results" indicates the result of one or more
authentication checks run by the report generator. The format of
this field is is defined in [AUTH-RESULTS]. Report receivers
should note that this field only indicates an assertion made by
the report generator.
o "Original-Rcpt-To" includes a copy of the email address used in
the RCPT TO portion of the original [SMTP] transaction. The
Shafranovich, et al. Expires November 22, 2010 [Page 8]
Internet-Draft Format for Feedback Reports May 2010
format of this field is a "Reverse-path" defined in section 4.1.2
of that memo. This field SHOULD be repeated for every SMTP
recipient seen by the report generator.
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. It is
unspecified how the report generator determines this information,
and thus the report receiver cannot be certain how it was chosen.
It is often used as a means of suggesting to the report receiver
how this report might be handled. In cases where the derivation
is not obvious, the report generator is encouraged to clarify in
the text section of the report. Domain format is defined in
section 2.3.1 of [DNS].
o "Reported-URI" indicates a URI that the report generator believes
to be relevant to the report, e.g. a suspect URI that was found in
the message that caused the report to be generated. The same
caveats about the origin of the value of "Reported-Domain" apply
to this field. URI format is defined in [URI].
3.4. Notes About URIs
Implementors should be aware that the Reported-URI field can carry
many different types of data depending on the URI scheme used. For
more information, please consult the URI Schemes registry maintained
by IANA.
Furthermore, it is outside the scope of this standard whether the
data carried in this field implies any additional information.
Implementors may negotiate their own agreements surrounding the
interpretation of this data.
3.5. 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 )
opt-fields-once
*( opt-fields-many )
*( ext-field )
feedback-type = "Feedback-Type:" [CFWS] token [CFWS] CRLF
; the "token" must be a registered feedback type as
; described elsewhere in this document
user-agent = "User-Agent:" [CFWS] product *( CFWS product )
Shafranovich, et al. Expires November 22, 2010 [Page 9]
Internet-Draft Format for Feedback Reports May 2010
[CFWS] CRLF
version = "Version:" [CFWS] %x31-%x39 *DIGIT [CFWS] CRLF
; as described above
opt-fields-once = [ arrival-date ]
[ incidents ]
[ original-envelope-id ]
[ original-mail-from ]
[ reporting-mta ]
[ source-ip ]
arrival-date = "Arrival-Date:" [CFWS] date-time CRLF
incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF
; must be a 32-bit unsigned integer
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-type [CFWS] ";"
[CFWS] mta-name [CFWS] CRLF
source-ip = "Source-IP:" [CFWS]
( IPv4-address-literal /
IPv6-address-literal ) [CFWS] CRLF
opt-fields-many = [ authres-header ]
[ original-rcpt-to ]
[ reported-domain ]
[ reported-uri ]
original-rcpt-to = "Original-Rcpt-To:" [CFWS]
forward-path [CFWS] CRLF
reported-domain = "Reported-Domain:" [CFWS]
domain [CFWS] CRLF
reported-uri = "Reported-URI:" [CFWS] URI [CFWS] CRLF
ext-field = field-name ":" unstructured
A set of fields satisfying this ABNF may appear in the transmitted
message in any order.
Shafranovich, et al. Expires November 22, 2010 [Page 10]
Internet-Draft Format for Feedback Reports May 2010
"CRLF" and "DIGIT" are imported from [ABNF].
"token" is imported from [MIME].
"product" is imported from [HTTP].
"field-name", "unstructured", "CFWS", "date-time" and "domain" are
imported from [MAIL].
"envelope-id", "mta-name-type" and "mta-name" are imported from
[DSN].
"reverse-path", "forward-path", "local-part", "IPv4-address-literal"
and "IPv6-address-literal" are imported from [SMTP].
"URI" is imported from [URI].
"authres-header" is imported from [AUTH-RESULTS].
"ext-field" refers to extension fields, which are discussed in
Section 6.
Shafranovich, et al. Expires November 22, 2010 [Page 11]
Internet-Draft Format for Feedback Reports May 2010
4. Handling Malformed Reports
When an agent that accepts and handles ARF messages receives a
message that purports (by MIME type) to be an ARF message but
syntactically deviates from this specification, that agent SHOULD
ignore or reject the message. Where rejection is performed, the
rejection notice (either via an [SMTP] reply or generation of a
[DSN]) SHOULD identify the specific cause for the rejection.
See Section 8.9 for further discussion.
Shafranovich, et al. Expires November 22, 2010 [Page 12]
Internet-Draft Format for Feedback Reports May 2010
5. Transport Considerations
[DSN] requires that its reports be sent with the empty [SMTP]
envelope sender to avoid bounce loops. A similar requirement was
considered for this specification, but it seems unlikely that an ARF
report would be generated in response to receipt of an ARF report,
and furthermore such a requirement would prevent an ARF generator
from ever determining that an ARF report was not actually received.
On the other hand, if an ARF report is generated without the empty
envelope sender and is sent to an address that actually does not
work, then the generating address can also be overwhelmed by DSNs as
a denial of service attack (see Section 8.6).
This specification therefore makes no requirement related to the
envelope sender of a generated report. Operators will have to
consider what envelope sender to use within the context of their own
installations.
Shafranovich, et al. Expires November 22, 2010 [Page 13]
Internet-Draft Format for Feedback Reports May 2010
6. 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 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 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 or report types they do
not explicitly support.
Additional report types (extension report types) or report header
fields might be defined in the future by later revisions to this
specification, or by registrations as described above. Such types
and fields MUST be registered as described above and published in an
Open Specification such as an RFC.
Experimental report types and report header fields MUST only be used
between ADMDs that have explicitly consented to use them. These
names and the parameters associated with them are not documented in
RFCs. Therefore, they are subject to change at any time and not
suitable for general use.
Shafranovich, et al. Expires November 22, 2010 [Page 14]
Internet-Draft Format for Feedback Reports May 2010
7. IANA Considerations
IANA is requested to register a new [MIME] type and create three new
registries, as described below.
7.1. MIME Type Registration of 'message/feedback-report'
This section provides the media type registration 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 MUST be
used to maintain readability when viewed by non-MIME mail readers.
Security considerations: See Section 8 of [this document].
Interoperability considerations: Implementors MUST ignore any fields
they do not support.
Published specification: [this document]
Applications that 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@cloudmark.com>
Shafranovich, et al. Expires November 22, 2010 [Page 15]
Internet-Draft Format for Feedback Reports May 2010
Intended usage: COMMON
Author:
Yakov Shafranovich
John Levine
Murray S. Kucherawy
Change controller: IESG
7.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, as defined by this memo.
New registrations or updates MUST be published in accordance with the
"Specification Required" guidelines as described in
[IANA-CONSIDERATIONS]. Any new field thus registered is considered
optional by this specification unless a new version of this memo is
published.
New registrations and updates MUST contain the following information:
1. Name of the field being registered or updated
2. Short description of the field
3. Whether the field can appear more than once
4. To which feedback type(s) this field applies (or "any")
5. The document in which the specification of the field is published
6. New or updated status, which MUST be one of:
current: The field is in current use
deprecated: The field is in current use but its use is
discouraged
historic: The field is no longer in current use
An update may make a notation on an existing registration indicating
that a registered field is historic or deprecated if appropriate.
Shafranovich, et al. Expires November 22, 2010 [Page 16]
Internet-Draft Format for Feedback Reports May 2010
The initial registry should contain these values:
Field Name: Arrival-Date
Description: date/time the original message was received
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]
Status: current
Field Name: Authentication-Results
Description: results of authentication check(s)
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [this document]
Status: current
Field Name: Feedback-Type
Description: registered feedback report type
Multiple Appearances: No
Related "Feedback-Type": N/A
Published in: [this document]
Status: current
Field Name: Incidents
Description: expression of how many similar incidents are
represented by this report
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]
Status: current
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]
Status: current
Shafranovich, et al. Expires November 22, 2010 [Page 17]
Internet-Draft Format for Feedback Reports May 2010
Field Name: Original-Rcpt-To
Description: email address used in the RCPT TO portion of the
original SMTP transaction
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [this document]
Status: current
Field Name: Received-Date
Description: date/time the original message was received
(replaced by "Arrival-Date")
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]
Status: historic
Field Name: Reported-Domain
Description: a domain name the report generator considers to
be key to the message about which a report is
being generated
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [this document]
Status: current
Field Name: Reported-URI
Description: a URI the report generator considers to be key
to the message about which a report is being
generated
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [this document]
Status: current
Field Name: Reporting-MTA
Description: MTA generating this report
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]
Status: current
Shafranovich, et al. Expires November 22, 2010 [Page 18]
Internet-Draft Format for Feedback Reports May 2010
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]
Status: current
Field Name: User-Agent
Description: name and version of the program generating the
report
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]
Status: current
Field Name: Version
Description: version of specification used
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [this document]
Status: current
7.3. Feedback Report Type Values
IANA is requested to create the "Feedback Report Type Values"
registry. This registry will contain feedback types for use in
feedback reports, defined by this memo.
New registrations or updates MUST be published in accordance with the
"Specification Required" guidelines as described in
[IANA-CONSIDERATIONS]. Any new field thus 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 feedback type being registered
2. Short description of the feedback type
3. The document in which the specification of the field is published
4. New or updated status, which MUST be one of:
Shafranovich, et al. Expires November 22, 2010 [Page 19]
Internet-Draft Format for Feedback Reports May 2010
current: The field is in current use
deprecated: The field is in current use but its use is
discouraged
historic: The field is no longer in current use
The initial registry should contain these values:
Feedback Type Name: abuse
Description: unsolicited email or some other kind of email abuse
Published in: [this document]
Status: current
Feedback Type Name: fraud
Description: indicates some kind of fraud or phishing activity
Published in: [this document]
Status: current
Feedback Type Name: other
Description: any other feedback that does not fit into other
registered types
Published in: [this document]
Status: current
Feedback Type Name: virus
Description: report of a virus found in the originating message
Published in: [this document]
Status: current
Shafranovich, et al. Expires November 22, 2010 [Page 20]
Internet-Draft Format for Feedback Reports May 2010
8. Security Considerations
The following security considerations apply when generating or
processing a feedback report:
8.1. Inherited from RFC3462
All of the Security Considerations from [REPORT] are inherited here.
8.2. Interpretation
This specification describes a report format. The authentication and
validity of the content of the report SHOULD be established through
other means. The content of an unvetted report could be wrong,
incomplete or deliberately false, including the alleged abuse
incident in the third part, derived data in the second part or the
human readable first part.
There will be some desire to perform some actions in an automated
fashion in order to 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 generate undesirable actions on the part of a
report recipient.
It is suggested that the origin of an ARF report be vetted, such as
by using common message authentication schemes like [SMIME], [DKIM],
[SPF] or [SENDERID], prior to the undertaking of any kind of
automated action in response to receipt of the report. In
particular, S/MIME offers the strongest authentication and the cost
of key exchange is assumed in the process of establishing a bi-
lateral reporting relationship that uses this specification; however,
it is not as transparent as the others and thus will interfere with
the parsing capabilities of code that is designed specifically to
handle multipart/report messages.
The details of the required validation to achieve this are a matter
of local policy and are thus outside the scope of this specification.
8.3. Attacks Against Authentication Methods
If an attack becomes known against an authentication method, clearly
then the 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 an
authentication method that might be used to protect the authenticity
of an abuse report is also a security consideration here.
Shafranovich, et al. Expires November 22, 2010 [Page 21]
Internet-Draft Format for Feedback Reports May 2010
8.4. Intentionally Malformed Reports
It is possible for an attacker to generate an ARF message field that
is extraordinarily large or otherwise malformed in an attempt to
discover or exploit weaknesses in recipient parsing code.
Implementors SHOULD thoroughly verify all such messages and be robust
against intentionally as well as unintentionally malformed messages.
8.5. Omitting Data from ARF Reports
The sending of these reports can reveal possibly private information
about the person sending the report. For example, such a report sent
in response to a mailing list posting will reveal to the report
recipient a valid email address on the list that might otherwise have
remained hidden.
For this reason, report generators might wish to redact portions of
the report to conceal private information. Doing so could be
necessary where privacy trumps operational necessity, but as
mentioned in Section 2 it might impede a timely or meaningful
response from the report recipient.
8.6. Automatically Generated ARF Reports
Systems have been implemented that generate ARF reports automatically
in response to an event. For example, software monitoring a honeypot
email address might generate an ARF report immediately upon delivery
of any message to it. An attacker that becomes aware of such a
configuration can exploit it to attack an ARF recipient with
automatically generated ARF reports.
8.7. Attached Malware
As this format is sometimes used to automatically report malware, ARF
processors (human or otherwise) SHOULD ensure that attachments are
processed in a manner appropriate for unverified and potentially
hostile data.
8.8. The User-Agent Field
Further to Section 8.2, the User-Agent field is an assertion of the
generating software and is neither specified in this memo nor derived
from the message represented in the third part of the report. It is
intended for documentation and debugging, and since it is trivially
forged by a malicious agent, it SHOULD NOT be interpreted by
recipients.
Shafranovich, et al. Expires November 22, 2010 [Page 22]
Internet-Draft Format for Feedback Reports May 2010
8.9. Malformed Messages
Further to the discussion in Section 4, there might be cases where an
ARF processing agent elects to accept messages not consistent with
this specification, such as during transition periods where some
fields are moving toward "historic" or "deprecated" status, or the
introduction of new non-standard extension or experimental fields.
Such choices need to be implemented with extreme caution; where two
different fields have related meaning (e.g. "Received-Date", which
is historic, and "Arrival-Date", which is current), an attacker could
craft a report that makes a confusing claim in an attempt to exploit
such liberal parsing logic.
Shafranovich, et al. Expires November 22, 2010 [Page 23]
Internet-Draft Format for Feedback Reports May 2010
9. References
9.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[AUTH-RESULTS]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009.
[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.
[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.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[MAIL] Resnick, P., "Internet Message Format", RFC 5322,
October 2008.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[MIME-REG]
Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, December 2005.
[MIME-TYPES]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages",
RFC 3462, January 2003.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
Shafranovich, et al. Expires November 22, 2010 [Page 24]
Internet-Draft Format for Feedback Reports May 2010
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986,
January 2005.
9.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.
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009.
[IANA-CONSIDERATIONS]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008.
[SENDERID]
Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[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.
Shafranovich, et al. Expires November 22, 2010 [Page 25]
Internet-Draft Format for Feedback Reports May 2010
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 November 22, 2010 [Page 26]
Internet-Draft Format for Feedback Reports May 2010
Appendix B. Sample Feedback Reports
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 November 22, 2010 [Page 27]
Internet-Draft Format for Feedback Reports May 2010
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
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 [NOTE TO RFC EDITOR: CHANGE TO "1" FOR PUBLICATION]
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline
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
From: <somespammer@example.net>
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 November 22, 2010 [Page 28]
Internet-Draft Format for Feedback Reports May 2010
specification. Only the required fields are used.
B.2. Full Report for Email Abuse with All Headers
A full email abuse report:
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
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
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
Reporting-MTA: dns; mail.example.com
Source-IP: 192.0.2.1
Authentication-Results: mail.example.com;
spf=fail smtp.mail=somespammer@example.com
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
[192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
Thu, 08 Mar 2005 14:00:00 -0400
Shafranovich, et al. Expires November 22, 2010 [Page 29]
Internet-Draft Format for Feedback Reports May 2010
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: Generic abuse report with maximum returned information
A contrived example in which the report generator has returned all
possible information about an abuse incident.
Shafranovich, et al. Expires November 22, 2010 [Page 30]
Internet-Draft Format for Feedback Reports May 2010
Appendix C. Public Discussion, History and Support
[REMOVE BEFORE PUBLICATION]
Public discussion of this proposed specification is handled via the
abuse-feedback-report@mipassoc.org mailing list. The list is open.
Access to subscription forms and 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/>.
(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 November 22, 2010 [Page 31]
Internet-Draft Format for Feedback Reports May 2010
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:
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 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 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" 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 fields.
Shafranovich, et al. Expires November 22, 2010 [Page 32]
Internet-Draft Format for Feedback Reports May 2010
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
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
Shafranovich, et al. Expires November 22, 2010 [Page 33]
Internet-Draft Format for Feedback Reports May 2010
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:
o Add "Incidents" header
o RFC3464 replaces RFC1894
o RFC5226 replaces RFC2434
Changes from draft-shafranovich-feedback-report-05 to
draft-shafranovich-feedback-report-06:
o Remove Paul Hoffman as co-author, per his request
o Add ABNF 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
Changes from draft-shafranovich-feedback-report-06 to
draft-shafranovich-feedback-report-07:
Shafranovich, et al. Expires November 22, 2010 [Page 34]
Internet-Draft Format for Feedback Reports May 2010
o I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER published as RFC5451
Changes from draft-shafranovich-feedback-report-07 to
draft-shafranovich-feedback-report-08:
o None.
Changes from draft-shafranovich-feedback-report-08 to
draft-ietf-marf-base-00:
o Renamed given the formation of the working group.
o Remove all report types apart from the basic ones known to be in
use today. The rest can be added back via extension memos.
o I-D.DRAFT-CROCKER-EMAIL-ARCH published as RFC5598.
o Copy extensibility language from RFC5451.
o Other minor copy editing.
Changes from draft-ietf-marf-base-00 to draft-ietf-marf-base-01:
o Reword Security Considerations segment about redacted data.
o Add "Notes about URIs".
o Add "Transport Considerations".
o Add notes about auto-generated ARFs under Security Considerations.
o Make some references normative.
o Update STRADS URL reference.
o Various wordsmithing.
o Extend about "Reported-Domain".
Changes from draft-ietf-marf-base-01 to draft-ietf-marf-base-02:
o Correct ABNF for "reported-uri".
Changes from draft-ietf-marf-base-02 to draft-ietf-marf-base-03:
o Remove "Envelope Sender Selection" section.
Shafranovich, et al. Expires November 22, 2010 [Page 35]
Internet-Draft Format for Feedback Reports May 2010
o Fix "Authentication-Results" and "From" fields in example.
o Tighten up definition of "Reported-URI".
o Discuss registration updates that declare report as either
historic or deprecated.
o Add "Attached Malware" section.
o Several edits in "Extensions" section.
o Reword "Purpose".
o Minor grammar nits.
Changes from draft-ietf-marf-base-03 to draft-ietf-marf-base-04:
o Fix references to RFC5321 ABNF
o Fix ABNF for user-agent, version, arrival-date, domain
o Change registrations from Designated Expert to Specification
Required
o Add a "status" field to both registries
o Add "Incidents" to the registry
o Add better descriptions for "abuse", "Reporting-Domain" and
"Reporting-URI" in the registries
o Make some references normative
Changes from draft-ietf-marf-base-04 to draft-ietf-marf-base-05:
o Another change to version ABNF
o Remove "x-" prefix stuff in Extensibility
o Update John Levine's contact info
o Add an example use of "Reporting-MTA"
o Add "ext-field" ABNF
o Add guidance about intepreting the various MIME parts
Shafranovich, et al. Expires November 22, 2010 [Page 36]
Internet-Draft Format for Feedback Reports May 2010
o Add reference to S/MIME
o Add commentary on User-Agent forgery in Security Considerations
o Slight fix to Introduction regarding scope
Changes from draft-ietf-marf-base-05 to draft-ietf-marf-base-06:
o Add discussion of malformed message handling
o Example should use Arrival-Date
o Registry should show Received-Date as historic
Shafranovich, et al. Expires November 22, 2010 [Page 37]
Internet-Draft Format for Feedback Reports May 2010
Authors' Addresses
Yakov Shafranovich
ShafTek Enterprises
4014 Labyrinth Rd.
Baltimore, MD 21215
Email: ietf@shaftek.org
URI: http://www.shaftek.org
John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
Phone: +1 831 480 2300
Email: standards@taugh.com
Murray S. Kucherawy
Cloudmark
128 King St., 2nd Floor
San Francisco, CA 94107
US
Phone: +1 415 946 3800
Email: msk@cloudmark.com
Shafranovich, et al. Expires November 22, 2010 [Page 38]