Re: [dmarc-ietf] p=quarantine

[Todd Herr <[e-mail]>]

On Fri, Dec 18, 2020 at 4:55 PM Michael Thomas <[e-mail]> wrote:

>
> On 12/15/20 8:01 AM, Todd Herr wrote:
>
>
> I'm not sure there's anything actionable about DMARC's policy values.
>
> you mean p=quarantine, or p=* in general?
>

Depending on the level of sophistication of a receiving email system, a
given email message can have dozens of signals (or data points) associated
with it, of which the relevant DMARC policy record, if it exists, is one.
Those signals can all be actionable, individually or collectively, or
ignored entirely, in that receiving system's decision to accept or reject
the message, and if it accepts it, the decision of where to place that
message.

If an applicable DMARC policy record exists for the RFC5322.From domain in
a message, the receiver can:

   - Perform the necessary authentication checks for DMARC validation, and
   use those validation results and the p= value as the sole or primary
   determining factor in how to handle the message, strictly applying the p=
   value in cases where it's not 'none' and validation checks fail
   - Perform the necessary authentication checks for DMARC validation, and
   use those validation results and the p= value as the sole or primary
   determining factor in how to handle the message, loosely applying the p=
   value in cases where it's not 'none' and validation checks fail (e.g.,
   placing the message in the spam folder even if p=reject is specified in the
   policy record)
   - Perform the necessary authentication checks for DMARC validation, and
   use those validation results and the p= value as one data point in a larger
   data set in how to handle the message
   - Ignore the DMARC policy record entirely



> 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.
>
> We've always been able to check the reputation of lists that resign the
> message. The reputation is the previously (un)solved problem.
>
>
> Lists are a specific instance of the more general case of indirect mail
flows.

Any intermediate host can ARC seal and ARC-sign (a term I use as distinct
from re-sign) a message, an act that is meant to capture the results of
authentication checks done when it reached the intermediary. Whether or not
the receiver trusts those results (especially those results that claim that
authentication checks passed at the intermediary) when the message reaches
the receiver depends on the intermediary's reputation for being a truthful
sealer and signer, meaning whether or not it has established a history of
capturing authentication results that are true and accurate.

Since the receiver typically can't perform the same checks under the same
conditions that existed when the intermediary performed them (if it could,
we wouldn't need something like ARC) then the receiver has to decide if the
message is consistent with messages it's previously seen through direct
mail flows using that same authenticated identity that was captured by the
intermediary in the ARC header set.

If the indirect mail flow looks like the direct mail flow, then the sealer
is showing evidence that it can be trusted, and so the indirect mail flow
can receive the same treatment by the receiver that it would give to the
direct mail flow associated with the authenticated identity.

If the indirect mail flow looks different than the direct mail flow, then
the receiver can either decide to not trust the sealer and so treat the
indirect mail flow as unauthenticated, or perhaps it can dig into matters
further to see why the difference exists. A mailing list, for example, that
has subscribers whose domain is a consumer mailbox provider might just show
an indirect mail flow for that domain to the receiver that has a
substantially better overall reputation than the direct mail flow for that
domain to the receiver; rather than letting this difference impact the
level of trust in its sealing reputation that a receiver would assign to
the list, it may very well have to put in an override to its system for
tracking sealer trust.

-- 

*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.