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

"Bron Gondwana" <brong@fastmailteam.com> Wed, 27 February 2019 04:17 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B55130E11 for <extra@ietfa.amsl.com>; Tue, 26 Feb 2019 20:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.982
X-Spam-Level:
X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=GFSVrA3c; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=v/U/JzCs
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eYzz2WlASLB for <extra@ietfa.amsl.com>; Tue, 26 Feb 2019 20:17:11 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6EC130DEC for <extra@ietf.org>; Tue, 26 Feb 2019 20:17:11 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A1C9D21F24 for <extra@ietf.org>; Tue, 26 Feb 2019 23:17:10 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 26 Feb 2019 23:17:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm2; bh=JP58rQj/osA0KAiCFTeMR/qbRxDK BpOkMCxzcqGNxSY=; b=GFSVrA3cHxYyxuMy93F8fMIWQQwFZ/aNRzTb1KCoQRqO c2AONcXuxqvrAlX3WarogTbABOv2LRUNLqfD1KUr9h5gtm0tgFPjVxuUJ3lTXRLh mcUQphpOfVZ7G5hABPUmSUEX7o0T8g2ToP2g4crSTQu1VTtDUJjULGtVLrd7uula riJEMagA3hPVer3YSr2+MSYxV5Oz/yP8cVy/7M3WRRUS5VDo7CkVQLW5eV7jY/9k GcpSj4+6HC5IIqs4hlirSm87GCv8xv/+IXBa9RqasUQWH+2zMDR5CH8X+Uka8t9Q 7m5mcbYDhiQUz+IbPXchOePZYht1EZMOp82lguCcig==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=JP58rQj/osA0KAiCF TeMR/qbRxDKBpOkMCxzcqGNxSY=; b=v/U/JzCs61I+4FkY5RVmwXbAg1bBJEwr5 nOfgfhNdiRIDD1eU7ahI3M5tBjGk1dLnJLan5v+NRUoF5bE+YRV3CnA1D8yC5/+Y xvObzigfgmDTzePrsn79CWLOONN//E89Aa9pf6YDl1iZLV8UdsvM6YXWA2hsWoop 10bu2VHvGelSKnJmQCa8zsHmZkITUVln0GUxfyMpmYM7oS1SSFJUltLtEMvLntgD q+NKBQn7ibmuSGLbr085Mf2PfNw3/mB4T46ccw7qaUn3lyXc9zHzLwMK6N73Li3P ovC9KTM4bLUWGKylS9tMbIWtwdBf57DLXow1wm7k7Vlk4M0GTtYig==
X-ME-Sender: <xms:Rg92XIyO1U0DFQ5BWm44Cb1sL8IMQk2W-zTNou-lVs07QICgI1PwyA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrvddtgdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepjhhlrdhlhidpihgvthhfrd horhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhht vggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:Rg92XNyjsFjBpO3k7mf1iWsv8GoIZ1h7u_7e1kETGfYYRJl0T0qyKQ> <xmx:Rg92XKYpU4KvmbLzteUgXhpe9mez7VNeY9AiHlqSJl56gSq1i8bqLw> <xmx:Rg92XGU52JHczw5GNG1DLsfyQdF2ITfRMvAWq-NaITpsaY7EDerQLw> <xmx:Rg92XIOJ-VIbdVBjadp4CCYPYDErg32GPoBlqJ_VtZKRS-sUMF8D-w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 137222031D; Tue, 26 Feb 2019 23:17:10 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-918-g4e3ba4c-fmstable-20190227v1
X-Me-Personality: 56629417
Message-Id: <af25a165-ff24-41d4-810e-b00adf2092d5@beta.fastmail.com>
In-Reply-To: <alpine.OSX.2.21.1902262150050.14048@ary.local>
References: <alpine.OSX.2.21.1902262150050.14048@ary.local>
Date: Tue, 26 Feb 2019 23:17:09 -0500
From: "Bron Gondwana" <brong@fastmailteam.com>
To: extra@ietf.org
Content-Type: multipart/alternative; boundary=fe2a7c1159364a55bc5023406de1a65e
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/ViErNaDB0EADmMhE7irIDqZr2zI>
Subject: Re: [Extra] Is this a plausible IMAP extension ?
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 04:17:14 -0000

This isn't a standard feature on any IMAP server I'm aware of.

I can see how to implement it in Cyrus IMAPd. Add a custom numbered ACL to control a set of listed flags, and allow the delivery agent to have that ACL.

On the other hand...

We do something like this already at FastMail, and here's the thing.... the user should be allowed to add or clear this header to change the interpretation of the email in their mailbox. Once they have the message - they should be able to update the BIMI status.

This is particularly important when you're talking about importing and exporting email between systems. Having the flag to avoid phishing, sure. But restricting MUAs from setting that flag - that's bogus.

I guess I'm going to the BIMI session.

Bron.

On Wed, Feb 27, 2019, at 14:06, John R. Levine wrote:
> There is this thing called BIMI that is being debated elsewhere in the 
> IETF. Leaving aside for the moment the issue of whether it's a good idea 
> in the first place, it invents an IMAP feature that seems dodgy to me.
> 
> When an MTA that supports BIMI delivers a message into the mailstore, it 
> adds a header that tells MUAs where to find a logo to show next to the 
> message. (Think of it as x-face for corporations.) Since bad people 
> could phish victims with their own header with a misleading image, BIMI 
> invents a new IMAP flag that only the delivery MTA can set on messages 
> where it has added a virtuous header. An MUA can test it to decide 
> whether to show the logo. Other IMAP or POP clients can't set the flag, 
> but it presumably stays with the message if it's moved from one folder to 
> another.
> 
> Does existing IMAP software have this kind of privileged flag? Is it 
> something that would be reasonable to implement, e.g., is there already a 
> concept of users at different privilege levels manipulating the same mail 
> store beyond just R/W and R/O? The IMAP software I use is Dovecot, where 
> in the vast amount of badly organized documentation I don't see anything 
> like this, but maybe it's hiding and I don't know where to look.
> 
> Advice from actual IMAP experts welcome.
> 
> Regards,
> John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
> 
> PS: If as I suspect this is unlikely to be implementable, I have an 
> alternate approach that involves misusing DKIM.
> 
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra
> 

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 brong@fastmailteam.com