Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

Adrien de Croy <adrien@qbik.com> Mon, 20 February 2012 19:50 UTC

Return-Path: <adrien@qbik.com>
X-Original-To: imap5@ietfa.amsl.com
Delivered-To: imap5@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6557721F8648 for <imap5@ietfa.amsl.com>; Mon, 20 Feb 2012 11:50:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.639
X-Spam-Level:
X-Spam-Status: No, score=-3.639 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+BkRPh+E1+s for <imap5@ietfa.amsl.com>; Mon, 20 Feb 2012 11:50:44 -0800 (PST)
Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 042FD21F8595 for <imap5@ietf.org>; Mon, 20 Feb 2012 11:50:43 -0800 (PST)
Received: From [192.168.1.10] (unverified [125.237.241.8]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3384)) with SMTP id <0018873503@smtp.qbik.com>; Tue, 21 Feb 2012 08:50:39 +1300
Message-ID: <4F42A410.2070409@qbik.com>
Date: Tue, 21 Feb 2012 08:50:40 +1300
From: Adrien de Croy <adrien@qbik.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120216 Thunderbird/11.0
MIME-Version: 1.0
To: Bron Gondwana <brong@fastmail.fm>
References: <alpine.LSU.2.00.1202161626400.30682@hermes-2.csi.cam.ac.uk><4F3D6E57.8010301@qbik.com><alpine.LSU.2.00.1202171127330.30682@hermes-2.csi.cam.ac.uk><4F3F4F8F.3040601@qbik.com><1329550573.30138.140661038121885@webmail.messagingengine.com><alpine.LSU.2.00.1202191832430.12769@hermes-2.csi.cam.ac.uk><20120219192604.GA11323@launde.brong.net><4F415C07.3040100@qbik.com><20120219220835.GB12549@launde.brong.net><4F417EF5.6030809@qbik.com><20120219233901.GA13600@launde.brong.net><4F41952B.8020809@qbik.com><1329738117.22774.140661038826265@webmail.messagingengine.com><4F423CE4.5060103@qbik.com> <CAD8HnzwaaHjPTwsze0ACOTgPdEUgyrJZ62CDyasxE0eKd8rDcA@mail.gmail.com> <1329743631.12698.140661038857849@webmail.messagingengine.com>
In-Reply-To: <1329743631.12698.140661038857849@webmail.messagingengine.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>
Subject: Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP
X-BeenThere: imap5@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion on drastically slimming-down IMAP." <imap5.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imap5>, <mailto:imap5-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imap5>
List-Post: <mailto:imap5@ietf.org>
List-Help: <mailto:imap5-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2012 19:50:45 -0000

you're correct.

But just because the current way is inefficient doesn't mean we should 
replace it with an equally inefficient method.

I'd rather do something better.

Allow the client to instruct the server to refer to the message in sent 
items, and add some meta data about its delivery envelope(s)

Adrien

On 21/02/2012 2:13 a.m., Bron Gondwana wrote:
> On Mon, Feb 20, 2012, at 01:43 PM, Filip Navara wrote:
>> JYFI, we (eM Client, www.emclient.com) do use BURL in some cases.
>>
>> F.
> How do you handle BCC?
>
>> On Mon, Feb 20, 2012 at 1:30 PM, Adrien de Croy<adrien@qbik.com>  wrote:
>>
>>> We didn't implement BURL (HURL).
>>>
>>> It was just too far over the insanity horizon to write an IMAP client for
>>> that purpose.
>>>
>>> Especially since I don't know of a single client that uses it.
>>>
>>> So the MUA takes care of BCC in sent items, when it uploads the file there
>>> after sending with SMTP.
> So in other words, requiring the IMAP5 server to strip BCC when sending to
> the MTA would cause no more IO or CPU usage than what is currently required
> to do two separate uploads, one via SMTP and one to the Sent folder.
>
> Which has been my point all along.  This is making the server do what the
> client would be doing anyway - doing it in one place rather than many -
> purely for the case of a user-facing IMAP client.
>
> Bron.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com