RFC 7073

A Reputation Response Set for Email Identifiers

📅 published November 2013, from ietf

RFC 7073: A Reputation Response Set for Email Identifiers 💌

Okay bestie, let's start with the vibe check ✨ This is RFC 7073, titled "A Reputation Response Set for Email Identifiers" 🦋 It's a Standards Track document from November 2013 (ISSN 2070-1721). The authors are N. Borenstein (from Mimecast) and M. Kucherawy. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

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). More info on Internet Standards is in Section 2 of RFC 5741, if you're curious 🧚

Want the latest status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc7073 🔗

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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty as described in the Simplified BSD License.

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 🌸

So this doc specifies a response set for describing the reputation of an email identifier 💖 A "response set" here is defined in [RFC7070], and it's used to describe assertions a reputation service provider can make about email identifiers, plus any metadata that can ride along in a reply beyond the base set specified there.

An atomic reputation response is called a "reputon" (defined in [RFC7071]) 🧚 That doc also defines a media type for carrying a reputon during transport, and it creates a registry for reputation applications and the interesting parameters of each one.

2. Terminology and Definitions 📖

This section defines the terms used in the rest of the doc, so it's basically your glossary bestie 🫶

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 📬

Need the common definitions for the email architecture? They're defined and discussed in [EMAIL-ARCH] ✨

2.3. Other Definitions 🦋

Other terms that matter in this doc are defined in [RFC7070], the base document for the reputation services work. Main character energy, the base doc is the foundation for everything here 👑

3. Discussion 💬

Okay, so expressing reputation about an email identifier needs extensions to the base set defined in [RFC7070] 🙌 This document defines and registers some common assertions about an entity found in a piece of [MAIL]. It's giving organization. 💅

3.1. Assertions 🚩

The "email-id" reputation application recognizes these 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, and a value of 1.0 means all accumulated data support the assertion. The values in between have a linear relationship, so a score of "x" is twice as strong of an assertion as a value of "x/2" 📏✨

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, meaning 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 different from the "sample-size" parameter, which counts the total number of reports across all reporting sources 📊

A reply that doesn't contain the "identity" or "sources" extensions is making a non-specific statement about how the reputation was developed. A client can use or ignore such a reply at its discretion 🤷‍♀️✨

3.3. Identifiers 🔍

When you're evaluating an email message based on reputation, there can be more than one identifier in the message that needs validating 🫣 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 too. So the software evaluating the message may need to query the reputation of more than one identifier. Busy bestie behavior, but it makes sense 💁‍♀️

The reason for including the identity in the reply is to show the client the context in which the identifier was pulled from the message being evaluated. Some of the items listed are extracted verbatim from the message and have not been validated in any way, but a domain name in a valid DKIM signature has more reliable semantics attached to it 🔐 Computing or using reputation information about unauthenticated identifiers has substantially reduced value, but it can sometimes be useful when combined. For example, a reply showing that a message had one of these low-value identifiers with a high "spam" rating might not be worth noticing. But a reply showing that a message had several of them could be grounds for suspicion 🚨

A client that wants to check these weaker identifiers would send a query about each one using the same assertion (for example, "spam"). Then it collates the results to figure out which ones, and how many, came back with ratings showing content of concern, and it takes action accordingly. For stronger identifiers, decisions can typically be made based on a few of them, or even just one 💪

3.4. Query Extensions 🧩

A query within this application can include the OPTIONAL query parameter "identity" to say which specific identity the query is about. Legal values are the same as those listed in Section 3.2 ✅

4. IANA Considerations 🌷

This memo presents one action for IANA: registering 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:

  • Application symbolic name: email-id
  • Short description: Evaluates DNS domain names or IP addresses found in email identifiers
  • Defining document: [RFC7073]
  • Status: current
  • Subject: A string appropriate to the identifier of interest (see Section 3.2 of this document)
  • Application-specific query parameters:
    • identity: (current) as defined in Section 3.4 of this document
  • 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
  • Application-specific response set extensions:
    • identity: (current) as defined in Section 3.2 of this document

5. Security Considerations 🛡️

Okay, serious moment incoming 😭 This document is primarily an IANA action, and it doesn't describe any protocols or protocol elements that might introduce new security concerns. Still, 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 the use of reputation services can be found in [CONSIDERATIONS]. Read those, bestie. Seriously. 🫶

6. References 📚

To be continued... more references and appendices are coming in part 2! 🌈💖

6.1. Normative References ✨

Okay so, here are the reading-list essentials, the stuff you genuinely need to have read before this all makes sense, bestie 📚💖

[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 🎀

These ones are the extra-credit reads, the "ooh tell me more" stash 🧚

[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.

Appendix A. Positive vs. Negative Assertions 🦋

Okay this one is so good, bestie. The [CONSIDERATIONS] doc says some current theories about reputation suggest it might have more impact to build up positive reputations and to give preferential treatment to the content or sources that earn them 🌈 But the assertions defined in this document are all clearly negative in nature 💀

Basically, this document is just recording how reputation is being used right now, and this framework in particular. It's expected that in the future, the application being registered here will get augmented, and other applications will be registered, that focus more on positive assertions instead of negative ones ✨👑

Appendix B. Acknowledgments 🫶

The authors wanted to shout out the people who contributed to this spec: Scott Hollenbeck, Scott Kitterman, Peter Koch, John Levine, Danny McPherson, S. Moonesamy, Doug Otis, and David F. Skoll. Iconic contributors, all of them 💅💜

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
📦 where this page comes from