idnits 2.17.1 draft-ietf-repute-email-identifiers-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 : ---------------------------------------------------------------------------- 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 (November 19, 2011) is 4541 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: 'RFCxxxx' is mentioned on line 128, but not defined == Missing Reference: 'TBD' is mentioned on line 195, but not defined -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: May 22, 2012 Cloudmark 6 November 19, 2011 8 A Reputation Vocabulary for Email Identities 9 draft-ietf-repute-email-identifiers-00 11 Abstract 13 This document defines a vocabulary for describing email identities 14 (typically authors or signers) with the application/reputon media 15 type. 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 May 22, 2012. 34 Copyright Notice 36 Copyright (c) 2011 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. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 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. Vocabulary Extensions . . . . . . . . . . . . . . . . . . . 4 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Registration of 'email-id' Reputation Application . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 64 Appendix B. Public Discussion . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 This memo defines a "vocabulary" for describing reputation of an 70 email identity. A "vocabulary" in this context is defined in 71 [RFCxxxx] and is used to describe assertions a reputation service 72 provider can make about email identities as well as meta-data that 73 can be included in such a reply beyond the base set specified there. 75 2. Terminology and Definitions 77 This section defines terms used in the rest of the document. 79 2.1. Keywords 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [KEYWORDS]. 85 2.2. Email Definitions 87 Commonly used definitions describing entities in the email 88 architecture are defined and discussed in [EMAIL-ARCH]. 90 2.3. Other Definitions 92 Other terms of importance in this memo are defined in RFCxxxx, the 93 base memo in this document series. 95 3. Discussion 97 The expression of reputation about an email identity requires 98 extensions of the base set defined in [RFCxxxx]. This memo defines 99 and registers some common assertions about an entity found in a piece 100 of [MAIL]. 102 3.1. Assertions 104 The "email-id" reputation application recognizes the following 105 assertions: 107 PERPETRATES-FRAUD: The subject identity is associated with 108 fraudulent email 110 SENDS-MALWARE: The subject identity is associated with the sending 111 or relaying of malware via email 113 SENDS-SPAM: The subject identity is associated with unwanted bulk 114 email 116 SENDS-TO-INVALID-RECIPIENTS: The subject delivery attempts to 117 nonexistent recipients 119 For all assertions, the RATING scale is linear: A value of 0.0 means 120 there is no data to support the assertion, a value of 1.0 means all 121 accumulated data support the assertion, and the intervening values 122 have a linear relationship (i.e., a score of "x" is twice as strong 123 of an assertion as a value of "x/2"). 125 3.2. Vocabulary Extensions 127 The "email-id" reputation application recognizes the following 128 OPTIONAL extensions to the vocabulary defined in [RFCxxxx]: 130 IDENTITY: A token indicating the source of the identity; that is, 131 where the subject identity was found in the message. This MUST be 132 one of: 134 DKIM: The signing domain, i.e. the value of the "d=" tag, found 135 on a valid [DKIM] signature in the message 137 IPV4: The IPv4 address of the client 139 IPV6: The IPv6 address of the client 141 RFC5321.MAILFROM: The RFC5321.MailFrom value of the envelope of a 142 message of the message (see [SMTP]) 144 RFC5322.FROM: The RFC5322.From field of the message (see [MAIL]) 146 SPF: The identity verified by [SPF]) 148 RATE: A token that recommends an overall message acceptance rate for 149 the subject domain. This is expected to be a value tailored to 150 the requesting agent; for example, the reputation service would 151 use this to indicate that, based on the data reported by the 152 requesting agent, the service recommends a particular message 153 limit for that agent. The value is an unsigned decimal value. 155 SOURCES: A token relating a count of the number of sources of data 156 that contributed to the reported reputation. This is in contrast 157 to the SAMPLE-SIZE parameter, which indicates the total number of 158 reports across all reporting sources. 160 A reply that does not contain the IDENTITY or SOURCES extensions is 161 making a non-specific statement about how the reputation returned was 162 developed. A client may use or ignore such a reply at its 163 discretion. 165 4. IANA Considerations 167 This memo presents one action for IANA, namely the registraton of the 168 reputation application "email-id". 170 4.1. Registration of 'email-id' Reputation Application 172 This section registers the "email-id" reputation application, as 173 defined in [RFCxxxx+1]. The registration parameters are as folows: 175 o Application name: email-id 177 o Short description: Evaluates DNS domain names found in email 178 identities 180 o Defining document: [this memo] 182 o Status: current 184 o Application-specific query parameters: 186 subject: (current) identifies the subject of the reputation 187 query; in this case, it is the email identity whose reputation 188 is requested 190 5. Security Considerations 192 This memo describes security considerations introduced by the 193 reputation application and vocabulary defined here. 195 [TBD] 197 6. Informative References 199 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 200 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, 201 September 2011. 203 [EMAIL-ARCH] 204 Crocker, D., "Internet Mail Architecture", RFC 5598, 205 July 2009. 207 [KEYWORDS] 208 Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 212 October 2008. 214 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 215 October 2008. 217 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 218 for Authorizing Use of Domains in E-Mail, Version 1", 219 RFC 4408, April 2006. 221 Appendix A. Acknowledgments 223 The authors wish to acknowledge the contributions of the following to 224 this specification: John Levine, and David F. Skoll. 226 Appendix B. Public Discussion 228 Public discussion of this suite of memos takes place on the 229 domainrep@ietf.org mailing list. See 230 https://www.ietf.org/mailman/listinfo/domainrep. 232 Authors' Addresses 234 Nathaniel Borenstein 235 Mimecast 236 203 Crescent St., Suite 303 237 Waltham, MA 02453 238 USA 240 Phone: +1 781 996 5340 241 Email: nsb@guppylake.com 242 Murray S. Kucherawy 243 Cloudmark 244 128 King St., 2nd Floor 245 San Francisco, CA 94107 246 USA 248 Phone: +1 415 946 3800 249 Email: msk@cloudmark.com