[dmarc-ietf] Re: I-D Action: draft-ietf-dmarc-arc-to-historic-00.txt

[Alessandro Vesely <[e-mail]>]

On 27/04/2026 15:52, Todd Herr wrote:
> On Fri, Apr 24, 2026 at 2:12 PM Alessandro Vesely <[e-mail]> wrote:
>> On 24/04/2026 03:24, Murray S. Kucherawy wrote:
>>> On Thu, Apr 23, 2026 at 8:04 AM Alessandro Vesely <[e-mail]> wrote:
>>
>>>> Section 3.2 is titled "ARC’s Core Lesson: Signatures Are Not Trust". 
>>>> However, DMARC itself relies on trusting authenticated identifiers, whether 
>>>> established via cryptographic signatures or IP-based mechanisms.  For 
>>>> direct messages, this model is generally effective. There is a qualitative 
>>>> difference, however, when identity is asserted transitively (e.g., in 
>>>> forwarding scenarios): authentication alone does not convey the same level 
>>>> of trust. Informally, when an entity proves its own identity, this can be 
>>>> seen as a kind of “fixed point” of the trust function; this property does 
>>>> not hold when identity is asserted on behalf of a third party.
>>>
>>> I'm not sure I understand the claim here.   A DMARC "pass" is not 
>>> predicated on trust (unless you only say DKIM passes for trusted entities, 
>>> for instance).  I mean, it could be, but the protocol doesn't require it 
>>> (and how could it?).
>>
>> Perhaps “trust” is not the most precise term here.  What I meant is that 
>> a DMARC “pass” typically contributes positively to a message’s 
>> evaluation (e.g., reducing its score).  While this is not a normative 
>> requirement of the protocol, it is a common operational consequence of 
>> successful authentication.
>
> The notion that a DMARC "pass" typically contributes positively to a 
> message's evaluation is not only not a normative requirement of the 
> protocol, it is in fact contrary to the text of both RFC 7489 and DMARCbis.
>
> RFC 7489 includes this text in the Abstract section:
>
>     "DMARC does not produce or encourage elevated delivery privilege of
>     authenticated email."
>
> DMARCbis, meanwhile, contains this text in the Introduction section:
>
>     "A DMARC pass for a message indicates only that the use of the Author
>     Domain has been validated for that message as authorized by the Domain
>     Owner. Such authorization does not carry an explicit or implicit value
>     assertion about that message or about the Domain Owner, and so a DMARC pass
>     by itself does not guarantee that delivery to the recipient's Inbox would
>     be safe or desirable."
>
> A DMARC pass allows one to evaluate the current message in the context of 
> the authenticated identity's previous message sending history, but it does 
> not and should not, by itself, ascribe a positive value to a message.


I agree that neither RFC 7489 nor DMARCbis assigns any intrinsic 
positive value to a DMARC “pass”, and that such a result does not by 
itself justify favorable handling.

My point was about how authentication results are used in practice as 
inputs to local evaluation, independently of any notion of domain 
reputation.

Even in the absence of historical data (e.g., on smaller sites), a 
validated, aligned author-domain signature can still serve as a 
meaningful signal: it confirms that the domain in the visible identifier 
has participated in the authentication of the message.  This is distinct 
from reputation, which may amplify or override that signal when available.

The distinction I was trying to draw is between first-party 
authentication and transitive assertions.  When a domain authenticates 
its own mail, the identifier is directly bound to the originating actor. 
  In contrast, when identity is conveyed via intermediaries (e.g., 
forwarding scenarios with third-party signatures), that direct binding 
is not present, and the same kind of signal is not available.


Best
Ale
--