Subject: [Bimi] Fwd: New Version Notification for draft-bkl-bimi-overview-00.txt

From: Seth Blank <[email-masked]>
Date: Mon, 11 Mar 2019 09:08:22 -0700

As requested by several people on this list, we've put together an
architectural overview of BIMI. This document specifically focuses on
options that were considered and the threats inherent in them.

This document should provide solid groundwork for the BoF discussion in
Prague.

We're looking forward to your comments.

Seth

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Mar 11, 2019 at 1:47 AM
Subject: New Version Notification for draft-bkl-bimi-overview-00.txt
To: Seth Blank <[email-masked]>, John Levine <[email-masked]>,
Neil Kumaran <[email-masked]>

A new version of I-D, draft-bkl-bimi-overview-00.txt
has been successfully submitted by John Levine and posted to the
IETF repository.

Name:           draft-bkl-bimi-overview
Revision:       00
Title:          An Overview of the Design of BIMI
Document date:  2019-03-11
Group:          Individual Submission
Pages:          19
URL:
https://www.ietf.org/internet-drafts/draft-bkl-bimi-overview-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bkl-bimi-overview/
Htmlized:       https://tools.ietf.org/html/draft-bkl-bimi-overview-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview

Abstract:
   Brand Indicators for Message Identification (BIMI) provides a
   mechanism for mail senders to publish a validated logotype that mail
   receivers can display with the senders' messages.  This document
   provides a brief overview of BIMI and examines some of the trade offs
   and decisions in its design.

Discussion venue

   Comments on this draft may be directed to the BIMI list at
   [email-masked].

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 

Seth Blank | Director, Industry Initiatives

e: [email-masked] |* p: *415-273-8818

<https://www.valimail.com/>

<https://twitter.com/valimail> <https://twitter.com/valimail>
<https://www.linkedin.com/company/valimail/>
<https://www.linkedin.com/company/valimail/>
<https://www.facebook.com/ValiMail-649042791951699>
<https://www.facebook.com/Valimail-649042791951699/>

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it.  If you are not an intended and authorized
recipient you are hereby notified any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful.  Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "Kurt Andersen (IETF)" <[email-masked]>
Date: Thu, 14 Mar 2019 14:05:59 -0700

A couple of minor comments while awaiting a more thorough discussion in the
IETF104 BoF:

In section 3, the opening sentence refers to benefits for senders and
recipients. I think it should also identify that there are potential
benefits to receivers and operators of MUAs too.

In section 3.1, there is a reference to "changes the secret handshake". I
think that the point of having a public standard is that the crucial change
is to make is a non-secret handshake. I appreciate that this is qualified
with "if implemented poorly", but that should perhaps be changed to "if
specified poorly (or obscurely)".

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Fri, 15 Mar 2019 09:09:32 -0700

> benefits to receivers and operators of MUAs too.

Excellent point.

> specified poorly (or obscurely)".

Do the current drafts present a framework that clears the bar? Opinions
differ, but there's a reasonable argument that the bar is still only
clearable if you're a large US/EU organization, and the goal of being
approachable to all domain owners has not yet been met. This is a crucial
question for the BoF.

Seth

---

From: "John Levine" <[email-masked]>
Date: 17 Mar 2019 17:14:16 -0400

>> benefits to receivers and operators of MUAs too.

I would want to see more than speculation there.  As Dave Crocker
often reminds us, human factor research has made it clear that most
humans are completely unable to do anything useful with security
indicators.  That's one of the reasons that browsers aren't showing EV
cert indicators any more, and have made it a lot harder to click
through invalid cert warnings.

I'm not aware of any research specifically about indicators on mail
messages.  Perhaps that would be a good place to toss some money at
academic researchers.

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Sun, 17 Mar 2019 14:23:46 -0700

On Sun, Mar 17, 2019 at 2:14 PM John Levine <[email-masked]> wrote:

> I would want to see more than speculation there.

BIMI is about standardizing logo discovery, making a currently siloed
process approachable to domain owners and smaller receivers.

This is the value I believe Kurt was alluding to (for receivers and thick
mail clients) - nothing at all about the user impact, for the exact reasons
you outlined.

Seth

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 18 Mar 2019 06:55:55 -0700

Benefits to receiver/operators are clear: no more roll your own logo
scraping systems are needed.

Benefits elsewhere are less clear even though you called them in the doc.

--Kurt

On Sun, Mar 17, 2019, 14:14 John Levine <[email-masked]> wrote:

> bimi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bimi
>