> So, if a MUA [...] displays besides verified BIMI logos also other logos,
> obtained by different method from a different source (for example Gmail
> profile pictures as it is today), we have exactly this case - the presence
> or absence of logo says nothing to the user with respect to whether the mail
> is genuine or not.
>
> [...] To fulfill this goal, it must be the only mechanism.
I feel like multiple people in this thread have mentioned alternative ways of
showing a logo is verified. Some MUAs may work on the principle you suggest,
presence alone. But if an MUA has some sort of other indicator that the brand
logo was verified for a specific email, surely that still fulfills a large part
of the goal? In the end it's up to the MUA how to best implement this in a way
that it's clear to the user, but I don't see how that's the fault of the BIMI
spec. It's just another tool that should help communicate email authenticity
somewhat clearer (while also being quite attractive to adopt for many
businesses, who doesn't want their logo next to the email saying it's verified).
I'm not sure why people seem to be taking this all or nothing approach, where
either it solves everything or it's useless. The reality is almost always
somewhere in between.
Groetjes,
Louis
Op zaterdag 13 januari 2024 om 00:52, schreef Jaroslaw Rafa via mailop
<mailop@mailop.org>:
> Dnia 12.01.2024 o godz. 13:23:07 Todd Herr via mailop pisze:
> > There is no such thing as "BIMI-authenticated". BIMI isn't authentication,
> > and doesn't claim to be. I quote from the Abstract of
> >
> https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification
> [https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification]
> >
> > BIMI permits Domain Owners to coordinate with Mail User Agents (MUAs) to
> > display brand-specific Indicators next to properly authenticated messages.
> > There are two aspects of BIMI coordination: a scalable mechanism for Domain
> > Owners to publish their desired Indicators, and a mechanism for Mail
> > Transfer Agents (MTAs) to verify the authenticity of the Indicator.
> >
> > The "scalable mechanism" is the DNS, and the "mechanism for MTAs to verify
> > the authenticity" is the Evidence Document, a.k.a., the VMC.
>
> And that's what I call by a shortcut "BIMI-authenticated". A properly
> authenticated message that also conforms to the BIMI spec and has a
> validated logo (VMC). In other words, a message that is qualified to have
> the logo displayed, according to the BIMI spec.
>
> Let's step aside a bit from the technical details and conformance to the
> specs and return to the basic question I'm asking from the very beginning, a
> question that needs to be viewed in "big picture" and not only in terms of
> conformance to the specs or what piece of software does what. Let's look at
> the whole *system*, as it is done in system testing, and try to test the
> design from the end user point of view.
>
> The question is:
> What problem is BIMI supposed to solve, and/or what benefits it gives to the
> user?
>
> From the very paragraph you quoted above, the answer is more or less so: it
> allows for displaying of *verified* logos alongside messages, which can
> serve as a visual signal to the user that the message is genuine.
>
> I emphasized the word *verified*, because the whole sense of BIMI depends on
> this very word. If the logos are not verified, their presence or absence
> isn't any useful signal to the user.
>
> So, if a MUA (it's not important at the moment whether it is a mailbox
> provider's
> webmail client, or some independent application - *something* has to display
> these logos anyway), displays besides verified BIMI logos also other logos,
> obtained by different method from a different source (for example Gmail
> profile pictures as it is today), we have exactly this case - the presence
> or absence of logo says nothing to the user with respect to whether the mail
> is genuine or not. The user can get a similar visual experience with a
> spoofed message that has a logo obtained eg. from someone's profile picture
> and with a legitimate message that has a verified BIMI logo. And that was
> the whole purpose of BIMI, that the presence of the logo should help
> distinguish real messages from the fake ones, right?
>
> In other words, the design fails the end-user test case at this point.
>
> So if a MUA displays other logos besides verified BIMI logos, it effectively
> defeats the purpose of BIMI. The "big picture", high-level purpose, not the
> one understood as conformance to the specs. I wonder how you can not see
> this and say that:
>
> > BIMI is not the end-all and be-all of display of logos or avatars at some
> > place in an MUA; it is one specification for having such logos appear,
> > either in the folder list, next to the message after it's opened, or both.
>
> As I have shown above, for BIMI to be useful, it *has* to be the *only*
> specification for having such logos appear, and no other options could be
> possible. If other options exist, the design fails the usability test.
>
> Also Tim writes in similar tone here:
>
> Dnia 12.01.2024 o godz. 14:04:59 Tim Starr via mailop pisze:
> > BIMI's value is not dependent upon MUAs
> > never doing anything outside its spec.
>
> Yes, it is. Because it depends on the condition that the logo is displayed
> only if it is a verified BIMI logo.
>
> If that condition is not met (and logo is displayed in other circumstances
> too), BIMI fails the usability test.
>
> If I'm wrong, please explain in detail (but not in technical detail with
> regard to the spec, but rather try to refer to some hypothetical end-user
> test case as I did) where I'm wrong. Because again, I don't see BIMI
> fulfilling its purported goal if it's only *one* of the mechanisms to display
> logos. To fulfill this goal, it must be *the only* mechanism.
> --
> Regards,
> Jaroslaw Rafa
> r...@rafa.eu.org [r...@rafa.eu.org]
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> _______________________________________________
> mailop mailing list
> mailop@mailop.org [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
