One document matched: draft-ietf-marf-as-02.txt
Differences from draft-ietf-marf-as-01.txt
MARF Working Group J. Falk
Internet-Draft Return Path
Updates: 5965 (if approved) M. Kucherawy, Ed.
Intended status: Standards Track Cloudmark
Expires: June 30, 2012 December 28, 2011
Creation and Use of Email Feedback Reports: An Applicability Statement
for the Abuse Reporting Format (ARF)
draft-ietf-marf-as-02
Abstract
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 abuse reporting. 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.
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 June 30, 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
Falk & Kucherawy Expires June 30, 2012 [Page 1]
Internet-Draft ARF AS December 2011
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
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.
Though other uses for the format defined in [RFC5965] have been
discussed (and may be documented similarly in the future), abuse
remains the primary application.
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.
Further introduction to this topic may be found in [RFC6449].
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 [RFC2119], and are
intended to replace the Requirement Levels described in Section 3.3
of [RFC2026].
Some of the terminology used in this document is taken from
[RFC5598].
"Mailbox Provider" refers to an organization that accepts, stores,
and offers access to [RFC5322] messages ("email messages") for end
users. Such an organization has typically implemented SMTP
Falk & Kucherawy Expires June 30, 2012 [Page 2]
Internet-Draft ARF AS December 2011
([RFC5321]), and might provide access to messages through IMAP
([RFC3501]), POP ([RFC1939]), a proprietary interface designed for
HTTP ([RFC2616]), or a proprietary protocol.
3. Applicability Statement
[RFC Editor: please remove this section prior to publication.]
NOTE TO IESG: This document is part of the experiment to reintroduce
Applicability Statements, as defined in Section 3.2 of [RFC2026], to
the Applications Area.
4. Discussion
[RFC Editor: please remove this section prior to publication.]
This document is being discussed within the IETF MARF Working Group,
on the marf@ietf.org mailing list.
5. Solicited and Unsolicited Reports
The original application of [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.
Other uses for ARF involve reports sent between parties that don't
know each other, with the recipient address typically being
abuse@domain (see [RFC2142]), looked up via WHOIS, or using other
heuristics. The reports may be manual, or automated due to hitting
spam traps, scored high by spam filters, or anything else that the
sender of the report considers to merit an abuse report.
In either case, where an abusive message is signed using a domain-
level authentication technology such as DKIM ([RFC6376]) or SPF
([RFC4408]), the domain that has been verified by the authentication
mechanism is likely a reasonable candidate for receiving feedback
about the message.
6. Creating and Sending Complaint-Based Solicited Reports
1. 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
Falk & Kucherawy Expires June 30, 2012 [Page 3]
Internet-Draft ARF AS December 2011
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
[RFC6449]. Policy concerns related to the collection of this
data are discussed in Section 3.4 of that document.
2. The Mailbox Provider SHOULD process the reports to improve its
spam filtering systems. The design of these systems is discussed
in [RFC2505] and elsewhere.
3. The Mailbox Provider SHOULD send reports to relevant parties who
have requested to receive such reports. The reports MUST be
formatted per [RFC5965], and transmitted as an email message
([RFC5322]), typically using SMTP ([RFC5321]). The process
whereby such parties may request the reports is discussed in
Section 3.5 of [RFC6449].
4. 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.
5. 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.
6. Ongoing maintenance of an ARF processing system is discussed in
Section 3.6 of [RFC6449].
7. Receiving and Processing Complaint-Based Solicited Reports
1. 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 [RFC6449].
2. Mail operators MUST be prepared to receive reports formatted per
[RFC5965] as email messages ([RFC5322]) over SMTP ([RFC5321]).
These and other types of email messages that may be received are
discussed in Section 4.2 of [RFC6449].
3. Mail operators SHOULD utilize an automated system to receive and
process these reports, as discussed in Section 4.4 of [RFC6449].
4. That system MUST accept all Feedback-Types defined in [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.
5. Implementers SHOULD NOT expect all Mailbox Providers to include
the same optional fields.
Falk & Kucherawy Expires June 30, 2012 [Page 4]
Internet-Draft ARF AS December 2011
6. Actions that mail operators might take upon receiving a report
(or multiple reports) are discussed in Section 4.3 of [RFC6449].
8. Generating and Handling Unsolicited Reports
Systems that generate unsolicited reports SHOULD ensure that the
criteria used to decide what messages to report accurately identify
messages that the generating entity believes in good faith are
abusive. Criteria might include direct complaint submissions from
MUAs, reports triggered by mail sent to "spam trap" or "honeypot"
addresses, reports of authentication failures, 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.
Senders 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.
Recipients of unsolicited ARF reports SHOULD, in general, handle them
the same way as any other abuse reports. 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.
Some large messaging service providers specifically request that
abuse reports be sent to them in ARF format. Experience of systems
that send abuse reports in ARF format suggests that even recipient
systems that haven't asked for ARF format reports handle them at
least as well as any other format such as plain text, with or without
a copy of the message attached.
9. IANA Considerations
[RFC Editor: please remove this section prior to publication.]
This document has no IANA actions.
Falk & Kucherawy Expires June 30, 2012 [Page 5]
Internet-Draft ARF AS December 2011
10. Security Considerations
Implementers are strongly urged to review, at a minimum, the Security
Considerations sections of [RFC5965] and [RFC6449].
11. Acknowledgements
The author and editor wish to thank John Levine and Alessandro Vesely
for their contributions to this memo.
All of the Best Practices referenced by this document are found in
[RFC6449], written within the Collaboration Committee of the
Messaging Anti-Abuse Working Group (MAAWG) -- which is described
further in [RFC6449].
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.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009.
[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
Extensible Format for Email Feedback Reports", RFC 5965,
August 2010.
12.2. Informative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
Falk & Kucherawy Expires June 30, 2012 [Page 6]
Internet-Draft ARF AS December 2011
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997.
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
BCP 30, RFC 2505, February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", RFC 6376,
September 2011.
[RFC6449] Falk, J., "Complaint Feedback Loop Operational
Recommendations", RFC 6449, November 2011.
Authors' Addresses
J.D. Falk
Return Path
100 Mathilda Street, Suite 100
Sunnyvale, CA 94089
USA
Email: ietf@cybernothing.org
URI: http://www.returnpath.net/
M. Kucherawy (editor)
Cloudmark
128 King St., 2nd Floor
San Francisco, CA 94107
US
Email: msk@cloudmark.com
Falk & Kucherawy Expires June 30, 2012 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 01:28:15 |