I understand the need to limit scope, if DMARC limits its claims to what it covers. This complaint was triggered largely with the "MUST NOT" claim in the draft, which implied that DMARC is the all-inclusive tool for validating the RFC5322.From address using SPF and DKIM. If it is all inclusive, it needs to be comprehensive. If not, it should be clear that other options are possible. I would be satisfied with changing the "MUST NOT" into a reference to local policy, and including this language in the scope and goals section.
"The combination of SPF and DKIM provide a concept for validating the RFC5322.From address. DMARCbis defines a protocol for using this concept with bi-directionaoll communication between the recipient and the domain owner, using SPF, DKIM, a DMARC policy, and a reporting framework. Validation strategies which do not use a DMARC policy, use different alignment strategies, or do not include reporting are considered out of scope." About Decisonmaking Both DMARC FAIL and NO POLICY create concern that the message might be a malicious impersonation. FAIL probably adds greater weight than NO POLICY, and .FAIL with "p=reject" adds even more weight. A reasonable solution is to proceed with content filtering. Messages which die in that filter provide confirmation that the message is unwanted. For messages that survive content filtering, the decision is how to disposition the message given the DMARC result. DMARC PASS means that the message is judged free of impersonation risk. This improves the probability of acceptance by any disposition system based on risk weighting which is why I asserted that a PASS may increase delivery rates for a sender.) If a particular domain is trusted and configured for whitelisting, eliminating impersonation risk becomes essential. Since any domain may be selected for whitelisting, the system administrator needs to be able to validate any trusted message source. Much of my desire to maximize DMARC PASS results is to minimize the complexity of providing validation via other strategies. Finally, PASS simplifies risk management by reducing the volume of messages that need to be evaluated for malicious impersonation risk. In sum, PASS is more useful than FAIL because the result is more certain. Tthe value of DMARC PASS seems poorly understood by the vendor community. Doug On Wed, Aug 24, 2022, 7:25 AM Alessandro Vesely <ves...@tana.it> wrote: > On Wed 24/Aug/2022 07:56:41 +0200 Murray S. Kucherawy wrote: > > I believe your "policy is useful when present but not required" remark > is a > > re-statement of your claim that DMARC should yield a "pass" for any > aligned > > identifier irrespective of the presence or absence of a published policy. > > > The theory thus far was that dmarc=fail calls for possibly make a > decision. > Does dmarc=pass bear different values depending on the policy? > > > > However, the charter, at paragraph 4, demands that any change made by > this > > working group which does not preserve compatibility with the deployed > base > > has to be justified. If suddenly the absence of a published policy can > > result in a DMARC "pass" or "fail" when this was not previously the > case, > > and this results in different handling decisions by receivers, I would > say > > compatibility has not been preserved. > > > We already made a change by allowing a default policy. DMARC records in > the installed base were illegal if they had no p= tag. So, at this time, > we are discussing of the difference between a record saying just v=DMARC1 > and no record at all. > > The striking difference is that without record we cannot determine > alignment. However, this doesn't impinge on compatibility, as the > installed base used the PSL. > > > > The working group is able to make that change, but (a) consensus must > exist > > to do so, and (b) we need to justify the resulting potential disruption > > adequately. > > > I see no disruption. > > Anyway, we should fix Authentication-Results:, because it is currently not > clear enough. For example: say the filter can be configured to enable > DMARC or not (possibly on a per-domain base). Now a message gets > dmarc=fail with p=quarantine. This has to be enacted by downstream > agents, > after the SMTP session is over. The rMDA filter must then know if > quarantining is enabled. What is the A-R? > > > Best > Ale > -- > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
