Replay Resistant Authenticated Receiver Chain

1.1.1. Definitions

SMTP transport and particular email senders and receivers are defined in [RFC5321]. Email payload and headers are defined in [RFC5322]. This document uses [RFC5598] email flow definitions, which describes the interactions between the parties in sending email. In particular these parties assist the email senders and receivers in email transport. draft-ietf-dkim-replay-problem adds context to those mailflows for the DKIM replay problem.¶

1.1.2. Acronyms

ADMD:

ADministrative Management Domain is defined as [RFC5598] and represents the independent operational scope authorship, handling, and receiving.¶

ARC:

Authenticated Received Chain [RFC8617] - is a protocol that is meant to resolve some of the issues for DMARC [RFC7489] to fix the problems that DMARC policy rejects caused by mail forwarding. ARC uses a digital signing mechanism derived from DKIM to protect the integrity of the Authentication-Results of a forwarder and a versioning mechanism to describe the forwarders. ARC suffers from similar replay issues as DKIM.¶

Authentication-Results:

A header containing a list of email authentication validation methods, results and comments as specified in [RFC8601].¶

DKIM:

DomainKeys Identified Mail [RFC6376] standard for the cryptographic protocol to authenticate email at the domain level and protect the integrity of messages during transit.¶

DKIM replay

As defined in [RFC6376] section 8.6- 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.¶

DMARC:

Domain-based Message Authentication, Reporting, and Conformance [RFC7489]- defines a sender defined message handling policy for spoofed messages to be applied when a message is delivered at some receiving SMTP server.¶

MDA

Message Delivery Agent defined in [RFC5598].¶

MSA

Message Submission Agent defined in [RFC5598].¶

MTA

Message Transfer Agent defined in [RFC5598].¶

SPF:

Sender Policy Framework [RFC7208] standard for authenticating sending servers typically based on IP address.¶

3.1.1. Declaring All Recipients

The specified email authentication protocol is resistant against replay attacks by explicitly identifying all recipients in the headers, including when the recipient is "hidden" such as Bcc: or Mailing-lists. That way when a signed message arrives, the receiver can check if the RCPT TO recipient correctly is a subset of the recipient in the signed message header. If not, then the message MAY be part of a replay attack. When To: and Cc: recipients are declared by their headers, they MUST be specified in the "h=" header list and signed by DKIM-Signature or ARC-Message-Signature. For blind carbon copy, while a Bcc: header might be added, it can be stripped by subsequent forwarders. Instead we create a new _Forwarded-to: _ header that includes an ARC set versioning number to indicate which ADMD sent the message to a new recipient. It MAY include one or more comma separated recipients. Whitespaces in the recipient list are ignored.¶

Forwarded-to: i=1; user@example.com, user2@example.com

As part of the DARA protocol, recipients not declared by To: or Cc: MUST be declared with the Forwarded-to: header. This supports the email forwarder and mailing list scenario where we also use the Forwarded-to header to indicate that a message is sent to a new recipient. Forwarded-to: _MUST be propagated by forwarders unmodified. For the privacy of "hidden" recipients and to prevent their identity from being visible to other recipients via the _Forwarded-to: header, the message MUST be split and signed exclusively for each Forwarded-to: recipient. This means the header is visible only to that recipient. Messages sent to a new ADMD but with the same recipient identity disclosed by a prior Forwarded-to MAY elect to optimize header space by skipping adding a redundant Forwarded-to header.¶

To protect the integrity of the Forwarded-to: header, they MUST be hashed and signed by ARC-Seal as follows: Collect all Forwarded-to: headers and hash them following the header processing algorithm in RFC6376 section 5.4. This hash is published in the ARC-Message-Signature header as "fh=" tag and base64 hash value. DARA aware verifiers can recompute the hash and check it against the hash contained in the "fh=" tag to verify the integrity of the Forwarded-to: headers. For example:¶

ARC-Message-Signature: i=1; fh=abcd...
Forwarded-to: user@example.com

3.1.2. Protocol Awareness

