[Bimi] Re: Improvements on BIMI specification

[Ben van Hartingsveldt | Yocto <[e-mail]>]

Taavi Eomäe schreef op 2025-01-27 13:45:
> On 27/01/2025 15:07, Ben van Hartingsveldt | Yocto wrote:
>> - Section 2:
>> 
>> Change "BIMI relies on these authentication protocols, but is not a 
>> new authentication protocol itself." to "BIMI relies on these 
>> authentication protocols, but is not a new authentication protocol 
>> itself. Failing for BIMI should not have an other effect then having 
>> no BIMI at all."
> 
> I do not see the point in adding that sentence. It's unlikely that 
> vendors will follow such an instruction because the existence of BIMI 
> can (but maybe not should) be considered a positive thing (due to its 
> somewhat higher requirements). Thus the inverse also applies, not being 
> given a "bonus" is an effect, and the sentence would not really have 
> any practical value.
> 
I think I forgot the word "delivery" here: "Failing for BIMI should not 
have an effect on delivery then having no BIMI at all."
> 
>> 
>> - Section 4.2:
>> 
>> At the moment, personal avatars only work on same-platform mails, not 
>> on cross-platform mails. If I want other mail providers to access the 
>> avatars of my platform, I would like to have some option to do that. 
>> (E.g. "v=BIMI1; p=https://avatars.example.com/images/%s" or something, 
>> where %s is the mail address or some other thing that could be used to 
>> indicate a user or mailbox.)
> 
> A personal avatar is (usually) not a brand, so this really not in the 
> scope of BIMI.
> 
Understandable for being out of scope. There may pop up some other RFC 
one day that will cover this, esspecially when using the value 
"personal".
> 
>> - Section 5:
>> 
>> The BIMI-Selector header is understandable. It indicates which 
>> selector is used to get the correct BIMI DNS record. But what is the 
>> purpose of having the other 3 headers? They are all inserted by the 
>> Mail Receiver, but having those written in the mail file makes them 
>> breakable. I change the DNS record in the future, maybe because my URL 
>> paths have changed, those BIMI headers have invalid values and the 
>> BIMI logo is not able to load anymore. Technically, a MUA that 
>> implements BIMI can generate these values themselves.
> 
> There are multiple topics here.
> 
> The first one being that how does the MUA know that the MTA is doing 
> BIMI validation, current implementations require a specific set of MTA 
> + MUA. Vendors like Apple say otherwise, but there's no usable 
> documentation for fulfilling their requirements. There have been 
> mentions of JMAP/IMAP extension to signify support, letting the MUA 
> automatically trust their MTA (which is a fairly reasonable thing 
> considering). I'm not aware of any ongoing efforts by MUAs to do so 
> though. (If any IMAP MUA developer is interested, then we are actively 
> developing an IMAP server here at Zone.EU and could discuss the details 
> of adding support for such an extension.)
> 
> Second topic is BIMI invalidation. There is a draft here that proposed 
> some approaches. Though we at Zone.EU found it overly complex (at least 
> currently) and find it that a received message should remain as it is 
> over time (as much as possible). Being able to unpublish a BIMI image 
> almost the same way as its possible to unpublish DKIM keys and the 
> resulting effect seems reasonable. Putting in effort to go further in 
> terms of both revocation and un-revocation seems excessive.
> 
> Third topic would be BIMI caching. For example to provide some 
> resiliency against errors like (accidentally) breaking your URLs. But 
> this feels very architecture and threat model specific, it would be 
> weird to try and dictate any implementation details.
> 
You want BIMI to work only on real emails from that company, indeed, not 
the spoofed ones. It seems that those 3 headers are now in the spec 
because the server is more knowledgable on what is fake and what is not, 
and only adding the headers to the mail when it validated the mail being 
authentic. I'm not against adding headers, but a simple "BIMI-Validated: 
1" would do the same thing, I guess, without having breakable URLs 
within its headers. Also, there may be some already existing headers 
like "Authentication-Results" that can be used instead of introducing a 
new header like "BIMI-Validated".
> 
> Best Regards,
> Taavi