As best I understand the chair position, DMARC supports domain owners:
- via PASS, which might improve delivery rates, and more importantly
- via FAIL, by providing a way to deflect blame and liability when others
are harmed by messages impersonating the domain's identity.
This requires a DMARC policy, because the DMARC policy for deflecting blame.
My definition of DMARC supports evaluators
- via PASS, by helping ensure that they accept all messages from wanted
senders,
- via FAIL, by obstructing attempts to avoid harm to themselves from
messages impersonating a trusted domain's identity.
The DMARC policy is useful when present but not required.
I don't think you can use the charter to reject my definition.
On your other points:
The reason an evaluator expends compute cycles on validation is to meet
their own needs, which are to accept messages that they want and block
messages that they do not want. Source filtering is the most important
part of that process.
Of course DMARC is useful without an RUA address. I am confident that
many organizations use DMARC results without sending reports. Reporting
is charity work and not everyone has the resources and the altruism to do
so. RFC7489 and our current draft allow an organization to publish a DMARC
policy without an rua address. It is probably rare, but it is allowed.
So reporting is useful, but it is not essential to the definition of DMARC.
The market has already rejected the narrow definition of DMARC. Laura
reported knowledge of ISPs that, like me, apply a DMARC test to every
message. A trivially-customized version of DMARC is the way that mailing
lists can validate posted messages, which was indeed the point of my post.
What John reports about how ARC is being used is insignificantly different
from DMARC when used elsewhere without rua reporting.
Finally, you seem to overestimate the value of the
sender's disposition instructions. Based on data that others have reported
to the group, the vast majority of published dispositions are currently
NONE, so they add no value. On the other hand, anyone who has tried to
enforce sender authentication also learns that there are a variety of
situations that require exceptions because the FAILed message is still an
acceptable one. So p=reject does not carry much weight with me either.
In short, some messages can be verified as PASS based on exact match,
without a policy. Other messages can be verified as FAIL, without a
policy, because they don't align at all. ("Sendgrid.net" does not align
with "Example.com".) The policy adds value when it is present, but it is
not required. Expecting evaluators to ignore this information is
unreasonable. Using this document in an effort to prevent them from
knowing that they should do so is unacceptable.
Doug
On Tue, Aug 23, 2022 at 7:24 AM Todd Herr <[email protected]> wrote:
> 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