Senders and receivers MAY variously support the DARA protocol or not, so the protocol needs to be tolerant of ADMDs that don't support the protocol. For example a naive mailing list sender sending to a protocol aware receiver SHOULD NOT have traffic rejected simply because it didn't follow the protocol. Yet simultaneously, the DARA protocol needs to discourage abuse by spammers seeking to use the naive ADMD path for replay. The protocol calls for the DARA aware senders to lookup the capability of the receiver in supporting DARA and disclose that capability in the message. All ADMD supporting the DARA protocol SHOULD publish a DNS TXT policy record. The DARA aware sender SHOULD look up the receiver's policy record as described next or look up an internal list of receivers that support DARA. The following paragraph describes the DARA DNS policy record and disclosure statement, and the following paragraph describes when the ADMD does not support DARA.¶

When the ADMD indicates it supports DARA via DNS, the ADMD publishes a DNS TXT policy record at the supported domain name, prepended with a "_dara" label. The format of the policy record are tag/values in form of the textual representation in RFC6376 section 3.2. The policy record MUST start with a DARA version tag "v=" with a DARA version number that MUST be set to "DARA_1.0". The lookup also discovers the destination domain name, and that destination domain MUST match the ADMD's ARC-Seal "d=" signing domain [RFC8617] which enables tracing this domain From sender to receiver as described later. The signing domain name is specified by the tag "dara=" with value being that domain name. The "dara=" signing domain enables an Email Service Provider (ESP) to forward mail on behalf of someone else. Once discovered, this domain is copied to "dara=<domain>" domain that is then placed in the sender's DKIM-Signature or ARC-Seal. The "dara=" tag/value indicates support by the receiver for the DARA as well as the identity of the intended receiver signing domain. The following is an example of a DARA DNS policy record for example.org that normalizes to example.com. The TXT record is published at _dara.example.org and contains:¶

v=DARA_1.0; dara=example.com

If no such DNS TXT policy record is found or not in the list of supported domains, then the receiver does not support the DARA protocol. This is indicated by the tag "darn=" with the receiving domain as the value. This is placed in the sender's DKIM-Signature or ARC-Seal. The "darn=" tag indicates to subsequent DARA aware receivers that there was an intermediate naive forwarder. Also, when there is spam, instead of penalizing the sender that is DARA aware, the receiver MAY elect to apply the reputation penalty to the receiving domain that is naive to DARA.¶

A DARA aware receiver MAY elect to check the sender's policy if it suspects that a malicious forwarder was acting as a Man-In-The-Middle and has stripped off some prior sender's DARA policy. If it detects a DARA declaration in the sender's DNS policy, but not declared in the message, the receiver MAY elect to treat the message as spam.¶

3.1.3. Receiver Verification

A DARA aware receiver looks in the message to determine how to do DARA validation. First it looks for the most recent ARC-Seal (if present) using the ARC set number to determine recency. If not present then it looks for a DKIM-Signature. When found, a DARA aware receiver verifies the integrity of the header, then looks for a DARA tag/values and these are interpreted as follows. If the tag is "dara=", then the receiver MUST validate the recipients, and if it fails verification, treat the message as DARA unauthenticated with the implication that the message might be replayed. The recipient verification process for a given forwarder is to collect all the recipients in the To, Cc and prior Forwarded-to headers. In particular, for a forwarder i=n, the verifier collects all Forwarded-to headers from i=1 to i=n-1. It verifies that they are signed appropriately and if not fails the verification. The verifier checks that the To and Cc headers are present in the sender's DKIM-Signature or ARC-Message-Signature "h=" header list, and signed. Next it checks the integrity of the Forwarded-to headers by validating the "fh=" hash. The receiver collects all Forwarded-to: headers and hash them following the header processing algorithm in RFC6376 section 5.4, then checks the hash against the value associated with the "fh=" tag. If this mismatches, this is treated as failing verification. Assuming headers integrity, the receiver then collects all the RCPT TO recipients as the envelope recipients. The receiver then verifies that the envelope recipients are a subset of the signed headers. If not a subset, this too is treated as failing verification.¶

As with other email authentication methods, the receiver's verifier is free to apply a locally defined policy against unauthenticated email. Next if the sender's tag is "dara=", the verifier SHOULD treat validation success as pass, and validation failure as fail. If the sender' tag is "darn=", the verifier SHOULD treat recipient verification failure as neutral and SHOULD treat success as pass. This discretionary validation mode is to support the scenario of DARA unaware ADMDs that may cause false positive validation failures. The domain value associated with the "darn=" tag helps identify the naive ADMD in processing local policy.¶

