Internet DRAFT - draft-vesely-marf-abuse-reporting

draft-vesely-marf-abuse-reporting






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]