Sorry to be obscure. For the moment, I am trying to add the quoted sentence at the beginning of my treatise, which Murray thinks can be accommodated.
For the longer haul, I am trying to lay a conceptual foundation for exception management,to frame later discussion. If I had my way, exception management would be part of the main document. It is risky to implement any new filtering method without a plan to detect and resolve false positives. But my best hope is that a follow-on BCP document will be created and that it will address exception management. Doug On Fri, Nov 25, 2022, 3:46 PM Neil Anuskiewicz <n...@marmot-tech.com> wrote: > > > > On Nov 25, 2022, at 5:53 AM, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > > > > > DMARC requires an evaluator to trust the design, but we lack a cogent > statement of the theoretical basis for doing so. Here is my proposed > language: > > > > "The RFC5322.From address is not directly verifiable. DMARC addresses > this problem using proxy verification: The From address is considered > verified using the combination of a verified identifier and a meaningful > relationship between the verified identifier domain and the RFC5322.From > domain." > > > > Discussion > > This language identifies the two axioms on which DMARC is built: > > - a verified identifier, one of: > > RFC5321.MailFrom verified by SPF PASS or > > RFC6376 DKIM "d=" domain, verified by DKIM PASS > > - a meaningful relationship > > Same Organization > > Which includes the subtypes of: > > same domain > > parent authenticates child > > child authenticates parent > > sibling authenticates sibling > > These are chosen because they have broad applicability, such that > reputation knowledge about the identifier is not required to produce a > meaningful result. > > > > Like any heuristic, DMARC will sometime produces results which encourage > a disposition different than what the evaluator wants, typically suggesting > distrust when trust is intended. This requires alternate verification > strategies, but our core documents have not explained how exceptions should > be handled, and a best practices document is not yet started. Therefore, > it is worth examining how alternate authentication can be achieved by > altering the axioms: > > > > Alternate identifiers could include: > > ARC Set "d=" domain validated an intact ARC set > > Server host name validated by forward-confirmed DNS > > Sender header domain validated by DKIM signature > > > > Alternate relationships include: > > "Vendor to Client" -- the From domain is trusted to have a client > relationship with the validated domain > > "Delegated authenticator" -- The From domain is trusted to have been > successfully validated by a previous server > > "Trusted impersonator" -- The validated domain is trusted for > impersonation because it only impersonates for beneficial purposes on > behalf on an individual domain account. > > "Trusted infrastructure" -- The validated domain is trusted to not > impersonate > > > > There may be other identifiers and relationships that could be > imagined. None of these alternatives can produce general solutions, > because they require knowledge which is external to both the message and > the DNS. However, these methods do provide the basis for local policy to > address situations where authentication is needed but DMARC cannot produce > PASS. > > > > ARC provides proxy validation using the combination of the ARC Set's > "d=" domain identifier, the ARC Sets authentication results, and "Delegated > Authenticator" as the meaningful relationship > > > > A website or organization which is known to impersonate, but only for > beneficial purposes, can be validated using the server host name, verified > by fcDNS, and "Trusted Impersonator" as the meaningful relationship. > > > > Proposals to use Sender as the alternate identifier have failed for two > reasons: (1) by trying to create a general solution rather than a > local-policy solution, and (2) failing to provide an alternative to "same > organization" as the meaningful > > Sir, your knowledge of this domain is clearly deeper than I could ever > achieve so it’s with deep respect that I acknowledge that I don’t grok what > your highest priority is in terms of the standard. That is, what’s the > highest priority problem and solution with solution defined as wording to > be added to or changed in the document addressing the problem? > > Neil
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
