Mimecast

203 Crescent St., Suite 303 Waltham MA 02453 USA +1 781 996 5340 nsb@guppylake.com

270 Upland Drive San Francisco CA 94127 USA superuser@gmail.com

Applications REPUTE Working Group reputation domain security messaging dkim spf authentication This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.

This document specifies a response set for describing the reputation of an email identifier. A "response set" in this context is defined in 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 . 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.

This section defines terms used in the rest of the document.

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 .

Commonly used definitions describing entities in the email architecture are defined and discussed in .

Other terms of importance in this document are defined in , the base document for the reputation services work.

The expression of reputation about an email identifier requires extensions of the base set defined in . This document defines and registers some common assertions about an entity found in a piece of .

The "email-id" reputation application recognizes the following assertions: The subject identifier is associated with sending or handling email of a personally abusive, threatening, or otherwise harassing nature 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 ) The subject identifier is associated with delivery attempts to nonexistent recipients The subject identifier is associated with the sending or handling of malware via email 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").

The "email-id" reputation application recognizes the following OPTIONAL extensions to the basic response set defined in : A token indicating the source of the identifier; that is, where the subject identifier was found in the message. This MUST be one of: The signing domain, i.e., the value of the "d=" tag, found on a valid DomainKeys Identified Mail signature in the message The IPv4 address of the client The IPv6 address of the client The RFC5321.HELO value used by the client (see ) The RFC5321.MailFrom value of the envelope of the message (see ) The RFC5322.From field of the message (see ) The domain name portion of the identifier (RFC5321.MailFrom or RFC5321.HELO) verified by 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.

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

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 .

This memo presents one action for IANA, namely the registration of the reputation application "email-id".

This section registers the "email-id" reputation application, as per the IANA Considerations section of . The registration parameters are as follows: 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 of this document) Application-specific query parameters: (current) as defined in of this document Application-specific assertions: (current) as defined in of this document (current) as defined in of this document (current) as defined in of this document (current) as defined in of this document (current) as defined in of this document Application-specific response set extensions: (current) as defined in of this document

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 .

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.</t><t> This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. This document defines the format of reputation response data ("reputons"), the media-type for packaging it, and definition of a registry for the names of reputation applications and response sets. This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over the Internet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC4101 for describing a protocol model. This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. This memo defines an Experimental Protocol for the Internet community. The use of reputation systems is has become a common tool in many applications that seek to apply collected intelligence about traffic sources. Often this is done because it is common or even expected operator practice. It is therefore important to be aware of a number of considerations for both operators and consumers of the data. This document includes a collection of the best advice available regarding providers and consumers of reputation data, based on experience to date. Much of this is based on experience with email reputation systems, but the concepts are generally applicable. This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. [STANDARDS-TRACK] Qualcomm Incorporated

5775 Morehouse Drive San Diego CA 92121-1714 US +1 858 651 4478 presnick@qualcomm.com http://www.qualcomm.com/~presnick/

This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.

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.

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.