idnits 2.17.1 draft-jdfalk-marf-as-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2026]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5965, but the abstract doesn't seem to directly say this. It does mention RFC5965 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 13, 2011) is 4725 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5598 == Outdated reference: A later version (-03) exists of draft-jdfalk-maawg-cfblbcp-00 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mail Abuse Working Group J. Falk 3 Internet-Draft Return Path 4 Updates: 5965 (if approved) May 13, 2011 5 Intended status: Standards Track 6 Expires: November 14, 2011 8 Creation and Use of Email Feedback Reports: An Applicability Statement 9 for the Abuse Reporting Format (ARF) 10 draft-jdfalk-marf-as-00 12 Abstract 14 RFC 5965 defines an extensible, machine-readable format intended for 15 mail operators to report feedback about received email to other 16 parties. This document describes how this format is utilized for 17 reporting at scale between large mailbox providers, and from large 18 mailbox providers to other sending entities. 20 Applicability Statement? 22 [RFC Editor: please remove this section prior to publication.] 24 This document is part of the experiment to reintroduce Applicability 25 Statements, as defined in section 3.2 of [RFC2026], to the 26 Applications Area. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 14, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 1. Introduction 62 The Abuse Reporting Format (ARF) was initially developed for two very 63 specific use cases. First and foremost, it was intended to be used 64 for reporting feedback between large email operators or from large 65 email operators to end user network access operators, who could be 66 presumed to have automated abuse-handling systems. Secondarily, it 67 is used by those same large mail operators to send those same reports 68 to other entities, including those involved in sending bulk email for 69 commercial purposes. In both cases, the reports would be triggered 70 by an end user action such as clicking on a "report spam" button in 71 their email client. 73 Though other uses for the format defined in [RFC5965] have been 74 developed (and may be documented similarly in the future), those were 75 (and remain) the primary applications. 77 Further introduction to this topic may be found in 78 [I-D.jdfalk-maawg-cfblbcp]. 80 1.1. Definitions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119], and are 85 intended to replace the Requirement Levels described in section 3.3 86 of [RFC2026]. 88 Some of the terminology used in this document is taken from 89 [RFC5598]. 91 "Mailbox Provider" refers to an organization that accepts, stores, 92 and offers access to [RFC5322] messages ("email messages") for end 93 users. Such an organization MUST have implemented SMTP ([RFC5321]), 94 and MAY provide access to messages through IMAP ([RFC3501]), POP 95 ([RFC1939]), a proprietary interface designed for HTTP ([RFC2616]), 96 or a proprietary protocol. 98 1.2. Discussion 100 [RFC Editor: please remove this section prior to publication.] 102 This document is being discussed within the IETF MARF Working Group, 103 on the marf@ietf.org mailing list. 105 2. Creating and Sending Reports 107 1. A Mailbox Provider receives reports of abusive or unwanted mail 108 from their users, most often by providing a "report spam" button 109 (or similar nomenclature) in the MUA. The method of transferring 110 this message and any associated metadata from the MUA to the 111 Mailbox Provider's ARF processing system is not defined, but is 112 discussed further in section 3.2 of [I-D.jdfalk-maawg-cfblbcp]. 113 Policy concerns related to the collection of this data are 114 discussed in section 3.4 of [I-D.jdfalk-maawg-cfblbcp]. 115 2. The Mailbox Provider SHOULD process the reports to improve their 116 spam filtering systems. The design of these systems is discussed 117 in [RFC2505] and elsewhere. 118 3. The Mailbox Provider SHOULD (but is not required to) send reports 119 to relevant parties who have requested to receive such reports. 120 The reports MUST be formatted per [RFC5965], and transmitted as 121 an [RFC5322] message using [RFC5321]. The process whereby such 122 parties may request the reports is discussed in section 3.5 of 123 [I-D.jdfalk-maawg-cfblbcp]. 124 4. Ongoing maintenance of an ARF processing system is discussed in 125 section 3.6 of [I-D.jdfalk-maawg-cfblbcp]. 127 3. Receiving and Processing Reports 129 1. At the time this document is being written, for the use cases 130 described here, mail operators need to proactively request a 131 stream of ARF reports from Mailbox Providers. Recommendations 132 for preparing to make that request are discussed in section 4.1 133 of [I-D.jdfalk-maawg-cfblbcp]. 134 2. Mail operators MUST be prepared to receive reports formatted per 135 [RFC5965] as [RFC5322] messages via [RFC5321]. These and other 136 types of [RFC5322] messages which may be received at discussed in 137 section 4.2 of [I-D.jdfalk-maawg-cfblbcp]. 138 3. Mail operators SHOULD utilize an automated system to receive and 139 process these reports, as discussed in section 4.4 of 140 [I-D.jdfalk-maawg-cfblbcp]. 141 4. Actions that mail operators MAY take upon receiving a report (or 142 multiple reports) are discussed in section 4.3 of 143 [I-D.jdfalk-maawg-cfblbcp]. 145 4. Acknowledgements 147 This document is a product of the IETF MARF Working Group, chaired by 148 Barry Leiba and Murray Kucherawy. The idea to present it in the form 149 of an Applicability Statement originated (I believe) with Pete 150 Resnick. 152 All of the Best Practices referenced by this document are found in 153 [I-D.jdfalk-maawg-cfblbcp], written within the Collaboration 154 Committee of the Messaging Anti-Abuse Working Group (MAAWG), which is 155 described further in [I-D.jdfalk-maawg-cfblbcp]. 157 Finally, I must thank the doctors and staff at the University of 158 Texas MD Anderson Cancer Center for reasons which need not be 159 explored here. 161 5. IANA Considerations 163 [RFC Editor: please remove this section prior to publication.] 165 This document has no IANA actions. 167 6. Security Considerations 169 Implementers are urged to review, at a minimum, the Security 170 Considerations sections of [RFC5965] and [I-D.jdfalk-maawg-cfblbcp]. 172 7. References 174 7.1. Normative References 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 180 October 2008. 182 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 183 October 2008. 185 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 186 July 2009. 188 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 189 Extensible Format for Email Feedback Reports", RFC 5965, 190 August 2010. 192 7.2. Informative References 194 [I-D.jdfalk-maawg-cfblbcp] 195 Falk, J., "Complaint Feedback Loop Best Current 196 Practices", draft-jdfalk-maawg-cfblbcp-00 (work in 197 progress), January 2011. 199 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 200 STD 53, RFC 1939, May 1996. 202 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 203 3", BCP 9, RFC 2026, October 1996. 205 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 206 BCP 30, RFC 2505, February 1999. 208 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 209 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 210 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 212 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 213 4rev1", RFC 3501, March 2003. 215 Author's Address 217 J.D. Falk 218 Return Path 219 100 Mathilda Street, Suite 100 220 Sunnyvale, CA 94089 221 USA 223 Email: ietf@cybernothing.org 224 URI: http://www.returnpath.net/