After the receiver's verifier applies the "dara=" or "darn=" policy as described above, the result of this verification MUST be published in the ARC-Authentication-Results. The verifier describes the result with [RFC8601] method "dara", and a result value of pass, fail or neutral. Receivers MUST declare the RCPT TO identity of that the message was received as a property header.i=<recipient email address>. This is to enable 3rd party mail flow validation as will be described shortly. For example the ARC-Authentication-Result could look like:¶

ARC-Authentication-Result: i=2; dara=pass header.i=user@example.com¶

3.1.4. 3rd Party Verification

A third party verifier MUST be able to verify that DARA results from the sender and receiver using only values in the message headers and DNS. First the verifier identifies the sender and receiver. The sender may be identified by ARC-Seal with an ARC set number preceding the receiver or DKIM-Signature if no prior ARC-Seal is discovered. The sender's "dara=" or "darn=" policy declaration in the ARC-Seal or DKIM-Signature. The receiver's results will be found in the ARC-Authentication-Results. For both the sender and receiver, the integrity of the headers are checked i.e. checking the ARC-Seal and then the "fh=" hash. If it passes, then verifier determines the sender's declaration of the receiver's DARA support, by looking for "dara=" tag in the DKIM-Signature or ARC-Message-Signature. The value of the "dara=" domain MUST match the receiver's ARC-Seal's "d=" domain, and the receiver's ARC seal MUST verify. The 3rd party verifier SHOULD also check to see if the ARC-Authentication-Result "header.i=" is a subset of the declared and signed header so far. If these step pass, the 3rd party verification passes. If verification at any individual fails, the 3rd party verification fails. The above procedure can later be used by the Chain verification algorithm in Section 4 to construct verification across multiple senders and receivers in the mail flow.¶

3.3.1. Originator ==> Mailing-List ==> Receiver

Originator outbound¶

DKIM-Signature: d=originator.example.com; dara=mailinglist.example.com
To: list@mailinglist.example.com

Mailing-List inbound (after ARC seal)¶

ARC-Seal: i=1; d=mailinglist.example.com;
ARC-Authentication-Results: i=1; dara=pass
     header.i=list@mailinglist.example.com (rcpt.to
     list@mailinglist.example.com matches signed header)
DKIM-Signature: d=originator.example.com; dara=mailinglist.example.com
To: list@mailinglist.example.com

Mailing-List outbound (after ARC reseal)¶

Forwarded-to: i=1; user@receiver.example.org
ARC-Seal: i=1; d=mailinglist.example.com...
ARC-Message-Signature: i=1; fh=...
ARC-Authentication-Results: i=1; dara=pass
     header.i=list@mailinglist.example.com (rcpt.to
     list@mailinglist.example.com matches signed header)
DKIM-Signature: d=originator.example.com; dara=mailinglist.example.com
To: list@mailinglist.example.com

Receiver inbound (after ARC seal)¶

ARC-Seal: i=2; d=receiver.example.org...
ARC-Message-Signature: i=2; fh=...
ARC-Authentication-Results: i=2; dara=pass
        header.i=user@receiver.example.org (rcpt.to
        user@receiver.example.org matches signed header)
Forwarded-to: i=1; user@receiver.example.org
ARC-Seal: i=1; d=mailinglist.example.com...
ARC-Message-Signature: i=1; fh=...
ARC-Authentication-Results: i=1; dara=pass
     header.i=list@mailinglist.example.com (rcpt.to
     list@mailinglist.example.com matches signed header)
DKIM-Signature: d=originator.example.com; dara=mailinglist.example.com
To: list@mailinglist.example.com

3.3.2. Originator ==> First Receiver; Replay ==> Victim Receiver

Originator outbound (after ARC seal)¶

DKIM-Signature: d=originator.example.com; dara=receiver.example.com
To: user@receiver.example.com

First receiver inbound (after ARC seal)¶

ARC-Seal: i=1; d=receiver.example.com
ARC-Authentication-Results: i=1; dara=pass
     header.i=user@receiver.example.com (rcpt.to
     user@receiver.example.com matches signed header)
DKIM-Signature: d=originator.example.com; dara=receiver.example.com
To: user@receiver.example.com

Above message captured by spammer, modified (add additional headers) and then resent. A spammer might send the message to john.doe@victim.example.net which would be unspecified in the headers.¶

Victim (last) receiver inbound (after ARC seal)¶

ARC-Seal: i=2; d=victim.example.net
ARC-Authentication-Results: i=2; dara=fail
     header.i=john.doe@victim.example.net (rcpt.to
     john.doe@victim.example.net mismatches signed header);
