[mailop] BIMI and multiple hops

[Andrew C Aitchison via mailop]

[ Wearing an MTA developer's hat. ]

I see that an MTA is supposed to remove existing Authentication-Results 
and BIMI-Indicator headers, and that generally an MUA may use these 
headers if present.


I presume that most MTAs only add these headers on delivery, but if a 
non-compliant MTA received a message with these headers there is a risk 
that the MUA would trust them.


Would it help if MUAs that don't actively support BIMI at least removed 
these headers when delivering to local mailboxes ?


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Louis Laureys via mailop]

> 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
:

> 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 

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Robert L Mathews via mailop]

On Jan 12, 2024, at 3:52 PM, Jaroslaw Rafa via mailop  wrote:

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

Yes, this is exactly right.

If an MUA displays a "sender's logo" like this, it's a signal that "a human 
being has checked this out, and is reasonably confident that this logo 
accurately represents the true sender".

Recipients can then (optionally) use that logo to help them decide "this 
message really is from my bank" -- or more to the point, to decide they should 
be suspicious of a later message  "from the bank" that does not display this 
logo.

If an MUA also displays any sender-controlled logos that have not been 
human-verified as part of this process, it defeats the purpose, because 
malicious senders would then be able to use the bank's logo.

I hope nobody creates MUA features that show non-BIMI logos in the same space 
as BIMI logos (or that make it difficult for users to notice the difference, 
such as a tiny padlock superimposed on it sometimes).

If MUA authors think BIMI is pointless, or that users shouldn't be trusting 
logos to make security decisions, that's fine -- but then they should not 
implement BIMI or display "sender logos" outside the message's content area at 
all. I want to be able to tell my 91-year-old wife's uncle that "if you get a 
message from Bank of America and it doesn't have that logo to the left of the 
sender's name, call me before you do anything".

-- 
Robert L Mathews

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Jaroslaw Rafa via mailop]

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
> 
> 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
--
"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
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Gellner, Oliver via mailop]

On 10.01.2024 at 21:59 Randolf Richardson, Postmaster via mailop wrote:

> What's missing from BIMI in its current form?  The option for mail server 
> oparators to use the same TLS certificates that we're already using for our 
> mail servers (and web servers, and FTP servers, etc.).

A server certificate only verifies domain ownership. It does not include any 
logos, so it's not suitable to authenticate a BIMI selector. Therefor a server 
certificate cannot be used as evidence whether a domain is entitled to use a 
certain logo or not.

Besides AFAIK the list price for a Verified Mark Certificate is 1500$. 
Depending on other contracts which a company might already have with the CA 
they'd probably receive a 10% to 90% discount. Even without any discount, 1500$ 
per year is not really something which I would consider a barrier for anyone 
but very small shops. Even a 3 person business will probably pay more for 
coffee than for the  certificate per year.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Gellner, Oliver via mailop]

On 11.01.2024 at 17:18 Ángel via mailop wrote:

> On 2024-01-10 at 20:38 +, Gellner, Oliver wrote:
>> Either way, BIMI is not suitable for reader tracking as you cannot
>> provide different logo URIs for each recipient.

> Sorry, but it would be possible:
>> Domain Owners can specify which other selector to use on a per-
>> message basis by utilizing the BIMI-Selector Header

> You could set a different selector per email message sent. You could manage 
> that with a wildcard dns entry and check the dns server logs.

> However, the draft is specified in such manner that the fetching would be 
> done by the MTA, so the BIMI check and fetching wouldn't provide information 
> to the senders.

Yes and even if the MUA fetched the logo directly, tracking would only be 
possible if the receiver displayed unverified BIMI logos. Otherwise the sender 
would have to acquire a different VMC for each selector / recipient, which 
wouldn't scale. There are a lot of ways to track email receivers, BIMI isn't 
one of them.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Tim Starr via mailop]

I don't see how you're disagreeing with me. BIMI is a complicated if-then
statement. If X, then do Y. It says nothing about doing anything else. I
didn't say displaying non-BIMI images was contrary to the spec, just that
it was something outside the spec. BIMI's value is not dependent upon MUAs
never doing anything outside its spec.

-Tim

