add BIMI icons support (instead (?) on favicon) [enhancement]

plouflechien commented 3 years ago

Hi! First of all, thank you for this graet addon!! could you support BIMI icon (instead/with ?) favicon from numerous websites ?

This is, nowdays, part of dmarc/dkim standart https://bimigroup.org/ and in my opinion, be much more simplier to handle than your long list of favicons embeded with this (great) pluggin.

A dns lookup to default._bimi.domainname.tld TXT gave you an SVG file url (witch must be less than 10Kb if i remember correctly and of type tiny-svg), then give it to thunderbird instead of favicon ; thunderbird should be abble to render svg files on the fly.

Thanks.

lieser commented 3 years ago

Had a quick look, and seems at least parts of it seems to be basically a standard way of what was requested in #118.

Unfortunately BIMI itself does not solve the main point of the manually administered list inside the add-on: Establishing a trusted relation between the icon and the signing domain. I.e. BIMI does not prevent a malicious domain to use the same brand icon as from a well known company, and by that impersonating it. Yes it would be detectable if one looks carefully at the SDID. But the point of the icon is that you don't have to do that.

1. Simple standard way for brand icon retrieval

(a) This could be useful for implementing allowing the user to extend the standard favicon list #83.

(b) It could also be used as a replacement for shipping the icons inside the add-on, to reduce the size of the shipped add-on and reducing the maintenance burden for keeping the icons up to date. The list of trusted domains however would need to stay. Disadvantage here would be that one trusted domain (e.g. if it gets compromised) could impersonate all other domains.

2. Use the BIMI information that the MTA (i.e. your mail server) can provide for the MUA (e.g. Thunderbird)

BIMI seems to allow the MTA to evaluate the BIMI information for the MUA, and store it inside the Authentication-Results header (ARH). See https://tools.ietf.org/html/draft-blank-ietf-bimi-01#section-8.7. An example can be found at https://tools.ietf.org/html/draft-blank-ietf-bimi-01#appendix-C.

This would allow the add-on to basically reuse the trusted list maintained by the MTA. If the MTA is however not aware of BIMI, it could potentially allow an attacker to influence what is shown. So this would be something the user has to enable by himself, if he is sure that the sever implements BIMI.

Would be nice to know if there already exist a server implementing this.

3. Verified Mark Certificate (VMC)

This seems not to be part of BIMI itself, but is mentioned there:

This seems to be an attempt to make this trusted relation between icon and the signing domain by using certificates and root trust anchors. Basically similar how a browser can know if he can trust a TLS certificates for a specific domain.

plouflechien commented 3 years ago

Ok, mentionning VMC (Verified Mark Certificate) seems (at least to me) the death before born of the BIMI project: it's seems only a new way to some US companies to grab money from organisations worldwilde. Pretty useless .

willw-git commented 2 years ago

Thanks for pointing me to this thread (after a review of the add-on on the main web page). I notice the BIMI people are boasting they now have Gmail support for the certified images https://bimigroup.org/how-bimi-avoids-unauthorized-or-fraudulent-use-of-logos/

Would you consider some convention similar to the handling of http/https by web browsers?

e.g. unverified BIMI: shown, but with bright red, open padlock next to it. (or closed padlock crossed out?) VMC'd certificate: shown with green padlock next to it.

With the user given the option to enable or disable padlock display or whole BMI etc in the options?

(You will have spotted that I am just making work for you. ;-) But the add-on is a really neat piece of work, and this feels like a logical enhancement.)

lieser commented 2 years ago

Just showing an icon without it being in some way trusted is probably not something I will add. I would really like to keep the icon as a quick and easy way to let user know that an email can be trusted to come from a certain brand.

But if in the feature users can extend the list of trusted icons, it would of course be nice to let the user know in some way that there is a potential icon available (e.g. via BIMI) to show. And let them simply mark that icon as trusted, so it will be shown.

EmailKarma commented 2 years ago

Apple has implemented BIMI in a way that uses the standard and a the BIMI headers that are inserted by the recipients mailbox provider to determine the validity of logo: https://developer.apple.com/support/bimi

Might be worth looking at how they describe the efforts. On behalf the BIMI Group, we available to help answer questions if you have them.

plouflechien commented 2 years ago

@lieser

Just showing an icon without it being in some way trusted is probably not something I will add. I would really like to keep the icon as a quick and easy way to let user know that an email can be trusted to come from a certain brand.

perhaps returning to the good old style, with a 'green lock' sign when the bimi icon pass the VMC certification and no sign if not.. ?

@EmailKarma

Apple has implemented BIMI in a way that uses the standard and a the BIMI headers that are inserted by the recipients mailbox provider to determine the validity of logo: https://developer.apple.com/support/bimi

I'm sorry, I don't see how they made a mechanism other than VMC (Verified Mark Certificates) in their announce ? In fact I really don't understand what their syntax give more than the actual way it's handled...

