Re: [Bimi] Thoughts about MUA/BIMI

[Todd Herr <[e-mail]>]

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.


-- 

*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.