Subject: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2

From: Marcel Bokhorst <[email-masked]>
Date: Fri, 30 Jul 2021 09:57:23 +0200

FairEmail will not rely on the BIMI-Location header because this requires
support from the email server. Instead, FairEmail will use the logo in the
VMC and fallback to the DNS record logo location if needed (logo missing in
the VMC, etc). The logo will always be shown, but the verified sender icon
(a double check mark before the sender's name) will be shown only when
everything checks out.

I think it would be a good idea to summarize the steps to follow to
fetch/decode/check BIMI because I think it will make it easier for
developers to implement BIMI and to do this in the right way.

The BIMI TXT record is always being fetched from the top level domain (
example.org). I hope this is correct.

An IMAP flag would be nice, but I guess it will take quite some time until
all email servers are supporting this. Something like a signed
authentication results header would be nice, as long as it can be checked
in a simple and efficient way. For example heavy cryptographic operations
and looking up DNS records (for certificates, etc) would result in slow
downs and increased battery usage when downloading many messages.

Currently, the authentication header inserted by the email server is just
being trusted, but this relies on either inserting the header by the
receiving email server or removing previous headers of intermediate email
servers.

FairEmail will cache the logo for two weeks, which is the same as for
favicons. IMHO this is a reasonable default, preventing logos from being
fetched too often and still allowing to change the logo by the sender
(which I guess won't happen too often).

I hope this clarifies things, else feel free to reply.

Marcel Bokhorst (author of FairEmail)

---------- Forwarded message ----------
From: "Brotman, Alex" <[email-masked]>
To: Trent Adams <tadams=[email-masked]>, "[email-masked]" <
[email-masked]>
Cc:
Bcc:
Date: Thu, 29 Jul 2021 19:45:04 +0000
Subject: Re: [Bimi] Independent BIMI-capable Email Client

I do have that app, but I haven’t yet pointed it at a platform utilizing
BIMI.  I’ll make a note to give it a try.

>From below:

   - They aren't entirely clear on how (or why) to evaluate a logo
   referenced by the BIMI record and the one retrieved from a VMC.

What about the BIMI-Location header instance, if present? (assuming you
want to trust that header, etc).  After that, I’d probably use the VMC if
present.  Should we add an evaluation path to the core document?

   - It's also not all that clear where to retrieve the BIMI logo when the
   email is sent from a subdomain, and match that up with the DMARC results.

I’m not sure I follow the issue here.  Is there some example that shows the
questionable path?

   - There's also the question about whether or not an independent client
   can/should trust the authentication results performed by the mailbox
   provider when deciding to display the BIMI logo.

If you go back to -00 of the core spec, there was an IMAP flag that was
meant to be set (Section 8.6).  That was removed in -01.  I don’t recall
the justification, but may have had to do with MUA workload.  Seems like
the IMAP flag could be reintroduced (POP3 would be an issue though).  Or
perhaps something akin to a DKIM signature signed by the inbound MTA that
could be verified by the MUA.  The latter could potentially be reused
though?

   - There is a non-zero addition of processing required by the client to
   handle BIMI, leading to the question about what impact this may have on a
   client... and what efficiencies can be introduced with local caching (if
   any).

I’d think at least equivalent to the TTL of the BIMI DNS record, perhaps
even up to the expiration of the VMC (though I could understand where a
domain holder could refresh their VMC and change logos, etc).  I’m sure
there’s a better answer somewhere in between.

--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast

*From:* bimi <[email-masked]> *On Behalf Of *Trent Adams
*Sent:* Friday, July 23, 2021 5:36 PM
*To:* [email-masked]
*Subject:* [Bimi] Independent BIMI-capable Email Client

Since Gmail's announcement, more companies are starting to play around with
BIMI (no surprise there).  And, as expected, the increased attention is
helping to put more eyeballs on the experiment.

And while some of the major mailbox providers are adding BIMI support to
their own mobile clients, I ran into a FOSS project run by a developer in
the Netherlands who has already added BIMI to their independent mobile mail
client.

If you get a chance, I'd suggest taking a look at their FairEmail
implementation as they made some interesting choices:

https://email.faircode.eu/
<https://urldefense.com/v3/__https:/email.faircode.eu/__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfdsADeC4$>

The current Android client package can be downloaded from their GitHub
repository:

https://github.com/M66B/FairEmail/releases
<https://urldefense.com/v3/__https:/github.com/M66B/FairEmail/releases__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHf2gwnAj4$>

So far, they've already found some useful results from their experiment.
And now we're finally at a point where we can test the architecture (and
pressure-test the specifications) beyond the handful of usual suspects.

For example, here're a few issues this work as already surfaced when
interpreting the specifications [1] [2] [3]:

   - They aren't entirely clear on how (or why) to evaluate a logo
   referenced by the BIMI record and the one retrieved from a VMC.
   - It's also not all that clear where to retrieve the BIMI logo when the
   email is sent from a subdomain, and match that up with the DMARC results.
   - There's also the question about whether or not an independent client
   can/should trust the authentication results performed by the mailbox
   provider when deciding to display the BIMI logo.
   - There is a non-zero addition of processing required by the client to
   handle BIMI, leading to the question about what impact this may have on a
   client... and what efficiencies can be introduced with local caching (if
   any).

What I found most interesting was how the specifications assume a tight
coupling between the client and the mailbox provider.  It definitely opens
the question of whether it's possible (or recommended) for an independent
client to support BIMI even for email received by mailbox providers that
don't support it.  It's real-world interop testing like this that I hope
will highlight issues that need to be discussed as the experiment continues.

Also, if anyone would be willing to test the FairEmail client, I'd be keen
to hear if you think that the way it leverages BIMI matches your
expectations.  Also, are there any others out there that might contribute
their learnings to the conversation?

Anyway, thanks for any feedback you may have.  It'll be useful to hash out
ideas for improvements and next steps on the list.

Cheers,

Trent

[1] https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi-02
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-blank-ietf-bimi-02__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfVUyABq4$>

[2]
https://datatracker.ietf.org/doc/html/draft-fetch-validation-vmc-wchuang-00
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-fetch-validation-vmc-wchuang-00__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfIMZn7Z8$>

[3]
https://datatracker.ietf.org/doc/html/draft-brotman-ietf-bimi-guidance-03
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-brotman-ietf-bimi-guidance-03__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfQyodXbk$>

-- 

*J. Trent Adams*

*Director, Ecosystem Security*

*Proofpoint*

[email-masked]

bimi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bimi

---

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 30 Jul 2021 13:19:04 +0000

Consider “emails.xfinity.com”.  We didn’t want BIMI on “xfinity.com”, but just that sub-domain (for now).  There is no BIMI record at “xfinity.com”, though it does exist at “emails.xfinity.com”.  I believe this is covered in the drafts.

The flag could be nice, but again, that only covers IMAP.  What about POP (or MAPI) users?  The cryptographic solution may be more intensive, but seems like it may make BIMI more available (but yes, at the expense of mobile CPU).

Could you elaborate on the “everything checks out” from your section about evaluation?

From: bimi <[email-masked]> On Behalf Of Marcel Bokhorst
Sent: Friday, July 30, 2021 3:57 AM
To: [email-masked]
Subject: [Bimi] Fwd: bimi Digest, Vol 10, Issue 2

FairEmail will not rely on the BIMI-Location header because this requires support from the email server. Instead, FairEmail will use the logo in the VMC and fallback to the DNS record logo location if needed (logo missing in the VMC, etc). The logo will always be shown, but the verified sender icon (a double check mark before the sender's name) will be shown only when everything checks out.

I think it would be a good idea to summarize the steps to follow to fetch/decode/check BIMI because I think it will make it easier for developers to implement BIMI and to do this in the right way.

The BIMI TXT record is always being fetched from the top level domain (example.org<https://urldefense.com/v3/__http:/example.org__;!!CQl3mcHX2A!QOleDIsQOkjN3HXlKrItrq62gf5-G3hak8l7aDR3RAX6gQqWqTVXcLfIwcPA3DMVHSX2WGk$>). I hope this is correct.

An IMAP flag would be nice, but I guess it will take quite some time until all email servers are supporting this. Something like a signed authentication results header would be nice, as long as it can be checked in a simple and efficient way. For example heavy cryptographic operations and looking up DNS records (for certificates, etc) would result in slow downs and increased battery usage when downloading many messages.

Currently, the authentication header inserted by the email server is just being trusted, but this relies on either inserting the header by the receiving email server or removing previous headers of intermediate email servers.

FairEmail will cache the logo for two weeks, which is the same as for favicons. IMHO this is a reasonable default, preventing logos from being fetched too often and still allowing to change the logo by the sender (which I guess won't happen too often).

---------- Forwarded message ----------
From: "Brotman, Alex" <[email-masked]<mailto:[email-masked]>>
To: Trent Adams <tadams=[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:
Bcc:
Date: Thu, 29 Jul 2021 19:45:04 +0000
Subject: Re: [Bimi] Independent BIMI-capable Email Client
I do have that app, but I haven’t yet pointed it at a platform utilizing BIMI.  I’ll make a note to give it a try.

From below:

  *   They aren't entirely clear on how (or why) to evaluate a logo referenced by the BIMI record and the one retrieved from a VMC.

What about the BIMI-Location header instance, if present? (assuming you want to trust that header, etc).  After that, I’d probably use the VMC if present.  Should we add an evaluation path to the core document?

  *   It's also not all that clear where to retrieve the BIMI logo when the email is sent from a subdomain, and match that up with the DMARC results.

I’m not sure I follow the issue here.  Is there some example that shows the questionable path?

  *   There's also the question about whether or not an independent client can/should trust the authentication results performed by the mailbox provider when deciding to display the BIMI logo.

If you go back to -00 of the core spec, there was an IMAP flag that was meant to be set (Section 8.6).  That was removed in -01.  I don’t recall the justification, but may have had to do with MUA workload.  Seems like the IMAP flag could be reintroduced (POP3 would be an issue though).  Or perhaps something akin to a DKIM signature signed by the inbound MTA that could be verified by the MUA.  The latter could potentially be reused though?

  *   There is a non-zero addition of processing required by the client to handle BIMI, leading to the question about what impact this may have on a client... and what efficiencies can be introduced with local caching (if any).

I’d think at least equivalent to the TTL of the BIMI DNS record, perhaps even up to the expiration of the VMC (though I could understand where a domain holder could refresh their VMC and change logos, etc).  I’m sure there’s a better answer somewhere in between.

From: bimi <[email-masked]<mailto:[email-masked]>> On Behalf Of Trent Adams
Sent: Friday, July 23, 2021 5:36 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Bimi] Independent BIMI-capable Email Client

Since Gmail's announcement, more companies are starting to play around with BIMI (no surprise there).  And, as expected, the increased attention is helping to put more eyeballs on the experiment.

And while some of the major mailbox providers are adding BIMI support to their own mobile clients, I ran into a FOSS project run by a developer in the Netherlands who has already added BIMI to their independent mobile mail client.

If you get a chance, I'd suggest taking a look at their FairEmail implementation as they made some interesting choices:

https://email.faircode.eu/<https://urldefense.com/v3/__https:/email.faircode.eu/__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfdsADeC4$>

The current Android client package can be downloaded from their GitHub repository:

https://github.com/M66B/FairEmail/releases<https://urldefense.com/v3/__https:/github.com/M66B/FairEmail/releases__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHf2gwnAj4$>

So far, they've already found some useful results from their experiment.  And now we're finally at a point where we can test the architecture (and pressure-test the specifications) beyond the handful of usual suspects.

For example, here're a few issues this work as already surfaced when interpreting the specifications [1] [2] [3]:

  *   They aren't entirely clear on how (or why) to evaluate a logo referenced by the BIMI record and the one retrieved from a VMC.
  *   It's also not all that clear where to retrieve the BIMI logo when the email is sent from a subdomain, and match that up with the DMARC results.
  *   There's also the question about whether or not an independent client can/should trust the authentication results performed by the mailbox provider when deciding to display the BIMI logo.
  *   There is a non-zero addition of processing required by the client to handle BIMI, leading to the question about what impact this may have on a client... and what efficiencies can be introduced with local caching (if any).

What I found most interesting was how the specifications assume a tight coupling between the client and the mailbox provider.  It definitely opens the question of whether it's possible (or recommended) for an independent client to support BIMI even for email received by mailbox providers that don't support it.  It's real-world interop testing like this that I hope will highlight issues that need to be discussed as the experiment continues.

Also, if anyone would be willing to test the FairEmail client, I'd be keen to hear if you think that the way it leverages BIMI matches your expectations.  Also, are there any others out there that might contribute their learnings to the conversation?

Anyway, thanks for any feedback you may have.  It'll be useful to hash out ideas for improvements and next steps on the list.

Cheers,
Trent

[1] https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi-02<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-blank-ietf-bimi-02__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfVUyABq4$>
[2] https://datatracker.ietf.org/doc/html/draft-fetch-validation-vmc-wchuang-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-fetch-validation-vmc-wchuang-00__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfIMZn7Z8$>
[3] https://datatracker.ietf.org/doc/html/draft-brotman-ietf-bimi-guidance-03<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-brotman-ietf-bimi-guidance-03__;!!CQl3mcHX2A!UUyJEN3_Ay0ac-Ux9txqVoPDIfnSSmOT5S-OCXjjRVeXJEEqrPRjGUg2a_oFLJHfQyodXbk$>

--
J. Trent Adams
Director, Ecosystem Security
Proofpoint

[email-masked]<mailto:[email-masked]>

bimi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bimi<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!QOleDIsQOkjN3HXlKrItrq62gf5-G3hak8l7aDR3RAX6gQqWqTVXcLfIwcPA3DMVB8lC6MU$>

---

From: Marcel Bokhorst <[email-masked]>
Date: Fri, 30 Jul 2021 16:45:25 +0200

I understood that always "xfinity.com" should be checked and never
subdomains like "emails.xfinity.com". Am I wrong?

"*Everything checks out*" means:

   - The VMC could be downloaded from location referenced in the BIMI TXT
   record
   - The certificate chain up to a known CA certificate is valid
   - The certificate is of the right type (BIMI)
   - The DNS name of the certificate matches the domain name of the sender
   and of the BIMI DNS record
   - A logo is present and could be extracted from the certificate
   - The *Authentication-Results* header says "pass" for DKIM, SPF and DMARC
   - The DMARC DNS record policy is "reject" or "quarantine"

Op vr 30 jul. 2021 om 15:19 schreef Brotman, Alex <[email-masked]
>:

>
>
> Consider “emails.xfinity.com”.  We didn’t want BIMI on “xfinity.com”, but
> just that sub-domain (for now).  There is no BIMI record at “xfinity.com”,
> though it does exist at “emails.xfinity.com”.  I believe this is covered
> in the drafts.
>
>
>
> The flag could be nice, but again, that only covers IMAP.  What about POP
> (or MAPI) users?  The cryptographic solution may be more intensive, but
> seems like it may make BIMI more available (but yes, at the expense of
> mobile CPU).
>
>
>
> *From:* bimi <[email-masked]> *On Behalf Of * Marcel Bokhorst
> *Sent:* Friday, July 30, 2021 3:57 AM
> *To:* [email-masked]
> *Subject:* [Bimi] Fwd: bimi Digest, Vol 10, Issue 2
>
>
>
> example.org
> <https://urldefense.com/v3/__http:/example.org__;!!CQl3mcHX2A!QOleDIsQOkjN3HXlKrItrq62gf5-G3hak8l7aDR3RAX6gQqWqTVXcLfIwcPA3DMVHSX2WGk$>).
> I hope this is correct.
>
>
>
> To: Trent Adams <tadams=[email-masked]>, "[email-masked]"
> <[email-masked]>
> Cc:
> Bcc:
>    - It's also not all that clear where to retrieve the BIMI logo when
>    the email is sent from a subdomain, and match that up with the DMARC
>    results.
>
>
>
> Since Gmail's announcement, more companies are starting to play around
> with BIMI (no surprise there).  And, as expected, the increased attention
> is helping to put more eyeballs on the experiment.
>
>
>
>    - It's also not all that clear where to retrieve the BIMI logo when
>    the email is sent from a subdomain, and match that up with the DMARC
>    results.
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!QOleDIsQOkjN3HXlKrItrq62gf5-G3hak8l7aDR3RAX6gQqWqTVXcLfIwcPA3DMVB8lC6MU$>
>

---

From: Todd Herr <[email-masked]>
Date: Fri, 30 Jul 2021 11:03:10 -0400

> subdomains like "emails.xfinity.com". Am I wrong?

Current rev of the spec says to start with the author domain, then look at
the org domain if there's no BIMI record at the author domain. It's
analogous to DMARC in that way.

https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi-02#section-7.2

-- 

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

---

From: Marcel Bokhorst <[email-masked]>
Date: Fri, 30 Jul 2021 17:33:03 +0200

I see, but I am not happy with a second DNS record lookup. This might cause
extra delays in showing logos, etc. Nevertheless, I have changed this as
described now:

https://github.com/M66B/FairEmail/commit/b4a193473cbe8477584c4328b98af967fd059048

---

From: Jakub Olexa <[email-masked]>
Date: Fri, 30 Jul 2021 18:24:46 +0200

Hi Marcel,

i'm missing the check for the SVG logo. Do you intend to fully rely on 
VMC itself? I believe I have raised this topic before but if not - not 
checking that the SVG stored in VMC matches the logo in l= brings 
potential risks and most imporantly allows for misaligned logos across 
services. Allowing brands to create BIMI records that would return 
different logos in l= and a= could result in bad user experience and 
even VMC abuse. fetching the l= logo should not be an option but 
mandatory and the draft is clear on the fact that it's required. At 
least that's how I read the assertion discovery part and I believe that 
it makes no sense to permit different logo in l= and a= and not checking 
for the alignment of the 2 logos could lead to abuse.

If the retrieved Assertion Record does not include a valid bimi-
        location in the l= tag, then Indicator Discovery has failed, and
        the Indicator MUST NOT be displayed.  The bimi-location entry
        MUST be a URI with a HTTPS transport.

Jakub Olexa
Founder & CEO
E-mail: [email-masked] <mailto:[email-masked]>
Tel: +420 777 744 440 <tel:+420777744440>

Mailkit - Closing the circle between Deliverability and Engagement 
<https://www.mailkit.com>

On 30.07.2021 16:45, Marcel Bokhorst wrote:
>
> I understood that always "xfinity.com <http://xfinity.com>" should be 
> checked and never subdomains like "emails.xfinity.com 
> <http://emails.xfinity.com>". Am I wrong?
>
> "/Everything checks out/" means:
>
>   * The VMC could be downloaded from location referenced in the BIMI
>     TXT record
>   * The certificate chain up to a known CA certificate is valid
>   * The certificate is of the right type (BIMI)
>   * The DNS name of the certificate matches the domain name of the
>     sender and of the BIMI DNS record
>   * A logo is present and could be extracted from the certificate
>   * The /Authentication-Results/ header says "pass" for DKIM, SPF and
>     DMARC
>   * The DMARC DNS record policy is "reject" or "quarantine"
>
>
>
>
>
> Op vr 30 jul. 2021 om 15:19 schreef Brotman, Alex 
> <[email-masked] <mailto:[email-masked]>>:
>
>     Consider “emails.xfinity.com <http://emails.xfinity.com>”.  We
>     didn’t want BIMI on “xfinity.com <http://xfinity.com>”, but just
>     that sub-domain (for now).  There is no BIMI record at
>     “xfinity.com <http://xfinity.com>”, though it does exist at
>     “emails.xfinity.com <http://emails.xfinity.com>”.  I believe this
>     is covered in the drafts.
>
>     The flag could be nice, but again, that only covers IMAP.  What
>     about POP (or MAPI) users?  The cryptographic solution may be more
>     intensive, but seems like it may make BIMI more available (but
>     yes, at the expense of mobile CPU).
>
>     *From:* bimi <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of * Marcel Bokhorst
>     *To:* [email-masked] <mailto:[email-masked]>
>     FairEmail will not rely on the BIMI-Location header because this
>     requires support from the email server. Instead, FairEmail will
>     use the logo in the VMC and fallback to the DNS record logo
>     location if needed (logo missing in the VMC, etc). The logo will
>     always be shown, but the verified sender icon (a double check mark
>     before the sender's name) will be shown only when everything
>     checks out.
>
>
>     I think it would be a good idea to summarize the steps to follow
>     to fetch/decode/check BIMI because I think it will make it easier
>     for developers to implement BIMI and to do this in the right way.
>
>     The BIMI TXT record is always being fetched from the top level
>     domain (example.org
>     An IMAP flag would be nice, but I guess it will take quite some
>     time until all email servers are supporting this. Something like a
>     signed authentication results header would be nice, as long as it
>     can be checked in a simple and efficient way. For example heavy
>     cryptographic operations and looking up DNS records (for
>     certificates, etc) would result in slow downs and increased
>     battery usage when downloading many messages.
>
>     Currently, the authentication header inserted by the email server
>     is just being trusted, but this relies on either inserting the
>     header by the receiving email server or removing previous headers
>     of intermediate email servers.
>
>     FairEmail will cache the logo for two weeks, which is the same as
>     for favicons. IMHO this is a reasonable default, preventing logos
>     from being fetched too often and still allowing to change the logo
>     by the sender (which I guess won't happen too often).
>
>     To: Trent Adams <tadams=[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     Cc:
>     Bcc:
>     I do have that app, but I haven’t yet pointed it at a platform
>     utilizing BIMI.  I’ll make a note to give it a try.
>
>     From below:
>
>       * They aren't entirely clear on how (or why) to evaluate a logo
>     What about the BIMI-Location header instance, if present?
>     (assuming you want to trust that header, etc).  After that, I’d
>     probably use the VMC if present.  Should we add an evaluation path
>     to the core document?
>
>       * It's also not all that clear where to retrieve the BIMI logo
>         when the email is sent from a subdomain, and match that up
>         with the DMARC results.
>
>       * There's also the question about whether or not an independent
>         client can/should trust the authentication results performed
>         by the mailbox provider when deciding to display the BIMI logo.
>
>     If you go back to -00 of the core spec, there was an IMAP flag
>     that was meant to be set (Section 8.6). That was removed in -01. 
>     I don’t recall the justification, but may have had to do with MUA
>     workload.  Seems like the IMAP flag could be reintroduced (POP3
>     would be an issue though).  Or perhaps something akin to a DKIM
>     signature signed by the inbound MTA that could be verified by the
>     MUA.  The latter could potentially be reused though?
>
>       * There is a non-zero addition of processing required by the
>         client to handle BIMI, leading to the question about what
>         impact this may have on a client... and what efficiencies can
>         be introduced with local caching (if any).
>
>     I’d think at least equivalent to the TTL of the BIMI DNS record,
>     perhaps even up to the expiration of the VMC (though I could
>     understand where a domain holder could refresh their VMC and
>     change logos, etc).  I’m sure there’s a better answer somewhere in
>     between.
>
>     --
>
>     Alex Brotman
>
>     *From:* bimi <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Trent Adams
>     *To:* [email-masked] <mailto:[email-masked]>
>     Since Gmail's announcement, more companies are starting to play
>     around with BIMI (no surprise there).  And, as expected, the
>     increased attention is helping to put more eyeballs on the experiment.
>
>     And while some of the major mailbox providers are adding BIMI
>     support to their own mobile clients, I ran into a FOSS project run
>     by a developer in the Netherlands who has already added BIMI to
>     their independent mobile mail client.
>
>     So far, they've already found some useful results from their
>     experiment.  And now we're finally at a point where we can test
>     the architecture (and pressure-test the specifications) beyond the
>     handful of usual suspects.
>
>     For example, here're a few issues this work as already surfaced
>     when interpreting the specifications [1] [2] [3]:
>
>       * They aren't entirely clear on how (or why) to evaluate a logo
>       * It's also not all that clear where to retrieve the BIMI logo
>         when the email is sent from a subdomain, and match that up
>         with the DMARC results.
>       * There's also the question about whether or not an independent
>         client can/should trust the authentication results performed
>         by the mailbox provider when deciding to display the BIMI logo.
>       * There is a non-zero addition of processing required by the
>         client to handle BIMI, leading to the question about what
>         impact this may have on a client... and what efficiencies can
>         be introduced with local caching (if any).
>
>     What I found most interesting was how the specifications assume a
>     tight coupling between the client and the mailbox provider.  It
>     definitely opens the question of whether it's possible (or
>     recommended) for an independent client to support BIMI even for
>     email received by mailbox providers that don't support it.  It's
>     real-world interop testing like this that I hope will highlight
>     issues that need to be discussed as the experiment continues.
>
>     Also, if anyone would be willing to test the FairEmail client, I'd
>     be keen to hear if you think that the way it leverages BIMI
>     matches your expectations.  Also, are there any others out there
>     that might contribute their learnings to the conversation?
>
>     Anyway, thanks for any feedback you may have.  It'll be useful to
>     hash out ideas for improvements and next steps on the list.
>
>     Cheers,
>
>     Trent
>
>     /Director, Ecosystem Security/
>
>     *Proofpoint*
>
>     [email-masked] <mailto:[email-masked]>
>
>     bimi mailing list
>     [email-masked] <mailto:[email-masked]>