ARC-Seal: i=1; d=receiver.example.com
ARC-Authentication-Results: i=1; dara=pass
     header.i=user@receiver.example.com (rcpt.to
     user@receiver.example.com matches signed header)
DKIM-Signature: d=originator.example.com; dara=receiver.example.com
To: user@receiver.example.com

3.3.3. Originator ==> Naive-Forwarder ==> Receiver

This describes a message sent through Bcc to a forwarder that does not support DARA.¶

First outbound (after ARC seal)¶

ARC-Seal: i=1; d=originator.example.com; darn=naive.example.com;
ARC-Message-Signature: i=1; fh=...
Forwarded-to: i=1; user@naive.example.com
Bcc: user@naive.example.com

The naive forwarder changes the recipient address from user@naive.example.com to user@aware.example.com, and the envelope recipient will change accordingly. aware.example.com supports DARA.¶

Final inbound (after ARC seal).¶

ARC-Seal: i=2; d=aware.example.com
ARC-Authentication-Results: i=2; dara=neutral
     header.i=user@aware.example.com (rcpt.to
     user@aware.example.com mismatches signed header);
ARC-Seal: i=1; d=originator.example.com; darn=naive.example.com;
ARC-Message-Signature: i=1; fh=...
Forwarded-to: i=1; user@naive.example.com
Bcc: user@naive.example.com

At receiver, the declared and signed recipient user@naive.example.com will mismatch the envelope recipient user@aware.example.com, and fail DARA. However the protocol is set to optional verification with "darn=", and so does not report the failure. The domain specified naive.example.com by "darn=" may be useful by spam filters at the receiver. For example the SPF HELO domain may match the "darn=" domain.¶

4.4.1. Originator ==> Mailing-List ==> Receiver

This is an example of mail being sent from one Mail-Box-Provider to another through a Mailing-List where all ADMDs participate in DARA. In this illustrative example, we show the construction of the headers.¶

Originator (after ARC seal)¶

ARC-Seal: i=1; d=originator.example.com;
    dara=mailinglist.example.com
ARC-Authentication-Results: i=1
To: mailing.list@mailinglist.example.com

Mailing-List outbound (after ARC seal)¶

ARC-Seal: i=2; d=mailinglist.example.com;
    dara=destination.example.com
ARC-Authentication-Results: i=2; dara=pass; chain=pass
ARC-Seal: i=1; d=originator.example.com;
    dara=mailinglist.example.com
ARC-Authentication-Results: i=1
To: mailing.list@mailinglist.example.com

Receiver inbound (after ARC seal)¶

ARC-Seal: i=3; d=receiver.example.com
ARC-Authentication-Results: i=3; dara=pass; chain=pass
ARC-Seal: i=2; d=mailinglist.example.com;
    dara=destination.example.com
ARC-Authentication-Results: i=2; dara=pass; chain=pass
ARC-Seal: i=1; d=originator.example.com;
    dara=mailinglist.example.com
ARC-Authentication-Results: i=1
To: mailing.list@mailinglist.example.com

The global Chain verification result is pass and the message is considered DARA authenticated. The constructed path is [originator.example.com, mailinglist.example.com, receiver.example.com].¶

4.4.2. Originator ==> Naive-Forwarder ==>Aware-Forwarder ==>Aware-Receiver

This demonstrates a naive forwarder naive.example.com that does not support DARA/Chain. The headers represent what would be seen after inbound delivery to the receiver.¶

ARC-Seal: i=3; d=receiver.example.com
ARC-Authentication-Results: i=3; dara=pass; chain=neutral
ARC-Seal: i=2; d=intermediate.example.com;
    dara=receiver.example.com
ARC-Authentication-Results: i=2; chain=neutral
ARC-Seal: i=1; d=originator.example.com; snr=naive.example.com
ARC-Authentication-Results: i=1
To: user@naive.example.com

The global Chain verification result is neutral and the message is considered DARA unauthenticated. The constructed path is [originator.example.com, naive.example.com, intermediary.example.com, receiver.example.com].¶

4.4.3. Originator ==> Receiver ; Spammer ==> Victim Receiver

Headers as seen by the receiver ADMD.¶

ARC-Seal: i=2; d=receiver.example.com
ARC-Authentication-Results: i=2; dara=pass; chain=pass
ARC-Seal: i=1; d=originator.example.com;
    dara=receiver.example.com
