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]