On Fri, Jan 12, 2024 at 12:05 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 12.01.2024 o godz. 11:18:32 Tim Starr via mailop pisze:
> > By publishing the BIMI spec. No one's required to follow the spec, but if
> > they don't, then they're not doing BIMI, and that's not the fault of the
> > spec.
>
> Does the BIMI spec *require* that *only* BIMI-authenticated messages can
> have logos displayed alongside them in the MUA?
>
> In my understanding no. If it actually states so, then it's far too
> restrictive and unacceptable (and this *is* fault of the spec). That's what
> im talking about all the time.
>
> So MUAs that display "other" (non-BIMI !) logos, are doing BIMI *plus*
> something else. They are not contrary to the BIMI spec. They are just in
> addition doing something that is completely orthogonal to BIMI, but gives
> similar visual experience to the user.
>
> Which actually defeats the purpose of BIMI, as I understand it.
> --
> Regards,
>Jaroslaw Rafa
>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
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Todd Herr via mailop]

On Fri, Jan 12, 2024 at 12:30 PM Randolf Richardson, Postmaster via mailop <
mailop@mailop.org> wrote:

> As an aside, I find it interesting that the BIMI Group doesn't
> have
> a Verified Mark (no PEM specified in the "a=" parameter):
>
> https://bimigroup.org/bimi-generator/
>
> Just type "bimigroup.org" in that form and see the results, which
> show their logo followed by this notice:
>
> "Note: While your BIMI record is compliant, it doesn't
> include a
> Verified Mark Certificate that may be required by some mailbox
> providers."
>
> With all the money that the two CAs the BIMI Group promotes could
> earn, I'm surprised that neither of them has donated a free
> certificate.
>
> I don't know that bimigroup.org is used as the From domain in any emails
sent on behalf of the working group, so this isn't a terribly big deal.

Of course, I feel compelled to point out that I'm doing the same
> thing right now as the BIMI Group is doing (no PEM defined in the
> "a=" parameter), and I think this is fine and that it's perfectly
> okay for the BIMI Group to do it this way too.
>
>
A self-asserted logo as you have and as the domain bimigroup.org has is
certainly valid from a specification perspective; however, not all mailbox
providers that participate in BIMI support the display of logos that are
self-asserted.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*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.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Todd Herr via mailop]

On Fri, Jan 12, 2024 at 1:03 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 12.01.2024 o godz. 11:18:32 Tim Starr via mailop pisze:
> > By publishing the BIMI spec. No one's required to follow the spec, but if
> > they don't, then they're not doing BIMI, and that's not the fault of the
> > spec.
>
> Does the BIMI spec *require* that *only* BIMI-authenticated messages can
> have logos displayed alongside them in the MUA?
>

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

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.

The current BIMI spec requires that:

   - A message pass DMARC authentication
   - The RFC5322.From domain's DMARC policy be either p=quarantine or
   p=reject
   - The Organizational Domain (as defined by DMARC) for the RFC5322.From
   domain (if different) also have a DMARC policy of p=quarantine or p=reject,
   and further the Organizational Domain must not have sp=none in its DMARC
   record.
   - There is a BIMI record published in DNS that is associated with the
   RFC5322.From domain, usually at default._bimi.fromDomain or
   default._bimi.organizationalDomain, although alternative selector names are
   supported.

Mailbox providers who participate in BIMI can and likely will add other
criteria to their decision as to whether or not to actually have their
clients display a BIMI logo.


> In my understanding no. If it actually states so, then it's far too
> restrictive and unacceptable (and this *is* fault of the spec). That's what
> im talking about all the time.
>
>
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.

So MUAs that display "other" (non-BIMI !) logos, are doing BIMI *plus*
> something else. They are not contrary to the BIMI spec. They are just in
> addition doing something that is completely orthogonal to BIMI, but gives
> similar visual experience to the user.
>
> Which actually defeats the purpose of BIMI, as I understand it.
>

I do not know of any independent MUAs (i.e., those that are not client
applications of mailbox providers) that currently support BIMI. I suspect
that it might be rather a challenge for an independent MUA to perform the
required DMARC validation of the message, but I am not a developer of MUAs
and so cannot do any more than suspect this to be true.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*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.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Jaroslaw Rafa via mailop]

Dnia 12.01.2024 o godz. 11:18:32 Tim Starr via mailop pisze:
> By publishing the BIMI spec. No one's required to follow the spec, but if
> they don't, then they're not doing BIMI, and that's not the fault of the
> spec.

Does the BIMI spec *require* that *only* BIMI-authenticated messages can
have logos displayed alongside them in the MUA?

In my understanding no. If it actually states so, then it's far too
restrictive and unacceptable (and this *is* fault of the spec). That's what
im talking about all the time.

