One document matched: draft-ietf-marf-as-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1939 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1939.xml">
<!ENTITY RFC2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2142 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2142.xml">
<!ENTITY RFC2505 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2505.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC3464 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3464.xml">
<!ENTITY RFC3501 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml">
<!ENTITY RFC3912 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">
<!ENTITY RFC4408 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4408.xml">
<!ENTITY RFC5321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY RFC5322 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY RFC5965 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5965.xml">
<!ENTITY RFC5598 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5598.xml">
<!ENTITY RFC5617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5617.xml">
<!ENTITY RFC6376 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6376.xml">
<!ENTITY RFC6449 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6449.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc comments="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-ietf-marf-as-09" ipr="trust200902"
updates="5965">
<front>
<title abbrev="ARF AS">
Creation and Use of Email Feedback Reports:
An Applicability Statement for the Abuse Reporting
Format (ARF)</title>
<author fullname="J.D. Falk" initials="J.D." surname="Falk">
<organization>Return Path</organization>
<address>
<postal>
<street>
100 Mathilda Street, Suite 100
</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>ietf@cybernothing.org</email>
<uri>http://www.returnpath.net/</uri>
</address>
</author>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy" role="editor">
<organization>Cloudmark</organization>
<address>
<postal>
<street>128 King St., 2nd Floor</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>US</country>
</postal>
<email>msk@cloudmark.com</email>
</address>
</author>
<date year="2012"/>
<area>Applications</area>
<workgroup>MARF Working Group</workgroup>
<keyword>arf</keyword>
<keyword>marf</keyword>
<keyword>abuse reporting</keyword>
<keyword>spam reporting</keyword>
<abstract>
<t> RFC 5965 defines an extensible, machine-readable
format intended for mail operators to report
feedback about received email to other parties.
This Applicability Statement describes common
methods for utilizing this format for reporting
both abuse and authentication failure events.
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. Some related optional mechanisms are
also discussed. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> 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. </t>
<t> Though other uses for the format defined in
<xref target="RFC5965"/> have been discussed (and
may be documented similarly in the future), abuse
remains the primary application, with a small
amount of adoption of extensions that enable
authentication failure reporting. </t>
<t> This Applicability Statement provides direction
for using the Abuse Reporting Format (ARF) in
both contexts. It also includes some statements
about the use of ARF in conjunction with other email
technologies. </t>
<t> 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. </t>
<t> Further introduction to this topic may be found
in <xref target="RFC6449"/>. </t>
<section title="Discussion">
<t> [RFC Editor: please remove this section prior
to publication.] </t>
<t> This document is being discussed within
the IETF MARF Working Group, on the
marf@ietf.org mailing list. </t>
</section>
</section>
<section title="Definitions">
<t> 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
<xref target="RFC2119"/>, and are intended
to replace the Requirement Levels
described in Section 3.3 of
<xref target="RFC2026"/>. </t>
<t> Some of the terminology used in this
document is taken from
<xref target="RFC5598"/>. </t>
<t> "Mailbox Provider" refers to an
organization that accepts, stores, and
offers access to <xref target="RFC5322"/>
messages ("email messages") for end users.
Such an organization has typically
implemented SMTP
(<xref target="RFC5321"/>), and might
provide access to messages through IMAP
(<xref target="RFC3501"/>), POP3
(<xref target="RFC1939"/>), a proprietary
interface designed for HTTP
(<xref target="RFC2616"/>), or a
proprietary protocol. </t>
</section>
<section title="Solicited and Unsolicited Reports">
<t>The original application of <xref target="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.</t>
<t>Other uses for ARF involve reports sent between parties
that don't know each other. These unsolicited reports
are sent without prior arrangement between the parties
as to the context and meaning of the reports, so the
constraints on how these unsolicited reports need to be
structured such that the reports generated are likely to
be useful to the recipient, to what address(es) they
can usefully be sent, what issues the can be used to
report, and how they can be handled by the receiver
of the report are very different. </t>
</section>
<section title="Creating and Sending Complaint-Based Solicited Abuse Reports">
<t> [The numbered items in these subsections are not
intended to be in a paricular sequence. The
numbers are here during document development to
make it easier to identify the items for
discussion, and will be removed before
publication.] </t>
<t> The following subsections include statements
applicable when establishing an abuse report
relationship and generating reports in that
context. </t>
<section anchor="sol_general"
title="General Considerations">
<t> <list style="numbers">
<t> 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
<xref target="RFC6449"/>. Policy concerns
related to the collection of this data
are discussed in Section 3.4 of
<xref target="RFC6449"/>. </t>
<t> To implement the recommendations of this
memo, the reports MUST be formatted per
<xref target="RFC5965"/>,
and transmitted as an email message
(<xref target="RFC5322"/>), typically
using SMTP (<xref target="RFC5321"/>). </t>
<t> Ongoing maintenance of an ARF processing
system is discussed in Section 3.6 of
<xref target="RFC6449"/>. </t>
</list> </t>
</section>
<section anchor="sol_where"
title="Where To Send Reports">
<t> <list style="numbers">
<t> The Mailbox Provider SHOULD send reports
to relevant parties who have requested
to receive such reports.
The process whereby such parties may
request the reports is discussed in
Section 3.5 of
<xref target="RFC6449"/>.</t>
</list> </t>
</section>
<section anchor="sol_what"
title="What To Put In Reports">
<t> <list style="numbers">
<t> 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. </t>
<t> 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. </t>
<t> Reports MAY be subjected to redaction of
user-identifiable data as described in
<xref target="I-D.IETF-MARF-REDACTION"/>. </t>
</list> </t>
</section>
</section>
<section
title="Receiving and Processing Complaint-Based Solicited Abuse Reports">
<t> [The numbered items in these subsections are not intended
to be in a paricular sequence. The numbers are here
during document development to make it easier to identify
the items for discussion, and will be removed before
publication.] </t>
<t> The following subsections include statements
applicable when receiving abuse reports in the
context of an established abuse report feedback
relationship. </t>
<section anchor="sol_r_general"
title="General Considerations">
<t> <list style="numbers">
<t> It is strongly suggested that the Mailbox
Provider process the reports to improve
its spam filtering systems. The design of
these systems is discussed in
<xref target="RFC2505"/> and
elsewhere. </t>
<t> 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
<xref target="RFC6449"/>. </t>
<t> Mail operators MUST be prepared to receive
reports formatted per
<xref target="RFC5965"/> as email
messages (<xref target="RFC5322"/>) over
SMTP (<xref target="RFC5321"/>). These
and other types of email messages that
may be received are discussed in
Section 4.2 of
<xref target="RFC6449"/>. </t>
<t> Mail operators need to consider the idea
of automating report processing.
Discussion of this can be found in
Section 4.4 of
<xref target="RFC6449"/>. </t>
</list> </t>
</section>
<section anchor="sol_r_content" title="What To Expect">
<t> <list style="numbers">
<t> An automated report processing system MUST
accept all Feedback-Types defined in
<xref target="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. </t>
<t> Implementers SHOULD NOT expect all Mailbox
Providers to include the same optional
fields. </t>
<t> Reports MAY be subjected to redaction of
user-identifiable data as described in
<xref target="I-D.IETF-MARF-REDACTION"/>.
This is also discussed in Section 4.4
of <xref target="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. </t>
</list> </t>
</section>
<section anchor="sol_r_action" title="What To Do">
<t> <list style="numbers">
<t> Actions that mail operators might take upon
receiving a report (or multiple reports)
are discussed in Section 4.3 of
<xref target="RFC6449"/>. </t>
</list> </t>
</section>
</section>
<section title="Generating and Handling Unsolicited Abuse Reports">
<t> [The numbered items in these subsections are not
intended to be in a paricular sequence. The numbers are
here during document development to make it easier to
identify the items for discussion, and will be removed
before publication.] </t>
<t> The following subsections include statements
applicable when sending or receiving reports
outside of the context of an established abuse
report feedback relationship. </t>
<section anchor="unsol_general"
title="General Considerations">
<t> <list style="numbers">
<t> A report generator MUST provide a way for
a report recipient to request no further
reports be sent to that address and MAY
provide a way for recipients to change the
address(es) to which reports about them
are sent. </t>
</list> </t>
</section>
<section anchor="unsol_when"
title="When To Generate Reports">
<t> <list style="numbers">
<t> Handling of unsolicited reports has a
significant cost to the receiver. Senders
of unsolicited reports, especially those
sending large volumes of them
automatically, need to be aware of this
and do all they reasonably can to avoid
sending reports that cannot be used as a
basis for action by the recipient, whether
this is due to the report being sent about
an incident that is not abuse-related, the
report being sent to an email address that
won't result in action, or the content or
format of the report being hard for the
recipient to read or use. </t>
<t> 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, and virus reports. (These
applications might be described in future
IETF documents.) </t>
<t> Systems SHOULD NOT report all mail sent
from a particular sender merely because
some of it is determined to be abusive.
Mechanical reports of mail that "looks
like" spam, based solely on the results
of inline content analysis tools, SHOULD
NOT be sent since, because of their
subjective nature, they are unlikely to
provide a basis for the recipient to take
action. </t>
<t> If a report generator applies SPF to
arriving messages, and that evaluation
produced something other than a "Pass",
"None" or "Neutral" result, a report
addressed to the RFC5321.MailFrom domain
SHOULD NOT be generated as it is probably
a forgery and thus not actionable. A
valid exception would be specific
knowledge that the SPF result is not
definitive for that domain under those
circumstances (for example, a message that
is also DKIM-signed by the same domain,
and that signature validates). </t>
<t> Message authentication is generally a good
idea, but it is especially important to
encourage credibility of and thus response
to unsolicited reports. Therefore, as
with any other message, report generators
sending unsolicited reports SHOULD arrange
to send reports for which SPF and/or
DKIM checks will pass. </t>
</list> </t>
</section>
<section anchor="unsol_where"
title="Where To Send Reports">
<t> <list style="numbers">
<t> MUAs SHOULD NOT generate abuse reports
directly to entities found in the message
or by queries to WHOIS
(<xref target="RFC3912"/>) or other
heuristic means. Rather, the MUA needs to
signal, by some means, the mailbox
provider to which it connects to trigger
generation of such a report. </t>
<t> 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. </t>
<t> Deciding where to send an unsolicited
report will typically rely on heuristics.
Abuse addresses in WHOIS records of the IP
address relaying the subject message
and/or of the domain name found in the
results of a PTR ("reverse lookup") query
on that address are likely reasonable
candidates, as is the abuse@domain role
address (see <xref target="RFC2142"/>) of
related domains. Unsolicited reports
SHOULD NOT be sent to email addresses that
are not intended to handle abuse rpeorts,
including any personal or role address
found in WHOIS records or on a web site
that is not either explicitly described
as an abuse contact or is of the form
"abuse@domain". </t>
<t> Where an abusive message is signed using a
domain-level authentication technology
such as DKIM (<xref target="RFC6376"/>)
or SPF (<xref target="RFC4408"/>), the
domain that has been verified by the
authentication mechanism is often a
reasonable candidate for receiving
feedback about the message. For DKIM,
though, while the authenticated domain
has some responsibility for the mail sent,
it can be a poor contact point for abuse
issues (for example, it could represent
the message's author but not its sender,
it could identify the bad actor
responsible for the message, or it could
refer to a domain that cannot receive mail
at all). </t>
<t> Unsolicited reports will have no meaning
if sent to abuse reporting addresses
belonging to the abusive parties
themselves. In fact, it is possible that
such reports might reveal information
about their recipients. Reports SHOULD
NOT be sent to such addresses if they can
be identified beforehand. </t>
</list> </t>
</section>
<section anchor="unsol_what"
title="What To Put In Reports">
<t> <list style="numbers">
<t> 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. </t>
<t> 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. </t>
<t> Experience suggests use of ARF is
advisable in most contexts. Automated
recipient systems can handle abuse reports
sent in ARF format at least as well as any
other format such as plain text, with or
without a copy of the message attached.
That holds even for systems that did not
request ARF format reports, provided that
reports are generated with use by
recipients not using automated ARF parsing
in mind. Anyone sending unsolicited
reports in ARF format can legitimately
presume that some recipients will only be
able to access the human readable (first,
text/plain) part of it, and SHOULD include
all information needed also in this part.
Further, they SHOULD 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 most
extreme cases. </t>
</list> </t>
</section>
<section anchor="unsol_actions"
title="What To Do With Reports">
<t> <list style="numbers">
<t> 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 address 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. </t>
<t> Per Section 4.4 of
<xref target="RFC6449"/>, a network
service provider MAY use ARF data for
automated forwarding of feedback messages
to the originating customer. </t>
<t> 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. </t>
<t> Although <xref target="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 by the report generator. In
addition, using an address that cannot
receive replies precludes any requests for
additional information, and increases the
likelihood that further reports will be
discarded or blocked. 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 <xref target="RFC6449"/>
for a discussion of establishment of
feedback arrangements. </t>
</list> </t>
</section>
</section>
<section title="Generating Automatic Authentication Failure Reports">
<t> [These numbered items are not intended to be in a
paricular sequence. The numbers are here during
document development to make it easier to identify
the items for discussion, and will be removed
before publication.] </t>
<t> There are some cases where report generation is
caused by automation rather than user request.
A specific example of this is reporting, using
the ARF format (or extensions to it), of messages
that fail particular message authentication checks.
Examples of this include
<xref target="I-D.IETF-MARF-DKIM-REPORTING"/>
and <xref target="I-D.IETF-MARF-SPF-REPORTING"/>.
The considerations presented below apply in those
cases. </t>
<t> The applicability statement for this use case
is somewhat smaller as many of the issues
associated with abuse reports are not relevant
to reports about authentication failures. </t>
<t> <list style="numbers">
<t> Selection of the recipient(s) for reports
that are automatically generated MUST
be done based on data provided by the
report recipient, and MUST NOT be done
heuristically. Therefore these reports
are always solicited, though the means
for doing so are not specified in this
memo. </t>
<t> If the message under evaluation by the
Verifier is an ARF
(<xref target="RFC5965"/>)
message, a report MUST NOT be automatically
generated. </t>
<t> When sending a new report via SMTP,
it is necessary to construct the message
so as to avoid amplification attacks,
deliberate or otherwise. The envelope
sender address of the report needs to be
chosen so that these reports will not
generate mail loops. Similar to Section 2
of <xref target="RFC3464"/>, the envelope
sender address of the report SHOULD be
chosen to ensure that no feedback reports
will be issued in response to the report
itself. Therefore, when an SMTP
transaction is used to send a report, the
MAIL FROM command SHOULD use the NULL
reverse-path, i.e.,
"MAIL FROM:<>". </t>
<t> Reports SHOULD use
"Feedback-Type: auth-failure", 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. </t>
<t> 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. </t>
</list> </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t> [RFC Editor: please remove this section prior to
publication.] </t>
<t> This document has no IANA actions. </t>
</section>
<section anchor="Security" title="Security Considerations">
<section anchor="sec-other" title="In Other Documents">
<t> Implementers are strongly urged to review,
at a minimum, the Security Considerations
sections of <xref target="RFC5965"/> and
<xref target="RFC6449"/>. </t>
</section>
<section anchor="sec-fake" title="Forgeries">
<t> 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. </t>
<t> Also, these reports may be forged as
easily as ordinary Internet electronic
mail. User agents and automatic mail
handling facilities (such as mail
distribution list exploders) that wish
to make automatic use of reports of any
kind should take appropriate precautions
to minimize the potential damage from
denial-of-service attacks. </t>
<t> Perhaps the simplest means of mitigating
this threat is to assert that these
reports should themselves be signed with
something like DKIM or authorized by SPF.
On the other hand,
if there is a problem with the DKIM
infrastructure at the Verifier, signing
DKIM failure reports may produce reports
that aren't trusted or even accepted by
their intended recipients. Similar issues
could exist with SPF evaluation. Use of
both technologies can mitigate this risk
to a degree. </t>
</section>
<section anchor="sec-amplify"
title="Amplification Attacks">
<t> Failure to comply with the recommendations
regarding selection of the envelope sender
can lead to amplification denial-of-service
attacks. </t>
</section>
<section anchor="sec-autogen"
title="Automatic Generation">
<t> ARF (<xref target="RFC5965"/>) reports have
historically been generated individually
as a result of some kind of human request,
such as someone clicking a "Report Abuse"
button in a mail reader. In contrast, the
mechanisms described in some extension
documents (i.e.,
<xref target="I-D.IETF-MARF-DKIM-REPORTING"/>
and
<xref target="I-D.IETF-MARF-SPF-REPORTING"/>)
are focused around automated reporting.
This obviously implies the potential for
much larger volumes or frequency of
messages, and thus greater mail system
load (both for report generators and
report receivers). </t>
<t> Those mechanisms are primarily intended
for use in generating reports to aid
implementers of DKIM
(<xref target="RFC6376"/>),
ADSP (<xref target="RFC5617"/>), and
SPF (<xref target="RFC4408"/>), and other
related
protocols during development and debugging.
They are not generally intended for
prolonged forensic use, specifically
because of these load concerns. However,
extended use is possible by ADMDs that
want to keep a close watch for fraud or
infrastructure problems. It is important
to consider the impact of doing so on both
report generators and the requesting
ADMDs. </t>
<t> A sender requesting these reports can
cause its mail servers to be overwhelmed
if it sends out signed messages whose
signatures fail to verify for some reason,
provoking a large number of reports from
report generators. Similarly, a report
generator could be overwhelmed by a large
volume of messages requesting reports
whose signatures fail to validate, as
those now need to send reports back to
the signer. </t>
<t> Limiting the rate of generation of these
messages may be appropriate but threatens
to inhibit the distribution of important
and possibly time-sensitive
information. </t>
<t> In general ARF feedback loop terms, it is
often suggested that report generators
only create these (or any) ARF reports
after an out-of-band arrangement has been
made between two parties. These extension
mechanisms then become ways to adjust
parameters of an authorized abuse report
feedback loop that is configured and
activated by private agreement rather than
starting to send them automatically based
solely on data found in the messages,
which may have unintended
consequences. </t>
</section>
<section anchor="multiple-incidents"
title="Reporting Multiple Incidents">
<t> If it is known that a particular host
generates abuse reports upon certain
incidents, an attacker could forge a high
volume of messages that will trigger such
a report. The recipient of the report
could then be innundated with reports.
This could easily be extended to a
distributed denial-of-service attack by
finding a number of report-generating
servers. </t>
<t> The incident count referenced in
ARF (<xref target="RFC5965"/>) provides a
limited
form of mitigation. The host generating
reports can elect to send reports only
periodically, with each report
representing a number of identical or
nearly-identical incidents. One might
even do something inverse-exponentially,
sending reports for each of the first ten
incidents, then every tenth incident up
to 100, then every 100th incident up to
1000, etc., until some period of relative
quiet after which the limitation
resets. </t>
<t> The use of this for "nearly-identical"
incidents in particular causes a
degradation in reporting quality, however.
If for example a large number of pieces of
spam arrive from one attacker, a reporting
agent could decide only to send a report
about a fraction of those messages. While
this averts a flood of reports to a
system administrator, the precise details
of each incident are similarly not
sent. </t>
<t> Other rate limiting provisions might be
considered, including detection of a
temporary failure response from the report
destination and thus halting report
generation to that destination for some
period, or simply imposing or negotiating
a hard limit on the number of reports to
be sent to a particular receiver in a
given time frame. </t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t> The author and editor wish to thank
Steve Atkins,
John Levine,
Shmuel Metz,
S. Moonesamy,
and
Alessandro Vesely
for their contributions to this memo. </t>
<t> All of the Best Practices referenced by this document are
found in <xref target="RFC6449"/>, written within the
Collaboration Committee of the Messaging Anti-Abuse
Working Group (MAAWG). </t>
<t> 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. </t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5321;
&RFC5322;
&RFC5965;
&RFC5598;
</references>
<references title="Informative References">
&RFC1939;
&RFC2026;
&RFC2142;
&RFC2505;
&RFC3912;
&RFC2616;
&RFC3464;
&RFC3501;
&RFC4408;
&RFC5617;
&RFC6376;
&RFC6449;
<reference anchor="I-D.IETF-MARF-DKIM-REPORTING">
<front>
<title>Extensions to DKIM for Failure Reporting</title>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy">
<organization>
Cloudmark
</organization>
</author>
<date month="January" year="2012"/>
</front>
<seriesInfo name="I-D"
value="draft-ietf-marf-dkim-reporting" />
</reference>
<reference anchor="I-D.IETF-MARF-REDACTION">
<front>
<title>Redaction of Potentially Sensitive Data from Mail Abuse Reports</title>
<author initials="JD" surname="Falk"
fullname="JD Falk">
<organization>
Return Path
</organization>
</author>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy" role="editor">
<organization>
Cloudmark
</organization>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="I-D"
value="draft-ietf-marf-redaction" />
</reference>
<reference anchor="I-D.IETF-MARF-SPF-REPORTING">
<front>
<title>SPF Authentication Failure Reporting using
the Abuse Report Format</title>
<author initials="S." surname="Kitterman"
fullname="S. Kitterman">
<organization>
Agari Data, Inc.
</organization>
</author>
<date month="January" year="2012"/>
</front>
<seriesInfo name="I-D"
value="draft-ietf-marf-spf-reporting" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:24 |