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

Adrien de Croy <adrien@qbik.com> Sun, 19 February 2012 20:31 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 3D81A21F84C3 for <imap5@ietfa.amsl.com>; Sun, 19 Feb 2012 12:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.722
X-Spam-Level:
X-Spam-Status: No, score=-3.722 tagged_above=-999 required=5 tests=[AWL=-1.123, 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 sLu0StehVWFp for <imap5@ietfa.amsl.com>; Sun, 19 Feb 2012 12:31:28 -0800 (PST)
Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 03F9221F84DD for <imap5@ietf.org>; Sun, 19 Feb 2012 12:31:21 -0800 (PST)
Received: From sago.qbik.com (unverified [192.168.0.3]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018871876@smtp.qbik.com>; Mon, 20 Feb 2012 09:31:18 +1300
Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.3] (WinGate SMTP Receiver v7.0.8 (Build 3364)) with SMTP id <0010061819@sago.qbik.com>; Mon, 20 Feb 2012 09:31:03 +1300
Message-ID: <4F415C07.3040100@qbik.com>
Date: Mon, 20 Feb 2012 09:31:03 +1300
From: Adrien de Croy <adrien@qbik.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0
MIME-Version: 1.0
To: Bron Gondwana <brong@fastmail.fm>
References: <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> <1329550573.30138.140661038121885@webmail.messagingengine.com> <alpine.LSU.2.00.1202191832430.12769@hermes-2.csi.cam.ac.uk> <20120219192604.GA11323@launde.brong.net>
In-Reply-To: <20120219192604.GA11323@launde.brong.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Sun, 19 Feb 2012 20:31:29 -0000

not everyone is on sendmail

we're talking about adding 2 parameters, a return path and forward 
path.    Hardly complex.

this allows us to
- not have to parse the headers
- not have to re-write the entire message when stripping bcc

these things are not cheap.  they will affect service capacity.

Why would you incur such penalty simply to avoid transmission of a 
couple of parameters?

It's trivially simple for an MUA to supply this information when it 
wants to send the message.

There's no reason to assume this information would be lost either.  It's 
up to the server how to record such things and make them visible.  
Whether that's in the sent items folder or something associated with the 
message.

Distinction between envelope and content is a key principle of SMTP.  
One could argue it's also a cause of certain issues, but I don't think 
it should be discarded without some fairly serious thought.

Adrien


On 20/02/2012 8:26 a.m., Bron Gondwana wrote:
> On Sun, Feb 19, 2012 at 06:34:13PM +0000, Tony Finch wrote:
>> Bron Gondwana<brong@fastmail.fm>  wrote:
>>> 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.
>> Right. That last bit (creating the message envelope from the
>> From/To/CC/BCC headers and stripping BCC) is explained in RFC 5321,
>> and it's what sendmail -t does.
> I've seen the argument of "what if you want to forward a copy on to
> someone else for inspection, whatever" - without forming a new copy
> of the message.  That's actually really hard to do in the current
> universe, because the headers will make it look extra spammy.  You're
> much better off forming a new message.  Also, storage space for
> "Sent Items" is almost always cheap.  The record of who you sent it
> to is almost always useful.  All that's really missing is a way to
> form a "new" message from an "old" message without necessarily
> downloading everything first - but that's what the Lemonade CATENATE
> stuff was for.  Build a new message, potentially including the old
> one as a message/rfc822 attachment, and then send that.
>
> Again, I really think it's the rare case.  I'd rather not complicate
> message sending (and knowing which recipients had the message sent
> to them) for this case.  There will still be SMTP.  Most clients
> don't provide it for good reason - it's weird, advanced,
> non-intuative stuff.  Do Exchange or Facebook provide such interfaces?
>
> I get a feeling that protocol designers tend to be people who are
> paranoid about all the edge cases, which is good, but then wind up
> optimising rare edge cases at the expense of being able to do the
> normal operations easily - which is bad.  I don't want to optimise
> for "I want to bounce this message untouched to a new recipient
> without changing the sender", which is almost always a spam scanning
> nightmare anyway, at the expense of "the \XSent flag means that it
> was sent to the recipients named in the message, nothing more,
> nothing less".
>
> Bron.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/