Re: [Bimi] MUA Evaluation of BIMI

[Trent Adams <[e-mail]>]

It sounds like there's rough consensus around the idea that for an MUA to have any chance at evaluating BIMI, we first need to ensure the MUA can reliably identify the relevant authentication results.  If not, then the MUA can't evaluate BIMI.  And even if the AuthN-Results can be identified, there's the question about whether or not the MUA can rely upon the information.  I suggest we set aside the veracity of the information until after we more fully explore whether we can reliably identify the AuthN-Results first.

Fortunately, there are a couple existing methods for MTAs to convey authentication results to an MUA:


  *   An AuthN-Results header inserted by the mailbox provider (which may include the BIMI-Results).
  *   A signed ARC signature block, which includes the AuthN-Results.

If we first look at the AuthN-Results header, the question is how the MUA can identify the relevant header.  There's no guarantee that there is only one AuthN-Results header in a given email and, if there's more than one, it's not clear which one's applicable (especially as we can't rely on order).  Fortunately, RFC8601 defines a services identifier that might be used.  Unfortunately, the "authserv-id" field is optional (and can be any arbitrary string).  That makes it sub-optimal for an MUA to rely upon it.

Then, if we consider the ARC signature block, it'll include the AuthN-Results, with the added benefit that it requires that the evaluator be identified by a domain (in the "d=" value of the ARC-Seal block).  Unfortunately, the ARC Signing Domain Identifier (SDID) may be difficult for the MUA to match to the mailbox provider and message.

It's also worth noting that even if the evaluator (whether identified via the AuthN-Results header or the ARC signature block) is identified by a domain, there's no guarantee that the domain will match the domain of the recipient… so the MUA may have a hard time matching them up.  For example, when sending to a "@gmail.com" address, the AuthN-Results authserv-id and the associated ARC results SDID are "google.com".  So, absent prior knowledge baked into the MUA to link the two… there's currently no way for the MUA to figure that out.

Even with the limitations… I think we may be able to specify a cascading set of options the MUA can use to identify relevant AuthN-Results from the mailbox provider (along with the associated caveats).  If, after going through the full if-then-else set of options, and the MUA can't reliably identify relevant AuthN-Results… then it can't evaluate BIMI.

The question I'm wondering about now… is what percentage of relevant AuthN-Results can be identified using this process?   Because if the number is vanishingly small (and unlikely to increase), should we stop chasing the solution for MUAs?  If so, then perhaps we fall back to a section that just describes the issues along with a "user beware" message rather than specifying all the different options.

Anyway, before we start talking about the veracity of the AuthN-Results… is there anything I'm missing, or I've misstated?

Progress(?),
Trent


From: bimi <[e-mail]> on behalf of Jakub Olexa <jakub=[e-mail]>
Organization: Mailkit
Date: Friday, March 18, 2022 at 2:43 AM
To: "[e-mail]" <[e-mail]>
Subject: Re: [Bimi] MUA Evaluation of BIMI

I'd say the only thing that would be worth checking is the source of the A-R header and host MAY match the server host (which may often not be possible) or fallback to the topmost A-R header. Keep in mind that BIMI is not a trust indicator


I'd say the only thing that would be worth checking is the source of the A-R header and host MAY match the server host (which may often not be possible) or fallback to the topmost A-R header.

Keep in mind that BIMI is not a trust indicator but just a logo - marketing feature rather than security feature. Custom MUA of a hosting company may rely on the A-R headers in a different way as it would get those from the MTA they have control over then a public MUA that simply has to trust that the user chose an imap server for a reason. What's the point of questioning the headers authenticity? I do get that it would prevent a malicious actor from having a "fake" logo displayed but the impact would be very limited.

maybe we could require MUAs to rely on the BIMI-Indicator header added by MUA.

Jakub Olexa
Founder & CEO
E-mail: [e-mail]<mailto:[e-mail]>
Tel: [phone]<tel:[phone]>

Mailkit - Closing the circle between Deliverability and Engagement<https://urldefense.com/v3/__https:/www.mailkit.com__;!!ORgEfCBsr282Fw!vffTF121WWRZp3c6MeAaSmZYDkpQYWTA2tLEoWsZ49u2F-7fHnr2CSIcf06VWlRahB7B9jGfL5wEhxp-41Dzl5gIBCszefZs$>
On 17.03.2022 20:35, Dave Crocker wrote:


You can tie yourself in knots here but I really doubt you're going to end up with anything better than believe your MTA's A-R or you don't.


This seems to be trust without verification and without any meaningful basis for the trust, other than having logged into an IMAP session with a mailbox provider.

Since 'users' certainly won't be doing a meaningful assessment, this reduces to:  Random MUAs with support for displaying Bimi images must use any A-R header field that shows up.

Note that the trust includes having no basis for knowing whether the connected servers knows about, or cares about, A-R fields.

d/