idnits 2.17.1 draft-ietf-repute-email-identifiers-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 6, 2012) is 4403 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) == Missing Reference: 'TBD' is mentioned on line 215, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5598 (ref. 'EMAIL-ARCH') ** Obsolete normative reference: RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 REPUTE Working Group N. Borenstein 3 Internet-Draft Mimecast 4 Intended status: Standards Track M. Kucherawy 5 Expires: October 8, 2012 Cloudmark 6 April 6, 2012 8 A Reputation Response Set for Email Identifiers 9 draft-ietf-repute-email-identifiers-03 11 Abstract 13 This document defines a response set for describing assertions a 14 reputation service provider can make about email identifers, for use 15 in generating reputons. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 8, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology and Definitions . . . . . . . . . . . . . . . . . . 3 53 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Email Definitions . . . . . . . . . . . . . . . . . . . . . 3 55 2.3. Other Definitions . . . . . . . . . . . . . . . . . . . . . 3 56 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Response Set Extensions . . . . . . . . . . . . . . . . . . 4 59 3.3. Query Extensions . . . . . . . . . . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Registration of 'email-id' Reputation Application . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 67 Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 This document specifies a response set for describing reputation of 73 an email identifier. A "response set" in this context is defined in 74 [I-D.REPUTE-MODEL] and is used to describe assertions a reputation 75 service provider can make about email identifiers as well as meta- 76 data that can be included in such a reply beyond the base set 77 specified there. 79 An atomic reputation response is called a "reputon", also defined in 80 that document. 82 2. Terminology and Definitions 84 This section defines terms used in the rest of the document. 86 2.1. Key Words 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [KEYWORDS]. 92 2.2. Email Definitions 94 Commonly used definitions describing entities in the email 95 architecture are defined and discussed in [EMAIL-ARCH]. 97 2.3. Other Definitions 99 Other terms of importance in this document are defined in 100 [I-D.REPUTE-MODEL], the base document for the reputation services 101 work. 103 3. Discussion 105 The expression of reputation about an email identifier requires 106 extensions of the base set defined in [I-D.REPUTE-MODEL]. This 107 document defines and registers some common assertions about an entity 108 found in a piece of [MAIL]. 110 3.1. Assertions 112 The "email-id" reputation application recognizes the following 113 assertions: 115 FRAUD: The subject identifier is associated with sending or handling 116 of fraudulent email, such as "phishing" (some good discussion on 117 this topic can be found in [IODEF-PHISHING]) 119 MALWARE: The subject identifier is associated with the sending or 120 handling of malware via email 122 SPAM: The subject identifier is associated with sending or handling 123 of unwanted bulk email 125 INVALID-RECIPIENTS: The subject identifier is associated with 126 delivery attempts to nonexistent recipients 128 For all assertions, the RATING scale is linear: A value of 0.0 means 129 there is no data to support the assertion, a value of 1.0 means all 130 accumulated data support the assertion, and the intervening values 131 have a linear relationship (i.e., a score of "x" is twice as strong 132 of an assertion as a value of "x/2"). 134 3.2. Response Set Extensions 136 The "email-id" reputation application recognizes the following 137 OPTIONAL extensions to the basic response set defined in 138 [I-D.REPUTE-MODEL]: 140 IDENTITY: A token indicating the source of the identifier; that is, 141 where the subject identifier was found in the message. This MUST 142 be one of: 144 DKIM: The signing domain, i.e. the value of the "d=" tag, found 145 on a valid [DKIM] signature in the message 147 IPV4: The IPv4 address of the client 149 IPV6: The IPv6 address of the client 151 RFC5321.HELO: The RFC5321.Helo value used by the (see [SMTP]) 152 client 154 RFC5321.MAILFROM: The RFC5321.MailFrom value of the envelope of a 155 message of the message (see [SMTP]) 157 RFC5322.FROM: The RFC5322.From field of the message (see [MAIL]) 159 SPF: The domain name portion of the identifier (RFC5321.MailFrom 160 or RFC5321.Helo) verified by [SPF]) 162 SOURCES: A token relating a count of the number of sources of data 163 that contributed to the reported reputation. This is in contrast 164 to the SAMPLE-SIZE parameter, which indicates the total number of 165 reports across all reporting sources. 167 A reply that does not contain the IDENTITY or SOURCES extensions is 168 making a non-specific statement about how the reputation returned was 169 developed. A client can use or ignore such a reply at its 170 discretion. 172 3.3. Query Extensions 174 A query within this application can include the OPTIONAL query 175 parameter "identity" to indicate which specific identity is of 176 interest to the query. Legal values are the same as those listed in 177 Section 3.2. 179 4. IANA Considerations 181 This memo presents one action for IANA, namely the registration of 182 the reputation application "email-id". 184 4.1. Registration of 'email-id' Reputation Application 186 This section registers the "email-id" reputation application, as per 187 the IANA Considerations section of [I-D.REPUTE-MODEL]. The 188 registration parameters are as folows: 190 o Application name: email-id 192 o Short description: Evaluates DNS domain names found in email 193 identifiers 195 o Defining document: [this document] 197 o Status: current 199 o Subject: A string appropriate to the identifier of interest (see 200 Section 3.2 of this document) 202 o Application-specific query parameters: 204 identity: (current) as defined in Section 3.3 of this document 206 o Application-specific extensions: 208 identity: (current) as defined in Section 3.2 of this document 210 5. Security Considerations 212 This section describes security considerations introduced by the 213 reputation application and response set extensions defined here. 215 [TBD] 217 6. References 219 6.1. Normative References 221 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 222 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, 223 September 2011. 225 [EMAIL-ARCH] 226 Crocker, D., "Internet Mail Architecture", RFC 5598, 227 July 2009. 229 [I-D.REPUTE-MODEL] 230 Borenstein, N. and M. Kucherawy, "A Model for Reputation 231 Interchange", draft-ietf-repute-model (work in progress), 232 November 2011. 234 [KEYWORDS] 235 Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 239 for Authorizing Use of Domains in E-Mail, Version 1", 240 RFC 4408, April 2006. 242 6.2. Informative References 244 [IODEF-PHISHING] 245 Cain, P. and D. Jevans, "Extensions to the IODEF-Document 246 Class for Reporting Phishing", RFC 5901, July 2010. 248 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 249 October 2008. 251 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 252 October 2008. 254 Appendix A. Acknowledgments 256 The authors wish to acknowledge the contributions of the following to 257 this specification: Scott Kitterman, John Levine, S. Moonesamy, Doug 258 Otis, and David F. Skoll. 260 Appendix B. Public Discussion 262 Public discussion of this suite of memos takes place on the 263 domainrep@ietf.org mailing list. See 264 https://www.ietf.org/mailman/listinfo/domainrep. 266 Authors' Addresses 268 Nathaniel Borenstein 269 Mimecast 270 203 Crescent St., Suite 303 271 Waltham, MA 02453 272 USA 274 Phone: +1 781 996 5340 275 Email: nsb@guppylake.com 277 Murray S. Kucherawy 278 Cloudmark 279 128 King St., 2nd Floor 280 San Francisco, CA 94107 281 USA 283 Phone: +1 415 946 3800 284 Email: msk@cloudmark.com