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

[Marcel Bokhorst <[e-mail]>]

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 <[e-mail]
>:

>
>
> 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?
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* bimi <[e-mail]> *On Behalf Of * Marcel Bokhorst
> *Sent:* Friday, July 30, 2021 3:57 AM
> *To:* [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]>
> To: Trent Adams <tadams=[e-mail]>, "[e-mail]"
> <[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]> *On Behalf Of *Trent Adams
> *Sent:* Friday, July 23, 2021 5:36 PM
> *To:* [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]
>
>
>
> bimi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bimi
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!QOleDIsQOkjN3HXlKrItrq62gf5-G3hak8l7aDR3RAX6gQqWqTVXcLfIwcPA3DMVB8lC6MU$>
>