Subject: Re: [arc] Simplifying the Decision to Trust an ARC Header Set

From: Alessandro Vesely <[email-masked]>
Date: Fri, 1 Oct 2021 10:10:20 +0200

On Thu 30/Sep/2021 19:40:54 +0200 Todd Herr via Arc wrote:
> On Thu, Sep 30, 2021 at 1:31 PM Alessandro Vesely via Arc <[email-masked]> wrote:
>> On Thu 30/Sep/2021 14:55:10 +0200 Todd Herr via Arc wrote:
>>>
>>> The decision by a server to accept a message from a client is made based on
>>> whatever criteria the operators of that server establish. My proposal is
>>> simply:
>>>
>>>     - IF you accept a message from a client, AND
>>>     - IF that client has inserted an ARC header set that passes validation
>>>       checks (RFC 8617 Section 5.2), THEN
>>>     - The information in that header set (and any previously-inserted
>>>       header sets that pass validation checks) must be accepted by you to
>>>       be true and correct
>>
>> Where would you insert John's objection about sender reputation?  I'd 
>> propose after accept, because servers who don't have a reliable
>> reputation database need to accept messages from unknown senders.  For
>> example, like so: >
> I have reviewed the thread, and for the life of me I can't find something I
> would call "John's objection about sender reputation". Can you point it out
> to me, please?

He expressed it as "if they do that, they are likely doing other bad stuff and 
the sender will have a bad reputation."  That's the first time the term 
"reputation" appears in the thread.

>>     - IF you accept a message from a client, AND
>>     - IF you can swear the client is not malicious, AND
>>     - IF that client has inserted an ARC header set that passes validation
>>       checks (RFC 8617 Section 5.2), THEN
>>     - The information in that header set (and any previously-inserted
>>       header sets that pass validation checks) must be accepted by you to
>>       be true and correct
>>
>> Swearing about the client is not quite practicable, but I don't know how 
>> to express assessment so as to include 0-day exploits, such as a trusted 
>> server having just been compromised. >
> The locally-known reputation of the client is factored into the decision to
> accept the message, and has nothing itself to do with ARC, in my opinion.

I can accept a message with uncertain reputation, but wouldn't deliver a 
message with dmarc=fail from a domain whose locally-accepted policy is reject. 
  (I say locally-accepted in the sense that the local filter is configured to 
honor DMARC requests, at least for that domain.)

> I would expect senders without a locally-known reputation to be judged
> differently from those with a locally-known good reputation and from those
> with a locally-known bad reputation, in that unknown senders should be
> treated as suspicious until proven otherwise by your users (e.g., route all
> mail to spam until your users tell you it's not spam, perhaps).

So /accept with suspicion/ is not accept, in the same sense as
https://en.wikipedia.org/wiki/When_a_white_horse_is_not_a_horse

> That suspicion may, and probably should, carry over to your trust in any
> ARC header sets inserted by the previously unknown sender.

That strategy leads to overloading the spam folder, and is unbearable for a 
small server.  When fine grained --requiring the same local part-- it is 
unsatisfactory even for large providers like Microsoft.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Fri, 1 Oct 2021 08:03:20 -0400

> unsatisfactory even for large providers like Microsoft.
It seems pretty clear to me that you stand in opposition to the idea that
"message accepted means validated ARC header sets are trusted to be true".
That's fine; this thread was intended to get people's opinions on the topic.

Please propose an alternative method for deciding when to trust ARC header
sets, because unless and until there is something resembling consensus in
the community about when to trust ARC header sets, ARC doesn't really stand
a chance to be adopted as an actual standard.
-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 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.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 2 Oct 2021 10:37:11 +0200

On Fri 01/Oct/2021 14:03:20 +0200 Todd Herr via Arc wrote:
> On Fri, Oct 1, 2021 at 4:10 AM Alessandro Vesely via Arc wrote:
> 
>> That strategy leads to overloading the spam folder, and is unbearable for 
>> a small server.  When fine grained --requiring the same local part-- it
>> is unsatisfactory even for large providers like Microsoft. >

The point is /how much/ trust do you put in validated ARC header sets.  ARC can 
be used to differentiate responsibility of forwarders from that of originators. 
  Email address portability implies lots of forwarding and I saw descriptions 
of large providers being happy to use ARC to put order in that, even on mail 
flows where original DKIM signatures don't break.  In such situations, your 
rule of trust is fine.

On the other hand, overriding a failed DMARC check on a message from a heavily 
abused domain requires more trust than that.  Of course, your own mail server 
could be compromised and a hacker could then deliver a phish with your site's 
authenticity imprimatur.  That risk is low, and has to be accepted.  However, 
multiplying such risk by millions of loosely trusted servers out there results 
in an unacceptable value, IMHO.  A few servers can be trusted; for example, if 
you outsource some secondary MXes, you must trust their ARC.  The risk is still 
low.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 2 Oct 2021 18:27:42 -0400

It appears that Alessandro Vesely  <[email-masked]> said:
>The point is /how much/ trust do you put in validated ARC header sets. 

As Todd said, if you generally trust the source you trust the ARC sets.  If not,
you don't.

I understand that you would like to set up a much more complicated set of rules
but it should be obvious by now that even if you did, nobody would use them.

R's,
John