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

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 <johnl@taugh.com> wrote:

> In article <01R3SIVTJAOS00004L@mauve.mrochek.com> you write:
> >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.
>
> 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.
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra
>