IETF Logo Mail Archive

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

Bron Gondwana <brong@fastmail.fm> Sat, 18 February 2012 07:36 UTC

Return-Path: <brong@fastmail.fm>
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 AE20E21F86FE for <imap5@ietfa.amsl.com>; Fri, 17 Feb 2012 23:36:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.421
X-Spam-Level:
X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 bsZW72csWG+a for <imap5@ietfa.amsl.com>; Fri, 17 Feb 2012 23:36:19 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id D83A921F86FA for <imap5@ietf.org>; Fri, 17 Feb 2012 23:36:19 -0800 (PST)
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 37F4D20FF9 for <imap5@ietf.org>; Sat, 18 Feb 2012 02:36:14 -0500 (EST)
Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute1.internal (MEProxy); Sat, 18 Feb 2012 02:36:14 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=mesmtp; bh= e/1CBVS5pucBfaag1m4J02x58MM=; b=lumgxAJ2aJKMOF1RLodUwvkig75EW+XO rYpF6oeGBgSnT1Ewb4nkRZ5czf+P1CuvlJv6nVQePgs4zbsLzgv80TmJErLNhdWT VHqpbuo4uOehoJp73382czfvDGL6f0U/nSbsSvhxhyGE6p/d1QwIQvdX6fP2gMG+ ihCgJLOgOhA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:references:subject :in-reply-to:date; s=smtpout; bh=e/1CBVS5pucBfaag1m4J02x58MM=; b= gftCi/pMOlEGIetahh2oTNcZrmlFqh2waFwLRYNMNL5LhjTSh27jTmmgPfulM9K4 OclH0DErg0M7L9Zem5UY7y3OcnnYlXgq/ERzyUOWoNcWxIsLed27dQQ2GioGJCNc fHQ5cx4JCORdjKChBixSW0vRdL406zysyt8p1EDz8cM=
Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 0711B400A5; Sat, 18 Feb 2012 02:36:13 -0500 (EST)
Message-Id: <1329550573.30138.140661038121885@webmail.messagingengine.com>
X-Sasl-Enc: Ecb0r5Fw3ZAAQUrH1Db8+aIk6X3WVUzIIJxVWyeJNrM1 1329550573
From: Bron Gondwana <brong@fastmail.fm>
To: Adrien de Croy <adrien@qbik.com>, Tony Finch <dot@dotat.at>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Mailer: MessagingEngine.com Webmail Interface
References: <B764BD8C8B6047E659EABBE2@caldav.corp.apple.com><20120213210805.GB13029@launde.brong.net><alpine.LSU.2.00.1202151405550.30682@hermes-2.csi.cam.ac.uk><1329315552.1444.140661036879893@webmail.messagingengine.com><4F3BBFA4.8010107@isode.com><1329316981.8310.140661036883625@webmail.messagingengine.com><4F3BC7DA.5070803@gulbrandsen.priv.no><20120215181047.GB13906@launde.brong.net><alpine.OSX.2.00.1202151020140.38441@hsinghsing.panda.com><20120215213122.GB16253@launde.brong.net><4F3C2C1B.6030408@qbik.com> <4F3CCA6C.3020004@qbik.com><3077.1329386263.642278@puncture> <4F3CD728.3010203@qbik.com><3077.1329388899.383165@puncture> <4F3CE16B.3060603@qbik.com><3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <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>
In-Reply-To: <4F3F4F8F.3040601@qbik.com>
Date: Sat, 18 Feb 2012 08:36:13 +0100
Cc: "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
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: Sat, 18 Feb 2012 07:36:20 -0000

On Sat, Feb 18, 2012, at 08:13 PM, Adrien de Croy wrote:
> 
> AFAIR Bcc should never hit the wire.  That's how it can be "blind" 
> carbon copy.
> 
> Otherwise you rely on a server to strip it.

I entirely disagree.  I was thinking quite a bit about the "upload to
the IMAP server and then send it via SMTP while telling it who to
send to", and I actually don't like it.

Certainly in the XSENT I implemented, once it has sent, it sets an
\XSent flag on the immutable message.  Not an \XSent-to-one-address.

The message with an \XSent flag is a record that it was sent to the
addresses listed in that header.

And the copy that went "over the wire" up to the IMAP server is your
record of what you did.  That _should_ include the BCC, so you can go
back later and check who you sent it to.  Obviously, the BCC should
be stripped as it gets handed over to the delivery agent.

Bron.
-- 
  Bron Gondwana
  brong@fastmail.fm

v2.23.0 | Report a Bug | By Email