Re: [dmarc-ietf] p=quarantine

[Todd Herr <[e-mail]>]

On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely <[e-mail]> wrote:

> On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote:
> >
> > Lists are a specific instance of the more general case of indirect mail
> flows.
>
>
> How many kinds of indirect mail flows do rewrite From:?
>
> Specific methods might prove more effective than general ones.
>
>
Sender Rewriting Scheme (SRS) exists for the rewriting of the RFC5321.From
address, and is sometimes used in mail that is forwarded by rule, say from @
alum.institution.edu to @consumerMailboxProvider.com

The larger point, though, is that mail that automatically passes through
one or more intermediary hosts on its way to its final destination can fail
authentication checks at the final destination due to the impact of changes
on the message, either in path, or content, or both, as it traverses that
journey. It seems to me that we can either work to find a way to ensure
that such failures don't happen, or we can work to find a reliable and
trustworthy way to record authentication results along the way so that the
failures can be mitigated and not result in failed delivery of wanted mail.


> > [...]
> >
> > 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.
>
>
> Doesn't that assume some kind of omniscience at the receiver's?
> Consistency
> with previous messages by the same source is not straightforward.  Using
> the
> same selector?  Signing more or less the same set of header fields?
> Choice of
> vocabulary?  HTML vs. plain text style (e.g. line length)?  A.I.?
>
>
Not omniscience, no, but certainly a method of tracking an authenticated
identity's reputation, and consistency of reputation is what I'm speaking
of. Allow me to try again to get across the idea that I'm so far failing to
make clear.

I'm not currently working for a mailbox provider, but I have in the past,
and so I will role play as one here.

As a mailbox provider, I have a system for authenticating the identity or
identities associated with messages that come directly to me.

These authenticated identities can include some or all of:

   - The DKIM signing domain(s)
   - The DKIM signing domain(s) and selector(s)
   - The RFC5322.From domain (authenticated using DMARC)
   - The RFC5321.From domain (SPF)
   - The IP address of the client that passed the message to me
   - The domain associated with the PTR record of that IP address
   - Others as I deem useful

For each of these authenticated identities, I can and will track how my
users/customers/mailbox holders engage with the mail they receive, thus
over time establishing in my system a reputation to associate with each
authenticated identity. If, for example, mail that is DKIM signed using
selector S and domain D is mail that my users demonstrate through their
actions (opening it, clicking on links in it, etc.) is wanted mail, then
that authenticated identity (S._domainkey.D) will be associated with a good
reputation (however I define "good") in my system. Lather, rinse, and
repeat for other authenticated identities associated with the message, and
allow that both good and bad reputations can be earned.

Now here comes a message that is DKIM-signed by D with selector S, and it
fails DKIM validation when I do my checks. However, in scanning the
message, I see that there is an ARC header set, one that was signed and
sealed by A, and in that ARC header set is an ARC-Authentication-Results
header that says that the message passed DKIM validation with signing
domain D and selector S when A did its check.

My conundrum here is "Do I trust A's claim that the message was correctly
DKIM signed by domain D with selector S?"

The answer to that question will depend on how my users treat the message
and others like it, assuming that I accept it and deliver it. If my users
treat such messages in a manner that's consistent with how they treat
direct mail flow that is DKIM-signed by D with selector S, then A's
reputation as an ARC-sealer/signer will be positive, because A will
establish with me a history of being a source of ARC-sealed/signed mail
with ARC header sets that can be believed. On the other hand, if my users
consistently treat such messages differently than they do direct mail flow
that is DKIM-signed by D with selector s, then A's reputation as an
ARC-sealer/signer will be negatively impacted with me, because I will not
have evidence in hand that this is a path for mail with an authenticated
identity of S._domainkey.D to take.

The point here is that ARC (or any system designed to capture intermediate
authentication results) can only succeed if the downstream recipients of
the message trust the information that the intermediary host(s) record in
the message. What I'm describing above is one way to determine if that
information can be trusted, one that I'm trying to design to scale beyond
"Let me just whitelist these X hosts as reliable ARC sealer/signers."

-- 

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