ARC-Authentication-Results: i=1
To: user@receiver.example.com

Final headers as seen by the victim ADMD after replay injection to victim.example.com domain.¶

ARC-Seal: i=3; d=victim.example.com
ARC-Authentication-Results: i=3; chain=fail
ARC-Seal: i=2; d=receiver.example.com
ARC-Authentication-Results: i=2; dara=pass; chain=pass
ARC-Seal: i=1; d=originator.example.com;
    dara=receiver.example.com
ARC-Authentication-Results: i=1
To: user@receiver.example.com

Note at ARC set #2, it does not set a "dara=" tag, causing a path discontinuity. Due to the path discontinuity, the global Chain verification result is fail and the message is considered DARA unauthenticated. The constructed path is [dara-fail].¶

B.2.1. Concepts

We can create a challenge response system using cryptographic signing orchestrated between the sender and receiver of an SMTP transaction. The receiver challenges the sender to sign a mutually agreed upon value with their secret key, and can demonstrate a proof of that SMTP client-server relationship to 3rd parties. One problem is that the receiver can't proactively issue the challenge, so as part of the EHLO, the server issues the challenge as an optional SMTP extension argument. The sender can respond with the signature incorporating the shared value as a SMTP extension verb. Another problem is preventing a malicious party from intercepting a message and trying to replicate the challenge. We propose using a timestamp that can't be used in the future i.e. both parties make sure the timestamp reasonably represents the current time. This cryptographic challenge needs to sign a hash that ties the signature back to the message, and for this proposal, we take the whole message hash from the ARC-message-signature. In addition the destination domain is specified to reduce the risk for this signature to be intercepted and reused for other communications with other destination domains.¶

Such a protocol can help authenticate to a receiver that some sender sent a message without risk of replay via some third party. Sender Receiver Co-Signing (SeRCi pronounced Cersei as in the Game-of-Thrones character) could be used similarly to SPF [RFC7208] but without the risk of shared tenancy attack, IP reuse attack, and BPG vulnerabilities. Moreover a third party can independently verify the result that some sender and receiver sent the given message at the given time. This obviates the need to trust the ARC-Authentication-Results. Later we use SeRCi metadata to describe the forwarding path of the message.¶

This protocol signs the messages content at the exit to the ADMD to protect the SMTP transaction and yet be insensitive to message body or header modifications by the ADMD. This is necessary to tolerate the changes that a legitimate forwarder may make such as a mailing list adding a footer or adding the name of the mailing list to the Subject header. Other forwarders may alter the Content-Transfer-Encoding or delete attachments which this protocol also tolerates. However malicious forwarders may add or replace malicious content to otherwise benign messages and this must be detected. SeRCi identifies message body changes via different body hashes between the originator and the destination. If a message is unchanged between the originator to destination, then malicious content is attributed to the originator. If a message is changed and there is malicious content, then the originator and the mutating ADMDs are assigned responsibility. Potentially the attribution can affect the receiver reputation given to the ADMDs. The existing ARC protocol can do this, however it is a risky endeavor due to the potential for ARC replay and looseness around when ARC does its ARC-Message-Signature.¶

SERCI-SIGNATURE <sender domain> <selector> <header-body hash> \
<message-body hash> <signature>

base64(signsender(sha256(<sender domain><selector><header hash>\
<message body hash><timestamp>)))

