MARF Working Group J. Falk Internet-Draft Return Path Updates: 5965 (if approved) M. Kucherawy, Ed. Intended status: Standards Track Cloudmark Expires: August 3, 2012 January 31, 2012 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) draft-ietf-marf-as-05 Abstract RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes common methods for utilizing this format for abuse reporting. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. 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 August 3, 2012. Copyright Notice Copyright (c) 2012 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 Falk & Kucherawy Expires August 3, 2012 [Page 1]
Internet-Draft ARF AS January 2012 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. 1. Introduction The Abuse Reporting Format (ARF) was initially developed for two very specific use cases. Initially, it was intended to be used for reporting feedback between large email operators, or from large email operators to end user network access operators, any of whom could be presumed to have automated abuse-handling systems. Secondarily, it is used by those same large mail operators to send those same reports to other entities, including those involved in sending bulk email for commercial purposes. In either case, the reports would be triggered by direct end user action such as clicking on a "report spam" button in their email client. Though other uses for the format defined in [RFC5965] have been discussed (and may be documented similarly in the future), abuse remains the primary application. The purpose for reporting abusive messages is to stop recurrences. The methods described in this document focus on automating abuse reporting as much as practical, so as to minimize the work of a site's abuse team. There are further reasons why abuse feedback generation is worthwhile, such as instruction of mail filters or reputation trackers, or to initiate investigations of particularly egregious abuses. These other applications are not discussed in this memo. Further introduction to this topic may be found in [RFC6449]. 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], and are intended to replace the Requirement Levels described in Section 3.3 of [RFC2026]. Some of the terminology used in this document is taken from [RFC5598]. "Mailbox Provider" refers to an organization that accepts, stores, and offers access to [RFC5322] messages ("email messages") for end users. Such an organization has typically implemented SMTP Falk & Kucherawy Expires August 3, 2012 [Page 2]
Internet-Draft ARF AS January 2012 ([RFC5321]), and might provide access to messages through IMAP ([RFC3501]), POP ([RFC1939]), a proprietary interface designed for HTTP ([RFC2616]), or a proprietary protocol. 3. Applicability Statement [RFC Editor: please remove this section prior to publication.] NOTE TO IESG: This document is part of the experiment to reintroduce Applicability Statements, as defined in Section 3.2 of [RFC2026], to the Applications Area. 4. Discussion [RFC Editor: please remove this section prior to publication.] This document is being discussed within the IETF MARF Working Group, on the marf@ietf.org mailing list. 5. Solicited and Unsolicited Reports The original application of [RFC5965], and still by far the most common, is when two mail systems make a private agreement to exchange abuse reports, usually reports due to recipients manually reporting messages as spam. We refer to these as solicited reports. Other uses for ARF involve reports sent between parties that don't know each other, with the recipient address typically being abuse@domain (see [RFC2142]), looked up via WHOIS, or using other heuristics. The reports may be manual, or automated due to hitting spam traps, or caused by anything else that the sender of the report considers to merit an abuse report. Abuse addresses in WHOIS records of the source IP and of the domain found in the results of a PTR ("reverse lookup") query on that address are likely reasonable candidates for receiving feedback about the message, although automated parsing may be difficult, and such addresses are not guaranteed to be useful. However, it is inadvisable to generate automated reports based on inline content analysis tools that apply subjective evaluation rules. This can cause reports that, because of their subjective nature, are not actionable by report receivers, which wastes valuable operator time in processing them. Falk & Kucherawy Expires August 3, 2012 [Page 3]
Internet-Draft ARF AS January 2012 6. Creating and Sending Complaint-Based Solicited Reports 1. A Mailbox Provider receives reports of abusive or unwanted mail from its users, most often by providing a "report spam" button (or similar nomenclature) in the MUA. The method of transferring this message and any associated metadata from the MUA to the Mailbox Provider's ARF processing system is not defined by any standards document, but is discussed further in Section 3.2 of [RFC6449]. Policy concerns related to the collection of this data are discussed in Section 3.4 of [RFC6449]. 2. The Mailbox Provider SHOULD process the reports to improve its spam filtering systems. The design of these systems is discussed in [RFC2505] and elsewhere. 3. The Mailbox Provider SHOULD send reports to relevant parties who have requested to receive such reports. The reports MUST be formatted per [RFC5965], and transmitted as an email message ([RFC5322]), typically using SMTP ([RFC5321]). The process whereby such parties may request the reports is discussed in Section 3.5 of [RFC6449]. 4. The reports SHOULD use "Feedback-Type: abuse", but MAY use other types as appropriate. However, the Mailbox Provider generating the reports SHOULD NOT assume that the operator receiving the reports will treat different Feedback-Types differently. 5. The reports SHOULD include the following optional fields whenever practical: Original-Mail-From, Arrival-Date, Source-IP, Original- Rcpt-To. Other optional fields MAY be included, as the implementer feels is appropriate. 6. Ongoing maintenance of an ARF processing system is discussed in Section 3.6 of [RFC6449]. 7. Reports MAY be subjected to redaction of user-identifiable data as described in [I-D.IETF-MARF-REDACTION]. 7. Receiving and Processing Complaint-Based Solicited Reports 1. At the time this document is being written, for the use cases described here, mail operators need to proactively request a stream of ARF reports from Mailbox Providers. Recommendations for preparing to make that request are discussed in Section 4.1 of [RFC6449]. 2. Mail operators MUST be prepared to receive reports formatted per [RFC5965] as email messages ([RFC5322]) over SMTP ([RFC5321]). These and other types of email messages that may be received are discussed in Section 4.2 of [RFC6449]. 3. Mail operators need to consider the idea of automating report processing. Discussion of this can be found in Section 4.4 of [RFC6449]. Falk & Kucherawy Expires August 3, 2012 [Page 4]
Internet-Draft ARF AS January 2012 4. An automated report processing system MUST accept all Feedback- Types defined in [RFC5965] or extensions to it, but implementers SHOULD NOT assume that Mailbox Providers will make use of any Feedback-Type other than "abuse". Additional logic may be required to separate different types of abuse reports after receipt. 5. Implementers SHOULD NOT expect all Mailbox Providers to include the same optional fields. 6. Actions that mail operators might take upon receiving a report (or multiple reports) are discussed in Section 4.3 of [RFC6449]. 7. Reports MAY be subjected to redaction of user-identifiable data as described in [I-D.IETF-MARF-REDACTION]. This is also discussed in Section 4.4 of [RFC6449]. Although the end user causing the report to be generated has been obscured, the report processor SHOULD attempt to correlate and prioritize reports that appear to have been caused by the same end user as it may be indicative of a problem worthy of increased attention. 8. Generating and Handling Unsolicited Reports 1. Systems that generate unsolicited reports SHOULD ensure that the criteria used to decide what messages to report accurately identify messages that the reporting entity believes in good faith are abusive. Such criteria might include direct complaint submissions from MUAs, reports triggered by mail sent to "spam trap" or "honeypot" addresses, reports of authentication failures, and virus reports. (These applications might be described in future IETF documents.) Systems SHOULD NOT report all mail sent from a particular sender merely because some of it is determined to be abusive. 2. With respect to authentication failures, these could occur for legitimate reasons outside of the control of the author. A report generator SHOULD be cautious to generate reports only in those cases where doing so highlights a serious problem, such as an ADSP ([RFC5617]) failure for a high-value spam target. 3. MUAs SHOULD NOT generate abuse reports directly to entities found in the message or by queries to WHOIS or other heuristic means. Rather, the MUA should signal, by some means, the mailbox provider to which it connects to generate such a report. 4. Report generators SHOULD send reports to recipients that are both responsible for the messages and are able to do something about them, and SHOULD NOT send reports to recipients that are uninvolved or only peripherally involved. For example, they SHOULD NOT send reports to the operator of every Autonomous System in the path between the apparent originating system and the operator generating the report. Falk & Kucherawy Expires August 3, 2012 [Page 5]
Internet-Draft ARF AS January 2012 5. Where an abusive message is signed using a domain-level authentication technology such as DKIM ([RFC6376]) or SPF ([RFC4408]), the domain that has been verified by the authentication mechanism is likely a reasonable candidate for receiving feedback about the message. However, this is not universally true, since sometimes the domain thus verified exists only to distinguish one stream of mail from another (see Section 2.5 of [RFC6377]), and cannot actually receive email. 6. Recipients of unsolicited ARF reports SHOULD, in general, handle them the same way as any other abuse reports. However, they MAY take advantage of the standardized parts of the ARF format to automate processing. Lacking knowledge about the sender of the report, they SHOULD separate valid from invalid reports by, for example, looking for references to IP ranges, domains, and mailboxes for which the recipient organization is responsible in the copy of the reported message, and by correlating multiple reports of similar messages to identify bulk senders. 7. Reports SHOULD use "Feedback-Type: abuse", but MAY use other types as appropriate. However, the Mailbox Provider generating the reports SHOULD NOT assume that the operator receiving the reports will treat different Feedback-Types differently. 8. Reports SHOULD include the following optional fields whenever practical: Original-Mail-From, Arrival-Date, Source-IP, Original-Rcpt-To. Other optional fields MAY be included, as the implementer feels is appropriate. 9. Per Section 4.4 of [RFC6449], a network service provider MAY use ARF data for automated forwarding of feedabck messages to the originating customer. 10. Published abuse mailbox addresses SHOULD NOT reject messages not in the ARF format, as generation of ARF messages can occasionally be unavailable or not applicable. Nevertheless, some large messaging service providers specifically request that abuse reports be sent to them in ARF format. Experience of systems that send abuse reports in ARF format suggests that even automated recipient systems that haven't asked for ARF format reports handle them at least as well as any other format such as plain text, with or without a copy of the message attached. This suggests use of ARF is advisable in most contexts. 11. This is, however, not universally true. Anyone sending unsolicited reports in ARF format can legitimately presume that recipients will not be able to see the ARF metadata (i.e., those elements present in the second part of the report), and instead MAY include all information needed in the human readable (first, text/plain) section of the report. Further, they MAY ensure that the report is readable when viewed as plain text, to give low-end ticketing systems as much assistance as possible. Finally, they need to be aware that the report could be discarded or ignored due to failure to take these steps in the Falk & Kucherawy Expires August 3, 2012 [Page 6]
Internet-Draft ARF AS January 2012 most extreme cases. 12. Although [RFC6449] suggests that replying to feedback is not useful, in the case of receipt of ARF reports where no feedback arrangement has been established, a reply might be desirable to indicate that the complaint will result in action, heading off more severe filtering from the report generator. Thus, a report generator sending unsolicited reports SHOULD ensure that a reply to such a report can be received. Where an unsolicited report results in the establishment of contact with a responsible and responsive party, this can be saved for future complaint handling and possible establishment of a formal (solicited) feedback arrangement. See Section 3.5 of [RFC6449] for a discussion of establishment of feedback arrangements. 13. Unsolicited reports will have no meaning if sent to abuse reporting addresses belonging to the abusive parties themselves. Reports SHOULD NOT be sent to such addresses if they can be identified beforehand. 9. IANA Considerations [RFC Editor: please remove this section prior to publication.] This document has no IANA actions. 10. Security Considerations Implementers are strongly urged to review, at a minimum, the Security Considerations sections of [RFC5965] and [RFC6449]. Report generators that relay user complaints directly, rather than by reference to a stored message (e.g., IMAP or POP), could be duped into sending a complaint about a message that the complaining user never actually received, as an attack on the purported originator of the falsified message. Report generators need to be resilient to such attack methods. 11. Acknowledgements The author and editor wish to thank Steve Atkins, John Levine, Shmuel Metz, and Alessandro Vesely for their contributions to this memo. All of the Best Practices referenced by this document are found in [RFC6449], written within the Collaboration Committee of the Messaging Anti-Abuse Working Group (MAAWG). Falk & Kucherawy Expires August 3, 2012 [Page 7]
Internet-Draft ARF AS January 2012 Finally, the original author wishes to thank the doctors and staff at the University of Texas MD Anderson Cancer Center for doing what they do. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010. 12.2. Informative References [I-D.IETF-MARF-REDACTION] Falk, JD. and M. Kucherawy, Ed., "Redaction of Potentially Sensitive Data from Mail Abuse Reports", I-D draft-ietf-marf-redaction, March 2011. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997. [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Falk & Kucherawy Expires August 3, 2012 [Page 8]
Internet-Draft ARF AS January 2012 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, September 2011. [RFC6449] Falk, J., "Complaint Feedback Loop Operational Recommendations", RFC 6449, November 2011. Authors' Addresses J.D. Falk Return Path 100 Mathilda Street, Suite 100 Sunnyvale, CA 94089 USA Email: ietf@cybernothing.org URI: http://www.returnpath.net/ M. Kucherawy (editor) Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US Email: msk@cloudmark.com Falk & Kucherawy Expires August 3, 2012 [Page 9]
