]> 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, base64 identifier token 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 () for originating traffic and ARC 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.

Terminology and Definitions 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 for authenticated relay. Typically it is password authenticated such as methods provided for in but other methods MAY be possible. This identifier MAY be used for other authenticated forwarding flows such as mailing lists and with other authentication methods such DKIM or SPF that verifies who the sender is. Because some relays may be originated at the relay which traditionally will be DKIM signed, this document provides a specification for DKIM (). In other instances, relays act as forwarders, and these are sometimes not DKIM signed by the relay so instead this document proposes a specification using ARC ().

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. If a message is associated with more than one flow, the relay SHOULD select the more specific flow based on local policy. This specification defines the relay flow identifier as a base64 () token. That name MUST not be any internal name of the relay though MAY be a secure cryptographic hash of such.

DKIM This proposes a new DKIM DKIM-Signature tag-value that identifies the presence of a relay flow and a flow identifier as a token. The tag is defined "rfid", while the token value is in base64 (). The token parsers MUST ignore a reserved comma 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 flow identifier as a token. 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 "id" property i.e "policy.id" that takes a single token value. That token value is in base64 (). The token parser MUST ignore a reserved comma that may be further specified in the future. Example: \

Privacy Considerations

Security Considerations

IANA Considerations This document has no IANA actions yet.

Normative References 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] 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. 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. 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.