Add local BIMI validation to show favicons for domains signing the logo using a Mark Certificate

[lieser]

Some minimal BIMI support was already added in #242. It relies on the MTA to write the BIMI result inside the Authentication-Results header.

However many mail providers do not yet support BIMI and won't write a BIMI result in the Authentication-Results header. For this it would be good if the add-on could do a local BIMI validation.

Note that we explicitly don't want to support self-asserted logos and will require the logo to be signed using a Mark Certificate (MC).
A longer explanation on why can be found in #417 (comment), and an explanation of the different types in https://bimigroup.org/understanding-bimi-certificate-types/.

Some additional links:

• Website for BIMI: https://bimigroup.org/
  • https://bimigroup.org/supporting-documents/
  • https://bimigroup.org/vmc-issuers/
• Latest RFC draft of BIMI: https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/
• Latest RFC draft for Fetch and Validation of Verified Mark Certificates: https://datatracker.ietf.org/doc/html/draft-fetch-validation-vmc-wchuang

[zWhdmB5T]

Issue on Bugzilla: can you please check and confirm - English / Applications - openSUSE Forums

Please see full comment at https://forums.opensuse.org/t/issue-on-bugzilla-can-you-please-check-and-confirm/188263/14 fur current info!

FYI: working temporary solution / positiv work-around!
 

- My ~/.config/fontconfig/fonts.conf is not relevant.
- openSUSE standard build 128 ESR DOES work without modifications in >about:config
- Flatpak 143 DOES work without modifications in about:config — but does have >different specific standard values!
- openSUSE standard build 140 ESR does NOT work with standard values — but CAN >work with modifications in about:config — the standard values are different >again: from 128 ESR AND from Flatpak 143!
 
Please view and compare! I marked the areas of interest.
 
I don’t have a clue about the meaning and background, i.e. is this really really a bug (maybe not!) or just different standard behaviour…?

Issue seems related to upstream, so probably this ticket can be closed.