Re: [Bimi] Thoughts about MUA/BIMI

[Todd Herr <[e-mail]>]

On Thu, Aug 11, 2022 at 1:54 PM Todd Herr <[e-mail]> wrote:

> On Thu, Aug 11, 2022 at 1:03 PM John C Klensin <[e-mail]> wrote:
>
>>
>>
>> --On Thursday, August 11, 2022 10:38 -0400 Todd Herr
>> <todd.herr=[e-mail]> wrote:
>>
>> > On Thu, Aug 11, 2022 at 10:21 AM Brotman, Alex <Alex_Brotman=
>> > [e-mail]> wrote:
>> >
>> >> In thinking more about the MUA proposal, we are trying to
>> >> find a solution for the case where an unaffiliated[1] MUA
>> >> would like to be able to either independently validate
>> >> message authentication details (to support DMARC), or rely
>> >> upon the validation process from the MBP.
>> >>
>> >> [snip]
>> >>
>> >
>> > I've got a long-standing bias toward the idea that the only
>> > authentication/validation results that matter are the ones
>> > that were arrived at when the message was written to the
>> > mailbox, because results can be different upon subsequent
>> > checks, mainly due to potential differences in the
>> > resolvability and content of the various DNS records retrieved
>> > during the validation processes.
>>
>> I have the same bias, but it leads me to a different place.
>> That, again, is to conclude that the BIMI data is content
>> information, best expressed as a body part.  Body parts,
>> signatures over them, and other validation are far more stable
>> than header fields and combinations of them.  And, of course,
>> they do not require interactions with DMARC at all.  In
>> addition, body parts generally survive message forwarding, which
>> ought to be an advantage in this case.
>>
>> It is my understanding that mailbox providers, at least the larger ones,
> are keen on seeing email authentication standards more widely adopted than
> they are today, because authenticated mail is a much more stable anchor to
> which to attach reputation for mail streams than other data points. Now,
> they have a tool on their tool belt to make that happen, and they will
> occasionally finger the holster holding that tool. It's a big old hammer,
> and written on its handle is "No Auth, No Entry", and were they to
> let loose the hammer on the world I suspect that they might get the
> adoption rates they seek after some period of time has passed, but not
> without quite a lot of pain in the interim, not just for senders but also
> for the mailbox providers' users, who would miss out on some wanted mail.
>
> In the meantime, there is the concept of BIMI, the current intent of which
> is to drive adoption of email authentication best practices. The idea
> behind it is that if a domain owner does the work to get to a point where
> it can publish a DMARC policy of p=reject or at least p=quarantine for both
> its sending domain and its organizational domain, then it can possibly
> enjoy the privilege of having its logo displayed with mail it sends to
> participating mailbox providers, modulo whatever other requirements such a
> mailbox provider might impose.
>
> Your implementation of BIMI data as a body part might well solve the
> problem of communicating the BIMI logo information to the downstream MUA,
> but if pushing DMARC adoption is to be a goal for BIMI, then we still have
> to figure out how best for that unaffiliated MUA to determine whether the
> underlying DMARC policy requirements are met before displaying the logo.
>
>
And the more I think about this, I'm wondering if I'm overthinking it...

If your proposal is that the BIMI data is only attached as a body part by
the MBP if the DMARC/auth requirements were met at the time the message was
accepted by the MBP, then I apologize for misunderstanding your proposal.

That said, I still think we might have a trust issue for the unaffiliated
MUA, since an abuser could theoretically attach a MIME part and run it
through any MBP that's not participating in BIMI.

-- 

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