On Tue, Aug 23, 2022 at 7:52 AM Douglas Foster <
[email protected]> wrote:
> 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.
>
>
I don't think I used the word "charter" in my message, which was in reply
to your assertion about the meaning of spf=pass in ARC header sets.
> 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.
>
>
Sure, but in the absence of a published DMARC policy, you're assuming facts
not in evidence. If a domain owner publishes a DMARC policy, they're
theoretically saying that they're trying to make sure they're properly
authenticating all their mail (if p=none) or that they're pretty sure
(p=quarantine) or very sure (p=reject) that they're properly authenticating
their mail. You are free to do whatever you wish with any inbound message,
even flat out reject if there's no DMARC policy; I just don't see the point
in trying to do any extra work to perform DMARC validation if no policy can
be found.
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.
>
>
I think reporting goes beyond "charity work". I don't think you'll find a
mailbox provider that prefers unauthenticated mail to authenticated mail,
and so to me, reporting is essential to driving increased authentication,
because it allows the domain owner to identify any shortcomings in their
authentication practices before leveling up to p=quarantine or p=reject.
> The market has already rejected the narrow definition of DMARC.
>
Please cite your sources for this claim.
> 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.
>
I don't overestimate their value; I don't even consider them to be
instructions. They're requests for handling, which are free to be honored
or ignored as the validator chooses.
>
> 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.
>
>
> 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
>
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email protected]
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
