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

Brandon Long <> Wed, 06 March 2019 00:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1355112F1AC for <>; Tue, 5 Mar 2019 16:39:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F8wWrpqVyUju for <>; Tue, 5 Mar 2019 16:39:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E73D21279E6 for <>; Tue, 5 Mar 2019 16:39:12 -0800 (PST)
Received: by with SMTP id y19so1181129vsc.4 for <>; Tue, 05 Mar 2019 16:39:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S7miROGQLRVGmVzAf1MYhD5fnxnz9N8obuhxRl1A1kc=; b=A3GAEwVM+05BV6/04wYx4flq28BgNdLfgnlb8o6QxbQhVWND/8v56F3qGZhQO5xOJ1 ZGuCLXlV+2owpKS1spXRxIT8a+h2ncWbj9a1kTtcNiPb61EushJs+aShr8gUxnWPsFNF dEsU+MS2qCLI87ksElY6KOEbJ0nXtRc+LkvVnfLiMIL/LMHIZ04cU1pQUNyY4SccCrbm hwqdrLRV21c3WxjwT6cYLw9TKW8T3zzPHwv2iXKkvjZzez1rS7Aeyt17eh53LXCrvCPS SEVbLkTNZ1IeOA/czE6jfgA1/DAlQlXgSuXDeKsEE2e3PsCDkeHFGCZN0ZWayxp1+ys2 VM/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S7miROGQLRVGmVzAf1MYhD5fnxnz9N8obuhxRl1A1kc=; b=ASgbWzQs0xZLu8xQE8FsJBj2pKyfo01bBGfZs9e3mVnGhmnJIJtiyg3FfmF40LUmjB 73KLhDGcWLH3a0qutRa2ebhmBnaXcds1wlA2HAuf8+VV6xxwk6mlQoNCpPXLTzX8bNsb zLulIVLgfbMVYgGNt1p8O6ff3p2edM3BiOpcohyzdiv84nwwRr07kYR/u21GqK6O/XW1 0/vijJguas4NFEufxbfS6wnVUmAnAlGRkvUoPBzmgqLspRQrRb8YHDD9zJ2X0NsElbVK x/rahPr9S+OqKsnVxJL007f1n7vP2O6rpXWDGsFRpbzLFJ2WY+rJeBBSkuGvPIT+0z6C /qYA==
X-Gm-Message-State: APjAAAWAUmbgcRD4h72+nSgaLvzmyZXt/bS5omzf06IMlMKFJr6XfSSh EDtDc59CA6H5l1ymxpIbEEMGJDas3eTkiSSHlvnP5xg=
X-Google-Smtp-Source: APXvYqyZiCvz/0J1T3krhnxO0FgeBsH8/B4PgP3AVsKdIOd4dWgvHL4h+HfOyf3ndPqrcBI7aBNIMh/M6p/auJqpDW8=
X-Received: by 2002:a67:ee86:: with SMTP id n6mr2609504vsp.92.1551832751388; Tue, 05 Mar 2019 16:39:11 -0800 (PST)
MIME-Version: 1.0
References: <> <20190302153532.86AEF200F83ABF@ary.local>
In-Reply-To: <20190302153532.86AEF200F83ABF@ary.local>
From: Brandon Long <>
Date: Tue, 5 Mar 2019 16:38:58 -0800
Message-ID: <>
To: John Levine <>
Cc:, Ned Freed <>
Content-Type: multipart/alternative; boundary="000000000000e631ed0583623790"
Archived-At: <>
Subject: Re: [Extra] Is this a plausible IMAP extension ?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Mar 2019 00:39:16 -0000

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

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.


On Sat, Mar 2, 2019 at 7:35 AM John Levine <> wrote:

> In article <> you write:
> >The question is what value, if any, does that add. As I see it the big
> problem
> >is that nothing prevents 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