> Then the recipient can choose to use a MUA that supports avatars (of course,
> there should always be the possibility to turn them off in configuration -
> which also solves the issue of tracking; if someone doesn't want to be
> tracked, he/she can turn the avatar support off in options, and their MUA
> won't fetch any avatar images from any website).
Of course! In my case avatars can be disabled, it's user preference whether to
have them or not. The avatars are also cached for a month or more on the server
side, are never requested directly from the client as to expose the user IP, and
only ever fetch the root domain to avoid tracking through per user subdomains.
Tracking would still be possible if you use a single domain specifically to
track a single user, but my thinking is that the chances of that are fairly low.
> But what would be actually desirable, is exactly what you wrote - an
> implementation not geared towards businesses. BIMI is nothing like this, as
> John clearly explained below it is and always will be geared towards
> businesses
Yep! To be fair, a lot of people receive mostly B2C email. So in the case of a
recipient wanting to see avatars, it's still quite nice to have as opposed to no
standard at all. A general avatar standard would have been nicer in my opinion.
But then, perhaps the big players would not have adopted it because there are no
verification benefits? Not sure.
Groetjes,
Louis
Op donderdag 11 januari 2024 om 12:19, schreef Jaroslaw Rafa via mailop
<mailop@mailop.org>:
> Dnia 10.01.2024 o godz. 22:57:21 Louis Laureys via mailop pisze:
> > Just wanted to add that I actually like it for visual clarity. Though I
> would
> > have liked a more general avatar implementation not geared towards
> businesses.
>
> If someone, *as a recipient*, likes having avatars next to email, I have
> nothing against it - but *only if it's totally optional and decided upon by
> recipient* (and by recipient, I mean the individual person and not the
> organization that runs the receiving mail server). Then the recipient can
> choose to use a MUA that supports avatars (of course, there should always be
> the possibility to turn them off in configuration - which also solves the
> issue of tracking; if someone doesn't want to be tracked, he/she can turn
> the avatar support off in options, and their MUA won't fetch any avatar
> images from any website).
>
> But what would be actually desirable, is exactly what you wrote - an
> implementation *not geared towards businesses*. BIMI is nothing like this,
> as John clearly explained below it *is and always will be* geared towards
> businesses. And for me BIMI looks more like push from the *senders* (and in
> particular, big marketing senders) on people to use the avatars (and use
> them only in a particular way dictated by big businesses), rather than
> a response to an *actual need* from *recipients* to use them.
>
> Dnia 10.01.2024 o godz. 21:21:16 John Levine via mailop pisze:
> > While it would be nice to make BIMI available to small organizations
> > without costing a lot of money, the question "is entity A allowed to
> > show logo X" is very hard even for people, and not amenable to
> > authomation. In a few cases where the entity has already paid to put
> > the logo in a trademark database it's easier but that sure doesn't
> > scale.
>
> There is a very real danger (and this is even predicted in the document
> linked in the previous email) that adoption of BIMI by big mail providers
> will serve as another "antispam" measure; messages having verified BIMI mark
> would be treated by ISPs as more "trustworthy" and "reputable" than the
> messages that don't. This would clearly lead to dividing email service in
> two categories: "first class" would be an email from businesses that are big
> and rich enough that they can afford having their email BIMI certified,
> which would give them a kind of "guarantee" for their emails to be delivered
> to all the big ISPs - and a "second class" consisiting of all the other
> senders, who lack BIMI verification, and thus can only hope to have luck
> that their email gets through the filters (which will happen gradually less
> and less often).
>
> As it has happened with DMARC, which also in the beginning - as the document
> states - was purely optional and meant only for specific, often-phished
> domains.
>
> This is a very bad perspective, and BIMI is in my opinion a road straight to
> this direction.
> --
> 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