EHLO sender.example.com
250-sender.example.com at your service, [1.2.3.4]
250-SIZE 157286400
...
250 SMTPUTF8
250 SERCI <timestamp>
MAIL FROM:<sender>`
RCPT TO:<recipient>
DATA <message>
SERCI-SIGNATURE <sender domain> <selector> \
base64(<message body hash>) base64(<header hash>) \
base64(signsender(sha256(<sender domain><selector><header hash> \
<message body hash><timestamp>)))

v=SERCI_1.0; serci=example.com

ARC-Authentication-Results i=1; serci=<pass|fail> (<comment>)
     smtp.sd=<sender domain>
     smtp.s=<sender domain>
     smtp.bh=base64(<message body hash>)
     smtp.hh=base64(<header body hash>)
     smtp.t=<timestamp>
     smtp.s=<selector>
     smtp.b=base64(<signature>)

B.2.2. Header Example

ARC-Seal: i=1; d=destination.example.com
ARC-Authentication-Results: i=1; serci=pass (comment)
     smtp.sd=originator.example.com smtp.s=selector
     smtp.bh=message_body_hash_base64 smtp.t=1664511950175
     smtp.s=signature_base64
ARC-Seal: i=1; d=originator.example.com; serci=destination.example.com
ARC-Authentication-Results: i=1
To: user@destination.example.com

B.3.1. Flow Identification Token

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>

B.3.2. ARC Authentication-Result Method

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

B.3.3. Spammer ==> Relay ==> Receiver

This demonstrates a spammer sending a message through a relay to receiver.¶

ARC-Seal: i=2; d=receiver.example.com
ARC-Authentication-Results: i=2; spf=pass; dara=pass; chain=pass
ARC-Seal: i=1; d=relay.forwarder.com;
    dara=destination.example.com
ARC-Authentication-Results: i=1; spf=neutral; relay=pass
    policy.rfid=relay+flow+id
To: user@receiver.example.com
From: spoofed_user@victim.example.com

As with the above, a better approach might be to use the path based reputation system where the relay flow identifier is used to replace the domain in the path . The spammy forwarding path is [spf-neutral, relay+flow+id, receiver.example.com]. Reputation analysis using this identifier with the relay flow identifier will be more specific than the domain based approach.¶

B.3.4. Spammer ==> Gullible Forwarder ==> Receiver

In this example the spammer does not participate in ARC or DARA/Chain protocol. The spammer forwards a message through an permissive cloud provider gullible.forwarder.com to reach the inbox of some user at destination.example.com. Spammer selects a victim domain that uses email services of gullible.forwarder.com such that they include the IPs of gullible.forwarder.com in their SPF policy. While the spammer cannot SPF authenticate at inbound to gullible.forwarder.com, they can SPF authenticate at inbound to destination.example.com, hence the SPF upgrade attack.¶

ARC-Seal: i=2; d=receiver.example.com
ARC-Authentication-Results: i=2; spf=pass; dara=pass; chain=pass
ARC-Seal: i=1; d=gullible.example.com;
    dara=receiver.example.com
ARC-Authentication-Results: i=1; spf=neutral
To: user@guillible.example.com
From: spoofed_user@victim.example.com

While SPF and consequently DMARC is pass at the receiver, DARA/Chain verification result is neutral because the message was not originated at victim.example.com. A DMARC evaluation would likely pick the SPF result. Instead a better approach might be to use the path based reputation system. The spammy forwarding path is [spf-neutral, gullible.example.com, receiver.example.com] which include evidence of the spammer. Contrasts that to the path from a normal message delivery by victim.example.com using their cloud provider which either would look like [victim.example.com, receiver.example.com] or [victim.example.com, gullible.example.com, receiver.example.com]. Both would be distinct from the spammer forwarding flow in a path aware reputation system.¶

The spammer may attempt to confuse the receiver by replaying ARC headers before forwarding to gullible.forwarder.com. This would change the DARA/Chain verification result to fail and the constructed path very much [arc-fail, gullible.example.com, destination.example.com]. As gullible.forwarder.com is ARC and DARA aware, it would indicate that the replayed ARC headers would not pass ARC verification.¶

B.3.5. Originator ==> Modifying Forwarder ==> Receiver

This demonstrates a spammy message where the forwarder modifies the message content, representing for example a mailing list adding a footer.¶

ARC-Seal: i=3; d=receiver.example.com
ARC-Authentication-Results: i=3; dara=pass; chain=neutral
ARC-Seal: i=2; d=intermediary.example.com;
    dara=destination.example.com
ARC-Authentication-Results: i=2; chain=pass
ARC-Seal: i=1; d=originator.example.com;
    dara=intermediary.example.com
ARC-Authentication-Results: i=1
To: user@receiver.example.com

While the global Chain verification result is pass and the message is considered DARA authenticated, the modified message body change is visible via the modified body algorithm. The constructed path is [originator.example.com, modified-message-body, intermediary.example.com, receiver.example.com] where we embellish the path with the modification result. The set of contributing domains associated with the spammy message is {originator.example.com, intermediary.example.com}.¶

A different message may travel along the same forwarding path but is not modified by the forwarder. That non-modifying forwarder constructed path is: [originator.example.com, intermediary.example.com, destination.example.com], and is distinct from above. The set of contributing domains associated with the message content is now {originator.example.com}.¶