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 relationship.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc