From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7073.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc7073.txt (limited to 'doc/rfc/rfc7073.txt') diff --git a/doc/rfc/rfc7073.txt b/doc/rfc/rfc7073.txt new file mode 100644 index 0000000..e351546 --- /dev/null +++ b/doc/rfc/rfc7073.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) N. Borenstein +Request for Comments: 7073 Mimecast +Category: Standards Track M. Kucherawy +ISSN: 2070-1721 November 2013 + + + A Reputation Response Set for Email Identifiers + +Abstract + + This document defines a response set for describing assertions a + reputation service provider can make about email identifiers, for use + in generating reputons. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7073. + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + +Borenstein & Kucherawy Standards Track [Page 1] + +RFC 7073 Email Identifiers Response Set November 2013 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology and Definitions .....................................2 + 2.1. Key Words ..................................................2 + 2.2. Email Definitions ..........................................2 + 2.3. Other Definitions ..........................................3 + 3. Discussion ......................................................3 + 3.1. Assertions .................................................3 + 3.2. Response Set Extensions ....................................4 + 3.3. Identifiers ................................................4 + 3.4. Query Extensions ...........................................5 + 4. IANA Considerations .............................................5 + 4.1. Registration of 'email-id' Reputation Application ..........5 + 5. Security Considerations .........................................6 + 6. References ......................................................7 + 6.1. Normative References .......................................7 + 6.2. Informative References .....................................7 + Appendix A. Positive vs. Negative Assertions .......................8 + Appendix B. Acknowledgments ........................................8 + +1. Introduction + + This document specifies a response set for describing the reputation + of an email identifier. A "response set" in this context is defined + in [RFC7070] and is used to describe assertions a reputation service + provider can make about email identifiers as well as metadata that + can be included in such a reply beyond the base set specified there. + + An atomic reputation response is called a "reputon", defined in + [RFC7071]. That document also defines a media type to contain a + reputon for transport, and creates a registry for reputation + applications and the interesting parameters of each. + +2. Terminology and Definitions + + This section defines terms used in the rest of the document. + +2.1. Key Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KEYWORDS]. + +2.2. Email Definitions + + Commonly used definitions describing entities in the email + architecture are defined and discussed in [EMAIL-ARCH]. + + + +Borenstein & Kucherawy Standards Track [Page 2] + +RFC 7073 Email Identifiers Response Set November 2013 + + +2.3. Other Definitions + + Other terms of importance in this document are defined in [RFC7070], + the base document for the reputation services work. + +3. Discussion + + The expression of reputation about an email identifier requires + extensions of the base set defined in [RFC7070]. This document + defines and registers some common assertions about an entity found in + a piece of [MAIL]. + +3.1. Assertions + + The "email-id" reputation application recognizes the following + assertions: + + abusive: The subject identifier is associated with sending or + handling email of a personally abusive, threatening, or otherwise + harassing nature + + fraud: The subject identifier is associated with the sending or + handling of fraudulent email, such as "phishing" (some good + discussion on this topic can be found in [IODEF-PHISHING]) + + invalid-recipients: The subject identifier is associated with + delivery attempts to nonexistent recipients + + malware: The subject identifier is associated with the sending or + handling of malware via email + + spam: The subject identifier is associated with the sending or + handling of unwanted bulk email + + For all assertions, the "rating" scale is linear: a value of 0.0 + means there is no data to support the assertion, a value of 1.0 means + all accumulated data support the assertion, and the intervening + values have a linear relationship (i.e., a score of "x" is twice as + strong of an assertion as a value of "x/2"). + + + + + + + + + + + + +Borenstein & Kucherawy Standards Track [Page 3] + +RFC 7073 Email Identifiers Response Set November 2013 + + +3.2. Response Set Extensions + + The "email-id" reputation application recognizes the following + OPTIONAL extensions to the basic response set defined in [RFC7071]: + + email-id-identity: A token indicating the source of the identifier; + that is, where the subject identifier was found in the message. + This MUST be one of: + + dkim: The signing domain, i.e., the value of the "d=" tag, found + on a valid DomainKeys Identified Mail [DKIM] signature in + the message + + ipv4: The IPv4 address of the client + + ipv6: The IPv6 address of the client + + rfc5321.helo: The RFC5321.HELO value used by the client (see + [SMTP]) + + rfc5321.mailfrom: The RFC5321.MailFrom value of the envelope of + the message (see [SMTP]) + + rfc5322.from: The RFC5322.From field of the message (see [MAIL]) + + spf: The domain name portion of the identifier (RFC5321.MailFrom + or RFC5321.HELO) verified by [SPF] + + sources: A token relating a count of the number of sources of data + that contributed to the reported reputation. This is in contrast + to the "sample-size" parameter, which indicates the total number + of reports across all reporting sources. + + A reply that does not contain the "identity" or "sources" extensions + is making a non-specific statement about how the reputation returned + was developed. A client can use or ignore such a reply at its + discretion. + +3.3. Identifiers + + In evaluating an email message on the basis of reputation, there can + be more than one identifier in the message needing to be validated. + For example, a message may have different email addresses in the + RFC5321.MailFrom parameter and the RFC5322.From header field. The + RFC5321.Helo identifier will obviously be different. Consequently, + the software evaluating the email message may need to query for the + reputation of more than one identifier. + + + + +Borenstein & Kucherawy Standards Track [Page 4] + +RFC 7073 Email Identifiers Response Set November 2013 + + + The purpose of including the identity in the reply is to expose to + the client the context in which the identifier was extracted from the + message under evaluation. In particular, several of the items listed + are extracted verbatim from the message and have not been subjected + to any kind of validation, while a domain name present in a valid + DKIM signature has some more reliable semantics associated with it. + Computing or using reputation information about unauthenticated + identifiers has substantially reduced value, but can sometimes be + useful when combined. For example, a reply that indicates a message + contained one of these low-value identifiers with a high "spam" + rating might not be worthy of notice, but a reply that indicates a + message contained several of them could be grounds for suspicion. + + A client interested in checking these weaker identifiers would issue + a query about each of them using the same assertion (e.g., "spam"), + and then collate the results to determine which ones and how many of + them came back with ratings indicating content of concern, and take + action accordingly. For stronger identifiers, decisions can + typically be made based on a few or even just one of them. + +3.4. Query Extensions + + A query within this application can include the OPTIONAL query + parameter "identity" to indicate which specific identity is of + interest to the query. Legal values are the same as those listed in + Section 3.2. + +4. IANA Considerations + + This memo presents one action for IANA, namely the registration of + the reputation application "email-id". + +4.1. Registration of 'email-id' Reputation Application + + This section registers the "email-id" reputation application, as per + the IANA Considerations section of [RFC7071]. The registration + parameters are as follows: + + o Application symbolic name: email-id + + o Short description: Evaluates DNS domain names or IP addresses + found in email identifiers + + o Defining document: [RFC7073] + + o Status: current + + + + + +Borenstein & Kucherawy Standards Track [Page 5] + +RFC 7073 Email Identifiers Response Set November 2013 + + + o Subject: A string appropriate to the identifier of interest (see + Section 3.2 of this document) + + o Application-specific query parameters: + + identity: (current) as defined in Section 3.4 of this document + + o Application-specific assertions: + + abusive: (current) as defined in Section 3.1 of this document + + fraud: (current) as defined in Section 3.1 of this document + + invalid-recipients: (current) as defined in Section 3.1 of this + document + + malware: (current) as defined in Section 3.1 of this document + + spam: (current) as defined in Section 3.1 of this document + + o Application-specific response set extensions: + + identity: (current) as defined in Section 3.2 of this document + +5. Security Considerations + + This document is primarily an IANA action and doesn't describe any + protocols or protocol elements that might introduce new security + concerns. + + Security considerations relevant to email and email authentication + can be found in most of the documents listed in the References + sections below. Information specific to use of reputation services + can be found in [CONSIDERATIONS]. + + + + + + + + + + + + + + + + + +Borenstein & Kucherawy Standards Track [Page 6] + +RFC 7073 Email Identifiers Response Set November 2013 + + +6. References + +6.1. Normative References + + [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", STD 76, + RFC 6376, September 2011. + + [EMAIL-ARCH] + Crocker, D., "Internet Mail Architecture", RFC 5598, July + 2009. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC7070] Borenstein, N., Kucherawy, M., and A. Sullivan, "An + Architecture for Reputation Reporting", RFC 7070, November + 2013. + + [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for + Reputation Interchange", RFC 7071, November 2013. + + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + + [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) + for Authorizing Use of Domains in E-Mail, Version 1", RFC + 4408, April 2006. + +6.2. Informative References + + [CONSIDERATIONS] + Kucherawy, M., "Operational Considerations Regarding + Reputation Services", Work in Progress, May 2013. + + [IODEF-PHISHING] + Cain, P. and D. Jevans, "Extensions to the IODEF-Document + Class for Reporting Phishing", RFC 5901, July 2010. + + [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, + October 2008. + + + + + + + + + + +Borenstein & Kucherawy Standards Track [Page 7] + +RFC 7073 Email Identifiers Response Set November 2013 + + +Appendix A. Positive vs. Negative Assertions + + [CONSIDERATIONS] some current theories about reputation, namely that + it will possibly have more impact to develop positive reputations and + focus on giving preferential treatment to content or sources that + earn those. However, the assertions defined in this document are all + clearly negative in nature. + + In effect, this document is recording current use of reputation and + of this framework in particular. It is expected that, in the future, + the application being registered here will be augmented, and other + applications registered, that focus more on positive assertions + rather than negative ones. + +Appendix B. Acknowledgments + + The authors wish to acknowledge the contributions of the following to + this specification: Scott Hollenbeck, Scott Kitterman, Peter Koch, + John Levine, Danny McPherson, S. Moonesamy, Doug Otis, and David F. + Skoll. + +Authors' Addresses + + Nathaniel Borenstein + Mimecast + 203 Crescent St., Suite 303 + Waltham, MA 02453 + USA + + Phone: +1 781 996 5340 + EMail: nsb@guppylake.com + + + Murray S. Kucherawy + 270 Upland Drive + San Francisco, CA 94127 + USA + + EMail: superuser@gmail.com + + + + + + + + + + + + +Borenstein & Kucherawy Standards Track [Page 8] + -- cgit v1.2.3