One document matched: draft-ietf-marf-as-08.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-08" 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 document 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. </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. This memo
provides direction for both contexts. </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>
<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"/>), POP
(<xref target="RFC1939"/>), a proprietary
interface designed for HTTP
(<xref target="RFC2616"/>), or a
proprietary protocol. </t>
</section>
<section title="Applicability Statement">
<t> [RFC Editor: please remove this section prior
to publication.] </t>
<t> NOTE TO IESG: This document is part of the
experiment to reintroduce Applicability
Statements, as defined in Section 3.2 of
<xref target="RFC2026"/>, to the Applications
Area. </t>
</section>
<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 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> [These numbered items are not intended to be in a
paricular sequence. The numbers are here during
document development to make it easier to idenify
the items for discussion, and will be removed
before publication.] </t>
<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> The Mailbox Provider SHOULD process the
reports to improve its spam filtering
systems. The design of these systems is
discussed in <xref target="RFC2505"/> and
elsewhere. </t>
<t> The Mailbox Provider SHOULD send reports
to relevant parties who have requested
to receive such reports. 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"/>).
The process whereby such parties may
request the reports is discussed in
Section 3.5 of
<xref target="RFC6449"/>.</t>
<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> Ongoing maintenance of an ARF processing
system is discussed in Section 3.6 of
<xref target="RFC6449"/>. </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
title="Receiving and Processing Complaint-Based Solicited Abuse 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 idenify
the items for discussion, and will be removed
before publication.] </t>
<t>
<list style="numbers">
<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>
<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> Actions that mail operators might take upon
receiving a report (or multiple reports)
are discussed in Section 4.3 of
<xref target="RFC6449"/>. </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 title="Generating and Handling Unsolicited Abuse 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 idenify
the items for discussion, and will be removed
before publication.] </t>
<t> The following advice is offered for the case of
reports that are not solicited:
<list style="numbers">
<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.) 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> 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. </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 (<xref target="RFC3912"/>) 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>Similarly, 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 (e.g., a message that is also
DKIM-signed by the same domain, and that signature
validates). </t>
<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>
<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 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> 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> 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> 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>
<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
from 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>
<t> 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. </t>
<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>
</list></t>
</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 idenify
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
return address, 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 (e.g.,
<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,
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;
&RFC2616;
&RFC3464;
&RFC3501;
&RFC3912;
&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:55:13 |