Re: [dmarc-ietf] p=quarantine

[Todd Herr <[e-mail]>]

On Mon, Dec 14, 2020 at 10:36 PM Michael Thomas <[e-mail]> wrote:

>
> On 12/14/20 7:26 PM, Douglas Foster wrote:
> >
> > But what I am trying to figure out is under what circumstances a DMARC
> > policy can be considered actionable.  Do I conclude that
> > "p=quarantine" means "domain is still collecting data, so results are
> > unpredictable"?   Or do I conclude that it means "Domain is fully
> > deployed and failure to validate is a highly suspicious event?"
>
>
> Yeah, that's why I question whether there is something actionable and
> whether this is so much wishful thinking. Somebody did say that they
> took action on it (gmail?), but i'm not sure whether that is a good
> thing or a bad thing. For mailing lists, that would seemingly be a bad
> thing, but if you're of the mind that mailing lists are a security bug
> and not a feature that might be contradictory.
>
>
I'm not sure there's anything actionable about DMARC's policy values.

For receivers, attempts at manually tracking which RFC5322.From domains
appear in mail that's authenticated or not with SPF and/or DKIM are ones
that are bound to fail due to scaling issues. DMARC provides a solution to
this problem, in that if a domain owner publishes a DMARC policy, the
receiver now has some information that the owner of the RFC5322.From domain
may have an expectation that mail with that domain in the RFC5322.From
domain might be authenticated in some fashion, using SPF and/or DKIM.
The receiver can use that data point, and the data points collected from
DMARC validation checks for that message, as part of the sum total of data
it uses to decide its handling of that message. If there is a published
DMARC policy for the RFC5322.From domain, and the receiver so chooses, the
receiver can also use the p= value in that policy as another data point
contributing to the message handling decision, but the receiver is not
compelled or required to do so (nor is the receiver compelled or required
to even perform DMARC validation checks, or send aggregate and/or failure
reports, or even check for the existence of a DMARC policy record for the
RFC5322.From domain).

For domain owners that publish DMARC policies, the best case is that the
owner is announcing to the internet at large that

   - It is on a journey to ensure that if it's domain (or a sub-domain
   thereof) is the RFC5322.From domain in a message, then such a message will
   pass SPF and/or DKIM authentication checks, and
   - It is interested in seeing data from receivers about what kind of
   traffic the receivers are seeing where the domain is used in the
   RFC5322.From address, perhaps as a way of increasing the rate at which
   those authentication checks are passing, and
   - It is providing to DMARC validators some information, in the form of
   the p= value, that expresses its own level of confidence in how
   well-implemented its email authentication practices are, with such
   confidence levels probably roughly approximating:
      - none - Not at all confident, just starting the process, we know or
      at least think that some of our mail streams aren't authenticating
      - quarantine - We think we've got it all locked down, but even a very
      small risk of bouncing a big campaign is very scary to us,
and/or we don't
      fully trust SPF and DKIM to pass validation checks 100% of the time when
      they should, and it's better for us and our customer service staff if the
      mail we originate at least gets delivered to the recipients'
spam folders,
      regardless of the risk of our domain being spoofed.
      - reject - We've got everything locked down, we're confident in our
      choices, and if you, Mr. Receiver, accept messages that fail DMARC
      validation checks and your mailbox holders fall victim to a scam
because of
      it, it's your fault, not ours. Alternatively, 'reject' could also mean
      'this domain should never appear as the domain in the
RFC5322.From header',
      but with the same messaging about whose fault it is if messages are
      accepted and lead to a bad outcome.

In the worst case, the domain owner is just checking a box because they
think that "publishing a DMARC policy" means "my mail will make it to the
inbox".

Obviously indirect mail flows, such as mailing lists and forwarding,
complicate matters greatly here, as the handling by the intermediary
host(s) can and will lead to a higher percentage of authentication
failures. The community has attempted to mitigate this problem;
RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS),
and ARC are among the attempts put forth so far, but none have been deemed
The Solution(tm) yet. In my opinion, ARC has promise, because if a message
reaches me as a receiver or even intermediary and fails the authentication
checks I perform, ARC header sets in the message can tell me whether or not
such checks passed at previous hops *if I trust the entities that inserted
those ARC header sets*. In an earlier thread, I floated an idea about ARC
sealer reputation, but it didn't draw much response, so I'll float it here
again in the hopes that it does.

The idea is, I believe, simple in concept but complex in execution, and
perhaps extraordinarily so, and it requires that a mail handler have a
system in place to track reputation, however it defines reputation. We'll
let "X" represent an authenticated identity (i.e., a domain that passes an
authentication check) and "Y" represent the ARC Sealer identity; my idea
would work something like this:

   - The receiver has in its reputation system already historical data
   about direct mail flows where X was an authenticated identity, establishing
   X's reputation with the receiver
   - ARC header sets record the identities used in authentication checks at
   a given hop, and the purported results of those checks
   - For messages arriving with ARC header sets sealed by Y, with X as an
   authenticated identity in that header set:
      - If such messages earn a reputation for X that is consistent with
      that earned by X's direct mail flow, then Y builds a reputation as a
      trustworthy sealer. It doesn't matter whether X's reputation is good or
      bad, only that mail seen through the indirect flow has a
reputation that is
      consistent with mail seen through direct flow.
      - If such messages earn a reputation for X that is inconsistent with
      that earned by X's direct mail flow, then Y might build a reputation as a
      non-trustworthy sealer.

Now, there are a number of what-ifs here with the latter scenario, chief
among them "What if X's mail has a better reputation with an indirect flow
than it does with a direct flow?" and I haven't worked those out yet.
However, the larger point for me is that if X's mail is functionally the
same, reputationally, regardless of whether it arrives by direct or
indirect mail flow, then that is evidence that the ARC sealer (Y) can be
trusted. Of course X is just one data point in Y's reputation; all
authenticated identities that Y records in ARC header sets would play into
Y's reputation over time, and yeah, it's complicated.

Anyway, I've wandered far afield from your initial query, and though I
attempted to address it, I apologize in advance for my loquaciousness.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [e-mail]
*p:* 703.220.4153


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.