This post started more than one year ago, bimi is quite dead since. I operate a small mail server with a few customers on it. It provide them all mail securities possible (dkim, tlsa, tlsrtp, dnssec, etc..). Bimi seemd a good idea at start, but the thousand dollars VMC had just killed the game before it even started. Most of my customers and I, had registred business mark with our authorities (france, INPI for registred marks, here): none of us feel the right for gafams/private foreign companies to racket us for just an icon, So, I'll soon, gave up on bimi's icons: total lost of time.

EmailKarma commented 2 years ago

I'm not sure I'd call it dead when companies like Apple, Cloudmark, Laposte and more are rolling out support for it in just the last quarter. But I appreciate your perspective on the cost, and the process but the BIMIGroup is working to address many of the things you've mentioned as roadblocks.

lieser commented 2 years ago

@EmailKarma Thanks a lot for letting me know about Apple's support for BIMI in the Authentication-Results header. If this means more or some bigger mail providers start writing the BIMI result in the header this would defiantly increase my priority of implementing some BIMI support in the addon. So far the two I am using are still not writing any BIMI results.

Did not yet read the complete BIMI spec, but at first glance it looks like Apple is having stricter requirements with the additional DKIM signatures that the BIMI spec. Are you aware on the specifics why they think this additional DKIM signature is needed to establish trust?

For testing it would be nice to have test date available for both positive and negative test, and also covering some edge cases. Are you aware of there being more test data publicly available than the examples in the appendix?

plouflechien commented 2 years ago

I have no apple products, then have no apple mail/icloud/etc... access (just a good old fairphone 2 ;-) If you have an apple mail and wan't to test with a clean a fully complying (but not paid) BIMI header, send me a PM.

I have added the BIMI Selector in our server's dkim signed headers (just after my last post), and have no more luck with gmail/gmx/protonmail .. As of today gmail & microsoft are still not sending bimi in their headers. (perhaps a good starting point shoud be (for microsoft), start being really compatible with dkim ; ie by adding their originator email's "To:" in their DKIM-Signature.....

