On Mon, Aug 22, 2022 at 9:14 PM Douglas Foster <
[email protected]> wrote:
> If an ARC chain with SPF PASS demonstrates that a list post is legitimate,
> it only does so because the evaluator is testing alignment (exact match)
> between the domain reported in the ARC results and the domain of the FROM
> address on the message. This is the DMARC verification algorithm, without
> the burden of a DMARC policy which is not relevant in this case.
>
An ARC header set with an SPF pass verdict is asserting that the
Return-Path or EHLO domain recorded at that step in the chain included the
source IP of the client that connected to the ARC signer in its SPF record.
The SPF pass verdict makes no assertion of anything to do with the
RFC5322.From domain.
Section 9, Security Considerations, of RFC 8617, describes the meaning of
ARC header sets:
As with other domain-based authentication technologies (such as SPF,
DKIM, and DMARC), ARC makes no claims about the semantic content of
messages. A received message with a validated ARC Chain provides
evidence (at instance N) that:
1. the sealing domain (ARC-Seal[N] d=) emitted the message with this
body,
2. the authentication assessment reported in the ARC-Authentication-
Results was determined upon receipt of the corresponding message
at the sealing domain, and
3. the preceding ARC Chain (1..N-1) (with the validation status as
reported in the cv field) existed on the message that was
received and assessed.
> We can conclude that:
> (a) lists which test SPF and create ARC results are desirous of being
> authenticated, and
>
I would say that lists which create ARC results are desirous of recording
the results of the authentication checks they performed, because that's all
ARC does. Preserving these results for posterity (i.e., the next hosts to
handle the message) might influence handling of the message at subsequent
hops, but there's no guarantee that subsequent hops are participating in
ARC.
(b) evaluators who use ARC results in this way are also desirous of
> verifying authentication, because
> (c) the sender, the list, the evaluator, and the recipient all
> benefit when trust is increased by verification.
>
> So we have a non-policy implementation in the wild, based on ARC, but this
> committee wants to shut it down because it "is not DMARC". Why?
>
> (Remember that this last draft says MUST NOT attempt validation when the
> policy is not found.)
>
Because a domain that does not publish a DMARC policy record has chosen not
to participate in DMARC. Obviously any site can perform any validation
check they prefer, and accept or reject any message for any reason or no
reason at all, and might choose to reject mail outright if there is no
DMARC policy published (a.k.a., "No auth, no entry") but it makes no sense
to do DMARC validation when there is no DMARC policy record published.
If one chooses to do validation in such circumstances, what p= value would
be applied? "none" seems to be the only one that makes sense, but there's
no DMARC policy record and so no corresponding rua tag to use for reporting
the results to the domain owner, and so what's the point of expending
computing cycles?
--
Todd Herr
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
