[Bimi] Improvements on BIMI specification

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

Dear all,

Last year I sent a mail to this mailing group because I had some 
feedback on the internet draft. However, ever since I didn't received 
any reponse on it. Actually, there was no mailing at all. However, 
because I think that BIMI is a nice feature to have, I want to help 
giving some more feedback. This are my thoughts when reading 
"draft-brand-indicators-for-message-identification-08":

- Section 1:

Remove the following block:

RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source for this draft is maintained in GitHub at:
https://github.com/BLAHBLAHBLAH (https://github.com/BLAHBLAHBLAH)

It doesn't serve any need, because the GitHub repository isn't even 
real.

- 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."

- Section 2:

It seems that thing shouldn't be there or isn't yet written:

#Requirements {#requirements}

- 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.)

- Section 4.3:

"s= Avatar Preference (plain-text; OPTIONAL; default is "bimi")."

As told in my previous mail, I would suggest to use the word "brand" 
instead of "bimi", so keeping the word "bimi" out of the DNS record 
(except for the version property).

- 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.

- Appendix:

I think we can differentiate the levels on how BIMI is set up (for a 
specific selector):
- 1) No BIMI record at all
- 2) An invalid or empty BIMI record
- 3) A BIMI record without any MCs.
- 4) A BIMI record with a CMC.
- 5) A BIMI record with a VMC.

I think that it can be useful to have those levels defined somewhere in 
the RFC, in a section or appendix. It may be out of scope for this 
document to define how Mailbox providers or mail software should behave 
for each level, but having the levels itself defined can be useful to 
write recommendations or to describe how a certain mail provider has 
implemented BIMI. (E.g. Google may have implemented to show the logo for 
level 4 and higher.)

I hope some feedback may be useful.

Ben