I maintain my idea, BIMI would be a good idea if it had at start a mechanism to show if the logo is VMC authentified or not (for instance with a good old "green-lock" or a "red-open-lock" in a corner to show it's VMC status; eventually these lock should be framed with a black line to avoid being flooded in a green or a red background icon).

EmailKarma commented 1 year ago

@EmailKarma Thanks a lot for letting me know about Apple's support for BIMI in the Authentication-Results header. If this means more or some bigger mail providers start writing the BIMI result in the header this would defiantly increase my priority of implementing some BIMI support in the addon. So far the two I am using are still not writing any BIMI results.

Did not yet read the complete BIMI spec, but at first glance it looks like Apple is having stricter requirements with the additional DKIM signatures that the BIMI spec. Are you aware on the specifics why they think this additional DKIM signature is needed to establish trust?

For testing it would be nice to have test date available for both positive and negative test, and also covering some edge cases. Are you aware of there being more test data publicly available than the examples in the appendix?

Apple's requirements are new as of September so it'll take some time to have everyone catchup and support it accordingly. iCloud mail works on the mobile devices (ios16) and should now on the desktop (Monterey) - web support looks to still be a WIP as my account doesn't show logos.

Laposte (free accounts) adds the additional headers you might be looking for - CNN example:

Authentication-Results: laposte.net; spf=pass smtp.mailfrom=bounce-[redacted]@mail.cnn.com smtp.helo=[redacted]; dkim=pass reason="good signature" header.d=mail.cnn.com header.s=v2 header.b=adFGz6; dmarc=pass reason="SPF is aligned, DKIM is aligned"; arc=none smtp.remote-ip=[redacted]; bimi=pass

BIMI-Indicator: [long data hash] BIMI-Location: v=BIMI1; l=https://amplify.valimail.com/bimi/time-warner/rWgzqvey7wX-cable_news_network_inc.svg

I believe FastMail does as well (I don't have an account to validate that).

Yahoo verifies/displays BIMI even without a VMC for validated commercial email (not personal mail), but don't yet publish the full headers to my knowledge.

Other supporting MBPs may also be working on these additional headers .

dustwolf commented 1 year ago

Laposte (free accounts) adds the additional headers you might be looking for - CNN example:

Authentication-Results: laposte.net; spf=pass smtp.mailfrom=bounce-[redacted]@mail.cnn.com smtp.helo=[redacted]; dkim=pass reason="good signature" header.d=mail.cnn.com header.s=v2 header.b=adFGz6; dmarc=pass reason="SPF is aligned, DKIM is aligned"; arc=none smtp.remote-ip=[redacted]; bimi=pass

Just in case it comes handy, this header is described by RFC 5451 .

marcbradshaw commented 1 year ago

Fastmail also adds the relevant headers, we have a free trial account that could be used. Fastmail will add these headers for self asserted BIMI (without a VMC), but if a VMC is present we will verify it, and note this in the headers

Authentication-Results: mx5.messagingengine.com;
    bimi=pass header.d=cnn.com header.selector=default policy.authority=pass
      policy.authority-uri=
      https://amplify.valimail.com/bimi/time-warner/rWgzqvey7wX-cable_news_network_inc.pem
BIMI-Indicator: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPCEtLSBHZW5lcmF0b3...
BIMI-Location: v=BIMI1;
    l=https://amplify.valimail.com/bimi/time-warner/rWgzqvey7wX-cable_news_network_inc.svg
    a=https://amplify.valimail.com/bimi/time-warner/rWgzqvey7wX-cable_news_network_inc.pem

It would be possible to use those headers to determine if a VMC had been used and use this to inform display of the logo.

For deciding if BIMI headers are legitimate, that part of the draft hasn't been decided on yet, but it's clearly something that needs to be produced. As an first step for the use case of a third party client such as this one a hardcoded whitelist of IMAP services which are known to implement BIMI correctly, and strip/add headers may be good enough.

lieser commented 1 year ago

@marcbradshaw Thanks a lot for your example headers. Note that I have found an issue in it.

The value for policy.authority-uri contains characters that are not allowed in a simple token, so it must be in quotes to be a quoted-string (https://www.rfc-editor.org/rfc/rfc2045#section-5.1 contains the definition for value which is used by ARH here).

@EmailKarma Can you check if Laposte is still only writing bimi=pass in the header, or if they now also add the policy.authority=pass the header from FastMail contains?

The problem is I only want to use the BIMI icon if the server that checked BIMI tells us in the ARH that the icon can be trusted. Which basically means that all bimi=pass results without an policy.authority=pass will probably be ignored by the addon.

lieser commented 1 year ago

Small update, I have locally some rudimentary BIMI support that simply looks for an ARH result of bimi=pass with policy.authority=pass and then reads and shows the icon in the BIMI-Indicator header. I currently don't think much more checks need to be added (under the assumption that the ARH and BIMI-Indicator header can be trusted, which I think is ok if ARH reading is enabled).

Here a small example from Amazon send to a test Fastmail account, showing the icon in the header instead of the one included in the add-on for amazon: grafik

A few open questions:

@marcbradshaw Can you give an estimate then Fastmail will fix the quoted string problem? Wondering if there is a need think about allowing an RFC violation here (if it is enabled in the advanced options).
Does someone sees a need to make it configurable if BIMI is enabled, or is it OK to automatically enable it if ARH reading and showing of favicons is enabled?
Can someone think of a situation there the check I described above is not enough, and additional validation of some BIMI information would be required?

dodmi commented 1 year ago

Does someone sees a need to make it configurable if BIMI is enabled, or is it OK to automatically enable it if ARH reading and showing of favicons is enabled?

Well, what should/would happen in scenarios with limited/no internet connection?

Display no icon, as it can't be fetched?
For offline mode: Caching icons like DKIM results and show cached icons?
Fallback to classic favicon (and potentially displaying a different icon in online/offline mode)

I guess, depending on the answer, people might prefer to disable BIMI to have the "classic" behavior.

lieser commented 1 year ago

Well, what should/would happen in scenarios with limited/no internet connection?

Note that the add-on will not fetch anything from the internet here. The icon is base64 encoded inside the BIMI-Indicator Header. Retrieving the icon and putting it in the header is the responsibility of the receiving e-mail server, that also write the ARH with the BIMI result of pass.

dodmi commented 1 year ago

Ok, in this case, I can't think of anything speaking against automatically enabling BIMI in this scenario.

marcbradshaw commented 1 year ago

@marcbradshaw Can you give an estimate then Fastmail will fix the quoted string problem? Wondering if there is a need think about allowing an RFC violation here (if it is enabled in the advanced options).

We're moving carefully with this one as the fix will touch headers other than the BIMI uris, and it has not been a high priority fix. But it is moving through review now.

lieser commented 1 year ago

I just added support for BIMI to the add-on. Note that the add-on doesn't do any BIMI verification itself, but relies on the email provider to do it and store the result in the ARH.

Successfully tested it with e-mails from CNN and Amazon, received by Fastmail. Note that for Fastmail relaxed ARH parsing needs to be enabled in the advanced options.

If you want to try it out yourself you can use dkim_verifier@pl-2023-10-30-2381e68.zip.

Would be nice if compatibility with some other providers that support BIMI could be tested.

gitservers commented 8 months ago

Ok, mentionning VMC (Verified Mark Certificate) seems (at least to me) the death before born of the BIMI project: it's seems only a new way to some US companies to grab money from organisations worldwilde. Pretty useless .

can't disagree

w64 commented 4 months ago

Hey @lieser , can you check this case: In Gmail, when i receive emails from emag.bg , they are with bimi logo and blue checkmark. The same emails in Thunderbird with dkim verifier addon doesn't show logo. In the emails metadata i can't see anywhere the word "bimi" or something like that in the headers... Why there is logo in Gmail, but not in Thunderbird? Emag.bg has VMC and must be working everywhere, i think!

lieser commented 4 months ago

@w64 The addon does not do the BIMI check itself but relies on the information in the ARH header, see also https://github.com/lieser/dkim_verifier/wiki/Display-Options#show-the-favicon-of-known-signing-domains-before-the-from-address.

If you have further questions about this please create a separate issue for it, and provide the ARH headers in the email.

lieser / dkim_verifier