#95 closed defect (out-of-scope)

Need to allow multiple ARC Sets per domain

Reported by: dougfoster.emailstandards@… Owned by:
Priority: major Milestone: Deliverable #2 (DMARC improvements to better support indirect email flows)
Component: dmarc-bis Version:
Severity: - Keywords:


While assessing the impact of my request (ticket 90) to include identifiers in ARC sets, I realized another problem.

ARC necessarily requires the last ARC Set in the chain to have a verifiable ARC-Message-Signature. Since the intent is to survive intra-domain message modifications, this final set needs to be applied at (or near) the outbound gateway. However, the desired information within the ARC set is the state of the message when it was received at the inbound gateway. This is information which an outbound gateway cannot independently determine. The best that it can do is to report what it thinks happened, based on A-R headers which it believes originated within its domain. A-R data is not well secured, and the end result seems little better than notarized hearsay.

The solution to this is fairly straightforward. To ensure accurate data, ARC Sets with evaluation results must be created by whichever MTA performs the evaluation. If authentication is assessed across multiple servers, then each participating server should create an ARC set for the tests that it performed. Because the outbound gateway performs no inbound authentication tests, it creates an ARC set with only identifiers but no test results. Collectively, this provides better security and vastly better definition of any identity changes which occurred in transit through the domain.

This conflicts with the current specification, which states that only one ARC Set is allowed per domain. I see no reason why that constraint is necessary or helpful. I also note the GMail implementation already violates this part of the specifciation. It applies an ARC set to every incoming message.

These are the sections which assume that the ARC Set is only created by an outbound gateway, which I believe should be changed.

4.1.1. ARC-Authentication-Results (AAR)

Because there is only one AAR allowed per ARC Set, the AAR MUST
contain the combined authres-payload with all of the authentication
results from within the participating ADMD, regardless of how many
Authentication-Results header fields are attached to the message.

4.1.2. ARC-Message-Signature (AMS)

To reduce the chances of accidental invalidation of AMS signatures:

o AMS header fields are added by ARC-participating ADMDs as messages

exit the ADMD. AMS header fields SHOULD be attached so that any
modifications made by the ADMD are included in the signature of
the AMS header field.

5.1. Sealer Actions

  1. All message modifications (including adding a DKIM-Signature

header field(s)) MUST be performed before sealing.

Change History (1)

comment:1 Changed 14 months ago by johnl@…

  • Resolution set to out-of-scope
  • Status changed from new to closed

ARC is out of scope

Note: See TracTickets for help on using tickets.