Re: [Bimi] Proposal to Clarify Role of MUA in BIMI Evaluation

["Brotman, Alex" <[e-mail]>]

That's not something we should attempt to exert control over.  That's a client design decision IMO.  That could be influenced by local caching, or only loading X number of messages above/below where you are, etc.  They may decide to only do it during message view, not list view (and therefore only have to do it when you open the message itself).

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: bimi <[e-mail]> On Behalf Of Ken O'Driscoll
Sent: Monday, July 18, 2022 3:42 PM
To: Todd Herr <todd.herr=[e-mail]>
Cc: [e-mail]
Subject: Re: [Bimi] Proposal to Clarify Role of MUA in BIMI Evaluation

I don't believe that an internet standard can address individual MUA design issues.

The specification should clearly explain how MUAs can/should implement BIMI. The development considerations surely must be left up to the individual implementers.

Are there other standards that go into such application level UI/UX details?

Ken.

________________________________
From: bimi <[e-mail]<mailto:[e-mail]>> on behalf of Todd Herr <todd.herr=[e-mail]<mailto:todd.herr=[e-mail]>>
Sent: Monday, 18 July 2022, 19:08
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Bimi] Proposal to Clarify Role of MUA in BIMI Evaluation

On Mon, Jul 18, 2022 at 12:47 PM Trent Adams <[e-mail]<mailto:[e-mail]>> wrote:

Coolio... that certainly simplifies things.

My only question would be how MUAs can determine if they can rely upon the headers, if found.  I think this rolls back to how the MUA knows if the MBP from which they retrieve email is (correctly) evaluating BIMI.

For example, what if a malicious actor includes a BIMI-Location header in an email sent to an MBP that doesn't strip it out?  How can we signal to the MUA that they should only rely on headers inserted by the MBPs known to be compliant with the BIMI specification (which requires stripping of BIMI headers they didn't insert)?

What if the MBP was required to sign BIMI headers they inserted (e.g. via ARC)?


Before I forget, there's something else I'd like to add to the discussion...

If the consensus lands on "Unaffiliated MUAs should do their own BIMI validation", then I must ask if there will be any limits suggested or proscribed on how many messages that validation should be done on?

Here's a real-world scenario...

Last year, after many years of being an Android user, I switched to an iPhone. While it's true that most large mailbox providers' mail clients are capable of retrieving mail from unaffiliated MBPs, it seems that Apple's Mail client is a pretty common one to do this sort of thing on.

My primary personal email address is @gmail.com<https://urldefense.com/v3/__http:/gmail.com__;!!CQl3mcHX2A!AC30eBlMX0rYYEmNCG-iliXehy7BVMpq_ihl_v2XWr7Ab9j0navONZRdWhUuPBGt4DP3ZYRDzLuntkcUKqe7EVku_YjQmAVWh3dGChw$>, and it has been for many years. So long, in fact, that Google tells me that I've got well over 9GB of storage in use for my mail. Yeah, it'd all fit on a thumb drive, but that's still $VERY_VERY_VERY_LARGE_NUMBER of messages.

I've fooled around with pointing the Mail app on my iPhone at Gmail, but I don't like the fact that the labels Gmail uses for tabs (Promotions, Social, Updates, and Forums) don't carry over as folders in IMAP, so the end result is a big old Inbox with tens of thousands of uncategorized unread messages, to say nothing of all the read ones, but I digress...

Let's say the upcoming version of Mail in iOS 16 supports BIMI for third party mailboxes, and I try once again to use Mail to read my Gmail mailbox.

How many messages should the Mail client try to do BIMI validation on before the battery on my phone is exhausted and/or the iPhone becomes a smoldering pile of melted plastic and silicon?

--
Todd Herr | Technical Director, Standards and Ecosystem
e: [e-mail]<mailto:[e-mail]>
m: 703.220.4153
[https://hosted-packages.s3-us-west-1.amazonaws.com/Valimail+Logo.png]

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.