idnits 2.17.1 draft-ietf-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 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 (September 1, 2011) is 4618 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-01 -- 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MARF Working Group J. Falk 3 Internet-Draft Return Path 4 Updates: 5965 (if approved) September 1, 2011 5 Intended status: Standards Track 6 Expires: March 4, 2012 8 Creation and Use of Email Feedback Reports: An Applicability Statement 9 for the Abuse Reporting Format (ARF) 10 draft-ietf-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 one common method for utilizing 17 this format for reporting at scale between large mailbox providers, 18 and from large mailbox providers to other mail sending entities. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 4, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 The Abuse Reporting Format (ARF) was initially developed for two very 55 specific use cases. Initially, it was intended to be used for 56 reporting feedback between large email operators, or from large email 57 operators to end user network access operators, any of whom could be 58 presumed to have automated abuse-handling systems. Secondarily, it 59 is used by those same large mail operators to send those same reports 60 to other entities, including those involved in sending bulk email for 61 commercial purposes. In either case, the reports would be triggered 62 by direct end user action such as clicking on a "report spam" button 63 in their email client. 65 Though other uses for the format defined in [RFC5965] have been 66 discussed (and may be documented similarly in the future), those were 67 (and remain) the primary applications. 69 Further introduction to this topic may be found in 70 [I-D.jdfalk-maawg-cfblbcp]. 72 1.1. Definitions 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119], and are 77 intended to replace the Requirement Levels described in section 3.3 78 of [RFC2026]. 80 Some of the terminology used in this document is taken from 81 [RFC5598]. 83 "Mailbox Provider" refers to an organization that accepts, stores, 84 and offers access to [RFC5322] messages ("email messages") for end 85 users. Such an organization MUST have implemented SMTP ([RFC5321]), 86 and MAY provide access to messages through IMAP ([RFC3501]), POP 87 ([RFC1939]), a proprietary interface designed for HTTP ([RFC2616]), 88 or a proprietary protocol. 90 Applicability Statement? 92 [RFC Editor: please remove this section prior to publication.] 94 This document is part of the experiment to reintroduce Applicability 95 Statements, as defined in section 3.2 of [RFC2026], to the 96 Applications Area. 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 Complaint-Based 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 by any 112 standards document, but is discussed further in section 3.2 of 113 [I-D.jdfalk-maawg-cfblbcp]. Policy concerns related to the 114 collection of this data are discussed in section 3.4 of 115 [I-D.jdfalk-maawg-cfblbcp]. 116 2. The Mailbox Provider SHOULD process the reports to improve their 117 spam filtering systems. The design of these systems is discussed 118 in [RFC2505] and elsewhere. 119 3. The Mailbox Provider SHOULD (but is not required to) send reports 120 to relevant parties who have requested to receive such reports. 121 The reports MUST be formatted per [RFC5965], and transmitted as 122 an [RFC5322] message using [RFC5321]. The process whereby such 123 parties may request the reports is discussed in section 3.5 of 124 [I-D.jdfalk-maawg-cfblbcp]. 125 4. The reports SHOULD use "Feedback-Type: abuse", but MAY use other 126 types if appropriate. However, the Mailbox Provider generating 127 the reports SHOULD NOT assume that the operator receiving the 128 reports will treat different Feedback-Types differently. 129 5. The reports SHOULD include the following optional fields: 130 Original-Mail-From, Arrival-Date, Source-IP, Original-Rcpt-To. 131 Other optional fields MAY be included, as the implementor feels 132 is appropriate. 133 6. Ongoing maintenance of an ARF processing system is discussed in 134 section 3.6 of [I-D.jdfalk-maawg-cfblbcp]. 136 3. Receiving and Processing Complaint-Based Reports 138 1. At the time this document is being written, for the use cases 139 described here, mail operators need to proactively request a 140 stream of ARF reports from Mailbox Providers. Recommendations 141 for preparing to make that request are discussed in section 4.1 142 of [I-D.jdfalk-maawg-cfblbcp]. 143 2. Mail operators MUST be prepared to receive reports formatted per 144 [RFC5965] as [RFC5322] messages via [RFC5321]. These and other 145 types of [RFC5322] messages which may be received at discussed in 146 section 4.2 of [I-D.jdfalk-maawg-cfblbcp]. 147 3. Mail operators SHOULD utilize an automated system to receive and 148 process these reports, as discussed in section 4.4 of 149 [I-D.jdfalk-maawg-cfblbcp]. 150 4. This system MUST accept all Feedback-Types defined in [RFC5965], 151 but implementors SHOULD NOT assume that Mailbox Providers will 152 use any Feedback-Type other than "abuse". Additional logic may 153 be required to separate different types of abuse reports after 154 receipt. 155 5. Implementors SHOULD NOT expect all Mailbox Providers to include 156 the same optional fields. 157 6. Actions that mail operators MAY take upon receiving a report (or 158 multiple reports) are discussed in section 4.3 of 159 [I-D.jdfalk-maawg-cfblbcp]. 161 4. Other Applications 163 What is described here is the most common application of [RFC5965], 164 and provides a starting point for additional applications, but it is 165 certainly not the only possible application. Other uses for ARF 166 could include direct complaint submissions from MUAs, reports 167 triggered by mail sent to "spam trap" addresses without human 168 involvement, reports of authentication failures, virus reports, and 169 so forth. These applications may be described in other IETF 170 documents. 172 5. IANA Considerations 174 [RFC Editor: please remove this section prior to publication.] 176 This document has no IANA actions. 178 6. Security Considerations 180 Implementers are strongly urged to review, at a minimum, the Security 181 Considerations sections of [RFC5965] and [I-D.jdfalk-maawg-cfblbcp]. 183 7. Acknowledgements 185 This document is a product of the IETF MARF Working Group, chaired by 186 Barry Leiba and Murray Kucherawy. The idea to present it in the form 187 of an Applicability Statement originated (I believe) with Pete 188 Resnick. 190 All of the Best Practices referenced by this document are found in 191 [I-D.jdfalk-maawg-cfblbcp], written within the Collaboration 192 Committee of the Messaging Anti-Abuse Working Group (MAAWG) -- which 193 is described further in [I-D.jdfalk-maawg-cfblbcp]. 195 Finally, I must thank the doctors and staff at the University of 196 Texas MD Anderson Cancer Center for doing what they do. 198 8. References 200 8.1. Normative References 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997. 205 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 206 October 2008. 208 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 209 October 2008. 211 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 212 July 2009. 214 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 215 Extensible Format for Email Feedback Reports", RFC 5965, 216 August 2010. 218 8.2. Informative References 220 [I-D.jdfalk-maawg-cfblbcp] 221 Falk, J., "Complaint Feedback Loop Best Current 222 Practices", draft-jdfalk-maawg-cfblbcp-01 (work in 223 progress), June 2011. 225 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 226 STD 53, RFC 1939, May 1996. 228 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 229 3", BCP 9, RFC 2026, October 1996. 231 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 232 BCP 30, RFC 2505, February 1999. 234 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 235 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 236 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 238 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 239 4rev1", RFC 3501, March 2003. 241 Author's Address 243 J.D. Falk 244 Return Path 245 100 Mathilda Street, Suite 100 246 Sunnyvale, CA 94089 247 USA 249 Email: ietf@cybernothing.org 250 URI: http://www.returnpath.net/