[dmarc-ietf] ARC for internal use

[Alessandro Vesely <[e-mail]>]

Hi all,

On Mon 20/Jul/2026 14:24:20 +0200 Brotman, Alex wrote:
> [...] points that the proposed document mentions in 3.1.
> Should we examine each of those bullets for accuracy?  Have we sufficiently addressed that section?


The first bullet in Section 3.1 says:

    *  Data-center and intra-domain utility: Early effective use of ARC
       occurred inside single administrative domains or tightly
       controlled data centers, where messages traversed multiple
       internal hops.  Operators applied ARC to ensure messages were not
       modified unexpectedly between their own servers.  In these cases,
       operators already had implicit trust and operational control.

This concept already appears in RFC 8617:

  7.1.2.  Multi-tier MTA Processing

     A large message-processing infrastructure is often divided into
     several processing tiers that can break authentication information
     between tiers.  For example, a large site may maintain a cluster of
     MTAs dedicated to connection handling and enforcement of IP-based
     reputation filtering.  A secondary cluster of MTAs may be dedicated
     and optimized for content-based processing of messages.

     Authenticated Received Chains can be used to communicate
     authentication assessment between processing tiers.

I have difficulty understanding this use case, and I'd ask three questions:

1)  Why does a large infrastructure need to authenticate its 
Authentication-Results?  Cryptographic signatures are normally used to protect 
against malicious tampering.  However, in many cases where the same ADMD adds 
multiple ARC sets, they are all signed with the same key.  Sharing that key 
allows any operator to alter data at will.  What threat are the signatures 
intended to address?

2)  If the participating MTAs belong to the same ADMD, what benefit is expected 
from having intermediate MTAs emit their own ARC sets?  Since, as I understand 
it, only the last valid ARC set can be relied upon, wouldn't it be preferable 
for the final MTA to emit a single ARC set containing the ADMD's complete 
authentication assessment?

3)  According to Section 4.1.1. of RFC 8617, the AAR MUST contain the combined 
authres-payload with all of the authentication results from within the 
participating ADMD.  In some cases of multiple ARC sets, all AARs contain the 
same data (including remote IP address).  In other cases, each MTA carries out 
and reports its own checks as if it were a different ADMD, despite using the 
same d=.  Which behavior is consistent with the specification?


Best
Ale
--