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
