Re: [Bimi] MUA Evaluation of BIMI

>From what I can tell, the decision of whether or not an independent MUA should display a BIMI logo reduces to: "can the MUA reliably determine what the mailbox provider states to be the AuthN results of the evaluation they performed."

I don't believe it's about whether or not the MUA trusts the AuthN evaluation performed by the mailbox provider; that ship has sailed by the time the MUA fetches the mail.  If the MUA starts second-guessing the veracity of what the mailbox provider states, all bets are off well beyond the purview of BIMI.

In case it helps get inside my head (and perhaps illuminate my insanity), here's a rough operational flow I think would work:

  1.  First, let's consider the case that would short circuit this entire flow.  If the independent MUA can verify DKIM for the message it fetched from the mailbox provider, it can evaluate DMARC and BIMI without relying on the AuthN-Results from the mailbox provider.  If so, then we can skip ahead and GOTO 8.  Otherwise, that's where the following process kicks in…
  2.  The following assumes that the MUA trusts mail it fetches from the mailbox provider (otherwise… why're they fetching it?).  If the MUA trusts that the mailbox provider is performing the necessary validation/verification/filtering, etc… then the MUA should be able to trust headers inserted by that specific MTA (as long as they can reliably identify them).
  3.  That's not to say that the MUA should trust all the headers… just the ones that can be confirmed as having been put there by the mailbox provider.  Enter ARC, not so much as a "trust the chain" mechanism, but primarily as a method to "identify AuthN-Results inserted by the mailbox provider".
  4.  If the MUA can identify and verify a signed ARC block that includes the AuthN-Results inserted by mailbox provider, the MUA can use it to make determinations related to BIMI.  Presumably, this includes enough information for the MUA to perform the same BIMI evaluation as the MTA would have.
  5.  Regardless of any other AuthN-Results hanging out in the headers (perhaps ones that the mailbox provider neglected to strip out), at least the MUA knows that the AuthN-Results in the signature block inserted by the mailbox provider indicates what their inbound MTA evaluated.
  6.  And sure, there may be other entries in the ARC chain before what the mailbox provider inserted… and perhaps the MUA will only trust valid AuthN-Results within the block inserted by that mailbox provider (i.e. not a full chain).  But the point of this is that the ARC signature block is currently the only way for the MUA to clearly identify the specific AuthN-Results header inserted by the mailbox provider.
  7.  Optionally… if there's no ARC header inserted by the mailbox provider, perhaps there's a special DKIM-like signed AuthN-Reults header (akin to what Alex suggested)… in that case, the MUA finds it, verifies the signature, and then uses it to move forward.
  8.  Whether the AuthN-Results come from directly validating DKIM, the ARC signature block, or a new DKIM-like signed header…  With this information, the MUA can now decide what to do about BIMI… knowing that they're only trusting the mailbox provider from which they fetched the email.

I get that this is all very hand-wavy at the moment… but I hope that by breaking up the process into discreet steps we can identify where the proposal goes off the rails.  Perhaps then we can focus in and address those specific points and run through it again (hopefully getting further down the track with the next iteration).

Once we see a full path… then we can figure out how to update the specification to more effectively clarify the functionality.

Thoughts?

- Trent

From: bimi <bimi-bounces@ietf.org> on behalf of John Levine <johnl@taugh.com>
Organization: Taughannock Networks
Date: Wednesday, March 16, 2022 at 12:30 PM
To: "bimi@ietf.org" <bimi@ietf.org>
Cc: "Alex_Brotman@comcast.com" <Alex_Brotman@comcast.com>
Subject: Re: [Bimi] MUA Evaluation of BIMI

It appears that Brotman, Alex <Alex_Brotman@comcast.com> said: >So it seems clear we need some way to validate the results of the MTA authentication evaluation, presuming they >divulge those results into the headers of the message.

It appears that Brotman, Alex <Alex_Brotman@comcast.com> said:

>So it seems clear we need some way to validate the results of the MTA authentication evaluation, presuming they

>divulge those results into the headers of the message.  Trent suggested ARC, and while that should do that, it

>may not be ideal given adoption, and perhaps creating an additional barrier.

I don't get it.  I can see situations where you believe the topmost A-R in the message and where you don't,

but I don't see how signing it would help, since I can sign my A-R even if I am lying so you have the

exact same situation deciding whether to believe the signer.

This would be a situation where an IMAP server mangles or forges A-R headers but is otherwise

trustworthy.  That seems kind of implausible.

R's,

John

--

bimi mailing list

bimi@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bimi__;!!ORgEfCBsr282Fw!sF7Rls7k9AVY7scazu54DZLRLoHEGm8BSBYOgPj2scNTvzzn_7vmp6Iq-D9sEJLg13wBiGGx9fO6pg$