summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7073.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7073.txt')
-rw-r--r--doc/rfc/rfc7073.txt451
1 files changed, 451 insertions, 0 deletions
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]
+