MARF Working Group                                               J. Falk
Internet-Draft                                               Return Path
Updates: 5965 (if approved)                            M. Kucherawy, Ed.
Intended status: Standards Track                               Cloudmark
Expires: June 23, 2012                                 December 21, 2011


 Creation and Use of Email Feedback Reports: An Applicability Statement
                  for the Abuse Reporting Format (ARF)
                         draft-ietf-marf-as-01

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.

   [NOTE TO EDITOR: Murray Kucherawy is listed as an author only to
   enable him to complete the publication process on behalf of J.D.
   Falk.  Please remove Murray from the author list prior to
   publication.]

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 23, 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



Falk & Kucherawy          Expires June 23, 2012                 [Page 1]


Internet-Draft                   ARF AS                    December 2011


   (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
   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 [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
   ([RFC5321]), and might provide access to messages through IMAP
   ([RFC3501]), POP ([RFC1939]), a proprietary interface designed for
   HTTP ([RFC2616]), or a proprietary protocol.





Falk & Kucherawy          Expires June 23, 2012                 [Page 2]


Internet-Draft                   ARF AS                    December 2011


3.  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
   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.  Creating and Sending Complaint-Based 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
       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].





Falk & Kucherawy          Expires June 23, 2012                 [Page 3]


Internet-Draft                   ARF AS                    December 2011


6.  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
       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 implementors 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.  Implementors SHOULD NOT expect all Mailbox Providers to include
       the same optional fields.
   6.  Actions that mail operators might take upon receiving a report
       (or multiple reports) are discussed in Section 4.3 of [RFC6449].


7.  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" or "honeypot" addresses without
   human involvement, reports of authentication failures, virus reports,
   and so forth.  These applications might be described in future IETF
   documents.


8.  IANA Considerations

   [RFC Editor: please remove this section prior to publication.]

   This document has no IANA actions.


9.  Security Considerations

   Implementers are strongly urged to review, at a minimum, the Security
   Considerations sections of [RFC5965] and [RFC6449].




Falk & Kucherawy          Expires June 23, 2012                 [Page 4]


Internet-Draft                   ARF AS                    December 2011


10.  Acknowledgements

   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, I must thank the doctors and staff at the University of
   Texas MD Anderson Cancer Center for doing what they do.


11.  References

11.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.

11.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.

   [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.



Falk & Kucherawy          Expires June 23, 2012                 [Page 5]


Internet-Draft                   ARF AS                    December 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 23, 2012                 [Page 6]