So MUAs that display "other" (non-BIMI !) logos, are doing BIMI *plus*
something else. They are not contrary to the BIMI spec. They are just in
addition doing something that is completely orthogonal to BIMI, but gives
similar visual experience to the user.

Which actually defeats the purpose of BIMI, as I understand it.
-- 
Regards,
   Jaroslaw Rafa
   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
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Randolf Richardson, Postmaster via mailop]

As an aside, I find it interesting that the BIMI Group doesn't have 
a Verified Mark (no PEM specified in the "a=" parameter):

https://bimigroup.org/bimi-generator/

Just type "bimigroup.org" in that form and see the results, which 
show their logo followed by this notice:

"Note: While your BIMI record is compliant, it doesn't include 
a 
Verified Mark Certificate that may be required by some mailbox 
providers."

With all the money that the two CAs the BIMI Group promotes could 
earn, I'm surprised that neither of them has donated a free 
certificate.

Of course, I feel compelled to point out that I'm doing the same 
thing right now as the BIMI Group is doing (no PEM defined in the 
"a=" parameter), and I think this is fine and that it's perfectly 
okay for the BIMI Group to do it this way too.

As for the ESP hacking problem, that's one very good example of how 
technology ultimately can't solve all social problems.

> The image has to be specified in the DNS, and it has to be certified w/ a
> VMC. The VMC certification process includes checking if it's trademarked.
> So, in order for a trusted brand's BIMI logo to get spoofed, the email
> would have to be DMARC-authenticated and the logo specified in the DNS
> would be the one presented to the mailbox provider when they do DNS lookups
> on the authentication domains. IOW, the only real way to do it would be
> with account takeovers. If you can hack into the ESP account of a trusted
> brand, then you can send fully-authenticated email for that brand, with its
> BIMI logos.
> 
> The biggest spoofing risk here is with really inclusive SPF records that
> include an entire cloud SMTP provider's IP ranges, where other senders also
> send from those ranges, and they can then send SPF-authenticated email w/ a
> trusted brand's return-path domain, which would then pass DMARC and BIMI.
> But that's a security risk already, BIMI doesn't make it worse. Cloud SMTP
> providers need to do a better job of locking down the sending domains their
> clients can use to prevent that. However, even there, if the DNS accounts
> of domain owners can be hacked into, authorization of domains can be faked,
> too. But, again, that's an existing risk, which BIMI doesn't make any worse.
> 
> -Tim
> 
> On Thu, Jan 11, 2024 at 2:35PM Bastian Blank via mailop 
> wrote:
> 
> > On Thu, Jan 11, 2024 at 01:45:19PM -0600, Tim Starr via mailop wrote:
> > > To elaborate on Marcel's answer, so he doesn't have to waste time
> > > explaining it all over again, the "different logo" won't be displayed by
> > > the mailbox providers, because it's not the authenticated one.
> >
> > What prohibits them from making it authenticated?  A trademark check?
> >
> > Bastian
> >
> > --
> > Extreme feminine beauty is always disturbing.
> > -- Spock, "The Cloud Minders", stardate 5818.4
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> >
> 


-- 
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Tim Starr via mailop]

By publishing the BIMI spec. No one's required to follow the spec, but if
they don't, then they're not doing BIMI, and that's not the fault of the
spec.

-Tim

On Thu, Jan 11, 2024 at 5:31 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 11.01.2024 o godz. 17:02:01 Tim Starr via mailop pisze:
> > The image has to be specified in the DNS, and it has to be certified w/ a
> > VMC. The VMC certification process includes checking if it's trademarked.
> > So, in order for a trusted brand's BIMI logo to get spoofed, the email
> > would have to be DMARC-authenticated and the logo specified in the DNS
> > would be the one presented to the mailbox provider when they do DNS
> lookups
> > on the authentication domains.
>
> Under the assumption that that he MUA will display *only certified BIMI
> logos* and not any other "avatars" with the emails, ever.
>
> How are you going to force MUA developers to do that?
>
> Assume the recipient uses a MUA that displays not only BIMI logos, but eg.
> avatars from Gravatar service as well. The attacker just sets as his
> Gravatar picture the logo he wants to spoof. Then sends mail to the
> recipient. Recipient sees a familiar logo (without BIMI being used at all!)
> and assumes the mail is genuine.
>
> As I wrote previously, the only method to prevent this is a (totally
> unrealistic) *legal prohibition* for MUA developers to display any other
> images than certified BIMI logos. Not possible.
> --
> Regards,
>Jaroslaw Rafa
>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
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop