Re: [Bimi] Alternate proposal

["Brotman, Alex" <[e-mail]>]

John,

Firstly, apologies for my late response.  Dayjob and IETF kept me from re-reading the proposal.

Generally speaking, I don't dislike the idea as you've proposed it.  It certainly solves some of the same issues we've been looking to solve with the proposed mechanisms.  If we look at BIMI as at least two basic goals:

1) Foster DMARC adoption by requiring the OrgDomain to be at enforcement (quarantine/reject)
2) Create a mechanism by which the brand owner can supply iconography for messages associated with messages that pass message authentication required to pass DMARC
3-ish) Craft a method by which trademarked imagery is not used in an infringing manner or by unauthorized entities

We probably could add 4-ish) Allow MUA to validate/display BIMI independent of Mailbox Provider.  

I believe your proposal is lacking on the first (or at least does not explicitly cover it)?  Perhaps this could be approximated by having the MUA perform DKIM validation and evaluate DMARC and perform alignment checks.  Or perhaps that was intentional (alluded to by "drop DNS requirements").   The proposal also seems to eliminate the web-bug concern, though may be traded for a "web-bug" from fetching keys to validate signatures.  Another advantage is that you could cache older keys and use those at a later time on older messages, barring some expiration.  However, if you change mail clients and those keys are no longer available, that could leave a gap (could we put a keystore in the IMAP system so that the user has access to all prior keys from any IMAP client?)

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: bimi <[e-mail]> On Behalf Of John C Klensin
> Sent: Wednesday, July 20, 2022 9:17 PM
> To: [e-mail]
> Subject: [Bimi] Alternate proposal
> 
> As promised in my recent "Radical critique" note, a suggestion about a
> completely different way to approach the BIMI problem, one that would be far
> less complex and problematic.  This is just an outline with many details left to be
> filled in -- my purpose in sending the note is to encourage people to think
> differently about the issues and see if there is interest in further discussion.
> 
> Overview:
> 
> Drop the idea of new mail header fields entirely.  With them, drop the (slightly
> odd) uses of mechanisms intended to validate mail senders, header field
> integrity, etc., the requirement for MUAs to be "Affiliated" with MBPs, and for
> Mailboxes or Mailbox Providers to be special in any way.  Also drop DNS
> dependencies connected with entirely different concepts.
> 
> Instead, define a new MIME content-type, presumably something like
> Application/BIMI.  If any trick supplemental information is needed, use
> parameters to the Content-type: header field.
> Probably that would give a typical message these day three body parts with
> content types respectively
>    BIMI
>    text/plain
>    text/html
> 
> If you really needed to, you could make BIMI multipart, but that would lose the
> advantages of the message looking perfectly reasonable to MUAs that were not
> BIMI-aware (see below).
> 
> Make it as complicated as it needs to be (but not worse), including providing for
> relevant parts of the content to be digitally signed.  From the discussions so far, I
> don't see any need for encryption, which makes things much less complex, but
> there is nothing in what I'm suggesting that would prevent it.
> MUAs who do not recognize the content type may generate warning messages
> to the user, but every MUA in the world with MIME support already has code for
> dealing with unrecognized content types.
> 
> An MUA that does want to handle the content type presumably
> installs appropriate application code.   Vendors who want to use
> BIMI could reasonably provide that code as a library or
> equivalent without getting involved with "affiliated".   And,
> then, that content-type specific MUA extension or add-on provides for
> downloading whatever special (i.e., specific to
> BIMI) certificates the user wants to have available.  My instinct at the moment
> would be to build validation on OpenPGP - most of the code that would be
> needed is readily available, many MUAs already have parts of it built-in, and so
> on.  Especially if encryption is not needed, this is perfect web of trust stuff, with
> the MUA client needing to install only those keys locally
> that it obtains from the MSP and trusts.   The certificates and
> keys would also be specific to BIMI, rather than shared with other applications,
> so things like expiration dates (and what to do with expired ones) could be per-
> MSP and tailored to the needs of BIMI, rather than compromises with the needs
> of other applications.
> 
> The MBP would not need to be special in any way.  And just exactly how to
> handle / display valid BIMIs would be a UI issue for the MUA, not more
> complexity that needed to be specified in the protocol.
> 
> Would something along those lines make any sense at all?
> 
> best,
>     john
> 
> --
> bimi mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bimi__;!!C
> Ql3mcHX2A!DSW_2M6Pp4LFJbEcg7702keyogYAc1OshmG_zEyXVwYvBfQiccBGA
> OaYOjmjjk8cOpQlROW6N_yao0enyCmaI5T3$