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

[Jakub Olexa <[e-mail]>]

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: [e-mail] <mailto:[e-mail]>
Tel: [phone] <tel:[phone]>

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 
> <[e-mail] <mailto:[e-mail]>>:
>
>     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).
>
>     Could you elaborate on the “everything checks out” from your
>     section about evaluation?
>
>     --
>
>     Alex Brotman
>
>     Sr. Engineer, Anti-Abuse & Messaging Policy
>
>     Comcast
>
>     *From:* bimi <[e-mail]
>     <mailto:[e-mail]>> *On Behalf Of * Marcel Bokhorst
>     *Sent:* Friday, July 30, 2021 3:57 AM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *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).
>
>     I hope this clarifies things, else feel free to reply.
>
>     Marcel Bokhorst (author of FairEmail)
>
>
>     ---------- Forwarded message ----------
>     From: "Brotman, Alex" <[e-mail]
>     <mailto:[e-mail]>>
>     To: Trent Adams <tadams=[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>     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 <[e-mail]
>     <mailto:[e-mail]>> *On Behalf Of *Trent Adams
>     *Sent:* Friday, July 23, 2021 5:36 PM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *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*
>
>     [e-mail] <mailto:[e-mail]>
>
>     bimi mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/bimi
>     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!QOleDIsQOkjN3HXlKrItrq62gf5-G3hak8l7aDR3RAX6gQqWqTVXcLfIwcPA3DMVB8lC6MU$>
>
>