A Reputation Response Set for Email Identifiers
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) Signatures
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]
Internet Mail Architecture
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.
Key words for use in RFCs to Indicate Requirement Levels
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.
A Media Type for Reputation Interchange
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.
An Architecture for Reputation Reporting
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.
Simple Mail Transfer Protocol
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]
Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
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.
Operational Considerations Regarding Reputation Services
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.
Extensions to the IODEF-Document Class for Reporting Phishing
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]
Internet Message Format
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.