Network Working Group A. Vesely Internet-Draft September 3, 2011 Intended status: BCP Expires: March 6, 2012 Abuse Reporting draft-vesely-marf-abuse-reporting-00 Abstract This documents covers issues of spam reporting by the general public. The Abuse Reporting Format (ARF) was originally developed for use by large operators. However, abuse reporting is also useful for medium and small operators. The need to automate abuse reporting originates from the volume of spam, not the size of the operators. 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 March 6, 2012. Copyright Notice Copyright (c) 2011 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 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Vesely Expires March 6, 2012 [Page 1] Internet-Draft Abuse Reporting September 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Starting The Abuse Reporting Mechanism . . . . . . . . . . . . 3 4. Forwarding Abuse Reports From Local Users . . . . . . . . . . . 4 5. Receiving Abuse Reports From Other Mailbox Providers . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Vesely Expires March 6, 2012 [Page 2] Internet-Draft Abuse Reporting September 2011 1. Introduction The Abuse Reporting Format, [ARF], was originally developed for use by large operators. However, abuse reporting is also useful for medium and small operators. The need to automate abuse reporting originates from the volume of spam, not the size of the operators. An abuse report is started by a recipient, or an automated tool acting on recipient's behalf. Either agent recognizes the abusive nature of a message, without the need to investigate about its origin. Such first step is followed by a second step, carried out on the recipient's server side, which determines whether the abuse ought to be reported upstream. The second step has to clear any issues about authenticity of messages, trustworthiness of senders, privacy requirements, and the email address of the target abuse team. The purpose for reporting an abuse to its origin is to stop recurrences. The practices described in this document focus on automating abuse reporting as much possible, so as to minimize the work of a site's abuse team. There are further reasons why it is worth to generate and forward abuse reports, such as instructing mail filters, or notifying reputation trackers or law enforcement agencies; such reasons are beyond the scope of this document. 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 RFC 2119 [RFC2119]. Mailbox provider is defined in [FBL]. It includes email facilities in corporations, universities, and similar organizations. 3. Starting The Abuse Reporting Mechanism User support for automatic or one-click abuse reporting has to be supported by both the Mail User Agent (MUA) and the Mailbox Provider (MP) in order to be effective. In the absence of it, users should seek advice from their MPs. Expert users MAY act as if they were their own MP, but the rest of this section assumes that MUAs report abuse to the user's MP. A MUA can report abuse using any method that the relevant MP supports. The advantage of using methods that refer to messages stored on the server, such as [IMAP-SREP] or a web interface, is twofold: it identifies which is the relevant server, and avoids Vesely Expires March 6, 2012 [Page 3] Internet-Draft Abuse Reporting September 2011 transferring message contents. Otherwise, if a MUA downloads messages from multiple servers, it MAY identify the relevant server from the Authentication-Results header fields added there, locating them as discussed in [A-R]. Such fields include the id of the authentication server ("authserv-id" in [A-R]) which may or may not be a DNS domain. In case it matches the domain name configured for an outbound mail server, a MUA MAY assume that it has a mailbox for the abuse role as described in [MAILBOX-NAMES], and report abuse there. MPs who add Authentication-Results header fields to the header of (some) received messages and don't support abuse reporting as described in the previous paragraph SHOULD NOT set an authserv-id that matches the domain name of any of their mail servers. In any case, this first step of abuse reporting SHOULD happen in an authenticated context. If a MUA submits abuse reports via [SMTP] or [SUBMIT], it SHOULD use [ARF] or an equivalent format specifically designed for reporting abuse, in order to allow automatic processing of the report. Abuse reports sent via SMTP or SUBMIT without using an abuse-specific format MUST include the abusive message as a message/rfc822 entity (sometimes called "as attachment") and SHOULD be limited to one of the following circumstances: o no tools are available for producing any acceptable abuse-specific format, o the report is being submitted to an address whose owner is giving explicit instructions of not using any abuse-specific format, or o the reporter has relevant information about the abuse, which cannot be correctly compiled into the fields of any abuse-specific format available, and writes that info for the convenience of the abuse team, so that the report needs to be dealt with manually. 4. Forwarding Abuse Reports From Local Users Mailbox Providers (MPs) SHOULD dedicate an email address for abuse reports from their users. The "abuse@domain" role address defined in [MAILBOX-NAMES] MAY be used, as long as messages delivered there can be correctly distinguished from other messages being delivered at the same address. An MP MAY forward an abuse report to the abuse team at the domain where the reported message originated from. MPs MAY also use reports Vesely Expires March 6, 2012 [Page 4] Internet-Draft Abuse Reporting September 2011 to instruct their mail filtering system or their firewall, but the rest of this section assumes that they are willing to forward a report, and describes possible ways for doing it. MPs SHOULD perform any possible checks to ascertain that the reported message really originated at the domain they intend to forward it to. This includes checking that the reporting user did not inadvertently or maliciously alter the reported message. MPs MAY digitally sign received messages on delivery in order to ease this check. If the reported message can be successfully authenticated by [DKIM] or [SPF] methods, an MP MAY use the corresponding domain as a destination candidate. In this case, the existence of a feedback loop SHOULD be checked, as described in [FBL]. If an MP discovers the existence of a feedback loop, the report MAY be forwarded as described there. Otherwise, the IP address of the last external host that relayed the message can be used. Looking up the address using rDNS may allow to infer a candidate domain name. Querying the database of the Regional Internet Registry (RIR) of the relevant region may allow to locate the Point Of Contact (POC) of the abuse team directly. All that failing, it is still possible, but NOT RECOMMENDED, to blindly use the abuse@domain address for the originating domain, or the postmaster address (without domain-part) at the service listening on port 25 on the host who relayed the reported message, if any such service exists. An MP should evaluate the trustworthiness of the target abuse team, possibly using external reputation providers. It is not worth to send any information to domains that exist for the sole purpose of spamming. An MP MAY redact the reported message, according to its policy and to the reputation of the destination. Redacting techniques are discussed in [REDACT]. An MP SHOULD manually inspect the reported message if its spam score is noticeably low --which might indicate that the user hit the spam- button by mistake. Manual inspection is also RECOMMENDED for abuse reports not using an abuse-specific format such as ARF. Abuse reports automatically forwarded to a remote abuse team, SHOULD be formatted according to [ARF]. Reports thus forwarded SHOULD be DKIM-signed, and transmitted from a host that has full SPF permissions. An MP MAY keep track of the domains whose abuse teams have been the targets of forwarded abuse reports. If doing so, the [SMTP] envelope sender of outgoing abuse reports MAY be set so as to get possible Delivery Status Notifications [DSN] and thus avoid repeatedly sending to bad addresses. The Reply-To header field MAY be set if an Vesely Expires March 6, 2012 [Page 5] Internet-Draft Abuse Reporting September 2011 acknowledge is desired. 5. Receiving Abuse Reports From Other Mailbox Providers It is obviously up to each site to specify their policy, including any provisions to avoid that people may use their site for spamming and get away with it. An abuse report may indicate that such a policy was contravened, and it may also lead to the discovery of more serious incidents. Otherwise, it may be a false positive, either due to an error of the agent who started reporting of the message, whether interactively or not. Finally, an abuse report may also be forged in a malicious attempt to trigger specific action, or simply to spam the abuse team itself. The latter cases, like defects discovered during quality tests, deserve being dispatched exemplarily, for example having the relevant account terminated, or firewalling the relevant IP addresses. A Mailbox Provider who knows the true identity of its users may forward genuine abuse reports to the authors of the reported messages, asking them to either acknowledge that they contravened a policy, or challenge the report. The obvious correction for an acknowledged policy contravention is to remove the email address of the original recipient from whatever storage it was retrieved from for sending the reported message, including mailing lists. A challenged report may require the abuse team to actually inspect it, or the remote abuse reporter to acknowledge that he or she started the abuse report by mistake. A policy might provide for prohibiting a user from sending for an amount of time proportional to the number of acknowledged abuse reports. Such a policy is not going to be very effective for sites that allow creating new mailboxes anonymously. Automatic processing of abuse reports MAY provide for sending a reply that summarizes the processing itsef, if the incoming abuse report has a suitable Reply-To header field. If such reply is sent, it SHOULD be human readable plain text and MUST NOT be ARF. If the incoming abuse report has a Message-Id, the acknowledgment SHOULD have an In-Reply-To field set accordingly. 6. IANA Considerations None. Vesely Expires March 6, 2012 [Page 6] Internet-Draft Abuse Reporting September 2011 7. Security Considerations TBD, possibly repeat privacy considerations from other marf drafts. 8. References 8.1. Normative References [A-R] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010. [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [FBL] Falk, J., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", draft-ietf-marf-as-00 (work in progress), September 2011. [MAILBOX-NAMES] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. 8.2. Informative References [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [IMAP-SREP] Ordogh, Z., "Spam reporting using IMAP: SREP", draft-ordogh-spam-reporting-using-imap-00 (work in progress), August 2011. [REDACT] Falk, J., "Redaction of Potentially Sensitive Data from Vesely Expires March 6, 2012 [Page 7] Internet-Draft Abuse Reporting September 2011 Mail Abuse Reports", draft-ietf-marf-redaction-00 (work in progress), April 2011. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. Author's Address Alessandro Vesely v. L. Anelli 13 Milano, MI 20122 IT Email: vesely@tana.it Vesely Expires March 6, 2012 [Page 8]