> On 23 Aug 2022, at 12:51, Douglas Foster > <dougfoster.emailstanda...@gmail.com> wrote: > > As best I understand the chair position, DMARC supports domain owners: > - via PASS, which might improve delivery rates, and more importantly
This is an incorrect interpretation of what DMARC does. DMARC allows evaluators to reliably determine if the domain in the 5322.from is being sent through channels that are identified by the domain owners as under their control. This allows the evaluators to apply a reputation to the domain in the 5322.from. A DMARC pass does not and should not mean that a mail should be delivered. As evidence by the PayPal phishing that is DMARC authenticated as PayPal and the chinese language spam that is DMARC authenticated as coming from careers.microsoft.com <http://careers.microsoft.com/>. Neither of these messages should be delivered to the inbox despite passing DMARC. > - 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. This is not what I said. Please do not misrepresent my statements in order to defend your point of view. > 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 <toddmh...@gmail.com > <mailto:toddmh...@gmail.com>> wrote: > On Mon, Aug 22, 2022 at 9:14 PM Douglas Foster > <dougfoster.emailstanda...@gmail.com > <mailto:dougfoster.emailstanda...@gmail.com>> 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
