Re: [dmarc-ietf] Evaluator reference model

[Douglas Foster <[e-mail]>]

I have been trying to understand why such a big disconnect is possible
between my usage of DMARC data and the standard one.   I have concluded
that it occurs because we are dealing with two protocols, not one, and the
standard view conflates them unnecessarily.   The first protocol is the
algorithm for detecting DMARC PASS, and the second protocol is the
algorithm for handling DMARC FAIL.

DMARC PASS is trusted to indicate that the message is from the domain owner
because of the nature of DNS record ownership – the message is reliably
tied to a DNS record, and the DNS record is reliably tied to the domain
owner.   There is no secondary authentication which is required to make
DKIM PASS  or SPF PASS authenticate the domain’s messages; the
authentication is inherently triggered by publishing SPF or DKIM
information.    Therefore the DMARC PASS protocol is a datagram service,
like SPF and ARC.   All three use a one-way flow of information from the
domain owner to the evaluator via DNS.

The DMARC FAIL protocol is different.   Once a message is determined to not
pass the DMARC PASS protocol, the domain owner is queried to answer the
question, “What is the probability your messages are always authenticated,
and therefore that this FAIL represents an impersonation?”   The possible
responses are:  No protocol, None, Test Quarantine, Test Reject,
Quarantine, and Reject.   As we move from No policy to Reject, we have an
increase in the probability that all domain messages  can be authenticated
and therefore that all FAIL messages are impersonations.    (Of course,
even when impersonation is confirmed, the evaluator has to determine
whether it is an acceptable impersonation.  This is sufficiently common
that it needs to be mentioned, but is outside the scope of our protocols.)

The two protocols are largely independent.  A domain owner could publish
nothing for SPF and DKIM, then publish a P=REJECT policy, to indicate that
it never sends mail from a particular subdomain name.   It could also
publish SPF and DKIM information to allow some messages to be
authenticated, yet publish no DMARC policy to guide failure handling.

Doug

On Tue, Jan 18, 2022 at 5:33 PM Barry Leiba <[e-mail]> wrote:

> First: I note that you did not answer my direct questions.  Please
> consider that when you see that people aren't understanding you.
>
> > I test every message for SPF, aligned SPF, and aligned verified DKIM.
>  With one exception mentioned below,
> > I don't block on FAIL, but I do collect data.
> ...
> > I cannot imagine why I would give this up to only evaluate the domains
> that have given me permission via a
> > DMARC policy.
>
> And here's where we have the disconnect:
> No one is suggesting that you should not do anything you find useful
> with the data you collect: no one wants you to give anything up.  All
> we are saying is that when a domain owner does not publish a DMARC
> policy, anything you choose to do is outside of the DMARC spec,
> because DMARC is about the policies that domain owners publish.
>
> > I think documenting this approach would help a lot of other evaluators
> and software developers.
>
> An informational document that suggests collecting data they way
> you're doing it, and documents things you can do with that data...
> would be a fine thing to write.  You may, of course, do so, publish it
> as an Internet draft, and see if there's agreement to publish it
> through the IETF.  Lacking that, you might get it published through
> the Independent stream.
>
> In any case, I don't see that it has anything to do with the DMARC
> protocol spec that we're working on now.
>
> Barry
>