idnits 2.17.00 (12 Aug 2021) /tmp/idnits55932/draft-kucherawy-reputation-vocab-email-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 (June 1, 2011) is 4000 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCxxxx' is mentioned on line 149, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Borenstein 3 Internet-Draft Mimecast 4 Intended status: Informational M. Kucherawy 5 Expires: December 3, 2011 Cloudmark 6 June 1, 2011 8 A Reputation Vocabulary for Email Properties 9 draft-kucherawy-reputation-vocab-email-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 December 3, 2011. 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. Document Series . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology and Definitions . . . . . . . . . . . . . . . . . . 3 54 3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Email Definitions . . . . . . . . . . . . . . . . . . . . . 4 56 3.3. Other Definitions . . . . . . . . . . . . . . . . . . . . . 4 57 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Vocabulary Extensions . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Registration of 'email-content' Reputation Application . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 This memo defines a "vocabulary" for describing reputation of a 71 property of an email message that is not an identity. A "vocabulary" 72 in this context is defined in [RFCxxxx] and is used to describe 73 assertions a reputation service provider can make about properties of 74 an email message as well as meta-data that can be included in such a 75 reply beyond the base set specified there. 77 A separate document in this series declares a vocabulary for use in 78 relating reputation information about an identity found in an email 79 message. 81 2. Document Series 83 This memo represents the media type registration, part of a series of 84 documents that define the overall service and introduce the initial 85 exemplary applications. The series is as follows: 87 1. RFCxxxx: A Model for Reputation Interchange 89 2. RFCxxxx+1: A Media Type for Reputation Information 91 3. RFCxxxx+2: Using UDP for Reputation Interchange 93 4. RFCxxxx+3: Using the DNS for Reputation Interchange 95 5. RFCxxxx+4: Using HTTP/XML for Reputation Interchange 97 6. RFCxxxx+5: A Reputation Vocabulary for Email Identity Reputation 99 7. RFCxxxx+6: A Reputation Vocabulary for Email Property Reputation 100 (this memo) 102 3. Terminology and Definitions 104 This section defines terms used in the rest of the document. 106 3.1. Keywords 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [KEYWORDS]. 112 3.2. Email Definitions 114 Commonly used definitions describing entities in the email 115 architecture are defined and discussed in [EMAIL-ARCH]. 117 3.3. Other Definitions 119 Other terms of importance in this memo are defined in RFCxxxx, the 120 base memo in this document series. 122 4. Discussion 124 The expression of reputation about an email property requires 125 extensions of the base set defined in [RFCxxxx]. This memo defines 126 and registers some common assertions about an entity found in a piece 127 of [MAIL]. 129 Unless otherwise noted, the property extracted from the message MUST 130 be preserved precisely, with no characters omitted even if they are 131 considered syntax errors within context. 133 4.1. Assertions 135 The "email" reputation application recognizes the following 136 assertions: 138 CONTAINS-MALWARE: The subject property is associated with messages 139 that contain malware 141 IS-PHISH: The subject property is associated with fraudulent email 142 with a goal of identity theft 144 IS-SPAM: The subject property is associated with unwanted bulk email 146 4.2. Vocabulary Extensions 148 The "email-content" reputation application recognizes the following 149 extensions to the vocabulary defined in [RFCxxxx]: 151 SOURCE: A token indicating the source of the property; that is, 152 where the subject property was found in the message. This MUST be 153 one of: 155 RFC5321.MAILFROM: The RFC5321.MailFrom value of the envelope of a 156 message of the message (see [SMTP]) 158 RFC5322.FROM: The RFC5322.From field of the message (see [MAIL]). 159 Any folding whitespace MUST be rewritten to a single linear 160 space character (ASCII 32). 162 RFC5322.MESSAGE-ID: The RFC5322.Message-Id field of the message 163 (see [MAIL]) 165 RFC5322.SUBJECT: The RFC5322.Subject field of the message (see 166 [MAIL]). Any folding whitespace MUST be rewritten to a single 167 linear space character (ASCII 32). 169 UNSPECIFIED: Any arbitrary string from anywhere in the message. 171 URI: A complete URI found in the message, such as the content of 172 a "src" tag in an "img" element, or an "href" tag in an "a" 173 element. (See [URI] and [HTML]). 175 URI-HOST: The "host" portion of a URI found in the message. Note 176 that this can be a DNS domain name or an IP address, each in 177 any of various encodings. (See [URI] and [HTML]). 179 5. IANA Considerations 181 This memo presents one action for IANA, namely the registraton of the 182 reputation application "email-content". 184 5.1. Registration of 'email-content' Reputation Application 186 This section registers the "email-content" reputation application, as 187 defined in [RFCxxxx+1]. The registration parameters are as folows: 189 o Application name: email-content 191 o Short description: Evaluates any of various properties of an email 192 message that are not identities 194 o Defining document: [this memo] 196 o Status: current 198 6. Security Considerations 200 This memo describes security considerations introduced by the media 201 type defined here. 203 6.1. General 205 This memo is part of a series introducing a reputation query and 206 response system (see Section 2). The Security Considerations 207 sections of the other memos should also be consulted. 209 7. Informative References 211 [EMAIL-ARCH] 212 Crocker, D., "Internet Mail Architecture", RFC 5598, 213 July 2009. 215 [HTML] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 216 Specification", December 1999, 217 . 219 [KEYWORDS] 220 Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 224 October 2008. 226 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 227 October 2008. 229 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 230 Resource Identifier (URI): Generic Syntax", RFC 3986, 231 January 2005. 233 Appendix A. Public Discussion 235 Public discussion of this suite of memos takes place on the 236 domainrep@ietf.org mailing list. See 237 https://www.ietf.org/mailman/listinfo/domainrep. 239 Authors' Addresses 241 Nathaniel Borenstein 242 Mimecast 243 203 Crescent St., Suite 303 244 Waltham, MA 02453 245 USA 247 Phone: +1 781 996 5340 248 Email: nsb@guppylake.com 250 Murray S. Kucherawy 251 Cloudmark 252 128 King St., 2nd Floor 253 San Francisco, CA 94107 254 USA 256 Phone: +1 415 946 3800 257 Email: msk@cloudmark.com