> On Nov 25, 2022, at 5:53 AM, Douglas Foster > <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
