Re: [dmarc-ietf] p=quarantine

[Alessandro Vesely <[e-mail]>]

On Tue 22/Dec/2020 16:41:43 +0100 Todd Herr wrote:
> 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


VERP as done by MLMs is more specific (and better thought) than generic SRS.  I 
don't have numbers but off the top of my head I'd reckon MLMs cover a major 
part of RFC5321.From rewriters.  If you additionally select by RFC5322.From 
rewriting, I'd guess you're left with exactly MLMs.


> It seems to me that we can either work to find a way to ensure that
> [forwarding] 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.

Actually, people seem to be doing both.  Avoiding gratuitous autoconversions, 
anti-virus results as footers, and the like, have become a must for most modern 
MTA software.  And there are several mailing lists which operate that way as 
well.  OTOH, modifications are sometimes unavoidable and we still need to cope.


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


Except for PTR records, that's the data I collect to send out aggregate reports.


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


That's a delicate job.  For one point, 20161025._domainkey.gmail.com is not the 
kind of identifier you want to associate with users' liking, as it is shared 
among so many messages with diverging characteristics.  For another point, 
there are domains that change selector very often (taugh.com changes it on 
every message), so it can identify too narrow a message set.

Characterizing by author (a.k.a. RFC5322.From) probably works better.  An 
author authenticated by her submission server (a.k.a. author's domain) looks 
like a good identifier.  You still have to sort out authors having multiple 
email address and using them interchangeably.

However, as forwarding of modified messages settles on From: rewriting, 
recovering that identifier becomes fuzzy.  ARC does not cover that bit.  If we 
want to reliably use the author as an identifier, we need those forwarders who 
rewrite the From: header field —let's call'em MLMs— to adopt a standard way to 
convey the original value.  In my mlm-transform draft, I propose 
Original-From:.  IETF uses X-Original-From:.  Mailman uses Reply-To: or Cc:.


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


Here you're pairing a method which is fuzzy in nature with one, digital 
signatures, designed to be strictly binary.  You need a very large user base to 
achieve meaningful results.  Most medium/ small mailbox provider, think company 
servers to family MXes, will not even want to spy on users to determine their 
liking.


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


Overall, your plan confirms that ARC better suits global mailbox providers.


Best
Ale
--