A Reputation Response Set for Email Identifiers
Extracted elements (12)
All assertions defined in this document are negative in nature, reflecting current operational use of reputation services. Future augmentations are expected to add positive assertions, as current theory suggests positive reputations (preferential treatment for trusted sources) may have greater impact than negative filtering.
Computing reputation about unauthenticated identifiers has substantially reduced value, but can be useful in combination: a single low-value identifier with a high spam rating may not warrant action, but several such identifiers together could be grounds for suspicion.
Multiple identifiers in an email message (RFC5321.MailFrom, RFC5322.From, RFC5321.HELO) may need separate reputation queries. The 'identity' field in replies exposes the context in which each identifier was extracted, particularly distinguishing validated identifiers (e.g., DKIM-signed domains) from unauthenticated ones.
A reply that does not 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.
The 'email-id-identity' extension value MUST be one of the enumerated tokens: dkim, ipv4, ipv6, rfc5321.helo, rfc5321.mailfrom, rfc5322.from, or spf.
A query within the 'email-id' application can include the OPTIONAL query parameter 'identity' to indicate which specific identity is of interest; legal values are the same as those defined for the 'email-id-identity' response extension.
For all assertions in the 'email-id' application, the rating scale is linear: 0.0 means no data supports the assertion, 1.0 means all accumulated data supports it, and intervening values have a linear relationship (a score of x is twice as strong as x/2).
The 'email-id-identity' response set extension is an OPTIONAL token indicating where the subject identifier was found in the message. Valid values are: dkim (signing domain from valid DKIM signature), ipv4, ipv6, rfc5321.helo, rfc5321.mailfrom, rfc5322.from, and spf (domain verified by SPF).
The 'email-id' reputation application defines five assertions: 'abusive' (personally abusive/threatening/harassing email), 'fraud' (phishing and fraudulent email), 'invalid-recipients' (delivery attempts to nonexistent recipients), 'malware' (sending/handling malware via email), and 'spam' (unwanted bulk email).
The 'sources' response set extension is an OPTIONAL token indicating the count of data sources that contributed to the reported reputation, as distinct from 'sample-size' which counts total reports across all sources.
This document registers the 'email-id' reputation application in the IANA reputation application registry (established by RFC 7071). The application evaluates DNS domain names or IP addresses found in email identifiers, with subject strings appropriate to the identifier of interest.
This document is primarily an IANA action and does not describe protocols or protocol elements that introduce new security concerns. Security considerations for email and email authentication are addressed in the referenced documents, and considerations specific to reputation services are in [CONSIDERATIONS].