MARF Working Group Y. Shafranovich Internet-Draft ShafTek Enterprises Intended status: Standards Track J. Levine Expires: August 27, 2010 Domain Assurance Council M. Kucherawy Cloudmark February 23, 2010 An Extensible Format for Email Feedback Reports draft-ietf-marf-base-01 Abstract This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with 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 August 27, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Shafranovich, et al. Expires August 27, 2010 [Page 1] Internet-Draft Format for Feedback Reports February 2010 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 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 BSD License. Shafranovich, et al. Expires August 27, 2010 [Page 2] Internet-Draft Format for Feedback Reports February 2010 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 . . . . . . . . . . 6 3.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 6 3.2. Optional Fields Appearing Once . . . . . . . . . . . . . . 7 3.3. Optional Fields Appearing Multiple Times . . . . . . . . . 7 3.4. Notes About URIs . . . . . . . . . . . . . . . . . . . . . 8 3.5. Formal Definition . . . . . . . . . . . . . . . . . . . . 8 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 11 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.1. MIME Type Registration of 'message/feedback-report' . . . 13 6.2. Feedback Report Header Fields . . . . . . . . . . . . . . 14 6.3. Feedback Report Type Values . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.1. Inherited from RFC3462 . . . . . . . . . . . . . . . . . . 18 7.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 18 7.3. Envelope Sender Selection . . . . . . . . . . . . . . . . 18 7.4. Attacks Against Authentication Methods . . . . . . . . . . 18 7.5. Intentionally Malformed Reports . . . . . . . . . . . . . 19 7.6. Omitting Data from ARF Reports . . . . . . . . . . . . . . 19 7.7. Automatically Generated ARF Reports . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 Appendix B. Sample Feedback Reports . . . . . . . . . . . . . . . 23 B.1. Simple Report for Email Abuse without Optional Headers . . 23 B.2. Full Report for Email Abuse with All Headers . . . . . . . 25 Appendix C. Public Discussion, History and Support . . . . . . . 27 Appendix D. Document History . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Shafranovich, et al. Expires August 27, 2010 [Page 3] Internet-Draft Format for Feedback Reports February 2010 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 by creating 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 [REPORT]. 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, 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. 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; o To inform email service providers or other primarily outbound senders that there may be abuse issues regarding their mail; these issues include (but are not limited to) reports that the mail may be considered to be "spam" by a recipient of the message. 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 Shafranovich, et al. Expires August 27, 2010 [Page 4] Internet-Draft Format for Feedback Reports February 2010 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 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 August 27, 2010 [Page 5] Internet-Draft Format for Feedback Reports February 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 orignal 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 7 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.) Shafranovich, et al. Expires August 27, 2010 [Page 6] Internet-Draft Format for Feedback Reports February 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 which 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 August 27, 2010 [Page 7] Internet-Draft Format for Feedback Reports February 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.1.2 of [SMTP]. 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 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". 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 format of this field is defined in section 4.1.1.3 of that memo. This field SHOULD be repeated for every SMTP recipient seen by the report generator. Shafranovich, et al. Expires August 27, 2010 [Page 8] Internet-Draft Format for Feedback Reports February 2010 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 URI to which the report recipient can go for further details. 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: Shafranovich, et al. Expires August 27, 2010 [Page 9] Internet-Draft Format for Feedback Reports February 2010 feedback-report = *( feedback-type / user-agent / version ) opt-fields-once *( opt-fields-many ) 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] CRLF version = "Version:" [CFWS] token [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 [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 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-name [CFWS] CRLF reported-uri = "Reported-Domain:" [CFWS] URI [CFWS] CRLF Shafranovich, et al. Expires August 27, 2010 [Page 10] Internet-Draft Format for Feedback Reports February 2010 A set of fields satisfying this ABNF may appear in the transmitted message in any order. "CRLF" is imported from [ABNF]. "token" is imported from [MIME]. "product" is imported from [HTTP]. "mailbox", "CFWS" and "date-time" are imported from [MAIL]. "envelope-id" 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]. Shafranovich, et al. Expires August 27, 2010 [Page 11] Internet-Draft Format for Feedback Reports February 2010 4. 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 7.7). 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 August 27, 2010 [Page 12] Internet-Draft Format for Feedback Reports February 2010 5. 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) might be defined in the future by later revisions to this specification, or by type registrations as described above. Extension report types beginning with "x-" will never be defined as standard types; such names are reserved for experimental use. Result codes not beginning with "x-" MUST be registered as described above and appropriately published. Implementations using new report types MUST use the "x-" prefix until such time as the new type is registered by IANA. Extension types MUST only be used between ADMDs that have explicitly consented to use them. These types 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. Any MTA, MUA or filter intended for production use MUST ignore or reject any ARF report that uses an extension result. Shafranovich, et al. Expires August 27, 2010 [Page 13] Internet-Draft Format for Feedback Reports February 2010 6. IANA Considerations IANA is requested to register a new [MIME] type and create three new registries, as described below. 6.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 7 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 Murray S. Kucherawy Shafranovich, et al. Expires August 27, 2010 [Page 14] Internet-Draft Format for Feedback Reports February 2010 Intended usage: COMMON Author: Yakov Shafranovich John Levine Murray S. Kucherawy Change controller: IESG 6.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 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 IESG. 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 field being registered 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 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] Shafranovich, et al. Expires August 27, 2010 [Page 15] Internet-Draft Format for Feedback Reports February 2010 Field Name: Authentication-Results Description: results of authentication check(s) Multiple Appearances: Yes Related "Feedback-Type": any Published in: [this document] Field Name: Feedback-Type Description: registered feedback report type Multiple Appearances: No Related "Feedback-Type": N/A 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: 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: Received-Date Description: date/time the original message was received (historic; deprecated) Multiple Appearances: No Related "Feedback-Type": any 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 August 27, 2010 [Page 16] Internet-Draft Format for Feedback Reports February 2010 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 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 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 Published in: [this document] 6.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 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. Shafranovich, et al. Expires August 27, 2010 [Page 17] Internet-Draft Format for Feedback Reports February 2010 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 kind of email abuse Published in: [this document] Feedback Type Name: fraud Description: indicates some kind of fraud or phishing activity Published in: [this document] Feedback Type Name: other Description: any other feedback that does not fit into other registered types Published in: [this document] Feedback Type Name: virus Description: report of a virus found in the originating message Published in: [this document] Shafranovich, et al. Expires August 27, 2010 [Page 18] Internet-Draft Format for Feedback Reports February 2010 7. Security Considerations The following security considerations apply when generating or processing a feedback report: 7.1. Inherited from RFC3462 All of the Security Considerations from [REPORT] are inherited here. 7.2. Interpretation This specification describes a report format. This memo makes no normative assertions of any 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 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 recommended that the origin of an ARF report be vetted, such as by using common message authentication schemes like [DKIM], [SPF] or [SENDERID], prior to the undertaking of any kind of automated action in response to receipt of the report. The details of the required validation to achieve this are a matter of local policy and are thus outside the scope of this specification. 7.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 [DSN], 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:<>". 7.4. 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 Shafranovich, et al. Expires August 27, 2010 [Page 19] Internet-Draft Format for Feedback Reports February 2010 authentication method that might be used to protect the authenticity of an abuse report is also a security consideration here. 7.5. Intentionally Malformed Reports It is possible for an attacker to generate an ARF message field which is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in recipient parsing code. Implementors must thoroughly verify all such messages and be robust against intentionally as well as unintentionally malformed messages. 7.6. 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 may wish to redact portions of the report to conceal private information. Doing so may be necessary where privacy trumps operational necessity, but as mentioned in Section 2 it may impede a timely or meaningful response from the report recipient. 7.7. 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. Shafranovich, et al. Expires August 27, 2010 [Page 20] Internet-Draft Format for Feedback Reports February 2010 8. References 8.1. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [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. 8.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. Shafranovich, et al. Expires August 27, 2010 [Page 21] Internet-Draft Format for Feedback Reports February 2010 [AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [DNS] Mockapetris, P., "Domain Names -- Implementation and Specification", RFC 1035, November 1987. [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. [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. [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005. Shafranovich, et al. Expires August 27, 2010 [Page 22] Internet-Draft Format for Feedback Reports February 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 August 27, 2010 [Page 23] Internet-Draft Format for Feedback Reports February 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 August 27, 2010 [Page 24] Internet-Draft Format for Feedback Reports February 2010 From: Date: Thu, 8 Mar 2005 17:40:36 EDT Subject: FW: Earn money To: 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 --part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline From: 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: 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 August 27, 2010 [Page 25] Internet-Draft Format for Feedback Reports February 2010 specification. Only the required fields are used. B.2. Full Report for Email Abuse with All Headers A full email abuse report: From: Date: Thu, 8 Mar 2005 17:40:36 EDT Subject: FW: Earn money To: 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: Original-Rcpt-To: Received-Date: Thu, 8 Mar 2005 14:00:00 EDT Source-IP: 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: 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 August 27, 2010 [Page 26] Internet-Draft Format for Feedback Reports February 2010 To: 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 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. Shafranovich, et al. Expires August 27, 2010 [Page 27] Internet-Draft Format for Feedback Reports February 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 . A public website regarding this draft and related efforts is located at . (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 August 27, 2010 [Page 28] Internet-Draft Format for Feedback Reports February 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 August 27, 2010 [Page 29] Internet-Draft Format for Feedback Reports February 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 August 27, 2010 [Page 30] Internet-Draft Format for Feedback Reports February 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 August 27, 2010 [Page 31] Internet-Draft Format for Feedback Reports February 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". Shafranovich, et al. Expires August 27, 2010 [Page 32] Internet-Draft Format for Feedback Reports February 2010 Authors' Addresses Yakov Shafranovich 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 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 August 27, 2010 [Page 33]