| Internet-Draft | Relay Flow Identifier | January 2023 |
| Chuang | Expires 24 July 2023 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 July 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC7208] 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.¶
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 [RFC2119].¶
Acronyms¶
DomainKeys Identified Mail (DKIM) [RFC6376]- IETF standard for the cryptographic protocol to authenticate email at the domain level and protect the integrity of messages during transit.¶
This specification defines an identifier name for mail traversing a relay. Typically the relay uses password authentication such as methods provided for in [RFC4954] 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 [RFC6376]. 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 [RFC8617].¶
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.¶
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 [RFC4648] token, or be empty if no such delegated domain is present. It MAY include a local part url-safe base64 [RFC4648] 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:¶
0123456789 0123456789.abcdwxyz .abcdwxyz <empty>¶
This proposes a new DKIM [RFC8617] 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:¶
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
s=20230116; h=...; bh=...; b....=; rfid=0123456789.abcdwxyz
¶
This proposes a new ARC [RFC8617] ARC-Authentication-Result defined method [RFC8601] 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:¶
ARC-Authentication-Results: i=1; auth.example.com;
relay=pass (comments) policy.rfid=0123456789.abcdwxyz
¶
This document has no IANA actions yet.¶
Thanks goes to Emil Gustafsson for suggesting a DKIM specification.¶