IETF Logo Mail Archive

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

Adrien de Croy <adrien@qbik.com> Mon, 20 February 2012 20:23 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 BC4AB21F8471 for <imap5@ietfa.amsl.com>; Mon, 20 Feb 2012 12:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.586
X-Spam-Level:
X-Spam-Status: No, score=-4.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, GB_I_LETTER=-2]
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 rFyTKwnxfuvS for <imap5@ietfa.amsl.com>; Mon, 20 Feb 2012 12:23:46 -0800 (PST)
Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9772821F87D6 for <imap5@ietf.org>; Mon, 20 Feb 2012 12:23:44 -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 <0018873543@smtp.qbik.com>; Tue, 21 Feb 2012 09:23:34 +1300
Message-ID: <4F42ABC1.2040507@qbik.com>
Date: Tue, 21 Feb 2012 09:23:29 +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: Tony Finch <dot@dotat.at>
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> <1329744434.16008.140661038859217@webmail.messagingengine.com> <alpine.LSU.2.00.1202201329130.31357@hermes-2.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.1202201329130.31357@hermes-2.csi.cam.ac.uk>
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: Mon, 20 Feb 2012 20:23:49 -0000

the main problem with MDNs, bounce messages etc is that the network 
doesn't know what they are.

This is WAY o-t now...

With TCP or UDP etc, if you have a delivery issue (certain types), you 
get an ICMP message back.

If there was a distinction between a control message and a data message, 
then the network could know things like how to not create loops.

It could also mean we could drop the requirement to allow submission of 
mail with NULL return paths, and instead use a non-destructive (in terms 
of information) method to notify issues which retained the addressing 
information.

It would need to be clearly defined, machine readable etc.  It could be 
stored and forwarded, and moved over the same transport.  It would just 
need to be unambiguously identifiable in all cases, which IMO would 
require another verb in the mail transport to mark it as a control 
message.  I don't think message format would cut it.

In terms of privacy etc, if you send a registered letter to someone, you 
know when it is received.  You're entitled to know this, and you don't 
hear complaints about it.  So I don't have a problem with the concept of 
allowing a sender to know when a message is retrieved.  I just turned 
off MDNs because the way they are implemented is problematic esp with spam.

Adrien


On 21/02/2012 2:30 a.m., Tony Finch wrote:
> Bron Gondwana<brong@fastmail.fm>  wrote:
>> It almost seems that a SENDMDN command is what is indicated for this
>> usage.  Again, the "client can't screw it up" philosophy.
> On the other hand, MDNs are an abusive misfeature that should be shunned.
>
> Tony.

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

v2.23.0 | Report a Bug | By Email