Subject: Re: [Extra] Is this a plausible IMAP extension ?

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 01 Mar 2019 14:48:55 -0800

Arnt Gulbrandsen writes:
> So why not let the sender supply the logo by marking a body part, and 
> then specifying when and whether to use it? Why must the logo be 
> marked/inserted/supplied after the DKIM signature?

How is this not just X-Logo, ala X-Face?  Neither are
trustworthy in any sense, so why bother pretending?

---

From: Ned Freed <[email-masked]>
Date: Fri, 01 Mar 2019 15:03:38 -0800 (PST)

> trustworthy in any sense, so why bother pretending?

It's different in that the logo, or reference to the logo, is covered by  the
message's DKIM signature. Which combined with DMARC tells you that the logo
displayed is bound to the From: domain.

The question is what value, if any, does that add. As I see it the big problem
is that nothing prevents goggle.com from signing a pointer to Google's logo.
Or a logo that looks very, very similar to Google's.

Until and unless BIMI offers a solution to this problem, I'm afraid I see very
little value here.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 3 Mar 2019 00:35:31 +0900

>Until and unless BIMI offers a solution to this problem, I'm afraid I see very

That's where we came in, the recipient MTA validates the logo, adds a
header pointing to the validated logo, and adds a magic IMAP flag to
say that it's done so.

I'm not saying that's a particularly good way to do it, but it's not
like they haven't thought about it.  There's also the mess of how in
the real world you determine whether the owner of a domain should be
using any particular logo.

R's,
John

PS: there's some urgency here since the big gorillas are showing
sender logos now and not doing a wonderful job of it.

---

From: Ned Freed <[email-masked]>
Date: Sat, 02 Mar 2019 08:55:52 -0800 (PST)

> header pointing to the validated logo, and adds a magic IMAP flag to

How is this validation performed? If the answer is the DKIM signature check,
that doesn't address the issue at hand in any way I can see.

> using any particular logo.

Precisely my point.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 3 Mar 2019 07:48:25 +0900

> that doesn't address the issue at hand in any way I can see.

They only show logos on mail that's DMARC aligned, but that just tells us 
that the domain on the From: header really sent the message.

They're trying to invent third party validation services to attest that 
logos A, B, and C can be used by domains X, Y, and Z, and then explain 
why that will work better than EV certificates.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ned Freed <[email-masked]>
Date: Sat, 02 Mar 2019 16:54:27 -0800 (PST)

> why that will work better than EV certificates.

Uh... Really, I have no words.

				Ned

---

From: "Robert Mueller" <[email-masked]>
Date: Mon, 04 Mar 2019 22:14:01 -0500

> why that will work better than EV certificates.

This seems to be a long term ongoing problem. Associating domains with real world entities so that systems or users can say "example.com is really associated with the company/brand XYZ corp that I know/trust in the real world".

This seems to require some sort of trusted authority/authorities to do the vetting process. On the surface, this doesn't seem a bad idea, but ends up with all sorts of problems. The real world is complex so you can end up with unexpected overlaps - https://stripe.ian.sh/ - which is I presume part of what caused EV certs to fall over.

(OT: is there any actual documentation anywhere on why all the browser makers appeared to move away from EV all at once significantly downplaying the UI?)

Is there any particular plan on how these third party validation services will work and avoid these sort of problems going forward? Is the idea just that they'll maintain a validated map of domain => logo(s), or will it be something more than that?

-- 
Rob Mueller
[email-masked]

---

From: Brandon Long <[email-masked]>
Date: Tue, 5 Mar 2019 16:38:58 -0800

Isn't this similar to AuthRes?  Ie, it was a header added by the MTA to
pass on information to the client.  The "validation" model was that header
was added with an srv_id and the MTA would remove any such header during
delivery so only the receivers one would survive.

That said, I have no idea how much utility clients have gotten out of
AuthRes, or how they determined which srvid was the correct one to trust.
Also, copying the message to a different provider would not really work to
keep that information unless the client had some weird heuristics to trust
the old srvid and the new one...

and of course the headers could be just included in the inbound arc message
signature, though that implies signing all inbound mail like Gmail does
when that's not otherwise strictly necessary.

I'm not clear on why the imap keyword is necessary here.  Unless you're
worried that someone can insert a message into your imap store, in which
case I would think you have a worse problem (is it typical for
anti-phishing to run on APPENDED messages?  Gmail would have some
protections, but certainly not the full stack, and mostly only for the web
ui)

Even the arc/dkim-like solution still has issues when moved to a new
provider, since again, the client would need to trust the signer, most
likely by relating it to the imap provider, so changing the provider breaks
that chain.  Unless the client has a whitelist of providers to trust
regardless of which provider you're using.

I have no useful comments on how to do the validation itself.

Brandon

On Sat, Mar 2, 2019 at 7:35 AM John Levine <[email-masked]> wrote:

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