]> Google, Inc.

weihaw@google.com

Independent Stream DKIM ARC Relay To prevent spammers from using relay forwarding, we propose to identify relay flows. We do this by having relays categorize their authenticated traffic flows and publish to receivers identifiers associated with those flows. This is a unique, persistent over time, relay flow identifier name that is secured by some digital signature. Receivers can use this identifier to help categorize traffic through the relay and use that identifier to apply fine-grain anti-abuse policies instead of on the entire traffic through the relay. This document provides a specification for DKIM (RFC6376) for originating traffic and ARC (RFC8617) for forwarded traffic.

Introduction Spammers utilize relays to obfuscate their identities and often to spoof some other identity with email receivers. For example a spammer may exploit the shared tenancy vulnerability of SPF to spoof some identity as follows. It finds a relay that hosts many different enterprise customers who include the relay's IPs in their SPF policies. The spammer then sends traffic through the relay assuming the identity of one of those customers i.e. it spoofs the MAIL FROM identity of the victim domain. While the SPF validation (if done) of the initial send by the spammer to the relay fails, a subsequent SPF validation when forwarded to some other victim receiver from the relay will pass SPF because the IPs are contained in the victim's SPF policy. At some point, the receiver notices the spam via the relay and wants to apply anti-abuse counter measures. With existing authentication methods, this policy would impact all mail flows through that relay, both innocent and malicious. A better approach would be to selectively apply anti-abuse counter measures to the spammer's flow which is what this proposal enables. Better yet, the receiver is enabled to cluster traffic to a spammer controlled domain and apply policies scoped to what the spammers have control over.

Terminology and Definitions 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 . Acronyms

• Authenticated Received Chain (ARC) - is a protocol that is meant to resolve some of the issues for DMARC to fix the problems that DMARC policy rejects caused by mail forwarding, and is based on DKIM, but suffers from similar issues as DKIM replay. ARC defines digital signatures and Authentication-Results by ADMD and a versioning mechanism for them.
• Authentication-Results - A header containing a list of validation results and comments.
• DomainKeys Identified Mail (DKIM) - IETF standard for the cryptographic protocol to authenticate email at the domain level and protect the integrity of messages during transit.
  • DKIM replay- section 8.6 defines a vulnerability called DKIM Replay as a spam message sent through a SMTP MTA DKIM signer, that then is sent to many more recipients, leveraging the reputation of the signer.
• Sender Policy Framework (SPF) - IETF standard for authenticating sending servers typically based on IP address.

Relay Flow Identifier Specification This specification defines an identifier name for mail traversing a relay. Typically the relay uses password authentication such as methods provided for in but other methods MAY be possible. This identifier MAY also be used for authenticated forwarding flows such as mailing lists and with other authentication methods such DKIM or SPF that verify who the sender is. Because some traffic may have originated at the relay, which traditionally may be DKIM signed, this document provides a specification for DKIM . In other instances, the relay forwards traffic originated elsewhere, and these are typically not DKIM signed by the relay, so instead this document provides a specification using ARC . Email Service Providers can delegate relay and forwarding services to enterprise customers, typically associated with some customer domain. Spammers utilize these features either by acting as an enterprise customer or by hijacked accounts. This specification proposes naming flows by enterprise customers to help the email receiver with categorization and application of anti-abuse counter measures. As some mechanisms for mail forwarding such as mailing lists are often opaque after being sent and problematic for debug and abuse protection, this offers a naming scheme to help identify those mechanisms.

Flow Identification The relaying service choosing to use this specification MUST categorize and name relayed traffic flows such that receivers can do anti-abuse analysis upon them if necessary. In order for the identifier to be effective, it SHOULD be persistent in time and uniquely named across all flows through the relay. As relayed traffic flow is often associated with a delegated domain, the first part of the identifier MUST either include a domain associated url-safe base64 token, or be empty if no such delegated domain is present. It MAY include a local part url-safe base64 token after the domain token and separated by a period '.'. This local part token can help describe the mail forwarding mechanism. Combined the domain token and the optional local token form the relay flow identifier name. If a message is associated with more than one flow, the relay SHOULD select the more specific flow based on local policy. That name MUST NOT be any relay internal name though MAY be a secure cryptographic hash of such. Also that name MUST NOT contain or be associated with any Personally Identifiable Information (PII). The parser should ignore commas '+' whose use may be specified in the future. Example valid names: ]]>

DKIM This proposes a new DKIM DKIM-Signature tag-value that identifies the presence of a relay flow and a relay flow identifier name. The tag is defined "rfid", while the value name consists of a domain url-safe base64 token and the optional local url-safe base64 token separated by a period. The token parsers MUST ignore a reserved plus that may be further specified in the future. Example:

ARC This proposes a new ARC ARC-Authentication-Result defined method that identifies the presence of a relay flow and its property that identifies a relay flow identifier name. The defined method is "relay", which when present, takes a single result value of "pass" that indicates the relay was authenticated. The relay method will have a propspec tag-value with a policy ptype with a "rfid" property i.e "policy.rfid" that takes a single token value. That token value consists of a domain url-safe base64 token and the optional local url-safe base64 token separated by a period. The token parsers MUST ignore a reserved plus that may be further specified in the future. Example:

Privacy Considerations

Security Considerations

IANA Considerations This document has no IANA actions yet.

Normative References Email 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 "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes RFC 7601. 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. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP. This document obsoletes RFC 2554. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]

Acknowledgments Thanks goes to Emil Gustafsson for suggesting a DKIM specification.