One document matched: draft-ietf-marf-as-00.txt
MARF Working Group J. Falk
Internet-Draft Return Path
Updates: 5965 (if approved) September 1, 2011
Intended status: Standards Track
Expires: March 4, 2012
Creation and Use of Email Feedback Reports: An Applicability Statement
for the Abuse Reporting Format (ARF)
draft-ietf-marf-as-00
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 one common method for utilizing
this format for reporting at scale between large mailbox providers,
and from large mailbox providers to other mail sending entities.
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 4, 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
Falk Expires March 4, 2012 [Page 1]
Internet-Draft ARF AS September 2011
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), those were
(and remain) the primary applications.
Further introduction to this topic may be found in
[I-D.jdfalk-maawg-cfblbcp].
1.1. 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 MUST have implemented SMTP ([RFC5321]),
and MAY provide access to messages through IMAP ([RFC3501]), POP
([RFC1939]), a proprietary interface designed for HTTP ([RFC2616]),
or a proprietary protocol.
Applicability Statement?
[RFC Editor: please remove this section prior to publication.]
This document is part of the experiment to reintroduce Applicability
Statements, as defined in section 3.2 of [RFC2026], to the
Falk Expires March 4, 2012 [Page 2]
Internet-Draft ARF AS September 2011
Applications Area.
1.2. 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.
2. Creating and Sending Complaint-Based Reports
1. A Mailbox Provider receives reports of abusive or unwanted mail
from their 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
[I-D.jdfalk-maawg-cfblbcp]. Policy concerns related to the
collection of this data are discussed in section 3.4 of
[I-D.jdfalk-maawg-cfblbcp].
2. The Mailbox Provider SHOULD process the reports to improve their
spam filtering systems. The design of these systems is discussed
in [RFC2505] and elsewhere.
3. The Mailbox Provider SHOULD (but is not required to) send reports
to relevant parties who have requested to receive such reports.
The reports MUST be formatted per [RFC5965], and transmitted as
an [RFC5322] message using [RFC5321]. The process whereby such
parties may request the reports is discussed in section 3.5 of
[I-D.jdfalk-maawg-cfblbcp].
4. The reports SHOULD use "Feedback-Type: abuse", but MAY use other
types if 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:
Original-Mail-From, Arrival-Date, Source-IP, Original-Rcpt-To.
Other optional fields MAY be included, as the implementor feels
is appropriate.
6. Ongoing maintenance of an ARF processing system is discussed in
section 3.6 of [I-D.jdfalk-maawg-cfblbcp].
3. Receiving and Processing Complaint-Based 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
Falk Expires March 4, 2012 [Page 3]
Internet-Draft ARF AS September 2011
of [I-D.jdfalk-maawg-cfblbcp].
2. Mail operators MUST be prepared to receive reports formatted per
[RFC5965] as [RFC5322] messages via [RFC5321]. These and other
types of [RFC5322] messages which may be received at discussed in
section 4.2 of [I-D.jdfalk-maawg-cfblbcp].
3. Mail operators SHOULD utilize an automated system to receive and
process these reports, as discussed in section 4.4 of
[I-D.jdfalk-maawg-cfblbcp].
4. This system MUST accept all Feedback-Types defined in [RFC5965],
but implementors SHOULD NOT assume that Mailbox Providers will
use any Feedback-Type other than "abuse". Additional logic may
be required to separate different types of abuse reports after
receipt.
5. Implementors SHOULD NOT expect all Mailbox Providers to include
the same optional fields.
6. Actions that mail operators MAY take upon receiving a report (or
multiple reports) are discussed in section 4.3 of
[I-D.jdfalk-maawg-cfblbcp].
4. Other Applications
What is described here is the most common application of [RFC5965],
and provides a starting point for additional applications, but it is
certainly not the only possible application. Other uses for ARF
could include direct complaint submissions from MUAs, reports
triggered by mail sent to "spam trap" addresses without human
involvement, reports of authentication failures, virus reports, and
so forth. These applications may be described in other IETF
documents.
5. IANA Considerations
[RFC Editor: please remove this section prior to publication.]
This document has no IANA actions.
6. Security Considerations
Implementers are strongly urged to review, at a minimum, the Security
Considerations sections of [RFC5965] and [I-D.jdfalk-maawg-cfblbcp].
7. Acknowledgements
This document is a product of the IETF MARF Working Group, chaired by
Falk Expires March 4, 2012 [Page 4]
Internet-Draft ARF AS September 2011
Barry Leiba and Murray Kucherawy. The idea to present it in the form
of an Applicability Statement originated (I believe) with Pete
Resnick.
All of the Best Practices referenced by this document are found in
[I-D.jdfalk-maawg-cfblbcp], written within the Collaboration
Committee of the Messaging Anti-Abuse Working Group (MAAWG) -- which
is described further in [I-D.jdfalk-maawg-cfblbcp].
Finally, I must thank the doctors and staff at the University of
Texas MD Anderson Cancer Center for doing what they do.
8. References
8.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.
8.2. Informative References
[I-D.jdfalk-maawg-cfblbcp]
Falk, J., "Complaint Feedback Loop Best Current
Practices", draft-jdfalk-maawg-cfblbcp-01 (work in
progress), June 2011.
[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.
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
BCP 30, RFC 2505, February 1999.
Falk Expires March 4, 2012 [Page 5]
Internet-Draft ARF AS September 2011
[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.
Author's Address
J.D. Falk
Return Path
100 Mathilda Street, Suite 100
Sunnyvale, CA 94089
USA
Email: ietf@cybernothing.org
URI: http://www.returnpath.net/
Falk Expires March 4, 2012 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 01:29:35 |