From brong@fastmail.fm Wed Feb 8 12:15:31 2012 Return-Path: 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 C1A8D11E80A0 for ; Wed, 8 Feb 2012 12:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 jt72kzgWgVXd for ; Wed, 8 Feb 2012 12:15:30 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7086011E809B for ; Wed, 8 Feb 2012 12:15:27 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6506921311 for ; Wed, 8 Feb 2012 15:15:26 -0500 (EST) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute5.internal (MEProxy); Wed, 08 Feb 2012 15:15:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date; s=mesmtp; bh=GeNe1ttnOq1n/NloKRSQGsm anwc=; b=ost2Ay/p0TnBqefBy2OARnPGZgJHIoX2NqHOer1xhDpmw9UkDM1kcMa YPckh5iwS/0gxaXPfISkkAiZoscPbGkEIlQvn7IIEnbTUNwk69N+xxQWSU+DyFF1 Cyi/t/PuQi+BlDGyCARq6NupzdTjMFhhMfeWL2gwOf4ODhDxGfdg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=GeNe1ttnOq1n/NloKRSQGsmanwc=; b=NmbsgWtFf4UkQfk4eEij5HzSuZ1E nd/CkVAAY0z89BoHOKgeDfa/HNSG+Yy5zswK081cRGPjwb5ve7uE0KQfXocOXf7f q3Hisk6nASGegsHhfoFv3AD06szR46U/7lKnEig/9wHgoj+J7GzksWbiayNX8iSI o6rsswnmF3al8nE= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 3E653400E0; Wed, 8 Feb 2012 15:15:26 -0500 (EST) Message-Id: <1328732126.32086.140661033971485@webmail.messagingengine.com> X-Sasl-Enc: CzgA3IIG77nbd4ZYPwvK6TfQVTbMqJS2ZNj6rq9hgZVQ 1328732126 From: Bron Gondwana To: IMAP Protocol Interest List , "Discussion on drastically slimming-down IMAP." , ietf-imapext@imc.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface Date: Wed, 08 Feb 2012 21:15:26 +0100 Subject: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:15:31 -0000 I've given up on the IMAP5 mailing list going endlessly around in circles, though I'm definitely going to read through the backlogs and remind myself again what everyone spoke about, because there was some excellent discussion. So - I will build something and prove that it's good by showing improved user experiences. And I'm happy to keep talking here on these mailing lists too. I've started a wiki page: http://imapwiki.org/ReplacementProtocol and plan to blog about what I'm doing on our own (Opera's) blogging platform, to practice using it: http://my.opera.com/brongondwana/blog/ I plan to make on a protocol which can replace IMAP in most of its current uses. I want to get (at least) two working server implementations, and two working clients. I have at least in-principle support from enough project maintainers to do that. My strong philosophical ideals are: * Simple to build clients - morons welcome. If it's not clear the right way to do something to someone just reading a protocol dump, we haven't done a good enough job. We can't expect you to read 30 RFCs and resolve their conflicts yourself before starting coding, and we won't insult you if you didn't get it right. Where there is necessary complexity, the server authors bear the brunt. * Server side data model compatible with IMAP4 + extensions; we need to be able to co-exist. * Handle disconnection more gracefully - able to cheaply resync state (I plan to reuse the QRESYNC/CONDSTORE logic here - the model is sane). Getting reliable updates on mailbox state changes should not require a continuous connection. * Easy to proxy - regular syntax (UTF-8 for all communications where possible, but won't screw about trying to "fix" MIME - message file format will remain unchanged) * NO MAGIC - everything is explicitly requested. No UNSELECT/CLOSE/ SELECT another mailbox special behaviours, no implicit FETCH + SET \Seen, no pre-calculated "UNSEEN X" that wasn't asked for. (This probably means some way to compose actions and fetches, but it's better than being complex and magical. Remember our friends the morons.) * COMPLETE TEST SUITE that exercises every constraint in the spec, both positive and negative constraints. An implementation which passes the tests is compliant. An implementation which doesn't is not. This is much more likely to produce inter-operable implementations than a wordy spec ... ... if the authors want inter-operability that is. Nothing can protect against a deliberate embrace and extend - though negative constraint tests (MUST NOT) should help. I would love input. I spent most of the time at FOSDEM this year talking to other people involved in email about these ideas. I quite like the mailbox model behind IMAP, but I want to address the pain points I have seen so many times over the years. Snide comments from those who don't agree with the goals are welcome too... I just won't listen to you. These goals are very important to me. Regards, Bron. -- Bron Gondwana brong@fastmail.fm From thomas@koch.ro Wed Feb 8 23:20:41 2012 Return-Path: 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 0FDFA21F85B4 for ; Wed, 8 Feb 2012 23:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_RO=1.235, HELO_IS_SMALL6=0.556, HOST_EQ_RO=0.904] 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 5K82RZUqsgss for ; Wed, 8 Feb 2012 23:20:39 -0800 (PST) Received: from koch.ro (koch.ro [88.198.2.104]) by ietfa.amsl.com (Postfix) with ESMTP id BC1A321F853A for ; Wed, 8 Feb 2012 23:20:39 -0800 (PST) Received: from 43-172.77-83.cust.bluewin.ch ([83.77.172.43] helo=t61.localnet) by koch.ro with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RvOJ3-0002cX-0q; Thu, 09 Feb 2012 08:20:37 +0100 From: Thomas Koch To: imap5@ietf.org Date: Thu, 9 Feb 2012 08:20:27 +0100 User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; ) References: <1328732126.32086.140661033971485@webmail.messagingengine.com> In-Reply-To: <1328732126.32086.140661033971485@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201202090820.28260.thomas@koch.ro> Cc: ietf-imapext@imc.org, IMAP Protocol Interest List Subject: Re: [imap5] Designing a new replacement protocol for IMAP X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: thomas@koch.ro List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 07:20:41 -0000 Bron Gondwana: > Snide comments from those who don't agree with the goals are welcome too... > I just won't listen to you. These goals are very important to me. Hi Bron, I'm not an expert in IMAP, just got here out of curiosity about Kolab[1]'s use of IMAP folders as data stores. I found some older initiatives to replace IMAP with an HTTP based approach.[2] What do you think of HTTP for mail access? For my bachelor thesis[3] I currently argue that CardDAV/CalDAV could be perfectly replaced by AtomPub (RFC 5023). The main advantage would be that most software developers on this planet have some vague understanding of HTTP and that imense infrastructure and software already exists. [1] http://wiki.kolab.org/Why_IMAP_Is_Used_For_Storage [2] http://www.prescod.net/rest/restmail/ https://www.ietf.org/mailman/listinfo/httpmail [3] https://github.com/thkoch2001/bachelor-thesis Best regards, Thomas Koch, http://www.koch.ro From brong@fastmail.fm Thu Feb 9 03:24:15 2012 Return-Path: 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 58B1C21F8667 for ; Thu, 9 Feb 2012 03:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 Ka1GTJBxgjr7 for ; Thu, 9 Feb 2012 03:24:14 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 728AF21F85F8 for ; Thu, 9 Feb 2012 03:24:14 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5288421021 for ; Thu, 9 Feb 2012 06:24:13 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 09 Feb 2012 06:24:13 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=eyPXuJRWfA3AXuiX2tZFA2H0 IS0=; b=bUbkW2yF0fyEFxTkMD/plKdAWJ2qG6A4e84VHJaStPeYC9hMWNQOhSs7 0DM6BDPU3BqoSlX7Dt2R/nnveC3/OuvHB7IFjxDLI9XcA5cCdgIvb/z3ilRX437t CqqaQirhtWqoR27sY1nq35CLs2d9zy7sFVnJPMmepQlY4iSRLgo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=eyPXuJRWfA3AXuiX2tZFA2H0IS0=; b=W+Y72hA1zXC5iq/s3oZjJfy4gyaJ Sl0F3ZfeHDTb3uXhX3Yz14grU5MBuGlN6TsoB5N0slVzpdmk3WH6KAY2ve+BEJ9G 55sBIszGJji853jHfyzwQAmZv5elgOVW17rMfDLLKSA0szaez5aSFFKfFUBsvn4J K5jed5OPxBfmyPc= X-Sasl-enc: DRLqcQnkDZ/s9vPvcFYXo6cyO3ntFszOGgVzj6jfL1Pj 1328786653 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 07DA9483525; Thu, 9 Feb 2012 06:24:13 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 4D35819BF04; Thu, 9 Feb 2012 12:24:11 +0100 (CET) Date: Thu, 9 Feb 2012 12:24:11 +0100 From: Bron Gondwana To: Adrien de Croy Message-ID: <20120209112411.GB29734@launde.brong.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F337E61.5040702@qbik.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ietf-imapext@imc.org, imap5@ietf.org, IMAP Protocol Interest List Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 11:24:15 -0000 On Thu, Feb 09, 2012 at 09:05:53PM +1300, Adrien de Croy wrote: > > Whilst HTTP could certainly be used to put together an email system, > I don't think it would perform well enough to replace existing > protocols on desktops. > > The main issues I see are: > > * updates. Would need to poll or use long polling to get real-time > updates (e.g. notification of incoming mail). Yes - long polling or "out of band" notification systems. We have an HTTP protocol defined kind of "on top of" IMAP plus our own extensions here at FastMail/Opera (mail.opera.com if you want to play with it) We are currently using EventSource to notify the client that "there is something new", after which the client queries to find what's updated. This is possible to be efficient because we use a single counter for uidvalidity and a single counter for highestmodseq across the entire user's folders - so any change to uidvalidity means the folder list needs refreshing, and any change to highestmodseq means the message view needs checking. Combined with efficient "what's changed in this view since my previous modseq value" queries, it's very bandwidth efficient. > * slow. Gut feel based on 17 years writing http proxies is that it > would be too slow Not really actually - so long as you can query multiple things in a single "transaction" > * complex. In order to reduce round-trips, you'd have to do many > things in a single transaction, which would create complexity issues > in the server and client But here's the rub. Yes, complex. > * protocol bloat. if you think IMAP is bloated, try HTTP. > * fundamentally an off-line style protocol for mail, which has > strong incentives to be online (esp for in-office use). Mostly facebook's "live feed" is plenty fast enough. People are doing all sorts of close-enough-to-real-time stuff on top of HTTP. It doesn't mean it's the right choice, but I wouldn't dismiss it out of hand either. > I think it would also be very problematic in the wild, since any > http intermediary would feel entitled to mess with traffic. E.g. > heuristic caching, intercepting proxies etc. That's a problem for sure. Mind you, proxyability is high on my list of goals. Immutable stuff should be cachable. > It's almost too ubiquitous. Everyone and their dog thinks they know > how http works. It's not strictly-enough defined, and has a LOT of > optional features which aren't relevant for mail (e.g. content > negotiation). Interop in http is already problematic, but start > getting people writing mail servers in php etc, and see what starts > to happen. I think it would be a nightmare. Like IMAP then, except only their dogs actually understand it ;) Good enough tests should, in theory, allow people to write their servers in PHP if they want to. Why you would choose to write in PHP, I'm not sure... but still. It takes all types. Bron. From giovanni@panozzo.it Thu Feb 9 03:25:35 2012 Return-Path: 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 CF6C221F86F2 for ; Thu, 9 Feb 2012 03:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 FobNKPf3CjwR for ; Thu, 9 Feb 2012 03:25:35 -0800 (PST) Received: from do2.yuu.it (do2.yuu.it [46.37.9.250]) by ietfa.amsl.com (Postfix) with ESMTP id 325B921F86AB for ; Thu, 9 Feb 2012 03:25:35 -0800 (PST) Received: from [192.168.98.218] (host213-176-static.106-82-b.business.telecomitalia.it [82.106.176.213]) by do2.yuu.it (Postfix) with ESMTPSA id E88D380495; Thu, 9 Feb 2012 12:25:26 +0100 (CET) Message-ID: <4F33AD2D.7050904@panozzo.it> Date: Thu, 09 Feb 2012 12:25:33 +0100 From: Giovanni Panozzo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: imap5@ietf.org References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> In-Reply-To: <201202090820.28260.thomas@koch.ro> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org, imap-protocol@u.washington.edu Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 11:25:35 -0000 > I found some older initiatives to replace IMAP with an HTTP based approach.[2] > What do you think of HTTP for mail access? For my bachelor thesis[3] I > currently argue that CardDAV/CalDAV could be perfectly replaced by AtomPub > (RFC 5023). > The main advantage would be that most software developers on this planet have > some vague understanding of HTTP and that imense infrastructure and software > already exists. Hi Bron, hi Thomas. I'm happy to see this interesting traffic on the ML. Just a small note: these two post are full of "programmer point of view" considerations and philosophical ideals. That's good. But I'm mostly "system integrator", involved also with end-user helpdesk. I'm a programmer also, but only form 2% of my time, so I'm not a "professional programmer". I would like to contribute with other key points useful both to system integrators, helpdesk and end user (moron end user) ease to use (I have a long list... do you want it ? :)) Here are my first notes about HTTP: I think HTTP is welcome. Many mobile phone carriers do offer only http/https connectivity, sometimes filtered by a transparent proxy too. In some enterprise LANs, users are forced to use an http proxy with proxy authentication to access the Internet. No other protocols are allowed. HTTP would allow all these users to access their e-mail without requiring impossible access upgrades. And HTTP completed with digest authentication and email body encryption also will also help sysadmins to have more security without incurring into the SSL certificate infrastructure pains. Http is also "stateless" from its birth: the advantage is that we can better serve clients with intermittent connections (point 3 in Bron's list), like mobile phones or poorly connected wifi laptops. Giovanni PS: I think that crossposting in 3 ML is too much. Which one will be the official ML for this discussion ? From brong@fastmail.fm Thu Feb 9 03:32:21 2012 Return-Path: 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 D439221F8466 for ; Thu, 9 Feb 2012 03:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 V0Wli9m2lTPM for ; Thu, 9 Feb 2012 03:32:21 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5C89E21F86EE for ; Thu, 9 Feb 2012 03:32:10 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0683E209A8 for ; Thu, 9 Feb 2012 06:32:10 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 09 Feb 2012 06:32:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=wPCn9RtD+I2RGzRY5ggh/VUe mtU=; b=Gbr3CvUxKMNaThkEvyic5Oq5+9OcqBQcSlwN37QLthMcsBeG3p+iPHTk QJDgK6n8ioJ5n80LOntvgVBKDbqkvkXFWmFSPsKW2fk0GOqU78Jnl1XgH9MW3biV 2zPn2VFN9PZ1SbmGXPFjOOJLMHAZNJ7gFPR5OZdhaSJnPwO73ec= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=wPCn9RtD+I2RGzRY5ggh/VUemtU=; b=AmuL2A2HKAkyqSjv4v9gqaDqkqI/ knnqmOnIzrzbmHyd7JVeks6wdkL73KodYdunG43A+Gmin2r0BO84+ozqfmu6Y1D8 KiC+VOrF/29YminiWVyu6P/o6vW8w10NxsE1LhFaZmq6YuO7l5ISsL6fZp2xjxkz y2fasYKE3tk+Ms0= X-Sasl-enc: t+LLM2k4dsiT7QwkYEiqOLrfMqwb1O0wfKAnksCsqsBx 1328787129 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id AF14D8E0085; Thu, 9 Feb 2012 06:32:09 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 380351C6FBC; Thu, 9 Feb 2012 12:32:08 +0100 (CET) Date: Thu, 9 Feb 2012 12:32:08 +0100 From: Bron Gondwana To: Giovanni Panozzo Message-ID: <20120209113208.GA31355@launde.brong.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F33AD2D.7050904@panozzo.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F33AD2D.7050904@panozzo.it> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ietf-imapext@imc.org, imap5@ietf.org, imap-protocol@u.washington.edu Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 11:32:21 -0000 On Thu, Feb 09, 2012 at 12:25:33PM +0100, Giovanni Panozzo wrote: > PS: I think that crossposting in 3 ML is too much. Which one will be > the official ML for this discussion ? (posting to all three for this...) Let's take the rest of the traffic to just imap5@ietf.org Bron. From brong@fastmail.fm Thu Feb 9 03:42:47 2012 Return-Path: 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 D0EE021F855D for ; Thu, 9 Feb 2012 03:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 Kpla1+PQ-87I for ; Thu, 9 Feb 2012 03:42:47 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id E84AA21F855A for ; Thu, 9 Feb 2012 03:42:46 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9F58720D94 for ; Thu, 9 Feb 2012 06:42:46 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 09 Feb 2012 06:42:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=K/YcNm+oFbch5iR9WiJ8m9Cy Jpw=; b=PTsNOOgF5dT5jeRKCKzsfSzrCyQAnG4iGByhHeUsbQNIIHxzeF8NChZi sbwYlCSg3/X57C8B/roxXbJAHXDSNFYor0sSnSqyKDR6Zoj0uIXNt+P8R1dWQ4e7 0y6nBg+lG6yqlCxLuU9qFdFe60/zOpHcAx6IbCmBylOEjU2WAdk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=K/YcNm+oFbch5iR9WiJ8m9CyJpw=; b=AkybBp0MvqR9DFAq4kNuv9Jjd4bu rsvFYWHzJN9NcZxPWVOV+/pYmWmMHLpkFzQqzWgItTaz7A9d6UpIuVIuloB6OCJX gJCjcP7dao4lHeVIlf29yZg3Nyzh/5OD78VmRdxljEQnlGfAA6rFxmKlomp/ba+H 5NbyZdcn7WIF0F8= X-Sasl-enc: 0uC0Z2n2RhOWWBXXNxWGraacjDXr8WunUOzjEucC7/2B 1328787766 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 5748C8E00B1; Thu, 9 Feb 2012 06:42:46 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 05B111C6FBC; Thu, 9 Feb 2012 12:42:45 +0100 (CET) Date: Thu, 9 Feb 2012 12:42:44 +0100 From: Bron Gondwana To: Giovanni Panozzo Message-ID: <20120209114244.GB31355@launde.brong.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F33AD2D.7050904@panozzo.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F33AD2D.7050904@panozzo.it> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 11:42:47 -0000 On Thu, Feb 09, 2012 at 12:25:33PM +0100, Giovanni Panozzo wrote: > >I found some older initiatives to replace IMAP with an HTTP based approach.[2] > >What do you think of HTTP for mail access? For my bachelor thesis[3] I > >currently argue that CardDAV/CalDAV could be perfectly replaced by AtomPub > >(RFC 5023). > >The main advantage would be that most software developers on this planet have > >some vague understanding of HTTP and that imense infrastructure and software > >already exists. > > > Hi Bron, hi Thomas. > I'm happy to see this interesting traffic on the ML. > > Just a small note: these two post are full of "programmer point of > view" considerations and philosophical ideals. That's good. > > But I'm mostly "system integrator", involved also with end-user > helpdesk. I'm a programmer also, but only form 2% of my time, so I'm > not a "professional programmer". > I would like to contribute with other key points useful both to > system integrators, helpdesk and end user (moron end user) ease to > use (I have a long list... do you want it ? :)) Yep! I do all of those too, though programming is a larger part of my week. There's a lot of sysadmin and user operations - and third level support. I'm not doing much first level any more. > Here are my first notes about HTTP: I think HTTP is welcome. Many > mobile phone carriers do offer only http/https connectivity, > sometimes filtered by a transparent proxy too. In some enterprise > LANs, users are forced to use an http proxy with proxy > authentication to access the Internet. No other protocols are > allowed. HTTP would allow all these users to access their e-mail > without requiring impossible access upgrades. > And HTTP completed with digest authentication and email body > encryption also will also help sysadmins to have more security > without incurring into the SSL certificate infrastructure pains. > Http is also "stateless" from its birth: the advantage is that we > can better serve clients with intermittent connections (point 3 in > Bron's list), like mobile phones or poorly connected wifi laptops. That's certainly a strong point in HTTP's favour. I'm going to spend some time on the wiki tonight (Oslo time) building up a list of the major technology choices and the advantages and disadvantages of each one. Protocols will basically be: * Custom * HTTP * XMPP And within HTTP: XML / JSON / other? RESTful URIs vs batching... One important point - I don't want to lose "literals". RFC822 messages should be able to zero-copy IO across the wire as the raw bytes. Bron. From vanmeeuwen@kolabsys.com Thu Feb 9 04:38:41 2012 Return-Path: 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 4075821F86AD for ; Thu, 9 Feb 2012 04:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PdrgVq6L-0CD for ; Thu, 9 Feb 2012 04:38:40 -0800 (PST) Received: from kolab.kolabsys.com (kolab.kolabsys.com [78.46.32.248]) by ietfa.amsl.com (Postfix) with ESMTP id 7736721F86B3 for ; Thu, 9 Feb 2012 04:38:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kolab.kolabsys.com (Postfix) with ESMTP id 02A5B256BECD for ; Thu, 9 Feb 2012 13:38:38 +0100 (CET) X-Virus-Scanned: by amavisd-new at kolabsys.com Received: from kolab.kolabsys.com ([127.0.0.1]) by localhost (kolab.kolabsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-1Qlqk1H4ED for ; Thu, 9 Feb 2012 13:38:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by kolab.kolabsys.com (Postfix) with ESMTP id 5B3CC256BECF for ; Thu, 9 Feb 2012 13:38:36 +0100 (CET) Received: from webmail.kolabsys.com (unknown [178.209.35.98]) (Authenticated sender: vanmeeuwen@kolabsys.com) by kolab.kolabsys.com (Postfix) with ESMTPSA id 3FB0E256BEBB for ; Thu, 9 Feb 2012 13:38:36 +0100 (CET) Received: from mpOqX/Z2X7bQ713L3I0L71BrMCuhBbDy by webmail.kolabsys.com with HTTP (HTTP/1.1 POST); Thu, 09 Feb 2012 13:38:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 09 Feb 2012 13:38:35 +0100 From: "Jeroen van Meeuwen (Kolab Systems)" To: In-Reply-To: <201202090820.28260.thomas@koch.ro> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> Message-ID: X-Sender: vanmeeuwen@kolabsys.com User-Agent: Roundcube Webmail/0.7.0-0.1.el6.kolab_2.4 Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 12:38:41 -0000 On 2012-02-09 8:20, Thomas Koch wrote: > Bron Gondwana: >> Snide comments from those who don't agree with the goals are welcome >> too... >> I just won't listen to you. These goals are very important to me. > Hi Bron, > > I'm not an expert in IMAP, just got here out of curiosity about > Kolab[1]'s use of IMAP folders as data stores. Please, rest of list, let's not view this article as authoritative representation of the position of the current Kolab Groupware development drivers, whom are currently primarily the colleagues at the company I work for. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 From dave@cridland.net Thu Feb 9 04:50:54 2012 Return-Path: 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 6C01121F84E2 for ; Thu, 9 Feb 2012 04:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 YJf7xHTaS3S8 for ; Thu, 9 Feb 2012 04:50:53 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBC621F8703 for ; Thu, 9 Feb 2012 04:50:53 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id A53AE1168087 for ; Thu, 9 Feb 2012 12:50:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6DhRZniNZia for ; Thu, 9 Feb 2012 12:50:44 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 278481168067 for ; Thu, 9 Feb 2012 12:50:44 +0000 (GMT) References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F33AD2D.7050904@panozzo.it> In-Reply-To: <4F33AD2D.7050904@panozzo.it> MIME-Version: 1.0 Message-Id: <23858.1328791844.127428@puncture> Date: Thu, 09 Feb 2012 12:50:44 +0000 From: Dave Cridland To: "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 12:50:54 -0000 On Thu Feb 9 11:25:33 2012, Giovanni Panozzo wrote: > Http is also "stateless" from its birth: the advantage is that we > can better serve clients with intermittent connections (point 3 in > Bron's list), like mobile phones or poorly connected wifi laptops. This one's a myth. We've had BOSH in the XMPP world for a while, and although it's used in the web browser, it's typically avoided in mobile because it ramps up the power requirements quite heavily, and turns out to to no more effective than the newer XEP-0198 anyway. It'd be much better for web clients to run actual IMAP over either BOSH or Websocket. The difficulty with this approach is twofold: 1) IMAP transfers binary data in-line, and Javascript simply doesn't cope well with this. 2) Parsing IMAP in Javascript means parsing it with a pure Javascript parser, which will be slower and more prone to error. Using XML or JSON would be better here. To address both, I think I could build a useful IMAP replacement that ran the metadata, push, and folder management over XMPP, and the content access over HTTP, quite easily. It's almost tempting, and is at least as perverse as the other proposals. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From arnt@gulbrandsen.priv.no Thu Feb 9 05:40:55 2012 Return-Path: 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 30DCA21F86D7 for ; Thu, 9 Feb 2012 05:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 5iFcr2o35q-a for ; Thu, 9 Feb 2012 05:40:54 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 985F121F86BE for ; Thu, 9 Feb 2012 05:40:54 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1D71AF8C553; Thu, 9 Feb 2012 13:40:53 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328794852-31942-31942/10/12; Thu, 9 Feb 2012 13:40:52 +0000 Message-Id: <4F33CCFC.1090206@gulbrandsen.priv.no> Date: Thu, 9 Feb 2012 14:41:16 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F33AD2D.7050904@panozzo.it> <23858.1328791844.127428@puncture> In-Reply-To: <23858.1328791844.127428@puncture> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 13:40:55 -0000 On 02/09/2012 01:50 PM, Dave Cridland wrote: > To address both, I think I could build a useful IMAP replacement that > ran the metadata, push, and folder management over XMPP, and the content > access over HTTP, quite easily. If you wish to be faithful to history, then the right thing would be to run that on TCP ports 20 and 21. Ahem. Arnt From dave@cridland.net Thu Feb 9 05:51:12 2012 Return-Path: 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 5053821F8741 for ; Thu, 9 Feb 2012 05:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 D-ian9rZQMMS for ; Thu, 9 Feb 2012 05:51:11 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 932AC21F873D for ; Thu, 9 Feb 2012 05:51:11 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 7A3D51168087; Thu, 9 Feb 2012 13:51:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgeu4UarpWBp; Thu, 9 Feb 2012 13:51:06 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 2C61B1168067; Thu, 9 Feb 2012 13:51:06 +0000 (GMT) References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F33AD2D.7050904@panozzo.it> <23858.1328791844.127428@puncture> <4F33CCFC.1090206@gulbrandsen.priv.no> In-Reply-To: <4F33CCFC.1090206@gulbrandsen.priv.no> MIME-Version: 1.0 Message-Id: <23858.1328795466.182537@puncture> Date: Thu, 09 Feb 2012 13:51:06 +0000 From: Dave Cridland To: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 13:51:12 -0000 On Thu Feb 9 13:41:16 2012, Arnt Gulbrandsen wrote: > On 02/09/2012 01:50 PM, Dave Cridland wrote: > > To address both, I think I could build a useful IMAP replacement > that > > ran the metadata, push, and folder management over XMPP, and the > content > > access over HTTP, quite easily. > > If you wish to be faithful to history, then the right thing would > be to > run that on TCP ports 20 and 21. Ahem. Quite - the design is not far off. Obviously if we did use port 20, then we could also send IAC WILL RANDOMLY_LOSE, and come full circle. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From thomas@koch.ro Fri Feb 10 06:45:04 2012 Return-Path: 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 422F421F877F for ; Fri, 10 Feb 2012 06:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.696 X-Spam-Level: ** X-Spam-Status: No, score=2.696 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_RO=1.235, HELO_IS_SMALL6=0.556, HOST_EQ_RO=0.904] 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 kNUdNXMXXfth for ; Fri, 10 Feb 2012 06:45:00 -0800 (PST) Received: from koch.ro (koch.ro [88.198.2.104]) by ietfa.amsl.com (Postfix) with ESMTP id CD26D21F870A for ; Fri, 10 Feb 2012 06:44:59 -0800 (PST) Received: from aktaia.intevation.org ([212.95.126.10] helo=t61.localnet) by koch.ro with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RvriZ-0007SW-3v; Fri, 10 Feb 2012 15:44:55 +0100 From: Thomas Koch To: Adrien de Croy Date: Fri, 10 Feb 2012 15:44:50 +0100 User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; ) References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> In-Reply-To: <4F337E61.5040702@qbik.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201202101544.51364.thomas@koch.ro> Cc: ietf-imapext@imc.org, imap5@ietf.org, IMAP Protocol Interest List Subject: Re: [imap5] Designing a new replacement protocol for IMAP X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: thomas@koch.ro List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 14:45:05 -0000 Hi Adrien, thank you for your insights. I've some more questions inline. Adrien de Croy: > * updates. Would need to poll or use long polling to get real-time > updates (e.g. notification of incoming mail). Could Websockets or http://en.wikipedia.org/wiki/Comet_(programming) be of help here? > * complex. In order to reduce round-trips, you'd have to do many things > in a single transaction, which would create complexity issues in the > server and client I was thinking restful HTTP which by definition is not complex. The question is, whether a useful mail fetch protocol could be designed in the constraints of rest. > I think it would also be very problematic in the wild, since any http > intermediary would feel entitled to mess with traffic. E.g. heuristic > caching, intercepting proxies etc. There is an HTTP header to instruct any cache to pipe the request through and do no caching. But anybody on any line in any protocol could mess with your data. Have to go now, sorry. :-) Best regards, Thomas Koch, http://www.koch.ro From cyrus@daboo.name Fri Feb 10 07:10:02 2012 Return-Path: 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 0DE1A21F85A3 for ; Fri, 10 Feb 2012 07:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_05=-1.11, USER_IN_WHITELIST=-100] 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 3ukia5Xkljet for ; Fri, 10 Feb 2012 07:10:01 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 363B821F859F for ; Fri, 10 Feb 2012 07:10:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4339221BAAEE; Fri, 10 Feb 2012 10:10:00 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu272O3v9Lfs; Fri, 10 Feb 2012 10:09:54 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id A2F1421BAAE3; Fri, 10 Feb 2012 10:09:53 -0500 (EST) Date: Fri, 10 Feb 2012 10:09:48 -0500 From: Cyrus Daboo To: thomas@koch.ro, Adrien de Croy Message-ID: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> In-Reply-To: <201202101544.51364.thomas@koch.ro> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1181 Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 15:10:02 -0000 Hi Thomas, --On February 10, 2012 3:44:50 PM +0100 Thomas Koch wrote: >> * updates. Would need to poll or use long polling to get real-time >> updates (e.g. notification of incoming mail). > Could Websockets or http://en.wikipedia.org/wiki/Comet_(programming) be > of help here? For CalDAV and CardDAV we (Apple, http://calendarserver.org) have used XMPP pubsub and our own APNS to implement a push notification service. Frankly I think the IETF should have developed a proper notification protocol for use alongside other protocols a long time ago - simply "blessing" XMPP pubsub as the solution for that would be fine from a standards point, but perhaps something else (new) coukld be done too. What then needs to be defined are the hooks in each underlying protocol to allow clients to discover the appropriate pubsub service. In CalDAV/CardDAV that is simply done using WebDAV properties to advertise the essential client push configuration. So, in my opinion, whilst push notifications should be a requirement for imap5, we should not define that protocol and instead push the IETF to provide such a protocol for general use. -- Cyrus Daboo From filip.navara@gmail.com Fri Feb 10 07:29:28 2012 Return-Path: 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 417C821F8749 for ; Fri, 10 Feb 2012 07:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LpKUNuIuyzDH for ; Fri, 10 Feb 2012 07:29:27 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C28821F8745 for ; Fri, 10 Feb 2012 07:29:26 -0800 (PST) Received: by obbwd15 with SMTP id wd15so4680106obb.31 for ; Fri, 10 Feb 2012 07:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dFSTnjziZgWcZz6RUE/OYMQeOFrIXUyVNUeS8scgU08=; b=B7lHn4cUZR64j3dOzyAAMzK76ljXERMNtZ4oC040n3iInBS+WMp5V8YwmOLVonilN7 G+DIM/zTVmobBafw9o22ZA0IcewuP4aPAyiOPprRqPxU6ir+HAGod6G8d6G8uJq+WnbF 7IpiVoQQ9QBJwd97j4E2GizyTD8/aXQlt4VUI= MIME-Version: 1.0 Received: by 10.50.15.231 with SMTP id a7mr11696925igd.8.1328887765372; Fri, 10 Feb 2012 07:29:25 -0800 (PST) Received: by 10.182.74.8 with HTTP; Fri, 10 Feb 2012 07:29:25 -0800 (PST) In-Reply-To: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> Date: Fri, 10 Feb 2012 16:29:25 +0100 Message-ID: From: Filip Navara To: Cyrus Daboo Content-Type: multipart/alternative; boundary=14dae9340857338f5104b89dcb14 Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 15:29:28 -0000 --14dae9340857338f5104b89dcb14 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 10, 2012 at 4:09 PM, Cyrus Daboo wrote: > Hi Thomas, > > > --On February 10, 2012 3:44:50 PM +0100 Thomas Koch > wrote: > > * updates. Would need to poll or use long polling to get real-time >>> updates (e.g. notification of incoming mail). >>> >> Could Websockets or http://en.wikipedia.org/wiki/**Comet_(programming)be >> of help here? >> > > For CalDAV and CardDAV we (Apple, http://calendarserver.org) have used > XMPP pubsub and our own APNS to implement a push notification service. > Frankly I think the IETF should have developed a proper notification > protocol for use alongside other protocols a long time ago - simply > "blessing" XMPP pubsub as the solution for that would be fine from a > standards point, but perhaps something else (new) coukld be done too. What > then needs to be defined are the hooks in each underlying protocol to allow > clients to discover the appropriate pubsub service. In CalDAV/CardDAV that > is simply done using WebDAV properties to advertise the essential client > push configuration. > > So, in my opinion, whilst push notifications should be a requirement for > imap5, we should not define that protocol and instead push the IETF to > provide such a protocol for general use. There already exists a standardized way to implement XMPP notifications on IMAP, although it is a bit cumbersome and I doubt anyone ever implemented it. http://tools.ietf.org/html/rfc5435 (Sieve Notify) http://tools.ietf.org/html/rfc 5550 (Lemonade IMAP profile) Best regards, Filip Navara --14dae9340857338f5104b89dcb14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 10, 2012 at 4:09 PM, Cyrus Daboo <cyrus@daboo.name= > wrote:
Hi Thomas,


--On February 10, 2012 3:44:50 PM +0100 Thomas Koch <thomas@koch.ro> wrote:

* updates. =A0Would need to poll or use long polling to get real-time
updates (e.g. notification of incoming mail).
Could Websockets or http://en.wikipedia.org/wiki/Comet_(programm= ing) be
of =A0help here?

For CalDAV and CardDAV we (Apple, http://calendarserver.org) have used XMPP pubsub and our= own APNS to implement a push notification service. Frankly I think the IET= F should have developed a proper notification protocol for use alongside ot= her protocols a long time ago - simply "blessing" XMPP pubsub as = the solution for that would be fine from a standards point, but perhaps som= ething else (new) coukld be done too. What then needs to be defined are the= hooks in each underlying protocol to allow clients to discover the appropr= iate pubsub service. In CalDAV/CardDAV that is simply done using WebDAV pro= perties to advertise the essential client push configuration.

So, in my opinion, whilst push notifications should be a requirement for im= ap5, we should not define that protocol and instead push the IETF to provid= e such a protocol for general use.

There al= ready exists a standardized way to implement XMPP notifications on IMAP, al= though it is a bit cumbersome and I doubt anyone ever implemented it.=A0

http://tools.ietf.org/html/rfc5550=A0(Lemonade IMAP profil= e)

Best regards,
Filip Navara


--14dae9340857338f5104b89dcb14-- From cyrus@daboo.name Fri Feb 10 07:48:44 2012 Return-Path: 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 35FD911E8088 for ; Fri, 10 Feb 2012 07:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.072 X-Spam-Level: X-Spam-Status: No, score=-102.072 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 0iUmmhlcfoXZ for ; Fri, 10 Feb 2012 07:48:42 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0A83B11E8076 for ; Fri, 10 Feb 2012 07:48:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 3A5EE21BAFB3; Fri, 10 Feb 2012 10:48:41 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxIAOBnwqUNq; Fri, 10 Feb 2012 10:48:38 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id B1E4D21BAFA8; Fri, 10 Feb 2012 10:48:36 -0500 (EST) Date: Fri, 10 Feb 2012 10:48:32 -0500 From: Cyrus Daboo To: Filip Navara Message-ID: <13042F851E6093B120D14B34@caldav.corp.apple.com> In-Reply-To: References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=864 Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 15:48:44 -0000 Hi Filip, --On February 10, 2012 4:29:25 PM +0100 Filip Navara=20 wrote: > There already exists a standardized way to implement XMPP notifications > on IMAP, although it is a bit cumbersome and I doubt anyone ever > implemented it.=C2=A0 > > > http://tools.ietf.org/html/rfc5435=C2=A0(Sieve Notify) > http://tools.ietf.org/html/rfc5550=C2=A0(Lemonade IMAP profile) > The SIEVE notify solution only covers the case of message delivery into a=20 mailstore (be it IMAP or POP). It won't cover the case of changes made=20 directly to that store (e.g. and IMAP APPEND). Now there is the IMAP-SIEVE=20 draft () which = in theory allows notifications to be added to IMAP. That may be overboard=20 for what is required here and it does not cover what needs to be done in=20 other protocols. --=20 Cyrus Daboo From brong@fastmail.fm Fri Feb 10 10:22:48 2012 Return-Path: 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 1F94A21F8668 for ; Fri, 10 Feb 2012 10:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 NVq3-7xzXWoR for ; Fri, 10 Feb 2012 10:22:47 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id EA75321F87D1 for ; Fri, 10 Feb 2012 10:22:44 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3D25B20E8D for ; Fri, 10 Feb 2012 13:22:44 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 10 Feb 2012 13:22:44 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=qjXM/5fVMq7SgihYGPkDM1NT GJ0=; b=DKqINntrkiKOyDo4qwUhpX6LliMRDczRlyNkAmaXruLnqjz5Q9z/0omO nBRMEk5PmfcDKw5xymGfdfKsfUq8cJercvi3RW5fn8lQgOsvMxyF4oTLfQy2bHpc TQuQ7ky0FfeiA/0b1iQoSfvkGvJEPb526LQ4UXcEfNDYmm6Fwg8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=qjXM/5fVMq7SgihYGPkDM1NTGJ0=; b=ID/yXEn57oZ+w/+vL1W/pJTFmJ4V K6xpJFCMgMpiCOS7PiS8mNLWNsxEXlDm44FsnfH8BoB3pegCnK83JV25ySWyhL43 2FIoWboDPYO/D2tijP6GM1iqQVNLkDa9AIW4g5LkLJjKmwVb2J7j0EKe8I9NFTHQ L9q1WizcB8oBeM4= X-Sasl-enc: /1nituYgh5UIgo/iXz7W7SNDhJLBAEIsMhSdw4WlyJ3b 1328898163 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id E8A668E0226; Fri, 10 Feb 2012 13:22:43 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 5313C1C9391; Fri, 10 Feb 2012 19:22:42 +0100 (CET) Date: Fri, 10 Feb 2012 19:22:42 +0100 From: Bron Gondwana To: Cyrus Daboo Message-ID: <20120210182242.GA29036@launde.brong.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 18:22:48 -0000 On Fri, Feb 10, 2012 at 10:09:48AM -0500, Cyrus Daboo wrote: > For CalDAV and CardDAV we (Apple, http://calendarserver.org) have > used XMPP pubsub and our own APNS to implement a push notification > service. Frankly I think the IETF should have developed a proper > notification protocol for use alongside other protocols a long time > ago - simply "blessing" XMPP pubsub as the solution for that would > be fine from a standards point, but perhaps something else (new) > coukld be done too. What then needs to be defined are the hooks in > each underlying protocol to allow clients to discover the > appropriate pubsub service. In CalDAV/CardDAV that is simply done > using WebDAV properties to advertise the essential client push > configuration. I really should make sure we're compatible with what you're doing too. Obviously, there's a tradeoff between being able to do everything in one protocol vs simplicity and saving the wheels from being reinvented all over again. I really appreciate your input here - you've got some good points, and an actual implementation of something interesting, which trumps talking every time! > So, in my opinion, whilst push notifications should be a requirement > for imap5, we should not define that protocol and instead push the > IETF to provide such a protocol for general use. My plan is to define in-band push if there's an active TCP connection, plus out-of-band notifications. Either way they would be of the "something has changed, go request an update to the views you are interested in"... What we've done at mail.opera.com for a web-based system is to use eventsource to push just a "here's a new modseq for you" to the client, after which it can request a diff against the previous view. This works because we use a single HIGHESTMODSEQ counter across all the users' mailboxes. Obviously, it doesn't scale so nicely to shared folders. For this I'm seriously considering a CHANGEROOT or similar, which would be a tree of related folders in which modseqs are serialised. For a 64 bit counter, there's probably actually no real problem with updating them across the entire server - other than then having to filter the change notifications so you don't generate a zillion spurious "something may have been updated" notification to every client. Bron. From brong@fastmail.fm Sun Feb 12 12:22:28 2012 Return-Path: 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 DA35C21F854B for ; Sun, 12 Feb 2012 12:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 qj2T3ViqrvOQ for ; Sun, 12 Feb 2012 12:22:27 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 32EDB21F864E for ; Sun, 12 Feb 2012 12:22:27 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9DC9620DEF for ; Sun, 12 Feb 2012 15:22:25 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 12 Feb 2012 15:22:25 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:subject:message-id:mime-version:content-type; s= mesmtp; bh=stI1/kc9DYJdTuwJVNXMpZuAEzo=; b=k/P31OFsSSRXpu13aY6D3 tYSodiLhpuEF9wivCO4Vc6ijQidEpQ2VX8u0Ov3IQHF7pKy7VkSzNP9/jz6s2m3d yKt2a1vVwJMdCl2r/rBIj74vKaZA8Njye6KjrGHELlLSeLZdOpzFH/mOVf2/2RJ/ /9bscAVJjuQiGpe+dJt9/0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:subject:message-id :mime-version:content-type; s=smtpout; bh=stI1/kc9DYJdTuwJVNXMpZ uAEzo=; b=W/P8d61iRUhDEuFPi18rMhi9SUNP/BGTVqz+Z9MwvT6vz5QTomsm14 pAmfY+iIT4Bip4FCr8c9Bj5n/0TtXv8/AFdFEDLJKhLyOP+iNbO86dtgZhdY2bXn T66yVGLtG6l4tSEKXfVgsPkvwA4pmRwecen/gB31yi/KJariYwLvo= X-Sasl-enc: SkQpQQP+fmA8VpuiHltQbtkjhGoV0J0E5pnc/Urz46oE 1329078145 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 5C22B4827D2 for ; Sun, 12 Feb 2012 15:22:25 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id D001E327E1F; Sun, 12 Feb 2012 21:22:23 +0100 (CET) Date: Sun, 12 Feb 2012 21:22:23 +0100 From: Bron Gondwana To: imap5@ietf.org Message-ID: <20120212202223.GA22484@launde.brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [imap5] Existing RFCs - what do they solve, and how to solve those problems X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:22:29 -0000 Before building something new, it helps understand what's already been done and what problems it's solving - since I won't have seen every problem that everyone is having. I'm probably not the best standards writer or the best programmer out there - but I'm driven do this bloody thing! I plan to build a list of all the RFCs which refer to the communications between clients and servers. http://www.imc.org/rfcs.html is a good starting point. I want to capture things like ACAP and SIEVE as well. I plan to build a table with: a) RFC Number and title b) Problem being solved c) Plan to handle that same problem Now it may be that (c) is "won't deal with it", or "won't exist because it's a workaround for a deficiency which won't exist". I'm hoping for more of the latter. I went to a great talk by Damien Conway about rewriting all his CPAN Perl modules for Perl6 (yes, yes - I know, it doesn't even exist yet). Fully half of his modules were workarounds for deficiencies in perl5 which just don't exist in perl6, so they don't need to be ported. Of the rest, many were cut down to fewer than half the number of lines of code due to the increased expressivity of the new language. I hope many of the extension RFCs for IMAP will fall under the same patterns - simpler to implement if required at all. I'll post more here as the list of RFCs is put together. I'm particularly hoping to make sure I don't miss any relevant RFCs: http://imapwiki.org/ImapRFCList Bron. From Pidgeot18@verizon.net Sun Feb 12 13:14:09 2012 Return-Path: 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 D26E121F863B for ; Sun, 12 Feb 2012 13:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 aINTmaYpeU9V for ; Sun, 12 Feb 2012 13:14:08 -0800 (PST) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by ietfa.amsl.com (Postfix) with ESMTP id 1449E21F8636 for ; Sun, 12 Feb 2012 13:14:08 -0800 (PST) Received: from [192.168.1.67] ([unknown] [108.199.240.147]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LZA00KYQTN68F70@vms173003.mailsrvcs.net> for imap5@ietf.org; Sun, 12 Feb 2012 15:13:55 -0600 (CST) Message-id: <4F382B91.9050806@verizon.net> Date: Sun, 12 Feb 2012 15:13:53 -0600 From: Joshua Cranmer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-version: 1.0 To: imap5@ietf.org References: <20120212202223.GA22484@launde.brong.net> In-reply-to: <20120212202223.GA22484@launde.brong.net> Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit Subject: Re: [imap5] Existing RFCs - what do they solve, and how to solve those problems X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 21:14:10 -0000 On 2/12/2012 2:22 PM, Bron Gondwana wrote: > I plan to build a list of all the RFCs which refer to the communications > between clients and servers. http://www.imc.org/rfcs.html is a good > starting point. I want to capture things like ACAP and SIEVE as well. is a list that I made and others extended over the years. Looking back on it, I realize that it completely omits all of the MIME specifications; some recent work I did on a MIME parser produced the following list of stuff (this does more than just MIME): // * RFC 2045 -- MIME Part 1, Format of Internet Message Bodies // * RFC 2046 -- MIME Part 2, Media Types // * RFC 5322 -- Internet Message Format (see also RFC 2822, RFC 822) // * RFC 5536 -- Netnews Article Format (see also RFC 1036) // * RFC 2047 -- MIME Part 3, Message Header Extensions for Non-ASCII Text // * RFC 2231 -- MIME Parameter Value and Encoded Word Extensions // * RFC 5335 -- Internationalized Email Headers // XXX: RFC 5335bis (Downgrading was removed from EAI, so...) // * Uuencode -- No spec for this? Wikipedia doesn't list a reference // * -- yEnc "specification" // * -- BinHex // * XXX: find refs for PGP, S/MIME, TNEF // * XXX: 2646/3676 (f=f?), 3798/? (mdn), ??? (cid, mhtml, etc.) -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth From brong@fastmail.fm Sun Feb 12 13:56:23 2012 Return-Path: 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 43AE621F86B3 for ; Sun, 12 Feb 2012 13:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 gTtM7rdRSyGZ for ; Sun, 12 Feb 2012 13:56:22 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6E72C21F86AD for ; Sun, 12 Feb 2012 13:56:21 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 10BE020168 for ; Sun, 12 Feb 2012 16:56:21 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Sun, 12 Feb 2012 16:56:21 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=Z54zQ6tvBwxIQ8V9imA6vjUg QYw=; b=HyhVO9rZV2UXI0OtGmpER5L04OuzLdHOMmTyLssTEZscsASwqXXAUs6d SJjvqPaDMdgAfpEeX3fwEwuLK8yaKY7wN5JdycGh19bIooYEabHfP8vcrEBiGCfY bQiViWuLjHXLA61xxnAQ5TgmhAydp6HKlzqnoW9rIGPyNoJU+9Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=Z54zQ6tvBwxIQ8V9imA6vjUgQYw=; b=t9akZCsEIR/MXhlB4x54Zvl55QzE JNuJV2PPFs2YW58pTaZIyaGA0McTgE69pInQXVAuudw/lQ6ZCtnM5OUeAeboMy4n AsheRdwbCSnJqqquDWtOjs1xILXfZwcJkqs3u+ur6xGp7BmHtNoreBBPx0J9aMY9 puXh5jtGdcycTkY= X-Sasl-enc: UnkEzkWMZahx/8nF99SH/0qTlT+gVgQj0dy3BuDbuQtq 1329083780 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id C4158483524; Sun, 12 Feb 2012 16:56:20 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 4D582327E24; Sun, 12 Feb 2012 22:56:19 +0100 (CET) Date: Sun, 12 Feb 2012 22:56:19 +0100 From: Bron Gondwana To: Joshua Cranmer Message-ID: <20120212215619.GA23624@launde.brong.net> References: <20120212202223.GA22484@launde.brong.net> <4F382B91.9050806@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F382B91.9050806@verizon.net> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] Existing RFCs - what do they solve, and how to solve those problems X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 21:56:23 -0000 On Sun, Feb 12, 2012 at 03:13:53PM -0600, Joshua Cranmer wrote: > On 2/12/2012 2:22 PM, Bron Gondwana wrote: > >I plan to build a list of all the RFCs which refer to the communications > >between clients and servers. http://www.imc.org/rfcs.html is a good > >starting point. I want to capture things like ACAP and SIEVE as well. > is a list that > I made and others extended over the years. Looking back on it, I > realize that it completely omits all of the MIME specifications; > some recent work I did on a MIME parser produced the following list > of stuff (this does more than just MIME): Excellent. Added to my list of stuff to look over! I'll make sure I haven't missed anything from there too. Bron. From adrien@qbik.com Sun Feb 12 13:57:15 2012 Return-Path: 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 E88F221F86AD for ; Sun, 12 Feb 2012 13:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.08 X-Spam-Level: X-Spam-Status: No, score=-6.08 tagged_above=-999 required=5 tests=[AWL=-3.481, 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 5hmelJBlCBPP for ; Sun, 12 Feb 2012 13:57:14 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6E93B21F861D for ; Sun, 12 Feb 2012 13:57:14 -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 3379)) with SMTP id <0018859797@smtp.qbik.com>; Mon, 13 Feb 2012 10:57:11 +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 <0010058419@sago.qbik.com>; Mon, 13 Feb 2012 10:56:49 +1300 Message-ID: <4F3835A1.7060804@qbik.com> Date: Mon, 13 Feb 2012 10:56:49 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120124 Thunderbird/10.0 MIME-Version: 1.0 To: Cyrus Daboo References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> In-Reply-To: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 21:57:16 -0000 On 11/02/2012 4:09 a.m., Cyrus Daboo wrote: > Hi Thomas, > > --On February 10, 2012 3:44:50 PM +0100 Thomas Koch > wrote: > >>> * updates. Would need to poll or use long polling to get real-time >>> updates (e.g. notification of incoming mail). >> Could Websockets or http://en.wikipedia.org/wiki/Comet_(programming) be >> of help here? > > For CalDAV and CardDAV we (Apple, http://calendarserver.org) have used > XMPP pubsub and our own APNS to implement a push notification service. > Frankly I think the IETF should have developed a proper notification > protocol for use alongside other protocols a long time ago - simply > "blessing" XMPP pubsub as the solution for that would be fine from a > standards point, but perhaps something else (new) coukld be done too. > What then needs to be defined are the hooks in each underlying > protocol to allow clients to discover the appropriate pubsub service. > In CalDAV/CardDAV that is simply done using WebDAV properties to > advertise the essential client push configuration. > > So, in my opinion, whilst push notifications should be a requirement > for imap5, we should not define that protocol and instead push the > IETF to provide such a protocol for general use. > I don't think that's a workable approach. Getting such a protocol together, which enables notifications from any other application protocol I think will take a very long time, if it can even succeed. It's hard enough getting consensus within one protocol working group, let alone all of them working together. Also every different protocol has different notification requirements. trying to cover all that in a single protocol I think would be difficult. Finally, one of the things I am keen to see disappear with IMAP5 (for want of a better name) is the requirement for clients, admins etc to deploy multiple protocols - e.g. allow submission in IMAP. This is because it's frankly a large (and should be unnecessary) admin burden trying to support 2 protocols for mail (e.g. SMTP + POP3/IMAP4). Mail users don't understand the significance, they just submit support tickets because they can retrieve mail but not send. Firewalls block ports, ISPs intercept / block port 25 (NZ largest ISP does this), multiple protocols = multiple realms for credentials, multiple implementations of authentication and authorization etc. Having to have another protocol to implement to get notifications back probably over another channel etc makes this issue worse not better. Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From brong@fastmail.fm Sun Feb 12 14:09:00 2012 Return-Path: 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 9815421F86BB for ; Sun, 12 Feb 2012 14:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 pnEX-REfYhyC for ; Sun, 12 Feb 2012 14:08:58 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id A6BF121F8677 for ; Sun, 12 Feb 2012 14:08:58 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5A69421049 for ; Sun, 12 Feb 2012 17:08:58 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 12 Feb 2012 17:08:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=jhLQ8gcClf1Pnvw/rWYn5857 8dE=; b=confUj2/SUiVBEkDru1pH4dBH99b6PeIVd54qzYLZfupGfY4avjdz6Ih MKE6iLNYO6BVJXtMdk1Ske8hIRVACu9t+tsW8b0fDoLVe26tdCuY5jA80Z8NP98a gYuxXBq/Pt/NYLWbThEjU9+vDrfsBI+2qKgsJehypVy6ARWQlVc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=jhLQ8gcClf1Pnvw/rWYn58578dE=; b=kra4+C5qtwQFkvMoNxxGnaWkTFD3 2pt7dl3QysKxb8YzJKFnhzprXe2fGT2+JKUO6HE88HsUnkygSuwec21md7KOUWQt JT5q9g4JTARtzeOj/DUDxkaHdyQNszcqgwvlGGrhEoWIb7VYSYaayfNFyq46mQkW oDSzVfonhbG409g= X-Sasl-enc: GtEDZU0PgRV0PJlcOqnqCl2vZnsFRXUphhlgNzrIBm0z 1329084538 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 122958E0085; Sun, 12 Feb 2012 17:08:58 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id ADE41327E24; Sun, 12 Feb 2012 23:08:56 +0100 (CET) Date: Sun, 12 Feb 2012 23:08:56 +0100 From: Bron Gondwana To: Adrien de Croy Message-ID: <20120212220856.GA24013@launde.brong.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3835A1.7060804@qbik.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 22:09:00 -0000 On Mon, Feb 13, 2012 at 10:56:49AM +1300, Adrien de Croy wrote: > Finally, one of the things I am keen to see disappear with IMAP5 > (for want of a better name) is the requirement for clients, admins > etc to deploy multiple protocols - e.g. allow submission in IMAP. > This is because it's frankly a large (and should be unnecessary) > admin burden trying to support 2 protocols for mail (e.g. SMTP + > POP3/IMAP4). Mail users don't understand the significance, they > just submit support tickets because they can retrieve mail but not > send. Firewalls block ports, ISPs intercept / block port 25 (NZ > largest ISP does this), multiple protocols = multiple realms for > credentials, multiple implementations of authentication and > authorization etc. Absolutely agree. There has to be a way to do basic "client wants to upload a message to Sent (possibly upload it to Drafts first and then move it to Sent, with a copy going out to the destination too) within the one protocol. If you're doing something more fancy, there's still SMTP. > Having to have another protocol to implement to get notifications > back probably over another channel etc makes this issue worse not > better. Similarly, there needs to be a way to do notifications in-protocol. I still think that being compatible with an external protocol as well is good. Either way the notification should need to be nothing more than a new HIGHESTMODSEQ value from which the client can update whichever views it's interested in. To reduce roundtrips, it would be nice to register a view on which you want updates pushed rather than just getting a new modseq and having to ask for the updates... but that's a minor optimisation compared to having to run a "STATUS loop" over all your folders or open hundreds of separate TCP connections to get information. Bron. From alexey.melnikov@isode.com Mon Feb 13 04:52:54 2012 Return-Path: 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 CE2CC21F84D5 for ; Mon, 13 Feb 2012 04:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Wwn4Em69nhvO for ; Mon, 13 Feb 2012 04:52:52 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5762A21F84D3 for ; Mon, 13 Feb 2012 04:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1329137569; d=isode.com; s=selector; i=@isode.com; bh=1cDIySNtV/YU6mr80zWsbcjIvUdOt+lIXbn1hZOzPfc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ppcLOjEePiydk2TziKEjztdNTCkeOgTz7ByNZaQuEuEBsAGgKdk6sz+XCTVO4mPBs6GHli aZwqgM1TB1pUZ1Luycg8NzH5N2dc72DpQa4M/+vxbh5sNgt/Wjgxlra9Hk6FmL//ALxqsr kGjAyP8VJYx7msVUvqoOiyWl2m+Cj0A=; Received: from [192.168.1.145] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Feb 2012 12:52:49 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4F3907A2.2050801@isode.com> Date: Mon, 13 Feb 2012 12:52:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 To: Bron Gondwana References: <20120212202223.GA22484@launde.brong.net> <4F382B91.9050806@verizon.net> <20120212215619.GA23624@launde.brong.net> In-Reply-To: <20120212215619.GA23624@launde.brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] Existing RFCs - what do they solve, and how to solve those problems X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 12:52:54 -0000 On 12/02/2012 21:56, Bron Gondwana wrote: > On Sun, Feb 12, 2012 at 03:13:53PM -0600, Joshua Cranmer wrote: >> On 2/12/2012 2:22 PM, Bron Gondwana wrote: >>> I plan to build a list of all the RFCs which refer to the communications >>> between clients and servers. http://www.imc.org/rfcs.html is a good >>> starting point. I want to capture things like ACAP and SIEVE as well. >> is a list that >> I made and others extended over the years. Looking back on it, I >> realize that it completely omits all of the MIME specifications; >> some recent work I did on a MIME parser produced the following list >> of stuff (this does more than just MIME): > Excellent. Added to my list of stuff to look over! I'll make sure I > haven't missed anything from there too. Also have a look at www.rfc-editor.org (e.g. search for "IMAP"). From cyrus@daboo.name Mon Feb 13 07:21:15 2012 Return-Path: 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 A472521F8539 for ; Mon, 13 Feb 2012 07:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] 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 h05LI-s8pxiJ for ; Mon, 13 Feb 2012 07:21:07 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5C79221F850D for ; Mon, 13 Feb 2012 07:20:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B71A021DBD61; Mon, 13 Feb 2012 10:20:56 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXrwS8twprSh; Mon, 13 Feb 2012 10:20:52 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 897F421DBD56; Mon, 13 Feb 2012 10:20:51 -0500 (EST) Date: Mon, 13 Feb 2012 10:20:45 -0500 From: Cyrus Daboo To: Adrien de Croy Message-ID: In-Reply-To: <4F3835A1.7060804@qbik.com> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2281 Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 15:21:15 -0000 Hi Adrien, --On February 13, 2012 10:56:49 AM +1300 Adrien de Croy wrote: >> So, in my opinion, whilst push notifications should be a requirement >> for imap5, we should not define that protocol and instead push the >> IETF to provide such a protocol for general use. >> > > I don't think that's a workable approach. > > Getting such a protocol together, which enables notifications from any > other application protocol I think will take a very long time, if it can > even succeed. It's hard enough getting consensus within one protocol > working group, let alone all of them working together. > > Also every different protocol has different notification requirements. > trying to cover all that in a single protocol I think would be difficult. I disagree because what I envisage for the generic notification service is an OS-level api (supplied by OS or 3rd party libraries) that implement the "internet push service protocol". What that means is that client developers only have to implement a simple api to get push notifications. What is more anyone implementing more than one protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only have to implement that once, albeit with some minor differences in regard to how to get protocol specific pieces for registering for notifications. Your point about actually getting this done is valid. But realistically, do you really think IMAP5 is going to deploy overnight? Frankly, anyone who has a reasonably solid IMAP4 implementation today is going to question the need to work on something new, particularly if that something new brings nothing to the table (and simply fixing interop problems will probably not be seen as something "new"). If you can actually show that IMAP5 adds significant value by doing things like helping centralize push notifications, simplifying submission etc, then maybe, just maybe, those existing implementors might actually consider throwing out their current investment in IMAP4 for the new thing. But, IMHO, you are really going to have to up-sell IMAP5 to get buy-in from the major email providers. Now that does not mean it is not worth doing, but it does mean having to do more than just fixing perceived or real deficiencies. -- Cyrus Daboo From brong@fastmail.fm Mon Feb 13 08:23:38 2012 Return-Path: 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 A4AD721F853E for ; Mon, 13 Feb 2012 08:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] 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 rMTW6OeSro6i for ; Mon, 13 Feb 2012 08:23:36 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3233921F853B for ; Mon, 13 Feb 2012 08:23:36 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 12B0020802 for ; Mon, 13 Feb 2012 11:23:35 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 13 Feb 2012 11:23:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=3F6bOXcF0ButalwFIdTlqnnj TC0=; b=WuQFXy+TZbWXHw7wtpMoX+yoLY0E1BEonDd3s+D7BbjxCI7hpaOn1ikT DFqir4VBK05ILveKu0sfpl/oFDIF4PfjofI+wVld89kPqEVaOxv9FiqoW/2tR4H0 QSnU8cTd/5HWvjynVHFV5nZhUc6dDkauY5spy1dDIMA/c9gDiCM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=3F6bOXcF0ButalwFIdTlqnnjTC0=; b=iZ4WfmGoah2V7Qz6ImKs4PLnGOdw /PvVhXXeryqD1FflF9G+EI4aNeQ1shD9+9cYLal7RcUyrWZsuWUp8LFHJd+dMkXC 1Pzkt24CNrYwtZ34/wPyZvGiytrp7Y5e79JiJuTvxeBE1e2UGZCbv5nHVet1v/yS jjc/+GjpPR0X97U= X-Sasl-enc: JXkgpSt6eD+G7VTTp1jayD3ub4qwKiZbBdkuqoQxeQaT 1329150214 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id C149B8E00DA; Mon, 13 Feb 2012 11:23:34 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 42E4D1948A0; Mon, 13 Feb 2012 17:23:33 +0100 (CET) Date: Mon, 13 Feb 2012 17:23:33 +0100 From: Bron Gondwana To: Cyrus Daboo Message-ID: <20120213162333.GB28443@launde.brong.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 16:23:38 -0000 On Mon, Feb 13, 2012 at 10:20:45AM -0500, Cyrus Daboo wrote: > I disagree because what I envisage for the generic notification > service is an OS-level api (supplied by OS or 3rd party libraries) > that implement the "internet push service protocol". What that means > is that client developers only have to implement a simple api to get > push notifications. What is more anyone implementing more than one > protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only > have to implement that once, albeit with some minor differences in > regard to how to get protocol specific pieces for registering for > notifications. That's my vision too. Ideally not pushing a full data feed, but just a "ping, there's new stuff for you". Otherwise you wind up embedding every other protocol inside this protocol, which is too meta, even for me. > Your point about actually getting this done is valid. But > realistically, do you really think IMAP5 is going to deploy > overnight? Frankly, anyone who has a reasonably solid IMAP4 > implementation today is going to question the need to work on > something new, particularly if that something new brings nothing to > the table (and simply fixing interop problems will probably not be > seen as something "new"). If you can actually show that IMAP5 adds > significant value by doing things like helping centralize push > notifications, simplifying submission etc, then maybe, just maybe, > those existing implementors might actually consider throwing out > their current investment in IMAP4 for the new thing. But, IMHO, you > are really going to have to up-sell IMAP5 to get buy-in from the > major email providers. Now that does not mean it is not worth doing, > but it does mean having to do more than just fixing perceived or > real deficiencies. Absolutely agree. We need a hook to make it worthwhile, and I think submission and reliable push notifications are the hook. I've updated my RFC list from a simple text file which generates the list. Makes it easier to add new items :) Of course it means I miss any changes that anyone else makes to the wiki now - so I'll have to write a reverse parser too so I can see a diff first. The tricky bit is that the providers for whom it's going to be the most work are the ones who aren't already doing the LEMONADE profile, since that requires the sort of datastructures that would support the things I want to do with re-syncable state. Bron. From anil.srivastava@oracle.com Mon Feb 13 09:57:40 2012 Return-Path: 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 7904921F84D4 for ; Mon, 13 Feb 2012 09:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_RMML_Stock10=0.13, UNPARSEABLE_RELAY=0.001] 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 9mtmb52YZymo for ; Mon, 13 Feb 2012 09:57:39 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6144421F84D3 for ; Mon, 13 Feb 2012 09:57:39 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q1DHvR6E009293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2012 17:57:29 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q1DHvQhF007561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2012 17:57:27 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q1DHvOi7024540; Mon, 13 Feb 2012 11:57:24 -0600 Received: from Anils-MacBook-Pro.local (/148.87.13.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Feb 2012 09:57:24 -0800 Message-ID: <4F394F0A.2080506@oracle.com> Date: Mon, 13 Feb 2012 09:57:30 -0800 From: Anil SRIVASTAVA Organization: Oracle Corp [http://www.oracle.com] User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Cyrus Daboo References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080307090309020305050607" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090209.4F394F0A.0052,ss=1,re=0.000,fgs=0 Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 17:57:40 -0000 This is a multi-part message in MIME format. --------------080307090309020305050607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1. I could not have said this better. Anil On Mon Feb 13 2012 07:20:45 GMT-0800 (PST), Cyrus Daboo wrote: > Hi Adrien, > > --On February 13, 2012 10:56:49 AM +1300 Adrien de Croy > wrote: > >>> So, in my opinion, whilst push notifications should be a requirement >>> for imap5, we should not define that protocol and instead push the >>> IETF to provide such a protocol for general use. >>> >> >> I don't think that's a workable approach. >> >> Getting such a protocol together, which enables notifications from any >> other application protocol I think will take a very long time, if it can >> even succeed. It's hard enough getting consensus within one protocol >> working group, let alone all of them working together. >> >> Also every different protocol has different notification requirements. >> trying to cover all that in a single protocol I think would be >> difficult. > > I disagree because what I envisage for the generic notification > service is an OS-level api (supplied by OS or 3rd party libraries) > that implement the "internet push service protocol". What that means > is that client developers only have to implement a simple api to get > push notifications. What is more anyone implementing more than one > protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only > have to implement that once, albeit with some minor differences in > regard to how to get protocol specific pieces for registering for > notifications. > > Your point about actually getting this done is valid. But > realistically, do you really think IMAP5 is going to deploy overnight? > Frankly, anyone who has a reasonably solid IMAP4 implementation today > is going to question the need to work on something new, particularly > if that something new brings nothing to the table (and simply fixing > interop problems will probably not be seen as something "new"). If you > can actually show that IMAP5 adds significant value by doing things > like helping centralize push notifications, simplifying submission > etc, then maybe, just maybe, those existing implementors might > actually consider throwing out their current investment in IMAP4 for > the new thing. But, IMHO, you are really going to have to up-sell > IMAP5 to get buy-in from the major email providers. Now that does not > mean it is not worth doing, but it does mean having to do more than > just fixing perceived or real deficiencies. > -- ~Anil SRIVASTAVA --------------080307090309020305050607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1.  I could not have said this better.

Anil

On Mon Feb 13 2012 07:20:45 GMT-0800 (PST), Cyrus Daboo <cyrus@daboo.name> wrote:
Hi Adrien,

--On February 13, 2012 10:56:49 AM +1300 Adrien de Croy <adrien@qbik.com> wrote:

So, in my opinion, whilst push notifications should be a requirement
for imap5, we should not define that protocol and instead push the
IETF to provide such a protocol for general use.


I don't think that's a workable approach.

Getting such a protocol together, which enables notifications from any
other application protocol I think will take a very long time, if it can
even succeed.  It's hard enough getting consensus within one protocol
working group, let alone all of them working together.

Also every different protocol has different notification requirements.
trying to cover all that in a single protocol I think would be difficult.

I disagree because what I envisage for the generic notification service is an OS-level api (supplied by OS or 3rd party libraries) that implement the "internet push service protocol". What that means is that client developers only have to implement a simple api to get push notifications. What is more anyone implementing more than one protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only have to implement that once, albeit with some minor differences in regard to how to get protocol specific pieces for registering for notifications.

Your point about actually getting this done is valid. But realistically, do you really think IMAP5 is going to deploy overnight? Frankly, anyone who has a reasonably solid IMAP4 implementation today is going to question the need to work on something new, particularly if that something new brings nothing to the table (and simply fixing interop problems will probably not be seen as something "new"). If you can actually show that IMAP5 adds significant value by doing things like helping centralize push notifications, simplifying submission etc, then maybe, just maybe, those existing implementors might actually consider throwing out their current investment in IMAP4 for the new thing. But, IMHO, you are really going to have to up-sell IMAP5 to get buy-in from the major email providers. Now that does not mean it is not worth doing, but it does mean having to do more than just fixing perceived or real deficiencies. 


-- 
~Anil SRIVASTAVA
--------------080307090309020305050607-- From mrc+ietf@panda.com Mon Feb 13 10:55:44 2012 Return-Path: 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 29DFD21F8593 for ; Mon, 13 Feb 2012 10:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PZzVn3-Ij+47 for ; Mon, 13 Feb 2012 10:55:43 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0F821F854E for ; Mon, 13 Feb 2012 10:55:43 -0800 (PST) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Mon, 13 Feb 2012 10:55:27 -0800 X-MailFrom: mrc+ietf@panda.com Date: Mon, 13 Feb 2012 10:55:26 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Cyrus Daboo In-Reply-To: <4F394F0A.2080506@oracle.com> Message-ID: References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F394F0A.2080506@oracle.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:55:44 -0000 I will say this once. Then I will go back to rolling on the floor laughing at the extremely naive things that certain individuals post here. On Mon Feb 13 2012 07:20:45 GMT-0800 (PST), Cyrus Daboo wrote: > What is more anyone implementing more than one > protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only > have to implement that once, albeit with some minor differences in > regard to how to get protocol specific pieces for registering for > notifications. This should be self-evident, as is this statement: > Frankly, anyone who has a reasonably solid IMAP4 implementation today > is going to question the need to work on something new, particularly > if that something new brings nothing to the table (and simply fixing > interop problems will probably not be seen as something "new"). The IMAP5 talk is stunning and laughable in two ways. One is it that it seeks to make IMAP "simpler". The other is that it seeks to expand its scope to be Exchange. Unstated, but evident, is a third aspect: the naive notion that a protocol can be replaced without repeating the work that went into the original. History shows that the effort in any replacement is quite a bit greater. You can't escape that work no matter smart you think you are, or how much better your knowledge and tools are. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From alexey.melnikov@isode.com Mon Feb 13 11:00:50 2012 Return-Path: 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 A50BA21F869E for ; Mon, 13 Feb 2012 11:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.144 X-Spam-Level: X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] 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 jeytiuftKPEQ for ; Mon, 13 Feb 2012 11:00:50 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A71CA21F86C2 for ; Mon, 13 Feb 2012 11:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1329159648; d=isode.com; s=selector; i=@isode.com; bh=eabmZB32yTxDi3MD/DVQdz0e5TtjRh006JllwmzgNb8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=aX8LxtQpbbp9flkoBgYY5sEnTI8Z9CEo/bDQ0jYnWaotDxc++fNrn5mBH3jUKXYwbik17R eafzKlG2YCYWvP5bpPqFdqoBLPLKdWIQB1o3D9b50MUUABCvdzWfFRy1dHN2rwRpZljirT i8TbkUDhDYFBhRNQ8NZOYr4XBH1Ezew=; Received: from [192.168.1.145] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Feb 2012 19:00:48 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4F395DE0.9050400@isode.com> Date: Mon, 13 Feb 2012 19:00:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 To: Bron Gondwana References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <20120213162333.GB28443@launde.brong.net> In-Reply-To: <20120213162333.GB28443@launde.brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:00:50 -0000 On 13/02/2012 16:23, Bron Gondwana wrote: > On Mon, Feb 13, 2012 at 10:20:45AM -0500, Cyrus Daboo wrote: [...] >> Your point about actually getting this done is valid. But >> realistically, do you really think IMAP5 is going to deploy >> overnight? Frankly, anyone who has a reasonably solid IMAP4 >> implementation today is going to question the need to work on >> something new, particularly if that something new brings nothing to >> the table (and simply fixing interop problems will probably not be >> seen as something "new"). If you can actually show that IMAP5 adds >> significant value by doing things like helping centralize push >> notifications, simplifying submission etc, then maybe, just maybe, >> those existing implementors might actually consider throwing out >> their current investment in IMAP4 for the new thing. I agree. But I think another important point is that Bron not suggesting to throw away everything and start from scratch. Maybe it is just me, but I am hoping that if this effort takes off, then lots of capabilities/commands of IMAP4+extensions will be preserved as is, so that upgrading an existing IMAP4 implementation would be relatively easy. >> But, IMHO, you >> are really going to have to up-sell IMAP5 to get buy-in from the >> major email providers. Now that does not mean it is not worth doing, >> but it does mean having to do more than just fixing perceived or >> real deficiencies. From brong@fastmail.fm Mon Feb 13 11:42:26 2012 Return-Path: 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 6484D21F8495 for ; Mon, 13 Feb 2012 11:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 aKBW3vGrk58i for ; Mon, 13 Feb 2012 11:42:25 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 664A121F843E for ; Mon, 13 Feb 2012 11:42:25 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7DA0B20C15 for ; Mon, 13 Feb 2012 14:42:24 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 13 Feb 2012 14:42:24 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=axcoveLZPVIrT4bF3wj8AMip DpE=; b=oOafsFI0JByzL4oAD9vuUSfpFoBXCz6MkGVliDlygJ9f1nA5qwX0ZQXq hvyWJBzYQRvV1lA5UclVTk6Mk3Yoj4YHT9YXulqXvdzT6sfzEbi6UNkV9S8LLabC DxJCAzmZ51F30irt5vNNS7w75OiSTqS/KQpDf3dg8PT0TtXasjM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=axcoveLZPVIrT4bF3wj8AMipDpE=; b=hm/cJKWpUf5ImN72owf4iRRQMh3r Zp5efVE6csBDcvixEI44gjSbi3I3HH/Hn24YP1cQX60Vwb02Abr5+MO55wiOAQ6h XkpKZsMOyC21CHu5acPo/JICEXrAfDuZo28hjaiB1o/P+sWZuwTPuL8fMXBkFwbm c97JEYtuJwjFxis= X-Sasl-enc: hWknWjw/Ymw4AHtPvdVLKB2uPGQhzZOOluCw/BEbiOoQ 1329162144 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 32046482510; Mon, 13 Feb 2012 14:42:24 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id AF073F469B; Mon, 13 Feb 2012 20:42:22 +0100 (CET) Date: Mon, 13 Feb 2012 20:42:22 +0100 From: Bron Gondwana To: Alexey Melnikov Message-ID: <20120213194222.GA11806@launde.brong.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <20120213162333.GB28443@launde.brong.net> <4F395DE0.9050400@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F395DE0.9050400@isode.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:42:26 -0000 On Mon, Feb 13, 2012 at 07:00:48PM +0000, Alexey Melnikov wrote: > On 13/02/2012 16:23, Bron Gondwana wrote: > >On Mon, Feb 13, 2012 at 10:20:45AM -0500, Cyrus Daboo wrote: > [...] > >>Your point about actually getting this done is valid. But > >>realistically, do you really think IMAP5 is going to deploy > >>overnight? Frankly, anyone who has a reasonably solid IMAP4 > >>implementation today is going to question the need to work on > >>something new, particularly if that something new brings nothing to > >>the table (and simply fixing interop problems will probably not be > >>seen as something "new"). If you can actually show that IMAP5 adds > >>significant value by doing things like helping centralize push > >>notifications, simplifying submission etc, then maybe, just maybe, > >>those existing implementors might actually consider throwing out > >>their current investment in IMAP4 for the new thing. > I agree. But I think another important point is that Bron not > suggesting to throw away everything and start from scratch. Maybe it > is just me, but I am hoping that if this effort takes off, then lots > of capabilities/commands of IMAP4+extensions will be preserved as > is, so that upgrading an existing IMAP4 implementation would be > relatively easy. Absolutely preserved in semantics if not in syntax. The semantics are pretty good, mostly - and the ones that I don't like are mostly the "magic" bits. Being able to plug this in as another access method to an already existing IMAP store is a very important property - at most it would require a little extra indexing if you want to be efficient. Even more ideally, you could implement a connector either way at a loss of efficiency - an (at least basic) IMAP connector in front of this protocol, or a proxy for this protocol (caching quite a lot more information probably - particularly if the backend didn't have a concept of MODSEQ) in front of an existing IMAP store. Bron. From adrien@qbik.com Thu Feb 9 00:05:59 2012 Return-Path: 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 DDF7621F8546 for ; Thu, 9 Feb 2012 00:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=-3.979, 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 s+7Zqdj980Xz for ; Thu, 9 Feb 2012 00:05:58 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id EEE7B21F8543 for ; Thu, 9 Feb 2012 00:05:57 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3379)) with SMTP id <0018854642@smtp.qbik.com>; Thu, 09 Feb 2012 21:05:53 +1300 Message-ID: <4F337E61.5040702@qbik.com> Date: Thu, 09 Feb 2012 21:05:53 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: thomas@koch.ro References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> In-Reply-To: <201202090820.28260.thomas@koch.ro> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Feb 2012 11:43:57 -0800 Cc: ietf-imapext@imc.org, imap5@ietf.org, IMAP Protocol Interest List Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:06:00 -0000 Whilst HTTP could certainly be used to put together an email system, I don't think it would perform well enough to replace existing protocols on desktops. The main issues I see are: * updates. Would need to poll or use long polling to get real-time updates (e.g. notification of incoming mail). * slow. Gut feel based on 17 years writing http proxies is that it would be too slow * complex. In order to reduce round-trips, you'd have to do many things in a single transaction, which would create complexity issues in the server and client * protocol bloat. if you think IMAP is bloated, try HTTP. * fundamentally an off-line style protocol for mail, which has strong incentives to be online (esp for in-office use). I think it would also be very problematic in the wild, since any http intermediary would feel entitled to mess with traffic. E.g. heuristic caching, intercepting proxies etc. It's almost too ubiquitous. Everyone and their dog thinks they know how http works. It's not strictly-enough defined, and has a LOT of optional features which aren't relevant for mail (e.g. content negotiation). Interop in http is already problematic, but start getting people writing mail servers in php etc, and see what starts to happen. I think it would be a nightmare. Adrien On 9/02/2012 8:20 p.m., Thomas Koch wrote: > Bron Gondwana: >> Snide comments from those who don't agree with the goals are welcome too... >> I just won't listen to you. These goals are very important to me. > Hi Bron, > > I'm not an expert in IMAP, just got here out of curiosity about Kolab[1]'s use > of IMAP folders as data stores. > I found some older initiatives to replace IMAP with an HTTP based approach.[2] > What do you think of HTTP for mail access? For my bachelor thesis[3] I > currently argue that CardDAV/CalDAV could be perfectly replaced by AtomPub > (RFC 5023). > The main advantage would be that most software developers on this planet have > some vague understanding of HTTP and that imense infrastructure and software > already exists. > > [1] http://wiki.kolab.org/Why_IMAP_Is_Used_For_Storage > [2] http://www.prescod.net/rest/restmail/ > https://www.ietf.org/mailman/listinfo/httpmail > [3] https://github.com/thkoch2001/bachelor-thesis > > Best regards, > > Thomas Koch, http://www.koch.ro > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From adrien@qbik.com Thu Feb 9 03:46:09 2012 Return-Path: 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 6FF6521F870B for ; Thu, 9 Feb 2012 03:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=-3.713, 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 DxkSXkdtj7Zm for ; Thu, 9 Feb 2012 03:46:08 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id F33A321F8700 for ; Thu, 9 Feb 2012 03:46:07 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3379)) with SMTP id <0018854989@smtp.qbik.com>; Fri, 10 Feb 2012 00:46:05 +1300 Message-ID: <4F33B1F4.4010104@qbik.com> Date: Fri, 10 Feb 2012 00:45:56 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Bron Gondwana References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <20120209112411.GB29734@launde.brong.net> In-Reply-To: <20120209112411.GB29734@launde.brong.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Feb 2012 11:43:57 -0800 Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 11:46:09 -0000 On 10/02/2012 12:24 a.m., Bron Gondwana wrote: > On Thu, Feb 09, 2012 at 09:05:53PM +1300, Adrien de Croy wrote: >> Whilst HTTP could certainly be used to put together an email system, >> I don't think it would perform well enough to replace existing >> protocols on desktops. >> >> The main issues I see are: >> >> * updates. Would need to poll or use long polling to get real-time >> updates (e.g. notification of incoming mail). > Yes - long polling or "out of band" notification systems. We have > an HTTP protocol defined kind of "on top of" IMAP plus our own > extensions here at FastMail/Opera (mail.opera.com if you want to > play with it) if you compare the overhead / complexity in setting up the poll (on a separate connection), and re-sending the poll request each time it's completed by the server (or timed out by an intermediary etc), it's a particularly inelegant and wasteful way to get a notification. It's done this way in HTTP because that's the only way to do it, but let's face it, it's a fairly ugly hack. > > We are currently using EventSource to notify the client that > "there is something new", after which the client queries to > find what's updated. > > This is possible to be efficient because we use a single counter > for uidvalidity and a single counter for highestmodseq across the > entire user's folders - so any change to uidvalidity means the > folder list needs refreshing, and any change to highestmodseq > means the message view needs checking. > > Combined with efficient "what's changed in this view since my > previous modseq value" queries, it's very bandwidth efficient. > >> * slow. Gut feel based on 17 years writing http proxies is that it >> would be too slow > Not really actually - so long as you can query multiple things in > a single "transaction" > >> * complex. In order to reduce round-trips, you'd have to do many >> things in a single transaction, which would create complexity issues >> in the server and client > But here's the rub. Yes, complex. > >> * protocol bloat. if you think IMAP is bloated, try HTTP. >> * fundamentally an off-line style protocol for mail, which has >> strong incentives to be online (esp for in-office use). > Mostly facebook's "live feed" is plenty fast enough. People are > doing all sorts of close-enough-to-real-time stuff on top of HTTP. > It doesn't mean it's the right choice, but I wouldn't dismiss it > out of hand either. it might seem quick enough for a human, but not all mail clients are humans. E.g. EDI systems etc. I wouldn't dismiss HTTP out of hand either, but I would take some convincing, and the work that would be required to specify the requests and responses (would you use SOAP-RPC?) would be not much less (if any) than that required to do a nice slim efficient and blindingly quick specialised protocol. In fact, since mobile devices are going to probably be the primary agents for mail, we really should be looking at a binary protocol? Just not ASN.1 BER :) >> I think it would also be very problematic in the wild, since any >> http intermediary would feel entitled to mess with traffic. E.g. >> heuristic caching, intercepting proxies etc. > That's a problem for sure. Mind you, proxyability is high on my > list of goals. Immutable stuff should be cachable. caches impose their own beliefs on what is cachable and for how long. > >> It's almost too ubiquitous. Everyone and their dog thinks they know >> how http works. It's not strictly-enough defined, and has a LOT of >> optional features which aren't relevant for mail (e.g. content >> negotiation). Interop in http is already problematic, but start >> getting people writing mail servers in php etc, and see what starts >> to happen. I think it would be a nightmare. > Like IMAP then, except only their dogs actually understand it ;) > > Good enough tests should, in theory, allow people to write their > servers in PHP if they want to. Why you would choose to write in > PHP, I'm not sure... but still. It takes all types. it sure does :) Adrien > > Bron. > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From brong@fastmail.fm Mon Feb 13 11:52:57 2012 Return-Path: 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 3BFB121F8698 for ; Mon, 13 Feb 2012 11:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.592 X-Spam-Level: X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 db-QlBU6bOGe for ; Mon, 13 Feb 2012 11:52:56 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 167F521F8697 for ; Mon, 13 Feb 2012 11:52:56 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BF0F920F5F for ; Mon, 13 Feb 2012 14:52:55 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 13 Feb 2012 14:52:55 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=OIPBE4cUjoyEDQctYS0fT3N2 n/4=; b=laYDE+7RZGD8XhjP0/s+C99nbzsrAHFlFA+rZv9gcVfZb8vrYwrWR9Qa 32Uv0Lt7DlNZOG0drqBBLTZk5kFKqsqFfM9C4B4denQpaT59YnQBM46v2Umjh/I9 tm4BI/ZFj/rXdaS5MgPTwM9mrHrWR7JtsiQRhFlJP5iYYnCwvcY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=OIPBE4cUjoyEDQctYS0fT3N2n/4=; b=GoopAGGBwI8rY3paZ8sWhmR5RV0f gPyCFtTFaPSrwy04jyubniSdp86S1hiF+N1Ja6rGaDfSWcQTLsunnymmf4Bd6maV UjnTKwd0nTy1GvypULbirARPIOUKkeKqyWnJK3Ze9rXpdbhGEpZERnqxic0edZvK a4E7Xk+q7kn+gvo= X-Sasl-enc: J31zfcsvafG8dxmUupYR9a4lS8CNapUvStJi3cdLHszf 1329162775 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 50FDC8E00C7; Mon, 13 Feb 2012 14:52:55 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id D9B99F46A1; Mon, 13 Feb 2012 20:52:53 +0100 (CET) Date: Mon, 13 Feb 2012 20:52:53 +0100 From: Bron Gondwana To: Mark Crispin Message-ID: <20120213195253.GB11806@launde.brong.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F394F0A.2080506@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:52:57 -0000 On Mon, Feb 13, 2012 at 10:55:26AM -0800, Mark Crispin wrote: > I will say this once. Then I will go back to rolling on the floor laughing > at the extremely naive things that certain individuals post here. Go for it. I said the comments of haters who want to hate were welcome too, and I stand by it. > On Mon Feb 13 2012 07:20:45 GMT-0800 (PST), Cyrus Daboo wrote: > >What is more anyone implementing more than one > >protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only > >have to implement that once, albeit with some minor differences in > >regard to how to get protocol specific pieces for registering for > >notifications. > > This should be self-evident, as is this statement: > > >Frankly, anyone who has a reasonably solid IMAP4 implementation today > >is going to question the need to work on something new, particularly > >if that something new brings nothing to the table (and simply fixing > >interop problems will probably not be seen as something "new"). > > The IMAP5 talk is stunning and laughable in two ways. One is it that it > seeks to make IMAP "simpler". The other is that it seeks to expand its > scope to be Exchange. Simpler as in more regular data model, removing the unnecessary complexity, not the inherent complexity. I believe there is a reasonable pool of unnecessary complexity involved in both ends of IMAP which isn't inherent in the task of viewing and managing email, but is instead caused by the layers of protocol on top - both the irregular syntax of the different layers, and the MSGNO model with its artifacts like 'UNSEEN' which don't match the way in which email is being presented and managed by existing clients today. And then there's the need to support even more parsers and protocol agents for SIEVE, ACAP, and good old SMTP/Submission, plus the support headaches involved in firewall issues. For the 99% case of a client wanting to send an email via the same infrastructure where it stores its email, a basic submission will be sufficient. All of which I've said plenty of times before. I've even added xmove and xsend to Cyrus now. XMOVE is already in use for our own web interface code, removing all the quota issues we used to have with the "Delete to Trash" model, and the crazy workarounds like deleting a small number of messages at a time. There's a draft in progress, and I made sure our implementation is compatible with all the MUSTs. > Unstated, but evident, is a third aspect: the naive notion that a protocol > can be replaced without repeating the work that went into the original. > History shows that the effort in any replacement is quite a bit greater. I'm expecting to do a lot of work. I'm not afraid of work. I'm afraid of getting so bogged down saying it can't be done that we waste another 10 years. > You can't escape that work no matter smart you think you are, or how much > better your knowledge and tools are. You can escape the worst parts of the work by using what already exists, and by not re-inventing every wheel along the way, but by looking at some of the wheels that are a lot smoother than they were 20 years ago. I would prefer to have you involved than sitting on the sidelines laughing, but I'd prefer to do something than listen to you saying it can't be done. Maybe I'll burn out along the way, maybe not. I'm still going to try. Bron. From mrc+ietf@panda.com Mon Feb 13 12:27:01 2012 Return-Path: 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 CFCA621E801A for ; Mon, 13 Feb 2012 12:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9Jb7yg28T2-f for ; Mon, 13 Feb 2012 12:27:01 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id E0CAA21E801B for ; Mon, 13 Feb 2012 12:27:00 -0800 (PST) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Mon, 13 Feb 2012 12:26:55 -0800 X-MailFrom: mrc+ietf@panda.com Date: Mon, 13 Feb 2012 12:26:53 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Bron Gondwana In-Reply-To: <20120213195253.GB11806@launde.brong.net> Message-ID: References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F394F0A.2080506@oracle.com> <20120213195253.GB11806@launde.brong.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:27:01 -0000 On Mon, 13 Feb 2012, Bron Gondwana wrote: > Go for it. I said the comments of haters who want to hate were > welcome too, and I stand by it. Bwahahahaha! Complaining about "haters" just like a 13-year-old girl! If you really were competent enough to do what you purpose to do, you would babble less about "haters" (and public proclamations of what you purpose to do), and instead go off quietly on your own to do it. You'd also stay quiet about it until you had something concrete to show for it. "Concrete" means a written specification and interoperable code, both of which can be reviewed. Then it goes the entire IETF process, in which everybody and his grandmother weights in on how to "improve" what you have done (so much for "regularity" and "consistency" as each "improvement" goes in). Then, and only then, you try to convince the Big Players that they is a compelling reason why they should adopt it instead of IMAP. I know how long it took me, and I wasn't trying to replace something that was already widely deployed. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From adrien@qbik.com Mon Feb 13 12:27:28 2012 Return-Path: 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 2F8B321F8595 for ; Mon, 13 Feb 2012 12:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.81 X-Spam-Level: X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=-3.341, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] 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 xeoHOb1aYbUz for ; Mon, 13 Feb 2012 12:27:27 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8007B21F848C for ; Mon, 13 Feb 2012 12:27:26 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018861388@smtp.qbik.com>; Tue, 14 Feb 2012 09:27:23 +1300 Message-ID: <4F397212.1030107@qbik.com> Date: Tue, 14 Feb 2012 09:26:58 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Cyrus Daboo References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:27:28 -0000 Hi Cyrus I guess we are on different pages for what we want out of a mail protocol and where we want it to go. Sorry if this mail rambles a bit. Also taking into account Mark and others' comments. Maybe we need to start with what we want to achieve... which actually Bron did do at the start. All of us have various different histories when it comes to mail. When I first implemented our IMAP server, I was firstly struck by the unusual syntax, parsing requirements, and then the missing bits - lack of completely defined folder management protocol support, and the highly problematic dual-indexing (no UID in expunge response!!!). History obviously plays a huge part, but it's not 1998 any more. Then I was hit with the quirks of the implementations (e.g. TB ignores unsolicited responses unless it issued an IDLE). I've spent a lot of time evaluating IMAP clients, none of them are what I would call great (for my use). In terms of features, it seems over half the feature set nowadays is optional protocol extensions, which basically means no-one can count on them being there. So, I'm approaching this whole thing from a mail-user perspective, since I also am one. I think usability could be greatly improved if the protocol supported it. My issue with XMPP isn't with the protocol per-se, but just that if you're outside a firewall, someone needs to open another hole so you can access the XMPP server. It introduces another point of failure for the system. If we were to rely on XMPP for notifications, we would just be adding support tickets like "my mail client doesn't notify me when I get new mail". I already get "I can retrieve mail but not send". Also you then need to have hooks into it at both ends, and define some sort of addressing system so the XMPP server can know what the client wants it to provide notifications about, and hooks in the back end of the services so it can get them. Lots of points of failure. I don't know how many of you spend a lot of time on customer support desks. I do. So I think maybe we need to take a step back. If we want people to implement something new, it has to have some compelling reasons. I don't think just interop is that compelling since it's not completely awful at the moment, and I think that is not thinking big enough. We could do so much more. If we're going to do a new mail protocol, we need to think what we want it to be like, with the benefit of however many decades of experience. Mark is right in that the problems that IMAP solves are often problems that will also need solutions in a new system. I don't believe implementing a new protocol means doing all that work again. I've refactored enough code to know the thing you keep is the knowledge, even if the syntax changes. So, anyway for me an incremental change to IMAP isn't horribly interesting. Sure we can fix some things, but the way the protocol is extended and requirement for backwards compatibility is always going to hamstring us. For me something more interesting would be a protocol that allows a client to provides the best possible mail user experience. And doing that using a single connection. The reason for a single connection (could maybe be relaxed to a single port) is simply to reduce deployment issues. One username, one password, one port to open. That's the minimum number of things to go wrong, and minimum number of things to support. If a vendor knows that by moving to a new mail protocol their customer support issues can halve, that's very compelling. If a vendor knows that by using a new protocol they can drastically improve their users' mail experience, that's very compelling. For me, I'd like something that: * is fast, even over low bandwidth or latent connections * is simple to deploy for administrators and users * gives me all the mail functions I could need, including calendar etc. * gives me cool new functions, like telling me the mail address I just typed into the destination field is bad even before I finished typing the subject line. * works well with multiple clients (e.g. home and office, and on the road) And no, I don't believe for a second this will happen overnight. Cheers Adrien On 14/02/2012 4:20 a.m., Cyrus Daboo wrote: > Hi Adrien, > > --On February 13, 2012 10:56:49 AM +1300 Adrien de Croy > wrote: > >>> So, in my opinion, whilst push notifications should be a requirement >>> for imap5, we should not define that protocol and instead push the >>> IETF to provide such a protocol for general use. >>> >> >> I don't think that's a workable approach. >> >> Getting such a protocol together, which enables notifications from any >> other application protocol I think will take a very long time, if it can >> even succeed. It's hard enough getting consensus within one protocol >> working group, let alone all of them working together. >> >> Also every different protocol has different notification requirements. >> trying to cover all that in a single protocol I think would be >> difficult. > > I disagree because what I envisage for the generic notification > service is an OS-level api (supplied by OS or 3rd party libraries) > that implement the "internet push service protocol". What that means > is that client developers only have to implement a simple api to get > push notifications. What is more anyone implementing more than one > protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only > have to implement that once, albeit with some minor differences in > regard to how to get protocol specific pieces for registering for > notifications. > > Your point about actually getting this done is valid. But > realistically, do you really think IMAP5 is going to deploy overnight? > Frankly, anyone who has a reasonably solid IMAP4 implementation today > is going to question the need to work on something new, particularly > if that something new brings nothing to the table (and simply fixing > interop problems will probably not be seen as something "new"). If you > can actually show that IMAP5 adds significant value by doing things > like helping centralize push notifications, simplifying submission > etc, then maybe, just maybe, those existing implementors might > actually consider throwing out their current investment in IMAP4 for > the new thing. But, IMHO, you are really going to have to up-sell > IMAP5 to get buy-in from the major email providers. Now that does not > mean it is not worth doing, but it does mean having to do more than > just fixing perceived or real deficiencies. > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From brong@fastmail.fm Mon Feb 13 12:38:01 2012 Return-Path: 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 BA7B521E8029 for ; Mon, 13 Feb 2012 12:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.593 X-Spam-Level: X-Spam-Status: No, score=-3.593 tagged_above=-999 required=5 tests=[AWL=0.007, 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 oMGTtW-QPHI1 for ; Mon, 13 Feb 2012 12:38:00 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1470321E801B for ; Mon, 13 Feb 2012 12:38:00 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BBABF20EDD for ; Mon, 13 Feb 2012 15:37:59 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 13 Feb 2012 15:37:59 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=wLt/zS4kIe950fQKAWLYvBma 56s=; b=SSF7+Yf9jXjH9GsU7idoLNUmmKdwDB0DmmQKehb1ob2JclmsogGur4t5 i5ViXB4Zwj3471QXtQj0A9PCvkd4AH4I10O6J42VvjQzodSTjKx3YEi37p4CKi+D m9CwsQiI6Ycl/+16H7xNMx7RBTpJLW8WQvorDI7YymxnlmpPqpI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=wLt/zS4kIe950fQKAWLYvBma56s=; b=LCtwAIlh51eJhGP60tRAuHAesT8s 6DPQYG/CpgTombcwOfxnHf1Tf66A3S1eLT2LDRNchf2F7ERumHC0lQXgkspFlpj1 G5DKW9/7cGWHI74z7mh8FN8k6LvIFUEm22jRKmo1v6qg6P1sRwFGOTyNUkPJygs7 OSZw94sVl7viYgc= X-Sasl-enc: j3O0cZj2Ypzrr+XXKLQ99mxC1OKeDSpppnIZ0uW++T5D 1329165479 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4D5BE8E00DA; Mon, 13 Feb 2012 15:37:59 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 026F0F469B; Mon, 13 Feb 2012 21:37:57 +0100 (CET) Date: Mon, 13 Feb 2012 21:37:57 +0100 From: Bron Gondwana To: Mark Crispin Message-ID: <20120213203757.GA13029@launde.brong.net> References: <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F394F0A.2080506@oracle.com> <20120213195253.GB11806@launde.brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:38:01 -0000 On Mon, Feb 13, 2012 at 12:26:53PM -0800, Mark Crispin wrote: > On Mon, 13 Feb 2012, Bron Gondwana wrote: > >Go for it. I said the comments of haters who want to hate were > >welcome too, and I stand by it. > > Bwahahahaha! Complaining about "haters" just like a 13-year-old girl! Yo, I'm down with the kids, dawg. Or something. > If you really were competent enough to do what you purpose to do, you > would babble less about "haters" (and public proclamations of what you > purpose to do), and instead go off quietly on your own to do it. You'd > also stay quiet about it until you had something concrete to show for it. I want to talk to other people about what they need as well rather than just making everything up myself. Sorry for disturbing you with it. > "Concrete" means a written specification and interoperable code, both of > which can be reviewed. Then it goes the entire IETF process, in which > everybody and his grandmother weights in on how to "improve" what you have > done (so much for "regularity" and "consistency" as each "improvement" > goes in). Then, and only then, you try to convince the Big Players that > they is a compelling reason why they should adopt it instead of IMAP. > > I know how long it took me, and I wasn't trying to replace something that > was already widely deployed. It's true - the mountain looks very tall from the bottom - and you have climbed a mountain, which I haven't. It's not exactly the same mountain though, and we don't have exactly the same equipment. Feel free to keep laughing, but I'm starting climbing. And I'd rather do it in public than in secret right up until the IETF process bit. Do you still have your un-"improved" specification and interoperable code sitting around somewhere that you can show us all how nice it was before the grandmothers improved it? I'd be interested to see so I can tell what I'm in for. Thanks, Bron. From brong@fastmail.fm Mon Feb 13 13:08:12 2012 Return-Path: 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 A04F021F8484 for ; Mon, 13 Feb 2012 13:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.593 X-Spam-Level: X-Spam-Status: No, score=-3.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 PPq7Q7gHjF4j for ; Mon, 13 Feb 2012 13:08:11 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7293021F8463 for ; Mon, 13 Feb 2012 13:08:11 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DAFBD2095D for ; Mon, 13 Feb 2012 16:08:07 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 13 Feb 2012 16:08:07 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=/d0X0vTs1ctr9TigcS5lbdjx eF4=; b=lE2qG7IWycmJckOIzHOwDtrIMSUU1VTErCQyDN+yR6CGxa3OTDXBOiyF O1lqdXet+Zw3U9H5abX52S7K9Zi1S/hnfZgBnfQwpzUnB4KjMeNtPCJuDCnq6J3M CCnW9eYlFWaAe1xkpicNyFyj7tspYHGx17jfZWkD9owZuFBrQGY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=/d0X0vTs1ctr9TigcS5lbdjxeF4=; b=O/tDoBvPA/bbLswy5fBds+m48hfB 2sH8ELFuEk5ybQznKNF0ngUeMdK5yx9BXUAUVYCQ6pLyCeL1TNxdDy3Qi9uzT28Y muUcHk8I4s9DpRAO9Wt5jmAmOCzxkjm3fbAk7voNoK7DLls3YExDizl11JUVW1ov 7kN16w12HFV6hnE= X-Sasl-enc: winP3Fm1XoeYn03/qtnACmkZMlYm4/xwya5o5tyApbFv 1329167287 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 660C68E0156; Mon, 13 Feb 2012 16:08:07 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id EB877F469B; Mon, 13 Feb 2012 22:08:05 +0100 (CET) Date: Mon, 13 Feb 2012 22:08:05 +0100 From: Bron Gondwana To: Adrien de Croy Message-ID: <20120213210805.GB13029@launde.brong.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F397212.1030107@qbik.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:08:12 -0000 On Tue, Feb 14, 2012 at 09:26:58AM +1300, Adrien de Croy wrote: > Maybe we need to start with what we want to achieve... which > actually Bron did do at the start. All of us have various different > histories when it comes to mail. Oh yeah, so I did... it feels like a long time ago already! > When I first implemented our IMAP server, I was firstly struck by > the unusual syntax, parsing requirements, and then the missing bits > - lack of completely defined folder management protocol support, and > the highly problematic dual-indexing (no UID in expunge > response!!!). History obviously plays a huge part, but it's not > 1998 any more. Folder management is amazingly complex now that all the LIST-EXT stuff is in there, and interactions with "subscriptions" - complete with the whole "subscription has to survive when folder is deleted" funkyness. It's amazing how the best intentions have created a mess there. > Then I was hit with the quirks of the implementations (e.g. TB > ignores unsolicited responses unless it issued an IDLE). I've spent > a lot of time evaluating IMAP clients, none of them are what I would > call great (for my use). Mark will agree there I think. Me too. I use offlineimap and mutt with Maildirs still. It's not awesome, but at least I can edit my email in vim. > In terms of features, it seems over half the feature set nowadays is > optional protocol extensions, which basically means no-one can count > on them being there. I covered that in detail. Optional is useless for a client writer, because they have to support both options, and that's twice as much code to write and debug and keep in sync. So they don't bother unless the benefits are huge - they just write to the lowest common denominator. > [ extra protocol is adds too many support headaches ] > > So I think maybe we need to take a step back. If we want people to > implement something new, it has to have some compelling reasons. I > don't think just interop is that compelling since it's not > completely awful at the moment, and I think that is not thinking big > enough. We could do so much more. If we're going to do a new mail > protocol, we need to think what we want it to be like, with the > benefit of however many decades of experience. Absolutely agree. And my experience alone isn't enough, which is why I don't want to go hide in a dark room and make one up out of whole cloth. I may have tried that a few years ago, but talking to others at Fosdem in particular showed that I don't have all the right answers. I need to listen to other people who actually believe in making this protocol too. I'm willing to do a lot of the hard labour in getting the implementations and TESTS done. The tests are even more important than the code, because that's how you keep implementations compatible. I think that's something we have learned in the past 20 years. Wordy specs don't do as much for compatibility as automated tests which can be run against an implementation and show immediately if it's doing the right thing or not. Saying "you fail test XYZ, and here's how you can test against it until you have fixed your code" is much more effective than saying "go read all the documents again you moron, and make sure you understand them properly before you try to implement anything" > Mark is right in that the problems that IMAP solves are often > problems that will also need solutions in a new system. I don't > believe implementing a new protocol means doing all that work again. > I've refactored enough code to know the thing you keep is the > knowledge, even if the syntax changes. So, anyway for me an > incremental change to IMAP isn't horribly interesting. Sure we can > fix some things, but the way the protocol is extended and > requirement for backwards compatibility is always going to hamstring > us. And the first part of "not doing all the work again" is looking at what we have now. Every RFC and draft is the result of somebody feeling enough pain from what's there now to sit down and write up how they think their pain can be solved, and shepherd it through the standards process. That's a lot of effort. Those are important problems, and valuable thought has gone into them. Maybe some of them will be solved as a side effect of discarding backwards compatibility at the protocol level. I sure hope so, because otherwise it's not worth it. > For me something more interesting would be a protocol that allows a > client to provides the best possible mail user experience. And doing > that using a single connection. God yes. That's what it's all about. > The reason for a single connection (could maybe be relaxed to a > single port) is simply to reduce deployment issues. One username, > one password, one port to open. That's the minimum number of things > to go wrong, and minimum number of things to support. I think it has to be a single port. Otherwise you wind up having to multiplex EVERYTHING. Ouch. But one username, one password, potentially a "sessionid" from the initial login which can be used by the further connections. I think SCTP is not well enough supported to use, unfortunately, because it would be a great way to deal with the multiple connections issue otherwise. There's a lot of potentially great technology out there which just isn't right for the problem. We have to be pragmatic as well - it has to be stupidly simple for administrators and users to deal with. > If a vendor knows that by moving to a new mail protocol their > customer support issues can halve, that's very compelling. > If a vendor knows that by using a new protocol they can drastically > improve their users' mail experience, that's very compelling. Yes. > For me, I'd like something that: > > * is fast, even over low bandwidth or latent connections > * is simple to deploy for administrators and users These two are non-negotiable for me. > * gives me all the mail functions I could need, including calendar etc. This one is slightly more negotiable. I think we could easily over-reach in this. I'd like to do a "version 1" which doesn't go quite so far beyond what's there now. That said, there's the Kolab work to create a "Calendar Mailbox" which is just a bunch of messages with a specified attachment type, one message per calendar entry. That plus a "\Calendar special use" or similar could get you a working calendar system without needing too much complexity. > * gives me cool new functions, like telling me the mail address I > just typed into the destination field is bad even before I finished > typing the subject line. That one's tricky. I'd almost outsource that to a webservice rather than being "in-protocol". This being offline temporarily is annoying, but not fatal to the user experience, and it's cachable and doesn't necessarily need authentication. > * works well with multiple clients (e.g. home and office, and on the road) That's the one thing IMAP really has going for it already, but we can get a bit better. > And no, I don't believe for a second this will happen overnight. Nup. Bron. From mrc+ietf@panda.com Mon Feb 13 13:37:23 2012 Return-Path: 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 F0CCB21E8049 for ; Mon, 13 Feb 2012 13:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 OB2VBMjBgMRV for ; Mon, 13 Feb 2012 13:37:23 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id A111D21E8044 for ; Mon, 13 Feb 2012 13:37:22 -0800 (PST) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Mon, 13 Feb 2012 13:37:15 -0800 X-MailFrom: mrc+ietf@panda.com Date: Mon, 13 Feb 2012 13:37:14 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Bron Gondwana In-Reply-To: <20120213203757.GA13029@launde.brong.net> Message-ID: References: <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F394F0A.2080506@oracle.com> <20120213195253.GB11806@launde.brong.net> <20120213203757.GA13029@launde.brong.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:37:24 -0000 On Mon, 13 Feb 2012, Bron Gondwana wrote: > And I'd rather do it in public than > in secret right up until the IETF process bit. You will never make much progress as long as the initial design process is burdened with that monkey on its back. The best way to destroy any project is to subject it to review at that stage. > Do you still have your un-"improved" specification and interoperable > code sitting around somewhere that you can show us all how nice it was > before the grandmothers improved it? I'd be interested to see so I > can tell what I'm in for. Knowledge of the original IMAP (before IMAP2) exists primarily in my mind as all the original IMAP specifications and implementations were replaced with IMAP2. The only substantial difference between original IMAP and IMAP2 was the introduction of tags in IMAP2. In original IMAP, a response started with one of "OK", "NO", "BAD", "BYE", or "*". That incompatibility is caused the "2". Since it was still possible to replace all the "old protocol" implementations, there was no attempt at IMAP/IMAP2 compatibility. A secondary effect was the much-maligned advent of untagged OK/NO/BAD responses. As it turned out, tags never were as important for pipelining as its advocates claimed. The vast majority of Internet protocols pipeline do just fine without tags, although I admit ManageSieve did it in a cool way. The motivation for tags was the quaint idea (which I never believed back then) that an IMAP server will routinely have requests blocked while waiting for the computer operator to mount a 9-track tape or optical disk. Thus it was purportedly important for responses to arrive out of order for the request, and all clients must be completely asynchronous. Of course, that never happened... Post-IMAP2, there are all the past IMAP RFCs. The ftp.cac.washington.edu FTP site still has many of the IMAP2bis drafts on the mail/old/ directory, as well as the RFC drafts. There is quite a lot to review there. The history of IMAP2bis is particularly important, as it explains a great deal of the process from RFC 1176 to RFC 1730 which would otherwise be an unbridgeable gap. In turn, RFC 1730 to RFC 2060 shows what happens when a set of last-minute additions (to RFC 1730) are put in without adequate thought and consideration. There is a BIG lesson to learn from that abortion. RFC 2060 is the RFC 1176 replacement protocol in more or less final form. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From fanf2@hermes.cam.ac.uk Wed Feb 15 06:11:36 2012 Return-Path: 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 6AE1021F879D for ; Wed, 15 Feb 2012 06:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.073 X-Spam-Level: X-Spam-Status: No, score=-5.073 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 DtpT906y2GTc for ; Wed, 15 Feb 2012 06:11:32 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0E22B21F867A for ; Wed, 15 Feb 2012 06:11:31 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43518) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1RxfZY-0005bF-EG (Exim 4.72) (return-path ); Wed, 15 Feb 2012 14:11:04 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RxfZY-0000BH-A6 (Exim 4.67) (return-path ); Wed, 15 Feb 2012 14:11:04 +0000 Date: Wed, 15 Feb 2012 14:11:04 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Bron Gondwana In-Reply-To: <20120213210805.GB13029@launde.brong.net> Message-ID: References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:11:36 -0000 Bron Gondwana wrote: > > Folder management is amazingly complex now that all the LIST-EXT > stuff is in there, and interactions with "subscriptions" - complete > with the whole "subscription has to survive when folder is deleted" > funkyness. It's amazing how the best intentions have created a mess > there. Is there any reason to keep subscriptions in IMAP 5 ? Tony. -- f.anthony.n.finch http://dotat.at/ Dogger, Fisher, German Bight, Humber, Thames: Northwest backing west 5 to 7, occasionally gale 8 at first, decreasing 4 at times. Rough or very rough, becoming moderate or rough. Occasional rain. Moderate or good. From tss@iki.fi Wed Feb 15 06:18:54 2012 Return-Path: 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 A94DE21F871B for ; Wed, 15 Feb 2012 06:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.261 X-Spam-Level: X-Spam-Status: No, score=-106.261 tagged_above=-999 required=5 tests=[AWL=4.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 L6YC1qwUH6Q8 for ; Wed, 15 Feb 2012 06:18:53 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6084421F862F for ; Wed, 15 Feb 2012 06:18:53 -0800 (PST) Received: from [10.10.2.201] (unknown [193.184.212.30]) by dovecot.org (Postfix) with ESMTP id EBDBC1AE876C; Wed, 15 Feb 2012 16:18:51 +0200 (EET) Message-ID: <1329315531.11500.183.camel@innu> From: Timo Sirainen To: Tony Finch Date: Wed, 15 Feb 2012 16:18:51 +0200 In-Reply-To: References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.1- Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:18:54 -0000 On Wed, 2012-02-15 at 14:11 +0000, Tony Finch wrote: > Bron Gondwana wrote: > > > > Folder management is amazingly complex now that all the LIST-EXT > > stuff is in there, and interactions with "subscriptions" - complete > > with the whole "subscription has to survive when folder is deleted" > > funkyness. It's amazing how the best intentions have created a mess > > there. > > Is there any reason to keep subscriptions in IMAP 5 ? Somewhat more generic mailbox tags would be useful. So I could configure my IMAP client to show a view of only mailboxes related to e.g. "work", "mobile", etc. This could be done generically by assigning some metadata tags to mailboxes and having a LIST command that supports filtering using metadata. Of course clients would have to support it also somehow. From brong@fastmail.fm Wed Feb 15 06:19:18 2012 Return-Path: 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 6DE1721F862F for ; Wed, 15 Feb 2012 06:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 pE1f5pER-Ng0 for ; Wed, 15 Feb 2012 06:19:13 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4973321F85D2 for ; Wed, 15 Feb 2012 06:19:13 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 370D5206FE for ; Wed, 15 Feb 2012 09:19:12 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute5.internal (MEProxy); Wed, 15 Feb 2012 09:19:12 -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:in-reply-to:references:subject:date; s=mesmtp; bh= aMGKp0m7Am/dwyKE2vgR/HdOhvI=; b=R35A6Mb2eeTxOdVJ17G1DEZr8DTZhcc4 e+dhcxJW4MVVwcYGDyLtNg9zW6aDPZGUhFlrp2Yz4oYhN/o/dBcjaY1pBt7E9kOf vpiEq/KWeNhh3EJjnlpex4pyD2Ykv/nkJmypbxrwvd3JhRctuH3UlBvtflNdaOb1 Yh6QvbxMSgE= 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:in-reply-to:references :subject:date; s=smtpout; bh=aMGKp0m7Am/dwyKE2vgR/HdOhvI=; b=kU1 Cv5WXZpGDO/7m5KjR3UB1Q1NMY5NUmDNrmV2woibWEj5DmfFsEZabGbsZ9LY76kI X8VPa51aFiweJn/iDxUe+JB71klNyTD1XLFw4+X5ujlPCXetw74C7P6M3H9SQ9im H0qe1/TrFiKMpphfr1oMpATRzQbELx+aGrej8KDQ= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 126A9A000B6; Wed, 15 Feb 2012 09:19:12 -0500 (EST) Message-Id: <1329315552.1444.140661036879893@webmail.messagingengine.com> X-Sasl-Enc: kidg2XpfxdRJX7MHUP86acH97sRxVEc4fjWrOK655ahu 1329315552 From: Bron Gondwana To: Tony Finch MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> Date: Wed, 15 Feb 2012 15:19:12 +0100 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:19:18 -0000 On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote: > Bron Gondwana wrote: > > > > Folder management is amazingly complex now that all the LIST-EXT > > stuff is in there, and interactions with "subscriptions" - complete > > with the whole "subscription has to survive when folder is deleted" > > funkyness. It's amazing how the best intentions have created a mess > > there. > > Is there any reason to keep subscriptions in IMAP 5 ? I envisage "subscription" as either an annotation or a "Special Use" on a folder rather than yet another axis of data. Bron. -- Bron Gondwana brong@fastmail.fm From alexey.melnikov@isode.com Wed Feb 15 06:22:31 2012 Return-Path: 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 F337B21F84F7 for ; Wed, 15 Feb 2012 06:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.221 X-Spam-Level: X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wvREAeUO6rJg for ; Wed, 15 Feb 2012 06:22:25 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7836321F8777 for ; Wed, 15 Feb 2012 06:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1329315743; d=isode.com; s=selector; i=@isode.com; bh=W57V2+crNl2QOcz5ejiJ4AEVpKehcZZZaTbCk+CUh7o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=bzzOCj3eiFDTVzAt2xOsOA7tbLYvbDxy42gV4GA5QL9gXv9yl9xz5FcWalWj843j6qTMRV V8IyGedGkBh/vVp/m1AZUNnYJaRPE8iHJmZke4UAG7tXLp/3PeBFhPP4hnU0kivy6ibPT6 0rM4zTQkjL4TQuM0F3SAacu9tj9PSbo=; Received: from [192.168.1.145] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 15 Feb 2012 14:22:23 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4F3BBFA4.8010107@isode.com> Date: Wed, 15 Feb 2012 14:22:28 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 To: Bron Gondwana , Tony Finch References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> In-Reply-To: <1329315552.1444.140661036879893@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:22:31 -0000 On 15/02/2012 14:19, Bron Gondwana wrote: > > On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote: >> Bron Gondwana wrote: >>> Folder management is amazingly complex now that all the LIST-EXT >>> stuff is in there, and interactions with "subscriptions" - complete >>> with the whole "subscription has to survive when folder is deleted" >>> funkyness. It's amazing how the best intentions have created a mess >>> there. >> Is there any reason to keep subscriptions in IMAP 5 ? Yes. I think clients frequently have a mode of only showing subscribed folders as opposed to everything. This seems to be useful for mobile/low bandwidth use. > I envisage "subscription" as either an annotation or a "Special Use" on > a folder rather than yet another axis of data. +1. From brong@fastmail.fm Wed Feb 15 06:43:08 2012 Return-Path: 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 BD1C321E8018 for ; Wed, 15 Feb 2012 06:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, 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 r6G0fkUNhGtF for ; Wed, 15 Feb 2012 06:43:02 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB7521E803C for ; Wed, 15 Feb 2012 06:43:02 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A5C1420356 for ; Wed, 15 Feb 2012 09:43:01 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute6.internal (MEProxy); Wed, 15 Feb 2012 09:43:01 -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= JgHHrkimt+UarKGkv+ENHsm0qKM=; b=pI4zgy/MuajD57iow914d2i4VEMmHa4t 6DVRAnAqFrFoHeZis57hR2E1MEP23Na91cMoQ8ASrLbQVVTnpnXSOri+3mzXXIHf dppTLpBCqtT/TnSp36VcTo28z8imYlhoXA3L/wxGLZUYtUWUfHJAjHvyPVUv7hg+ PwrfkUkUcrM= 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=JgHHrkimt+UarKGkv+ENHsm0qKM=; b= rtkybiT+wR3/EXSAb0MPNGpQIHd640Ggwq3DSsjxrhUE67Pz/66a/P34BpMzeBRo lKR95sVGSFNaaoirX6cLCA1U8j6DASjdQDqicT9gFrDetmpD+0xyolQcGZvaIYDp PbKjG6kIIudx7uKyWpAIk3ZO9FHVsym9S9R5JbW3c7M= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 7F101A000B6; Wed, 15 Feb 2012 09:43:01 -0500 (EST) Message-Id: <1329316981.8310.140661036883625@webmail.messagingengine.com> X-Sasl-Enc: WDcSIQaWqfImTo8hNHfo9tcePKADD2Zj52x+PKP6t/lC 1329316981 From: Bron Gondwana To: Alexey Melnikov , Tony Finch MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> In-Reply-To: <4F3BBFA4.8010107@isode.com> Date: Wed, 15 Feb 2012 15:43:01 +0100 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:43:08 -0000 On Wed, Feb 15, 2012, at 02:22 PM, Alexey Melnikov wrote: > On 15/02/2012 14:19, Bron Gondwana wrote: > > On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote: > >> Is there any reason to keep subscriptions in IMAP 5 ? > > I envisage "subscription" as either an annotation or a "Special Use" on > > a folder rather than yet another axis of data. > +1. I was chatting to one of the other guys on our team yesterday about data modelling in this context. Mail is a structured data store, with some small set of types of data stored in the IMAP "model". The IMAP protocol is very much about the communications, and trying to optimise specific use cases. But at the core, it's about querying and modifying data in a particular model, with some constraints on the valid modifications - both for integrity and for ACL permissions reasons. Along with a side dose of syncronising up offline modifications to that same data model. This is not a problem that's unique to email. There's nothing really special about email here unless you make it special. Sure there's a bunch of indexed and optimised ways of viewing that data - sort by trimmed subject, encodings, etc. All of which could be expressed as generic queries against the data model with a query optimiser on the far end rather than needing a custom syntax for everything... It's a somewhat different view of email, but I think quite a useful perspective to look at it from. Just a database with some funky constraints and triggers. So in my head, I'm kind of thinking in SQL when I think about how I would access email. LIMIT, OFFSET, ORDER BY, VIEW. Particularly VIEW and ORDER BY with a dose of 'use modseq to re-synchronise up with your last copy of a view'. CREATE VIEW 'Inbox' AS SELECT * FROM Messages M JOIN Folders F USING (FolderId) WHERE F.SpecialUse = '\Inbox' AND M.IsExpunged = 0 ORDER BY M.Uid DESC; CREATE VIEW Status AS SELECT FolderId, MAX(Uid) + 1 AS UIDNEXT, MAX(Modseq) AS HIGHESTMODSEQ, COUNT(*) AS EXISTS, SUM(IsSeen) AS UNSEEN FROM Messages WHERE IsExpunged = 0 GROUP BY FolderId; There exist database engines which could optimise those views up the wazoo, rather than writing a custom optimizer for each one, and a custom protocol element with a custom parser for each value. ---- So basically what I'd like to see us doing with email is LESS. Less custom. Less "it's so special". Treat it like a generic bunch of data, and manipulate it with generic data manipulation methods. Bron. -- Bron Gondwana brong@fastmail.fm From arnt@gulbrandsen.priv.no Wed Feb 15 06:57:00 2012 Return-Path: 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 0EEB721E8044 for ; Wed, 15 Feb 2012 06:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 eX-JAot1q2Kb for ; Wed, 15 Feb 2012 06:56:59 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 778CD21E8040 for ; Wed, 15 Feb 2012 06:56:59 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3BB47F8C8A0; Wed, 15 Feb 2012 14:56:57 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1329317815-12558-12558/10/4; Wed, 15 Feb 2012 14:56:55 +0000 Message-Id: <4F3BC7DA.5070803@gulbrandsen.priv.no> Date: Wed, 15 Feb 2012 15:57:30 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> In-Reply-To: <1329316981.8310.140661036883625@webmail.messagingengine.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:57:00 -0000 On 02/15/2012 03:43 PM, Bron Gondwana wrote: > So basically what I'd like to see us doing with email is LESS. Less = custom. > Less "it's so special". Treat it like a generic bunch of data, and = manipulate > it with generic data manipulation methods. It sounds a bit like a reinvention of RFC 2244, which was too generic for people like me. Dave liked it, I think he still likes it, but he's really smart. Personally, I understood that 2244 could be used to do wondrous stuff in general, but when I read the document I wasn't able to connect it to any concrete wondrous applications for my work. Optimising for really smart people risks leaving mortals unable to see any reason to write code for it. Arnt From petite.abeille@gmail.com Wed Feb 15 07:37:07 2012 Return-Path: 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 DAD4E21F86B0 for ; Wed, 15 Feb 2012 07:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=-1.750, 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 q1P3wy+y93vl for ; Wed, 15 Feb 2012 07:37:07 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F35A621F86AB for ; Wed, 15 Feb 2012 07:37:06 -0800 (PST) Received: by werm10 with SMTP id m10so925422wer.31 for ; Wed, 15 Feb 2012 07:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=W2j2xx9uIgb9HnjePdVMel3HKueEH2El14wVKJYu4oU=; b=DYNaKc2ufRMvcmpIKz1tqVKwmIXW9yqT0uy6sdqaeqWV5UcMahL1vVIDJaVXMlS6a2 pzGhMXTdE1IhJySB6UIImgPs42K9AEH2Cq2lAPvo7aC+wDPa3p277mqIacSCEk0zph5+ yJcyIygajBuesf3r7FEF+dkjpqEu/QsaFAyJo= Received: by 10.180.24.7 with SMTP id q7mr36281862wif.14.1329320225819; Wed, 15 Feb 2012 07:37:05 -0800 (PST) Received: from [192.168.1.47] (158-176.194-178.cust.bluewin.ch. [178.194.176.158]) by mx.google.com with ESMTPS id y1sm11970331wiw.6.2012.02.15.07.37.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 07:37:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Petite Abeille In-Reply-To: <1329316981.8310.140661036883625@webmail.messagingengine.com> Date: Wed, 15 Feb 2012 16:37:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7982794D-E2A6-4925-88F2-8F94C5221958@gmail.com> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> To: imap5@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 15:37:08 -0000 On Feb 15, 2012, at 3:43 PM, Bron Gondwana wrote: > So in my head, I'm kind of thinking in SQL when I think about how I = would > access email.=20 Funnily enough, this is precisely how my diminutive IMAP server is = implemented :D E.g.: SelectMailboxStatus =3D [[ select cast( count( * ) as integer ) as messages, cast( 0 as integer ) as recent, cast( coalesce( max( uid ), 0 ) + 1 as integer ) as uidnext, cast( 1 as integer ) as uidvalidity, cast( 0 as integer ) as unseen from fetch_seq ]], FWIW, here is the DDL of the data model (a bit of a work in progress): http://dev.alt.textdrive.com/browser/Mail/MailStore.ddl And the DML for the IMAP store: http://dev.alt.textdrive.com/browser/Mail/IMAPStore.dml From brong@fastmail.fm Wed Feb 15 10:10:51 2012 Return-Path: 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 7961A21E8059 for ; Wed, 15 Feb 2012 10:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 XYlyR6pPu-L6 for ; Wed, 15 Feb 2012 10:10:50 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 03FE821E8029 for ; Wed, 15 Feb 2012 10:10:49 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 703D020B54 for ; Wed, 15 Feb 2012 13:10:48 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 15 Feb 2012 13:10:49 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=yAZycN09vuF7WUDJZeVpPuZ3 0PY=; b=J75nc7hiPKW0te7Bld8EfBgh5PkoUcr11RPusoogqGg6Bz53uDUSZ/Hm IslvR3cXBVNDdqyCDpWsAGITwfDfzB55R3UsP/dq/kPI3iXbQ9yz0Z4VADCdfgC9 41Oj+X+UPGsYIklR6c7OdUFXM69MoyDlTG8Nqh6wrFZqwRnhIpM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=yAZycN09vuF7WUDJZeVpPuZ30PY=; b=XnWdfUAKdYzvxtWDEoyXp5wwxAI/ v8Qas/JDDaNu9YRlNZvfeF4GC5yROP2GFPKJhJZh3QTnPtHOGLdF4zBoC5BjVJv+ ndWabUJggUHWX6rtKzxwN14vrfGeXZO6KNpcGtW8IskiDMRveSGDWDdlQiDHpGcV r/Ey5tGNOe18YZA= X-Sasl-enc: pRqWqexdjDI1AX5GNOO8crF2uAD691O6q7rhGhbPSH2I 1329329448 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6CF2A482549; Wed, 15 Feb 2012 13:10:48 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 2A5C0327E2F; Wed, 15 Feb 2012 19:10:47 +0100 (CET) Date: Wed, 15 Feb 2012 19:10:47 +0100 From: Bron Gondwana To: Arnt Gulbrandsen Message-ID: <20120215181047.GB13906@launde.brong.net> References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <4F3BC7DA.5070803@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3BC7DA.5070803@gulbrandsen.priv.no> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 18:10:51 -0000 On Wed, Feb 15, 2012 at 03:57:30PM +0100, Arnt Gulbrandsen wrote: > On 02/15/2012 03:43 PM, Bron Gondwana wrote: > > So basically what I'd like to see us doing with email is LESS. Less custom. > > Less "it's so special". Treat it like a generic bunch of data, and manipulate > > it with generic data manipulation methods. > > It sounds a bit like a reinvention of RFC 2244, which was too generic > for people like me. Dave liked it, I think he still likes it, but he's > really smart. Personally, I understood that 2244 could be used to do > wondrous stuff in general, but when I read the document I wasn't able to > connect it to any concrete wondrous applications for my work. Oh yeah, ACAP. It's on the list of things to look at. > Optimising for really smart people risks leaving mortals unable to see > any reason to write code for it. Obviously you need to avoid getting so over-generic that you wind up doing an anything protocol. The anything protocol is always tempting. The thing is - I don't mean leaving everything super flexible and undefined. I'm meaning more "don't define a separate custom protocol with custom behaviour for everything". For example (and I quote directly from ##imap on freenode over the past couple of hours) hello, is there a simple reason why my imap connected clients can't distinguish unread messages? (all messages marked as read) IroquoisTwist, probably is a simple reason, but it depends on a lot of factors... brong_: thanks, i found out my spam guard was "reading" the messages - turned it off and used local span filtering - all is well sounds like a classy piece of software. Forgot to put a .peek in did they? what am I saying. imap5 people - LOOK AT THIS brong_: not too sure - end of my spam knowledge - it's called Spamassassin (preinstalled via cPanel) Now, you could blame the authors of the spam scanner which wrapped Spamassassin and called it via IMAP. They're morons, no doubt. But .PEEK. Seriously? Hands up everyone who has screwed that up themselves or seen someone else screw it up over their entire time of working with email? I'll own up to having done it more than once. .PEEK is one of the warts that is out. No side effects. No magic. Along with \Recent, which is also magic - it's a read only value where EVERYTHING ELSE in the same space is writable (ACLs permitting), it's defined in a way that makes multi-session a pain. It's a wart. And UNSEEN, but I already said that. Why is 'STATUS UNSEEN' special, and "* UNSEEN x" - complete with the contradictory "use your common sense" definition... Bron. From jkt@flaska.net Wed Feb 15 10:25:57 2012 Return-Path: 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 B664B21E8086 for ; Wed, 15 Feb 2012 10:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 QzdPsnj5nF+n for ; Wed, 15 Feb 2012 10:25:56 -0800 (PST) Received: from serv132.fzu.cz (serv132.fzu.cz [147.231.26.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE5E21E8029 for ; Wed, 15 Feb 2012 10:25:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocDABv4O0+T5xpZgWdsb2JhbABDhRGrUyIBARYmJ4FyAQEFI2YLGAkhAgIPAkYTCAEBsAqRfYwMUQ4JA4NFAwYHBgkEDwIYFYIHgRYEjk2BG4VOkmk X-IronPort-AV: E=Sophos;i="4.73,424,1325458800"; d="asc'?scan'208";a="4580945" Received: from freja.fzu.cz ([147.231.26.89]) by serv147.fzu.cz with ESMTP; 15 Feb 2012 19:25:53 +0100 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id 3146C3DA82 for ; Wed, 15 Feb 2012 19:25:53 +0100 (CET) Message-ID: <4F3BF8B0.50707@flaska.net> Date: Wed, 15 Feb 2012 19:25:52 +0100 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imap5@ietf.org References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> In-Reply-To: <20120215181047.GB13906@launde.brong.net> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9F043C398C4B7A65A0FF5529" Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 18:25:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9F043C398C4B7A65A0FF5529 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/15/12 19:10, Bron Gondwana wrote: > Along with \Recent, which is also magic - it's a read only value where > EVERYTHING ELSE in the same space is writable (ACLs permitting), it's > defined in a way that makes multi-session a pain. It's a wart. On the other hand, some people (you know, I keep telling myself that I cannot possibly be alone in this) use the lack of \Seen to mean "I should do something for this mail", which means that we have a lot of "unread" messages in our mailboxes. Having a way of automatically marking those messages which are *really* fresh arrivals is therefore very convenient, and \Recent does exactly that. Sure, we can use another flag for this, but having these flags managed by the server means that no client has to ever touch it, and therefore it will "just work" all the time. That's a pretty big benefit, IMHO. (Yes, I typically run just a single instance of a MUA these days and lug my laptop around -- that might explain why this works for me.) Cheers, Jan --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enig9F043C398C4B7A65A0FF5529 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk87+LAACgkQamXfqERyJRdgBQCfb8XTcX90iehA7pTJtjsyJvsT ciwAnR2cWoW6Duw9p3zFsNyKq3X3Zb4f =f0e/ -----END PGP SIGNATURE----- --------------enig9F043C398C4B7A65A0FF5529-- From brong@fastmail.fm Wed Feb 15 10:54:10 2012 Return-Path: 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 1776521F8698 for ; Wed, 15 Feb 2012 10:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 HVBA5HP8jCrs for ; Wed, 15 Feb 2012 10:54:05 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id C641C21F8680 for ; Wed, 15 Feb 2012 10:54:05 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5117820B64 for ; Wed, 15 Feb 2012 13:54:05 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 15 Feb 2012 13:54:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=mesmtp; bh=T98ug7BhzESfjw9cVLqiOMFe1SM=; b=YPnCd6SyjLu0NhBfVVVe4XcmxOzn F75iMyHayBzagwXrDaKx8bY0/N35G1RqnDq5UW4SyxoTW0ufbONTRR9jJSqrF5CI eMEsQ1b+VLo0WH9ICtmSgrmMMR1BFwLjRsQ+j0YsL20e/rAB5xXzaNb/3Tg9iNsj 0col/tFQyCTT+TQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:content-transfer-encoding :in-reply-to; s=smtpout; bh=T98ug7BhzESfjw9cVLqiOMFe1SM=; b=BsD3 81J1iahwHNXL25KVfiVn0vyfPJ6NOYHD0K1yuOEV/96HjsEw7d789eRHJgZJCTJB HjpwYuXwbmkL7SCrHwU9h0MB7m3VOfA8bd3n6XotHGHrTh/bmbm5Ie45xgsZRZsQ 8ouqJ/kM9owzUc9+odYg6V9dPI0+6RPUakItzwk= X-Sasl-enc: JRe74BGo0g1Me+vUOKs7v8eIdi0WrVfYFw8X1CIj7QMl 1329332044 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id E626A4824B1; Wed, 15 Feb 2012 13:54:04 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 67CA5327E16; Wed, 15 Feb 2012 19:54:03 +0100 (CET) Date: Wed, 15 Feb 2012 19:54:03 +0100 From: Bron Gondwana To: Jan =?iso-8859-1?Q?Kundr=E1t?= Message-ID: <20120215185403.GC15694@launde.brong.net> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <4F3BF8B0.50707@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F3BF8B0.50707@flaska.net> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 18:54:10 -0000 On Wed, Feb 15, 2012 at 07:25:52PM +0100, Jan Kundrát wrote: > On 02/15/12 19:10, Bron Gondwana wrote: > > Along with \Recent, which is also magic - it's a read only value where > > EVERYTHING ELSE in the same space is writable (ACLs permitting), it's > > defined in a way that makes multi-session a pain. It's a wart. > > On the other hand, some people (you know, I keep telling myself that I > cannot possibly be alone in this) use the lack of \Seen to mean "I > should do something for this mail", which means that we have a lot of > "unread" messages in our mailboxes. Having a way of automatically > marking those messages which are *really* fresh arrivals is therefore > very convenient, and \Recent does exactly that. Kinda, unless you lose your IMAP connection, or... In other words, it's a lossy, partial solution - which comes at a server end penalty of having to WRITE something when a client reads. > Sure, we can use another flag for this, but having these flags managed > by the server means that no client has to ever touch it, and therefore > it will "just work" all the time. That's a pretty big benefit, IMHO. Except then someone says "but I want to see messages which have not yet been seen BY THIS DEVICE", so my phone sees things as new even when I left my desktop logged in and checking for new messages. Special cases are great when they match your use case, for sure. > (Yes, I typically run just a single instance of a MUA these days and lug > my laptop around -- that might explain why this works for me.) Whereas I work in a couple, and have my phone... so it's pointless to me. Bron ( and the management types with their crackb^WiPhones... they want something different again ) From mrc+ietf@panda.com Wed Feb 15 11:51:48 2012 Return-Path: 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 D053721F85EA for ; Wed, 15 Feb 2012 11:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 UzONsBXkdTNh for ; Wed, 15 Feb 2012 11:51:44 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id 74A9F21E8032 for ; Wed, 15 Feb 2012 11:51:44 -0800 (PST) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Wed, 15 Feb 2012 11:51:41 -0800 X-MailFrom: mrc+ietf@panda.com Date: Wed, 15 Feb 2012 11:51:39 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: imap5@ietf.org In-Reply-To: <20120215181047.GB13906@launde.brong.net> Message-ID: References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:51:48 -0000 On Wed, 15 Feb 2012, Bron Gondwana wrote: > No side effects. No magic. Your effort is doomed with that attitude. Protocol designers do NOT drive the evolution of a protocol. Protocol consumers do. In order for a protocol to be used, the protocol designer must accomodate everything that a protocol consumer identifies (whether correctly or incorrectly) as a requirement. All too often, there is no way to do so without adding magic and/or warts. If the designer refuses, the consumer will go elsewhere. In every protocol, every little wart, every bit of magic, happened for a reason - and almost always over the protocol designer's objection. For each of these, some consumer depends upon it. In order to get a consumer to switch from an existing protocol, you must accomodate ALL their dependencies, AND present a compelling reason why they should invest in switching. Neither elegance, nor beauty, nor magic and wart free are compelling. It's VERY hard to accomodate all the requirements of protocol consumers, especially when those requirements conflict (and they do conflict). That is why you have a very small number of successful protocol designers, and a much larger number of people who think that they can do a better job. Every field of human endeavor demonstrates it. The miraculous thing about IMAP is that, after nearly 25 years, it has a surprisingly small amount of magic and warts. Even better, the majority of magic and warts are in extensions that most people ignore. Above all, IMAP works well enough for consumers. The older that any protocol gets, the more difficult and expensive it becomes to deploy a new solution within open standards. Nobody cares that an implementor may find it to be hard work. Implementors are supposed to be Really Smart People that are worth their exorbitant salaries; and some of the best IMAP implementations I've seen were written by very smart people in Third World countries that work for much less... One last thought. The only likely "IMAP killer" is not a new open-source protocol. It is Exchange. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From tss@iki.fi Wed Feb 15 12:01:14 2012 Return-Path: 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 BA5DE21E80D9 for ; Wed, 15 Feb 2012 12:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 MsXh2o-k7DTO for ; Wed, 15 Feb 2012 12:01:12 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5E51021E809B for ; Wed, 15 Feb 2012 12:01:10 -0800 (PST) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 60DB01AE87E4; Wed, 15 Feb 2012 22:01:08 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Wed, 15 Feb 2012 22:01:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6954AA42-D86E-4477-9523-3F7B86DA30DF@iki.fi> References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> To: Mark Crispin X-Mailer: Apple Mail (2.1084) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 20:01:14 -0000 On 15.2.2012, at 21.51, Mark Crispin wrote: > One last thought. The only likely "IMAP killer" is not a new = open-source > protocol. It is Exchange. Well, it is open enough nowadays and has one almost complete open source = implementation, so it's not all bad.. From sebastien.michel@atos.net Wed Feb 15 13:00:05 2012 Return-Path: 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 D7D3521E8043 for ; Wed, 15 Feb 2012 13:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 D2LO+289ca7w for ; Wed, 15 Feb 2012 13:00:01 -0800 (PST) Received: from smtp1.mail.atosorigin.com (smtp1.mail.atosorigin.com [160.92.103.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E10921F864D for ; Wed, 15 Feb 2012 13:00:01 -0800 (PST) Received: from filter.atosorigin.com (localhost [127.0.0.1]) by mxfed001 (Postfix) with ESMTP id E96DB26396F7; Wed, 15 Feb 2012 21:59:57 +0100 (CET) Received: from mail.awl.fr.atosorigin.com (serv-smtp-wse01.fr.atosworldline.com [160.92.103.180]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "mail.awl.fr.atosorigin.com", Issuer "VeriSign Class 3 Secure Server CA - G2" (verified OK)) by mxfed001 (Postfix) with ESMTP id E2DB526396F0; Wed, 15 Feb 2012 21:59:57 +0100 (CET) Received: from frspx302.fr01.awl.atosorigin.net (10.24.253.187) by frspx401.priv.atos.fr (10.24.220.7) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 15 Feb 2012 21:59:57 +0100 Received: from FRSPX100.fr01.awl.atosorigin.net ([10.24.253.184]) by frspx302.fr01.awl.atosorigin.net ([10.24.253.187]) with mapi; Wed, 15 Feb 2012 21:59:57 +0100 From: =?iso-8859-1?Q?Michel_S=E9bastien?= To: Bron Gondwana , Alexey Melnikov , Tony Finch Date: Wed, 15 Feb 2012 21:59:56 +0100 Thread-Topic: [imap5] Designing a new replacement protocol for IMAP Thread-Index: Aczr8CkSWFTKkA7BTBek7e3hr6szzwAMZNZw Message-ID: <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> References: <1328732126.32086.140661033971485@webmail.messagingengine.com> <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> In-Reply-To: <1329316981.8310.140661036883625@webmail.messagingengine.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 21:00:06 -0000 >> On 15/02/2012 14:19, Bron Gondwana wrote: >> > On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote: >> >> Is there any reason to keep subscriptions in IMAP 5 ? >> > I envisage "subscription" as either an annotation or a "Special Use" >> > on a folder rather than yet another axis of data. >> +1. Does it works with shared folders ? > I was chatting to one of the other guys on our team yesterday about data = modelling in this context. > > Mail is a structured data store, with some small set of types of data sto= red in the IMAP "model". The IMAP protocol is very much about the > communications, and trying to optimise specific use cases. > > But at the core, it's about querying and modifying data in a particular m= odel, with some constraints on the valid modifications - both for integrity= and for ACL permissions reasons. > > Along with a side dose of syncronising up offline modifications to that s= ame data model. > > This is not a problem that's unique to email. There's nothing really spe= cial about email here unless you make it special. Sure there's a bunch of = indexed and optimised ways of viewing that data - sort by trimmed subject, = encodings, etc. All of which could be expressed as generic queries against= the data model with a query optimiser on the far end rather than needing a= custom syntax for everything... > Some others seems to think that webdav could be a candidate : http://www.we= bdav.org/other/faq.html#Q26 A new layer on top of webdav, with some keywords registered at IANA. But I = just don't like the trend to use HTTP for everything... despite its interes= t here. Ce message et les pi=E8ces jointes sont confidentiels et r=E9serv=E9s =E0 l= 'usage exclusif de ses destinataires. Il peut =E9galement =EAtre prot=E9g= =E9 par le secret professionnel. Si vous recevez ce message par erreur, mer= ci d'en avertir imm=E9diatement l'exp=E9diteur et de le d=E9truire. L'int= =E9grit=E9 du message ne pouvant =EAtre assur=E9e sur Internet, la responsa= bilit=E9 d'Atos ne pourra =EAtre recherch=E9e quant au contenu de ce messag= e. Bien que les meilleurs efforts soient faits pour maintenir cette transmi= ssion exempte de tout virus, l'exp=E9diteur ne donne aucune garantie =E0 ce= t =E9gard et sa responsabilit=E9 ne saurait =EAtre recherch=E9e pour tout d= ommage r=E9sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integr= ity cannot be secured on the Internet, the Atos liability cannot be trigger= ed for the message content. Although the sender endeavours to maintain a co= mputer virus-free network, the sender does not warrant that this transmissi= on is virus-free and will not be liable for any damages resulting from any = virus transmitted. From brong@fastmail.fm Wed Feb 15 13:13:09 2012 Return-Path: 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 A3B7521F845E for ; Wed, 15 Feb 2012 13:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 ds59cw9n0Tvv for ; Wed, 15 Feb 2012 13:13:04 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4784421F8672 for ; Wed, 15 Feb 2012 13:13:04 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D342D20D69 for ; Wed, 15 Feb 2012 16:13:03 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 15 Feb 2012 16:13:03 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=mesmtp; bh=ElDOBSVQob3HowogQ9MBWCHAvus=; b=O3lKlJCR9GYIX9dO3gtDxQPh85nF n+qJH/jyQtCJYSegQya70gwcSGzoXQJACLkQYAgXRvwMdXIk1P+0xXWuy7fZtxYm PbP+P/WqlFOcGblKg9zixo5xAX3SS0CqT2hhRc0KUUXb1AU9P4m8Zf2HHBocM+7s Y1FZYeGlRa9exXg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:content-transfer-encoding :in-reply-to; s=smtpout; bh=ElDOBSVQob3HowogQ9MBWCHAvus=; b=ojQr 1LZlvQXRv1J3DrRL3rRUydokQHt+fsqZl203ctY4wQt7HHb21L+mYmpeE9FjM+U+ 3BedmYxtJyTuT8ltKB/xK/x1scsa33qTh4JIab0YxBHyKCd6zeV4SLluYLRYq4tz DYsalOOHFReRTsAlhmbiqAlBVcgN6Icirmvwcak= X-Sasl-enc: vxguwcdCSdRLcYHlSWXU8FQW+NeF4DqK6OYjUgrsoFRt 1329340383 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8D1E74824B8; Wed, 15 Feb 2012 16:13:03 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 019C1327E2F; Wed, 15 Feb 2012 22:13:01 +0100 (CET) Date: Wed, 15 Feb 2012 22:13:01 +0100 From: Bron Gondwana To: Michel =?iso-8859-1?Q?S=E9bastien?= Message-ID: <20120215211301.GA16253@launde.brong.net> References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 21:13:09 -0000 On Wed, Feb 15, 2012 at 09:59:56PM +0100, Michel Sébastien wrote: > > >> On 15/02/2012 14:19, Bron Gondwana wrote: > >> > On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote: > >> >> Is there any reason to keep subscriptions in IMAP 5 ? > >> > I envisage "subscription" as either an annotation or a "Special Use" > >> > on a folder rather than yet another axis of data. > >> +1. > Does it works with shared folders ? Sure, it's a private annotation. > > This is not a problem that's unique to email. There's nothing really special about email here unless you make it special. Sure there's a bunch of indexed and optimised ways of viewing that data - sort by trimmed subject, encodings, etc. All of which could be expressed as generic queries against the data model with a query optimiser on the far end rather than needing a custom syntax for everything... > > > > Some others seems to think that webdav could be a candidate : http://www.webdav.org/other/faq.html#Q26 > A new layer on top of webdav, with some keywords registered at IANA. But I just don't like the trend to use HTTP for everything... despite its interest here. Yes, webdav is tempting for a few reasons - the downside is a relatively high overhead. BEEP has also been mentioned. A good advantage of both of these is that you can transport unmodified MIME across them. I'm wary of anything which will require the raw MIME bodies of messages to be encoded across the wire - some sort of length based literal syntax is very valuable. Of course it's hard to love something with examples like this: S: RPY 0 1 . 221 185 S: Content-Type: application/beep+xml S: S: S: PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1 jaS5uZXQ+]]> S: S: END It makes MIME header encoding look so lightweight in comparison. Still... as I'm regretting learning, compatible is more important than good. If there exist libraries everywhere which can reliably read and write that, and it's ugly enough that nobody wants to do it themselves, then maybe - just maybe, you'll actually get BETTER complience than if it's a simple enough protocol that people roll almost-correct code by hand. Bron. From adrien@qbik.com Wed Feb 15 13:28:24 2012 Return-Path: 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 08EFD21E80B2 for ; Wed, 15 Feb 2012 13:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.69 X-Spam-Level: X-Spam-Status: No, score=-5.69 tagged_above=-999 required=5 tests=[AWL=-3.091, 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 f5aMBOu3mp1K for ; Wed, 15 Feb 2012 13:28:19 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1C921E8065 for ; Wed, 15 Feb 2012 13:28:18 -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 <0018865154@smtp.qbik.com>; Thu, 16 Feb 2012 10:28:16 +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 <0010060065@sago.qbik.com>; Thu, 16 Feb 2012 10:28:02 +1300 Message-ID: <4F3C2362.2060007@qbik.com> Date: Thu, 16 Feb 2012 10:28:02 +1300 From: Adrien de Croy 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 References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> In-Reply-To: <20120215211301.GA16253@launde.brong.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 21:28:24 -0000 having dealt with support issues relating primarily to HTTP for the last 17 years, I'd STRONGLY recommend against using anything HTTP based. The number of proxies that break WebDAV makes it problematic alone. If some clients need HTTP-based access to some IMAP function, they can use a gateway. Then an administrator can choose whether to allow such access. But clients using the protocol that provides it all don't need it. If you're a system admin, and there's a product you can install where you install 1 service, open 1 port and it provides everything you'd go for that right? If we play our cards right, it should be simple for some gateway to provide legacy interfaces to the new protocol. re the discussion about richness of protocol... sure you can do things at a lower level. That typically requires more round-trips to the server though. unless the things are pipelined..... specifically designed to be, so a single meta command is sent as a bunch of micro commands... but therein lie a multitude of problems (e.g. enforcing security, synchronisation etc). Adrien On 16/02/2012 10:13 a.m., Bron Gondwana wrote: > On Wed, Feb 15, 2012 at 09:59:56PM +0100, Michel Sébastien wrote: >>>> On 15/02/2012 14:19, Bron Gondwana wrote: >>>>> On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote: >>>>>> Is there any reason to keep subscriptions in IMAP 5 ? >>>>> I envisage "subscription" as either an annotation or a "Special Use" >>>>> on a folder rather than yet another axis of data. >>>> +1. >> Does it works with shared folders ? > Sure, it's a private annotation. > >>> This is not a problem that's unique to email. There's nothing really special about email here unless you make it special. Sure there's a bunch of indexed and optimised ways of viewing that data - sort by trimmed subject, encodings, etc. All of which could be expressed as generic queries against the data model with a query optimiser on the far end rather than needing a custom syntax for everything... >>> >> Some others seems to think that webdav could be a candidate : http://www.webdav.org/other/faq.html#Q26 >> A new layer on top of webdav, with some keywords registered at IANA. But I just don't like the trend to use HTTP for everything... despite its interest here. > Yes, webdav is tempting for a few reasons - the downside is > a relatively high overhead. > > BEEP has also been mentioned. A good advantage of both of > these is that you can transport unmodified MIME across them. > I'm wary of anything which will require the raw MIME bodies > of messages to be encoded across the wire - some sort of > length based literal syntax is very valuable. > > Of course it's hard to love something with examples like this: > > S: RPY 0 1 . 221 185 > > S: Content-Type: application/beep+xml > S: > S: > S:PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1 > jaS5uZXQ+]]> > S: > S: END > > It makes MIME header encoding look so lightweight in comparison. > > > Still... as I'm regretting learning, compatible is more important > than good. If there exist libraries everywhere which can > reliably read and write that, and it's ugly enough that nobody > wants to do it themselves, then maybe - just maybe, you'll actually > get BETTER complience than if it's a simple enough protocol that > people roll almost-correct code by hand. > > Bron. > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From brong@fastmail.fm Wed Feb 15 13:31:29 2012 Return-Path: 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 72A0321E80AA for ; Wed, 15 Feb 2012 13:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 iDgofFD8E4wK for ; Wed, 15 Feb 2012 13:31:24 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 843A821E8032 for ; Wed, 15 Feb 2012 13:31:24 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3713C20DF5 for ; Wed, 15 Feb 2012 16:31:24 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 15 Feb 2012 16:31:24 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=MJoZg4+0moKNKXZIJTKb05w8 l08=; b=G/r2aofYtjyUOIrNYK4LNQil5UKPQjdICwDEaEWVTnLLuFHSFsLNk2nw khpHOegs9b/EY5XoiNTTJ3dlNxtOhLpxjqZW/EE95XZE0f635Ul/BTj/J5mjfo/V yFTG8Z87/KGrolObUFzKxaS3HiHyDxNFE4gddHhBLlPddWTQRPQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=MJoZg4+0moKNKXZIJTKb05w8l08=; b=pMyF01e4vJdWACHYhdEcC9gizrtU qC1Zdjyv5ZZ6HSRt1IB0sQaCq7bkobcCW8qSg9HNGNJQGJPKRxiNcT4z+4j7xxA4 DvgaLs7/VKUUFAKQkjngsLmIH9nOmn/sZeSwrBj1ScjFiDYReOGBsxqNM7m5KEI9 1On1Jtzfl9dMyU0= X-Sasl-enc: gtc0+VXjvNpPvvi1tms5Re6+CzPw1i7CiybQlsTCibqm 1329341483 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id DF33C48251E; Wed, 15 Feb 2012 16:31:23 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id A0D79327E2F; Wed, 15 Feb 2012 22:31:22 +0100 (CET) Date: Wed, 15 Feb 2012 22:31:22 +0100 From: Bron Gondwana To: Mark Crispin Message-ID: <20120215213122.GB16253@launde.brong.net> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 21:31:29 -0000 On Wed, Feb 15, 2012 at 11:51:39AM -0800, Mark Crispin wrote: > On Wed, 15 Feb 2012, Bron Gondwana wrote: > >No side effects. No magic. > > Your effort is doomed with that attitude. My effort would be even more doomed if I had your attitude, of course. And you're right - "no" is too strong. There will have to be magic. There doesn't have to be side effects though. More protocol consumers are aware of the downsides of them these days. They know there's a tradeoff, and side-effect-free is not just the realm of ivory tower Haskell peddlers. Magic is bound to happen, but if there's a clear way to indicate that you want the magic, rather than a default of magic, I contend that protocol consumers will be pleased. I suspect most protocol consumers use BODY.PEEK and explicit "STORE \Seen" these days. I could collect some statistics amongst our users easily enough, though I would have to exclude our web interface or it would skew the stats. At least there is BODY.PEEK. Bron. From adrien@qbik.com Wed Feb 15 14:05:39 2012 Return-Path: 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 B837C21E8091 for ; Wed, 15 Feb 2012 14:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.527 X-Spam-Level: X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=-2.928, 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 dqdEyBfSX3mN for ; Wed, 15 Feb 2012 14:05:34 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4313321E80A2 for ; Wed, 15 Feb 2012 14:05:33 -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 <0018865212@smtp.qbik.com>; Thu, 16 Feb 2012 11:05:31 +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 <0010060096@sago.qbik.com>; Thu, 16 Feb 2012 11:05:15 +1300 Message-ID: <4F3C2C1B.6030408@qbik.com> Date: Thu, 16 Feb 2012 11:05:15 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: IMAP5 list References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> In-Reply-To: <20120215213122.GB16253@launde.brong.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:05:40 -0000 Seems to me we're getting bogged in the implementation details, or at least going too far down that path. We don't even have a clearly defined set of objectives for the features we want the protocol to provide. here's my first cut off-the-cuff list: * mail access for obvious reasons. * mail submission For reasons I've stated already including ease of administrative and configuration and support. This breaks down into: - composing messages on the server - providing delivery information (e.g. destination address) * storage of mail client configuration So that clients can be dumb, and you can hook a new client to your mailstore and you don't need to configure anything else. * server-side mail processing rules Save downloading headers + MOVE etc to process filtering rules. Also saves synchronising such rules amongst multiple clients * ability for server to "comment" on anything, e.g: - that destination email address you gave me doesn't resolve (with MX or A) or is otherwise bad. - that attachment you uploaded contains a virus - that subject is offensive... - etc etc etc this could be part of a broader notification framework. In the cases where the IMAP server co-exists (as in WinGate for example) with SMTP delivery agent, then delivery information could be communicated back to the connected client. If we allow for it in the protocol, it can provide benefit where it's available, and causes no issues if it isn't. The general idea though is that anything should be able to be remarked upon by the server. * address book * calendaring * Any other feature to compete with Exchange. * Any other feature we think would give us an edge. In terms of design, I'd propose the following: * single port. This minimises problems traversing firewalls etc. * ability to access all mail (in all folders) through a single connection, and receive notifications about all state changes to anything of importance (probably with client-controlled filter) * layered protocol. Bottom layer deals with connection security (e.g. negotiating TLS) authentication, and advertisement of and connection to sub-services. Next layer are the sub-services e.g. mail, calendar, config etc. This eases gateway development, since a calendar gateway can simply connect through to the calendar sub-service. * compact yet extensible protocol message structure. The debate of text-based vs binary protocols will forever rage, I tend to prefer binary, since then you don't need to parse text which requires escaping of characters which would otherwise be protocol delimiters. Some of the downsides of text-based protocols can be averted by using length prefixes instead of searching for (and therefore needing to escape) delimiters. Even a mixture. Literal+ is a damn good design in my view, since it allows a large literal to be transferred without it having to survive parsing. It also allows any character set to go through. HTTP is a nightmare in this respect. * configuration attributes to be clearly defined (e.g. take a page from various MIBs) so that attributes can be re-used between different clients to the maximum extent. Clients can store arbitrary configuration attributes against the mail account. Regards Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From dave@cridland.net Wed Feb 15 14:25:48 2012 Return-Path: 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 BC2A421E8092 for ; Wed, 15 Feb 2012 14:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 O3HSnJThvv4r for ; Wed, 15 Feb 2012 14:25:43 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id EC19F21E8032 for ; Wed, 15 Feb 2012 14:25:42 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id E20521168087 for ; Wed, 15 Feb 2012 22:25:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK66RAZ9Dy4q for ; Wed, 15 Feb 2012 22:25:33 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 5BE6F1168067 for ; Wed, 15 Feb 2012 22:25:33 +0000 (GMT) References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> In-Reply-To: <4F3C2C1B.6030408@qbik.com> MIME-Version: 1.0 Message-Id: <3077.1329344733.342803@puncture> Date: Wed, 15 Feb 2012 22:25:33 +0000 From: Dave Cridland To: "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:25:48 -0000 On Wed Feb 15 22:05:15 2012, Adrien de Croy wrote: > * Any other feature we think would give us an edge. This mailing list is "Discussion on drastically slimming-down IMAP", and you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV *and* Submission, and then thrown in a kitchen sink too. I'm impressed. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From adrien@qbik.com Wed Feb 15 14:28:37 2012 Return-Path: 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 2AD2021F86DA for ; Wed, 15 Feb 2012 14:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.381 X-Spam-Level: X-Spam-Status: No, score=-5.381 tagged_above=-999 required=5 tests=[AWL=-2.782, 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 1PvuSjiJK6DE for ; Wed, 15 Feb 2012 14:28:32 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5D18F21F86DC for ; Wed, 15 Feb 2012 14:28:32 -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 <0018865241@smtp.qbik.com>; Thu, 16 Feb 2012 11:28:31 +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 <0010060111@sago.qbik.com>; Thu, 16 Feb 2012 11:28:18 +1300 Message-ID: <4F3C3182.8080600@qbik.com> Date: Thu, 16 Feb 2012 11:28:18 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> In-Reply-To: <3077.1329344733.342803@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:28:37 -0000 thanks :) I don't think in the context of a discussion on "Designing a new replacement protocol for IMAP" that it's off topic tho' Regards Adrien On 16/02/2012 11:25 a.m., Dave Cridland wrote: > On Wed Feb 15 22:05:15 2012, Adrien de Croy wrote: >> * Any other feature we think would give us an edge. > > This mailing list is "Discussion on drastically slimming-down IMAP", > and you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV > *and* Submission, and then thrown in a kitchen sink too. > > I'm impressed. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From tss@iki.fi Wed Feb 15 14:29:27 2012 Return-Path: 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 C316921F86DC for ; Wed, 15 Feb 2012 14:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ODOJSOdQNkU8 for ; Wed, 15 Feb 2012 14:29:27 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 293CE21F86DA for ; Wed, 15 Feb 2012 14:29:26 -0800 (PST) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 049071AE8771; Thu, 16 Feb 2012 00:29:25 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <3077.1329344733.342803@puncture> Date: Thu, 16 Feb 2012 00:29:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D2D1D68-1022-4FBA-88D6-FD3C9064B9CE@iki.fi> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> To: Dave Cridland X-Mailer: Apple Mail (2.1084) Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:29:27 -0000 On 16.2.2012, at 0.25, Dave Cridland wrote: > On Wed Feb 15 22:05:15 2012, Adrien de Croy wrote: >> * Any other feature we think would give us an edge. >=20 > This mailing list is "Discussion on drastically slimming-down IMAP", = and you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV = *and* Submission, and then thrown in a kitchen sink too. >=20 > I'm impressed. Who wrote that description? :) I never thought this list was about that. = Except maybe in some politically correct sense. From giovanni@panozzo.it Wed Feb 15 14:36:12 2012 Return-Path: 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 C959C21E80D5 for ; Wed, 15 Feb 2012 14:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 OadURbg-pFn9 for ; Wed, 15 Feb 2012 14:36:12 -0800 (PST) Received: from do2.yuu.it (do2.yuu.it [46.37.9.250]) by ietfa.amsl.com (Postfix) with ESMTP id 38F3021E8084 for ; Wed, 15 Feb 2012 14:36:12 -0800 (PST) Received: from [192.168.56.3] (nav-01.panozzo.it [88.149.172.182]) by do2.yuu.it (Postfix) with ESMTPSA id C63497F687 for ; Wed, 15 Feb 2012 23:36:02 +0100 (CET) Message-ID: <4F3C3356.6030100@panozzo.it> Date: Wed, 15 Feb 2012 23:36:06 +0100 From: Giovanni Panozzo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: imap5@ietf.org References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> In-Reply-To: <4F3C2362.2060007@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:36:12 -0000 Il 15/02/2012 22:28, Adrien de Croy ha scritto: > > having dealt with support issues relating primarily to HTTP for the last > 17 years, I'd STRONGLY recommend against using anything HTTP based. The > number of proxies that break WebDAV makes it problematic alone. > > If some clients need HTTP-based access to some IMAP function, they can > use a gateway. Such a gateway should be a mandatory part of the protocol, or we will end up on having a lot of servers with the http gateway and many other servers without it, really bad user experience. Could we think a "skype-like" solution, where the client makes two attempts: 1) Direct socket connection on a single TCP port and then, in case of failure 2) https tunnel of the same protocol (thru optional client side proxy). https is more likely to survive across proxyes than http. ? From dave@cridland.net Wed Feb 15 14:42:26 2012 Return-Path: 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 7CB7C21F84A0 for ; Wed, 15 Feb 2012 14:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 DvGjaDiqfktf for ; Wed, 15 Feb 2012 14:42:21 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAD221E8084 for ; Wed, 15 Feb 2012 14:42:19 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 69BFA1168087; Wed, 15 Feb 2012 22:42:18 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uazC3QqBtqKp; Wed, 15 Feb 2012 22:42:11 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id AC1C01168067; Wed, 15 Feb 2012 22:42:10 +0000 (GMT) References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> =?US-ASCII?Q?<66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl?= =?US-ASCII?Q?atosorigin.net>?= <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C3356.6030100@panozzo.it> In-Reply-To: <4F3C3356.6030100@panozzo.it> MIME-Version: 1.0 Message-Id: <3077.1329345730.658893@puncture> Date: Wed, 15 Feb 2012 22:42:10 +0000 From: Dave Cridland To: Giovanni Panozzo , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:42:26 -0000 On Wed Feb 15 22:36:06 2012, Giovanni Panozzo wrote: > Il 15/02/2012 22:28, Adrien de Croy ha scritto: >> >> having dealt with support issues relating primarily to HTTP for >> the last >> 17 years, I'd STRONGLY recommend against using anything HTTP >> based. The >> number of proxies that break WebDAV makes it problematic alone. >> >> If some clients need HTTP-based access to some IMAP function, they >> can >> use a gateway. > > Such a gateway should be a mandatory part of the protocol, or we > will end up on having a lot of servers with the http gateway and > many other servers without it, really bad user experience. > > Could we think a "skype-like" solution, where the client makes two > attempts: > > 1) Direct socket connection on a single TCP port > and then, in case of failure > 2) https tunnel of the same protocol (thru optional client side > proxy). > https is more likely to survive across proxyes than http. BOSH. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From adrien@qbik.com Wed Feb 15 14:44:37 2012 Return-Path: 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 761DA21E80DC for ; Wed, 15 Feb 2012 14:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[AWL=-2.649, 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 z0mV998NCNgU for ; Wed, 15 Feb 2012 14:44:32 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 58B4F21E80DA for ; Wed, 15 Feb 2012 14:44:32 -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 <0018865311@smtp.qbik.com>; Thu, 16 Feb 2012 11:44:31 +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 <0010060119@sago.qbik.com>; Thu, 16 Feb 2012 11:44:15 +1300 Message-ID: <4F3C353F.2010301@qbik.com> Date: Thu, 16 Feb 2012 11:44:15 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Giovanni Panozzo References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C3356.6030100@panozzo.it> In-Reply-To: <4F3C3356.6030100@panozzo.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:44:37 -0000 On 16/02/2012 11:36 a.m., Giovanni Panozzo wrote: > Il 15/02/2012 22:28, Adrien de Croy ha scritto: >> >> having dealt with support issues relating primarily to HTTP for the last >> 17 years, I'd STRONGLY recommend against using anything HTTP based. The >> number of proxies that break WebDAV makes it problematic alone. >> >> If some clients need HTTP-based access to some IMAP function, they can >> use a gateway. > > Such a gateway should be a mandatory part of the protocol, I think you misunderstood what I meant by gateway. What I was meaning was some other piece of software which talks HTTP to clients, and talks to the server. So it's a separate piece of software. > or we will end up on having a lot of servers with the http gateway and > many other servers without it, really bad user experience. > > Could we think a "skype-like" solution, where the client makes two > attempts: > > 1) Direct socket connection on a single TCP port > and then, in case of failure > 2) https tunnel of the same protocol (thru optional client side proxy). > https is more likely to survive across proxyes than http. there's talk (OK, I admit it, I proposed it) of deprecating http CONNECT method. Check the httpbis WG list archives for more details. Regards Adrien > > ? > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From adrien@qbik.com Wed Feb 15 14:51:52 2012 Return-Path: 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 76DAF21E80E8 for ; Wed, 15 Feb 2012 14:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.128 X-Spam-Level: X-Spam-Status: No, score=-5.128 tagged_above=-999 required=5 tests=[AWL=-2.529, 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 phSj2pq9s3sa for ; Wed, 15 Feb 2012 14:51:48 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 56FCC21E80CC for ; Wed, 15 Feb 2012 14:51:47 -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 <0018865318@smtp.qbik.com>; Thu, 16 Feb 2012 11:51:46 +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 <0010060123@sago.qbik.com>; Thu, 16 Feb 2012 11:51:37 +1300 Message-ID: <4F3C36F9.2030302@qbik.com> Date: Thu, 16 Feb 2012 11:51:37 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awlatosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C3356.6030100@panozzo.it> <3077.1329345730.658893@puncture> In-Reply-To: <3077.1329345730.658893@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:51:52 -0000 On 16/02/2012 11:42 a.m., Dave Cridland wrote: > On Wed Feb 15 22:36:06 2012, Giovanni Panozzo wrote: >> Il 15/02/2012 22:28, Adrien de Croy ha scritto: >>> >>> having dealt with support issues relating primarily to HTTP for the >>> last >>> 17 years, I'd STRONGLY recommend against using anything HTTP based. The >>> number of proxies that break WebDAV makes it problematic alone. >>> >>> If some clients need HTTP-based access to some IMAP function, they can >>> use a gateway. >> >> Such a gateway should be a mandatory part of the protocol, or we will >> end up on having a lot of servers with the http gateway and many >> other servers without it, really bad user experience. >> >> Could we think a "skype-like" solution, where the client makes two >> attempts: >> >> 1) Direct socket connection on a single TCP port >> and then, in case of failure >> 2) https tunnel of the same protocol (thru optional client side proxy). >> https is more likely to survive across proxyes than http. > > BOSH. long polling is a hideous hack. Proxies hate it. It's basically designing a system to provide a TCP over multiple HTTP over TCP connections. Bloat to the extreme. I understand the reasons why it exist, due to the model of HTTP, but building more things on top of it heading in the wrong direction IMO. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From dave@cridland.net Wed Feb 15 14:54:03 2012 Return-Path: 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 66F3121E8042 for ; Wed, 15 Feb 2012 14:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 bZHnX2t+cu4R for ; Wed, 15 Feb 2012 14:54:02 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 8864021E8032 for ; Wed, 15 Feb 2012 14:54:01 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 9E9711168087; Wed, 15 Feb 2012 22:54:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pwo4SQPriZac; Wed, 15 Feb 2012 22:53:53 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id D64111168067; Wed, 15 Feb 2012 22:53:52 +0000 (GMT) References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> =?US-ASCII?Q?<66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.aw?= =?US-ASCII?Q?atosorigin.net>?= <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C3356.6030100@panozzo.it> <3077.1329345730.658893@puncture> <4F3C36F9.2030302@qbik.com> In-Reply-To: <4F3C36F9.2030302@qbik.com> MIME-Version: 1.0 Message-Id: <3077.1329346432.849825@puncture> Date: Wed, 15 Feb 2012 22:53:52 +0000 From: Dave Cridland To: Adrien de Croy , Giovanni Panozzo , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:54:03 -0000 On Wed Feb 15 22:51:37 2012, Adrien de Croy wrote: > long polling is a hideous hack. Proxies hate it. > > It's basically designing a system to provide a TCP over multiple > HTTP over TCP connections. Bloat to the extreme. > > I understand the reasons why it exist, due to the model of HTTP, > but building more things on top of it heading in the wrong > direction IMO. There are two options if you want to live in the web world - BOSH or WebSockets. WebSocket support is *far* from universal, and BOSH works - and works very well with proxies, despite whatever personal feelings they may have. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From adrien@qbik.com Wed Feb 15 15:01:18 2012 Return-Path: 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 8D60221E80B9 for ; Wed, 15 Feb 2012 15:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[AWL=-2.419, 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 ixgJ6aQpmuAV for ; Wed, 15 Feb 2012 15:01:03 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 56C3B21E80CC for ; Wed, 15 Feb 2012 15:01:02 -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 <0018865332@smtp.qbik.com>; Thu, 16 Feb 2012 12:01:01 +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 <0010060131@sago.qbik.com>; Thu, 16 Feb 2012 12:00:48 +1300 Message-ID: <4F3C3920.6080904@qbik.com> Date: Thu, 16 Feb 2012 12:00:48 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awatosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C3356.6030100@panozzo.it> <3077.1329345730.658893@puncture> <4F3C36F9.2030302@qbik.com> <3077.1329346432.849825@puncture> In-Reply-To: <3077.1329346432.849825@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 23:01:18 -0000 On 16/02/2012 11:53 a.m., Dave Cridland wrote: > On Wed Feb 15 22:51:37 2012, Adrien de Croy wrote: >> long polling is a hideous hack. Proxies hate it. >> >> It's basically designing a system to provide a TCP over multiple HTTP >> over TCP connections. Bloat to the extreme. >> >> I understand the reasons why it exist, due to the model of HTTP, but >> building more things on top of it heading in the wrong direction IMO. > > There are two options if you want to live in the web world - BOSH or > WebSockets. I agree. I guess the question is whether we want to use http for a new mail protocol transport. I'd suggest not. > > WebSocket support is *far* from universal, and BOSH works - and works > very well with proxies, despite whatever personal feelings they may have. sure, since FB adopted long polling proxies have had to begrudgingly support it. It's not without issues, and as to whether it's more reliable to make a BOSH virtual TCP connection than just a TCP connection or not I don't have a feeling for. My understanding is this approach is used to basically bypass firewall filtering / blocking of ports. But it makes the task of trying to impose some meaningful restrictions on "web access" very difficult for customers let alone proxy vendors. In the end we could layer everything on top of HTTP. If you don't care about performance or resource consumption. Adrien > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From adrien@qbik.com Wed Feb 15 15:18:23 2012 Return-Path: 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 1D7CB21E804B for ; Wed, 15 Feb 2012 15:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[AWL=-2.319, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 HOkaXn3OFl2o for ; Wed, 15 Feb 2012 15:18:18 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id F156221E8032 for ; Wed, 15 Feb 2012 15:18:17 -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 <0018865373@smtp.qbik.com>; Thu, 16 Feb 2012 12:18:16 +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 <0010060151@sago.qbik.com>; Thu, 16 Feb 2012 12:18:02 +1300 Message-ID: <4F3C3D2A.2050609@qbik.com> Date: Thu, 16 Feb 2012 12:18:02 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awatosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C3356.6030100@panozzo.it> <3077.1329345730.658893@puncture> <4F3C36F9.2030302@qbik.com> <3077.1329346432.849825@puncture> In-Reply-To: <3077.1329346432.849825@puncture> Content-Type: multipart/alternative; boundary="------------060201020207080607050301" Cc: "IMAP5 list." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 23:18:23 -0000 This is a multi-part message in MIME format. --------------060201020207080607050301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit thanks for the pointer on BOSH. Some of the claims they make are patently false however. Especially in http://xmpp.org/extensions/xep-0124.html Sec 4. "Therefore, if over time the traffic to and from the client is balanced, bandwidth consumption will be about the same as if a standard TCP connection were being used" this completely ignores the overhead of the HTTP request and HTTP response, which can be very large. A protocol layered over BOSH which makes lots of small transmissions will have its bandwidth consumption greatly increased. IME most transactions have an http overhead > 1KB. There are minimum requirements for headers which must be included in order to be valid HTTP. So telnet over BOSH would increase bandwidth consumption by 500 times. It's quite amazing this statement remains in that document. On 16/02/2012 11:53 a.m., Dave Cridland wrote: > On Wed Feb 15 22:51:37 2012, Adrien de Croy wrote: >> long polling is a hideous hack. Proxies hate it. >> >> It's basically designing a system to provide a TCP over multiple HTTP >> over TCP connections. Bloat to the extreme. >> >> I understand the reasons why it exist, due to the model of HTTP, but >> building more things on top of it heading in the wrong direction IMO. > > There are two options if you want to live in the web world - BOSH or > WebSockets. > > WebSocket support is *far* from universal, and BOSH works - and works > very well with proxies, despite whatever personal feelings they may have. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ --------------060201020207080607050301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit thanks for the pointer on BOSH.

<OT>

Some of the claims they make are patently false however.  Especially in http://xmpp.org/extensions/xep-0124.html Sec 4.

"Therefore, if over time the traffic to and from the client is balanced, bandwidth consumption will be about the same as if a standard TCP connection were being used"

this completely ignores the overhead of the HTTP request and HTTP response, which can be very large.  A protocol layered over BOSH which makes lots of small transmissions will have its bandwidth consumption greatly increased.  IME most transactions have an http overhead > 1KB.  There are minimum requirements for headers which must be included in order to be valid HTTP.  So telnet over BOSH would increase bandwidth consumption by 500 times.

It's quite amazing this statement remains in that document.

</OT>


On 16/02/2012 11:53 a.m., Dave Cridland wrote:
On Wed Feb 15 22:51:37 2012, Adrien de Croy wrote:
long polling is a hideous hack.  Proxies hate it.

It's basically designing a system to provide a TCP over multiple HTTP over TCP connections.  Bloat to the extreme.

I understand the reasons why it exist, due to the model of HTTP, but building more things on top of it heading in the wrong direction IMO.

There are two options if you want to live in the web world - BOSH or WebSockets.

WebSocket support is *far* from universal, and BOSH works - and works very well with proxies, despite whatever personal feelings they may have.

Dave. 

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
--------------060201020207080607050301-- From cking@mumbo.ca Wed Feb 15 15:50:57 2012 Return-Path: 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 6BD6C21E80D1 for ; Wed, 15 Feb 2012 15:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 A1KmVJ9vFcIt for ; Wed, 15 Feb 2012 15:50:52 -0800 (PST) Received: from monet.mumbo.ca (monet.mumbo.ca [204.109.63.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7253321E801D for ; Wed, 15 Feb 2012 15:50:49 -0800 (PST) Received: from dali.mumbo.ca (S0106f8c001bbc600.gv.shawcable.net [24.69.174.164]) by monet.mumbo.ca (Postfix) with ESMTPA id AC9E345044; Wed, 15 Feb 2012 15:50:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Curtis King In-Reply-To: <8D2D1D68-1022-4FBA-88D6-FD3C9064B9CE@iki.fi> Date: Wed, 15 Feb 2012 15:50:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <8D2D1D68-1022-4FBA-88D6-FD3C9064B9CE@iki.fi> To: Timo Sirainen X-Mailer: Apple Mail (2.1257) Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 23:50:57 -0000 On 2012-02-15, at 2:29 PM, Timo Sirainen wrote: > On 16.2.2012, at 0.25, Dave Cridland wrote: >=20 >> On Wed Feb 15 22:05:15 2012, Adrien de Croy wrote: >>> * Any other feature we think would give us an edge. >>=20 >> This mailing list is "Discussion on drastically slimming-down IMAP", = and you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV = *and* Submission, and then thrown in a kitchen sink too. >>=20 >> I'm impressed. >=20 > Who wrote that description? :) Good question > I never thought this list was about that. Except maybe in some = politically correct sense. https://www.ietf.org/mailman/listinfo/imap5 ck From adrien@qbik.com Wed Feb 15 16:03:22 2012 Return-Path: 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 EAC7021E8084 for ; Wed, 15 Feb 2012 16:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.824 X-Spam-Level: X-Spam-Status: No, score=-4.824 tagged_above=-999 required=5 tests=[AWL=-2.225, 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 k-aHw+5vNrIS for ; Wed, 15 Feb 2012 16:03:17 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4918921E801D for ; Wed, 15 Feb 2012 16:03:17 -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 <0018865441@smtp.qbik.com>; Thu, 16 Feb 2012 13:03:16 +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 <0010060184@sago.qbik.com>; Thu, 16 Feb 2012 13:03:10 +1300 Message-ID: <4F3C47BE.3030500@qbik.com> Date: Thu, 16 Feb 2012 13:03:10 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Curtis King References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <8D2D1D68-1022-4FBA-88D6-FD3C9064B9CE@iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Timo Sirainen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 00:03:23 -0000 On 16/02/2012 12:50 p.m., Curtis King wrote: > https://www.ietf.org/mailman/listinfo/imap5 so, what's the upshot of that? do need to change the description associated with the list / scope? Regards Adrien > ck > > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From blong@google.com Wed Feb 15 16:26:51 2012 Return-Path: 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 DFB1421E807F for ; Wed, 15 Feb 2012 16:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 0PqbsG4Rgzwa for ; Wed, 15 Feb 2012 16:26:46 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B58AF21E801D for ; Wed, 15 Feb 2012 16:26:46 -0800 (PST) Received: by qan41 with SMTP id 41so1751633qan.10 for ; Wed, 15 Feb 2012 16:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=yGosM/7IAHZGzjiVsl4kmatMit3g2EPHExccv9ysLVA=; b=0AbzC8ArbwuzXuAxA7DSRNX1lLMKBIoZlTaKnCpNl3yU0ygGJeP80Lr7dZgRF9J/x1 VsZWgBmYXe2Ohy9WwFBAsAzKd823DalhbuEiXDoYSZ1fYHxoArZlVtrcbHU4F1MGxexv IcmkNX8nQBG82R2l1+TQfvU0O54dCzkNQq/3I= Received: by 10.229.111.165 with SMTP id s37mr173578qcp.80.1329352004343; Wed, 15 Feb 2012 16:26:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.111.165 with SMTP id s37mr173560qcp.80.1329352004104; Wed, 15 Feb 2012 16:26:44 -0800 (PST) Received: by 10.229.216.201 with HTTP; Wed, 15 Feb 2012 16:26:43 -0800 (PST) In-Reply-To: <4F3C2362.2060007@qbik.com> References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> Date: Wed, 15 Feb 2012 16:26:43 -0800 Message-ID: From: Brandon Long To: Adrien de Croy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmtem1vNDuIZord5dX6QVtkkcUqcjP3AqqS0WFxamGrXn4uC4k0osHL27bMg4EqvStMZyvPxc1lqaiXS+tKIR0KYh1e9XPHh95nkLWmJYhVDj3dPsMcWHY2q4dGvZakrObYVrBh Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 00:26:52 -0000 This is the second time I've heard about concern that proxies would break access to my mail data over http. Take those issues out of the loop, use https instead. That way, the data's encrypted end-end anyways, which of course it should be. I know people hate dealing with certs, but I think we're well past the point at which people want their personal mail traveling unencrypted from their mailstore to their client. Brandon On Wed, Feb 15, 2012 at 1:28 PM, Adrien de Croy wrote: > > having dealt with support issues relating primarily to HTTP for the last = 17 > years, I'd STRONGLY recommend against using anything HTTP based. =A0The n= umber > of proxies that break WebDAV makes it problematic alone. > > If some clients need HTTP-based access to some IMAP function, they can us= e a > gateway. > > Then an administrator can choose whether to allow such access. =A0But cli= ents > using the protocol that provides it all don't need it. > > If you're a system admin, and there's a product you can install where you > install 1 service, open 1 port and it provides everything you'd go for th= at > right? > > If we play our cards right, it should be simple for some gateway to provi= de > legacy interfaces to the new protocol. > > re the discussion about richness of protocol... sure you can do things at= a > lower level. =A0That typically requires more round-trips to the server th= ough. > > unless the things are pipelined..... specifically designed to be, so a > single meta command is sent as a bunch of micro commands... but therein l= ie > a multitude of problems (e.g. enforcing security, synchronisation etc). > > Adrien > > > > On 16/02/2012 10:13 a.m., Bron Gondwana wrote: >> >> On Wed, Feb 15, 2012 at 09:59:56PM +0100, Michel S=E9bastien wrote: >>>>> >>>>> On 15/02/2012 14:19, Bron Gondwana wrote: >>>>>> >>>>>> On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote: >>>>>>> >>>>>>> Is there any reason to keep subscriptions in IMAP 5 ? >>>>>> >>>>>> I envisage "subscription" as either an annotation or a "Special Use" >>>>>> on a folder rather than yet another axis of data. >>>>> >>>>> +1. >>> >>> Does it works with shared folders ? >> >> Sure, it's a private annotation. >> >>>> This is not a problem that's unique to email. =A0There's nothing reall= y >>>> special about email here unless you make it special. =A0Sure there's a= bunch >>>> of indexed and optimised ways of viewing that data - sort by trimmed >>>> subject, encodings, etc. =A0All of which could be expressed as generic= queries >>>> against the data model with a query optimiser on the far end rather th= an >>>> needing a custom syntax for everything... >>>> >>> Some others seems to think that webdav could be a candidate : >>> http://www.webdav.org/other/faq.html#Q26 >>> A new layer on top of webdav, with some keywords registered at IANA. Bu= t >>> I just don't like the trend to use HTTP for everything... despite its >>> interest here. >> >> Yes, webdav is tempting for a few reasons - the downside is >> a relatively high overhead. >> >> BEEP has also been mentioned. =A0A good advantage of both of >> these is that you can transport unmodified MIME across them. >> I'm wary of anything which will require the raw MIME bodies >> of messages to be encoded across the wire - some sort of >> length based literal syntax is very valuable. >> >> Of course it's hard to love something with examples like this: >> >> =A0S: RPY 0 1 . 221 185 >> >> =A0S: Content-Type: application/beep+xml >> =A0S: >> =A0S: >> =A0S:PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0jaS5uZXQ+]]> >> =A0S: >> =A0S: END >> >> It makes MIME header encoding look so lightweight in comparison. >> >> >> Still... as I'm regretting learning, compatible is more important >> than good. =A0If there exist libraries everywhere which can >> reliably read and write that, and it's ugly enough that nobody >> wants to do it themselves, then maybe - just maybe, you'll actually >> get BETTER complience than if it's a simple enough protocol that >> people roll almost-correct code by hand. >> >> Bron. >> _______________________________________________ >> imap5 mailing list >> imap5@ietf.org >> https://www.ietf.org/mailman/listinfo/imap5 > > > -- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com > WinGate 7 is released! - http://www.wingate.com/getlatest/ > > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 From adrien@qbik.com Wed Feb 15 16:44:08 2012 Return-Path: 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 5DF8E1F0C46 for ; Wed, 15 Feb 2012 16:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[AWL=-2.140, 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 L6hSTo9Izwuu for ; Wed, 15 Feb 2012 16:44:03 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 87DC821F8532 for ; Wed, 15 Feb 2012 16:44:02 -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 <0018865498@smtp.qbik.com>; Thu, 16 Feb 2012 13:44:01 +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 <0010060213@sago.qbik.com>; Thu, 16 Feb 2012 13:43:59 +1300 Message-ID: <4F3C514F.1010602@qbik.com> Date: Thu, 16 Feb 2012 13:43:59 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Brandon Long References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 00:44:08 -0000 On 16/02/2012 1:26 p.m., Brandon Long wrote: > This is the second time I've heard about concern that proxies would > break access to my mail data over http. layering other protocols over HTTP is currently an arms-race between client-software developers who want to do this, and proxy developers who want to provide the tools their customers (sys admins) ask for to allow them to prevent it. the harder it gets to block something intelligently, the more likely admins will resort to over-blocking. We see it every day. Developing a new protocol for mail designed ONLY to layer over HTTP is therefore extremely foolhardy. Sure by all means have options. HTTPS is no different. There are already proxies that scan and restrict https. IMO we'd be better off designing a protocol that is clearly identifiable (e.g. port) and easily able to be restricted. Then it is more likely to be explicitly permitted than fall victim to overblocking. I wonder what will happen when malware authors start using BOSH for instance, how long it will be before it's locked down. We already see malware using https / CONNECT which results in those services being locked down. I agree re encryption, but IMAP already has STARTTLS. (what I'd like to see is mandatory client certs for mail sending) Adrien > > Take those issues out of the loop, use https instead. That way, the > data's encrypted end-end anyways, which of course it should be. > > I know people hate dealing with certs, but I think we're well past the > point at which people want their personal mail traveling unencrypted > from their mailstore to their client. > > Brandon > > On Wed, Feb 15, 2012 at 1:28 PM, Adrien de Croy wrote: >> having dealt with support issues relating primarily to HTTP for the last 17 >> years, I'd STRONGLY recommend against using anything HTTP based. The number >> of proxies that break WebDAV makes it problematic alone. >> >> If some clients need HTTP-based access to some IMAP function, they can use a >> gateway. >> >> Then an administrator can choose whether to allow such access. But clients >> using the protocol that provides it all don't need it. >> >> If you're a system admin, and there's a product you can install where you >> install 1 service, open 1 port and it provides everything you'd go for that >> right? >> >> If we play our cards right, it should be simple for some gateway to provide >> legacy interfaces to the new protocol. >> >> re the discussion about richness of protocol... sure you can do things at a >> lower level. That typically requires more round-trips to the server though. >> >> unless the things are pipelined..... specifically designed to be, so a >> single meta command is sent as a bunch of micro commands... but therein lie >> a multitude of problems (e.g. enforcing security, synchronisation etc). >> >> Adrien >> >> >> >> On 16/02/2012 10:13 a.m., Bron Gondwana wrote: >>> On Wed, Feb 15, 2012 at 09:59:56PM +0100, Michel Sébastien wrote: >>>>>> On 15/02/2012 14:19, Bron Gondwana wrote: >>>>>>> On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote: >>>>>>>> Is there any reason to keep subscriptions in IMAP 5 ? >>>>>>> I envisage "subscription" as either an annotation or a "Special Use" >>>>>>> on a folder rather than yet another axis of data. >>>>>> +1. >>>> Does it works with shared folders ? >>> Sure, it's a private annotation. >>> >>>>> This is not a problem that's unique to email. There's nothing really >>>>> special about email here unless you make it special. Sure there's a bunch >>>>> of indexed and optimised ways of viewing that data - sort by trimmed >>>>> subject, encodings, etc. All of which could be expressed as generic queries >>>>> against the data model with a query optimiser on the far end rather than >>>>> needing a custom syntax for everything... >>>>> >>>> Some others seems to think that webdav could be a candidate : >>>> http://www.webdav.org/other/faq.html#Q26 >>>> A new layer on top of webdav, with some keywords registered at IANA. But >>>> I just don't like the trend to use HTTP for everything... despite its >>>> interest here. >>> Yes, webdav is tempting for a few reasons - the downside is >>> a relatively high overhead. >>> >>> BEEP has also been mentioned. A good advantage of both of >>> these is that you can transport unmodified MIME across them. >>> I'm wary of anything which will require the raw MIME bodies >>> of messages to be encoded across the wire - some sort of >>> length based literal syntax is very valuable. >>> >>> Of course it's hard to love something with examples like this: >>> >>> S: RPY 0 1 . 221 185 >>> >>> S: Content-Type: application/beep+xml >>> S: >>> S: >>> S:PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1 >>> jaS5uZXQ+]]> >>> S: >>> S: END >>> >>> It makes MIME header encoding look so lightweight in comparison. >>> >>> >>> Still... as I'm regretting learning, compatible is more important >>> than good. If there exist libraries everywhere which can >>> reliably read and write that, and it's ugly enough that nobody >>> wants to do it themselves, then maybe - just maybe, you'll actually >>> get BETTER complience than if it's a simple enough protocol that >>> people roll almost-correct code by hand. >>> >>> Bron. >>> _______________________________________________ >>> imap5 mailing list >>> imap5@ietf.org >>> https://www.ietf.org/mailman/listinfo/imap5 >> >> -- >> Adrien de Croy - WinGate Proxy Server - http://www.wingate.com >> WinGate 7 is released! - http://www.wingate.com/getlatest/ >> >> _______________________________________________ >> imap5 mailing list >> imap5@ietf.org >> https://www.ietf.org/mailman/listinfo/imap5 -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From arnt@gulbrandsen.priv.no Wed Feb 15 22:55:36 2012 Return-Path: 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 53E3221E8017 for ; Wed, 15 Feb 2012 22:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 NzCTdCqhItl5 for ; Wed, 15 Feb 2012 22:55:35 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id C32AD21E8011 for ; Wed, 15 Feb 2012 22:55:35 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 62B93F8C8DE; Thu, 16 Feb 2012 06:55:33 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1329375332-12558-12558/10/7; Thu, 16 Feb 2012 06:55:32 +0000 Message-Id: <4F3CA887.9050509@gulbrandsen.priv.no> Date: Thu, 16 Feb 2012 07:56:07 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> In-Reply-To: <3077.1329344733.342803@puncture> Content-Type: text/plain; charset=iso-8859-1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 06:55:36 -0000 On 02/15/2012 11:25 PM, Dave Cridland wrote: > This mailing list is "Discussion on drastically slimming-down IMAP", and > you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV *and* > Submission, and then thrown in a kitchen sink too. As I see it, he's listed features which are in the Exchange protocol and in the unnamed protocol spoken by gmail's javascript heap and its mothership. That makes them worthy of discussion. I know IETF dogma is that protocols shouldn't overlap. But it's a weak kind of dogma: IMAP overlaps with POP, POP overlaps with Submission, various IMAP extensions with ACAP and what's that about IMSP? I could go on. Arnt From adrien@qbik.com Wed Feb 15 23:11:03 2012 Return-Path: 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 AE0DB21F85A0 for ; Wed, 15 Feb 2012 23:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.66 X-Spam-Level: X-Spam-Status: No, score=-4.66 tagged_above=-999 required=5 tests=[AWL=-2.061, 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 vKNoqYxxhvnV for ; Wed, 15 Feb 2012 23:10:58 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id EEA6D21F8591 for ; Wed, 15 Feb 2012 23:10:54 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018865982@smtp.qbik.com>; Thu, 16 Feb 2012 20:10:52 +1300 Message-ID: <4F3CABDB.8080203@qbik.com> Date: Thu, 16 Feb 2012 20:10:19 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Arnt Gulbrandsen References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> In-Reply-To: <4F3CA887.9050509@gulbrandsen.priv.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 07:11:04 -0000 On 16/02/2012 7:56 p.m., Arnt Gulbrandsen wrote: > On 02/15/2012 11:25 PM, Dave Cridland wrote: >> This mailing list is "Discussion on drastically slimming-down IMAP", and >> you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV *and* >> Submission, and then thrown in a kitchen sink too. > As I see it, he's listed features which are in the Exchange protocol and > in the unnamed protocol spoken by gmail's javascript heap and its > mothership. > > That makes them worthy of discussion. > > I know IETF dogma is that protocols shouldn't overlap. But it's a weak > kind of dogma: IMAP overlaps with POP, POP overlaps with Submission, > various IMAP extensions with ACAP and what's that about IMSP? I could go on. actually with a layered approach, this dogma could be maintained, as the facilities would be able to be specified separately. Would be interesting to see wire-line protocol on GMail - I bet they use Json Regards Adrien > > Arnt > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From brong@fastmail.fm Wed Feb 15 23:53:16 2012 Return-Path: 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 E16DD21E802E for ; Wed, 15 Feb 2012 23:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 L+spnzeaHLlr for ; Wed, 15 Feb 2012 23:53:11 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1B421E8034 for ; Wed, 15 Feb 2012 23:53:11 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6579520B2D for ; Thu, 16 Feb 2012 02:53:10 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute4.internal (MEProxy); Thu, 16 Feb 2012 02:53:10 -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= PPe3OO5n5w8gE6P1Rtv4GwQBQUs=; b=CKLF8qzm8RNo8pZM44f4423pcWRHNyPe cRgb5GpqyUNLLZZIqBpD/YMvQbds+iQ7GKMxNx0riP+xjKyjNr4Kpd+CGZm3uFzb pnHjBNOOZ6Kxq/IXkfAwIP1uHc+7g9uWcnW4PkoPJ4jl2FtY3RyurW7D2Oqo9lg/ 6J9QinADGHU= 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=PPe3OO5n5w8gE6P1Rtv4GwQBQUs=; b= VQHdmYvjpTS0SFQIeKJ4HOnIEcH7plS7YdetTT04DjY9rnMMNfVt+f5M0vUXsMI5 Ujys+60eOvkPpgRRII2Xhr+6XOQM79/RO3S116Uq3kYtN2pGBPWybtZahZUMvd40 e9zYmjE2qjHDvsR/3MNcSF2kejEU2946JPywXwEkPQ8= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 3AEE4A000D0; Thu, 16 Feb 2012 02:53:10 -0500 (EST) Message-Id: <1329378790.1730.140661037246165@webmail.messagingengine.com> X-Sasl-Enc: clBsbzmHSX421JPL1GzxI/9PiX6s4eSZnRARZDdaR8fc 1329378790 From: Bron Gondwana To: Adrien de Croy , Arnt Gulbrandsen MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <4F397212.1030107@qbik.com><20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net><4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no> <4F3CABDB.8080203@qbik.com> In-Reply-To: <4F3CABDB.8080203@qbik.com> Date: Thu, 16 Feb 2012 08:53:10 +0100 Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 07:53:17 -0000 On Thu, Feb 16, 2012, at 08:10 PM, Adrien de Croy wrote: > On 16/02/2012 7:56 p.m., Arnt Gulbrandsen wrote: > > On 02/15/2012 11:25 PM, Dave Cridland wrote: > >> This mailing list is "Discussion on drastically slimming-down IMAP", and > >> you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV *and* > >> Submission, and then thrown in a kitchen sink too. > > As I see it, he's listed features which are in the Exchange protocol and > > in the unnamed protocol spoken by gmail's javascript heap and its > > mothership. > > > > That makes them worthy of discussion. > > > > I know IETF dogma is that protocols shouldn't overlap. But it's a weak > > kind of dogma: IMAP overlaps with POP, POP overlaps with Submission, > > various IMAP extensions with ACAP and what's that about IMSP? I could go on. > > actually with a layered approach, this dogma could be maintained, as the > facilities would be able to be specified separately. > > Would be interesting to see wire-line protocol on GMail - I bet they use > Json Yes they do - with the "while(1);" hack at the top to stop it being scraped by cross site tricks. It's quite a clever workaround - any cross site request that tries to embed the JSON URL just freezes - so the remote site can't actually read the data. We (mail.opera.com) also use JSON. Ours is probably much less efficient over the wire, because we chose readability over optimisation at this stage, so we have named keys. We will hopefully have two independent clients for it soon, which will help us keep it stable. I'm not sure that it's an ideal place to start either though. At least it was designed with a direct mapping to IMAP in mind, so the data models are as similar as we could get (though we "extended" IMAP to support the cross folder things we needed) Bron. -- Bron Gondwana brong@fastmail.fm From arnt@gulbrandsen.priv.no Thu Feb 16 00:20:38 2012 Return-Path: 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 536D621E802B for ; Thu, 16 Feb 2012 00:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] 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 DzyCHhqV463E for ; Thu, 16 Feb 2012 00:20:37 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id AE9F821E8013 for ; Thu, 16 Feb 2012 00:20:37 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 65E3EF8C8FE; Thu, 16 Feb 2012 08:20:35 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1329380434-12558-12558/10/8; Thu, 16 Feb 2012 08:20:34 +0000 Message-Id: <4F3CBC75.7050509@gulbrandsen.priv.no> Date: Thu, 16 Feb 2012 09:21:09 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <4F3CABDB.8080203@qbik.com> <1329378790.1730.140661037246165@webmail.messagingengine.com> In-Reply-To: <1329378790.1730.140661037246165@webmail.messagingengine.com> Content-Type: text/plain; charset=iso-8859-1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 08:20:38 -0000 Bron wrote (about exchange, gmail, mail.opera, I think): > I'm not sure that it's an ideal place to > start either though. No. IMAP4 is the default starting point. But the success of these things is such that the difference between their designs and that of IMAP4 cannot be disregarded. IMAP4 by design excludes (taking an example at random) mail submission. I think if Adrian or anyone else puts forward a cogent argument that IMAP's excluding mail submission is wrong, then the charter should permit discussing that. Arnt From arnt@gulbrandsen.priv.no Thu Feb 16 00:26:13 2012 Return-Path: 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 3761021F8550 for ; Thu, 16 Feb 2012 00:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 vvjRXmD7kcZ3 for ; Thu, 16 Feb 2012 00:26:12 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id A457621F8545 for ; Thu, 16 Feb 2012 00:26:12 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4B5D3F8C8FE; Thu, 16 Feb 2012 08:26:11 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1329380770-12558-12558/10/9; Thu, 16 Feb 2012 08:26:10 +0000 Message-Id: <4F3CBDC6.2030708@gulbrandsen.priv.no> Date: Thu, 16 Feb 2012 09:26:46 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <4F3CABDB.8080203@qbik.com> <1329378790.1730.140661037246165@webmail.messagingengine.com> <4F3CBC75.7050509@gulbrandsen.priv.no> In-Reply-To: <4F3CBC75.7050509@gulbrandsen.priv.no> Content-Type: text/plain; charset=iso-8859-1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 08:26:13 -0000 Oh. I misspelled Adrien's name. I'm so sorry. Arnt From dave@cridland.net Thu Feb 16 00:50:03 2012 Return-Path: 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 13B1321F86B8 for ; Thu, 16 Feb 2012 00:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] 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 XLYpYjodamzr for ; Thu, 16 Feb 2012 00:49:57 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 0187521F86BB for ; Thu, 16 Feb 2012 00:49:48 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 102801168087; Thu, 16 Feb 2012 08:49:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFw+r54NG-5m; Thu, 16 Feb 2012 08:49:37 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 65C6C1168067; Thu, 16 Feb 2012 08:49:37 +0000 (GMT) References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> In-Reply-To: <4F3CA887.9050509@gulbrandsen.priv.no> MIME-Version: 1.0 Message-Id: <3077.1329382177.374908@puncture> Date: Thu, 16 Feb 2012 08:49:37 +0000 From: Dave Cridland To: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 08:50:03 -0000 On Thu Feb 16 06:56:07 2012, Arnt Gulbrandsen wrote: > On 02/15/2012 11:25 PM, Dave Cridland wrote: > > This mailing list is "Discussion on drastically slimming-down > IMAP", and > > you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, > CardDAV *and* > > Submission, and then thrown in a kitchen sink too. > > As I see it, he's listed features which are in the Exchange > protocol and > in the unnamed protocol spoken by gmail's javascript heap and its > mothership. > > That makes them worthy of discussion. I'm mostly revelling in the irony. > I know IETF dogma is that protocols shouldn't overlap. But it's a > weak > kind of dogma: IMAP overlaps with POP, POP overlaps with Submission, > various IMAP extensions with ACAP and what's that about IMSP? I > could go on. There's two huge problems with the approach. Firstly, using a generic data model, or a generic protocol, automatically produces compromise. I've learnt to mistrust genericity in protocols - it all seems like such a lovely idea, and then everything turns into the bastard offspring of SQL. And the thing with SQL is that you can do useful things like indices and whotsits, which let you specialize the data store, but nobody ever gets that far. The only cases where this has worked is to partially specialize the datastore - LDAP/X.500 does this, as did ACAP - but only one of those has succeeded by any metric. I'd note that, similarly, METADATA and ANNOTATE should have done well, if it weren't for the fact they expanded beyond a simple dumping ground for "everything else", and people tried to use them as the One True Datastore. Secondly, the broader the scope, the bigger the task - I don't see any likelyhood of getting such a protocol sorted out before the end of the decade, or beyond. The phrase "boil the ocean" springs to mind. Remember, Exchange and the like are not successful because they do calendaring and mail, they're successful because they seamlessly blend calendaring and mail - the result is more than the sum of its parts, but making that blend will not be easy. Aside from anything else - you want configuration storage services in $NEWPROTO? Well, I surely want these to have all the facilities that ACAP gives me. Calendaring? I'm sure that Cyrus will want it to have parity with, or exceed, CalDAV. Mail? There's any number of folk here who'll want their own special sauce in. And they'd be right, from their perspective, and the net result would be unimplementable. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From sebastien.michel@atos.net Thu Feb 16 01:07:31 2012 Return-Path: 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 33BAC21F8497 for ; Thu, 16 Feb 2012 01:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 jaa01DeyC1ML for ; Thu, 16 Feb 2012 01:07:28 -0800 (PST) Received: from smtp1.mail.atosorigin.com (smtp1.mail.atosorigin.com [160.92.103.80]) by ietfa.amsl.com (Postfix) with ESMTP id CA89221F8712 for ; Thu, 16 Feb 2012 01:07:23 -0800 (PST) Received: from filter.atosorigin.com (localhost [127.0.0.1]) by mxfed001 (Postfix) with ESMTP id 8626620001A5; Thu, 16 Feb 2012 10:07:20 +0100 (CET) Received: from mail.awl.fr.atosorigin.com (serv-smtp-wse02.fr.atosworldline.com [160.92.103.181]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "mail.awl.fr.atosorigin.com", Issuer "VeriSign Class 3 Secure Server CA - G2" (verified OK)) by mxfed001 (Postfix) with ESMTP id 7FD9C20000B2; Thu, 16 Feb 2012 10:07:20 +0100 (CET) Received: from frspx302.fr01.awl.atosorigin.net (10.24.253.187) by frspx402.priv.atos.fr (10.24.220.8) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 10:07:19 +0100 Received: from FRSPX100.fr01.awl.atosorigin.net ([10.24.253.184]) by frspx302.fr01.awl.atosorigin.net ([10.24.253.187]) with mapi; Thu, 16 Feb 2012 10:07:20 +0100 From: =?iso-8859-1?Q?Michel_S=E9bastien?= To: Adrien de Croy , Brandon Long Date: Thu, 16 Feb 2012 10:07:18 +0100 Thread-Topic: [imap5] Designing a new replacement protocol for IMAP Thread-Index: AczsRBoKf2dW8UGuRTKChTDcs3cNBAARZRpQ Message-ID: <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> In-Reply-To: <4F3C514F.1010602@qbik.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:07:31 -0000 >On 16/02/2012 1:26 p.m., Brandon Long wrote: >> This is the second time I've heard about concern that proxies would >> break access to my mail data over http. > >layering other protocols over HTTP is currently an arms-race between clien= t-software developers who want to do this, and proxy developers who want to= provide the tools their customers (sys admins) ask for to allow them to pr= event it. > >the harder it gets to block something intelligently, the more likely admin= s will resort to over-blocking. We see it every day. > >Developing a new protocol for mail designed ONLY to layer over HTTP is the= refore extremely foolhardy. Sure by all means have options. I'm not really convinced, does it means that CalDAV and CardDAV are on the = wrong way ? I think not, even if they are not supported by all mobile platf= orms Ce message et les pi=E8ces jointes sont confidentiels et r=E9serv=E9s =E0 l= 'usage exclusif de ses destinataires. Il peut =E9galement =EAtre prot=E9g= =E9 par le secret professionnel. Si vous recevez ce message par erreur, mer= ci d'en avertir imm=E9diatement l'exp=E9diteur et de le d=E9truire. L'int= =E9grit=E9 du message ne pouvant =EAtre assur=E9e sur Internet, la responsa= bilit=E9 d'Atos ne pourra =EAtre recherch=E9e quant au contenu de ce messag= e. Bien que les meilleurs efforts soient faits pour maintenir cette transmi= ssion exempte de tout virus, l'exp=E9diteur ne donne aucune garantie =E0 ce= t =E9gard et sa responsabilit=E9 ne saurait =EAtre recherch=E9e pour tout d= ommage r=E9sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integr= ity cannot be secured on the Internet, the Atos liability cannot be trigger= ed for the message content. Although the sender endeavours to maintain a co= mputer virus-free network, the sender does not warrant that this transmissi= on is virus-free and will not be liable for any damages resulting from any = virus transmitted. From adrien@qbik.com Thu Feb 16 01:21:30 2012 Return-Path: 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 B22B521F86DA for ; Thu, 16 Feb 2012 01:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-4.611, BAYES_00=-2.599, GB_SUMOF=5] 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 AXar7WposKyo for ; Thu, 16 Feb 2012 01:21:26 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id A112521F86AD for ; Thu, 16 Feb 2012 01:21:24 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018866148@smtp.qbik.com>; Thu, 16 Feb 2012 22:21:23 +1300 Message-ID: <4F3CCA6C.3020004@qbik.com> Date: Thu, 16 Feb 2012 22:20:44 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> In-Reply-To: <3077.1329382177.374908@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:21:30 -0000 Hi Dave I agree with the things you've said about generic protocols, and trying to fix all the worlds problems - e.g. scoping something too big to be doable. This all started when Brom sent an email around about a replacement protocol for IMAP. One of the main problems with the current suite of protocols used for mail, is that even if one could implement them all, providing a better user experience than Exchange or Gmail would not be the result. Add to that the fact that specifying a new mail protocol is a heap of work, the obvious question was why limit ourselves to only providing a replacement. Forever is a long time. That's why I proposed a layered approach. If you look at a mail client even like Thunderbird, which I'm using to write this mail. There are settings for: SMTP: specification of server, choice of authentication method, choice of security (SSL vs STARTTLS vs none), username and password. IMAP: specification of server, choice of authentication method, choice of security (SSL vs STARTTLS vs none), username and password. LDAP: specification of server(s), choice of authentication method, choice of security (SSL vs STARTTLS vs none), username and password. If I want a calendar I need to add in something like Lightning (current version not compatible with TB11), or something else. Presumably it uses CalDAV, which goes over WebDAV which goes over HTTP, so I've got credentials to deal with for that, and possibly some intermediary proxy with credentials as well. This all adds up to a complete clusterxxxx - it's an appalling user experience, and supporting it is costly as well. Any one of these settings if wrong is a support call. That's why I proposed condensing all the choice of server, port, auth and security to 1 protocol, and layer the facilities on top. Even if all we did was layer the existing protocols on top of this, we'd be a lot further ahead. Last time I checked it was 2012. Email is supposed to be (or have been) the "killer" internet application - the most important one. To provide such a poor user experience is shameful. Especially after 30 odd years. And of course I understand it's the result of an evolutionary process over time. So of course it's messy and ugly. But unless we do something about it, it will be that way forever, or until someone in future deals with it. Or it gets replaced out from under us by web-based services which are able to independently provide an acceptable user experience. Seems to me that in the context of discussion of a new mail protocol, could be a good time to consider these things. Hence the kitchen sink :) Cheers Adrien On 16/02/2012 9:49 p.m., Dave Cridland wrote: > On Thu Feb 16 06:56:07 2012, Arnt Gulbrandsen wrote: >> On 02/15/2012 11:25 PM, Dave Cridland wrote: >> > This mailing list is "Discussion on drastically slimming-down >> IMAP", and >> > you've listed the properties of ACAP, SIEVE, IMAP, CalDAV, CardDAV >> *and* >> > Submission, and then thrown in a kitchen sink too. >> >> As I see it, he's listed features which are in the Exchange protocol and >> in the unnamed protocol spoken by gmail's javascript heap and its >> mothership. >> >> That makes them worthy of discussion. > > I'm mostly revelling in the irony. > >> I know IETF dogma is that protocols shouldn't overlap. But it's a weak >> kind of dogma: IMAP overlaps with POP, POP overlaps with Submission, >> various IMAP extensions with ACAP and what's that about IMSP? I could >> go on. > > There's two huge problems with the approach. > > Firstly, using a generic data model, or a generic protocol, > automatically produces compromise. I've learnt to mistrust genericity > in protocols - it all seems like such a lovely idea, and then > everything turns into the bastard offspring of SQL. And the thing with > SQL is that you can do useful things like indices and whotsits, which > let you specialize the data store, but nobody ever gets that far. The > only cases where this has worked is to partially specialize the > datastore - LDAP/X.500 does this, as did ACAP - but only one of those > has succeeded by any metric. > > I'd note that, similarly, METADATA and ANNOTATE should have done well, > if it weren't for the fact they expanded beyond a simple dumping > ground for "everything else", and people tried to use them as the One > True Datastore. > > Secondly, the broader the scope, the bigger the task - I don't see any > likelyhood of getting such a protocol sorted out before the end of the > decade, or beyond. The phrase "boil the ocean" springs to mind. > Remember, Exchange and the like are not successful because they do > calendaring and mail, they're successful because they seamlessly blend > calendaring and mail - the result is more than the sum of its parts, > but making that blend will not be easy. > > Aside from anything else - you want configuration storage services in > $NEWPROTO? Well, I surely want these to have all the facilities that > ACAP gives me. Calendaring? I'm sure that Cyrus will want it to have > parity with, or exceed, CalDAV. Mail? There's any number of folk here > who'll want their own special sauce in. And they'd be right, from > their perspective, and the net result would be unimplementable. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From Hagedorn@uni-koeln.de Thu Feb 16 01:35:51 2012 Return-Path: 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 C65B021F86E3 for ; Thu, 16 Feb 2012 01:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] 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 vq7GfKf9JnPO for ; Thu, 16 Feb 2012 01:35:49 -0800 (PST) Received: from smtp-out.rrz.uni-koeln.de (smtp-out.rrz.uni-koeln.de [134.95.19.53]) by ietfa.amsl.com (Postfix) with ESMTP id B918021F84FA for ; Thu, 16 Feb 2012 01:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at uni-koeln.de Received: from smtp-auth.rrz.uni-koeln.de (smtp-auth.rrz.uni-koeln.de [134.95.19.93]) by smtp-out.rrz.uni-koeln.de (8.13.8/8.13.8) with ESMTP id q1G9ZirZ012153; Thu, 16 Feb 2012 10:35:44 +0100 X-AUTH-SIP: a0620@tyrion.rrz.uni-koeln.de [134.95.128.1] Received: from tyrion.rrz.uni-koeln.de (tyrion.rrz.uni-koeln.de [134.95.128.1]) (authenticated as user a0620 using DIGEST-MD5 bits=0) by smtp-auth.uni-koeln.de (8.13.8/8.13.8) with ESMTP id q1G9ZhnW013681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 10:35:43 +0100 Date: Thu, 16 Feb 2012 10:35:43 +0100 From: Sebastian Hagedorn To: Adrien de Croy Message-ID: <8CA186A707E99CE0FB2B38E9@tyrion.rrz.uni-koeln.de> In-Reply-To: <4F3CCA6C.3020004@qbik.com> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========B6579026B09E069A1843==========" X-Scanned-By: MIMEDefang 2.72 on 134.95.19.53 Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:35:51 -0000 --==========B6579026B09E069A1843========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1127 --On 16. Februar 2012 22:20:44 +1300 Adrien de Croy = wrote: > If you look at a mail client even like Thunderbird, which I'm using to > write this mail. > > There are settings for: > > SMTP: specification of server, choice of authentication method, choice of > security (SSL vs STARTTLS vs none), username and password. > IMAP: specification of server, choice of authentication method, choice of > security (SSL vs STARTTLS vs none), username and password. > LDAP: specification of server(s), choice of authentication method, choice > of security (SSL vs STARTTLS vs none), username and password. Another way of dealing with that particular issue is autoconfiguration.=20 Unfortunately there's no accepted standard for that yet, but we (Cologne=20 University) support Microsoft's and Thunderbird's mechanisms. If you enter=20 a @uni-koeln.de address in the new account wizard, all settings are filled=20 in automatically. --=20 .:.Sebastian Hagedorn - RZKR-R1 (Geb=C3=A4ude 52), Zimmer 18.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universit=C3=A4t zu K=C3=B6ln / Cologne University - =E2=9C=86 = +49-221-478-5587.:. --==========B6579026B09E069A1843========== Content-Type: application/pkcs7-signature Content-Transfer-Encoding: base64 MIIUqAYJKoZIhvcNAQcCoIIUmTCCFJUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCEhMwggU5MIIEIaADAgECAgQOtLhdMA0GCSqGSIb3DQEBBQUAMHkxCzAJ BgNVBAYTAkRFMQ4wDAYDVQQHEwVLb2VsbjEeMBwGA1UEChMVVW5pdmVyc2l0YWV0 IHp1IEtvZWxuMRQwEgYDVQQDEwtVbmlLb2VsbiBDQTEkMCIGCSqGSIb3DQEJARYV Y2FtYXN0ZXJAdW5pLWtvZWxuLmRlMB4XDTA5MDgyNjEzMzgyMVoXDTEyMDgyNTEz MzgyMVowcDELMAkGA1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYDVQQKExVV bml2ZXJzaXRhZXQgenUgS29lbG4xFDASBgNVBAsTC1JSWkssIE5ldHplMRswGQYD VQQDExJTZWJhc3RpYW4gSGFnZWRvcm4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCvbrQcOH3+9/Pk2gOBHTD8neKH/ULtE2NJs3hdFgc1Zy8JiSPcQ1is E1zHaiX1RANfhWNu2fCMk1rgmlsJAq0K3YShGxdTzD36tTKKM3i+CEoNPLmWik0x +RWK5d/lSez3WGludxvjICAQsDBuFxok5AdtQcVgv2+PPBbjw8YiJhHyWiVcG0iR 3xE3ExWARR6UAhkQiR8MMD+bCDaSPrmv7O9oEkB3BOxY40cyFTzskb2H68MrCX8S HzHw9lcoE3xBvFEySKGOnJEProhE/x619FDRyXpmw6XqFGmBBufmGc1ymYZclVcl uvBsInBRUumjW6yxlnqEfg7PzVRdJAWpAgMBAAGjggHQMIIBzDAJBgNVHRMEAjAA MAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFFryMqfqZw/rn+SOR8hobWb3X/tmMB8GA1UdIwQY MBaAFCrqiesOstApxf75TKV23LdvTwm6MCAGA1UdEQQZMBeBFUhhZ2Vkb3JuQHVu aS1rb2Vsbi5kZTCBgwYDVR0fBHwwejA7oDmgN4Y1aHR0cDovL2NkcDEucGNhLmRm bi5kZS91bmkta29lbG4tY2EvcHViL2NybC9jYWNybC5jcmwwO6A5oDeGNWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvdW5pLWtvZWxuLWNhL3B1Yi9jcmwvY2FjcmwuY3Js MIGeBggrBgEFBQcBAQSBkTCBjjBFBggrBgEFBQcwAoY5aHR0cDovL2NkcDEucGNh LmRmbi5kZS91bmkta29lbG4tY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEUGCCsG AQUFBzAChjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1rb2Vsbi1jYS9wdWIv Y2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAEAQjwt/trFejwkc b0ZDFda7WWMZ48/a6kyXtDOzQwa82HSM77/hE2lRvryWx7oEW6D9Z84nI1AmjSxb fJI733ASHvw/VyA8mXf9/HRzCIMpiH9Zuk3kBqx6bezVRjL4gprvwP4ApUVPzH5A GGF/iEJl09kO6Cjv5VfbhJubucWJzsgmKuZfmfaHOOQ9uNcVqznmseMbkfVeICMy XfxA4+y5v8w65hb+EFP1rQXwf8csDxN48/g8KOmzOcwYd2+4cNz7vUIduQXUXhsc C+zO8gIZeDdAcDgAxGTGklwkGcuYfrQyJywSCz2GyiKK0Jk9maIKPooRSl7QuG5u q8p2A6swggUKMIID8qADAgECAgQKRUldMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQw IgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMDcwNDE4MDc0 MjA3WhcNMTkwNDE3MDAwMDAwWjB5MQswCQYDVQQGEwJERTEOMAwGA1UEBxMFS29l bG4xHjAcBgNVBAoTFVVuaXZlcnNpdGFldCB6dSBLb2VsbjEUMBIGA1UEAxMLVW5p S29lbG4gQ0ExJDAiBgkqhkiG9w0BCQEWFWNhbWFzdGVyQHVuaS1rb2Vsbi5kZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMvE96PdJusN/alR90nwwV4Y iLNM1ANMT2XN4MbfniygeGzgvMX7T8juVDw4H9LRtehfBvjPqMM7nth1RR5k/gSO yUyRUzcNLZS+UVu0bXARd1WckeS8moERrV+/3HMPqNCJuk67pLjowYw1psja4qsJ aT8yOhpbanc3mZIa9tq+d4mLZ0LvZVhuFxhbIdfl+f2agskQbbYbURcPLH/nsvKt vEnKDfcHeVJGX0hfR7ZBQhCe8XiKUNhKKdQV61UO71vw7dP3xzG8PQH3SnhZKTeY hCU7YgW82PXtv26DCDIg6iJyuODqLYwXTjc1601NoToDMN6WGGP0eC/fOnipm6MC AwEAAaOCAbcwggGzMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0G A1UdDgQWBBQq6onrDrLQKcX++Uyldty3b08JujAfBgNVHSMEGDAWgBRJt8bP6D0f f+pEexMp9/EKcD7eZDAgBgNVHREEGTAXgRVjYW1hc3RlckB1bmkta29lbG4uZGUw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5w Y2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUH MAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCteobYEtkcfAeVJzUD m1S/4mRtTt8E6dKtsVHFVuHSc59Gco57ugZ5PxmzV8PU5Pq45KwYZ0zE8mchP5YO iE43bu4dSeDDcIjoh9l5VanjQ+kMM3qf/tv73bRwanUQIMsd3qYHseqsXusddJgX BLZOfs+/o2FCOQX5UucQBHSFGSOObUx6uYywKDT/lY+3mzAQiA35Df20bN3UCQpA ja3KDqeLRhL8YjTw+K1cU4UwH5G/hErxOsUzhf0aKhNv074cReDkPxpBHi9QhKpQ PBehI/0alzG27CIf2rkMBSXiIwUfKQWtBOOVnDftPTB17qFttkhK4MnIIYVBBKrb AeINMIIEITCCAwmgAwIBAgICAMcwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMC REUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVs ZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UE BhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAi BgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTU IOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFssoNTl7LZBF0O2gAHp8 v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90D8EJ ovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWG fW8zs9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDN SVTbyRM0mnF1xWzqpwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBw BgNVHR8EaTBnMGWgY6Bhhl9odHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9z ZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNz dWVyPURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsTKffxCnA+3mQw HwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfc qRjsga9aifC9KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+ER Ee5reJEzfjtfJid1U2WOM2Puz3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUp QPY/czJYDQlrptqFbMA/u41mZFYkTq4NPzI1AVvpjILZcllPsYaF8XSFVuXD+Fzz je5Hs1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6LArZYtfahLDdXAGer I2iNY6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3LxMr+M zkljqAD38hwwggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNV BAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZU LVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDkyMzU5MDBaMHExCzAJ BgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxl a29tIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsL ozXgiykUsRSFrzwQ5DlvNV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25 TVw6ztO4qEJA38+juoJZapIbrBya2ggrJSf5aSNH8eDrLHqb9RMC0H40fMKePABZ q/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgBSV9yQTwVBgGOXa2quJO0 zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ7lMFjxlM 1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoD NNWOWwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0X bAqzK50zMA8GA1UdEwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCUZFmtOWTnKesT/lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7U wz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLOF/Msx2I2VeIi2IlVtJhIqmT6 1hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjytnv+AWeSbRbT2 O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHl cAWbDiNXmZQKbbo5YyiGkvMYhNj70c8FVmRXMYICXTCCAlkCAQEwgYEweTELMAkG A1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYDVQQKExVVbml2ZXJzaXRhZXQg enUgS29lbG4xFDASBgNVBAMTC1VuaUtvZWxuIENBMSQwIgYJKoZIhvcNAQkBFhVj YW1hc3RlckB1bmkta29lbG4uZGUCBA60uF0wCQYFKw4DAhoFAKCBsTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMTYwOTM1NDNa MCMGCSqGSIb3DQEJBDEWBBRUOYqHC9fapS0YfkV+iqF36yABBTBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBFVHji 6sXFoEtNN9Y1z1fAhnLAlmQlriVcE6+GOnEbSLfHeZjHsvL+RiCe82Gco4246p1b 45GDMlqKwXJB6IMKfrDCaTj5yj+dhfwnAgVMXcUjGYOTDP/czT0fDAhBqVbKogjI hCfUJec456rCxhxRb4/lhTMDESbN3tTe4nVAibZsmKJxy+MQvdeB3yzaUeUW0NYr cyWdXuQCV33NhvGiEaIgYebw67jSKRxcmtTlmzUFUIMWNy/RwjCojk+uKavILQJB KGRkah2we8mawKNRWONwNZogzkwbS52wUieYJ1NH0Fp1yRjJGcxTEGrNRSzkDybA KcFIw97UdTpMJ/zl --==========B6579026B09E069A1843==========-- From giovanni@panozzo.it Thu Feb 16 01:52:51 2012 Return-Path: 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 C19B221F8572 for ; Thu, 16 Feb 2012 01:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 rh+gZBWge37q for ; Thu, 16 Feb 2012 01:52:51 -0800 (PST) Received: from do2.yuu.it (do2.yuu.it [46.37.9.250]) by ietfa.amsl.com (Postfix) with ESMTP id 873E921F85B9 for ; Thu, 16 Feb 2012 01:52:48 -0800 (PST) Received: from [192.168.98.217] (host213-176-static.106-82-b.business.telecomitalia.it [82.106.176.213]) by do2.yuu.it (Postfix) with ESMTPSA id 4C7F680138 for ; Thu, 16 Feb 2012 10:52:36 +0100 (CET) Message-ID: <4F3CD1EB.20002@panozzo.it> Date: Thu, 16 Feb 2012 10:52:43 +0100 From: Giovanni Panozzo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: imap5@ietf.org References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <8CA186A707E99CE0FB2B38E9@tyrion.rrz.uni-koeln.de> In-Reply-To: <8CA186A707E99CE0FB2B38E9@tyrion.rrz.uni-koeln.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:52:51 -0000 > Another way of dealing with that particular issue is autoconfiguration. > Unfortunately there's no accepted standard for that yet, but we (Cologne > University) support Microsoft's and Thunderbird's mechanisms. If you > enter a @uni-koeln.de address in the new account wizard, all settings > are filled in automatically. I'm using autoconfiguration for both M$ and Thubderbird, for some Exchange and IMAP servers. It's quite good, but in my opinion it has 3 major problems: a) As you wrote, it's not a standard :( b) Autoconfiguration is checked only at client configuration. I would like to have the client reconfigured at every startup. This will let me do major changes at the server sides (ie: enable SSL ? Change server names ?), and client will be able to reconfigure themselves at next startup. c) Autoconfiguration for thunderbird does not solve the "multiple channel" problem. Thunderbird is still using one channel (TCP port) for IMAP and one for SMTP (and optionally one for LDAP). A roaming user, when changing network, can find some TCP ports open and some closed. So he/she will be able to only send or receive e-mail. He/she will be confused and he will open an helpdesk ticket. This is not a good user experience. I hope that newer IMAP will address all those problems. From dave@cridland.net Thu Feb 16 01:58:00 2012 Return-Path: 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 9974821F8512 for ; Thu, 16 Feb 2012 01:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 xQ2ELj-mafqq for ; Thu, 16 Feb 2012 01:57:55 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 37BC521F850D for ; Thu, 16 Feb 2012 01:57:55 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id D968C1168087; Thu, 16 Feb 2012 09:57:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cKoQ2zsJ-7A; Thu, 16 Feb 2012 09:57:43 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id A276D1168067; Thu, 16 Feb 2012 09:57:43 +0000 (GMT) References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> In-Reply-To: <4F3CCA6C.3020004@qbik.com> MIME-Version: 1.0 Message-Id: <3077.1329386263.642278@puncture> Date: Thu, 16 Feb 2012 09:57:43 +0000 From: Dave Cridland To: Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:58:00 -0000 On Thu Feb 16 09:20:44 2012, Adrien de Croy wrote: > SMTP: specification of server, choice of authentication method, > choice of security (SSL vs STARTTLS vs none), username and password. > IMAP: specification of server, choice of authentication method, > choice of security (SSL vs STARTTLS vs none), username and password. > LDAP: specification of server(s), choice of authentication method, > choice of security (SSL vs STARTTLS vs none), username and password. Well, of course, I'd argue that you could use a combination of SRV, common options, discovery, and ACAP to fix all that. The problem with Thunderbird isn't that it has all these options, it's that it requires the user to enter them, and fails to do discovery properly - Tony Finch wrote a particularly good blog post on why it's so awful several years ago, and provided solutions, too. Interestingly, XMPP has generally gone the discovery route, and the result is that you only enter a jid and a password. For Polymer, you enter a username, ACAP server, and password - ACAP doesn't have the SRV option, and maybe I should just add that in - not that anyone but me cares anymore. Having written multiprotocol clients, I just don't think they're as hard as people make them out to be. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From adrien@qbik.com Thu Feb 16 01:59:59 2012 Return-Path: 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 9DE7B21F86EE for ; Thu, 16 Feb 2012 01:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.411 X-Spam-Level: X-Spam-Status: No, score=-4.411 tagged_above=-999 required=5 tests=[AWL=-2.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 KZG7jLgeNZgm for ; Thu, 16 Feb 2012 01:59:55 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9021F8516 for ; Thu, 16 Feb 2012 01:59:54 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018866190@smtp.qbik.com>; Thu, 16 Feb 2012 22:59:53 +1300 Message-ID: <4F3CD398.3020901@qbik.com> Date: Thu, 16 Feb 2012 22:59:52 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michel_S=E9bastien?= References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> In-Reply-To: <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:59:59 -0000 On 16/02/2012 10:07 p.m., Michel Sébastien wrote: >> On 16/02/2012 1:26 p.m., Brandon Long wrote: >>> This is the second time I've heard about concern that proxies would >>> break access to my mail data over http. >> layering other protocols over HTTP is currently an arms-race between client-software developers who want to do this, and proxy developers who want to provide the tools their customers (sys admins) ask for to allow them to prevent it. >> >> the harder it gets to block something intelligently, the more likely admins will resort to over-blocking. We see it every day. >> >> Developing a new protocol for mail designed ONLY to layer over HTTP is therefore extremely foolhardy. Sure by all means have options. > I'm not really convinced, does it means that CalDAV and CardDAV are on the wrong way ? I think not, even if they are not supported by all mobile platforms well, deploying CalDAV to a corporate environment has all sorts of issues. You want to run your CalDAV server on a computer running a web server? Port conflict. Or you need to wedge it into your web server somehow. It's still another set of creds and config to access what users consider to just be a feature in mail. Imagine if you needed to use 5 different keys to drive your car. One for the door, a different one for the steering lock, another to start the engine, another to unlock the transmission etc etc. Then you lose 1 key. It's actually insane. > > > Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité d'Atos ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From brong@fastmail.fm Thu Feb 16 02:04:16 2012 Return-Path: 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 7B72821F86F5 for ; Thu, 16 Feb 2012 02:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 BuG9yJXemGXD for ; Thu, 16 Feb 2012 02:04:11 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2721F861E for ; Thu, 16 Feb 2012 02:04:10 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A266220B58 for ; Thu, 16 Feb 2012 05:04:10 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute2.internal (MEProxy); Thu, 16 Feb 2012 05:04:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= hDsPexRAzKUnGZwXDbmIRXgi11s=; b=Tr2CbAA4gfwQkGG5lxSdSOYcMozSjyOa I94qGUqxrc57epfIZqoZ0DDxnkJlvbEq5WO4wXf280yyiqI7jyOjIHlYGuL8bAsR kYB+Ao5Rv/NKCl0atKvHK6Q9OcyMxFQjEH+qC+0m8Ly9BkTCotrKZ+uOszohMEMc mCE37AR9ORY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=hDsPexRAzKUnGZwXDbmIRXgi11s=; b=Iyh JF7a2NOTs9K0EycHZ1Q6dwiy77DqHRVOmsFFvobWUMNuAh15nwhmCzLMvExg9GT3 IUIbySJTjEVph1MKC63EDJxFxB76N+cupO+0mF+pysEkI1xTHNyOaFXIiq4fNUpH 1I/OPrt8JwuPiy/3Gjdh4B/xFol+eZS5mYkIOTjo= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 72614A00098; Thu, 16 Feb 2012 05:04:10 -0500 (EST) Message-Id: <1329386650.31621.140661037282969@webmail.messagingengine.com> X-Sasl-Enc: pbYsPIL6L17M56kXky6knfzNKoD3VnpQuMs2xzGC8IfM 1329386650 From: Bron Gondwana To: Dave Cridland , Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <3077.1329386263.642278@puncture> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com><3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no><3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> Date: Thu, 16 Feb 2012 11:04:10 +0100 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:04:16 -0000 On Thu, Feb 16, 2012, at 09:57 AM, Dave Cridland wrote: > On Thu Feb 16 09:20:44 2012, Adrien de Croy wrote: > > SMTP: specification of server, choice of authentication method, > > choice of security (SSL vs STARTTLS vs none), username and password. > > IMAP: specification of server, choice of authentication method, > > choice of security (SSL vs STARTTLS vs none), username and password. > > LDAP: specification of server(s), choice of authentication method, > > choice of security (SSL vs STARTTLS vs none), username and password. > > Well, of course, I'd argue that you could use a combination of SRV, > common options, discovery, and ACAP to fix all that. > > The problem with Thunderbird isn't that it has all these options, > it's that it requires the user to enter them, and fails to do > discovery properly - Tony Finch wrote a particularly good blog post > on why it's so awful several years ago, and provided solutions, too. > > Interestingly, XMPP has generally gone the discovery route, and the > result is that you only enter a jid and a password. > > For Polymer, you enter a username, ACAP server, and password - ACAP > doesn't have the SRV option, and maybe I should just add that in - > not that anyone but me cares anymore. > > Having written multiprotocol clients, I just don't think they're as > hard as people make them out to be. Having seen support tickets for many years, those of us in a "service provider" role know how bad the multiple-credential, multiple service with different uptime issues and intermediate unreliability issues is. The autoconfiguration space is getting better, many services "just work" with Thunderbird now, for example. As for the ACAP server - the world is moving, for the better I think, to "you enter your email address and password, and it just works". That's the minimum short of a single-signon solution. One thing that uniquely identifies you and one thing that's secret. Entering the ACAP server address as a third datapoint is 50% more overhead, and that's the 50% that you need to look up somewhere, because you already know your email address and password. Which is a vote from me for "yes, SRV option makes sense". Bron. -- Bron Gondwana brong@fastmail.fm From dave@cridland.net Thu Feb 16 02:04:40 2012 Return-Path: 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 1BBAC21F86EA for ; Thu, 16 Feb 2012 02:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 AQfV2lWnoCma for ; Thu, 16 Feb 2012 02:04:35 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id C9A7121F861E for ; Thu, 16 Feb 2012 02:04:34 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id AECCF1168087; Thu, 16 Feb 2012 10:04:33 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRe7PYsPcADl; Thu, 16 Feb 2012 10:04:26 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 46AC31168067; Thu, 16 Feb 2012 10:04:26 +0000 (GMT) References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> =?US-ASCII?Q?<66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl?= =?US-ASCII?Q?atosorigin.net>?= <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> =?US-ASCII?Q?<66F68487BF0EED4BA?= =?US-ASCII?Q?D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.at?= =?US-ASCII?Q?sorigin.net>?= <4F3CD398.3020901@qbik.com> In-Reply-To: <4F3CD398.3020901@qbik.com> MIME-Version: 1.0 Message-Id: <3077.1329386666.285006@puncture> Date: Thu, 16 Feb 2012 10:04:26 +0000 From: Dave Cridland To: Adrien de Croy , "Discussion on drastically slimming-down IMAP\." , =?iso-8859-1?Q?Michel_S=E9bastien?= Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:04:40 -0000 On Thu Feb 16 09:59:52 2012, Adrien de Croy wrote: > Imagine if you needed to use 5 different keys to drive your car. > One for the door, a different one for the steering lock, another to > start the engine, another to unlock the transmission etc etc. My car has several keyholes, but due to advanced technology, it requires only one key! I've dubbed this "Single Key In", and it's a fantastic new technology! I wonder if we could devise some similar capability for authentication on the catenet? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From adrien@qbik.com Thu Feb 16 02:15:10 2012 Return-Path: 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 B38AC21F861E for ; Thu, 16 Feb 2012 02:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=-1.896, 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 CfYP0Jdm7V4Y for ; Thu, 16 Feb 2012 02:15:06 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id BC08E21F86FE for ; Thu, 16 Feb 2012 02:15:05 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018866210@smtp.qbik.com>; Thu, 16 Feb 2012 23:15:03 +1300 Message-ID: <4F3CD728.3010203@qbik.com> Date: Thu, 16 Feb 2012 23:15:04 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> In-Reply-To: <3077.1329386263.642278@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:15:10 -0000 sure, anything that can be auto discovered is great. But SRV has issues, not every corporate runs their own DNS (at least not for external). ACAP is great too, but it's another port and set of creds. And the tie-in between ACAP and other services is probably manual on the back-end right? Xtra is NZ's biggest ISP. It blocks port 25. So when I take my laptop home I need to reconfigure it. At least I know how to do that. We're techies here, we forget how lost and confused the punters get. Adrien On 16/02/2012 10:57 p.m., Dave Cridland wrote: > On Thu Feb 16 09:20:44 2012, Adrien de Croy wrote: >> SMTP: specification of server, choice of authentication method, >> choice of security (SSL vs STARTTLS vs none), username and password. >> IMAP: specification of server, choice of authentication method, >> choice of security (SSL vs STARTTLS vs none), username and password. >> LDAP: specification of server(s), choice of authentication method, >> choice of security (SSL vs STARTTLS vs none), username and password. > > Well, of course, I'd argue that you could use a combination of SRV, > common options, discovery, and ACAP to fix all that. > > The problem with Thunderbird isn't that it has all these options, it's > that it requires the user to enter them, and fails to do discovery > properly - Tony Finch wrote a particularly good blog post on why it's > so awful several years ago, and provided solutions, too. > > Interestingly, XMPP has generally gone the discovery route, and the > result is that you only enter a jid and a password. > > For Polymer, you enter a username, ACAP server, and password - ACAP > doesn't have the SRV option, and maybe I should just add that in - not > that anyone but me cares anymore. > > Having written multiprotocol clients, I just don't think they're as > hard as people make them out to be. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From sebastien.michel@atos.net Thu Feb 16 02:16:19 2012 Return-Path: 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 04C9021F870E for ; Thu, 16 Feb 2012 02:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 p0eS63Aq-Q+9 for ; Thu, 16 Feb 2012 02:16:14 -0800 (PST) Received: from smtp1.mail.atosorigin.com (smtp1.mail.atosorigin.com [160.92.103.80]) by ietfa.amsl.com (Postfix) with ESMTP id EF54421F8700 for ; Thu, 16 Feb 2012 02:16:10 -0800 (PST) Received: from filter.atosorigin.com (localhost [127.0.0.1]) by mxfed001 (Postfix) with ESMTP id 8BED926396E8; Thu, 16 Feb 2012 11:16:09 +0100 (CET) Received: from mail.awl.fr.atosorigin.com (serv-smtp-wse02.fr.atosworldline.com [160.92.103.181]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "mail.awl.fr.atosorigin.com", Issuer "VeriSign Class 3 Secure Server CA - G2" (verified OK)) by mxfed001 (Postfix) with ESMTP id 7298E26396E0; Thu, 16 Feb 2012 11:16:09 +0100 (CET) Received: from frspx301.fr01.awl.atosorigin.net (10.24.253.189) by frspx402.priv.atos.fr (10.24.220.8) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 11:16:09 +0100 Received: from FRSPX100.fr01.awl.atosorigin.net ([10.24.253.184]) by frspx301.fr01.awl.atosorigin.net ([10.24.253.189]) with mapi; Thu, 16 Feb 2012 11:16:09 +0100 From: =?iso-8859-1?Q?Michel_S=E9bastien?= To: Bron Gondwana , Dave Cridland , Adrien de Croy , Arnt Gulbrandsen , Discussion on drastically slimming-down IMAP. Date: Thu, 16 Feb 2012 11:16:07 +0100 Thread-Topic: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP Thread-Index: AczsklsXlLND396iTJu6iJhfM7uuPwAASd5Q Message-ID: <66F68487BF0EED4BA7D767E2410F30B3EFF25945FC@FRSPX100.fr01.awl.atosorigin.net> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com><3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no><3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <1329386650.31621.140661037282969@webmail.messagingengine.com> In-Reply-To: <1329386650.31621.140661037282969@webmail.messagingengine.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:16:19 -0000 > Which is a vote from me for "yes, SRV option makes sense". Your dream has come true :) http://tools.ietf.org/html/rfc6186 -- S=E9bastien Ce message et les pi=E8ces jointes sont confidentiels et r=E9serv=E9s =E0 l= 'usage exclusif de ses destinataires. Il peut =E9galement =EAtre prot=E9g= =E9 par le secret professionnel. Si vous recevez ce message par erreur, mer= ci d'en avertir imm=E9diatement l'exp=E9diteur et de le d=E9truire. L'int= =E9grit=E9 du message ne pouvant =EAtre assur=E9e sur Internet, la responsa= bilit=E9 d'Atos ne pourra =EAtre recherch=E9e quant au contenu de ce messag= e. Bien que les meilleurs efforts soient faits pour maintenir cette transmi= ssion exempte de tout virus, l'exp=E9diteur ne donne aucune garantie =E0 ce= t =E9gard et sa responsabilit=E9 ne saurait =EAtre recherch=E9e pour tout d= ommage r=E9sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integr= ity cannot be secured on the Internet, the Atos liability cannot be trigger= ed for the message content. Although the sender endeavours to maintain a co= mputer virus-free network, the sender does not warrant that this transmissi= on is virus-free and will not be liable for any damages resulting from any = virus transmitted. From dave@cridland.net Thu Feb 16 02:25:37 2012 Return-Path: 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 9D95821F872A for ; Thu, 16 Feb 2012 02:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 1srYcWiCAVjS for ; Thu, 16 Feb 2012 02:25:32 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 1C53521F86E3 for ; Thu, 16 Feb 2012 02:25:32 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 3F12D1168087; Thu, 16 Feb 2012 10:25:31 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4yIWfc57ejx; Thu, 16 Feb 2012 10:25:23 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id A93D31168067; Thu, 16 Feb 2012 10:25:22 +0000 (GMT) References: <4F397212.1030107@qbik.com> =?US-ASCII?Q?<20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net>_<4F3C2C1B.6030408@qbik.com><3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no><30?= =?US-ASCII?Q?7.1329382177.374908@puncture>?= <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <1329386650.31621.140661037282969@webmail.messagingengine.com> In-Reply-To: <1329386650.31621.140661037282969@webmail.messagingengine.com> MIME-Version: 1.0 Message-Id: <3077.1329387922.639535@puncture> Date: Thu, 16 Feb 2012 10:25:22 +0000 From: Dave Cridland To: Bron Gondwana , Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:25:37 -0000 On Thu Feb 16 10:04:10 2012, Bron Gondwana wrote: > As for the ACAP server - the world is moving, for the better I > think, to > "you enter your email address and password, and it just works". > That's > the minimum short of a single-signon solution. One thing that > uniquely > identifies you and one thing that's secret. Entering the ACAP > server > address as a third datapoint is 50% more overhead, and that's the > 50% > that you need to look up somewhere, because you already know your > email address and password. > > Which is a vote from me for "yes, SRV option makes sense". Oh, totally agree. Discovery is awesome, user-configuration is insane. I don't see there's any valid argument the other way. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave@cridland.net Thu Feb 16 02:41:57 2012 Return-Path: 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 627A321F876D for ; Thu, 16 Feb 2012 02:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 xpzlfHNAF2l0 for ; Thu, 16 Feb 2012 02:41:52 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id ACB3721F8770 for ; Thu, 16 Feb 2012 02:41:51 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id AA6EA1168087; Thu, 16 Feb 2012 10:41:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzmdzyMBeKLI; Thu, 16 Feb 2012 10:41:39 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 643411168067; Thu, 16 Feb 2012 10:41:39 +0000 (GMT) References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <4F3CD728.3010203@qbik.com> In-Reply-To: <4F3CD728.3010203@qbik.com> MIME-Version: 1.0 Message-Id: <3077.1329388899.383165@puncture> Date: Thu, 16 Feb 2012 10:41:39 +0000 From: Dave Cridland To: Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:41:57 -0000 On Thu Feb 16 10:15:04 2012, Adrien de Croy wrote: > But SRV has issues, not every corporate runs their own DNS (at > least not for external). > > Well, tough. There is a point at which we have to assume people will have to fix things. XMPP services get this fixed pretty quick, and mail is a much bigger juggernaut. > ACAP is great too, but it's another port and set of creds. And the > tie-in between ACAP and other services is probably manual on the > back-end right? > > What tie-in? ACAP's just a simple store. The enhancement to the client is that a sysadmin can preconfigure the clients, and ACAP gives a bunch of wacky data inheritance tricks to make this easy. I wouldn't worry too much about ACAP anyway - even I think it's dead-end. The key portions could be slammed into almost any other convenient protocol, and it's one case where I think bolting it onto an existing protocol makes sense. This wasn't the case when it was the only viable solution for handling address books, mind, and you'd lose the multi-account capability, but I think people are basically OK with such things now. > Xtra is NZ's biggest ISP. It blocks port 25. So when I take my > laptop home I need to reconfigure it. At least I know how to do > that. > > Why would blocking port 25 be a problem? Unless you're running an MTA on your laptop, in which case you're presumably savvy-enough to deal with the consequences. > We're techies here, we forget how lost and confused the punters get. No matter how good the protocols involved are, it comes down to how good the deployment and implementations are. The client is the punter-facing component, and without good clients you're shot whatever you do. To get "good" clients, you need mind-share, and you'll only get that if you start off with the status quo and figure out where to go - or if you base on another preexisting framework. Lots of folk are doing this very successfully with the web, of course, but I think there are other options, too. All this talk of a boil-the-ocean brave-new-world is great fun, I'll be the first to admit, but I really don't see how it gets us anywhere useful. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From brong@fastmail.fm Thu Feb 16 02:58:34 2012 Return-Path: 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 B1C3421F8571 for ; Thu, 16 Feb 2012 02:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 c-Ab+Jyn2LaQ for ; Thu, 16 Feb 2012 02:58:29 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4B99321F8598 for ; Thu, 16 Feb 2012 02:58:29 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id F06732074A for ; Thu, 16 Feb 2012 05:58:28 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute4.internal (MEProxy); Thu, 16 Feb 2012 05:58:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= xVQI/fvvJWN8dF5Bd5CV2xC/7cw=; b=UH3DKqjBiYHQEmHITK1TKxlXpAxfrczO C6WZ/MvluBs08EgxHkhGXgUDe16e8WEEMhVo+JCGuilEu8WV1ibHKTNZ3JXkxqVD ptlwOKv8iGw/7YTcxgifbeeP5oZdjXnTKxfmEKnRRDMgBe+8Mv0jqL2Ilt6fgJAu 2dI+5EvMEmg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=xVQI/fvvJWN8dF5Bd5CV2xC/7cw=; b=iTs VrhcSPwLJMJHm+4QaHzYQJbfxbFSsKQqw1lNhGBjERQ+OBgvF72r6lZ0mjCorliF dDIWuQe2iirnEytVjMWhmpoEjWFOp6CVhmB5hWjOl4fSZrfNtHeKAR6CzdV86Dlh b6/PDVY0jUEJX4rsByxd7HDoeNL9va1i+xMVjl1s= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id AC617A000E6; Thu, 16 Feb 2012 05:58:28 -0500 (EST) Message-Id: <1329389908.13522.140661037296941@webmail.messagingengine.com> X-Sasl-Enc: uk1HEyk0r23RSv3yVcXmiItgKRhuijS+1KLEOSJ9TQDf 1329389908 From: Bron Gondwana To: Dave Cridland , Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <3077.1329388899.383165@puncture> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com><3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no><3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com><3077.1329386263.642278@puncture> <4F3CD728.3010203@qbik.com> <3077.1329388899.383165@puncture> Date: Thu, 16 Feb 2012 11:58:28 +0100 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:58:34 -0000 On Thu, Feb 16, 2012, at 10:41 AM, Dave Cridland wrote: > To get "good" clients, you need mind-share, and you'll only get that > if you start off with the status quo and figure out where to go - or > if you base on another preexisting framework. Lots of folk are doing > this very successfully with the web, of course, but I think there are > other options, too. Or if you provide a better-enough experience that the switching cost is worth it to enough client authors. > All this talk of a boil-the-ocean brave-new-world is great fun, I'll > be the first to admit, but I really don't see how it gets us anywhere > useful. I see three choices: a) We want to spend the rest accessing our email with IMAP + layers of hotfixes, with an ever more complex set of potentially partially implemented capabilities. b) We want to switch to Exchange protocol (as per Mark's comment earlier) c) Neither of the above. If (c), what then. It's already going to be really hard. If we wait longer to start, it will keep getting harder. Bron. -- Bron Gondwana brong@fastmail.fm From adrien@qbik.com Thu Feb 16 02:58:57 2012 Return-Path: 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 C3E8A21F8748 for ; Thu, 16 Feb 2012 02:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.138 X-Spam-Level: X-Spam-Status: No, score=-4.138 tagged_above=-999 required=5 tests=[AWL=-2.139, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] 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 djyTbfylpP2k for ; Thu, 16 Feb 2012 02:58:52 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3B20A21F8571 for ; Thu, 16 Feb 2012 02:58:51 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018866270@smtp.qbik.com>; Thu, 16 Feb 2012 23:58:50 +1300 Message-ID: <4F3CE16B.3060603@qbik.com> Date: Thu, 16 Feb 2012 23:58:51 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <4F3CD728.3010203@qbik.com> <3077.1329388899.383165@puncture> In-Reply-To: <3077.1329388899.383165@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:58:57 -0000 On 16/02/2012 11:41 p.m., Dave Cridland wrote: > On Thu Feb 16 10:15:04 2012, Adrien de Croy wrote: >> But SRV has issues, not every corporate runs their own DNS (at least >> not for external). >> >> > Well, tough. There is a point at which we have to assume people will > have to fix things. XMPP services get this fixed pretty quick, and > mail is a much bigger juggernaut. > how many corporates deploy XMPP services? SRV is great, but it's only marginally better than ACAP in terms of conifguration points. You still need a domain. What happens when you're using hosted mail? Does your mail host have to give you a sub-domain so you can have your own SRV record to point to your own ACAP server to get your mail config? How many points of failure there? That's why I keep going back to the 1 port like a broken record. Maybe it should just be an SSH tunnel... but that;s back-pedalling quickly and reducing potential user experience with it. > >> ACAP is great too, but it's another port and set of creds. And the >> tie-in between ACAP and other services is probably manual on the >> back-end right? >> >> > What tie-in? ACAP's just a simple store. The enhancement to the client > is that a sysadmin can preconfigure the clients, and ACAP gives a > bunch of wacky data inheritance tricks to make this easy. as I said - manual. You have to type in the settings, the IMAP server can't publish them automatically to the ACAP server. > > I wouldn't worry too much about ACAP anyway - even I think it's > dead-end. The key portions could be slammed into almost any other > convenient protocol, and it's one case where I think bolting it onto > an existing protocol makes sense. definitely. > > This wasn't the case when it was the only viable solution for handling > address books, mind, and you'd lose the multi-account capability, but > I think people are basically OK with such things now. > > >> Xtra is NZ's biggest ISP. It blocks port 25. So when I take my >> laptop home I need to reconfigure it. At least I know how to do that. >> >> > Why would blocking port 25 be a problem? Unless you're running an MTA > on your laptop, in which case you're presumably savvy-enough to deal > with the consequences. there are a myriad of reasons. My MTA is Thunderbird. At work, I have my mail set to send to smtp.qbik.com with creds. When I take my laptop home, I can't connect any more. I have to send my mail through the ISP mail server. Some companies don't like this. Some users have trouble configuring this. We do actually get support tickets created by this particular issue. You go to a hotel, same issue. Some companies use SPF as well, so mail starts to bounce when you can't use your corporate MTA to send. > >> We're techies here, we forget how lost and confused the punters get. > > No matter how good the protocols involved are, it comes down to how > good the deployment and implementations are. The client is the > punter-facing component, and without good clients you're shot whatever > you do. > absolutely. But good clients can be impossible to achieve if the protocols don't allow it. > To get "good" clients, you need mind-share, and you'll only get that > if you start off with the status quo and figure out where to go - or > if you base on another preexisting framework. Lots of folk are doing > this very successfully with the web, of course, but I think there are > other options, too. Microsoft abandoned it all and wrote Exchange. So did GMail. They can afford to do that. We aren't MS or Google. Why do you think they did that? Exchange server was delayed for years. It cost them. But now it's almost the only game in town. > > All this talk of a boil-the-ocean brave-new-world is great fun, I'll > be the first to admit, but I really don't see how it gets us anywhere > useful. I prefer my ocean at ATP. We could just talk about what could be stripped out of IMAP. But I don't really see how that would get us anywhere useful either. Adrien > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From dave@cridland.net Thu Feb 16 03:22:40 2012 Return-Path: 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 700E421F8596 for ; Thu, 16 Feb 2012 03:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] 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 4lq+PJehQxW8 for ; Thu, 16 Feb 2012 03:22:35 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2A421F87F1 for ; Thu, 16 Feb 2012 03:22:34 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 41F251168087; Thu, 16 Feb 2012 11:22:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sg0QAr1QSll; Thu, 16 Feb 2012 11:22:24 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 2F43E1168067; Thu, 16 Feb 2012 11:22:24 +0000 (GMT) References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <4F3CD728.3010203@qbik.com> <3077.1329388899.383165@puncture> <4F3CE16B.3060603@qbik.com> In-Reply-To: <4F3CE16B.3060603@qbik.com> MIME-Version: 1.0 Message-Id: <3077.1329391344.173214@puncture> Date: Thu, 16 Feb 2012 11:22:24 +0000 From: Dave Cridland To: Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:22:40 -0000 On Thu Feb 16 10:58:51 2012, Adrien de Croy wrote: > > > On 16/02/2012 11:41 p.m., Dave Cridland wrote: >> On Thu Feb 16 10:15:04 2012, Adrien de Croy wrote: >>> But SRV has issues, not every corporate runs their own DNS (at >>> least not for external). >>> >>> >> Well, tough. There is a point at which we have to assume people >> will have to fix things. XMPP services get this fixed pretty >> quick, and mail is a much bigger juggernaut. >> >> > how many corporates deploy XMPP services? > > Approaching 10% and growing, at least by some metrics: http://eggert.org/meter/xmpp.html > SRV is great, but it's only marginally better than ACAP in terms of > conifguration points. You still need a domain. What happens when > you're using hosted mail? Does your mail host have to give you a > sub-domain so you can have your own SRV record to point to your own > ACAP server to get your mail config? > > You've gone off on one. If you have a mail domain, then you can put in SRV records to point to the servers. If you use another mail domain, then they do that for you. > How many points of failure there? > > Lots - but no fewer than without. Unless you think that SRV might break when the rest of the DNS doesn't. I don't think that's been an issue for the past decade or so. > That's why I keep going back to the 1 port like a broken record. > Maybe it should just be an SSH tunnel... but that;s back-pedalling > quickly and reducing potential user experience with it. > > No, I think it's an orthogonal issue. >>> ACAP is great too, but it's another port and set of creds. And >>> the tie-in between ACAP and other services is probably manual on >>> the back-end right? >>> >>> >> What tie-in? ACAP's just a simple store. The enhancement to the >> client is that a sysadmin can preconfigure the clients, and ACAP >> gives a bunch of wacky data inheritance tricks to make this easy. > > as I said - manual. You have to type in the settings, the IMAP > server can't publish them automatically to the ACAP server. > > Oh, right. Well, yes, it *can* - both WorldMail and CommuniGate work(ed) in this manner. But given the sysadmin has to make precisely one STORE command on a real ACAP server, it's a bit of a non-issue - it no more manual than setting up any other server. >>> Xtra is NZ's biggest ISP. It blocks port 25. So when I take my >>> laptop home I need to reconfigure it. At least I know how to do >>> that. >>> >>> >> Why would blocking port 25 be a problem? Unless you're running an >> MTA on your laptop, in which case you're presumably savvy-enough >> to deal with the consequences. > > there are a myriad of reasons. My MTA is Thunderbird. At work, I > have my mail set to send to smtp.qbik.com with creds. When I take > my laptop home, I can't connect any more. I have to send my mail > through the ISP mail server. Some companies don't like this. Some > users have trouble configuring this. We do actually get support > tickets created by this particular issue. > > You go to a hotel, same issue. > > Some companies use SPF as well, so mail starts to bounce when you > can't use your corporate MTA to send. > > Right, sure, understood (after s/MTA/MUA/) but what has port 25 got to do with it? >>> We're techies here, we forget how lost and confused the punters >>> get. >> >> No matter how good the protocols involved are, it comes down to >> how good the deployment and implementations are. The client is the >> punter-facing component, and without good clients you're shot >> whatever you do. >> > absolutely. But good clients can be impossible to achieve if the > protocols don't allow it. > >> To get "good" clients, you need mind-share, and you'll only get >> that if you start off with the status quo and figure out where to >> go - or if you base on another preexisting framework. Lots of folk >> are doing this very successfully with the web, of course, but I >> think there are other options, too. > > Microsoft abandoned it all and wrote Exchange. So did GMail. > > GMail did it with the web - preexisting framework. Then they leveraged the deployed base of mobile IMAP clients - preexisting framework. > They can afford to do that. We aren't MS or Google. > > Apparently not... > Why do you think they did that? Exchange server was delayed for > years. It cost them. But now it's almost the only game in town. > > Exchange was largely an X.400 system, until recently. Again, they didn't make any real attempt to reinvent the wheel. What they did do was carefully market it - Outlook was a very nice client, and it came free with Office, and only really worked tolerably with Exchange - where it worked really quite well. So they managed to leverage from Windows to Office, and from Office to Exchange. The fact that it's a monolithic protocol has little to do with it. >> All this talk of a boil-the-ocean brave-new-world is great fun, >> I'll be the first to admit, but I really don't see how it gets us >> anywhere useful. > > I prefer my ocean at ATP. > > We could just talk about what could be stripped out of IMAP. But I > don't really see how that would get us anywhere useful either. Sure. What we need to do is identify the core problems to be solved, instead of finding solutions and trying to figure out how to use them. But it's not nearly as much fun. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From sebastien.michel@atos.net Thu Feb 16 03:23:42 2012 Return-Path: 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 547AB21F87D6 for ; Thu, 16 Feb 2012 03:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 6SbhUoM3cN1I for ; Thu, 16 Feb 2012 03:23:41 -0800 (PST) Received: from smtp1.mail.atosorigin.com (smtp1.mail.atosorigin.com [160.92.103.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC8021F87E9 for ; Thu, 16 Feb 2012 03:23:41 -0800 (PST) Received: from filter.atosorigin.com (localhost [127.0.0.1]) by mxfed001 (Postfix) with ESMTP id 8D9F320000A9; Thu, 16 Feb 2012 12:23:40 +0100 (CET) Received: from mail.awl.fr.atosorigin.com (serv-smtp-wse02.fr.atosworldline.com [160.92.103.181]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "mail.awl.fr.atosorigin.com", Issuer "VeriSign Class 3 Secure Server CA - G2" (verified OK)) by mxfed001 (Postfix) with ESMTP id 8857820000A1; Thu, 16 Feb 2012 12:23:40 +0100 (CET) Received: from frspx301.fr01.awl.atosorigin.net (10.24.253.189) by frspx402.priv.atos.fr (10.24.220.8) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 12:23:40 +0100 Received: from FRSPX100.fr01.awl.atosorigin.net ([10.24.253.184]) by frspx301.fr01.awl.atosorigin.net ([10.24.253.189]) with mapi; Thu, 16 Feb 2012 12:23:40 +0100 From: =?iso-8859-1?Q?Michel_S=E9bastien?= To: Adrien de Croy Date: Thu, 16 Feb 2012 12:23:39 +0100 Thread-Topic: [imap5] Designing a new replacement protocol for IMAP Thread-Index: Aczskb7LQl2PJ2CPSCOWxUx3Ic+cUwACaZIg Message-ID: <66F68487BF0EED4BA7D767E2410F30B3EFF259462E@FRSPX100.fr01.awl.atosorigin.net> References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> <4F3CD398.3020901@qbik.com> In-Reply-To: <4F3CD398.3020901@qbik.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:23:42 -0000 > well, deploying CalDAV to a corporate environment has all sorts of issues= . You want to run your CalDAV server on a computer running a web server? = Port conflict. Or you need to wedge it into your web server somehow. You're right. It's also possible to bind to a different IP, do a port forwa= rding. Nothing complicated for a sysadmin >It's still another set of creds and config to access what users consider t= o just be a feature in mail. > >Imagine if you needed to use 5 different keys to drive your car. One for = the door, a different one for the steering lock, another to start the engin= e, another to unlock the transmission etc etc. > Seems inappropriate, SMTP and IMAP configurations are already barriers for = end-user. Regards, S=E9bastien Ce message et les pi=E8ces jointes sont confidentiels et r=E9serv=E9s =E0 l= 'usage exclusif de ses destinataires. Il peut =E9galement =EAtre prot=E9g= =E9 par le secret professionnel. Si vous recevez ce message par erreur, mer= ci d'en avertir imm=E9diatement l'exp=E9diteur et de le d=E9truire. L'int= =E9grit=E9 du message ne pouvant =EAtre assur=E9e sur Internet, la responsa= bilit=E9 d'Atos ne pourra =EAtre recherch=E9e quant au contenu de ce messag= e. Bien que les meilleurs efforts soient faits pour maintenir cette transmi= ssion exempte de tout virus, l'exp=E9diteur ne donne aucune garantie =E0 ce= t =E9gard et sa responsabilit=E9 ne saurait =EAtre recherch=E9e pour tout d= ommage r=E9sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integr= ity cannot be secured on the Internet, the Atos liability cannot be trigger= ed for the message content. Although the sender endeavours to maintain a co= mputer virus-free network, the sender does not warrant that this transmissi= on is virus-free and will not be liable for any damages resulting from any = virus transmitted. From fanf2@hermes.cam.ac.uk Thu Feb 16 03:30:22 2012 Return-Path: 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 7CAE021F874A for ; Thu, 16 Feb 2012 03:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UHqKsFPWm9oE for ; Thu, 16 Feb 2012 03:30:18 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 301DA21F8764 for ; Thu, 16 Feb 2012 03:30:17 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35051) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1RxzXT-0003Bq-sS (Exim 4.72) (return-path ); Thu, 16 Feb 2012 11:30:15 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RxzXT-0007Bn-HU (Exim 4.67) (return-path ); Thu, 16 Feb 2012 11:30:15 +0000 Date: Thu, 16 Feb 2012 11:30:15 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Bron Gondwana In-Reply-To: <20120215211301.GA16253@launde.brong.net> Message-ID: References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:30:22 -0000 Bron Gondwana wrote: > > This is not a problem that's unique to email. There's nothing really > special about email here unless you make it special. Sure there's a > bunch of indexed and optimised ways of viewing that data - sort by > trimmed subject, encodings, etc. All of which could be expressed as > generic queries against the data model with a query optimiser on the far > end rather than needing a custom syntax for everything... This sounds to me a bit more radical than I was expecting. In particular I thought you wanted to keep the data model so that existing servers could support the new protocol reasonably easily. Which implies that mailboxes remain separate silos rather than the store being a soup of messages GMail style. > BEEP has also been mentioned. I think BEEP is insane. Masses of complexity just to avoid using multiple concurrent TCP connections. Tony. -- f.anthony.n.finch http://dotat.at/ Sole: North backing west 4 or 5. Moderate. Fair. Good. From dave64@andrew.cmu.edu Thu Feb 16 03:37:27 2012 Return-Path: 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 0520C21F875C for ; Thu, 16 Feb 2012 03:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 oaCYzJYTu6k8 for ; Thu, 16 Feb 2012 03:37:26 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.96]) by ietfa.amsl.com (Postfix) with ESMTP id 5989221F875B for ; Thu, 16 Feb 2012 03:37:26 -0800 (PST) Received: from administrators-macbook-pro-2.local (c-98-219-195-113.hsd1.pa.comcast.net [98.219.195.113]) (user=dave64 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id q1GBbOfJ008161 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Feb 2012 06:37:25 -0500 Message-ID: <4F3CEA74.80807@andrew.cmu.edu> Date: Thu, 16 Feb 2012 06:37:24 -0500 From: Dave McMurtrie User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: imap5@ietf.org References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> <14945_1329386404_q1GA022W010356_4F3CD398.3020901@qbik.com> In-Reply-To: <14945_1329386404_q1GA022W010356_4F3CD398.3020901@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.4.9.4220 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, BODY_SIZE_1400_1499 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, RDNS_BROADBAND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, TO_NO_NAME 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_BROADBAND_5 0, __RDNS_POOLED_11 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.96 Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:37:27 -0000 On 2/16/12 4:59 AM, Adrien de Croy wrote: > > > On 16/02/2012 10:07 p.m., Michel Sébastien wrote: >>> On 16/02/2012 1:26 p.m., Brandon Long wrote: >>>> This is the second time I've heard about concern that proxies would >>>> break access to my mail data over http. >>> layering other protocols over HTTP is currently an arms-race between >>> client-software developers who want to do this, and proxy developers >>> who want to provide the tools their customers (sys admins) ask for to >>> allow them to prevent it. >>> >>> the harder it gets to block something intelligently, the more likely >>> admins will resort to over-blocking. We see it every day. >>> >>> Developing a new protocol for mail designed ONLY to layer over HTTP >>> is therefore extremely foolhardy. Sure by all means have options. >> I'm not really convinced, does it means that CalDAV and CardDAV are on >> the wrong way ? I think not, even if they are not supported by all >> mobile platforms > > well, deploying CalDAV to a corporate environment has all sorts of > issues. You want to run your CalDAV server on a computer running a web > server? Port conflict. Or you need to wedge it into your web server > somehow. The Cyrus Project aims to include CalDAV support as part of the Cyrus IMAP server, which would make CalDAV deployment much simpler for any sites that are already running Cyrus. Dave From adrien@qbik.com Thu Feb 16 03:40:46 2012 Return-Path: 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 360B321F8786 for ; Thu, 16 Feb 2012 03:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.075 X-Spam-Level: X-Spam-Status: No, score=-4.075 tagged_above=-999 required=5 tests=[AWL=-2.076, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] 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 84SJeaADogHe for ; Thu, 16 Feb 2012 03:40:41 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id AB90D21F8790 for ; Thu, 16 Feb 2012 03:40:40 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018866320@smtp.qbik.com>; Fri, 17 Feb 2012 00:40:39 +1300 Message-ID: <4F3CEB35.9080200@qbik.com> Date: Fri, 17 Feb 2012 00:40:37 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <4F3CD728.3010203@qbik.com> <3077.1329388899.383165@puncture> <4F3CE16B.3060603@qbik.com> <3077.1329391344.173214@puncture> In-Reply-To: <3077.1329391344.173214@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:40:46 -0000 On 17/02/2012 12:22 a.m., Dave Cridland wrote: > On Thu Feb 16 10:58:51 2012, Adrien de Croy wrote: >> >> >> On 16/02/2012 11:41 p.m., Dave Cridland wrote: >>> On Thu Feb 16 10:15:04 2012, Adrien de Croy wrote: >>>> But SRV has issues, not every corporate runs their own DNS (at >>>> least not for external). >>>> >>>> >>> Well, tough. There is a point at which we have to assume people will >>> have to fix things. XMPP services get this fixed pretty quick, and >>> mail is a much bigger juggernaut. >>> >>> >> how many corporates deploy XMPP services? >> >> > Approaching 10% and growing, at least by some metrics: > > http://eggert.org/meter/xmpp.html OK.. I'm struggling to understand why... > >> SRV is great, but it's only marginally better than ACAP in terms of >> conifguration points. You still need a domain. What happens when >> you're using hosted mail? Does your mail host have to give you a >> sub-domain so you can have your own SRV record to point to your own >> ACAP server to get your mail config? >> >> > You've gone off on one. hmmm, you're right I have!!!! what was I thinking... > > If you have a mail domain, then you can put in SRV records to point to > the servers. If you use another mail domain, then they do that for you. > > >> How many points of failure there? >> >> > Lots - but no fewer than without. Unless you think that SRV might > break when the rest of the DNS doesn't. I don't think that's been an > issue for the past decade or so. no I wouldn't expect its reliability to differ from any other records. > >> That's why I keep going back to the 1 port like a broken record. >> Maybe it should just be an SSH tunnel... but that;s back-pedalling >> quickly and reducing potential user experience with it. >> >> > No, I think it's an orthogonal issue. maybe, but nonetheless real, especially for ISP tech support staff. Just trying to think of "cheap" ways to get single sign on and single port using the existing protocols. But it would still be a bandaid. Auto config is a band-aid as well to the solution of multiple sets of creds. > >>>> ACAP is great too, but it's another port and set of creds. And the >>>> tie-in between ACAP and other services is probably manual on the >>>> back-end right? >>>> >>>> >>> What tie-in? ACAP's just a simple store. The enhancement to the >>> client is that a sysadmin can preconfigure the clients, and ACAP >>> gives a bunch of wacky data inheritance tricks to make this easy. >> >> as I said - manual. You have to type in the settings, the IMAP >> server can't publish them automatically to the ACAP server. >> >> > Oh, right. > > Well, yes, it *can* - both WorldMail and CommuniGate work(ed) in this > manner. > > But given the sysadmin has to make precisely one STORE command on a > real ACAP server, it's a bit of a non-issue - it no more manual than > setting up any other server. ok > >>>> Xtra is NZ's biggest ISP. It blocks port 25. So when I take my >>>> laptop home I need to reconfigure it. At least I know how to do that. >>>> >>>> >>> Why would blocking port 25 be a problem? Unless you're running an >>> MTA on your laptop, in which case you're presumably savvy-enough to >>> deal with the consequences. >> >> there are a myriad of reasons. My MTA is Thunderbird. At work, I >> have my mail set to send to smtp.qbik.com with creds. When I take my >> laptop home, I can't connect any more. I have to send my mail >> through the ISP mail server. Some companies don't like this. Some >> users have trouble configuring this. We do actually get support >> tickets created by this particular issue. >> >> You go to a hotel, same issue. >> >> Some companies use SPF as well, so mail starts to bounce when you >> can't use your corporate MTA to send. >> >> > Right, sure, understood (after s/MTA/MUA/) but what has port 25 got to > do with it? back to my point about getting everything over 1 port. If we had that, then blocking 25 wouldn't have affected me. > >>>> We're techies here, we forget how lost and confused the punters get. >>> >>> No matter how good the protocols involved are, it comes down to how >>> good the deployment and implementations are. The client is the >>> punter-facing component, and without good clients you're shot >>> whatever you do. >>> >> absolutely. But good clients can be impossible to achieve if the >> protocols don't allow it. >> >>> To get "good" clients, you need mind-share, and you'll only get that >>> if you start off with the status quo and figure out where to go - or >>> if you base on another preexisting framework. Lots of folk are doing >>> this very successfully with the web, of course, but I think there >>> are other options, too. >> >> Microsoft abandoned it all and wrote Exchange. So did GMail. >> >> > GMail did it with the web - preexisting framework. Then they leveraged > the deployed base of mobile IMAP clients - preexisting framework. > > >> They can afford to do that. We aren't MS or Google. >> >> > Apparently not... > > >> Why do you think they did that? Exchange server was delayed for >> years. It cost them. But now it's almost the only game in town. >> >> > Exchange was largely an X.400 system, until recently. Again, they > didn't make any real attempt to reinvent the wheel. > > What they did do was carefully market it - Outlook was a very nice > client, and it came free with Office, and only really worked tolerably > with Exchange - where it worked really quite well. So they managed to > leverage from Windows to Office, and from Office to Exchange. Actually last time I compared prices of versions of Office, the Outlook component accounted for like $500 NZ. It's also possibly the worst IMAP implementation out there. But they don't _want_ you to use IMAP. They want you to buy Exchange. > > The fact that it's a monolithic protocol has little to do with it. > > > >>> All this talk of a boil-the-ocean brave-new-world is great fun, I'll >>> be the first to admit, but I really don't see how it gets us >>> anywhere useful. >> >> I prefer my ocean at ATP. >> >> We could just talk about what could be stripped out of IMAP. But I >> don't really see how that would get us anywhere useful either. > > Sure. > > What we need to do is identify the core problems to be solved, instead > of finding solutions and trying to figure out how to use them. * SPAM * UDNs * configuration issues solve any one of these and you'll make a lot of people happy. Adrien > > But it's not nearly as much fun. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From adrien@qbik.com Thu Feb 16 03:45:04 2012 Return-Path: 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 AE3F921F84FB for ; Thu, 16 Feb 2012 03:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.316 X-Spam-Level: X-Spam-Status: No, score=-4.316 tagged_above=-999 required=5 tests=[AWL=-1.717, 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 SXfUCk7Sb5So for ; Thu, 16 Feb 2012 03:45:00 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id AA2FA21F84EF for ; Thu, 16 Feb 2012 03:44:59 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018866329@smtp.qbik.com>; Fri, 17 Feb 2012 00:44:58 +1300 Message-ID: <4F3CEC38.3070008@qbik.com> Date: Fri, 17 Feb 2012 00:44:56 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave McMurtrie References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> <14945_1329386404_q1GA022W010356_4F3CD398.3020901@qbik.com> <4F3CEA74.80807@andrew.cmu.edu> In-Reply-To: <4F3CEA74.80807@andrew.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:45:04 -0000 On 17/02/2012 12:37 a.m., Dave McMurtrie wrote: > > The Cyrus Project aims to include CalDAV support as part of the Cyrus > IMAP server, which would make CalDAV deployment much simpler for any > sites that are already running Cyrus. as someone looking to add CalDAV to a mail server, wouldn't it be nice if you didn't have to a) write a web server b) write DAV extensions c) layer XML on top of that d) debug / support all of the above just to get a calendar? Adrien > > Dave > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From arnt@gulbrandsen.priv.no Thu Feb 16 03:53:49 2012 Return-Path: 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 71FEB21F8776 for ; Thu, 16 Feb 2012 03:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 9iap76sOTk6c for ; Thu, 16 Feb 2012 03:53:45 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id EB90121F8770 for ; Thu, 16 Feb 2012 03:53:44 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 62E6EF8C915; Thu, 16 Feb 2012 11:53:42 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1329393221-12558-12558/10/16; Thu, 16 Feb 2012 11:53:41 +0000 Message-Id: <4F3CEE69.3090601@gulbrandsen.priv.no> Date: Thu, 16 Feb 2012 12:54:17 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <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> In-Reply-To: <4F3CEB35.9080200@qbik.com> Content-Type: text/plain; charset=iso-8859-1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:53:49 -0000 >>> how many corporates deploy XMPP services? >> Approaching 10% and growing, at least by some metrics: >> >> http://eggert.org/meter/xmpp.html > OK.. I'm struggling to understand why... You may be too young to remember the ascent of SMTP twenty years ago. MX records were an insuperable hurdle, corporates preferred other mail universes, and so on and so forth. Googletalk's adding an XMPP gateway rather reminds me of how Compuserve added an SMTP gateway. Arnt From dave64@andrew.cmu.edu Thu Feb 16 03:56:02 2012 Return-Path: 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 1000421F87A7 for ; Thu, 16 Feb 2012 03:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 arcYcq6Miqdw for ; Thu, 16 Feb 2012 03:56:01 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.61]) by ietfa.amsl.com (Postfix) with ESMTP id A8A7321F8770 for ; Thu, 16 Feb 2012 03:55:54 -0800 (PST) Received: from administrators-macbook-pro-2.local (c-98-219-195-113.hsd1.pa.comcast.net [98.219.195.113]) (user=dave64 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id q1GBtrI6011709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Feb 2012 06:55:53 -0500 Message-ID: <4F3CEEC9.9000002@andrew.cmu.edu> Date: Thu, 16 Feb 2012 06:55:53 -0500 From: Dave McMurtrie User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: imap5@ietf.org References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> <14945_1329386404_q1GA022W010356_4F3CD398.3020901@qbik.com> <4F3CEA74.80807@andrew.cmu.edu> <4F3CEC38.3070008@qbik.com> In-Reply-To: <4F3CEC38.3070008@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.18.170322 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, RDNS_BROADBAND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_BROADBAND_5 0, __RDNS_POOLED_11 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.61 Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:56:02 -0000 On 2/16/12 6:44 AM, Adrien de Croy wrote: > > > On 17/02/2012 12:37 a.m., Dave McMurtrie wrote: >> >> The Cyrus Project aims to include CalDAV support as part of the Cyrus >> IMAP server, which would make CalDAV deployment much simpler for any >> sites that are already running Cyrus. > > as someone looking to add CalDAV to a mail server, wouldn't it be nice > if you didn't have to > > a) write a web server > b) write DAV extensions > c) layer XML on top of that > d) debug / support all of the above > > just to get a calendar? Yes. I don't view Cyrus CalDAV as a replacement for coming up with new, simplified protocols. It's an attempt to provide a viable open-source alternative to Exchange. In the near term, it may at best offer existing Cyrus sites another option if they're seeking integrated mail and calendar. Dave From brong@fastmail.fm Thu Feb 16 03:56:51 2012 Return-Path: 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 B740B21F87A2 for ; Thu, 16 Feb 2012 03:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 E4BZ-MhIshOr for ; Thu, 16 Feb 2012 03:56:46 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 52B1721F87B1 for ; Thu, 16 Feb 2012 03:56:36 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CF31B21041 for ; Thu, 16 Feb 2012 06:56:35 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 16 Feb 2012 06:56:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= /IKVVECBOFhNGJ0KbuaWM7yYF1o=; b=fxR9JcLpMIXcGhtJ2D0Q/Vg6mNU1Zr7K CD1QdKc5KWm3bOxr+f4Mpzv/uqVFkjB+5ZYexS+Sel2r3f95ZMunf2AgyIsNrg03 tKlzzWArGhce4upAUUfPi3EJiOiBHL16Ygf8osS1cyLbEuM9MstkDWVQYRuaYKEs HR+Luh89oLk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=/IKVVECBOFhNGJ0KbuaWM7yYF1o=; b=PVG +6SLH4jFhFKh48OMQEa0I653OZhZLNArFDqWhzpp8Rk720CALU8tTVaNR1MdEuaQ TVvrwOdXV/JE76IxTb5sml63fLn9rPzN9Nb6Az9p9zytVn2iShaWMM/sE8f2CaQo itYe5L+9bsLflkW6Xw+povkqWVooYpxXodnWAIfU= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id A7DE7A0009E; Thu, 16 Feb 2012 06:56:35 -0500 (EST) Message-Id: <1329393395.29579.140661037313425@webmail.messagingengine.com> X-Sasl-Enc: pFQ+c1oIGb7Vr3v1anun5yB6I5IXy22qsNUkZnGsDn0S 1329393395 From: Bron Gondwana To: Dave Cridland , Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <3077.1329391344.173214@puncture> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com><3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no><3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com><3077.1329386263.642278@puncture> <4F3CD728.3010203@qbik.com><3077.1329388899.383165@puncture> <4F3CE16B.3060603@qbik.com> <3077.1329391344.173214@puncture> Date: Thu, 16 Feb 2012 12:56:35 +0100 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:56:51 -0000 On Thu, Feb 16, 2012, at 11:22 AM, Dave Cridland wrote: > What we need to do is identify the core problems to be solved, > instead of finding solutions and trying to figure out how to use them. > > But it's not nearly as much fun. I'm working on that! Have updated a reasonable amount of the wiki page with a list of RFCs now... more later. I absolutely agree that finding solutions first is a lousy approach, and I'm as guilty as anyone here. Let's get back to working on the core problem(s). Bron. -- Bron Gondwana brong@fastmail.fm From adrien@qbik.com Thu Feb 16 03:56:58 2012 Return-Path: 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 2499721F87C0 for ; Thu, 16 Feb 2012 03:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.268 X-Spam-Level: X-Spam-Status: No, score=-4.268 tagged_above=-999 required=5 tests=[AWL=-1.669, 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 6gHhPO2vmCse for ; Thu, 16 Feb 2012 03:56:53 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id A7CF821F87A9 for ; Thu, 16 Feb 2012 03:56:46 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018866345@smtp.qbik.com>; Fri, 17 Feb 2012 00:56:44 +1300 Message-ID: <4F3CEEFB.2070509@qbik.com> Date: Fri, 17 Feb 2012 00:56:43 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <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> In-Reply-To: <4F3CEB35.9080200@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:56:58 -0000 On 17/02/2012 12:40 a.m., Adrien de Croy wrote: >>> >> Approaching 10% and growing, at least by some metrics: >> >> http://eggert.org/meter/xmpp.html > > that measures deployment only amongst the top 500 sites per territory as per alexa. I think the true deployment would be much much lower. Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From dave@cridland.net Thu Feb 16 03:59:55 2012 Return-Path: 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 E3A2A21F87BD for ; Thu, 16 Feb 2012 03:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] 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 4AkOiQdok2uh for ; Thu, 16 Feb 2012 03:59:50 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id D9A4721F87BF for ; Thu, 16 Feb 2012 03:59:49 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 10FAF1168087; Thu, 16 Feb 2012 11:50:25 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC+dnSJ2N7J9; Thu, 16 Feb 2012 11:50:08 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 5EBC41168067; Thu, 16 Feb 2012 11:50:08 +0000 (GMT) References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <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> In-Reply-To: <4F3CEB35.9080200@qbik.com> MIME-Version: 1.0 Message-Id: <3077.1329393008.372073@puncture> Date: Thu, 16 Feb 2012 11:50:08 +0000 From: Dave Cridland To: Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:59:56 -0000 On Thu Feb 16 11:40:37 2012, Adrien de Croy wrote: > > > On 17/02/2012 12:22 a.m., Dave Cridland wrote: >> On Thu Feb 16 10:58:51 2012, Adrien de Croy wrote: >>> how many corporates deploy XMPP services? >>> >>> >> Approaching 10% and growing, at least by some metrics: >> >> http://eggert.org/meter/xmpp.html > > OK.. I'm struggling to understand why... > > What, why corporates deploy XMPP? That's wildly off-topic for this list. >>> That's why I keep going back to the 1 port like a broken record. >>> Maybe it should just be an SSH tunnel... but that;s >>> back-pedalling quickly and reducing potential user experience >>> with it. >>> >>> >> No, I think it's an orthogonal issue. > > maybe, but nonetheless real, especially for ISP tech support staff. > > Just trying to think of "cheap" ways to get single sign on and > single port using the existing protocols. But it would still be a > bandaid. > > Auto config is a band-aid as well to the solution of multiple sets > of creds. > > It's just part of reducing manual configuration, which we're all agreed is a good thing. Using multiple ports has no bearing, though. >> Right, sure, understood (after s/MTA/MUA/) but what has port 25 >> got to do with it? > > back to my point about getting everything over 1 port. If we had > that, then blocking 25 wouldn't have affected me. But my point is that blocking port 25 shouldn't be affecting you anyway. Submission runs on port 587, has done for years. >> What they did do was carefully market it - Outlook was a very nice >> client, and it came free with Office, and only really worked >> tolerably with Exchange - where it worked really quite well. So >> they managed to leverage from Windows to Office, and from Office >> to Exchange. > > Actually last time I compared prices of versions of Office, the > Outlook component accounted for like $500 NZ. > > Yes, indeed - now they charge for it. But originally, the Office suite covered everything. > It's also possibly the worst IMAP implementation out there. But > they don't _want_ you to use IMAP. They want you to buy Exchange. > > Right, exactly my point. >> What we need to do is identify the core problems to be solved, >> instead of finding solutions and trying to figure out how to use >> them. > > * SPAM ... an infrastructure problem, mostly. > * UDNs I'm not familiar with this acronym. Nor is Wikipedia or Google, I'm afraid. > * configuration issues Right, and discovery (and decent implementations using it) solves 99% of this without any changes to the core protocols. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From brong@fastmail.fm Thu Feb 16 04:12:13 2012 Return-Path: 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 62DAC21F86AF for ; Thu, 16 Feb 2012 04:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 z7zR+4m4+-SI for ; Thu, 16 Feb 2012 04:12:08 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4621F86FD for ; Thu, 16 Feb 2012 04:11:44 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 645A02063F for ; Thu, 16 Feb 2012 07:11:36 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute4.internal (MEProxy); Thu, 16 Feb 2012 07:11:36 -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:in-reply-to:references:subject:date; s=mesmtp; bh= lK+FpQAYHhs3zc1GkIJh5gnPqcU=; b=C8jRhYULgblbOlfxUtAw0XsceZvMe7nJ C3BzP/LZl0rapSoyMM82h/OGeiVeeLicb6Kyp3t1PriF6Byp1ahlueN8VtIa3Lwv S4s6v61uVRLjySFLjD4l0YJl8CGRJz6CIatF77vj4/NIrNBZs2fBkcXlOILSVMSf BRLMPlvsix8= 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:in-reply-to:references :subject:date; s=smtpout; bh=lK+FpQAYHhs3zc1GkIJh5gnPqcU=; b=S7M bxWgkBxP9JuWuOV/WeZU2D2t6dhETXPxCBO8va9Sqrx3GsdL5cX95MsVlKbZqdU0 1aX7AkweIWVPgURGUIJXP27l+e/BSeUh7ibIyrmEAXy0Lqj0rt8L5HBV5NLwqcaW LOnXadj/Hbo5dVQmHTloDDuTSXXrHJq4tSrzwNqQ= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 3C79DA0009E; Thu, 16 Feb 2012 07:11:36 -0500 (EST) Message-Id: <1329394296.953.140661037317197@webmail.messagingengine.com> X-Sasl-Enc: sI/DFgZse3Evt3M1XHImYNlU61i14MdhZIw9VgB61+TM 1329394296 From: Bron Gondwana To: Adrien de Croy , Dave Cridland MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <4F3CEB35.9080200@qbik.com> References: <4F397212.1030107@qbik.com><20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net><4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no><3077.1329382177.374908@puncture> <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> Date: Thu, 16 Feb 2012 13:11:36 +0100 Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:12:13 -0000 On Fri, Feb 17, 2012, at 12:40 AM, Adrien de Croy wrote: > On 17/02/2012 12:22 a.m., Dave Cridland wrote: > > Right, sure, understood (after s/MTA/MUA/) but what has port 25 got to > > do with it? > > back to my point about getting everything over 1 port. If we had that, > then blocking 25 wouldn't have affected me. If you were using port 587, it wouldn't have affected you - that's been standardised for a while. The more important thing is - if we were going over one port, it would have either not affected you, or TOTALLY affected you - with nothing working. Either of those is significantly more understandable to the "punter" than some things working, and others not. The same with "Send succeeds, but then append-to-Sent-folder fails" if your IMAP connection is unavailable but your SMTP server isn't. Or if you're over quota. BURL at least solves the second one, but it solves it in a half arsed way that the little XSEND I put together last week doesn't. With XSEND, you upload the message to IMAP first, then you say: TAG XSEND UID Which sends the message UNLESS it has the \XSent flag already. And it sets the \XSent flag as soon as the message is sent. No waiting on network IO. So the only gap is a failure within the server itself. If the client disconnects and tries again, the flag will already be set, and it will not duplicate the message. No partial failures. No multiple systems depending on each other to be up, configured correctly, routing to each other. (Implementation in this case is "Call sendmail -bmi and pipe the spool file to it") > > What we need to do is identify the core problems to be solved, instead > > of finding solutions and trying to figure out how to use them. > > * SPAM There's a checklist for why this one won't be solved. > * UDNs In the case of wingate, because of the embedded SMTP server, you could theoretically hold the client waiting until you had tried one outbound SMTP. Only fixes the first hop of course. A "ocean boiling" solution to this would involve server level magic on control messages. You'd want forgery protection though... gets trickier when you consider active attacks. Mind you, MDN is already fraught with active attacks. Bron. -- Bron Gondwana brong@fastmail.fm From adrien@qbik.com Thu Feb 16 04:19:24 2012 Return-Path: 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 9F34A21F878A for ; Thu, 16 Feb 2012 04:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.923 X-Spam-Level: X-Spam-Status: No, score=-3.923 tagged_above=-999 required=5 tests=[AWL=-1.924, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] 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 HHjUHlEZjClE for ; Thu, 16 Feb 2012 04:19:20 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id D8DC321F878B for ; Thu, 16 Feb 2012 04:19:19 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018866371@smtp.qbik.com>; Fri, 17 Feb 2012 01:19:17 +1300 Message-ID: <4F3CF440.4070900@qbik.com> Date: Fri, 17 Feb 2012 01:19:12 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <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> <3077.1329393008.372073@puncture> In-Reply-To: <3077.1329393008.372073@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:19:24 -0000 On 17/02/2012 12:50 a.m., Dave Cridland wrote: > > What, why corporates deploy XMPP? That's wildly off-topic for this list. > why so many. it's ok, I understand those stats better now. I think they are skewed. Top 500 sites are quite different to the other 99% of sites. >>>> That's why I keep going back to the 1 port like a broken record. >>>> Maybe it should just be an SSH tunnel... but that;s back-pedalling >>>> quickly and reducing potential user experience with it. >>>> >>>> >>> No, I think it's an orthogonal issue. >> >> maybe, but nonetheless real, especially for ISP tech support staff. >> >> Just trying to think of "cheap" ways to get single sign on and single >> port using the existing protocols. But it would still be a bandaid. >> >> Auto config is a band-aid as well to the solution of multiple sets of >> creds. >> >> > It's just part of reducing manual configuration, which we're all > agreed is a good thing. > > Using multiple ports has no bearing, though. not true. Ports can be (and are) individually blocked, filtered whathaveyou. Therefore availability of individual features within a mail application can be variable rather than all or nothing. Which is better is debatable, but there's more confusion associated with partial failure than complete failure IME. > >>> Right, sure, understood (after s/MTA/MUA/) but what has port 25 got >>> to do with it? >> >> back to my point about getting everything over 1 port. If we had >> that, then blocking 25 wouldn't have affected me. > > But my point is that blocking port 25 shouldn't be affecting you anyway. > > Submission runs on port 587, has done for years. ah... well I use SMTP :) So do many clients. Not enough years I think to make such a big impact. >> * SPAM > > ... an infrastructure problem, mostly. > >> * UDNs > > I'm not familiar with this acronym. Nor is Wikipedia or Google, I'm > afraid. Un deliverable notifications.... pretty sure I'd seen that TLA around before. by and large wrt bounce messages people * don't read them * don't understand them they just ask tech support. We get heaps of such questions. There may be no helping some people, but it's not free. > >> * configuration issues > > Right, and discovery (and decent implementations using it) solves 99% > of this without any changes to the core protocols. Discovery is a bit different to config. It's only part of the picture. I'd like to see it more fully fledged. If ACAP had been widely adopted and deployed it would be a no-brainer. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From brong@fastmail.fm Thu Feb 16 04:41:53 2012 Return-Path: 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 24C2121F87E0 for ; Thu, 16 Feb 2012 04:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 tXFgKbLShrXk for ; Thu, 16 Feb 2012 04:41:47 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id BC27B21F87D4 for ; Thu, 16 Feb 2012 04:41:44 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9C30D210AF for ; Thu, 16 Feb 2012 07:41:43 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute3.internal (MEProxy); Thu, 16 Feb 2012 07:41:43 -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:in-reply-to:references:subject:date; s=mesmtp; bh= qaK5/8rqlPUaByUwD6JP8lqkU2I=; b=mtouIRfLrP/6nJL+3BV+ren8JoxM/qEw n/1RsvNCesCQnenGcKK0gGwyFjpH8VW/feNX2ncb0dNzvRFQhJfQTJnvM1nCxleN KfY5t+tqn6jywyhIHMOi1EKcS75iAwymm5UMoul4ovDSZQNizDxjYmRAfJoifhEv 3CqFgJJ8/NY= 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:in-reply-to:references :subject:date; s=smtpout; bh=qaK5/8rqlPUaByUwD6JP8lqkU2I=; b=MkB EIUSg3NAvwNp2OHT9NeVDnB3sJpxGUnH+KSPDNKnTpYH2UTs5CbV4El8KLLRIjnS j1m3B2q4WqxK5EKn+Ro8v8pQHqOuAt09R2fj+SA9J9Rw1hoazW5rCZBQsU/Q/2zD 4zpUXXxvg0tKFUD+QMaj7A5zYbij2nccYoHgNNYY= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 7439BA0009E; Thu, 16 Feb 2012 07:41:43 -0500 (EST) Message-Id: <1329396103.8954.140661037328961@webmail.messagingengine.com> X-Sasl-Enc: /Hg3pi1Ekz9lqtdOKw9/cc6jR1fRTGX3miGstDmztbow 1329396103 From: Bron Gondwana To: Tony Finch MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net><20120215211301.GA16253@launde.brong.net> Date: Thu, 16 Feb 2012 13:41:43 +0100 Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:41:53 -0000 On Thu, Feb 16, 2012, at 11:30 AM, Tony Finch wrote: > Bron Gondwana wrote: > > > > This is not a problem that's unique to email. There's nothing really > > special about email here unless you make it special. Sure there's a > > bunch of indexed and optimised ways of viewing that data - sort by > > trimmed subject, encodings, etc. All of which could be expressed as > > generic queries against the data model with a query optimiser on the far > > end rather than needing a custom syntax for everything... > > This sounds to me a bit more radical than I was expecting. In particular I > thought you wanted to keep the data model so that existing servers could > support the new protocol reasonably easily. Which implies that mailboxes > remain separate silos rather than the store being a soup of messages > GMail style. Not really. Existing servers would be a lot more efficient with a query which limited to a single "folder", for sure - because they could optimise it. But it's no different than an SQL query across a partitioned table. It means your in-memory-state needs to be big enough to accommodate all the mailboxes that might be in the regular searches, of course. But anyone accessing with an IMAP-model client would still access single folders. The only difference is that the model would accommodate cross-folder requests as a first-order object, so you could sort them by something other than "folder name first", which the existing cross-folder solutions do. If you're always sorting by folder first, you lose all the benefits of having the server do it rather than the client synthesize the results (the FastMail interface's cross-folder-search is a client synthasize results thing - and it splits it up by folder... exactly because the alternative means client-side sorting. I wrote it many years ago, and it does a "GUID" alternative which is "f${folderid}u${uid}" - kind of ugly, and requires the "folder name to folderid" mapping in the database) > > BEEP has also been mentioned. > > I think BEEP is insane. Masses of complexity just to avoid using multiple > concurrent TCP connections. Yeah, I went and actually read the RFCs. Inclined to agree. It's enterprisy in the extreme. Now SCTP, that would be cool. But support isn't there. Bron. -- Bron Gondwana brong@fastmail.fm From adrien@qbik.com Thu Feb 16 04:57:34 2012 Return-Path: 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 C414221F8722 for ; Thu, 16 Feb 2012 04:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.172 X-Spam-Level: X-Spam-Status: No, score=-4.172 tagged_above=-999 required=5 tests=[AWL=-1.573, 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 xHoW0bPXi8wg for ; Thu, 16 Feb 2012 04:57:30 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id D79BC21F872F for ; Thu, 16 Feb 2012 04:57:29 -0800 (PST) Received: From [192.168.1.10] (unverified [219.89.217.118]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.1.0 (Build 3381)) with SMTP id <0018866408@smtp.qbik.com>; Fri, 17 Feb 2012 01:57:28 +1300 Message-ID: <4F3CFD35.10501@qbik.com> Date: Fri, 17 Feb 2012 01:57:25 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Bron Gondwana References: <4F397212.1030107@qbik.com><20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net><4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no><3077.1329382177.374908@puncture> <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> In-Reply-To: <1329394296.953.140661037317197@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:57:34 -0000 On 17/02/2012 1:11 a.m., Bron Gondwana wrote: > On Fri, Feb 17, 2012, at 12:40 AM, Adrien de Croy wrote: >> On 17/02/2012 12:22 a.m., Dave Cridland wrote: >>> Right, sure, understood (after s/MTA/MUA/) but what has port 25 got to >>> do with it? >> back to my point about getting everything over 1 port. If we had that, >> then blocking 25 wouldn't have affected me. > If you were using port 587, it wouldn't have affected you - that's been > standardised for a while. > > The more important thing is - if we were going over one port, it would > have either not affected you, or TOTALLY affected you - with nothing > working. Either of those is significantly more understandable to the > "punter" than some things working, and others not. that's what I've noticed in support. > The same with "Send succeeds, but then append-to-Sent-folder fails" if > your IMAP connection is unavailable but your SMTP server isn't. Or if > you're over quota. > > BURL at least solves the second one, but it solves it in a half arsed > way that the little XSEND I put together last week doesn't. aieeee BURL... until then, a mail server vendor had no need to write an IMAP client. Would have been a trillion times simpler to implement submission from IMAP. I can't even think of a mail server product with IMAP that doesn't have SMTP already. Did anyone actually implement this? It seems so fraught with problems / fragile that I'd expect very few implementations. That's even apart from the complexity. > With XSEND, you upload the message to IMAP first, then you say: > > TAG XSEND UID how do you provide the SMTP forward path? Is that scraped from the headers? maybe should be TAG XSEND UID (addr, addr...) > Which sends the message UNLESS it has the \XSent flag already. > > And it sets the \XSent flag as soon as the message is sent. No > waiting on network IO. So the only gap is a failure within the > server itself. If the client disconnects and tries again, the > flag will already be set, and it will not duplicate the message. > > No partial failures. No multiple systems depending on each other > to be up, configured correctly, routing to each other. > > (Implementation in this case is "Call sendmail -bmi and pipe the > spool file to it") > >>> What we need to do is identify the core problems to be solved, instead >>> of finding solutions and trying to figure out how to use them. >> * SPAM > There's a checklist for why this one won't be solved. > >> * UDNs > In the case of wingate, because of the embedded SMTP server, you could > theoretically hold the client waiting until you had tried one outbound > SMTP. Only fixes the first hop of course. sure, but if you're delivering direct to end MTA, you have pretty much the whole path. > > A "ocean boiling" solution to this would involve server level magic on > control messages. You'd want forgery protection though... gets trickier > when you consider active attacks. Mind you, MDN is already fraught with > active attacks. half the problem is lack of standardisation. MDNs should be machine-readable. Adrien > > Bron. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From fanf2@hermes.cam.ac.uk Thu Feb 16 05:06:18 2012 Return-Path: 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 EF27021F879D for ; Thu, 16 Feb 2012 05:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vJzgB4lPOXBg for ; Thu, 16 Feb 2012 05:06:15 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id DB2A321F8786 for ; Thu, 16 Feb 2012 05:06:14 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43440) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Ry12J-00039f-Sx (Exim 4.72) (return-path ); Thu, 16 Feb 2012 13:06:12 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Ry12J-0007lC-To (Exim 4.67) (return-path ); Thu, 16 Feb 2012 13:06:11 +0000 Date: Thu, 16 Feb 2012 13:06:11 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Bron Gondwana In-Reply-To: <1329396103.8954.140661037328961@webmail.messagingengine.com> Message-ID: References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net><20120215211301.GA16253@launde.brong.net> <1329396103.8954.140661037328961@webmail.messagingengine.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 13:06:19 -0000 Bron Gondwana wrote: > > Not really. Existing servers would be a lot more efficient with a query > which limited to a single "folder", for sure - because they could optimise > it. But it's no different than an SQL query across a partitioned table. > It means your in-memory-state needs to be big enough to accommodate all > the mailboxes that might be in the regular searches, of course. Have you seen UW-IMAP's in-memory state? :-) Tony. -- f.anthony.n.finch http://dotat.at/ South Biscay: Northerly or northeasterly, veering easterly or northeasterly 3 or 4. Slight or moderate. Mainly fair. Moderate or good. From brong@fastmail.fm Thu Feb 16 06:57:52 2012 Return-Path: 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 0D8A821F86A2 for ; Thu, 16 Feb 2012 06:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 gWaoDTXQlEri for ; Thu, 16 Feb 2012 06:57:47 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1532221F8698 for ; Thu, 16 Feb 2012 06:57:47 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9576C21309 for ; Thu, 16 Feb 2012 09:57:46 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 16 Feb 2012 09:57:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=hSLGl0/OsWWHLBEtjElLrLvG AOQ=; b=CBBcZVYcTehdeIrTIotgaEz+h7Sgn1rbVTdaNDtKyI0tutZLaJGpo8Pb zc5lrq4rFDLIP29eUJ3iRRysTFP+FBg5YSOPcJlHeGL02YY7wssk4hRt35FAL+Tn cCbegdlXhBUM33IM/iTjw4jFJn6u3FApliqboxVC5A2nT1gZG0c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=hSLGl0/OsWWHLBEtjElLrLvGAOQ=; b=Pmsr0invZnkUi4aIkgDx+1xC5MOa JsQBz5rG9/LQISSC1GntinublQsW13d4EbeKXfFbOCfFLBruPX48UsC1lHVKstQm het5qAkrzWYQUpkHIe43HLhA2eKYC/3B9DWngmZ6z/Bh397Qh/grC0ZFHYZjMC36 s9RpX9PiJcgjwJo= X-Sasl-enc: ULOfqS0T8P3ICKGkuc1k84JfEYOZZ17htIcQZ0VOlqSy 1329404266 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4C1444827C5; Thu, 16 Feb 2012 09:57:46 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 13B3F118A4A; Thu, 16 Feb 2012 15:57:45 +0100 (CET) Date: Thu, 16 Feb 2012 15:57:45 +0100 From: Bron Gondwana To: Tony Finch Message-ID: <20120216145745.GB21339@launde.brong.net> References: <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <1329396103.8954.140661037328961@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:57:52 -0000 On Thu, Feb 16, 2012 at 01:06:11PM +0000, Tony Finch wrote: > Bron Gondwana wrote: > > > > Not really. Existing servers would be a lot more efficient with a query > > which limited to a single "folder", for sure - because they could optimise > > it. But it's no different than an SQL query across a partitioned table. > > It means your in-memory-state needs to be big enough to accommodate all > > the mailboxes that might be in the regular searches, of course. > > Have you seen UW-IMAP's in-memory state? :-) Nup - I've seen Cyrus' though. It could be trimmed considerably if we had to... Bron. From cyrus@daboo.name Thu Feb 16 07:15:25 2012 Return-Path: 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 29CDB21F866D for ; Thu, 16 Feb 2012 07:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YSM+hOdMQ-WI for ; Thu, 16 Feb 2012 07:15:24 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5D521F863D for ; Thu, 16 Feb 2012 07:15:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E5D3E21FFE02; Thu, 16 Feb 2012 10:15:19 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnbFzwUdOW0U; Thu, 16 Feb 2012 10:15:13 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 0E6DC21FFDF5; Thu, 16 Feb 2012 10:15:11 -0500 (EST) Date: Thu, 16 Feb 2012 10:15:08 -0500 From: Cyrus Daboo To: Sebastian Hagedorn , Adrien de Croy Message-ID: <2778227D5CC4584EECBDA164@caldav.corp.apple.com> In-Reply-To: <8CA186A707E99CE0FB2B38E9@tyrion.rrz.uni-koeln.de> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <8CA186A707E99CE0FB2B38E9@tyrion.rrz.uni-koeln.de> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2489 Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:15:25 -0000 Hi Sebastian, --On February 16, 2012 10:35:43 AM +0100 Sebastian Hagedorn wrote: >> There are settings for: >> >> SMTP: specification of server, choice of authentication method, choice of >> security (SSL vs STARTTLS vs none), username and password. >> IMAP: specification of server, choice of authentication method, choice of >> security (SSL vs STARTTLS vs none), username and password. >> LDAP: specification of server(s), choice of authentication method, choice >> of security (SSL vs STARTTLS vs none), username and password. > > Another way of dealing with that particular issue is autoconfiguration. > Unfortunately there's no accepted standard for that yet, but we (Cologne > University) support Microsoft's and Thunderbird's mechanisms. If you > enter a @uni-koeln.de address in the new account wizard, all settings are > filled in automatically. Today we have SRV mechanisms for email and CalDAV/CardDAV. Whilst the former is relatively new and apparently not supported in any big way (*), the later is used by servers and clients. That said, at the Calendaring and Scheduling Consortium, we have been discussing putting together a more generic "account" provisioning mechanism as opposed to a per-service lookup which is essentially what SRV provides. I am planning on starting some discussion inthe IETF apps area on this. An initial proposal would be to use an HTTP well-known URI to advertise a site's set of services and basic user account provisioning. Many of the vendors involved in CalConnect want this because they feel that the current approach of configuring "standards" based protocols is too unwieldy for users (e.g. having to separately setup email, calendaring, chat etc) vs the kind of setup one gets with e.g. Exchange. Now one could argue that the current complexity could be hidden behind a simple UI on the client (where the client does all the multitude of SRV lookups to see what services are available) but there are downsides to that (multiple DNS requests, inability to tailor response on a per-user basis etc) - basically the process is too complex. So, I (we - CalConnect) want to see something done in this area. Keeping the scope as small and simple as possible will be key though... (*) Some services do have SRVs for email, CalDAV, CardDAV, e.g. try: dig _imaps._tcp.gmail.com srv dig _caldavs._tcp.gmail.com srv dig _caldavs._tcp.icloud.com srv dig _carddavs._tcp.icloud.com srv -- Cyrus Daboo From fanf2@hermes.cam.ac.uk Thu Feb 16 07:22:04 2012 Return-Path: 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 A13D521F87BF for ; Thu, 16 Feb 2012 07:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 RmvusgJ8o3+t for ; Thu, 16 Feb 2012 07:21:58 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA0121F87BA for ; Thu, 16 Feb 2012 07:21:58 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49568) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Ry39f-0004nT-Ff (Exim 4.72) (return-path ); Thu, 16 Feb 2012 15:21:55 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Ry39f-0006c6-QQ (Exim 4.67) (return-path ); Thu, 16 Feb 2012 15:21:55 +0000 Date: Thu, 16 Feb 2012 15:21:55 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Bron Gondwana In-Reply-To: <20120216145745.GB21339@launde.brong.net> Message-ID: References: <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <1329396103.8954.140661037328961@webmail.messagingengine.com> <20120216145745.GB21339@launde.brong.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:22:04 -0000 Bron Gondwana wrote: > On Thu, Feb 16, 2012 at 01:06:11PM +0000, Tony Finch wrote: > > Bron Gondwana wrote: > > > > > > Not really. Existing servers would be a lot more efficient with a query > > > which limited to a single "folder", for sure - because they could optimise > > > it. But it's no different than an SQL query across a partitioned table. > > > It means your in-memory-state needs to be big enough to accommodate all > > > the mailboxes that might be in the regular searches, of course. > > > > Have you seen UW-IMAP's in-memory state? :-) > > Nup - I've seen Cyrus' though. It could be trimmed considerably if we > had to... The problem is UW-IMAP is structured so it can only handle one mailbox at a time. Tony. -- f.anthony.n.finch http://dotat.at/ Dogger, Fisher, German Bight, Humber, Thames, Dover: West or southwest 4 or 5, increasing 6 for a time in Fisher. Slight or moderate, occasionally rough in Fisher. Occasional rain or showers. Moderate or good. From cyrus@daboo.name Thu Feb 16 07:24:07 2012 Return-Path: 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 1F42421F8690 for ; Thu, 16 Feb 2012 07:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 sLUMHUVEGXnr for ; Thu, 16 Feb 2012 07:24:06 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id D581321F87DD for ; Thu, 16 Feb 2012 07:24:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 806A621FFF24; Thu, 16 Feb 2012 10:23:59 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckWgZVn0iLY4; Thu, 16 Feb 2012 10:23:54 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 3437521FFF14; Thu, 16 Feb 2012 10:23:52 -0500 (EST) Date: Thu, 16 Feb 2012 10:23:49 -0500 From: Cyrus Daboo To: Giovanni Panozzo , imap5@ietf.org Message-ID: <58468AD004760C13E7117347@caldav.corp.apple.com> In-Reply-To: <4F3CD1EB.20002@panozzo.it> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <8CA186A707E99CE0FB2B38E9@tyrion.rrz.uni-koeln.de> <4F3CD1EB.20002@panozzo.it> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1808 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:24:07 -0000 Hi Giovanni, --On February 16, 2012 10:52:43 AM +0100 Giovanni Panozzo wrote: > b) Autoconfiguration is checked only at client configuration. I would > like to have the client reconfigured at every startup. This will let me > do major changes at the server sides (ie: enable SSL ? Change server > names ?), and client will be able to reconfigure themselves at next > startup. One of the things we are doing in CalDAV is supporting a server-driven client re-configuration mode. In large scale CalDAV deployments it is sometimes more efficient to "redirect" users to a specific host rather than rely on some internal-to-the-server reverse proxying. To deal with that we simply have servers change a WebDAV property from a path absolute value (e.g. '/calendars/users/cyrus') to one with an FQDN (e.g. 'https://newserver.example.com/calendars/users/cyrus'). Clients are then expected to check that property on a regular basis and if they see it point to a new host, they "re-base" the user account accordingly. And of course IMAP has a similar mechanism - RLOGIN. Now I think I would prefer to stick to a mechanism like that - i.e. the service (imap, CalDAV etc) provides a "redirect" mechanism or at least a signal to the client, to indicate that a re-basing of the account is needed. But that could also be the trigger for the client to go re-do account provisioning. However, you need to be careful in terms of understanding client side "layering". i.e. there are different apps for each service, and possible a separate overall account configuration system. It may not be feasible for say the email app to tell the account config app to re-do all the services for that account. In any case, there are some interesting things to think about here. -- Cyrus Daboo From cyrus@daboo.name Thu Feb 16 07:35:10 2012 Return-Path: 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 3F20D21F86AB for ; Thu, 16 Feb 2012 07:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 nXTSFtp-IQIk for ; Thu, 16 Feb 2012 07:35:09 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 86E6721F8657 for ; Thu, 16 Feb 2012 07:35:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 06D9822000A4; Thu, 16 Feb 2012 10:35:09 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aSZA-g0ca5k; Thu, 16 Feb 2012 10:35:03 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 9766A2200097; Thu, 16 Feb 2012 10:35:01 -0500 (EST) Date: Thu, 16 Feb 2012 10:34:57 -0500 From: Cyrus Daboo To: Dave Cridland , Bron Gondwana , Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\\." Message-ID: <340DCA8DBA39E16EA1E0835C@caldav.corp.apple.com> In-Reply-To: <3077.1329387922.639535@puncture> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com><3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no><307.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <1329386650.31621.140661037282969@webmail.messagingengine.com> <3077.1329387922.639535@puncture> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1226 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:35:10 -0000 Hi Dave, --On February 16, 2012 10:25:22 AM +0000 Dave Cridland wrote: >> Which is a vote from me for "yes, SRV option makes sense". > > Oh, totally agree. Discovery is awesome, user-configuration is insane. I > don't see there's any valid argument the other way. Practical experience with SRV has shown that, whilst it is fine for large service providers to do that sort of thing (c.f., Google, iCloud etc), the practicalities of actually being able to setup SRV records and have proper SSL cert validation is heard, particularly for "hosted domain" type applications. Having discussed with several engineers who have implemented SRV it is clear that having each app do it separately is problematic because there are a bunch of awkward issues. Not in the least is the simple issue of even getting SRV from standard DNS libraries (e.g. one Android developer mentioned that the size of his app increased significantly when he had to bring in libraries to do SRV). Then there is all the certificate verification stuff that needs to be done to properly implement discovery. Overall this is much harder than it needs to be, and other non-standard approaches have proved that. -- Cyrus Daboo From cyrus@daboo.name Thu Feb 16 07:53:31 2012 Return-Path: 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 83AF021F864A for ; Thu, 16 Feb 2012 07:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 q7KFsrrLNqr5 for ; Thu, 16 Feb 2012 07:53:29 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5CB21F85C4 for ; Thu, 16 Feb 2012 07:53:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 60AA222002D1; Thu, 16 Feb 2012 10:53:25 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqGhYb1boX+5; Thu, 16 Feb 2012 10:53:20 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 82F5122002C2; Thu, 16 Feb 2012 10:53:18 -0500 (EST) Date: Thu, 16 Feb 2012 10:53:15 -0500 From: Cyrus Daboo To: Adrien de Croy , Dave McMurtrie Message-ID: In-Reply-To: <4F3CEC38.3070008@qbik.com> References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> <14945_1329386404_q1GA022W010356_4F3CD398.3020901@qbik.com> <4F3CEA74.80807@andrew.cmu.edu> <4F3CEC38.3070008@qbik.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2455 Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:53:31 -0000 Hi Adrien, --On February 17, 2012 12:44:56 AM +1300 Adrien de Croy wrote: >> The Cyrus Project aims to include CalDAV support as part of the Cyrus >> IMAP server, which would make CalDAV deployment much simpler for any >> sites that are already running Cyrus. > > as someone looking to add CalDAV to a mail server, wouldn't it be nice if > you didn't have to > > a) write a web server > b) write DAV extensions > c) layer XML on top of that > d) debug / support all of the above > > just to get a calendar? You fail to appreciate the hard part here - it is not the protocol (which, guess what, is not that hard to do as there are many off-the-shelf webdav implementations to pick on as a starting point - and indeed within a few months of the initial draft being published we had several servers and clients interoperating). The hard part is the semantics of calendaring. As someone who has lived in both the IMAP (email) world, and the iCalendar/CalDAV world, I can tell you that calendaring is like an order of magnitude more complex than email - specifically scheduling. CalDAV servers are very "write heavy" in that there are a lot of modifications happening to existing data - that is something not typical of an IMAP server where modifications are simply metadata changes (flags) or actual message "injection" (delivery, APPEND) or deletion. So if you want to build a high performance CalDAV server you need to take that into account and build something whose scalability is based on a different set of client/server interactions than is typical for IMAP. That is not to say that building that within IMAP or on top of an existing mailstore is impossible - it is. But what is more important is to fully understand the core use cases - or more importantly the requirements for the client/server api. What I would really like us to focus on here, is not IMAP5 per se, but instead a "generic" mail store access API. Lets define the key operations needed by clients and a server API that can provide those behaviors. Once we have that, we can fit it into any protocol we like, be it extensions to IMAP4 (to make IMAP5), HTTP, XMPP whatever. The same thing can be done for a calendar store api (and indeed the Calendaring and Scheduling Consortium has been working on generic abstractions giving rise to REST and SOAP based protocols all built on the same store api model used by CalDAV). -- Cyrus Daboo From Hagedorn@uni-koeln.de Thu Feb 16 08:06:41 2012 Return-Path: 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 BC43E21F8808 for ; Thu, 16 Feb 2012 08:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 FSbjVQoX7CXf for ; Thu, 16 Feb 2012 08:06:37 -0800 (PST) Received: from smtp-out.rrz.uni-koeln.de (smtp-out.rrz.uni-koeln.de [134.95.19.53]) by ietfa.amsl.com (Postfix) with ESMTP id EAFB621F87D6 for ; Thu, 16 Feb 2012 08:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at uni-koeln.de Received: from smtp-auth.rrz.uni-koeln.de (smtp-auth.rrz.uni-koeln.de [134.95.19.93]) by smtp-out.rrz.uni-koeln.de (8.13.8/8.13.8) with ESMTP id q1GG6NLC008821; Thu, 16 Feb 2012 17:06:23 +0100 X-AUTH-SIP: a0620@cable-78-34-35-194.netcologne.de [78.34.35.194] Received: from [192.168.2.114] (cable-78-34-35-194.netcologne.de [78.34.35.194]) (authenticated as user a0620 using DIGEST-MD5 bits=0) by smtp-auth.uni-koeln.de (8.13.8/8.13.8) with ESMTP id q1GG6NwN009906; Thu, 16 Feb 2012 17:06:23 +0100 Date: Thu, 16 Feb 2012 17:06:23 +0100 From: Sebastian Hagedorn To: Cyrus Daboo Message-ID: <2E728E2FA79D62CCE9314E51@Sebbis-iMac.local> In-Reply-To: <340DCA8DBA39E16EA1E0835C@caldav.corp.apple.com> References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <307.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <1329386650.31621.140661037282969@webmail.messagingengine.com> <3077.1329387922.639535@puncture> <340DCA8DBA39E16EA1E0835C@caldav.corp.apple.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) Message-Context: text-message X-Spook: nuclear nuke spy secret assassination cia fbi nsa president MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========812B956C64B3D3F76254==========" X-Scanned-By: MIMEDefang 2.71 on 134.95.19.53 Cc: "Discussion on drastically slimming-down IMAP\\." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:06:41 -0000 --==========812B956C64B3D3F76254========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1495 Hi Cyrus, > --On February 16, 2012 10:25:22 AM +0000 Dave Cridland > wrote: > >>> Which is a vote from me for "yes, SRV option makes sense". >> >> Oh, totally agree. Discovery is awesome, user-configuration is insane. I >> don't see there's any valid argument the other way. > > Practical experience with SRV has shown that, whilst it is fine for large > service providers to do that sort of thing (c.f., Google, iCloud etc), > the practicalities of actually being able to setup SRV records and have > proper SSL cert validation is heard, particularly for "hosted domain" > type applications. This is veering off-topic, but it's something I've spent quite a bit of=20 time on: I suppose that you could call one of Germany's largest=20 universities a large service provider. Setting up SRV records and=20 certificates is no big deal for us. I have set up RC 6186 SRV records for=20 the uni-koeln.de domain, but there are two problems: =E2=80=A2 I'm not aware of a single client that actually uses those =E2=80=A2 it's not enough. What we need is a mechanism to map from an email address to a combo of=20 server addresses and logins. Both the Microsoft approach and the=20 Thunderbird model allow for that. With RFC 6186 the user still needs to=20 know what his or her login is ... in our case it's often not the email=20 address. -- Sebastian Hagedorn - RZKR-R1 (Flachbau), Zi. 18, Robert-Koch-Str. 10 Regionales Rechenzentrum (RRZK) Universit=C3=A4t zu K=C3=B6ln / Cologne University - Tel. +49-221-478-5587 --==========812B956C64B3D3F76254========== Content-Type: application/pkcs7-signature Content-Transfer-Encoding: base64 MIIUqAYJKoZIhvcNAQcCoIIUmTCCFJUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCEhMwggU5MIIEIaADAgECAgQOtLhdMA0GCSqGSIb3DQEBBQUAMHkxCzAJ BgNVBAYTAkRFMQ4wDAYDVQQHEwVLb2VsbjEeMBwGA1UEChMVVW5pdmVyc2l0YWV0 IHp1IEtvZWxuMRQwEgYDVQQDEwtVbmlLb2VsbiBDQTEkMCIGCSqGSIb3DQEJARYV Y2FtYXN0ZXJAdW5pLWtvZWxuLmRlMB4XDTA5MDgyNjEzMzgyMVoXDTEyMDgyNTEz MzgyMVowcDELMAkGA1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYDVQQKExVV bml2ZXJzaXRhZXQgenUgS29lbG4xFDASBgNVBAsTC1JSWkssIE5ldHplMRswGQYD VQQDExJTZWJhc3RpYW4gSGFnZWRvcm4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCvbrQcOH3+9/Pk2gOBHTD8neKH/ULtE2NJs3hdFgc1Zy8JiSPcQ1is E1zHaiX1RANfhWNu2fCMk1rgmlsJAq0K3YShGxdTzD36tTKKM3i+CEoNPLmWik0x +RWK5d/lSez3WGludxvjICAQsDBuFxok5AdtQcVgv2+PPBbjw8YiJhHyWiVcG0iR 3xE3ExWARR6UAhkQiR8MMD+bCDaSPrmv7O9oEkB3BOxY40cyFTzskb2H68MrCX8S HzHw9lcoE3xBvFEySKGOnJEProhE/x619FDRyXpmw6XqFGmBBufmGc1ymYZclVcl uvBsInBRUumjW6yxlnqEfg7PzVRdJAWpAgMBAAGjggHQMIIBzDAJBgNVHRMEAjAA MAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFFryMqfqZw/rn+SOR8hobWb3X/tmMB8GA1UdIwQY MBaAFCrqiesOstApxf75TKV23LdvTwm6MCAGA1UdEQQZMBeBFUhhZ2Vkb3JuQHVu aS1rb2Vsbi5kZTCBgwYDVR0fBHwwejA7oDmgN4Y1aHR0cDovL2NkcDEucGNhLmRm bi5kZS91bmkta29lbG4tY2EvcHViL2NybC9jYWNybC5jcmwwO6A5oDeGNWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvdW5pLWtvZWxuLWNhL3B1Yi9jcmwvY2FjcmwuY3Js MIGeBggrBgEFBQcBAQSBkTCBjjBFBggrBgEFBQcwAoY5aHR0cDovL2NkcDEucGNh LmRmbi5kZS91bmkta29lbG4tY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEUGCCsG AQUFBzAChjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1rb2Vsbi1jYS9wdWIv Y2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAEAQjwt/trFejwkc b0ZDFda7WWMZ48/a6kyXtDOzQwa82HSM77/hE2lRvryWx7oEW6D9Z84nI1AmjSxb fJI733ASHvw/VyA8mXf9/HRzCIMpiH9Zuk3kBqx6bezVRjL4gprvwP4ApUVPzH5A GGF/iEJl09kO6Cjv5VfbhJubucWJzsgmKuZfmfaHOOQ9uNcVqznmseMbkfVeICMy XfxA4+y5v8w65hb+EFP1rQXwf8csDxN48/g8KOmzOcwYd2+4cNz7vUIduQXUXhsc C+zO8gIZeDdAcDgAxGTGklwkGcuYfrQyJywSCz2GyiKK0Jk9maIKPooRSl7QuG5u q8p2A6swggUKMIID8qADAgECAgQKRUldMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQw IgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMDcwNDE4MDc0 MjA3WhcNMTkwNDE3MDAwMDAwWjB5MQswCQYDVQQGEwJERTEOMAwGA1UEBxMFS29l bG4xHjAcBgNVBAoTFVVuaXZlcnNpdGFldCB6dSBLb2VsbjEUMBIGA1UEAxMLVW5p S29lbG4gQ0ExJDAiBgkqhkiG9w0BCQEWFWNhbWFzdGVyQHVuaS1rb2Vsbi5kZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMvE96PdJusN/alR90nwwV4Y iLNM1ANMT2XN4MbfniygeGzgvMX7T8juVDw4H9LRtehfBvjPqMM7nth1RR5k/gSO yUyRUzcNLZS+UVu0bXARd1WckeS8moERrV+/3HMPqNCJuk67pLjowYw1psja4qsJ aT8yOhpbanc3mZIa9tq+d4mLZ0LvZVhuFxhbIdfl+f2agskQbbYbURcPLH/nsvKt vEnKDfcHeVJGX0hfR7ZBQhCe8XiKUNhKKdQV61UO71vw7dP3xzG8PQH3SnhZKTeY hCU7YgW82PXtv26DCDIg6iJyuODqLYwXTjc1601NoToDMN6WGGP0eC/fOnipm6MC AwEAAaOCAbcwggGzMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0G A1UdDgQWBBQq6onrDrLQKcX++Uyldty3b08JujAfBgNVHSMEGDAWgBRJt8bP6D0f f+pEexMp9/EKcD7eZDAgBgNVHREEGTAXgRVjYW1hc3RlckB1bmkta29lbG4uZGUw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5w Y2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUH MAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCteobYEtkcfAeVJzUD m1S/4mRtTt8E6dKtsVHFVuHSc59Gco57ugZ5PxmzV8PU5Pq45KwYZ0zE8mchP5YO iE43bu4dSeDDcIjoh9l5VanjQ+kMM3qf/tv73bRwanUQIMsd3qYHseqsXusddJgX BLZOfs+/o2FCOQX5UucQBHSFGSOObUx6uYywKDT/lY+3mzAQiA35Df20bN3UCQpA ja3KDqeLRhL8YjTw+K1cU4UwH5G/hErxOsUzhf0aKhNv074cReDkPxpBHi9QhKpQ PBehI/0alzG27CIf2rkMBSXiIwUfKQWtBOOVnDftPTB17qFttkhK4MnIIYVBBKrb AeINMIIEITCCAwmgAwIBAgICAMcwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMC REUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVs ZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UE BhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAi BgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTU IOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFssoNTl7LZBF0O2gAHp8 v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90D8EJ ovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWG fW8zs9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDN SVTbyRM0mnF1xWzqpwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBw BgNVHR8EaTBnMGWgY6Bhhl9odHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9z ZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNz dWVyPURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsTKffxCnA+3mQw HwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfc qRjsga9aifC9KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+ER Ee5reJEzfjtfJid1U2WOM2Puz3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUp QPY/czJYDQlrptqFbMA/u41mZFYkTq4NPzI1AVvpjILZcllPsYaF8XSFVuXD+Fzz je5Hs1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6LArZYtfahLDdXAGer I2iNY6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3LxMr+M zkljqAD38hwwggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNV BAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZU LVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDkyMzU5MDBaMHExCzAJ BgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxl a29tIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsL ozXgiykUsRSFrzwQ5DlvNV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25 TVw6ztO4qEJA38+juoJZapIbrBya2ggrJSf5aSNH8eDrLHqb9RMC0H40fMKePABZ q/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgBSV9yQTwVBgGOXa2quJO0 zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ7lMFjxlM 1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoD NNWOWwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0X bAqzK50zMA8GA1UdEwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCUZFmtOWTnKesT/lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7U wz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLOF/Msx2I2VeIi2IlVtJhIqmT6 1hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjytnv+AWeSbRbT2 O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHl cAWbDiNXmZQKbbo5YyiGkvMYhNj70c8FVmRXMYICXTCCAlkCAQEwgYEweTELMAkG A1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYDVQQKExVVbml2ZXJzaXRhZXQg enUgS29lbG4xFDASBgNVBAMTC1VuaUtvZWxuIENBMSQwIgYJKoZIhvcNAQkBFhVj YW1hc3RlckB1bmkta29lbG4uZGUCBA60uF0wCQYFKw4DAhoFAKCBsTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMTYxNjA2MjNa MCMGCSqGSIb3DQEJBDEWBBTxqgpky6Py6sI+phkpR+HuucLEJDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBn77bB MCgg7TbBReySEIdLbyJRW3OSKJhr8nOX7LySXa6PLiVFp+oDQMeugyq9AXR9g6Yw 9i3ZXw/zoPDvUQHFwCXEDkobZqeppfT+cj/0Akfkre9GM4JXQLspQdzOREXar+uS nQCgU4AQSFVQni12Ht3tGCnyzXfDFj1eva1VZnsR9CfgL4xTO0KvnK7n7Q1ASAGL IVGA49UunVtXSywZlkZ2Emr90rcMKZSuByyRYSJRwP1xHg1Twpoo1tZxt4tR0XIb AHOjvzX6DuGnJMQl02jfyeRjg4Rq/zNR5+JZPO/kGwA8UpOu5ROCv3tfQWhd87KR qEkFCogv8slvjk0C --==========812B956C64B3D3F76254==========-- From fanf2@hermes.cam.ac.uk Thu Feb 16 08:40:41 2012 Return-Path: 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 1DCA221F87FA for ; Thu, 16 Feb 2012 08:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UCLtvNH2B43z for ; Thu, 16 Feb 2012 08:40:37 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6021F87F1 for ; Thu, 16 Feb 2012 08:40:36 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39325) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Ry4Nk-0001Mz-ps (Exim 4.72) (return-path ); Thu, 16 Feb 2012 16:40:32 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Ry4Nk-0003lz-0e (Exim 4.67) (return-path ); Thu, 16 Feb 2012 16:40:32 +0000 Date: Thu, 16 Feb 2012 16:40:32 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Adrien de Croy In-Reply-To: <4F3CFD35.10501@qbik.com> Message-ID: References: <4F397212.1030107@qbik.com><20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net><4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no><3077.1329382177.374908@puncture> <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> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:40:41 -0000 Adrien de Croy wrote: > > > With XSEND, you upload the message to IMAP first, then you say: > > > > TAG XSEND UID > > how do you provide the SMTP forward path? Is that scraped from the headers? That's the right thing to do. You also need to do BCC: processing. (sendmail -t does the right thing.) The rationale for BURL is that there is more to the SMTP envelope than just the sender and recipient addresses - in particular there are the DSN attributes. There's a somewhat ugly and ill-defined split between information for MTA processing (in the envelope) and information for MUA processing (in the headers - see MDN for example). But in fact MTAs do header processing too, so there no practical advantage to ESMTP envelope extensions and a lot of complexity disadvantage. There are a few envelope extensions: DSN, future release, message tracking, CONNEG and CONPERM facsimile media conversion, and 8BITMIME + BINARYMIME. If you want to eliminate BURL you need to either define a mapping from headers to the extension parameters that you want to support, or embed ESMTP inside IMAP. Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle: West or northwest, backing southwest, 5 to 7. Rough or very rough. Squally wintry showers. Good, occasionally poor. From brong@fastmail.fm Thu Feb 16 11:18:35 2012 Return-Path: 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 0094121E805B for ; Thu, 16 Feb 2012 11:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 EQZdX9V6L+iQ for ; Thu, 16 Feb 2012 11:18:30 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id E83AF21E8053 for ; Thu, 16 Feb 2012 11:18:29 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3E18520EDB for ; Thu, 16 Feb 2012 14:18:29 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 16 Feb 2012 14:18:29 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=nxSsKcrJDgt0ax9zdoiThdHg vZU=; b=kybsKT9T6JgorM2wuj0s0yx2MNuiIeSHL5QGJIkDKWY748iXZ25IsVhH YPC9I7gcfHN/8hE1odE3j5LveGjsSMxxmvK6VbXD8hdqB6vkcX1aJWwpnvp3iaKN R2eKEGwJsGStGn2q7gHoz/eBrPDk54iIrJfPThN2No9SLSTD7uI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=nxSsKcrJDgt0ax9zdoiThdHgvZU=; b=m1cJyroLqkXFtxWwFweflgan+b/V FdE9xB5074bPAjhCNEy0eCc/vXKkKXUXxOg+Nv+FXVmgq3TiopfH2d44wDeGgn9v 9hUPk8pOQAF2xRhFX5tki1vmrs+WwQjWNMwterzRGVw2of+PSk1n8HMs0JFzNgs+ wibT9GPpPRKnrUs= X-Sasl-enc: ptbGrzFqarGTUvMcocm4csfPLEg73MrdIHaLUl0fRTW3 1329419908 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id CB14248248A; Thu, 16 Feb 2012 14:18:28 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 4C8A4118A4A; Thu, 16 Feb 2012 20:18:27 +0100 (CET) Date: Thu, 16 Feb 2012 20:18:27 +0100 From: Bron Gondwana To: Tony Finch Message-ID: <20120216191827.GA22862@launde.brong.net> References: <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <1329396103.8954.140661037328961@webmail.messagingengine.com> <20120216145745.GB21339@launde.brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:18:35 -0000 On Thu, Feb 16, 2012 at 03:21:55PM +0000, Tony Finch wrote: > Bron Gondwana wrote: > > On Thu, Feb 16, 2012 at 01:06:11PM +0000, Tony Finch wrote: > > > Bron Gondwana wrote: > > > > > > > > Not really. Existing servers would be a lot more efficient with a query > > > > which limited to a single "folder", for sure - because they could optimise > > > > it. But it's no different than an SQL query across a partitioned table. > > > > It means your in-memory-state needs to be big enough to accommodate all > > > > the mailboxes that might be in the regular searches, of course. > > > > > > Have you seen UW-IMAP's in-memory state? :-) > > > > Nup - I've seen Cyrus' though. It could be trimmed considerably if we > > had to... > > The problem is UW-IMAP is structured so it can only handle one mailbox at > a time. Cyrus too. Which is a reason for not forcing the model of "one big pool". I'm not committed to one big pool - if there's a syntax for joining smaller pools together to sort/search across them. This is one of the "more work for the server, less for the client" options, where we assume people writing servers are slightly more clueful. Besides, they'll have a test to run :) Bron. From brong@fastmail.fm Thu Feb 16 11:36:39 2012 Return-Path: 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 E46E821E8020 for ; Thu, 16 Feb 2012 11:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 2VIMDaS1pMQh for ; Thu, 16 Feb 2012 11:36:35 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 10B9A21F87F8 for ; Thu, 16 Feb 2012 11:36:35 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B6F56211FA for ; Thu, 16 Feb 2012 14:36:34 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 16 Feb 2012 14:36:34 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=CAbYETlLNv3lcy9ZQZPnEjCL XGo=; b=S/mmL+81bCSqjPU2zvUZ8z3eySo37gpnjZbWg2mv5GaOBJt9QqgebOe9 c5tGaUl4iOyTtlbHR3LrORVlHfmamtx+/QdSmq13RnBVFjSupQlXnvenxbLgbQKy L+Cx3aYYkmp9a+DdZYBYXNBpGLXDeO4497PCgAXtJEPbQurLA78= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=CAbYETlLNv3lcy9ZQZPnEjCLXGo=; b=ETpgN+eIsrYtSQYKdf/ynEUjQO0N MKnwZT9VuWXiNFKwsLVGwM/wKAUzTZFYLG1H2egaoimoDdshV3BS1gwHa1LdeN/k KAPcxJRO7oKjkMr/wTqT9z/AGSS545wKzESxXCic3hUlXk/cl+2OXw36axyAhAjM UcB+NtbwKjLpbHM= X-Sasl-enc: aATfv2zY7V+aDfwzPyAFE0GiMgxjh2o2O0moxWhwWLv3 1329420994 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6F3CE8E008B; Thu, 16 Feb 2012 14:36:34 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 0F388118A4A; Thu, 16 Feb 2012 20:36:33 +0100 (CET) Date: Thu, 16 Feb 2012 20:36:33 +0100 From: Bron Gondwana To: Cyrus Daboo Message-ID: <20120216193633.GD22862@launde.brong.net> References: <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> <14945_1329386404_q1GA022W010356_4F3CD398.3020901@qbik.com> <4F3CEA74.80807@andrew.cmu.edu> <4F3CEC38.3070008@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:36:40 -0000 On Thu, Feb 16, 2012 at 10:53:15AM -0500, Cyrus Daboo wrote: > What I would really like us to focus on here, is not IMAP5 per se, > but instead a "generic" mail store access API. Absolutely - this is what I've been saying (or at least trying to say) all along! Though I would say "API _and_ data model". And of course complience tests that ensure the API and the data model are correct. > Lets define the key > operations needed by clients and a server API that can provide those > behaviors. Once we have that, we can fit it into any protocol we > like, be it extensions to IMAP4 (to make IMAP5), HTTP, XMPP > whatever. The same thing can be done for a calendar store api (and > indeed the Calendaring and Scheduling Consortium has been working on > generic abstractions giving rise to REST and SOAP based protocols > all built on the same store api model used by CalDAV). Yes please. As I've said, I'm really happy to spend a lot of time on this. My initial posts were largely grown from the frustration of seeing IMAP5 discussions bogging down in silly little bits of custom syntax and bandaids. I will continue with my initial task of accumulating all the relevant RFCs and documenting the pain points they solved. I don't know all of them yet! Bron. From dave@cridland.net Thu Feb 16 11:52:38 2012 Return-Path: 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 4F26221F86A0 for ; Thu, 16 Feb 2012 11:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 d8noXmLjaMkr for ; Thu, 16 Feb 2012 11:52:37 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 43FA121E8094 for ; Thu, 16 Feb 2012 11:52:37 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 5F08A1168087; Thu, 16 Feb 2012 19:52:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sSd18KGRfsn; Thu, 16 Feb 2012 19:52:32 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 334001168067; Thu, 16 Feb 2012 19:52:32 +0000 (GMT) References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com><3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no><307.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <1329386650.31621.140661037282969@webmail.messagingengine.com> <3077.1329387922.639535@puncture> <340DCA8DBA39E16EA1E0835C@caldav.corp.apple.com> In-Reply-To: <340DCA8DBA39E16EA1E0835C@caldav.corp.apple.com> MIME-Version: 1.0 Message-Id: <3077.1329421952.185715@puncture> Date: Thu, 16 Feb 2012 19:52:32 +0000 From: Dave Cridland To: Cyrus Daboo , Bron Gondwana , Adrien de Croy , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:52:38 -0000 On Thu Feb 16 15:34:57 2012, Cyrus Daboo wrote: > Hi Dave, > > --On February 16, 2012 10:25:22 AM +0000 Dave Cridland > wrote: > >>> Which is a vote from me for "yes, SRV option makes sense". >> >> Oh, totally agree. Discovery is awesome, user-configuration is >> insane. I >> don't see there's any valid argument the other way. > > Practical experience with SRV has shown that, whilst it is fine for > large service providers to do that sort of thing (c.f., Google, > iCloud etc), the practicalities of actually being able to setup SRV > records and have proper SSL cert validation is heard, particularly > for "hosted domain" type applications. > > I agree with what you're saying, but I think it's getting substantially easier as time goes on. It used to be a rarity for XMPP services to have SRV records, and very rare to have them relied upon, but it's now commonplace, and the numbers of systems that require SRV resolution for them to be reachable is increasing. > Having discussed with several engineers who have implemented SRV it > is clear that having each app do it separately is problematic > because there are a bunch of awkward issues. Not in the least is > the simple issue of even getting SRV from standard DNS libraries > (e.g. one Android developer mentioned that the size of his app > increased significantly when he had to bring in libraries to do > SRV). Then there is all the certificate verification stuff that > needs to be done to properly implement discovery. Overall this is > much harder than it needs to be, and other non-standard approaches > have proved that. Again, I think SRV resolution in software is increasingly common, and becoming generally easier. It used to be next to impossible in many environments, whereas it's now merely awkward. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From arnt@gulbrandsen.priv.no Thu Feb 16 12:24:50 2012 Return-Path: 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 2F89821F8628 for ; Thu, 16 Feb 2012 12:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 K+FROYblbE7k for ; Thu, 16 Feb 2012 12:24:49 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6E321F861D for ; Thu, 16 Feb 2012 12:24:49 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 43370F8C930; Thu, 16 Feb 2012 20:24:47 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1329423886-12558-12558/10/24; Thu, 16 Feb 2012 20:24:46 +0000 Message-Id: <4F3D6632.1080803@gulbrandsen.priv.no> Date: Thu, 16 Feb 2012 21:25:22 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <307.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <3077.1329386263.642278@puncture> <1329386650.31621.140661037282969@webmail.messagingengine.com> <3077.1329387922.639535@puncture> <340DCA8DBA39E16EA1E0835C@caldav.corp.apple.com> In-Reply-To: <340DCA8DBA39E16EA1E0835C@caldav.corp.apple.com> Content-Type: text/plain; charset=iso-8859-1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:24:50 -0000 On 02/16/2012 04:34 PM, Cyrus Daboo wrote: > Not in the least is the simple issue of even getting SRV from standard > DNS libraries (e.g. one Android developer mentioned that the size of his > app increased significantly when he had to bring in libraries to do SRV). The code they're complaining about was ported to android by me, and I must say that the code isn't at all optimised for that use case. It wouldn't be too difficult to strip out about 95% of the code and leave a simple DNS query library. I didn't care enough to do it, and I observe that neither did the developer you spoke to. Arnt From adrien@qbik.com Thu Feb 16 12:50:23 2012 Return-Path: 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 A6DBB11E80B5 for ; Thu, 16 Feb 2012 12:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.132 X-Spam-Level: X-Spam-Status: No, score=-4.132 tagged_above=-999 required=5 tests=[AWL=-1.533, 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 zUp5RXu8LKGW for ; Thu, 16 Feb 2012 12:50:19 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id CF8AC11E808E for ; Thu, 16 Feb 2012 12:50:18 -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 <0018867037@smtp.qbik.com>; Fri, 17 Feb 2012 09:50:15 +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 <0010060731@sago.qbik.com>; Fri, 17 Feb 2012 09:50:01 +1300 Message-ID: <4F3D6BF9.6040801@qbik.com> Date: Fri, 17 Feb 2012 09:50:01 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Cyrus Daboo References: <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <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> <20120215213122.GB16253@launde.brong.net> <4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture> <4F3CA887.9050509@gulbrandsen.priv.no> <3077.1329382177.374908@puncture> <4F3CCA6C.3020004@qbik.com> <8CA186A707E99CE0FB2B38E9@tyrion.rrz.uni-koeln.de> <4F3CD1EB.20002@panozzo.it> <58468AD004760C13E7117347@caldav.corp.apple.com> In-Reply-To: <58468AD004760C13E7117347@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:50:23 -0000 One of the things that discovery gives you is an opportunity when the discovery is initiated to make a decision about what will provide the service(s). this means load-balancing, failover etc can be implemented. One issue with using a well-known http URI for user account discovery, is that most organisations that run web services already have a website set up on their base domain. So you'd have to wedge the discovery provision into an existing web site and infrastructure. Another option could be to use DNS again. e.g. do a dns SRV lookup for say _localpart._allservices._example.com which could return multiple records, one for each available service. Could even use SRV records for this where the record name is _ldap._tcp etc.... possibly need some CNAME glue. Adrien On 17/02/2012 4:23 a.m., Cyrus Daboo wrote: > Hi Giovanni, > > --On February 16, 2012 10:52:43 AM +0100 Giovanni Panozzo > wrote: > >> b) Autoconfiguration is checked only at client configuration. I would >> like to have the client reconfigured at every startup. This will let me >> do major changes at the server sides (ie: enable SSL ? Change server >> names ?), and client will be able to reconfigure themselves at next >> startup. > > One of the things we are doing in CalDAV is supporting a server-driven > client re-configuration mode. In large scale CalDAV deployments it is > sometimes more efficient to "redirect" users to a specific host rather > than rely on some internal-to-the-server reverse proxying. To deal > with that we simply have servers change a WebDAV property from a path > absolute value (e.g. '/calendars/users/cyrus') to one with an FQDN > (e.g. 'https://newserver.example.com/calendars/users/cyrus'). Clients > are then expected to check that property on a regular basis and if > they see it point to a new host, they "re-base" the user account > accordingly. > > And of course IMAP has a similar mechanism - RLOGIN. > > Now I think I would prefer to stick to a mechanism like that - i.e. > the service (imap, CalDAV etc) provides a "redirect" mechanism or at > least a signal to the client, to indicate that a re-basing of the > account is needed. But that could also be the trigger for the client > to go re-do account provisioning. However, you need to be careful in > terms of understanding client side "layering". i.e. there are > different apps for each service, and possible a separate overall > account configuration system. It may not be feasible for say the email > app to tell the account config app to re-do all the services for that > account. In any case, there are some interesting things to think about > here. > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From adrien@qbik.com Thu Feb 16 12:56:05 2012 Return-Path: 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 0E92C21E804E for ; Thu, 16 Feb 2012 12:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.094 X-Spam-Level: X-Spam-Status: No, score=-4.094 tagged_above=-999 required=5 tests=[AWL=-1.495, 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 giBMMUVL7sHW for ; Thu, 16 Feb 2012 12:56:02 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 72BF421E8051 for ; Thu, 16 Feb 2012 12:56:02 -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 <0018867048@smtp.qbik.com>; Fri, 17 Feb 2012 09:56:00 +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 <0010060736@sago.qbik.com>; Fri, 17 Feb 2012 09:55:58 +1300 Message-ID: <4F3D6D5E.7090507@qbik.com> Date: Fri, 17 Feb 2012 09:55:58 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Cyrus Daboo References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com> <4F3C514F.1010602@qbik.com> <66F68487BF0EED4BA7D767E2410F30B3EFF25945BF@FRSPX100.fr01.awl.atosorigin.net> <14945_1329386404_q1GA022W010356_4F3CD398.3020901@qbik.com> <4F3CEA74.80807@andrew.cmu.edu> <4F3CEC38.3070008@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:56:05 -0000 On 17/02/2012 4:53 a.m., Cyrus Daboo wrote: > Hi Adrien, > > --On February 17, 2012 12:44:56 AM +1300 Adrien de Croy > wrote: > >>> The Cyrus Project aims to include CalDAV support as part of the Cyrus >>> IMAP server, which would make CalDAV deployment much simpler for any >>> sites that are already running Cyrus. >> >> as someone looking to add CalDAV to a mail server, wouldn't it be >> nice if >> you didn't have to >> >> a) write a web server >> b) write DAV extensions >> c) layer XML on top of that >> d) debug / support all of the above >> >> just to get a calendar? > > You fail to appreciate the hard part here - it is not the protocol > (which, guess what, is not that hard to do as there are many > off-the-shelf webdav implementations to pick on as a starting point - > and indeed within a few months of the initial draft being published we > had several servers and clients interoperating). The hard part is the > semantics of calendaring. As someone who has lived in both the IMAP > (email) world, and the iCalendar/CalDAV world, I can tell you that > calendaring is like an order of magnitude more complex than email - > specifically scheduling. I'm not discounting the difficulty and complexity of writing calendaring. It's just that putting it over HTTP adds complexity is all. Not everyone can use an off-the-shelf component for that. Writing a web server is non-trivial. Making it hardened enough to withstand the internet is another issue. It's harder to defend against http-borne attacks than IMAP attacks. > > CalDAV servers are very "write heavy" in that there are a lot of > modifications happening to existing data - that is something not > typical of an IMAP server where modifications are simply metadata > changes (flags) or actual message "injection" (delivery, APPEND) or > deletion. So if you want to build a high performance CalDAV server you > need to take that into account and build something whose scalability > is based on a different set of client/server interactions than is > typical for IMAP. > > That is not to say that building that within IMAP or on top of an > existing mailstore is impossible - it is. But what is more important > is to fully understand the core use cases - or more importantly the > requirements for the client/server api. Yeah, I don't know that I was proposing building CalDAV into IMAP itself. That's where I was going with layering. > > What I would really like us to focus on here, is not IMAP5 per se, but > instead a "generic" mail store access API. Lets define the key > operations needed by clients and a server API that can provide those > behaviors. Once we have that, we can fit it into any protocol we like, > be it extensions to IMAP4 (to make IMAP5), HTTP, XMPP whatever. The > same thing can be done for a calendar store api (and indeed the > Calendaring and Scheduling Consortium has been working on generic > abstractions giving rise to REST and SOAP based protocols all built on > the same store api model used by CalDAV). > IMAP is fairly feature-rich. E.g. If we want to support server-side searching (which I hope we do), then the server needs to be able to unpick mime, and have a query language rich enough to be useful. That seems to me (on the face of it) to be a bit beyond just a mail store. Regards Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From adrien@qbik.com Thu Feb 16 13:00:22 2012 Return-Path: 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 0590A21F8604 for ; Thu, 16 Feb 2012 13:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.057 X-Spam-Level: X-Spam-Status: No, score=-4.057 tagged_above=-999 required=5 tests=[AWL=-1.458, 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 jDQYaOCTgT-Y for ; Thu, 16 Feb 2012 13:00:17 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3439A21F8602 for ; Thu, 16 Feb 2012 13:00:17 -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 <0018867054@smtp.qbik.com>; Fri, 17 Feb 2012 10:00:15 +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 <0010060739@sago.qbik.com>; Fri, 17 Feb 2012 10:00:07 +1300 Message-ID: <4F3D6E57.8010301@qbik.com> Date: Fri, 17 Feb 2012 10:00:07 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Tony Finch References: <20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net><4F3C2C1B.6030408@qbik.com> <3077.1329344733.342803@puncture><4F3CA887.9050509@gulbrandsen.priv.no><3077.1329382177.374908@puncture> <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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:00:22 -0000 On 17/02/2012 5:40 a.m., Tony Finch wrote: > Adrien de Croy wrote: >>> With XSEND, you upload the message to IMAP first, then you say: >>> >>> TAG XSEND UID >> how do you provide the SMTP forward path? Is that scraped from the headers? > That's the right thing to do. You also need to do BCC: processing. > (sendmail -t does the right thing.) I think the guys that developed SMTP would disagree with you. The reason the envelope is even specified in SMTP rather than the receiver simply scraping them out of the message, is that sometimes you need to deliver a message somewhere other than the To: / bcc: headers. > The rationale for BURL is that there is more to the SMTP envelope than > just the sender and recipient addresses - in particular there are the DSN > attributes. There's a somewhat ugly and ill-defined split between > information for MTA processing (in the envelope) and information for MUA > processing (in the headers - see MDN for example). But in fact MTAs do > header processing too, so there no practical advantage to ESMTP envelope > extensions and a lot of complexity disadvantage. > > There are a few envelope extensions: DSN, future release, message > tracking, CONNEG and CONPERM facsimile media conversion, and 8BITMIME + > BINARYMIME. If you want to eliminate BURL you need to either define a > mapping from headers to the extension parameters that you want to support, > or embed ESMTP inside IMAP. yep, I'd definitely go for embedding SMTP into IMAP... since a) SMTP is a trivially simple protocol for an IMAP server to use to submit a message on behalf, whereas an IMAP client is much more complicated, b) take a look at the security implications in the BURL RFC. Adrien > > Tony. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From adrien@qbik.com Thu Feb 16 13:01:07 2012 Return-Path: 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 2041021E8044 for ; Thu, 16 Feb 2012 13:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.022 X-Spam-Level: X-Spam-Status: No, score=-4.022 tagged_above=-999 required=5 tests=[AWL=-1.423, 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 OpMOYbnEp99p for ; Thu, 16 Feb 2012 13:01:02 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3538A21F8643 for ; Thu, 16 Feb 2012 13:01:02 -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 <0018867059@smtp.qbik.com>; Fri, 17 Feb 2012 10:01:00 +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 <0010060741@sago.qbik.com>; Fri, 17 Feb 2012 10:00:55 +1300 Message-ID: <4F3D6E87.9060006@qbik.com> Date: Fri, 17 Feb 2012 10:00:55 +1300 From: Adrien de Croy 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 References: <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <1329396103.8954.140661037328961@webmail.messagingengine.com> <20120216145745.GB21339@launde.brong.net> <20120216191827.GA22862@launde.brong.net> In-Reply-To: <20120216191827.GA22862@launde.brong.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:01:07 -0000 one thing - what do you mean by "one big pool". Cheers Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From brong@fastmail.fm Thu Feb 16 14:31:10 2012 Return-Path: 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 E23BF21E8093 for ; Thu, 16 Feb 2012 14:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 dZVMJ0vhmXvH for ; Thu, 16 Feb 2012 14:31:06 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id E8BE021E8092 for ; Thu, 16 Feb 2012 14:31:05 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 967C820CD3 for ; Thu, 16 Feb 2012 17:31:05 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 16 Feb 2012 17:31:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=fYJrpLukDe3695QUqXNsDPK3 jjo=; b=QU8eEaszSFc0jnii8d0qbzO1alk10iWRe2sBF/xDAioEb1OidZqm0BZ5 +SUTFnZyzTqomrHepFQb/xtVq876fnOec7rBmGz2ZRrP2WHjIXM//fQy+chA75oJ K1GT+TER7NtD8eNFaAWVNrwd2avINhmJU23dz5L9taq7d8YMzX8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=fYJrpLukDe3695QUqXNsDPK3jjo=; b=n/IB98Td6+ZOM73k8FBl37VcHB0T 03nXEIYFUzjq8mw8xGntvqCF0dFweNFt1XHDuHFLwCTl+kl6zp1GF0V2o36CqE5h cGgYsepMgI8s7y6bZpL3JlT+JPnJLrTPlAfYM0vhQnDfCeMtHA6TSWoBeZllSI0L 5VQfdzlZS/2CmXg= X-Sasl-enc: Cd29po1tKKQUKQATBkpRuhekA9L60RRgPiCxo2p4SrH/ 1329431465 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4F0954824CB; Thu, 16 Feb 2012 17:31:05 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 115F72260C3; Thu, 16 Feb 2012 23:31:04 +0100 (CET) Date: Thu, 16 Feb 2012 23:31:04 +0100 From: Bron Gondwana To: Adrien de Croy Message-ID: <20120216223104.GC24183@launde.brong.net> References: <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <1329396103.8954.140661037328961@webmail.messagingengine.com> <20120216145745.GB21339@launde.brong.net> <20120216191827.GA22862@launde.brong.net> <4F3D6E87.9060006@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3D6E87.9060006@qbik.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." Subject: Re: [imap5] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:31:11 -0000 On Fri, Feb 17, 2012 at 10:00:55AM +1300, Adrien de Croy wrote: > one thing - what do you mean by "one big pool". Similar to quotaroot - "messageroot". We're going to do it with users and the conversations database. For now they're actually locked to users, but it doesn't handled thousands of shared folders well, because they would all shared one central DB. So one 'root' per user which shares a single highestmodseq and uidvalidity counter. In particularly, we could then enforce every single folder having a different UIDVALIDITY, so we could use a single 64 bit value to uniquely identify message/folder. It would even allow multiple consecutive messages in the same folder to compress into a range. This will allow supporting shared folders quite nicely by rooting each one in itself as a standalone folder, no shared state. That's the idea, anyway. Bron. From brong@fastmail.fm Thu Feb 16 14:37:38 2012 Return-Path: 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 9E88A21E805E for ; Thu, 16 Feb 2012 14:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 SFbp5kgNbDYE for ; Thu, 16 Feb 2012 14:37:33 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id C14E321E803D for ; Thu, 16 Feb 2012 14:37:26 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 36F3F20DC7 for ; Thu, 16 Feb 2012 17:37:26 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 16 Feb 2012 17:37:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=/fYPrUa+lxtN76xA5iQcbJTT Pvg=; b=hM858dCdoFpnu5eYND4yOdygJhJQgYySMgQUzsIO3XSw9nuCQLzUHiOg GyVGYib+nrFbzykbtkUOfJPm12qttvJqtLmudwbgAmqc23SevhqswqcDDcdFGfoP OeaZcqjEIEvtBfsScM6gZIa2qVXwcIy2PasTpi7yadAK6lAsDNs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=/fYPrUa+lxtN76xA5iQcbJTTPvg=; b=JZx5RBCT4S1sVNXPpCtva0ItASbg 7MhD2/IjIjCxivI56jjx96iVwatuaQg+8qq6YWYEDMdO5Rw3/uVKS4m4D0wpD36s LwLVlA2CrVVjQwSPn984/jtY891UepIzDLpB46a1LU/s1zJUOnW+/j+HSQguOEB+ hePhTBVAtct0dT0= X-Sasl-enc: 08A3gxIG9JF/TyzQcAcFM9m8ut6lo0VE72QxGAgwdCX3 1329431845 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id C2C694824CB; Thu, 16 Feb 2012 17:37:25 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 826572260C3; Thu, 16 Feb 2012 23:37:24 +0100 (CET) Date: Thu, 16 Feb 2012 23:37:24 +0100 From: Bron Gondwana To: Adrien de Croy Message-ID: <20120216223724.GD24183@launde.brong.net> References: <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> <4F3D6E57.8010301@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3D6E57.8010301@qbik.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:37:38 -0000 On Fri, Feb 17, 2012 at 10:00:07AM +1300, Adrien de Croy wrote: > > > On 17/02/2012 5:40 a.m., Tony Finch wrote: > >Adrien de Croy wrote: > >>>With XSEND, you upload the message to IMAP first, then you say: > >>> > >>>TAG XSEND UID > >>how do you provide the SMTP forward path? Is that scraped from the headers? > >That's the right thing to do. You also need to do BCC: processing. > >(sendmail -t does the right thing.) > > I think the guys that developed SMTP would disagree with you. The > reason the envelope is even specified in SMTP rather than the > receiver simply scraping them out of the message, is that sometimes > you need to deliver a message somewhere other than the To: / bcc: > headers. Rarely. I don't even know an IMAP client which supports doing that. It's not like SMTP would disappear if you need something more complex. > >The rationale for BURL is that there is more to the SMTP envelope than > >just the sender and recipient addresses - in particular there are the DSN > >attributes. There's a somewhat ugly and ill-defined split between > >information for MTA processing (in the envelope) and information for MUA > >processing (in the headers - see MDN for example). But in fact MTAs do > >header processing too, so there no practical advantage to ESMTP envelope > >extensions and a lot of complexity disadvantage. > > > >There are a few envelope extensions: DSN, future release, message > >tracking, CONNEG and CONPERM facsimile media conversion, and 8BITMIME + > >BINARYMIME. If you want to eliminate BURL you need to either define a > >mapping from headers to the extension parameters that you want to support, > >or embed ESMTP inside IMAP. > > yep, I'd definitely go for embedding SMTP into IMAP... since Simple, heh. > a) SMTP is a trivially simple protocol for an IMAP server to use to > submit a message on behalf, whereas an IMAP client is much more > complicated, > b) take a look at the security implications in the BURL RFC. Definitely agree that Client <-----> IMAP ------> SMTP is much simpler dataflow than +--------------------+ +--------------+ | | <------------ | | | MUA (M) | | IMAPv4Rev1 | | | | Server | | | ------------> | (Server I) | +--------------------+ +--------------+ ^ | ^ | | | | | | | | | | | | | | | | | | | | | | | | v | | +--------------+ | |----------------------> | SMTP | | | Submit | |-----------------------------| Server | | (Server S) | +--------------+ Half as many communication channels. Bron. From dwhite@olp.net Thu Feb 16 14:41:29 2012 Return-Path: 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 967F521E805A for ; Thu, 16 Feb 2012 14:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 02Ii9v1OGUay for ; Thu, 16 Feb 2012 14:41:28 -0800 (PST) Received: from pinky.olp.net (pinky2.olp.net [67.217.151.213]) by ietfa.amsl.com (Postfix) with ESMTP id B98FB21E803D for ; Thu, 16 Feb 2012 14:41:28 -0800 (PST) Received: from quark.olp.net (vpn.olp.net [67.217.151.100]) by pinky.olp.net (Postfix) with ESMTP id A128D292DB4; Thu, 16 Feb 2012 16:41:24 -0600 (CST) Received: by quark.olp.net (Postfix, from userid 1000) id 8D2E37B2144; Thu, 16 Feb 2012 16:41:24 -0600 (CST) Date: Thu, 16 Feb 2012 16:41:24 -0600 From: Dan White To: Adrien de Croy Message-ID: <20120216224124.GC4578@dan.olp.net> References: <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> <4F3D6E57.8010301@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F3D6E57.8010301@qbik.com> X-OS: Linux quark 3.0.0-2-amd64 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:41:29 -0000 On 02/17/12 10:00 +1300, Adrien de Croy wrote: > > >On 17/02/2012 5:40 a.m., Tony Finch wrote: >>Adrien de Croy wrote: >>>>With XSEND, you upload the message to IMAP first, then you say: >>>> >>>>TAG XSEND UID >>>how do you provide the SMTP forward path? Is that scraped from the headers? >>That's the right thing to do. You also need to do BCC: processing. >>(sendmail -t does the right thing.) > >I think the guys that developed SMTP would disagree with you. The >reason the envelope is even specified in SMTP rather than the >receiver simply scraping them out of the message, is that sometimes >you need to deliver a message somewhere other than the To: / bcc: >headers. > >>The rationale for BURL is that there is more to the SMTP envelope than >>just the sender and recipient addresses - in particular there are the DSN >>attributes. There's a somewhat ugly and ill-defined split between >>information for MTA processing (in the envelope) and information for MUA >>processing (in the headers - see MDN for example). But in fact MTAs do >>header processing too, so there no practical advantage to ESMTP envelope >>extensions and a lot of complexity disadvantage. >> >>There are a few envelope extensions: DSN, future release, message >>tracking, CONNEG and CONPERM facsimile media conversion, and 8BITMIME + >>BINARYMIME. If you want to eliminate BURL you need to either define a >>mapping from headers to the extension parameters that you want to support, >>or embed ESMTP inside IMAP. > >yep, I'd definitely go for embedding SMTP into IMAP... since > >a) SMTP is a trivially simple protocol for an IMAP server to use to >submit a message on behalf, whereas an IMAP client is much more >complicated, >b) take a look at the security implications in the BURL RFC. However, spam is a problem caused by a deficiency (or whatever you want to call it) within the smtp protocol. imap does not directly or indirectly lead to the generation of spam, unless you want to consider backscatter from a sieve notification to be spam. smtp (or submission) is one of those things that's actually easy to configure in an email client. I fear that if the two get combined on the same port that imap server IPs may start to get caught up in the cat and mouse game spam parsers play. -- Dan White From mrcrispin@panda.com Thu Feb 16 14:48:50 2012 Return-Path: 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 8D60D21F882B for ; Thu, 16 Feb 2012 14:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1vOY-Jb4-FpT for ; Thu, 16 Feb 2012 14:48:46 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3081621F882E for ; Thu, 16 Feb 2012 14:48:46 -0800 (PST) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Thu, 16 Feb 2012 14:48:44 -0800 X-MailFrom: mrcrispin@panda.com Date: Thu, 16 Feb 2012 14:48:41 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: imap5@ietf.org In-Reply-To: <20120216223724.GD24183@launde.brong.net> Message-ID: References: <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> <4F3D6E57.8010301@qbik.com> <20120216223724.GD24183@launde.brong.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:48:50 -0000 On Thu, 16 Feb 2012, Bron Gondwana wrote: >> I think the guys that developed SMTP would disagree with you. The >> reason the envelope is even specified in SMTP rather than the >> receiver simply scraping them out of the message, is that sometimes >> you need to deliver a message somewhere other than the To: / bcc: >> headers. > Rarely. I don't even know an IMAP client which supports doing that. HAHAHAHAHAHAHAHAHAHAHAHAHAHA. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From adrien@qbik.com Thu Feb 16 14:50:22 2012 Return-Path: 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 B9CEB21F882F for ; Thu, 16 Feb 2012 14:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[AWL=-1.390, 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 RxMXrDFiYnAS for ; Thu, 16 Feb 2012 14:50:17 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 237E521E8022 for ; Thu, 16 Feb 2012 14:50:16 -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 <0018867273@smtp.qbik.com>; Fri, 17 Feb 2012 11:50:16 +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 <0010060807@sago.qbik.com>; Fri, 17 Feb 2012 11:50:08 +1300 Message-ID: <4F3D8820.6040500@qbik.com> Date: Fri, 17 Feb 2012 11:50:08 +1300 From: Adrien de Croy 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 References: <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> <4F3D6E57.8010301@qbik.com> <20120216223724.GD24183@launde.brong.net> In-Reply-To: <20120216223724.GD24183@launde.brong.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:50:22 -0000 On 17/02/2012 11:37 a.m., Bron Gondwana wrote: > On Fri, Feb 17, 2012 at 10:00:07AM +1300, Adrien de Croy wrote: >> >> On 17/02/2012 5:40 a.m., Tony Finch wrote: >>> Adrien de Croy wrote: >>>>> With XSEND, you upload the message to IMAP first, then you say: >>>>> >>>>> TAG XSEND UID >>>> how do you provide the SMTP forward path? Is that scraped from the headers? >>> That's the right thing to do. You also need to do BCC: processing. >>> (sendmail -t does the right thing.) >> I think the guys that developed SMTP would disagree with you. The >> reason the envelope is even specified in SMTP rather than the >> receiver simply scraping them out of the message, is that sometimes >> you need to deliver a message somewhere other than the To: / bcc: >> headers. > Rarely. I don't even know an IMAP client which supports doing that. > It's not like SMTP would disappear if you need something more complex. parsing the message file is a lot more work than the client passing the info over (which it already has). just sayin' then can handle both scenarios... list processing etc... opportunities open up instead of being shut down. Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From blong@google.com Thu Feb 16 14:53:19 2012 Return-Path: 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 BC0CE21E803D for ; Thu, 16 Feb 2012 14:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 RefVifWMnqUS for ; Thu, 16 Feb 2012 14:53:19 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 243C721E801C for ; Thu, 16 Feb 2012 14:53:18 -0800 (PST) Received: by qan41 with SMTP id 41so2970224qan.10 for ; Thu, 16 Feb 2012 14:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=g7WnbzcYe1i9yJWrtmpggZO/8sfoDu/MTchRIC4AwVI=; b=miwmnb8o8pdij0nY44KxdpZqJqPmXqyUIU824EqNsB54Op6Ane6VF4C/MzRysEQbOo 5XPy0yRIDi4Gfxj2cvfN1RimrC4zgjqOn5cIomuPwsypIIYm69EElCuJMfnd1ekCYOxs z7Tb+d9aEqr517kvdRByrDkZ6TYUVi7BUTJTY= Received: by 10.229.135.11 with SMTP id l11mr3097062qct.140.1329432798570; Thu, 16 Feb 2012 14:53:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.135.11 with SMTP id l11mr3097051qct.140.1329432798430; Thu, 16 Feb 2012 14:53:18 -0800 (PST) Received: by 10.229.216.201 with HTTP; Thu, 16 Feb 2012 14:53:18 -0800 (PST) In-Reply-To: <20120216223724.GD24183@launde.brong.net> References: <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> <4F3D6E57.8010301@qbik.com> <20120216223724.GD24183@launde.brong.net> Date: Thu, 16 Feb 2012 14:53:18 -0800 Message-ID: From: Brandon Long To: Bron Gondwana Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnCoMOFJ4//zcy0bPL1hm7XQX9kfyV6QM6EqBo3rDC3Vn+Ndzr+PO5TeJSnEwd9cZgUcGZcOIS5dfbFMysP73Muws3hJt6ihd+WTGsq73rg8JfLOfWxP0ps0JO407VHXAK8TQga Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:53:19 -0000 On Thu, Feb 16, 2012 at 2:37 PM, Bron Gondwana wrote: > On Fri, Feb 17, 2012 at 10:00:07AM +1300, Adrien de Croy wrote: >> >> >> On 17/02/2012 5:40 a.m., Tony Finch wrote: >> >Adrien de Croy =A0wrote: >> >>>With XSEND, you upload the message to IMAP first, then you say: >> >>> >> >>>TAG XSEND UID >> >>how do you provide the SMTP forward path? =A0Is that scraped from the = headers? >> >That's the right thing to do. You also need to do BCC: processing. >> >(sendmail -t does the right thing.) >> >> I think the guys that developed SMTP would disagree with you. =A0The >> reason the envelope is even specified in SMTP rather than the >> receiver simply scraping them out of the message, is that sometimes >> you need to deliver a message somewhere other than the To: / bcc: >> headers. > > Rarely. =A0I don't even know an IMAP client which supports doing that. > It's not like SMTP would disappear if you need something more complex. mutt comes to mind, though its not doing it through SMTP but via arguments to sendmail. Well, maybe it does support them with the newer built-in smtp submission. Brandon From blong@google.com Thu Feb 16 14:57:55 2012 Return-Path: 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 7F19121F854E for ; Thu, 16 Feb 2012 14:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 B5AKv+o+g2gw for ; Thu, 16 Feb 2012 14:57:55 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6A3D21F854C for ; Thu, 16 Feb 2012 14:57:54 -0800 (PST) Received: by qafi29 with SMTP id i29so194199qaf.10 for ; Thu, 16 Feb 2012 14:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=PkhozYU1VyR2co+8MhhhbkvNYLjhRTM5zwRpMnm/hXw=; b=UpjEiyZZW2c2jS+I2aI+LbmjWOOd1tI/sxZv4fpMsQKRakICbXvzCebA0HxR8xp8MU K9EUbxikedsUleLvKt+qSmF84fVc3U69Oxbf8EJVU3YadY1kG590sNQrVo83jOmk9njF AZ1Iy9noXd0fz6CEIi+Vp9t9rRLXDXoNBPt+w= Received: by 10.229.76.21 with SMTP id a21mr3214193qck.20.1329433074158; Thu, 16 Feb 2012 14:57:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.76.21 with SMTP id a21mr3214179qck.20.1329433073978; Thu, 16 Feb 2012 14:57:53 -0800 (PST) Received: by 10.229.216.201 with HTTP; Thu, 16 Feb 2012 14:57:53 -0800 (PST) In-Reply-To: <20120216224124.GC4578@dan.olp.net> References: <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> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> Date: Thu, 16 Feb 2012 14:57:53 -0800 Message-ID: From: Brandon Long To: Dan White Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlu2QzNxA0a4YpEc0uQilvT1sARB8+HJQO4/dWq0fTbYQg3GvDwtOpajDrtn/Lpnnu4/YE1tdvdSSIh2cNuI4WeW5R69ARBbQTrQNzvxw8l8f9xWEERLCepZxqHJ+xOVsW5SkLs Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:57:55 -0000 On Thu, Feb 16, 2012 at 2:41 PM, Dan White wrote: > However, spam is a problem caused by a deficiency (or whatever you want to > call it) within the smtp protocol. imap does not directly or indirectly lead > to the generation of spam, unless you want to consider backscatter from a > sieve notification to be spam. > > smtp (or submission) is one of those things that's actually easy to > configure in an email client. I fear that if the two get combined on the > same port that imap server IPs may start to get caught up in the cat > and mouse game spam parsers play. IMAP playing the game is no different than SMTP-MSA playing the game, it still requires authentication. I'm not sure how wide-spread it is, but we certainly already have to deal with spam through spammy accounts or hijacked accounts over SMTP-MSA. I find it hard to believe that IMAP doing mail submission is going to change any of that, but perhaps you mean that you would have to have the same smarts for protecting against bad logins in IMAP that you have in SMTP-MSA... but I would expect anyone who's under attack for either already does that as well (we certainly use the same auth backend for both. Brandon From dwhite@olp.net Thu Feb 16 15:29:56 2012 Return-Path: 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 AB02121E8025 for ; Thu, 16 Feb 2012 15:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 fHnlQjeBy6lh for ; Thu, 16 Feb 2012 15:29:56 -0800 (PST) Received: from pinky.olp.net (pinky2.olp.net [67.217.151.213]) by ietfa.amsl.com (Postfix) with ESMTP id 258FC21E801C for ; Thu, 16 Feb 2012 15:29:56 -0800 (PST) Received: from quark.olp.net (vpn.olp.net [67.217.151.100]) by pinky.olp.net (Postfix) with ESMTP id EA631292E5F; Thu, 16 Feb 2012 17:29:54 -0600 (CST) Received: by quark.olp.net (Postfix, from userid 1000) id D18D27B2144; Thu, 16 Feb 2012 17:29:54 -0600 (CST) Date: Thu, 16 Feb 2012 17:29:54 -0600 From: Dan White To: Brandon Long Message-ID: <20120216232954.GB5356@dan.olp.net> References: <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> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-OS: Linux quark 3.0.0-2-amd64 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:29:56 -0000 On 02/16/12 14:57 -0800, Brandon Long wrote: >On Thu, Feb 16, 2012 at 2:41 PM, Dan White wrote: >> However, spam is a problem caused by a deficiency (or whatever you want to >> call it) within the smtp protocol. imap does not directly or indirectly lead >> to the generation of spam, unless you want to consider backscatter from a >> sieve notification to be spam. >> >> smtp (or submission) is one of those things that's actually easy to >> configure in an email client. I fear that if the two get combined on the >> same port that imap server IPs may start to get caught up in the cat >> and mouse game spam parsers play. > >IMAP playing the game is no different than SMTP-MSA playing the game, >it still requires authentication. I'm not sure how wide-spread it is, >but we certainly already have to deal with spam through spammy >accounts or hijacked accounts over SMTP-MSA. I find it hard to >believe that IMAP doing mail submission is going to change any of >that, but perhaps you mean that you would have to have the same smarts >for protecting against bad logins in IMAP that you have in SMTP-MSA... >but I would expect anyone who's under attack for either already does >that as well (we certainly use the same auth backend for both. Separating imap from submission allows those functions to (easily) run on separate servers, like where the smtp server is a black box appliance, which is not uncommon in the service provider or enterprise space. Focussing on changing the mail submission aspect of the picture may introduce unexpected side effects, such as how other providers parse and block your messages (which some do based on client *and/or* relay IP). imap essentially already has its own mail submission component via imap append. Users can trust who sends them messages, and can limit who can send them messages (via enforceable acls). I just wish smtp worked more like that, but that's a pipe dream. -- Dan White From adrien@qbik.com Thu Feb 16 16:52:07 2012 Return-Path: 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 8061321E8083 for ; Thu, 16 Feb 2012 16:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.958 X-Spam-Level: X-Spam-Status: No, score=-3.958 tagged_above=-999 required=5 tests=[AWL=-1.359, 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 q0K7y89XagOB for ; Thu, 16 Feb 2012 16:52:03 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id AB95621E808A for ; Thu, 16 Feb 2012 16:52:02 -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 <0018867439@smtp.qbik.com>; Fri, 17 Feb 2012 13:52:01 +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 <0010060869@sago.qbik.com>; Fri, 17 Feb 2012 13:51:50 +1300 Message-ID: <4F3DA4A6.5020304@qbik.com> Date: Fri, 17 Feb 2012 13:51:50 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dan White References: <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> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> In-Reply-To: <20120216232954.GB5356@dan.olp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 00:52:07 -0000 On 17/02/2012 12:29 p.m., Dan White wrote: > On 02/16/12 14:57 -0800, Brandon Long wrote: >> On Thu, Feb 16, 2012 at 2:41 PM, Dan White wrote: >>> However, spam is a problem caused by a deficiency (or whatever you >>> want to >>> call it) within the smtp protocol. imap does not directly or >>> indirectly lead >>> to the generation of spam, unless you want to consider backscatter >>> from a >>> sieve notification to be spam. >>> >>> smtp (or submission) is one of those things that's actually easy to >>> configure in an email client. I fear that if the two get combined on >>> the >>> same port that imap server IPs may start to get caught up in the cat >>> and mouse game spam parsers play. >> >> IMAP playing the game is no different than SMTP-MSA playing the game, >> it still requires authentication. I'm not sure how wide-spread it is, >> but we certainly already have to deal with spam through spammy >> accounts or hijacked accounts over SMTP-MSA. I find it hard to >> believe that IMAP doing mail submission is going to change any of >> that, but perhaps you mean that you would have to have the same smarts >> for protecting against bad logins in IMAP that you have in SMTP-MSA... >> but I would expect anyone who's under attack for either already does >> that as well (we certainly use the same auth backend for both. > > Separating imap from submission allows those functions to (easily) run on > separate servers, like where the smtp server is a black box appliance, > which is not uncommon in the service provider or enterprise space. > Whichever way you do it, BURL vs SUBMIT, there is an issue of trust if the 2 servers are in different realms. And those issues were addressed in the BURL RFC, and the same security conditions apply. Notwithstanding all of that. It's still easier for a developer to hook up a way for an IMAP server to submit mail to SMTP than it is to hook up SMTP to retrieve IMAP. If the servers are on the same computer, it can be as simple as a file copy. One option would be an extension for submission that would only be available if the SMTP server trusted the IMAP server. That would then avoid the need to smuggle SMTP creds across your IMAP session (c.f. the way that BURL specifies IMAP creds in BURL requests). I think in most organisations this would prove a lot simpler to manage. Certainly a lot simpler to code as a developer. Maybe it should be an optional extension, usable as an alternative to BURL. I'd still be keen on any deployment stats on BURL. > > imap essentially already has its own mail submission component via imap > append. Users can trust who sends them messages, and can limit who can > send > them messages (via enforceable acls). I just wish smtp worked more like > that, but that's a pipe dream. > I don't know how you can use APPEND to send a message to another user unless you share a folder with them. Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From brong@fastmail.fm Thu Feb 16 19:58:08 2012 Return-Path: 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 2837D21E804E for ; Thu, 16 Feb 2012 19:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 B8vFxAY5iHt4 for ; Thu, 16 Feb 2012 19:58:03 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1C521E8056 for ; Thu, 16 Feb 2012 19:58:03 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id ACCCE2069C for ; Thu, 16 Feb 2012 22:58:02 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 16 Feb 2012 22:58:02 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=ywanNmnWevoFJBbRcHDzRg1f NVg=; b=bUmsxi9CLP+Nou5h+kuD27KT2CqwF5HHG3ayIw6A/MaN1kEkH6ddTAUq 3Ur+rOsQLyuptFONBpAd3/JbnuY7d66ggOCQbb2Uxch4h+TBtyHcGwdGQ2w5E7er KX8mrlyqO9mZcUTIEX6ypNWVWC6zyhzia/ldVVIdZYA9SrqoeB8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=ywanNmnWevoFJBbRcHDzRg1fNVg=; b=ucCsscvFNoj/b0vOq79Q3Kmn7sRm uHlI/BRIpuT2bqX4A95s+Xztkw/GJNUKCYxBckzfzuxWVss3LD34JtgkDLp18yqD 68YzFBJ1zZzkOrzxPOn8EIYG8qj/zgO/5AJcySYZsa5gsz/QqWskGYp0/bw8mZrM yU+npzEcMIrd9bo= X-Sasl-enc: ZvufP4P3TlQSgh98A7T0hjF0y9LqA7h7vJcvY1+TharZ 1329451082 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 32BE08E0162; Thu, 16 Feb 2012 22:58:02 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id B40F82260C2; Fri, 17 Feb 2012 04:58:00 +0100 (CET) Date: Fri, 17 Feb 2012 04:58:00 +0100 From: Bron Gondwana To: Mark Crispin Message-ID: <20120217035800.GA25362@launde.brong.net> References: <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> <4F3D6E57.8010301@qbik.com> <20120216223724.GD24183@launde.brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 03:58:08 -0000 On Thu, Feb 16, 2012 at 02:48:41PM -0800, Mark Crispin wrote: > On Thu, 16 Feb 2012, Bron Gondwana wrote: > >>I think the guys that developed SMTP would disagree with you. The > >>reason the envelope is even specified in SMTP rather than the > >>receiver simply scraping them out of the message, is that sometimes > >>you need to deliver a message somewhere other than the To: / bcc: > >>headers. > >Rarely. I don't even know an IMAP client which supports doing that. > > HAHAHAHAHAHAHAHAHAHAHAHAHAHA. I have not heard of this IMAP client. Please provide usage stats to help a determination if it's a significant player that we need to plan around. Thanks, Bron. From vanmeeuwen@kolabsys.com Thu Feb 16 22:17:09 2012 Return-Path: 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 8FF2021F88C6 for ; Thu, 16 Feb 2012 22:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 0g-dyP0n2OgK for ; Thu, 16 Feb 2012 22:17:03 -0800 (PST) Received: from kolab.kolabsys.com (kolab.kolabsys.com [78.46.32.248]) by ietfa.amsl.com (Postfix) with ESMTP id 924EF21F88C2 for ; Thu, 16 Feb 2012 22:17:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kolab.kolabsys.com (Postfix) with ESMTP id 21E4621B9D95 for ; Fri, 17 Feb 2012 07:17:00 +0100 (CET) X-Virus-Scanned: by amavisd-new at kolabsys.com Received: from kolab.kolabsys.com ([127.0.0.1]) by localhost (kolab.kolabsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GefkTC+xVBdZ for ; Fri, 17 Feb 2012 07:16:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by kolab.kolabsys.com (Postfix) with ESMTP id 5372821B9AA1 for ; Fri, 17 Feb 2012 07:16:58 +0100 (CET) Received: from albert.kolabsys.com (unknown [212.183.128.94]) (Authenticated sender: vanmeeuwen@kolabsys.com) by kolab.kolabsys.com (Postfix) with ESMTPSA id F176A21B9D95 for ; Fri, 17 Feb 2012 07:16:57 +0100 (CET) From: Jeroen van Meeuwen To: imap5@ietf.org Date: Fri, 17 Feb 2012 06:16:55 +0000 Message-ID: <2817964.kXiz5QikzJ@albert.kolabsys.com> User-Agent: KMail/4.7.4 (Linux/3.2.5-3.fc16.x86_64; KDE/4.7.4; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [imap5] Considerations from Akonadi/Kontact/Kmail implementers X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 06:17:09 -0000 Hello there, Having attended the KDE PIM development sprint in Osnabrueck last weekend, I wanted to start summarizing the feedback I've gotten so far, from the developers of the KDE PIM stack, responsible for Kontact (Kmail), Akonadi[1] and Nepomuk. This is not the complete feedback, however, and I hope to be able to find ways to have the actual implementors render their own feedback on this list. I'd like to view this feedback in the realm of personal information management, as some things may be workarounds for deficiencies in IMAP4, and other things may just simply not apply (to IMAP4, or even to IMAP5). Also, let me state this is only some initial feedback; Akonadi implements a interface that takes a subset of IMAP4 commands, enhanced to serve its use- cases. I think that's very valuable feedback for the IMAP5 discussion, as it clearly points out what this particular client implementer needs, and what they don't (i.e. what they could do away with in IMAP5, perhaps). First of all, please allow me to illustrate where Akonadi fits in, in relation to Kmail / Kontact. Akonadi is used as the universal storage layer for information aggregated through/from different resources - one of them is an IMAP resource. When the client (Kmail for email) wants to speak IMAP, it speaks a derivative "Almost IMAP" protocol to Akonadi - Akonadi spawns an "IMAP Agent" to get the actual data out of IMAP - which of course speaks IMAP "fluently". Akonadi is also the storage for the other applications wrapped up in Kontact - calendars, contacts, notes, tasks, journals, etc. Obviously, traditionally, an IMAP4 client has had to find another place to store such data. So, in the realm of things they made disappear or want, or that Kolab would like to offer for consideration; - No more selecting any mailboxes in order to allow operations against it. I suppose this mandates all operations use full or relative URIs, such as: C: FETCH "/Folder/Sub-Folder/" and: C: APPEND "/Folder/Sub-Folder/" There's been words about notification systems, possibly using a global UIDVALIDITY / MODSEQ, that I think are a step in the right direction to do away with mailbox-by-mailbox selection to get one's hands on any changes. - Simplification of getting folder properties, including size, MODSEQ/UIDVALIDITY/UIDNEXT and other such metadata on the state, quota(root), ACLs (MYRIGHTS/GETACL simplification), METADATA, etc. - "Fast" synchronization (of selected state changes only) - it's been suggested sometimes a client is only interested in NEW messages, or NEW before any other action(s)/change(s) are communicated (i.e. other actions such as flag changes, deletions, etc.). Please note I think QRESYNC is already supported, but on a mailbox-per-mailbox basis, it's still "slow" and doesn't allow one to get only to NEW messages, for example. - Rather specifically pointing in one direction, but the work that's been done by Opera on conversations is very interesting to the Kontact client developers. - The concept of "local" subscriptions could be translated into a mechanism that allows a client to subscribe to notifications on changes on explicit (sets of) folders. Right now, there seems to be a variety of selectors; a) server-side subscriptions, which is only ever one list, b) namespaces (INBOX/, user/, shared/, if you will), c) "local" subscriptions - where the client is configured to ignore certain folders when pulling down the data. One can imagine one's Archive/* folders need to be available in a web mailer, but not on a mobile device, for example. - Access to different data than only traditional email, specifically items that relate to groupware, such as (but not limited to) calendaring and contacts. This is currently being performed with xcal/xcard attachments to RFC822 messages. I think Calendaring and Contacts are first on the list of things a "IMAP user" would want to see included. - The requirements for client-side (full-text) search are currently implemented using Nepomuk/Strigli, the interface/indexer, after having obtained the original information from these messages (and decoding any base64 or other encoding that is done in order to be able to store as attachments). - In light of projects, tasks, journal and notes, it is thought that conversations (again) can be used / abused to build (on the client side) the desired relationship trees between the various components within a project (i.e. tasks, events, contacts, journal and notes, thus building "projects"). - It's also been considered that a good client protocol library might be helpful. I'm not sure what this would look like exactly, but I suppose such library would take away a little of the protocol parameter(s) syntax complexity. Bonus points, of course, if bindings for various languages could be generated on top of such library. Kind regards, Jeroen van Meeuwen [1] http://community.kde.org/KDE_PIM/Akonadi -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 From arnt@gulbrandsen.priv.no Fri Feb 17 01:10:19 2012 Return-Path: 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 0EA4321F868C for ; Fri, 17 Feb 2012 01:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 BRr+AYGuPpoD for ; Fri, 17 Feb 2012 01:10:17 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id BA23421F8828 for ; Fri, 17 Feb 2012 01:10:17 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4B7E5F8C967; Fri, 17 Feb 2012 09:10:13 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1329469812-12558-12558/10/25; Fri, 17 Feb 2012 09:10:12 +0000 Message-Id: <4F3E1999.4050703@gulbrandsen.priv.no> Date: Fri, 17 Feb 2012 10:10:49 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <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> <4F3D6E57.8010301@qbik.com> <20120216223724.GD24183@launde.brong.net> In-Reply-To: <20120216223724.GD24183@launde.brong.net> Content-Type: text/plain; charset=iso-8859-1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 09:10:19 -0000 On 02/16/2012 11:37 PM, Bron Gondwana wrote: >> I think the guys that developed SMTP would disagree with you. The >> reason the envelope is even specified in SMTP rather than the >> receiver simply scraping them out of the message, is that sometimes >> you need to deliver a message somewhere other than the To: / bcc: >> headers. > > Rarely. I don't even know an IMAP client which supports doing that. Some remove Bcc themselves, or never add it. That is, even though the word 'Bcc' may be visible onscreen, it does not occur in the submitted message. Arnt From jkt@flaska.net Fri Feb 17 02:15:29 2012 Return-Path: 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 0D0F921F889E for ; Fri, 17 Feb 2012 02:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 ZUuR0ksvupTZ for ; Fri, 17 Feb 2012 02:15:28 -0800 (PST) Received: from serv132.fzu.cz (serv132.fzu.cz [147.231.26.132]) by ietfa.amsl.com (Postfix) with ESMTP id CF2C821F8732 for ; Fri, 17 Feb 2012 02:15:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4DAFooPk+T5xpZgWdsb2JhbABDhRircCIBARYmJ4F1AQEFI1URCxgJFgsCAgkDAgECAUUTCAEBtBKKDYlAglsEOxMDAQKDQwEgAS6CCIEWBI5OgRuFTpJpgVs X-IronPort-AV: E=Sophos;i="4.73,435,1325458800"; d="asc'?scan'208";a="4608953" Received: from freja.fzu.cz ([147.231.26.89]) by serv147.fzu.cz with ESMTP; 17 Feb 2012 11:15:24 +0100 Received: from svist.flaska.net (wireless-108.fi.muni.cz [147.251.51.108]) by freja.fzu.cz (Postfix) with ESMTPSA id AC6143DA82 for ; Fri, 17 Feb 2012 11:15:24 +0100 (CET) Message-ID: <4F3E28BB.8070607@flaska.net> Date: Fri, 17 Feb 2012 11:15:23 +0100 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imap5@ietf.org References: <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> <4F3D6E57.8010301@qbik.com> <20120216223724.GD24183@launde.brong.net> In-Reply-To: <20120216223724.GD24183@launde.brong.net> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEAEC9D8D9B86195B32F79125" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 10:15:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEAEC9D8D9B86195B32F79125 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/16/12 23:37, Bron Gondwana wrote: > Rarely. I don't even know an IMAP client which supports doing that. > It's not like SMTP would disappear if you need something more complex. Even Thunderbird supports this, although through an extension nowadays ("Redirect Mail" IIRC). Unless I'm mistaken, they used to support it out-of-the-box in the TB 2.x series. You're probably right that "most people" have never used it, but it's a feature that's here for a good reason and could be useful, IMHO. Cheers, -jkt --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enigEAEC9D8D9B86195B32F79125 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8+KLsACgkQamXfqERyJRfwJQCeJZW0mvVmO9Mn5DONZ7pBptQS 4QIAn3GAQ0mTfwwrm+wRm4lKMnIgWQj2 =A6ij -----END PGP SIGNATURE----- --------------enigEAEC9D8D9B86195B32F79125-- From fanf2@hermes.cam.ac.uk Fri Feb 17 03:30:47 2012 Return-Path: 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 016CD21F873E for ; Fri, 17 Feb 2012 03:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 nuA3kLJPRaTI for ; Fri, 17 Feb 2012 03:30:45 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6336421F8738 for ; Fri, 17 Feb 2012 03:30:45 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:47351) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1RyM1Q-00016S-pt (Exim 4.72) (return-path ); Fri, 17 Feb 2012 11:30:40 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RyM1Q-0006FO-17 (Exim 4.67) (return-path ); Fri, 17 Feb 2012 11:30:40 +0000 Date: Fri, 17 Feb 2012 11:30:40 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Adrien de Croy In-Reply-To: <4F3D6E57.8010301@qbik.com> Message-ID: References: <20120213210805.GB13029@launde.brong.net><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><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> <4F3D6E57.8010301@qbik.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:30:47 -0000 Adrien de Croy wrote: > > I think the guys that developed SMTP would disagree with you. The reason the > envelope is even specified in SMTP rather than the receiver simply scraping > them out of the message, is that sometimes you need to deliver a message > somewhere other than the To: / bcc: headers. I don't believe that is true for message submission. See the discussion in RCF 5322 about how the BCC header can turned into a message envelope (or in some cases, several). Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle: Southwest 6 to gale 8, veering northwest 7 to severe gale 9, perhaps storm 10 later. Very rough or high. Rain or squally showers, wintry later. Good, occasionally poor. From fanf2@hermes.cam.ac.uk Fri Feb 17 07:36:20 2012 Return-Path: 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 9126721F85EC for ; Fri, 17 Feb 2012 07:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rdHXaa1ywATQ for ; Fri, 17 Feb 2012 07:36:19 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 45B0521F85BD for ; Fri, 17 Feb 2012 07:36:19 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49685) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1RyPr3-0003bM-Ea (Exim 4.72) (return-path ); Fri, 17 Feb 2012 15:36:13 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RyPr3-0006PI-FS (Exim 4.67) (return-path ); Fri, 17 Feb 2012 15:36:13 +0000 Date: Fri, 17 Feb 2012 15:36:13 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Adrien de Croy In-Reply-To: <4F3DA4A6.5020304@qbik.com> Message-ID: References: <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> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:36:20 -0000 Adrien de Croy wrote: > > Whichever way you do it, BURL vs SUBMIT, there is an issue of trust if the 2 > servers are in different realms. I don't think that setup is worth supporting in a simplified protocol. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire, South Utsire: Westerly 5 or 6, backing southwesterly 5 to 7, perhaps gale 8 later in Viking. Rough, occasionally very rough in Viking and North Utsire. Rain or squally showers. Good, occasionally poor. From fanf2@hermes.cam.ac.uk Fri Feb 17 07:37:12 2012 Return-Path: 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 35A7621F86C2 for ; Fri, 17 Feb 2012 07:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 32QR2WHqf89F for ; Fri, 17 Feb 2012 07:37:09 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 6C20521F86AD for ; Fri, 17 Feb 2012 07:37:09 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49925) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1RyPrw-0003yi-Du (Exim 4.72) (return-path ); Fri, 17 Feb 2012 15:37:08 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RyPrw-0006aW-8p (Exim 4.67) (return-path ); Fri, 17 Feb 2012 15:37:08 +0000 Date: Fri, 17 Feb 2012 15:37:08 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: =?ISO-8859-15?Q?Jan_Kundr=E1t?= In-Reply-To: <4F3E28BB.8070607@flaska.net> Message-ID: References: <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> <4F3D6E57.8010301@qbik.com> <20120216223724.GD24183@launde.brong.net> <4F3E28BB.8070607@flaska.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-1056532732-1329493028=:30682" Sender: Tony Finch Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:37:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870024-1056532732-1329493028=:30682 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Jan Kundr=C3=A1t wrote: > > Even Thunderbird supports this, although through an extension nowadays > ("Redirect Mail" IIRC). Unless I'm mistaken, they used to support it > out-of-the-box in the TB 2.x series. That's what the Resent-* headers are for. Tony. --=20 f.anthony.n.finch http://dotat.at/ Trafalgar: Northeasterly 5 or 6, becoming variable 4. Moderate or rough. Fa= ir. Good. --1870870024-1056532732-1329493028=:30682-- From dwhite@olp.net Fri Feb 17 09:15:00 2012 Return-Path: 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 496C221F853D for ; Fri, 17 Feb 2012 09:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 nURhHPxnPHFH for ; Fri, 17 Feb 2012 09:14:59 -0800 (PST) Received: from pinky.olp.net (pinky2.olp.net [67.217.151.213]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6D21F853B for ; Fri, 17 Feb 2012 09:14:59 -0800 (PST) Received: from quark.olp.net (vpn.olp.net [67.217.151.100]) by pinky.olp.net (Postfix) with ESMTP id BF7E0292D8D; Fri, 17 Feb 2012 11:14:57 -0600 (CST) Received: by quark.olp.net (Postfix, from userid 1000) id AFECC7B2144; Fri, 17 Feb 2012 11:14:57 -0600 (CST) Date: Fri, 17 Feb 2012 11:14:57 -0600 From: Dan White To: Adrien de Croy Message-ID: <20120217171457.GB4503@dan.olp.net> References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F3DA4A6.5020304@qbik.com> X-OS: Linux quark 3.0.0-2-amd64 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:15:00 -0000 On 02/17/12 13:51 +1300, Adrien de Croy wrote: >>imap essentially already has its own mail submission component via imap >>append. Users can trust who sends them messages, and can limit who can >>send them messages (via enforceable acls). I just wish smtp worked more >>like that, but that's a pipe dream. >> > >I don't know how you can use APPEND to send a message to another user >unless you share a folder with them. That's exactly what I want. I want to configure my ACLs to allow specific users to connect via IMAP (or an SMTP replacement). If someone wants to send me a message, their client connects directly to my server (why is relay still necessary?). They authenticate over sasl using some fancy federated authentication protocol (project moonshot) before being allowed to post to my inbox. 1) The need for submission-and-relay goes away. 2) I can trust the identity of who's sending me a message. 3) I can fiddle with my acls bits to determine who I want to get messages from. When relay is *really* necessary, sasl authorization to allow servers to act on behalf of domains/users should do the trick. In my opinion (and I admit I'm getting off topic), spam is merely a problem rooted in relay. -- Dan White From brong@fastmail.fm Fri Feb 17 11:41:06 2012 Return-Path: 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 8B42921F868A for ; Fri, 17 Feb 2012 11:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 yA17whJ1JHoO for ; Fri, 17 Feb 2012 11:41:05 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id A61D621F8688 for ; Fri, 17 Feb 2012 11:41:05 -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 1BCC0212DE for ; Fri, 17 Feb 2012 14:41:01 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 17 Feb 2012 14:41:01 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=D5r6ArzfUj/HReLQxhFOEIUU kKY=; b=bh4baw/SvMKIy7a0BE4VPDLCVddQ48VCPgc1LVLMesg/b6EZkv2ujJIu HRjGZ3FZDul8yob+3ROOgWdxr8Q5WyQtopytXTizuwH0lKS7VoCcnCKxeltMMNra i4Qunwl2ElEGLdxv+yGcDbmF5I1sK/WwNhfKHX1WSjKd6IDU9ww= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=D5r6ArzfUj/HReLQxhFOEIUUkKY=; b=KlcE3YGZ2ylNRS36rZsyb8/WhXVA Umnt25egljLMPgTLmm/MrscJWST5BxIxLM+gbwhXleUHGWesprABj0YG4lLNnFXK pwT5efZNDdIuibBfbTFzBsHq4vbTcCcR527zJH+NFQPRVODdBieFX136Mg1gn4Rg L2oDTXbiAU5/cn4= X-Sasl-enc: Y8qnjaZTmSQnqb9pw9EkKoccqL2Ycw8/9e3f1czTH9i8 1329507660 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id C974C4824D6; Fri, 17 Feb 2012 14:41:00 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 870E71EAD3F; Fri, 17 Feb 2012 20:40:59 +0100 (CET) Date: Fri, 17 Feb 2012 20:40:59 +0100 From: Bron Gondwana To: Dan White Message-ID: <20120217194059.GC32490@launde.brong.net> References: <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120217171457.GB4503@dan.olp.net> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:41:06 -0000 On Fri, Feb 17, 2012 at 11:14:57AM -0600, Dan White wrote: > That's exactly what I want. I want to configure my ACLs to allow specific > users to connect via IMAP (or an SMTP replacement). If someone wants to > send me a message, their client connects directly to my server (why is > relay still necessary?). They authenticate over sasl using some fancy > federated authentication protocol (project moonshot) before being allowed > to post to my inbox. > > 1) The need for submission-and-relay goes away. > 2) I can trust the identity of who's sending me a message. > 3) I can fiddle with my acls bits to determine who I want to get messages > from. > > When relay is *really* necessary, sasl authorization to allow servers to > act on behalf of domains/users should do the trick. > > In my opinion (and I admit I'm getting off topic), spam is merely a problem > rooted in relay. You have an excellent point that unavailable endpoints and incomplete routing really are almost entirely a thing of the past. There are still some network structures where things aren't directly connected to the world, but IPv6 should solve the remaining routability issues. BUT - for me at least, I don't want to solve this problem. It's a massive problem for sure. I'm not interested in your "point 3" though. It puts the administrative burden of adding every webshop I've ever used to my whitelist on to me. Sure it may be technically feasible - but it's just not the pain point that _I_ am feeling, so it's not in my vision of a replacement protocol for IMAP. I'm purely concerned with communications between the user agent and their remote data store/server. Bron. (in this theoretical world you could talk direct SUBMISSION to the remote users' servers and not even involve your IMAP$n server at all, given a federated authentication) From dwhite@olp.net Fri Feb 17 12:05:51 2012 Return-Path: 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 2AEBE21E8076 for ; Fri, 17 Feb 2012 12:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_41=0.6, 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 9-CU8fz1iXIX for ; Fri, 17 Feb 2012 12:05:50 -0800 (PST) Received: from pinky.olp.net (pinky2.olp.net [67.217.151.213]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA0D21E8073 for ; Fri, 17 Feb 2012 12:05:50 -0800 (PST) Received: from quark.olp.net (vpn.olp.net [67.217.151.100]) by pinky.olp.net (Postfix) with ESMTP id C83AE292E04; Fri, 17 Feb 2012 14:05:47 -0600 (CST) Received: by quark.olp.net (Postfix, from userid 1000) id B5C0F7B2144; Fri, 17 Feb 2012 14:05:47 -0600 (CST) Date: Fri, 17 Feb 2012 14:05:47 -0600 From: Dan White To: Bron Gondwana Message-ID: <20120217200547.GB6908@dan.olp.net> References: <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> <20120217194059.GC32490@launde.brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120217194059.GC32490@launde.brong.net> X-OS: Linux quark 3.0.0-2-amd64 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:05:51 -0000 On 02/17/12 20:40 +0100, Bron Gondwana wrote: >On Fri, Feb 17, 2012 at 11:14:57AM -0600, Dan White wrote: >> That's exactly what I want. I want to configure my ACLs to allow specific >> users to connect via IMAP (or an SMTP replacement). If someone wants to >> send me a message, their client connects directly to my server (why is >> relay still necessary?). They authenticate over sasl using some fancy >> federated authentication protocol (project moonshot) before being allowed >> to post to my inbox. >> >> 1) The need for submission-and-relay goes away. >> 2) I can trust the identity of who's sending me a message. >> 3) I can fiddle with my acls bits to determine who I want to get messages >> from. >> >> When relay is *really* necessary, sasl authorization to allow servers to >> act on behalf of domains/users should do the trick. >> >> In my opinion (and I admit I'm getting off topic), spam is merely a problem >> rooted in relay. > >You have an excellent point that unavailable endpoints and incomplete >routing really are almost entirely a thing of the past. There are still >some network structures where things aren't directly connected to the world, >but IPv6 should solve the remaining routability issues. I don't think the disconnected state really matters. The email could just sit in a local queue until it's reconnected to the network, at which point it could be send directly to the recipient's lmtp server (which makes better sense than direct imap, now that I think about it). >BUT - for me at least, I don't want to solve this problem. It's a massive >problem for sure. I'm not interested in your "point 3" though. It puts the >administrative burden of adding every webshop I've ever used to my whitelist >on to me. It's the same burden that Facebook users have, and points to the advantage that Facebook and Facebook like services have, one in which they have perfect knowledge of who's sending messages to who. It makes stopping spam a lot easier. I suppose someone you don't know could send you 10,000 invites, but Facebook will just deliver one of those. Or one of your friends goes crazy and annoys you will 100 messages, as which point you remove them from your list. Are the younger folks coming up today going to use email if the spam problem isn't solved? I doubt it. SMS and Facebook seem to suit most folks under age X (where X will continue to increase linearly over time). imap, smtp, and even exchange are pretty much doomed to role of legacy enterprise application if that continues. >Sure it may be technically feasible - but it's just not the pain point that >_I_ am feeling, so it's not in my vision of a replacement protocol for IMAP. >I'm purely concerned with communications between the user agent and their >remote data store/server. > >Bron. > >(in this theoretical world you could talk direct SUBMISSION to the remote > users' servers and not even involve your IMAP$n server at all, given a > federated authentication) I don't really even think there needs to be a change to the basic imap/lmtp specifications to support my grandios plan for eradicating spam (although I'm far from the first to have such a light bulb go off). As soon as the appropriate sasl mechanisms are in place to support some federated authentication (think authentication against Facebook), then all that's left is to improve ACL support in servers and clients. Simple matter... -- Dan White From mrc+ietf@panda.com Fri Feb 17 13:11:09 2012 Return-Path: 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 3767321F85FD for ; Fri, 17 Feb 2012 13:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 EOEphH0FwxpL for ; Fri, 17 Feb 2012 13:10:56 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0233621F85F6 for ; Fri, 17 Feb 2012 13:10:50 -0800 (PST) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Fri, 17 Feb 2012 13:10:39 -0800 X-MailFrom: mrc+ietf@panda.com Date: Fri, 17 Feb 2012 13:10:37 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Dan White In-Reply-To: <20120217200547.GB6908@dan.olp.net> Message-ID: References: <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> <20120217194059.GC32490@launde.brong.net> <20120217200547.GB6908@dan.olp.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:11:09 -0000 On Fri, 17 Feb 2012, Dan White wrote: > I don't think the disconnected state really matters. The email could just > sit in a local queue until it's reconnected to the network, at which point > it could be send directly to the recipient's lmtp server (which makes > better sense than direct imap, now that I think about it). What if the network you are on requires you to use their servers, and enforces that requirement through various evil means? Their policy may allow external traffic going in, even from a remote IMAP server, but not out. They even put themselves as a MITM on SSL/TLS (not that anyone pays attention to cert validation messages anyway). Outgoing email security: it's not just for totalitarian dictatorships any more. > Are the younger folks coming up today going to use email if the spam > problem isn't solved? I doubt it. SMS and Facebook seem to suit most folks > under age X (where X will continue to increase linearly over time). I doubt that they will use email in any case. There is simply no compelling reason for them to do so. > imap, smtp, and even exchange are pretty much doomed to role of legacy > enterprise application if that continues. I agree with this statement other than the word "legacy". Email originated as an enterprise application and was designed as to be an enterprise application. To date, nothing has filled that niche. Attempts to create FB-style applications for the enterprise have not done well. One problem is that enterprises are reluctant to turn internal data over to "the cloud". Those that have done so (primarily academia) are in the process of learning some hard lessons. > I don't really even think there needs to be a change to the basic imap/lmtp > specifications to support my grandios plan for eradicating spam (although > I'm far from the first to have such a light bulb go off). This is a definite "well, duh!" statement. You are correct; eliminating spam is not a correct motivation. > As soon as the > appropriate sasl mechanisms are in place to support some federated > authentication (think authentication against Facebook), then all that's > left is to improve ACL support in servers and clients. Simple matter... "Small matter of programming". -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From brong@fastmail.fm Fri Feb 17 13:31:11 2012 Return-Path: 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 9B12711E8098 for ; Fri, 17 Feb 2012 13:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.257 X-Spam-Level: X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 nR5hHrFlzMA6 for ; Fri, 17 Feb 2012 13:31:10 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id A88F911E808D for ; Fri, 17 Feb 2012 13:31:10 -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 4EF93212BA for ; Fri, 17 Feb 2012 16:31:10 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 17 Feb 2012 16:31:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=mesmtp; bh=xNPm5H8vmtTK0bpavUN0IeWoTaQ=; b=pfVx4KSWKfY3L8IQKG6IHiWNGRsn 5TbP8zWW/eBCZ4qhmv1ddKiErGHIq6K6xJ2Q5CLzyKJ+6O+2tqgocnUNS+Akcvn/ Zksp1cR8GTULa9lQoLzG0Y50gjgajA3z2F4Z+g5kcy9qVJe69fSxWvWWe81w6FF8 BmkQbv1SOE+93Fg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:content-transfer-encoding :in-reply-to; s=smtpout; bh=xNPm5H8vmtTK0bpavUN0IeWoTaQ=; b=nGAL 7rDvCT2WR6pPTrZpzGEYyiN65XQQ+iaHYTorr/L1fTCQm1/mgHluLC+8OBoZT32s gS8FMpuvfq04iAiJsZg78M6WM+p6gKdsVvrXwTUorYMbIuA5wTwlbI7G+wNE3TgC UEyv4VqUq9bvpmDIQGKv1Lif2vqiDAQx27nukt4= X-Sasl-enc: f5YfTRPYCW48vfAgKk64zEJ9tRX5awj8bHDZ7hJXtYmA 1329514269 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id E01A64824D6; Fri, 17 Feb 2012 16:31:09 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 615D22260D3; Fri, 17 Feb 2012 22:31:08 +0100 (CET) Date: Fri, 17 Feb 2012 22:31:08 +0100 From: Bron Gondwana To: Dan White Message-ID: <20120217213108.GA1084@launde.brong.net> References: <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> <20120217194059.GC32490@launde.brong.net> <20120217200547.GB6908@dan.olp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120217200547.GB6908@dan.olp.net> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:31:11 -0000 On Fri, Feb 17, 2012 at 02:05:47PM -0600, Dan White wrote: > On 02/17/12 20:40 +0100, Bron Gondwana wrote: > >You have an excellent point that unavailable endpoints and incomplete > >routing really are almost entirely a thing of the past. There are still > >some network structures where things aren't directly connected to the world, > >but IPv6 should solve the remaining routability issues. > > I don't think the disconnected state really matters. The email could just > sit in a local queue until it's reconnected to the network, at which point > it could be send directly to the recipient's lmtp server (which makes > better sense than direct imap, now that I think about it). Not if you want to solve non-delivery notifications as well. Otherwise, store and forward isn't too bad. I'd love if it had a return path all the way through, so each intermediate didn't delete its local copy until EVERYONE had confirmed it to the destination. It would help with retryability too. But that depends on Message-Id being not played fast-and-loose with, and that boat sailed :( > >BUT - for me at least, I don't want to solve this problem. It's a massive > >problem for sure. I'm not interested in your "point 3" though. It puts the > >administrative burden of adding every webshop I've ever used to my whitelist > >on to me. > > It's the same burden that Facebook users have, and points to the advantage > that Facebook and Facebook like services have, one in which they have > perfect knowledge of who's sending messages to who. It makes stopping spam > a lot easier. I suppose someone you don't know could send you 10,000 > invites, but Facebook will just deliver one of those. Or one of your > friends goes crazy and annoys you will 100 messages, as which point you > remove them from your list. I know. > Are the younger folks coming up today going to use email if the spam > problem isn't solved? I doubt it. SMS and Facebook seem to suit most folks > under age X (where X will continue to increase linearly over time). I have a whole talk about this that I've given a couple of times now. I think there are slides online from at least one set of it. Basically, "social networks are good for fun, email is for serious stuff". I pointed out that I have code from 10 years ago, and emails from even longer than that, that still works pefectly. I can still access it all. No "404", no "lost in a site redesign into a new timeline", no "deleted by sender". It's my copy, and it's immutable. In other words, it behaves a lot more like a piece of paper. I use facebook for social stuff - but I email copies of our internal IRC logs to myself, and all my instant messaging chats - because once it's in email, it's accessible everywhere, it's searchable, and it doesn't disappear. > imap, smtp, and even exchange are pretty much doomed to role of legacy > enterprise application if that continues. That's definitely a concern. > >(in this theoretical world you could talk direct SUBMISSION to the remote > >users' servers and not even involve your IMAP$n server at all, given a > >federated authentication) > > I don't really even think there needs to be a change to the basic imap/lmtp > specifications to support my grandios plan for eradicating spam (although > I'm far from the first to have such a light bulb go off). As soon as the > appropriate sasl mechanisms are in place to support some federated > authentication (think authentication against Facebook), then all that's > left is to improve ACL support in servers and clients. Simple matter... Heh. Go for it. I'll support your crusade, but I won't lead the charge on this one. Client/Server is my baby. Bron. From brong@fastmail.fm Fri Feb 17 13:35:27 2012 Return-Path: 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 A130521F85CF for ; Fri, 17 Feb 2012 13:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 fjFGygun-bJT for ; Fri, 17 Feb 2012 13:35:26 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id BBAF421F85CD for ; Fri, 17 Feb 2012 13:35:26 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6AFAD210E3 for ; Fri, 17 Feb 2012 16:35:26 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 17 Feb 2012 16:35:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=2wVIKiCOPX8GxQs47yHCVJNF Npk=; b=QafcBJxl/ReTGtBik//Zu4io95DykKiiuw4aD+uSByTgk2B3rYDvtu5T a+rzf6zDCfue71I/C0bxROkEsjvCJwe4JuS9G1onA9YmWQRcT3uYJLoChwGT35TL EyftfL8yVQ+qBoFmSZiI2i1GcpfxV4Ys4GOg4rNe8mcI/Y89JCo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=2wVIKiCOPX8GxQs47yHCVJNFNpk=; b=EQTwO9ALQezaBKDtVfZg+IR6+6t0 v2XxmZ4lA+moRKmyA9teTIRPqSKrrI/S+YyzaK/jv9C/Q4vsBqzhcphal/S9Bzl4 Ef54cdqJtGrnKdWlqMqMr0/kP6YmSzuXU4KTlTRr3ACnMFmbgKgumVoFCspxkeYW QNSbj0Xyu2pc5CM= X-Sasl-enc: HMLSBKzD2IWDd/HjS1k9uEAFP2FXM/Im7ql3xigGXCSe 1329514526 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 209178E00D5; Fri, 17 Feb 2012 16:35:26 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id B26DA2260D2; Fri, 17 Feb 2012 22:35:24 +0100 (CET) Date: Fri, 17 Feb 2012 22:35:24 +0100 From: Bron Gondwana To: Mark Crispin Message-ID: <20120217213524.GB1084@launde.brong.net> References: <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> <20120217194059.GC32490@launde.brong.net> <20120217200547.GB6908@dan.olp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:35:27 -0000 On Fri, Feb 17, 2012 at 01:10:37PM -0800, Mark Crispin wrote: > On Fri, 17 Feb 2012, Dan White wrote: > >I don't think the disconnected state really matters. The email could just > >sit in a local queue until it's reconnected to the network, at which point > >it could be send directly to the recipient's lmtp server (which makes > >better sense than direct imap, now that I think about it). > > What if the network you are on requires you to use their servers, and > enforces that requirement through various evil means? Their policy may > allow external traffic going in, even from a remote IMAP server, but not > out. They even put themselves as a MITM on SSL/TLS (not that anyone pays > attention to cert validation messages anyway). Sounds pretty easy to do with a nice proxyable protocol, they just block it, and you need to use a client which supports sending to an SMTP server. Hopefully a relatively rare case. Rarely enough, I agree with the rest of what you said, so I won't leave it inline with a bunch of m3t00. Bron. From adrien@qbik.com Fri Feb 17 23:12:43 2012 Return-Path: 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 0AA4D21F85CD for ; Fri, 17 Feb 2012 23:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.928 X-Spam-Level: X-Spam-Status: No, score=-3.928 tagged_above=-999 required=5 tests=[AWL=-1.329, 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 DTVj3akhXDTl for ; Fri, 17 Feb 2012 23:12:42 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 97DEB21F85C5 for ; Fri, 17 Feb 2012 23:12:39 -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 3381)) with SMTP id <0018869568@smtp.qbik.com>; Sat, 18 Feb 2012 20:12:35 +1300 Message-ID: <4F3F4F63.5070706@qbik.com> Date: Sat, 18 Feb 2012 20:12:35 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Tony Finch References: <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> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 07:12:43 -0000 On 18/02/2012 4:36 a.m., Tony Finch wrote: > Adrien de Croy wrote: >> Whichever way you do it, BURL vs SUBMIT, there is an issue of trust if the 2 >> servers are in different realms. > I don't think that setup is worth supporting in a simplified protocol. I agree. If a remote SMTP Server needs to be used for submission, then the IMAP server can be configured with some creds it can use for all submissions from all clients. > > Tony. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From adrien@qbik.com Fri Feb 17 23:13:23 2012 Return-Path: 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 9936221F85C6 for ; Fri, 17 Feb 2012 23:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-1.300, 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 8DNk-17eeJ1D for ; Fri, 17 Feb 2012 23:13:23 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9766021F85C4 for ; Fri, 17 Feb 2012 23:13:20 -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 3381)) with SMTP id <0018869570@smtp.qbik.com>; Sat, 18 Feb 2012 20:13:19 +1300 Message-ID: <4F3F4F8F.3040601@qbik.com> Date: Sat, 18 Feb 2012 20:13:19 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Tony Finch References: <20120213210805.GB13029@launde.brong.net><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><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> <4F3D6E57.8010301@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 07:13:24 -0000 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. On 18/02/2012 12:30 a.m., Tony Finch wrote: > Adrien de Croy wrote: >> I think the guys that developed SMTP would disagree with you. The reason the >> envelope is even specified in SMTP rather than the receiver simply scraping >> them out of the message, is that sometimes you need to deliver a message >> somewhere other than the To: / bcc: headers. > I don't believe that is true for message submission. See the discussion in > RCF 5322 about how the BCC header can turned into a message envelope (or > in some cases, several). > > Tony. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From adrien@qbik.com Fri Feb 17 23:14:21 2012 Return-Path: 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 BCA9D21F860E for ; Fri, 17 Feb 2012 23:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=-2.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457] 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 h68IL5KYgnCl for ; Fri, 17 Feb 2012 23:14:21 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 939BC21F84CE for ; Fri, 17 Feb 2012 23:14:09 -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 3381)) with SMTP id <0018869572@smtp.qbik.com>; Sat, 18 Feb 2012 20:14:08 +1300 Message-ID: <4F3F4FC0.1000905@qbik.com> Date: Sat, 18 Feb 2012 20:14:08 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= References: <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> <4F3D6E57.8010301@qbik.com> <20120216223724.GD24183@launde.brong.net> <4F3E28BB.8070607@flaska.net> In-Reply-To: <4F3E28BB.8070607@flaska.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 07:14:21 -0000
the use case I'm thinking of is when you want to forward a message to someone after it was already sent to someone else.


On 17/02/2012 11:15 p.m., Jan Kundrát wrote: 
On 02/16/12 23:37, Bron Gondwana wrote:

Rarely.  I don't even know an IMAP client which supports doing that.
It's not like SMTP would disappear if you need something more complex.

Even Thunderbird supports this, although through an extension nowadays
("Redirect Mail" IIRC). Unless I'm mistaken, they used to support it
out-of-the-box in the TB 2.x series.

You're probably right that "most people" have never used it, but it's a
feature that's here for a good reason and could be useful, IMHO.

Cheers,
-jkt




_______________________________________________
imap5 mailing list
imap5@ietf.org
https://www.ietf.org/mailman/listinfo/imap5


-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
From adrien@qbik.com Fri Feb 17 23:24:38 2012 Return-Path: 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 AC28921F8699 for ; Fri, 17 Feb 2012 23:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.826 X-Spam-Level: X-Spam-Status: No, score=-3.826 tagged_above=-999 required=5 tests=[AWL=-1.227, 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 eAKlc7uj0ycO for ; Fri, 17 Feb 2012 23:24:38 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9133721F852B for ; Fri, 17 Feb 2012 23:24:37 -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 3381)) with SMTP id <0018869579@smtp.qbik.com>; Sat, 18 Feb 2012 20:24:36 +1300 Message-ID: <4F3F5234.2080406@qbik.com> Date: Sat, 18 Feb 2012 20:24:36 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dan White References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> In-Reply-To: <20120217171457.GB4503@dan.olp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 07:24:38 -0000 On 18/02/2012 6:14 a.m., Dan White wrote: > On 02/17/12 13:51 +1300, Adrien de Croy wrote: >>> imap essentially already has its own mail submission component via imap >>> append. Users can trust who sends them messages, and can limit who can >>> send them messages (via enforceable acls). I just wish smtp worked more >>> like that, but that's a pipe dream. >>> >> >> I don't know how you can use APPEND to send a message to another user >> unless you share a folder with them. > > That's exactly what I want. I want to configure my ACLs to allow specific > users to connect via IMAP (or an SMTP replacement). If someone wants to > send me a message, their client connects directly to my server (why is > relay still necessary?). in some parts of the world dialup is still prevalent. We can't presume everyone has a full time internet connection. If the sender and receiver are both in this category, (which is common in such places) then finding an intersection in times for delivery if we only have end-to-end delivery could result in significant delays. Therefore store-and-forward is required. > They authenticate over sasl using some fancy > federated authentication protocol (project moonshot) before being allowed > to post to my inbox. Personally I'd be tempted to mandate use of X.509 (SSL) client certs and TLS. Citizens and organisations of a country would have certs which were issued and vouched for by their government. Every submitter into the secure mail system would require a cert, and abusers would have their cert revoked (and be fined/punished). ISPs could vouch for clients, but could have their cert revoked if they supported spammers. > 1) The need for submission-and-relay goes away. > 2) I can trust the identity of who's sending me a message. > 3) I can fiddle with my acls bits to determine who I want to get messages > from. > > When relay is *really* necessary, sasl authorization to allow servers to > act on behalf of domains/users should do the trick. > > In my opinion (and I admit I'm getting off topic), spam is merely a > problem > rooted in relay. > I believe it's rooted in the lack of responsibility. Responsibility for the actions of a mail sender is not enforced. Computers can't be tried and sent to jail. They can't be responsible for their actions. Only humans can. So the concept of a computer doing something where no person holds responsibility for it is nonsensical. To hold someone accountable for an action of a computer, that person must be identifiable as the sponsor of the action. Certificates can do that. Hence government involvement, since governments are the organisations responsible for establishing the identity of their citizens. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From brong@fastmail.fm Fri Feb 17 23:36:20 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 To: Adrien de Croy , Tony Finch MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <20120213210805.GB13029@launde.brong.net><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><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> <4F3D6E57.8010301@qbik.com> <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." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From giovanni@panozzo.it Fri Feb 17 23:45:21 2012 Return-Path: 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 8D00C21E8014 for ; Fri, 17 Feb 2012 23:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, FUZZY_AMBIEN=1.026, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 0GzCMqaiiIgQ for ; Fri, 17 Feb 2012 23:45:20 -0800 (PST) Received: from do2.yuu.it (do2.yuu.it [46.37.9.250]) by ietfa.amsl.com (Postfix) with ESMTP id 64C9921F851D for ; Fri, 17 Feb 2012 23:45:20 -0800 (PST) Received: from [192.168.56.43] (nav-01.panozzo.it [88.149.172.182]) by do2.yuu.it (Postfix) with ESMTPSA id 3C88180359 for ; Sat, 18 Feb 2012 08:45:05 +0100 (CET) Message-ID: <4F3F570D.9010903@panozzo.it> Date: Sat, 18 Feb 2012 08:45:17 +0100 From: Giovanni Panozzo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: imap5@ietf.org References: <4F3F56E7.3080004@panozzo.it> In-Reply-To: <4F3F56E7.3080004@panozzo.it> X-Forwarded-Message-Id: <4F3F56E7.3080004@panozzo.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 07:45:21 -0000 Il 18/02/2012 08:24, Adrien de Croy ha scritto: > > We can't presume everyone has a full time internet connection. 100% agree. Store and forward is still required in some part of the world. I developed XATRN (http://xatrn.panozzo.it), and there are still very some (few, very few) users that use it with intermittent Internet connection. Yes, I think that the future will be for always-on connections, but there is no full world coverage of such kind of Internet access. >> They authenticate over sasl using some fancy >> federated authentication protocol (project moonshot) before being allowed >> to post to my inbox. > > Personally I'd be tempted to mandate use of X.509 (SSL) client certs and > TLS. Maybe X509 can be one of the weapons against spam. But today spam comes from a "stolen" webserver (injectet PHP script) or from "stolen" PC (zombie PC, zombie network). Spam NEVER comes from the sender itself. SPAM comes from a stolen account :( Yes, better knowing the stolen account can help in fix the problem, linke telling the user to run antivirus/reinstall OS, or the webmaster to check its .PHP files. But I don't think that identifiyng the user with X509 cert or some other federated authentication will help. From adrien@qbik.com Sat Feb 18 02:06:54 2012 Return-Path: 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 963A921F86C7 for ; Sat, 18 Feb 2012 02:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[AWL=-1.202, 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 w7kdVGNx+-LU for ; Sat, 18 Feb 2012 02:06:53 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCC721F86C4 for ; Sat, 18 Feb 2012 02:06:52 -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 3381)) with SMTP id <0018869691@smtp.qbik.com>; Sat, 18 Feb 2012 23:06:49 +1300 Message-ID: <4F3F7833.9020003@qbik.com> Date: Sat, 18 Feb 2012 23:06:43 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Bron Gondwana References: <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><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> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> In-Reply-To: <1329550573.30138.140661038121885@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 10:06:54 -0000 On 18/02/2012 8:36 p.m., Bron Gondwana wrote: > 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. with respect, others may like it and want to do it. If you don't like it, you can design your server and client to behave the way you like without making it impossible for others to do it in the protocol. others may prefer to submit the SMTP envelope information when they tell the server to send a message, and it could be stored as some meta-data on the message. Sure, if there's a huge desire to do this then fall-back to SMTP may be possible... but we're doing submission in IMAP so that client authors no longer have to support that protocol right? > 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. server is free to do whatever else it likes, like moving it to sent, or making a copy or whatever. > > 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. I guess it's a grey area there - if you consider IMAP to be a remote mail client that you're driving from a distance, then it's ok to store a BCC header, just like you would if you were storing it in a local store. But you're relying on the IMAP server to strip it when it submits the mail for delivery, which is a bit of work for the IMAP server. If you don't have to parse and re-build messages all the time, you'll scale much better. > > Bron. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From adrien@qbik.com Sat Feb 18 02:07:15 2012 Return-Path: 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 70F4821F86D8 for ; Sat, 18 Feb 2012 02:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-1.691, BAYES_00=-2.599, FUZZY_AMBIEN=1.026] 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 Yw+YOt5p89lv for ; Sat, 18 Feb 2012 02:07:15 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7D30021F86C7 for ; Sat, 18 Feb 2012 02:07:14 -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 3381)) with SMTP id <0018869697@smtp.qbik.com>; Sat, 18 Feb 2012 23:07:13 +1300 Message-ID: <4F3F784B.2000809@qbik.com> Date: Sat, 18 Feb 2012 23:07:07 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: "Discussion on drastically slimming-down IMAP." References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> <4F3F5234.2080406@qbik.com> <4F3F56E7.3080004@panozzo.it> In-Reply-To: <4F3F56E7.3080004@panozzo.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 10:07:15 -0000 On 18/02/2012 8:44 p.m., Giovanni Panozzo wrote: > Il 18/02/2012 08:24, Adrien de Croy ha scritto: >> >> We can't presume everyone has a full time internet connection. > > 100% agree. Store and forward is still required in some part of the > world. I developed XATRN (http://xatrn.panozzo.it), and there are > still very some (few, very few) users that use it with intermittent > Internet connection. Yes, I think that the future will be for > always-on connections, but there is no full world coverage of such > kind of Internet access. > >>> They authenticate over sasl using some fancy >>> federated authentication protocol (project moonshot) before being >>> allowed >>> to post to my inbox. >> >> Personally I'd be tempted to mandate use of X.509 (SSL) client certs and >> TLS. > > Maybe X509 can be one of the weapons against spam. But today spam > comes from a "stolen" webserver (injectet PHP script) or from "stolen" > PC (zombie PC, zombie network). > Spam NEVER comes from the sender itself. SPAM comes from a stolen > account :( plenty of spam comes from the sender not stolen accounts. That's why the spammers do things like register their own domains and SPF records. > Yes, better knowing the stolen account can help in fix the problem, > linke telling the user to run antivirus/reinstall OS, or the webmaster > to check its .PHP files. But I don't think that identifiyng the user > with X509 cert or some other federated authentication will help. the server will have a cert. It can be seen as spamming, and its cert can be revoked. That will cut it off. Having to get another cert will provide an incentive for the admin to care about it. > > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From adrien@qbik.com Sat Feb 18 02:13:50 2012 Return-Path: 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 715E621F84FB for ; Sat, 18 Feb 2012 02:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-1.145, 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 kGPfL3za1Xcx for ; Sat, 18 Feb 2012 02:13:49 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2321F84AA for ; Sat, 18 Feb 2012 02:13:47 -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 3381)) with SMTP id <0018869738@smtp.qbik.com>; Sat, 18 Feb 2012 23:13:45 +1300 Message-ID: <4F3F79D1.8090909@qbik.com> Date: Sat, 18 Feb 2012 23:13:37 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Dan White References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> In-Reply-To: <20120217171457.GB4503@dan.olp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 10:13:50 -0000 On 18/02/2012 6:14 a.m., Dan White wrote: > 3) I can fiddle with my acls bits to determine who I want to get messages > from. > many companies publish email addresses, e.g. for sales or support enquiries. They need to be able to receive mail from unknown people. This doesn't fit with a whitelist approach to incoming. Even Facebook allows you to send a message to someone without asking them to friend you. Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From fanf2@hermes.cam.ac.uk Sun Feb 19 10:34:27 2012 Return-Path: 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 7F1D121F8466 for ; Sun, 19 Feb 2012 10:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 H8uRPiwufEtk for ; Sun, 19 Feb 2012 10:34:25 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id C09A421F8442 for ; Sun, 19 Feb 2012 10:34:19 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:60240) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1RzBaP-0004Kd-rw (Exim 4.72) (return-path ); Sun, 19 Feb 2012 18:34:13 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RzBaP-0003q9-Lh (Exim 4.67) (return-path ); Sun, 19 Feb 2012 18:34:13 +0000 Date: Sun, 19 Feb 2012 18:34:13 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Bron Gondwana In-Reply-To: <1329550573.30138.140661038121885@webmail.messagingengine.com> Message-ID: References: <20120213210805.GB13029@launde.brong.net><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><20120215213122.GB16253@launde.brong.net><4F3C2C1B.6030408@qbik.com> <4F3CE16B.3060603@qbik.com><3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 18:34:27 -0000 Bron Gondwana 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. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Rockall, Malin: Southwesterly 5 to 7, occasionally gale 8 in Rockall and Malin. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From brong@fastmail.fm Sun Feb 19 11:26:10 2012 Return-Path: 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 054A021F852A for ; Sun, 19 Feb 2012 11:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 MF6NcwCGNtzA for ; Sun, 19 Feb 2012 11:26:06 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7710821F8525 for ; Sun, 19 Feb 2012 11:26:06 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2BF37215A0 for ; Sun, 19 Feb 2012 14:26:06 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 19 Feb 2012 14:26:06 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=EqAVP0sk1d0eY19cWtdyx291 cc8=; b=APruEX9Lhx1FFjGqb15ZK2iwnQ1b3Do9SWI4XmXNP5afdZzQ+4B7XQbc mxTy3nWU7fuxtIKVVIa1f800GePq2i/FxF54RvBNPciuIHQOpl1Q1S9FiC0T0mEd +k6vjgk0d99MFh6UCIz62jOClmvxISTfV2XIHXpwGhAeoNQ9Has= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=EqAVP0sk1d0eY19cWtdyx291cc8=; b=X6zrsMy3KOLacpEtetiXLDMkdqqQ FbTYh9Z6bUfq23jiH1li7a0jSx5L3/erYXT8ntlBEyhWIBQ3uNml8wx1i2i0RWtA W1LvolPkhIWdHSTTBBQ7hkdS/Eb7Vu/ikY1TePynk3Rmyc2pW0ICtrI4PI3t03A6 wIwy+AELVPjy6Tc= X-Sasl-enc: 28pz7FW9ZCXkBe5GsIakusBl91ZtWJe6KfbWKq2YRM9a 1329679565 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id CECB64824EB; Sun, 19 Feb 2012 14:26:05 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 4FBB3316B81; Sun, 19 Feb 2012 20:26:04 +0100 (CET) Date: Sun, 19 Feb 2012 20:26:04 +0100 From: Bron Gondwana To: Tony Finch Message-ID: <20120219192604.GA11323@launde.brong.net> References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 19:26:10 -0000 On Sun, Feb 19, 2012 at 06:34:13PM +0000, Tony Finch wrote: > Bron Gondwana 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. From Hagedorn@uni-koeln.de Sun Feb 19 11:36:11 2012 Return-Path: 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 6F56521F8540 for ; Sun, 19 Feb 2012 11:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] 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 Vom8PHfhOa4V for ; Sun, 19 Feb 2012 11:36:10 -0800 (PST) Received: from smtp-out.rrz.uni-koeln.de (smtp-out.rrz.uni-koeln.de [134.95.19.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7385521F84F8 for ; Sun, 19 Feb 2012 11:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at uni-koeln.de Received: from smtp-auth.rrz.uni-koeln.de (smtp-auth.rrz.uni-koeln.de [134.95.19.93]) by smtp-out.rrz.uni-koeln.de (8.13.8/8.13.8) with ESMTP id q1JJa51F032005; Sun, 19 Feb 2012 20:36:05 +0100 X-AUTH-SIP: a0620@vpn83-106.vpn.uni-koeln.de [134.95.83.106] Received: from vpn83-106.vpn.uni-koeln.de (vpn83-106.vpn.uni-koeln.de [134.95.83.106]) (authenticated as user a0620 using DIGEST-MD5 bits=0) by smtp-auth.uni-koeln.de (8.13.8/8.13.8) with ESMTP id q1JJa3J3013067; Sun, 19 Feb 2012 20:36:04 +0100 Date: Sun, 19 Feb 2012 20:35:57 +0100 From: Sebastian Hagedorn To: Bron Gondwana Message-ID: <23AD106590F87A8C01A33FE4@vpn83-106.vpn.uni-koeln.de> In-Reply-To: <20120219192604.GA11323@launde.brong.net> References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) Message-Context: text-message X-Spook: nuclear nuke spy secret assassination cia fbi nsa president MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========4D97E95B55BF97F17D17==========" X-Scanned-By: MIMEDefang 2.71 on 134.95.19.53 Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 19:36:11 -0000 --==========4D97E95B55BF97F17D17========== Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1508 > 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. Not necessarily. I just resent your message to myself. Mulberry, IMO still=20 the best email client, adds the following headers: Resent-Date: Sun, 19 Feb 2012 20:30:30 +0100 Resent-From: Sebastian Hagedorn Resent-To: Sebastian Hagedorn Resent-Message-ID: <54B00D8CBCD7BCEB1191BE44@vpn83-106.vpn.uni-koeln.de> X-Resent-Mailer: Mulberry/4.1.0a1 (Mac OS X) Doesn't look spammy at all, because it's completely clear what has=20 happened. I use that feature all the time. > You're > much better off forming a new message. No, because the idea is precisely to preserve the original headers. > 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? Facebook not, but Outlook/Exchange does ... it's called "Resend This=20 Message...". -- Sebastian Hagedorn - RZKR-R1 (Flachbau), Zi. 18, Robert-Koch-Str. 10 Regionales Rechenzentrum (RRZK) Universit=E4t zu K=F6ln / Cologne University - Tel. +49-221-478-5587 --==========4D97E95B55BF97F17D17========== Content-Type: application/pkcs7-signature Content-Transfer-Encoding: base64 MIIUqAYJKoZIhvcNAQcCoIIUmTCCFJUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCEhMwggU5MIIEIaADAgECAgQOtLhdMA0GCSqGSIb3DQEBBQUAMHkxCzAJ BgNVBAYTAkRFMQ4wDAYDVQQHEwVLb2VsbjEeMBwGA1UEChMVVW5pdmVyc2l0YWV0 IHp1IEtvZWxuMRQwEgYDVQQDEwtVbmlLb2VsbiBDQTEkMCIGCSqGSIb3DQEJARYV Y2FtYXN0ZXJAdW5pLWtvZWxuLmRlMB4XDTA5MDgyNjEzMzgyMVoXDTEyMDgyNTEz MzgyMVowcDELMAkGA1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYDVQQKExVV bml2ZXJzaXRhZXQgenUgS29lbG4xFDASBgNVBAsTC1JSWkssIE5ldHplMRswGQYD VQQDExJTZWJhc3RpYW4gSGFnZWRvcm4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCvbrQcOH3+9/Pk2gOBHTD8neKH/ULtE2NJs3hdFgc1Zy8JiSPcQ1is E1zHaiX1RANfhWNu2fCMk1rgmlsJAq0K3YShGxdTzD36tTKKM3i+CEoNPLmWik0x +RWK5d/lSez3WGludxvjICAQsDBuFxok5AdtQcVgv2+PPBbjw8YiJhHyWiVcG0iR 3xE3ExWARR6UAhkQiR8MMD+bCDaSPrmv7O9oEkB3BOxY40cyFTzskb2H68MrCX8S HzHw9lcoE3xBvFEySKGOnJEProhE/x619FDRyXpmw6XqFGmBBufmGc1ymYZclVcl uvBsInBRUumjW6yxlnqEfg7PzVRdJAWpAgMBAAGjggHQMIIBzDAJBgNVHRMEAjAA MAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFFryMqfqZw/rn+SOR8hobWb3X/tmMB8GA1UdIwQY MBaAFCrqiesOstApxf75TKV23LdvTwm6MCAGA1UdEQQZMBeBFUhhZ2Vkb3JuQHVu aS1rb2Vsbi5kZTCBgwYDVR0fBHwwejA7oDmgN4Y1aHR0cDovL2NkcDEucGNhLmRm bi5kZS91bmkta29lbG4tY2EvcHViL2NybC9jYWNybC5jcmwwO6A5oDeGNWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvdW5pLWtvZWxuLWNhL3B1Yi9jcmwvY2FjcmwuY3Js MIGeBggrBgEFBQcBAQSBkTCBjjBFBggrBgEFBQcwAoY5aHR0cDovL2NkcDEucGNh LmRmbi5kZS91bmkta29lbG4tY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEUGCCsG AQUFBzAChjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1rb2Vsbi1jYS9wdWIv Y2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAEAQjwt/trFejwkc b0ZDFda7WWMZ48/a6kyXtDOzQwa82HSM77/hE2lRvryWx7oEW6D9Z84nI1AmjSxb fJI733ASHvw/VyA8mXf9/HRzCIMpiH9Zuk3kBqx6bezVRjL4gprvwP4ApUVPzH5A GGF/iEJl09kO6Cjv5VfbhJubucWJzsgmKuZfmfaHOOQ9uNcVqznmseMbkfVeICMy XfxA4+y5v8w65hb+EFP1rQXwf8csDxN48/g8KOmzOcwYd2+4cNz7vUIduQXUXhsc C+zO8gIZeDdAcDgAxGTGklwkGcuYfrQyJywSCz2GyiKK0Jk9maIKPooRSl7QuG5u q8p2A6swggUKMIID8qADAgECAgQKRUldMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQw IgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMDcwNDE4MDc0 MjA3WhcNMTkwNDE3MDAwMDAwWjB5MQswCQYDVQQGEwJERTEOMAwGA1UEBxMFS29l bG4xHjAcBgNVBAoTFVVuaXZlcnNpdGFldCB6dSBLb2VsbjEUMBIGA1UEAxMLVW5p S29lbG4gQ0ExJDAiBgkqhkiG9w0BCQEWFWNhbWFzdGVyQHVuaS1rb2Vsbi5kZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMvE96PdJusN/alR90nwwV4Y iLNM1ANMT2XN4MbfniygeGzgvMX7T8juVDw4H9LRtehfBvjPqMM7nth1RR5k/gSO yUyRUzcNLZS+UVu0bXARd1WckeS8moERrV+/3HMPqNCJuk67pLjowYw1psja4qsJ aT8yOhpbanc3mZIa9tq+d4mLZ0LvZVhuFxhbIdfl+f2agskQbbYbURcPLH/nsvKt vEnKDfcHeVJGX0hfR7ZBQhCe8XiKUNhKKdQV61UO71vw7dP3xzG8PQH3SnhZKTeY hCU7YgW82PXtv26DCDIg6iJyuODqLYwXTjc1601NoToDMN6WGGP0eC/fOnipm6MC AwEAAaOCAbcwggGzMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0G A1UdDgQWBBQq6onrDrLQKcX++Uyldty3b08JujAfBgNVHSMEGDAWgBRJt8bP6D0f f+pEexMp9/EKcD7eZDAgBgNVHREEGTAXgRVjYW1hc3RlckB1bmkta29lbG4uZGUw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5w Y2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUH MAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCteobYEtkcfAeVJzUD m1S/4mRtTt8E6dKtsVHFVuHSc59Gco57ugZ5PxmzV8PU5Pq45KwYZ0zE8mchP5YO iE43bu4dSeDDcIjoh9l5VanjQ+kMM3qf/tv73bRwanUQIMsd3qYHseqsXusddJgX BLZOfs+/o2FCOQX5UucQBHSFGSOObUx6uYywKDT/lY+3mzAQiA35Df20bN3UCQpA ja3KDqeLRhL8YjTw+K1cU4UwH5G/hErxOsUzhf0aKhNv074cReDkPxpBHi9QhKpQ PBehI/0alzG27CIf2rkMBSXiIwUfKQWtBOOVnDftPTB17qFttkhK4MnIIYVBBKrb AeINMIIEITCCAwmgAwIBAgICAMcwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMC REUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVs ZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UE BhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAi BgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTU IOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFssoNTl7LZBF0O2gAHp8 v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90D8EJ ovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWG fW8zs9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDN SVTbyRM0mnF1xWzqpwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBw BgNVHR8EaTBnMGWgY6Bhhl9odHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9z ZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNz dWVyPURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsTKffxCnA+3mQw HwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfc qRjsga9aifC9KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+ER Ee5reJEzfjtfJid1U2WOM2Puz3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUp QPY/czJYDQlrptqFbMA/u41mZFYkTq4NPzI1AVvpjILZcllPsYaF8XSFVuXD+Fzz je5Hs1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6LArZYtfahLDdXAGer I2iNY6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3LxMr+M zkljqAD38hwwggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNV BAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZU LVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDkyMzU5MDBaMHExCzAJ BgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxl a29tIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsL ozXgiykUsRSFrzwQ5DlvNV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25 TVw6ztO4qEJA38+juoJZapIbrBya2ggrJSf5aSNH8eDrLHqb9RMC0H40fMKePABZ q/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgBSV9yQTwVBgGOXa2quJO0 zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ7lMFjxlM 1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoD NNWOWwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0X bAqzK50zMA8GA1UdEwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCUZFmtOWTnKesT/lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7U wz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLOF/Msx2I2VeIi2IlVtJhIqmT6 1hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjytnv+AWeSbRbT2 O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHl cAWbDiNXmZQKbbo5YyiGkvMYhNj70c8FVmRXMYICXTCCAlkCAQEwgYEweTELMAkG A1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYDVQQKExVVbml2ZXJzaXRhZXQg enUgS29lbG4xFDASBgNVBAMTC1VuaUtvZWxuIENBMSQwIgYJKoZIhvcNAQkBFhVj YW1hc3RlckB1bmkta29lbG4uZGUCBA60uF0wCQYFKw4DAhoFAKCBsTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMTkxOTM2MDNa MCMGCSqGSIb3DQEJBDEWBBT+AffS7byKOXW8GVpe7FmHU8zLTDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBIdG+H 7lt8fu45SbOa4/MejGMAbMbXIDC6nveBmafofEu/S4mZ1fkqr2ASsCmIHIKqwMmg kQql5W4l290ztZtw1eO7PgDqZLlIUH1xDAj/LX+64oLe3hpsN3hZf4K4XAzcBzP5 9ctYzJ2tFWYwZ32g2yhHSUG1O8t+4aBdXKKi4INQajayGsQ/ZO5XkfGFMF1+lbN2 fmCIAv4YvT50INpZtb0AJaai7e7yZmEUDCGrjmoPmasLro63r8oTuPOSfibn9YBz jriRSYapwxb/E2ZaV+7BBrDkVyJ0dQKekAkJo9FJcVNZ0Yq1qQHZ14ALecyYGBf5 QoteSDNqWKAEmbM6 --==========4D97E95B55BF97F17D17==========-- From adrien@qbik.com Sun Feb 19 12:31:29 2012 Return-Path: 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 ; 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 ; 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 ; 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 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 References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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/ From brong@fastmail.fm Sun Feb 19 14:01:17 2012 Return-Path: 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 4BDCA21F8523 for ; Sun, 19 Feb 2012 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 kwD1xTy9YJPv for ; Sun, 19 Feb 2012 14:01:15 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 956A021F84D4 for ; Sun, 19 Feb 2012 14:01:15 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 377C32166F for ; Sun, 19 Feb 2012 17:01:15 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 19 Feb 2012 17:01:15 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=/RYXKWkp0JYIIlpx5D5jret7 7UA=; b=c7gQhoXs6fON+L0N8mT2P443PPXWA4CJ//C+QD/UZO6SB5QG3VoYr5Qq 5pKAiUbxPs0OPprMihbpUXSWYsqvR+urbyNJLDCOagY+pIb6nnEmGFfmrSx0Q4VF +TzYLAGipZ2KCyL8dW5kMyqqRVKRjXX4sjdqubILZDcqaesMLQQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=/RYXKWkp0JYIIlpx5D5jret77UA=; b=q65ApB+dgP4uXkHeWemjh5WdBur7 aMmjrWfyfINZs4C7MxURrY+XviJXIjXcx5CYYYYFxXJKCa1MaVmwp4+J+H5sH1NF 0jIoc7g89njvCS8pkX9Du9Ke34ATxGBRBM65Y2isEM0nPwqSHmwKNJBzJOGjSrG2 rK/hpo1tNJxDwGI= X-Sasl-enc: IRSi9L4WF16GH+iSKm9kaqrSIzSeczcTjFkSos9YBftB 1329688874 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id E6BF448250B; Sun, 19 Feb 2012 17:01:14 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 634AA316B81; Sun, 19 Feb 2012 23:01:13 +0100 (CET) Date: Sun, 19 Feb 2012 23:01:13 +0100 From: Bron Gondwana To: Sebastian Hagedorn Message-ID: <20120219220113.GA12549@launde.brong.net> References: <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <23AD106590F87A8C01A33FE4@vpn83-106.vpn.uni-koeln.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23AD106590F87A8C01A33FE4@vpn83-106.vpn.uni-koeln.de> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 22:01:17 -0000 On Sun, Feb 19, 2012 at 08:35:57PM +0100, Sebastian Hagedorn wrote: > >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. > > Not necessarily. I just resent your message to myself. Mulberry, IMO > still the best email client, adds the following headers: ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Resent-Date: Sun, 19 Feb 2012 20:30:30 +0100 > Resent-From: Sebastian Hagedorn > Resent-To: Sebastian Hagedorn > Resent-Message-ID: <54B00D8CBCD7BCEB1191BE44@vpn83-106.vpn.uni-koeln.de> > X-Resent-Mailer: Mulberry/4.1.0a1 (Mac OS X) > > Doesn't look spammy at all, because it's completely clear what has > happened. I use that feature all the time. Doesn't sound like it's the same IMAP UID to me. So it looks like using "Resent-To" rather than "To" if Resent-To exists handily covers your usecase. > > You're > >much better off forming a new message. > > No, because the idea is precisely to preserve the original headers. Sounds like you're forming a new RFC822 message stored on the server rather than redirecting the actual original bytes... > >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? > > Facebook not, but Outlook/Exchange does ... it's called "Resend This > Message...". Do they attach the original? Is the destination address stored in a header somewhere in the saved copy so that you can see it? Assuming that information is stored somewhere, requiring it to be so and parsing from that rather than extending the command is much cleaner. It provides an audit trail of sorts. Bron. From brong@fastmail.fm Sun Feb 19 14:08:39 2012 Return-Path: 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 639D321F8516 for ; Sun, 19 Feb 2012 14:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 D-RusDMnGLYi for ; Sun, 19 Feb 2012 14:08:38 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA5B21F84F5 for ; Sun, 19 Feb 2012 14:08:38 -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 D41D321342 for ; Sun, 19 Feb 2012 17:08:36 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 19 Feb 2012 17:08:36 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=xBxkaA7RiIfHHQBxzp+qM0+q r/o=; b=KxTaXkBJZ4kOE/410bJ/cduX3IcfZn1pzVZfs9+t2Q0HwEjoRBfoRCWD IHImGb2QGj0oPIXL/281iFLMWL3S7X9D74L5RXX+PM49diQAACxTKNgd0eHXh5a9 ZzRu/DUk8rtb6ypG6pqiZqLoyhQhQ2cmV1Rg8Jkc7VsILPNbWp4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=xBxkaA7RiIfHHQBxzp+qM0+qr/o=; b=upUW4Si04zj0ua+lIZ+zNw86PR3V MSxNyHv3PC0eXjwVnqbmuwQFuXDHB3uAaZg53Y7rcEmrR0ho/8zyKvIPXXMXFesa TBVFrXr5NmsS9JRVxqWZu6rAhko37HTAsG73CBalknwmvf2M5VGwEiwkWyR9qNdV Mu2L2iBH+ZOmO0Q= X-Sasl-enc: /pKA8q9NSCgSOoaHFaBPcb837C3Um+/IaLSOpmvWomPz 1329689316 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 67E0E8E0109; Sun, 19 Feb 2012 17:08:36 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 0B871316B81; Sun, 19 Feb 2012 23:08:35 +0100 (CET) Date: Sun, 19 Feb 2012 23:08:35 +0100 From: Bron Gondwana To: Adrien de Croy Message-ID: <20120219220835.GB12549@launde.brong.net> References: <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F415C07.3040100@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F415C07.3040100@qbik.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 22:08:39 -0000 On Mon, Feb 20, 2012 at 09:31:03AM +1300, Adrien de Croy wrote: > 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 Most MTAs seem to do header rewriting by appending or stripping parts of the header on the fly. They don't rewrite the entire message, they print the headers down the wire, then blat the body. That's not expensive unless you're doing it wrong. > these things are not cheap. they will affect service capacity. Seriously? We do it to millions of emails in Postfix every day on a single box and the CPU barely breaks a sweat. What sort of capacities are you considering serving on a single machine here? Micro-optimising this... if you can save a single fsync somewhere you'll get much better optimisation than avoiding a header removal. Remember you're probably ADDING a header anyway to note the sending time and user/ip of the sender at the time it happened. > Why would you incur such penalty simply to avoid transmission of a > couple of parameters? Because I don't believe you when you make it out to be a big penalty. You're not rewriting the header on disk, purely on what gets written to the wire. > It's trivially simple for an MUA to supply this information when it > wants to send the message. Trivially simple, yes - not so simple to track and repeat. > 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. Significantly more complex than a simple keyword. For a rare case. Parsing "Resent-To" instead handily covers the entire use-case that you have raised, with no loss of functionality, and without bloody raising the edge cases to higher importance than the simple common case which happens all the time. Make the easy things EASY and the hard things possible, not everything equally hard. > 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. Happy to have serious thought about it, but in this case the initial envelope should IMHO be part of the content, because you're sending something out of your "\Sent" box, near enough, and what's there should be a record of what you sent. SMTP will still exist for the 0.1% cases. Resent-To will handily cover the normal "user operated client" use-case. This is a method for "submission by a user operated client", that's all. Bron ( getting bogged down in side issues, whee ) From adrien@qbik.com Sun Feb 19 15:00:30 2012 Return-Path: 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 0BE2421F8571 for ; Sun, 19 Feb 2012 15:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 i5GptCm215Vg for ; Sun, 19 Feb 2012 15:00:22 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1F36421F850F for ; Sun, 19 Feb 2012 15:00: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 <0018872038@smtp.qbik.com>; Mon, 20 Feb 2012 12:00: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 <0010061869@sago.qbik.com>; Mon, 20 Feb 2012 12:00:05 +1300 Message-ID: <4F417EF5.6030809@qbik.com> Date: Mon, 20 Feb 2012 12:00:05 +1300 From: Adrien de Croy 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 References: <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F415C07.3040100@qbik.com> <20120219220835.GB12549@launde.brong.net> In-Reply-To: <20120219220835.GB12549@launde.brong.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 23:00:30 -0000 On 20/02/2012 11:08 a.m., Bron Gondwana wrote: > On Mon, Feb 20, 2012 at 09:31:03AM +1300, Adrien de Croy wrote: >> 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 > Most MTAs seem to do header rewriting by appending or stripping > parts of the header on the fly. They don't rewrite the entire > message, they print the headers down the wire, then blat the > body. That's not expensive unless you're doing it wrong. that depends on how your system is structured. The MTAs I'm familiar with put files into their send queues, and specify envelopes separately, either in a separate file or in a DB or something.. So a message file re-write would be required to strip bcc before putting it into the queue, or a re-factor of the SMTP sending code to allow the option to parse the headers on the fly (the option would need to be communicated out-of-band). That is of course do-able. But it forces a model on the SMTP delivery agent. What is the concern about sending the parameters? That they can be different to the headers in the message? the main use-case I can think of where the recipients and return-path are not normally in the message are in lists. So with your system, you won't be able to have an efficient list processor attach to an IMAP message store. It will need to make copies of the message for each recipient. Another problem is auto-responders, where commonly you specify a blackhole or empty return path to avoid loops. You'll at least need a way to update certain headers into the message efficiently. This would make for much more efficient forwarding as well... copy, rewrite To, Subject and send. Rather than download, edit, upload send. Maybe store the headers separately. >> these things are not cheap. they will affect service capacity. > Seriously? We do it to millions of emails in Postfix every day > on a single box and the CPU barely breaks a sweat. What sort of > capacities are you considering serving on a single machine here? I always save CPU when I can. There's always a bigger client out there who will need more capacity. > Micro-optimising this... if you can save a single fsync somewhere > you'll get much better optimisation than avoiding a header removal. > Remember you're probably ADDING a header anyway to note the sending > time and user/ip of the sender at the time it happened. Senders don't normally stamp Received if that's what you're referring to, that happens at the SMTP receiver. our sender doesn't write to the message. > >> Why would you incur such penalty simply to avoid transmission of a >> couple of parameters? > Because I don't believe you when you make it out to be a big penalty. > You're not rewriting the header on disk, purely on what gets written > to the wire. Sure if you do it all your way... but not all mail systems work that way. > >> It's trivially simple for an MUA to supply this information when it >> wants to send the message. > Trivially simple, yes - not so simple to track and repeat. Sure, displaying the information later is not something currently supported. Your way allows existing sent items mailbox to continue to perform its current function in the current way. But there may be a better way. Honestly I haven't fully convinced myself either way yet. I am quite nervous about such a wide-reaching change though. > >> 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. > Significantly more complex than a simple keyword. For a rare case. > Parsing "Resent-To" instead handily covers the entire use-case that > you have raised, with no loss of functionality, and without bloody > raising the edge cases to higher importance than the simple common > case which happens all the time. I must be missing something. AFAIK the common case that happens all the time is that you specify forward and reverse paths separately from the message content. You're proposing removing this. I'm still open to the option, but there are a myriad of consequences that haven't been touched on. Most MUAs can and will still ensure the parameters match the headers. Other software may have other requirements. You're just saying they will need to use SMTP. Fine, but that doesn't move us forward. I think if we're to drop the concept of an SMTP envelope, and say you can't send a message where the to and from in the message don't match the envelope (which I'm sure many people would like) we need tomake sure we don't break so much stuff as to make the new protocol impossible for people to adopt is all. Just seems that policy can be used to enforce such a requirement as desired, rather than mandating it in the protocol and removing everyone's choice. > Make the easy things EASY and the > hard things possible, not everything equally hard. sure. I just don't think it's hard to have a command like SEND UID forward-path reverse-path In fact I'd be keen on something like SENDFLAGANDMOVE UID +\Sent "Sent Items" forward-path reverse-path to avoid magic which you're otherwise doing with your Sent flag. The final point I'd make about obtaining the forward path from the message vs a parameter. If you're parsing the To, CC, BCC headers, you need to be able to parse all character sets (there are many) in a completely bullet-proof fashion. Adrien >> 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. > Happy to have serious thought about it, but in this case the initial > envelope should IMHO be part of the content, because you're sending > something out of your "\Sent" box, near enough, and what's there > should be a record of what you sent. > > SMTP will still exist for the 0.1% cases. Resent-To will handily > cover the normal "user operated client" use-case. This is a method > for "submission by a user operated client", that's all. > > Bron ( getting bogged down in side issues, whee ) -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From brong@fastmail.fm Sun Feb 19 15:39:06 2012 Return-Path: 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 A854021F8493 for ; Sun, 19 Feb 2012 15:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 AW3+SPlaMF8C for ; Sun, 19 Feb 2012 15:39:05 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9414821F845F for ; Sun, 19 Feb 2012 15:39:05 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 44697212D2 for ; Sun, 19 Feb 2012 18:39:05 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Sun, 19 Feb 2012 18:39:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=GpUgcf8ZUQP2o+Hn4iCZU6jK bRM=; b=S9eY+Y8f44+Dwra9JofDq2/fsyGIgt/thWNIgHmyjpoltH7Q34Jp0OgG KBgMiFv26ibQv5mPdqqLwVPMt10zuz4OYD+4N9Du4PDRC4I+WlKD/iWbBWMZkJBV Ty5M8WrYLLYJSOBf3xh8wZw9Xfkfr/NsBohpxZow6W6y8bZqzj8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=GpUgcf8ZUQP2o+Hn4iCZU6jKbRM=; b=B0Dwzp1z4KFsZc9TTdc4cmSPrmsE tIPWjPvYKASJ2CHxxMcnDVB8I5JAnAMJehxntU2eCr49hfTySRmm4bmiITZHnZVB iLA5RHB7BGo3Cfs5v8oQLCp29e+TcpvxJ2x3k+nSZL5XRpGtrOrq/GylZXp9Iq1z cbXQ/sa9Q7ghXVo= X-Sasl-enc: /OlGJZATqjjuJEuPrv5ISxZWc4kwrPckkaLxXiv/nLdF 1329694744 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id CFC118E0204; Sun, 19 Feb 2012 18:39:04 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id B06F8316B81; Mon, 20 Feb 2012 00:39:01 +0100 (CET) Date: Mon, 20 Feb 2012 00:39:01 +0100 From: Bron Gondwana To: Adrien de Croy Message-ID: <20120219233901.GA13600@launde.brong.net> References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F415C07.3040100@qbik.com> <20120219220835.GB12549@launde.brong.net> <4F417EF5.6030809@qbik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F417EF5.6030809@qbik.com> Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 23:39:06 -0000 On Mon, Feb 20, 2012 at 12:00:05PM +1300, Adrien de Croy wrote: > that depends on how your system is structured. The MTAs I'm > familiar with put files into their send queues, and specify > envelopes separately, either in a separate file or in a DB or > something.. Unless you're putting the pre-exiting file from store into the queue by reference rather than by copying, you would do the rewrite as you copy. Putting it in the queue by reference means you will have to guarantee that the original mailbox copy doesn't get expunged until the send has finished. > What is the concern about sending the parameters? Basically the \Sent things below. > the main use-case I can think of where the recipients and > return-path are not normally in the message are in lists. So with > your system, you won't be able to have an efficient list processor > attach to an IMAP message store. It will need to make copies of the > message for each recipient. I wouldn't expect an efficient list processor to be a user-facing client. Hence it would obviously talk directly, probably LMTP, to the MTA. > Another problem is auto-responders, where commonly you specify a > blackhole or empty return path to avoid loops. Not a user client. > You'll at least need a way to update certain headers into the > message efficiently. This would make for much more efficient > forwarding as well... copy, rewrite To, Subject and send. Rather > than download, edit, upload send. Maybe store the headers > separately. Lemonade style CATENATE. > Honestly I haven't fully convinced myself either way yet. I am > quite nervous about such a wide-reaching change though. So am I. But your arguments are convincing me more that I'm right. The cases you're coming up with are all "agents running on the server doing non-user-client things" or "we don't support a way to strip headers from a message when sending". The "we don't support a way to strip headers" is the closest to a viable argument I've heard so far, but that's an egg I think is worth breaking in exchange for a really clear model about who a message was sent to. You read the headers, you know. The \Sent flag has a really specific meaning - and it takes an actively malicious client to break that. The theoretical "moron" will get it right, because getting it wrong is a lot more work. > I must be missing something. AFAIK the common case that happens all > the time is that you specify forward and reverse paths separately > from the message content. Yes, you do. > You're proposing removing this. Yes, I am. > I'm still open to the option, but there are a myriad of consequences > that haven't been touched on. > > Most MUAs can and will still ensure the parameters match the > headers. Other software may have other requirements. You're just > saying they will need to use SMTP. Fine, but that doesn't move us > forward. I'm saying this is a protocol for MUAs to talk to mail stores. That's all. It does not replace SMTP, it does not replace LMTP. It provides a submission path for MUAs that can and will and want to make the parameters match because the message on the server is a record of what was sent. > >Make the easy things EASY and the > >hard things possible, not everything equally hard. > sure. I just don't think it's hard to have a command like > > SEND UID forward-path reverse-path > > In fact I'd be keen on something like > > SENDFLAGANDMOVE UID +\Sent "Sent Items" forward-path reverse-path > > to avoid magic which you're otherwise doing with your Sent flag. The magic is a latch. The latch is a protection against replay. I'd rather see "SENDFLAGANDMOVE" as a composition of simpler commands which can be composed than one funny-shaped lego block, so when you want to add something else to your chain, you don't need to do anything else. Which would make it "MOVE (IFNOT (FLAGS (\Sent)) (REPLACEHEADERS (Envelope-To: forward-path Envelope-From: return-path) +FLAGS (\Sent) DELIVER) UID "Sent Items" Looks a bit nasty in this syntax for sure. But that's non-magic then, it's a transaction including the various changes. I would infinitely prefer this to actual magic. But I think side effects on taking an action are significantly preferable to side effects on reading. The same way that a "STORE +FLAGS" has an implicit side-effect of bumping the MODSEQ on the message, and you can do an UNCHANGEDSINCE to latch that too. > The final point I'd make about obtaining the forward path from the > message vs a parameter. > > If you're parsing the To, CC, BCC headers, you need to be able to > parse all character sets (there are many) in a completely > bullet-proof fashion. Now that's a better argument than anything else I've seen so far. The flip side is, you're going to have to parse them to search and sort on them as well - so the code already exists in your server if it's even vaguely complete. Bron. From adrien@qbik.com Sun Feb 19 16:35:08 2012 Return-Path: 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 6C54E21F85D7 for ; Sun, 19 Feb 2012 16:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-1.078, 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 8s6SgJ49BHdj for ; Sun, 19 Feb 2012 16:35:07 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id D639E21F8491 for ; Sun, 19 Feb 2012 16:35:06 -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 <0018872124@smtp.qbik.com>; Mon, 20 Feb 2012 13:35:03 +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 <0010061898@sago.qbik.com>; Mon, 20 Feb 2012 13:34:51 +1300 Message-ID: <4F41952B.8020809@qbik.com> Date: Mon, 20 Feb 2012 13:34:51 +1300 From: Adrien de Croy 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 References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F415C07.3040100@qbik.com> <20120219220835.GB12549@launde.brong.net> <4F417EF5.6030809@qbik.com> <20120219233901.GA13600@launde.brong.net> In-Reply-To: <20120219233901.GA13600@launde.brong.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 00:35:08 -0000 On 20/02/2012 12:39 p.m., Bron Gondwana wrote: > On Mon, Feb 20, 2012 at 12:00:05PM +1300, Adrien de Croy wrote: >> that depends on how your system is structured. The MTAs I'm >> familiar with put files into their send queues, and specify >> envelopes separately, either in a separate file or in a DB or >> something.. > Unless you're putting the pre-exiting file from store into > the queue by reference rather than by copying, you would do > the rewrite as you copy. > > Putting it in the queue by reference means you will have to > guarantee that the original mailbox copy doesn't get > expunged until the send has finished. i'm just talking about good old file system file copy, without parsing. > >> What is the concern about sending the parameters? > Basically the \Sent things below. > >> the main use-case I can think of where the recipients and >> return-path are not normally in the message are in lists. So with >> your system, you won't be able to have an efficient list processor >> attach to an IMAP message store. It will need to make copies of the >> message for each recipient. > I wouldn't expect an efficient list processor to be a user-facing > client. Hence it would obviously talk directly, probably LMTP, to > the MTA. > >> Another problem is auto-responders, where commonly you specify a >> blackhole or empty return path to avoid loops. > Not a user client. check out RFC 6409 Sec 3.2 para 5 re NULL return paths. Clients do commonly auto respond. > >> You'll at least need a way to update certain headers into the >> message efficiently. This would make for much more efficient >> forwarding as well... copy, rewrite To, Subject and send. Rather >> than download, edit, upload send. Maybe store the headers >> separately. > Lemonade style CATENATE. I need to take another look, last time it gave me a headache. Is anyone supporting this? we may be putting the cart before the horse talking about submission before we even discussed message generation. > >> Honestly I haven't fully convinced myself either way yet. I am >> quite nervous about such a wide-reaching change though. > So am I. But your arguments are convincing me more that I'm right. > The cases you're coming up with are all "agents running on the > server doing non-user-client things" or "we don't support a way to > strip headers from a message when sending". > > The "we don't support a way to strip headers" is the closest to a > viable argument I've heard so far, but that's an egg I think is > worth breaking in exchange for a really clear model about who a > message was sent to. You read the headers, you know. The \Sent > flag has a really specific meaning - and it takes an actively > malicious client to break that. The theoretical "moron" will > get it right, because getting it wrong is a lot more work. > >> I must be missing something. AFAIK the common case that happens all >> the time is that you specify forward and reverse paths separately >> from the message content. > Yes, you do. > >> You're proposing removing this. > Yes, I am. > >> I'm still open to the option, but there are a myriad of consequences >> that haven't been touched on. >> >> Most MUAs can and will still ensure the parameters match the >> headers. Other software may have other requirements. You're just >> saying they will need to use SMTP. Fine, but that doesn't move us >> forward. > I'm saying this is a protocol for MUAs to talk to mail stores. That's > all. It does not replace SMTP, it does not replace LMTP. It provides > a submission path for MUAs that can and will and want to make the > parameters match because the message on the server is a record of what > was sent. does anyone except ISPs use LMTP? > >>> Make the easy things EASY and the >>> hard things possible, not everything equally hard. >> sure. I just don't think it's hard to have a command like >> >> SEND UID forward-path reverse-path >> >> In fact I'd be keen on something like >> >> SENDFLAGANDMOVE UID +\Sent "Sent Items" forward-path reverse-path >> >> to avoid magic which you're otherwise doing with your Sent flag. > The magic is a latch. The latch is a protection against replay. > I'd rather see "SENDFLAGANDMOVE" as a composition of simpler commands > which can be composed than one funny-shaped lego block, so when you > want to add something else to your chain, you don't need to do > anything else. > > Which would make it "MOVE (IFNOT (FLAGS (\Sent)) (REPLACEHEADERS (Envelope-To: forward-path Envelope-From: return-path) +FLAGS (\Sent) DELIVER) UID "Sent Items" > > Looks a bit nasty in this syntax for sure. But that's non-magic > then, it's a transaction including the various changes. I would > infinitely prefer this to actual magic. But I think side effects > on taking an action are significantly preferable to side effects > on reading. The same way that a "STORE +FLAGS" has an implicit > side-effect of bumping the MODSEQ on the message, and you can do > an UNCHANGEDSINCE to latch that too. however you do it, it needs to be transactional. A single command for this is one way to do it. Or you could create a new syntax that explicitly does transactions. Coding my SENDFLAGANDMOVE function would be quite simple. Your's with the conditional would be less simple. An alternative is providing explicit locking methods to clients (a la webDAV). But frankly I don't like giving control of locks to clients. So, maybe the best way is START SEND UID UID STORE UID +\Sent MOVE ... END Sent as one block. But that's just splitting my previous example into a few more lines. Gives you more combinations/flexibility I guess. Actually I don't have a problem with a side-effect of Send being to set a \Sent flag. But prohibiting subsequent re-sends I'm not so convinced about. You'd need to clear that flag if the message were to be copied (more magic). >> The final point I'd make about obtaining the forward path from the >> message vs a parameter. >> >> If you're parsing the To, CC, BCC headers, you need to be able to >> parse all character sets (there are many) in a completely >> bullet-proof fashion. > Now that's a better argument than anything else I've seen so far. > > The flip side is, you're going to have to parse them to search and > sort on them as well - so the code already exists in your server > if it's even vaguely complete. failure is quite different though - failure to deliver vs failure to search. Having had to deal with things like KoiR, Shift-JIS etc etc, it's non trivial. Frankly I'd avoid parsing wherever possible. An alternative would be to take another approach, where envelope is stored separately from the message itself, and combined with it at submission time when the copy is put into the sent folder. I don't see a strong reason to prohibit sending the same message more than once. Resending from my sent items folder is something I do quite often. They end up as another message in there. So It's implicitly a copy, edit, send. Adrien > > Bron. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From fanf2@hermes.cam.ac.uk Mon Feb 20 02:52:36 2012 Return-Path: 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 A7D0A21F875B for ; Mon, 20 Feb 2012 02:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EXlTHmdDhUEu for ; Mon, 20 Feb 2012 02:52:34 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2953221F8760 for ; Mon, 20 Feb 2012 02:52:33 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51454) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1RzQr6-0006jz-E6 (Exim 4.72) (return-path ); Mon, 20 Feb 2012 10:52:28 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RzQr6-0006Q4-86 (Exim 4.67) (return-path ); Mon, 20 Feb 2012 10:52:28 +0000 Date: Mon, 20 Feb 2012 10:52:28 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Bron Gondwana In-Reply-To: <20120219192604.GA11323@launde.brong.net> Message-ID: References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:52:36 -0000 Bron Gondwana wrote: > > 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. Use the Resent-* headers. (Pine/Alpine gets this right, though it uses 822 semantics rather than the better 2822 semantics.) > 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. message/rfc822 is also good. IMO every message that is forwarded or top-post replied should use message/rfc822 attachments rather than doing some fucked up redaction of the original message. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Westerly or southwesterly 6 to gale 8, occasionally severe gale 9 at first, veering northwesterly 4 or 5 later. Rough or very rough. Rain or squally showers. Good, occasionally poor. From fanf2@hermes.cam.ac.uk Mon Feb 20 02:55:17 2012 Return-Path: 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 9B0E121F8737 for ; Mon, 20 Feb 2012 02:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rmwhYiSPgPHY for ; Mon, 20 Feb 2012 02:55:13 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 49DF221F8732 for ; Mon, 20 Feb 2012 02:55:11 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52673) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RzQth-0000O6-Yk (Exim 4.72) (return-path ); Mon, 20 Feb 2012 10:55:09 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RzQth-0006vD-NK (Exim 4.67) (return-path ); Mon, 20 Feb 2012 10:55:09 +0000 Date: Mon, 20 Feb 2012 10:55:09 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Bron Gondwana In-Reply-To: Message-ID: References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:55:17 -0000 Tony Finch wrote: > > Use the Resent-* headers. ... in fact here's something I wrote on this topic six years ago ... http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rcpthdr.html Tony. -- f.anthony.n.finch http://dotat.at/ Northwest FitzRoy, Sole: Southerly 5 or 6. Rough, becoming moderate. Showers. Good. From brong@fastmail.fm Mon Feb 20 03:40:02 2012 Return-Path: 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 AB16C21F85D5 for ; Mon, 20 Feb 2012 03:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 pTR2MuMjH+dg for ; Mon, 20 Feb 2012 03:39:57 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7D93B21F84A6 for ; Mon, 20 Feb 2012 03:39:57 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7F1AA20B11 for ; Mon, 20 Feb 2012 06:39:56 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute3.internal (MEProxy); Mon, 20 Feb 2012 06:39:56 -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= dEVUXwJt89s4aJIBBJI+//ZudEk=; b=BvAUI8vyCHVLqoKdII7wkN+nAToCtLb6 1O3geoLUAwQLS4IQD6qLPczWlIQaggJMCTlgyxS5jvyFg5h/IBnxmN64+kcETW+U GBoUzbNW09JTHRwH/Eb7Wt1KcfiT7ssZChmh1DAUiACPQ11ILAz+T/sukmuDhmZf 5B+a262u0rQ= 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=dEVUXwJt89s4aJIBBJI+//ZudEk=; b= CZQK1HoDlLr/SdSHqz5kxK7QpjdFFBsWwshHfnZIDdghnZUQjzl0KkE5gz639lx5 JAk+NywnUS/G+mRZFn2MkFIpOFfqb9I9JAnnnTV5x5B0y7YCgTqhDknjRjluFDpX 6wqEPqiSC63GIi4R00qFKWR26HYQSJWWzFxPVhTUICk= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 553AEA000A0; Mon, 20 Feb 2012 06:39:56 -0500 (EST) Message-Id: <1329737996.22063.140661038826129@webmail.messagingengine.com> X-Sasl-Enc: MruABdsHl2JziKTkPJTd6oPtZXEZpQMvsTfAu71vy/gJ 1329737996 From: Bron Gondwana To: Tony Finch MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> In-Reply-To: Date: Mon, 20 Feb 2012 12:39:56 +0100 Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 11:40:02 -0000 On Mon, Feb 20, 2012, at 10:55 AM, Tony Finch wrote: > Tony Finch wrote: > > > > Use the Resent-* headers. > > ... in fact here's something I wrote on this topic six years ago ... > http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rcpthdr.html That reads like almost exactly what I have in mind. Bron. -- Bron Gondwana brong@fastmail.fm From brong@fastmail.fm Mon Feb 20 03:42:08 2012 Return-Path: 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 BD81121F8701 for ; Mon, 20 Feb 2012 03:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 FUmlN+OwvK9m for ; Mon, 20 Feb 2012 03:42:03 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 55D2D21F8636 for ; Mon, 20 Feb 2012 03:42:03 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D453B20BCF for ; Mon, 20 Feb 2012 06:41:57 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute5.internal (MEProxy); Mon, 20 Feb 2012 06:41:57 -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= fGzUwIc0twHIuOQiHzbOmx5+pBM=; b=g6fnOO0TCOi0PH3xCf6PHl4NL2JIfeOy dMdr0C//lCwyaEEnYHmCa2hkq4zJH8vinpWx6PcyNSOe1JIuJu/1J+EOOz+2vFvU LGsSlKqYkZqP2Y1btZMUoy/P4wuI9jpE3MgTqMamEEEt7eIVWD5OZRW5kZEo2lEJ TPxsA/W1EBk= 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=fGzUwIc0twHIuOQiHzbOmx5+pBM=; b= OEOmKf1ueS5fomOXhNhc0lgLgEzLLEyAr2G3HV76yXqhNVAcpael/6VkJZYBJq+u Wl3cNwNlPxWZoZESjTgUlA5inoZ5qPThK9ZCU6DgWouZ17oumM1MSVkGJ30z7/Pi rLlpUGIn1sWMItgwWWNCe90ruqFu75bWUbqf9t/lMr8= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id ABC75A000A0; Mon, 20 Feb 2012 06:41:57 -0500 (EST) Message-Id: <1329738117.22774.140661038826265@webmail.messagingengine.com> X-Sasl-Enc: RZlP8H3Ri8kJcGTr9aBG4G+b9iSxSuga1fbKepDw6KrN 1329738117 From: Bron Gondwana To: Adrien de Croy MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> In-Reply-To: <4F41952B.8020809@qbik.com> Date: Mon, 20 Feb 2012 12:41:57 +0100 Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 11:42:08 -0000 On Mon, Feb 20, 2012, at 01:34 PM, Adrien de Croy wrote: > i'm just talking about good old file system file copy, without parsing. Just our of interest, are you doing this with BURL now? If not, then a requirement to translate during copying is not an additional imposition on top of the IO and CPU hit you're currently getting from two different copies being sent through your system(s). If so, how do you handle the case where the client wants to store a BCC field in their "Sent Items" folder as a record of who it was really sent to? Bron. -- Bron Gondwana brong@fastmail.fm From fanf2@hermes.cam.ac.uk Mon Feb 20 03:57:01 2012 Return-Path: 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 145CC21F8759 for ; Mon, 20 Feb 2012 03:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6RLzH0ZyDj+q for ; Mon, 20 Feb 2012 03:56:57 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B321F8758 for ; Mon, 20 Feb 2012 03:56:56 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57740) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1RzRrM-0006I8-Qr (Exim 4.72) (return-path ); Mon, 20 Feb 2012 11:56:48 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RzRrM-0001E0-2o (Exim 4.67) (return-path ); Mon, 20 Feb 2012 11:56:48 +0000 Date: Mon, 20 Feb 2012 11:56:48 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dan White In-Reply-To: <20120217171457.GB4503@dan.olp.net> Message-ID: References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 11:57:01 -0000 Dan White wrote: > > In my opinion (and I admit I'm getting off topic), spam is merely a problem > rooted in relay. No, the spam problem comes from accepting messages from people you don't already know. This is of course a necessary feature of mail which is what makes spam so hard. (Actually not just that - it also comes from accepting messages from people you sort-of know but who don't care about wasting your time, such as corporate marketing departments.) Your federated authentication idea is pretty neat, and could be the basis of a better way of classifying mail from people you know or sort-of know. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Rockall, Malin: Southwesterly 5 to 7, occasionally gale 8 at first in Rockall and Malin. Rough, occasionally very rough in Rockall and Malin. Occasional rain. Moderate or good, occasionally poor. From adrien@qbik.com Mon Feb 20 04:31:01 2012 Return-Path: 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 D6EF221F86FC for ; Mon, 20 Feb 2012 04:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-1.059, 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 f-o2ZJrczbVi for ; Mon, 20 Feb 2012 04:30:57 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5A08521F8723 for ; Mon, 20 Feb 2012 04:30:55 -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 <0018872879@smtp.qbik.com>; Tue, 21 Feb 2012 01:30:52 +1300 Message-ID: <4F423CE4.5060103@qbik.com> Date: Tue, 21 Feb 2012 01:30:28 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Bron Gondwana References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> In-Reply-To: <1329738117.22774.140661038826265@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 12:31:01 -0000 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. On 21/02/2012 12:41 a.m., Bron Gondwana wrote: > > On Mon, Feb 20, 2012, at 01:34 PM, Adrien de Croy wrote: >> i'm just talking about good old file system file copy, without parsing. > Just our of interest, are you doing this with BURL now? > > If not, then a requirement to translate during copying is not an additional > imposition on top of the IO and CPU hit you're currently getting from > two different copies being sent through your system(s). > > If so, how do you handle the case where the client wants to store a > BCC field in their "Sent Items" folder as a record of who it was > really sent to? > > Bron. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From filip.navara@gmail.com Mon Feb 20 04:43:32 2012 Return-Path: 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 4F16321F86F0 for ; Mon, 20 Feb 2012 04:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 CknQ9qYxRcxH for ; Mon, 20 Feb 2012 04:43:27 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3592621F872B for ; Mon, 20 Feb 2012 04:43:27 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8184414obb.31 for ; Mon, 20 Feb 2012 04:43:26 -0800 (PST) Received-SPF: pass (google.com: domain of filip.navara@gmail.com designates 10.60.3.72 as permitted sender) client-ip=10.60.3.72; Authentication-Results: mr.google.com; spf=pass (google.com: domain of filip.navara@gmail.com designates 10.60.3.72 as permitted sender) smtp.mail=filip.navara@gmail.com; dkim=pass header.i=filip.navara@gmail.com Received: from mr.google.com ([10.60.3.72]) by 10.60.3.72 with SMTP id a8mr9763376oea.19.1329741806855 (num_hops = 1); Mon, 20 Feb 2012 04:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vv7NzPcIqxOwn7+tpwySkiy/OBWcheeMLx6KGkTGJpo=; b=jGj6s6QsPcypcNOOle6e6vFKpoZcjONixgHg3fAEf2qlv4HtpynZho2753tsUDtGf3 kmNPsQx2L8XxdaBemiLDIe2KD6Xe2MOEgIqUlfH0cEgHdFtoRHYP44LElIr6xNJn71xJ A087Bb16fboO3zh4gulSdaqrNHFkeSdZX6EyQ= MIME-Version: 1.0 Received: by 10.60.3.72 with SMTP id a8mr8390158oea.19.1329741806121; Mon, 20 Feb 2012 04:43:26 -0800 (PST) Received: by 10.182.74.8 with HTTP; Mon, 20 Feb 2012 04:43:25 -0800 (PST) In-Reply-To: <4F423CE4.5060103@qbik.com> References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> Date: Mon, 20 Feb 2012 13:43:25 +0100 Message-ID: From: Filip Navara To: Adrien de Croy Content-Type: multipart/alternative; boundary=e89a8fb1ee2aff330304b964a36c Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 12:43:32 -0000 --e89a8fb1ee2aff330304b964a36c Content-Type: text/plain; charset=ISO-8859-1 JYFI, we (eM Client, www.emclient.com) do use BURL in some cases. F. On Mon, Feb 20, 2012 at 1:30 PM, Adrien de Croy 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. > > > On 21/02/2012 12:41 a.m., Bron Gondwana wrote: > >> >> On Mon, Feb 20, 2012, at 01:34 PM, Adrien de Croy wrote: >> >>> i'm just talking about good old file system file copy, without parsing. >>> >> Just our of interest, are you doing this with BURL now? >> >> If not, then a requirement to translate during copying is not an >> additional >> imposition on top of the IO and CPU hit you're currently getting from >> two different copies being sent through your system(s). >> >> If so, how do you handle the case where the client wants to store a >> BCC field in their "Sent Items" folder as a record of who it was >> really sent to? >> >> Bron. >> > > -- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com > > ______________________________**_________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/**listinfo/imap5 > --e89a8fb1ee2aff330304b964a36c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable JYFI, we (eM Client, www.emclient.com) do use BURL in some cases.

F.

On Mon, Feb 20, 2012 at 1:30 PM, Adrien de Croy <adrien@qbik.com> wr= ote:

We didn't implement BURL (HURL).

It was just too far over the insanity horizon to write an IMAP client for t= hat 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.


On 21/02/2012 12:41 a.m., Bron Gondwana wrote:

On Mon, Feb 20, 2012, at 01:34 PM, Adrien de Croy wrote:
i'm just talking about good old file system file copy, without parsing.=
Just our of interest, are you doing this with BURL now?

If not, then a requirement to translate during copying is not an additional=
imposition on top of the IO and CPU hit you're currently getting from two different copies being sent through your system(s).

If so, how do you handle the case where the client wants to store a
BCC field in their "Sent Items" folder as a record of who it was<= br> really sent to?

Bron.

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

_______________________________________________
imap5 mailing list
imap5@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/imap5

--e89a8fb1ee2aff330304b964a36c-- From brong@fastmail.fm Mon Feb 20 05:13:57 2012 Return-Path: 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 C03A621F8596 for ; Mon, 20 Feb 2012 05:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 funL3eYXu-Wt for ; Mon, 20 Feb 2012 05:13:52 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5E921F8472 for ; Mon, 20 Feb 2012 05:13:52 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1B00720780 for ; Mon, 20 Feb 2012 08:13:52 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 20 Feb 2012 08:13:52 -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= SNJQ0Co3BMI5uiUz0zWdyYIKDbc=; b=JUcmU/xfu2eA/CG3wg0Ex+vz3JTqFc4v Z719kGCxKtFgrzHdETyU4p1s6XggoX3LPkDC9h/Pj8Xj4Z4asmNDNgcuSl2eDCwc YzPPm1YyiMTHJcXS8LppTPv/gAYJcaRrTqbiHidSJaQ5CnhIoJ4CnHLYuE9lCLg2 Lgp896QZ/bI= 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=SNJQ0Co3BMI5uiUz0zWdyYIKDbc=; b= fxP/9QWy3xGVIXMTp7xMTZfn7qAzde1nQv9mVix2u0t8YAX5hvu9cBN7zmr8zq+8 9j/AJ1XBWjeDaYB+iAyuM19t9J1PCiWWUNRzT9R8rOcN8puA7JlL6G7H8cA/VH9T +bSZ2yuID6lW/XeKOh3w3DQ6QOY+XOf6DzlcXI6/hSc= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id E0382A000DB; Mon, 20 Feb 2012 08:13:51 -0500 (EST) Message-Id: <1329743631.12698.140661038857849@webmail.messagingengine.com> X-Sasl-Enc: dj2C6eZDzYDItpaP1sSCaqVqdcJcu9iUH+00/yDh5gxn 1329743631 From: Bron Gondwana To: Filip Navara , Adrien de Croy MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <4F3D6E57.8010301@qbik.com><4F3F4F8F.3040601@qbik.com><1329550573.30138.140661038121885@webmail.messagingengine.com><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> In-Reply-To: Date: Mon, 20 Feb 2012 14:13:51 +0100 Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 13:13:57 -0000 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 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. -- Bron Gondwana brong@fastmail.fm From brong@fastmail.fm Mon Feb 20 05:27:20 2012 Return-Path: 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 3609321F860B for ; Mon, 20 Feb 2012 05:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 4tdveNmqYYnQ for ; Mon, 20 Feb 2012 05:27:15 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE7F21F871B for ; Mon, 20 Feb 2012 05:27:15 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B627620A44 for ; Mon, 20 Feb 2012 08:27:14 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 20 Feb 2012 08:27: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= 82wO3SbFLHFQbB94XMSwRxwGx08=; b=ChL6QQcsU1xUKjVUR5FSlfZLT6LFrm8l buLJN3JScQOzWL+os4h0pyU2qbyI/niKBtmskhgYRfrLkjNN9Riti6yWVZCN4q+T DsAktVoAlC2tQSRq52iJtEG4Ojp5zPnRk7wq0pfahNnFtqiR3q7XemiiBJAuplZ1 90XIhmiLCv0= 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=82wO3SbFLHFQbB94XMSwRxwGx08=; b= OpWyUzFGDf4pA1+SVOMwr+WfZC297TXOL/9SVZHUrjEMS0S4UGbg+KyN/3TPkKLI F9aVuafix1jeOM/7WDi1gE5GxiHI1gb5Fm0nSGuPehgRcxTKac9zsTSDiSLz5JYM K1mMKyAu9K44l2H5Xtjbm93AYk30HyqIXx0DpiQTU1I= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 916DFA000A0; Mon, 20 Feb 2012 08:27:14 -0500 (EST) Message-Id: <1329744434.16008.140661038859217@webmail.messagingengine.com> X-Sasl-Enc: 8I/5VFoTwk7HGP5EVvnDGH/acTa5/Ygq4LcPWBgkUj4/ 1329744434 From: Bron Gondwana To: Adrien de Croy MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> In-Reply-To: <4F41952B.8020809@qbik.com> Date: Mon, 20 Feb 2012 14:27:14 +0100 Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 13:27:20 -0000 On Mon, Feb 20, 2012, at 01:34 PM, Adrien de Croy wrote: > > > On 20/02/2012 12:39 p.m., Bron Gondwana wrote: > > On Mon, Feb 20, 2012 at 12:00:05PM +1300, Adrien de Croy wrote: > >> Another problem is auto-responders, where commonly you specify a > >> blackhole or empty return path to avoid loops. > > Not a user client. > > check out RFC 6409 Sec 3.2 para 5 re NULL return paths. > > Clients do commonly auto respond. Yep, got that. And thanks, I'll add RFC 6409 to the list of RFCs on the wiki. Done. If client do send an auto-response with a NULL return path, do they usually store a copy of that message on the server at all? I would imagine they don't. I also see from the KEYWORDS rfc (5788) that $MDNSent is registered for the MDN purpose. It almost seems that a SENDMDN command is what is indicated for this usage. Again, the "client can't screw it up" philosophy. Bron. -- Bron Gondwana brong@fastmail.fm From dave@cridland.net Mon Feb 20 05:27:33 2012 Return-Path: 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 A37F921F8771 for ; Mon, 20 Feb 2012 05:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 5+jlZXLLkuP3 for ; Mon, 20 Feb 2012 05:27:28 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id E67C521F860B for ; Mon, 20 Feb 2012 05:27:27 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 925E7116808D; Mon, 20 Feb 2012 13:27:24 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85UQOVWfQHi4; Mon, 20 Feb 2012 13:27:15 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id D11531168067; Mon, 20 Feb 2012 13:27:14 +0000 (GMT) References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> In-Reply-To: MIME-Version: 1.0 Message-Id: <16456.1329744434.840052@puncture> Date: Mon, 20 Feb 2012 13:27:14 +0000 From: Dave Cridland To: Filip Navara , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." , Adrien de Croy Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 13:27:33 -0000 On Mon Feb 20 12:43:25 2012, Filip Navara wrote: > JYFI, we (eM Client, www.emclient.com) do use BURL in some cases. > > As does the Qt Messaging Framework. (And Polymer, and Isode's M-Switch/M-Box, and ... ) That all said, I'm swinging around to the notion of sending mail through the message store access protocol: If we have a command which sends a particular mail *with an envelope*, then I think we can map all ESMTP stuff to it - but rather more interestingly, we can keep the envelope around as metadata within the store. This allows things which you simply cannot do with BURL, for instance: 1) We could track bounces using VERP, and annotate the message when a DSN is received, so you could see which sent messages have failed. 2) We could track MDNs in a similar way. You'd want multiple envelopes on a message, to handle resends and redirects, and it seems sensible to capture the S/LMTP envelope on delivery, too, such that a client would have sufficient information to cause a (delayed) bounce. I appreciate this appears to be a U-turn on my behalf - that's because it is. I don't see multiple protocols as being a show-stopper, but the comments about DSN/MDN processing sparked this chain of thought for me. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From fanf2@hermes.cam.ac.uk Mon Feb 20 05:30:35 2012 Return-Path: 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 29C0721F872B for ; Mon, 20 Feb 2012 05:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uXPtafyoOQR2 for ; Mon, 20 Feb 2012 05:30:31 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6297621F86E5 for ; Mon, 20 Feb 2012 05:30:24 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:59809) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1RzTJr-00086L-Sx (Exim 4.72) (return-path ); Mon, 20 Feb 2012 13:30:20 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RzTJr-0001NB-U6 (Exim 4.67) (return-path ); Mon, 20 Feb 2012 13:30:19 +0000 Date: Mon, 20 Feb 2012 13:30:19 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Bron Gondwana In-Reply-To: <1329744434.16008.140661038859217@webmail.messagingengine.com> Message-ID: References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 13:30:35 -0000 Bron Gondwana 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. -- f.anthony.n.finch http://dotat.at/ Trafalgar: North 4 or 5. Moderate. Fair. Good. From brong@fastmail.fm Mon Feb 20 05:33:30 2012 Return-Path: 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 81D8021F847D for ; Mon, 20 Feb 2012 05:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 FqGWIBajZwfx for ; Mon, 20 Feb 2012 05:33:25 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBA021F86A6 for ; Mon, 20 Feb 2012 05:33:25 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id F297B2085A for ; Mon, 20 Feb 2012 08:33:24 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 20 Feb 2012 08:33:24 -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= ZOQTrjCtXNoF4sFp65wBRxYWmkk=; b=FLDVw4PJ1fkU+qnd1L0uef0h6WfV9LI9 gqkUady+4U/TfQLYEbYy5qHFX7HmGhwLQ3CKYNYL7X3+iXJNPryCNSZuaO9amTW3 160t2yZg70//rISFiSwtPDbjVNEyrDeJLb9yKO1elo3887vuiwhrncu1+9yb9jl0 iHfdMNRjsVc= 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=ZOQTrjCtXNoF4sFp65wBRxYWmkk=; b= nCvhM3t+yNP6+RqCxKC/KThiBOOm+x2SviJVtnnYiKwdMsLG4cYIJXUR/ju9FDd9 trcM4Zwea3fvLvXKBDYvbcTO5VjAcCqNGM2Xw2in5qSZVYJBmMNkZShCukKPFPIj yb/JfqLfuKyas5E8il8e++VMUOIjuEymUoyQSYFkXCs= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id CB42CA000A0; Mon, 20 Feb 2012 08:33:24 -0500 (EST) Message-Id: <1329744804.17472.140661038865297@webmail.messagingengine.com> X-Sasl-Enc: x8UVcJKAJCscj5UvdcxmnOoXFkpF11Eg7XFW6ImEewv5 1329744804 From: Bron Gondwana To: Tony Finch MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> In-Reply-To: Date: Mon, 20 Feb 2012 14:33:24 +0100 Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 13:33:30 -0000 On Mon, Feb 20, 2012, at 01:30 PM, Tony Finch wrote: > Bron Gondwana 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. Good luck selling that one. Some sort of "it got received/seen" is wanted by a great many users. I'm not sure if Facebook provides it, but Exchange certainly does. Bron. -- Bron Gondwana brong@fastmail.fm From filip.navara@gmail.com Mon Feb 20 06:05:18 2012 Return-Path: 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 389FE21F8757 for ; Mon, 20 Feb 2012 06:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, 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 10qW75yrxwqM for ; Mon, 20 Feb 2012 06:05:13 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDCF921F8755 for ; Mon, 20 Feb 2012 06:05:13 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8296296obb.31 for ; Mon, 20 Feb 2012 06:05:13 -0800 (PST) Received-SPF: pass (google.com: domain of filip.navara@gmail.com designates 10.182.75.102 as permitted sender) client-ip=10.182.75.102; Authentication-Results: mr.google.com; spf=pass (google.com: domain of filip.navara@gmail.com designates 10.182.75.102 as permitted sender) smtp.mail=filip.navara@gmail.com; dkim=pass header.i=filip.navara@gmail.com Received: from mr.google.com ([10.182.75.102]) by 10.182.75.102 with SMTP id b6mr13534840obw.9.1329746713495 (num_hops = 1); Mon, 20 Feb 2012 06:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+e1hvhVFWW370VvLIld3Fxb3Vi3x2BfSQmzNmcX5jN0=; b=UP0UXUNF4Z4HCCueo67sPt+phQzApMPu2McspcDUxIgV1Y9YIA8SPZo3aQ7sGyttK6 nTLOQkoihr6M63pmU5+aByliOSWr9EpMyw1T9bSvT0xkFwX4kC8aYSRG/SBE9Sx69tDi 2YnVQVJ7LEddiZVFB5kDbW1byUN/bbK2+iXyA= MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr11480947obw.9.1329746713043; Mon, 20 Feb 2012 06:05:13 -0800 (PST) Received: by 10.182.74.8 with HTTP; Mon, 20 Feb 2012 06:05:12 -0800 (PST) In-Reply-To: <1329743631.12698.140661038857849@webmail.messagingengine.com> References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> <1329743631.12698.140661038857849@webmail.messagingengine.com> Date: Mon, 20 Feb 2012 15:05:12 +0100 Message-ID: From: Filip Navara To: Bron Gondwana Content-Type: multipart/alternative; boundary=14dae93994a978e1bb04b965c85d Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:05:18 -0000 --14dae93994a978e1bb04b965c85d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 20, 2012 at 2:13 PM, 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? We don't use BURL for mails with BCC. In theory we could use CHUNKING+BURL, but we never implemented it. F. --14dae93994a978e1bb04b965c85d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 20, 2012 at 2:13 PM, Bron Gondwana <= span dir=3D"ltr"><brong@fastmail.fm= > 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?
=A0
We don't us= e BURL for mails with BCC. In theory we could use CHUNKING+BURL, but we nev= er implemented it.

F.
--14dae93994a978e1bb04b965c85d-- From dave@cridland.net Mon Feb 20 06:15:33 2012 Return-Path: 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 479A321F86AF for ; Mon, 20 Feb 2012 06:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] 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 yww74Lvosioq for ; Mon, 20 Feb 2012 06:15:27 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id A040421F8745 for ; Mon, 20 Feb 2012 06:15:27 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 379E81168087; Mon, 20 Feb 2012 14:15:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb1AQ25CKqOJ; Mon, 20 Feb 2012 14:15:17 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id C66F41168067; Mon, 20 Feb 2012 14:15:17 +0000 (GMT) References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> <1329743631.12698.140661038857849@webmail.messagingengine.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <16456.1329747317.802075@puncture> Date: Mon, 20 Feb 2012 14:15:17 +0000 From: Dave Cridland To: Filip Navara , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." , Bron Gondwana Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:15:33 -0000 On Mon Feb 20 14:05:12 2012, Filip Navara wrote: > On Mon, Feb 20, 2012 at 2:13 PM, 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? > > > We don't use BURL for mails with BCC. In theory we could use > CHUNKING+BURL, > but we never implemented it. Right - if you sent the header first with HEADER.FIELDS.NOT, and then send the body, you can do it. Polymer just never puts BCC into the mail at all, which has alternate problems. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From brong@fastmail.fm Mon Feb 20 06:35:44 2012 Return-Path: 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 29CF821F844D for ; Mon, 20 Feb 2012 06:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 xeRef00vdNc2 for ; Mon, 20 Feb 2012 06:35:36 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 655E821F847B for ; Mon, 20 Feb 2012 06:35:36 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1F65220A4F for ; Mon, 20 Feb 2012 09:35:36 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute3.internal (MEProxy); Mon, 20 Feb 2012 09:35:36 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= hh0AKdJVRHjMGVBpmB80C2E+kVU=; b=YxAghTRfpvAVSklsrBE17O9z0idRPA6I Nb3PV6uqrR2cPjWOpUe+I1zSw9sKAPP8g0XhqPLNTUdkZQuzd5bP7WOrQA2REcCd hK7OrhuP1RWQq7QWswloOpP6qnTpdr/NEWgcRLMP8m5Eun8CGVDF01qmx0e3SbuI tEwvYQHJrhI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=hh0AKdJVRHjMGVBpmB80C2E+kVU=; b=WW7 tarjH5rWGoFpVIgNtoJOeFBbSmeBwWlpbZtVpItzHZpe5AL2S4j3Kb1PZz0cr67j Fr+6twVofLoDPj9ABVQ2yHT0suUeFnKyHl6sMj49qZyACzWS2j7MvlPzJlSOPo6m vUhwz5Og73+hHU5kZ0p3gX9vxygr80xo7QBW+P7M= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id E6E74A000A0; Mon, 20 Feb 2012 09:35:35 -0500 (EST) Message-Id: <1329748535.2585.140661038887405@webmail.messagingengine.com> X-Sasl-Enc: mTyemvfyS5eJXSR4UaxbzKTqDTGI6KsAS72XLyRnenVj 1329748535 From: Bron Gondwana To: Dave Cridland , Filip Navara , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." , Adrien de Croy MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <16456.1329744434.840052@puncture> References: <4F3D6E57.8010301@qbik.com><4F3F4F8F.3040601@qbik.com><1329550573.30138.140661038121885@webmail.messagingengine.com><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> <16456.1329744434.840052@puncture> Date: Mon, 20 Feb 2012 15:35:35 +0100 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:35:44 -0000 On Mon, Feb 20, 2012, at 01:27 PM, Dave Cridland wrote: > On Mon Feb 20 12:43:25 2012, Filip Navara wrote: > > JYFI, we (eM Client, www.emclient.com) do use BURL in some cases. > > > > > As does the Qt Messaging Framework. > > (And Polymer, and Isode's M-Switch/M-Box, and ... ) > > That all said, I'm swinging around to the notion of sending mail > through the message store access protocol: > > If we have a command which sends a particular mail *with an > envelope*, then I think we can map all ESMTP stuff to it - but rather > more interestingly, we can keep the envelope around as metadata > within the store. > > This allows things which you simply cannot do with BURL, for instance: > > 1) We could track bounces using VERP, and annotate the message when a > DSN is received, so you could see which sent messages have failed. > > 2) We could track MDNs in a similar way. > > You'd want multiple envelopes on a message, to handle resends and > redirects, and it seems sensible to capture the S/LMTP envelope on > delivery, too, such that a client would have sufficient information > to cause a (delayed) bounce. > > I appreciate this appears to be a U-turn on my behalf - that's > because it is. I don't see multiple protocols as being a > show-stopper, but the comments about DSN/MDN processing sparked this > chain of thought for me. I'm beginning to appreciate the "multiple envelopes" idea as well actually, particularly reading your thoughts. It probably means storing annotations - or at least providing a way to access this envelope data that smells remarkably like annotations. In which case I wouldn't be adverse to having the envelope in the protocol if it's stored with the message as well. The hard part then is bolting it on to existing server implementations, since we need to store it SOMEWHERE. At FastMail we add 'X-Delivered-To' and 'X-Mail-From' headers which capture at least that much of the envelope. That happens during the LMTP proxy stage, where spam scanning and cleanups are done. (Postfix on the MX passes ORCPT via LMTP, we patch that in.) The downside of out-of-band metadata is that everything needs to support it. Otherwise you can't even see it. If it's in-band in the message, you can transfer it via intermediate stages that don't understand it - so you can download it via a dumb client, then operate on the local copy. Of course, with this theoretical protocol, annotations would have to stay alongside. Potentially mutable annotations. Bron. -- Bron Gondwana brong@fastmail.fm From dave@cridland.net Mon Feb 20 06:44:12 2012 Return-Path: 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 7D11721F853B for ; Mon, 20 Feb 2012 06:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 MhuebD8mEpBB for ; Mon, 20 Feb 2012 06:44:07 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 2E94321F8526 for ; Mon, 20 Feb 2012 06:44:07 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8CC3D1168087; Mon, 20 Feb 2012 14:44:04 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+U4ncH83RTb; Mon, 20 Feb 2012 14:43:57 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 3A2A71168067; Mon, 20 Feb 2012 14:43:57 +0000 (GMT) References: =?US-ASCII?Q?<4F3D6E57.8010301@qb?= =?US-ASCII?Q?k.com><4F3F4F8F.3040601@qbik.co?= =?US-ASCII?Q?><1329550573.30138.140661038121885@webmail.me?= =?US-ASCII?Q?sagingengine.com><2012021919260?= =?US-ASCII?Q?.GA11323@launde.brong.net>?= <4F415C07.3040100@qbik.com><20120219220835.GB12549@launde.brong.net> <4F417EF5.6030809@qbik.com><20120219233901.GA13600@launde.brong.net> =?US-ASCII?Q?<4F41952B.8020809@qbik.com><1329738117.22774.140661038826265@webmail.messagingengine.com><4F423CE4.5060103@qbik.com>?= <16456.1329744434.840052@puncture> <1329748535.2585.140661038887405@webmail.messagingengine.com> In-Reply-To: <1329748535.2585.140661038887405@webmail.messagingengine.com> MIME-Version: 1.0 Message-Id: <16456.1329749037.223665@puncture> Date: Mon, 20 Feb 2012 14:43:57 +0000 From: Dave Cridland To: Bron Gondwana , Filip Navara , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP\." , Adrien de Croy Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:44:12 -0000 On Mon Feb 20 14:35:35 2012, Bron Gondwana wrote: > It probably means storing annotations - or at least providing a way > to access this envelope data that smells remarkably like > annotations. No. Store it as a properly modelled transport envelope - no need to turn it into magic soup - that's never worked. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From brong@fastmail.fm Mon Feb 20 06:46:45 2012 Return-Path: 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 7917C21F86F2 for ; Mon, 20 Feb 2012 06:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 4ykE1ut0pEgf for ; Mon, 20 Feb 2012 06:46:41 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 34E8921F8535 for ; Mon, 20 Feb 2012 06:46:41 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D1A7020738 for ; Mon, 20 Feb 2012 09:46:40 -0500 (EST) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 20 Feb 2012 09:46:40 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= cYvzDUw0Ja/qQdyCVQ9C9/RxZ3g=; b=pIsATu0a2JD2BiearHl+EYb94cP8kXPb s9SumkgT//GB6dUYbpu4TGtYev5L9ri3UdiZ4BMrVobEVydEtnKbDQ9fNkTo3lLq esciAUw8XOJJcspLOqxUEv54e9vzlh9yjYsPD3/XlV/kEsNV3lgVGfr8qMrsS7ry CYlVEFZj9JU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=cYvzDUw0Ja/qQdyCVQ9C9/RxZ3g=; b=Sra ZUF+kuIoFTuW0qxiPPS1ataTG+IeUw8PIOE/uMtHBooCtrq0SCAkIFZuZnktpVri CEEr6zo/8d8bnxaztd6XNX9TNdUQH/tf0gQHPgLq/OE1Mf+Ph1CEAR7VHAmOVm61 Iyy42w49pOp9MVmMH1f/Oewzw3IvJSUQ2Levg+OE= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id A79B8A000A0; Mon, 20 Feb 2012 09:46:40 -0500 (EST) Message-Id: <1329749200.5849.140661038894569@webmail.messagingengine.com> X-Sasl-Enc: KSTpZvQzCGBwJsbxzy1saVN8SjkjTEpdJOvZCc/S6SDo 1329749200 From: Bron Gondwana To: Dave Cridland , Filip Navara , Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." , Adrien de Croy MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <16456.1329749037.223665@puncture> References: <4F3D6E57.8010301@qbk.com><4F3F4F8F.3040601@qbik.co><1329550573.30138.140661038121885@webmail.mesagingengine.com><2012021919260.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> <16456.1329744434.840052@puncture><1329748535.2585.140661038887405@webmail.messagingengine.com> <16456.1329749037.223665@puncture> Date: Mon, 20 Feb 2012 15:46:40 +0100 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:46:45 -0000 On Mon, Feb 20, 2012, at 02:43 PM, Dave Cridland wrote: > On Mon Feb 20 14:35:35 2012, Bron Gondwana wrote: > > It probably means storing annotations - or at least providing a way > > to access this envelope data that smells remarkably like > > annotations. > > No. > > Store it as a properly modelled transport envelope - no need to turn > it into magic soup - that's never worked. Fine with me. It's just yet another axis of data tied to a message, and it needs its very own "keywords" or "annotations" as well, presumably, if you want to note when it was accepted, or MDNed. Bron. -- Bron Gondwana brong@fastmail.fm From fanf2@hermes.cam.ac.uk Mon Feb 20 06:49:40 2012 Return-Path: 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 DC13921F8620 for ; Mon, 20 Feb 2012 06:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1tRSD0OiveGq for ; Mon, 20 Feb 2012 06:49:37 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id D3D8921F864C for ; Mon, 20 Feb 2012 06:49:36 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:47078) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RzUYX-0006Nf-WX (Exim 4.72) (return-path ); Mon, 20 Feb 2012 14:49:33 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RzUYW-0007nJ-Lz (Exim 4.67) (return-path ); Mon, 20 Feb 2012 14:49:32 +0000 Date: Mon, 20 Feb 2012 14:49:32 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Bron Gondwana In-Reply-To: <1329748535.2585.140661038887405@webmail.messagingengine.com> Message-ID: References: <4F3D6E57.8010301@qbik.com><4F3F4F8F.3040601@qbik.com><1329550573.30138.140661038121885@webmail.messagingengine.com><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> <16456.1329744434.840052@puncture> <1329748535.2585.140661038887405@webmail.messagingengine.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:49:41 -0000 Bron Gondwana wrote: > > The downside of out-of-band metadata is that everything needs to > support it. Otherwise you can't even see it. If it's in-band in > the message, you can transfer it via intermediate stages that don't > understand it - so you can download it via a dumb client, then > operate on the local copy. I think this is very important. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire, South Utsire: Southwesterly 6 to gale 8, occasionally severe gale 9 at first in Viking and North Utsire, veering northwesterly 4 or 5, becoming variable 3 or 4 later. Rough or very rough. Rain or showers. Good, occasionally poor. From adrien@qbik.com Mon Feb 20 11:50:45 2012 Return-Path: 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 ; 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 ; 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 ; 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 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Bron Gondwana References: <4F3D6E57.8010301@qbik.com><4F3F4F8F.3040601@qbik.com><1329550573.30138.140661038121885@webmail.messagingengine.com><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> <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 , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From adrien@qbik.com Mon Feb 20 11:52:15 2012 Return-Path: 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 E69D321F865F for ; Mon, 20 Feb 2012 11:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.621 X-Spam-Level: X-Spam-Status: No, score=-3.621 tagged_above=-999 required=5 tests=[AWL=-1.022, 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 YfSwYqztjWHl for ; Mon, 20 Feb 2012 11:52:15 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1040221F864E for ; Mon, 20 Feb 2012 11:52:14 -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 <0018873507@smtp.qbik.com>; Tue, 21 Feb 2012 08:52:13 +1300 Message-ID: <4F42A46E.2000901@qbik.com> Date: Tue, 21 Feb 2012 08:52:14 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Bron Gondwana References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> In-Reply-To: <1329744434.16008.140661038859217@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:52:16 -0000 On 21/02/2012 2:27 a.m., Bron Gondwana wrote: > > On Mon, Feb 20, 2012, at 01:34 PM, Adrien de Croy wrote: >> >> On 20/02/2012 12:39 p.m., Bron Gondwana wrote: >>> On Mon, Feb 20, 2012 at 12:00:05PM +1300, Adrien de Croy wrote: >>>> Another problem is auto-responders, where commonly you specify a >>>> blackhole or empty return path to avoid loops. >>> Not a user client. >> check out RFC 6409 Sec 3.2 para 5 re NULL return paths. >> >> Clients do commonly auto respond. > Yep, got that. And thanks, I'll add RFC 6409 to the list of RFCs on > the wiki. Done. > > If client do send an auto-response with a NULL return path, do they > usually store a copy of that message on the server at all? I would > imagine they don't. Actually I think they do. I've had MDNs turned off since dot, but I've seen such messages in sent items folders before. > > I also see from the KEYWORDS rfc (5788) that $MDNSent is registered > for the MDN purpose. It almost seems that a SENDMDN command is what > is indicated for this usage. Again, the "client can't screw it up" > philosophy. sure. Gives the server the freedom to implement it the way they see fit as well. > > Bron. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From adrien@qbik.com Mon Feb 20 11:57:48 2012 Return-Path: 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 1658421F85F0 for ; Mon, 20 Feb 2012 11:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.603 X-Spam-Level: X-Spam-Status: No, score=-3.603 tagged_above=-999 required=5 tests=[AWL=-1.004, 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 GR8EHTvvn185 for ; Mon, 20 Feb 2012 11:57:46 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id E852E21F861A for ; Mon, 20 Feb 2012 11:57: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 <0018873516@smtp.qbik.com>; Tue, 21 Feb 2012 08:57:42 +1300 Message-ID: <4F42A5B6.2020301@qbik.com> Date: Tue, 21 Feb 2012 08:57:42 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> <16456.1329744434.840052@puncture> In-Reply-To: <16456.1329744434.840052@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:57:48 -0000 On 21/02/2012 2:27 a.m., Dave Cridland wrote: > On Mon Feb 20 12:43:25 2012, Filip Navara wrote: >> JYFI, we (eM Client, www.emclient.com) do use BURL in some cases. >> >> > As does the Qt Messaging Framework. > > (And Polymer, and Isode's M-Switch/M-Box, and ... ) OK, I'm not familiar with any of these clients. Most of our customers are running windows on the desktop. Anyone know of any windows-based clients that use BURL? > > That all said, I'm swinging around to the notion of sending mail > through the message store access protocol: > > If we have a command which sends a particular mail *with an envelope*, > then I think we can map all ESMTP stuff to it - but rather more > interestingly, we can keep the envelope around as metadata within the > store. > > This allows things which you simply cannot do with BURL, for instance: > > 1) We could track bounces using VERP, and annotate the message when a > DSN is received, so you could see which sent messages have failed. > > 2) We could track MDNs in a similar way. > > You'd want multiple envelopes on a message, to handle resends and > redirects, and it seems sensible to capture the S/LMTP envelope on > delivery, too, such that a client would have sufficient information to > cause a (delayed) bounce. > > I appreciate this appears to be a U-turn on my behalf - that's because > it is. I don't see multiple protocols as being a show-stopper, but the > comments about DSN/MDN processing sparked this chain of thought for me. People nowadays are used to instant feedback. So a 4 hour-later delivery warning is not well received. Some systems you only find out 2 days later that your mail couldn't be delivered. You might have missed the deal at that stage. There's no technical reason why a system can't be designed and built that would provide pretty much immediate feedback to a mail submitter as to the outcome of the delivery. And I'd like to even check parameters before that as well. It won't work in all cases, since there are still many clients that are not connected full-time to the network. But it can work in enough cases to provide real benefits. There are of course all manner of commercial roadblocks to that, such as what protocols are deployed. But there are ways to migrate to new protocols if there are enough compelling reasons to do so. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From adrien@qbik.com Mon Feb 20 12:23:49 2012 Return-Path: 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 ; 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 ; 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 ; 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 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Tony Finch References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From adrien@qbik.com Mon Feb 20 12:36:11 2012 Return-Path: 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 7BDD121F85B7 for ; Mon, 20 Feb 2012 12:36:11 -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 yrOTJtI6VOLt for ; Mon, 20 Feb 2012 12:36:10 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 24A2F21F852A for ; Mon, 20 Feb 2012 12:36:09 -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 <0018873559@smtp.qbik.com>; Tue, 21 Feb 2012 09:36:08 +1300 Message-ID: <4F42AEB0.4040901@qbik.com> Date: Tue, 21 Feb 2012 09:36:00 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Tony Finch References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> <4F42ABC1.2040507@qbik.com> In-Reply-To: <4F42ABC1.2040507@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:36:11 -0000 the reason I bring this up. Even though we may not fix SMTP MDN issues etc in a long time, if we build protocol support for notifying a client about things relating to delivery etc, then we can a) implement it initially with server-side heuristics if at all (e.g. recognise and strip bounce messages, or deliver them to a special folder and notify) b) move to a deterministic model once it becomes available So it affects what we do now with whatever client-server stuff we do now. Adrien On 21/02/2012 9:23 a.m., Adrien de Croy wrote: > > 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 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 From fanf2@hermes.cam.ac.uk Mon Feb 20 15:53:13 2012 Return-Path: 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 9D88A21E8010 for ; Mon, 20 Feb 2012 15:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 xP+b61nAlFwx for ; Mon, 20 Feb 2012 15:53:12 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 68B3421F85F0 for ; Mon, 20 Feb 2012 15:53:12 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38831) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Rzd2Z-0007Jc-qM (Exim 4.72) (return-path ); Mon, 20 Feb 2012 23:53:07 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Rzd2Z-00024u-6B (Exim 4.67) (return-path ); Mon, 20 Feb 2012 23:53:07 +0000 Date: Mon, 20 Feb 2012 23:53:07 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Adrien de Croy In-Reply-To: <4F42ABC1.2040507@qbik.com> Message-ID: References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> <4F42ABC1.2040507@qbik.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 23:53:13 -0000 Adrien de Croy wrote: > > 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. That's what null return paths are for. Exchange doesn't implement auto-replies properly so they don't work as they should. > It would need to be clearly defined, machine readable etc. It could be stored > and forwarded, and moved over the same transport. Already done. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: North 4 or 5. Moderate. Fair. Good. From adrien@qbik.com Mon Feb 20 16:13:08 2012 Return-Path: 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 AC38C21E8016 for ; Mon, 20 Feb 2012 16:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=-0.987, 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 m2bCN6eYcLrb for ; Mon, 20 Feb 2012 16:13:07 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6B70421F85B6 for ; Mon, 20 Feb 2012 16:13:06 -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 3384)) with SMTP id <0018873884@smtp.qbik.com>; Tue, 21 Feb 2012 13:13:05 +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 <0010062482@sago.qbik.com>; Tue, 21 Feb 2012 13:12:50 +1300 Message-ID: <4F42E182.8020509@qbik.com> Date: Tue, 21 Feb 2012 13:12:50 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Tony Finch References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> <4F42ABC1.2040507@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 00:13:08 -0000 On 21/02/2012 12:53 p.m., Tony Finch wrote: > Adrien de Croy wrote: >> 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. > That's what null return paths are for. Exchange doesn't implement > auto-replies properly so they don't work as they should. null return paths are a hack. And they aren't reliable. Even though it's explicitly stated in many RFCs, some MTAs still reject them. And they destroy information, unless you can put the lost information into a machine readable location in the message body. >> It would need to be clearly defined, machine readable etc. It could be stored >> and forwarded, and moved over the same transport. > Already done. you mean the message format is defined? Where? sorry if I'm being lazy, I didn't think that was defined in the RFC for DNs. Adrien > > Tony. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From adrien@qbik.com Mon Feb 20 21:23:55 2012 Return-Path: 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 B665C21F84C9 for ; Mon, 20 Feb 2012 21:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 XysfFxXoPBI5 for ; Mon, 20 Feb 2012 21:23:54 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id D390E21F84C3 for ; Mon, 20 Feb 2012 21:23:53 -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 3385)) with SMTP id <0018874525@smtp.qbik.com>; Tue, 21 Feb 2012 18:23:50 +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 <0010062853@sago.qbik.com>; Tue, 21 Feb 2012 18:23:38 +1300 Message-ID: <4F432A5A.3080901@qbik.com> Date: Tue, 21 Feb 2012 18:23:38 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Filip Navara References: <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <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> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060209050102020906090409" Cc: Arnt Gulbrandsen , "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 05:23:55 -0000 This is a multi-part message in MIME format. --------------060209050102020906090409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 21/02/2012 1:43 a.m., Filip Navara wrote: > JYFI, we (eM Client, www.emclient.com ) do > use BURL in some cases. thanks, I'll have a look. be nice to get a decent replacement for TB. Adrien > > F. > > On Mon, Feb 20, 2012 at 1:30 PM, Adrien de Croy > 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. > > > On 21/02/2012 12:41 a.m., Bron Gondwana wrote: > > > On Mon, Feb 20, 2012, at 01:34 PM, Adrien de Croy wrote: > > i'm just talking about good old file system file copy, > without parsing. > > Just our of interest, are you doing this with BURL now? > > If not, then a requirement to translate during copying is not > an additional > imposition on top of the IO and CPU hit you're currently > getting from > two different copies being sent through your system(s). > > If so, how do you handle the case where the client wants to > store a > BCC field in their "Sent Items" folder as a record of who it was > really sent to? > > Bron. > > > -- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com > > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 > > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ --------------060209050102020906090409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 21/02/2012 1:43 a.m., Filip Navara wrote:
JYFI, we (eM Client, www.emclient.com) do use BURL in some cases.

thanks, I'll have a look.  be nice to get a decent replacement for TB.

Adrien


F.

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.


On 21/02/2012 12:41 a.m., Bron Gondwana wrote:

On Mon, Feb 20, 2012, at 01:34 PM, Adrien de Croy wrote:
i'm just talking about good old file system file copy, without parsing.
Just our of interest, are you doing this with BURL now?

If not, then a requirement to translate during copying is not an additional
imposition on top of the IO and CPU hit you're currently getting from
two different copies being sent through your system(s).

If so, how do you handle the case where the client wants to store a
BCC field in their "Sent Items" folder as a record of who it was
really sent to?

Bron.

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

_______________________________________________
imap5 mailing list
imap5@ietf.org
https://www.ietf.org/mailman/listinfo/imap5


-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
--------------060209050102020906090409-- From adrien@qbik.com Mon Feb 20 21:29:25 2012 Return-Path: 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 433B621F84F8 for ; Mon, 20 Feb 2012 21:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=-0.956, 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 hKTDdnNr16RX for ; Mon, 20 Feb 2012 21:29:24 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4546A21F84EC for ; Mon, 20 Feb 2012 21:29:22 -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 3385)) with SMTP id <0018874531@smtp.qbik.com>; Tue, 21 Feb 2012 18:29:20 +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 <0010062855@sago.qbik.com>; Tue, 21 Feb 2012 18:29:11 +1300 Message-ID: <4F432BA7.209@qbik.com> Date: Tue, 21 Feb 2012 18:29:11 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Bron Gondwana References: <4F3D6E57.8010301@qbk.com><4F3F4F8F.3040601@qbik.co><1329550573.30138.140661038121885@webmail.mesagingengine.com><2012021919260.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> <16456.1329744434.840052@puncture><1329748535.2585.140661038887405@webmail.messagingengine.com> <16456.1329749037.223665@puncture> <1329749200.5849.140661038894569@webmail.messagingengine.com> In-Reply-To: <1329749200.5849.140661038894569@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." , Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 05:29:25 -0000 presuming you were storing the message in a file on disk, you could adopt some sort of meta structure, where the message was a part, and envelopes became other parts (and annotations if desired). This could be as simple as putting a length at the start of the message to where the envelopes start. Any sort of structure I'd length-prefix, so you can skip data instead of having to scan it. the server would take care of it all, and clients would just fetch the bits they wanted. Being in a single file would solve issues relating to synchronisation / keeping it all together. On 21/02/2012 3:46 a.m., Bron Gondwana wrote: > > On Mon, Feb 20, 2012, at 02:43 PM, Dave Cridland wrote: >> On Mon Feb 20 14:35:35 2012, Bron Gondwana wrote: >>> It probably means storing annotations - or at least providing a way >>> to access this envelope data that smells remarkably like >>> annotations. >> No. >> >> Store it as a properly modelled transport envelope - no need to turn >> it into magic soup - that's never worked. > Fine with me. It's just yet another axis of data tied to a message, and > it needs its very own "keywords" or "annotations" as well, presumably, if > you want to note when it was accepted, or MDNed. > > Bron. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From arnt@gulbrandsen.priv.no Tue Feb 21 02:07:23 2012 Return-Path: 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 95F2521F8638 for ; Tue, 21 Feb 2012 02:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 L45rE23esnls for ; Tue, 21 Feb 2012 02:07:23 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id C5C4721F8633 for ; Tue, 21 Feb 2012 02:07:22 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 160C9F8CB08; Tue, 21 Feb 2012 10:07:20 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1329818839-10328-10328/10/3; Tue, 21 Feb 2012 10:07:19 +0000 Message-Id: <4F436D03.10205@gulbrandsen.priv.no> Date: Tue, 21 Feb 2012 11:08:03 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: Tony Finch References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:07:23 -0000 On 02/20/2012 12:56 PM, Tony Finch wrote: > No, the spam problem comes from accepting messages from people you don't > already know. This is of course a necessary feature of mail which is what > makes spam so hard. You make it sound as if necessary features were binary. IMO, this problem is really three disjoint problems, two of which can be solved given architectural support. Two is a smaller number than three, and the solutions might not be perfect, but still... I'll post something when the current thread has subsided. > (Actually not just that - it also comes from accepting messages from > people you sort-of know but who don't care about wasting your time, such > as corporate marketing departments.) The one thing I love about Atlassian Confluence is that I can ignore the rubbish without causing offense to its creators, and in case I'm wrong to ignore some particular page, someone will give me its URL. Arnt From brong@fastmail.fm Wed Feb 22 10:59:23 2012 Return-Path: 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 8589C21F863E for ; Wed, 22 Feb 2012 10:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_40=-0.185, 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 10jSRN827ZsG for ; Wed, 22 Feb 2012 10:59:18 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B433821F85EF for ; Wed, 22 Feb 2012 10:59:13 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9BE852074C for ; Wed, 22 Feb 2012 13:59:12 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 22 Feb 2012 13:59:12 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=xfTg0qYEOzypoR4XigkfgVH xVc8=; b=h4I1o/n8cYExotkIvPJ/gwLcE4ZzUYQIRiiz//fzJM7+WtWLH+gpRTu 4ywIBbHNl0n//QwXA/ZrHuzIqdMZ5opvO51RJFV2iXOLikAy2o8sja4K15e4t1S+ KL6I/fHe7bYstlrWU/YMznyAS7r451pNQaTg3gfALCH7KegTMpbw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:subject:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=xfTg0qYEOzypoR4XigkfgVHxVc8=; b=QR60JZnXGXqt6sseQbR318u6cKNg pn2O2LUPmwGsBubxc296ZYO+Gz+Z57ywuZPtFYOKGbwMVRkhO5XIeB6UxxVEIZ47 HSity695LQt0cFT4pH1HcoTmm0w7S+641KC3fQDdDCdjEG81Ht83wmlfxoQ37cqE WiOw5bVRw2But3U= X-Sasl-enc: Wm7RLpi5VLDG8oDCbiTLKFLeNwdY3UK7MjZrzYDTia9P 1329937152 Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id 57BF6482493 for ; Wed, 22 Feb 2012 13:59:12 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 8639E20422C; Wed, 22 Feb 2012 19:59:10 +0100 (CET) Date: Wed, 22 Feb 2012 19:59:10 +0100 From: Bron Gondwana To: imap5@ietf.org Message-ID: <20120222185910.GA16665@launde.brong.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organization: brong.net User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [imap5] Feature Creep - how far? X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:59:23 -0000 I'm just about to disappear up to Tromsø with my family to try to see some Northern lights. I have finished updating the RFCs list that I have so far, but that's really only looking at IMAP4/POP3/SIEVE and a little bit of SMTP. I didn't reply earlier, but the discussion seems to be moving towards a "complete messaging solution" - possibly even integrating machine-readable delivery feedback. That's a much wider scope than just "client to server protocol replacement". So the real question is: is there any point doing the client to server part in isolation? Is it a big enough improvement to be worth it? Do we need to spec a complete "messaging and related stuff" protocol? Does it handle instant messaging a-la XMPP as well? What about SIP? What about video? It's easy to get carried away here and try to fix the whole world. Anyway, I'm not taking my laptop with me, so I'll come back to the discussion next week. Hopefully refreshed! Bron. From blong@google.com Wed Feb 22 11:24:41 2012 Return-Path: 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 64A9521F8677 for ; Wed, 22 Feb 2012 11:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FUZZY_AMBIEN=1.026, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 p6QspDFzB7Hi for ; Wed, 22 Feb 2012 11:24:40 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id C73B721F8650 for ; Wed, 22 Feb 2012 11:24:35 -0800 (PST) Received: by qan41 with SMTP id 41so568323qan.10 for ; Wed, 22 Feb 2012 11:24:35 -0800 (PST) Received-SPF: pass (google.com: domain of blong@google.com designates 10.229.76.195 as permitted sender) client-ip=10.229.76.195; Authentication-Results: mr.google.com; spf=pass (google.com: domain of blong@google.com designates 10.229.76.195 as permitted sender) smtp.mail=blong@google.com; dkim=pass header.i=blong@google.com Received: from mr.google.com ([10.229.76.195]) by 10.229.76.195 with SMTP id d3mr24616706qck.40.1329938675365 (num_hops = 1); Wed, 22 Feb 2012 11:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=gRTdTVPfOdbhp9BZJEQ44YY2ZmkijFl4BDYURsaIP58=; b=NIz0MGxwQyOUS0X5gbcoiLNw1z14jdcORDDCUcS7fAR5OaBClK7DnP2uvlDfWftDjK //p7Qx7phpKOC3DjHraB7T+zIcG27mU9dIPy1krJOtxT4xNEO5IfYEITWyXcPXQ4bTE7 u5srSLEs6dkidcR0oP89+91psDEVLEXGnX5cI= Received: by 10.229.76.195 with SMTP id d3mr20805912qck.40.1329938675264; Wed, 22 Feb 2012 11:24:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.76.195 with SMTP id d3mr20805904qck.40.1329938675123; Wed, 22 Feb 2012 11:24:35 -0800 (PST) Received: by 10.229.216.201 with HTTP; Wed, 22 Feb 2012 11:24:35 -0800 (PST) In-Reply-To: <4F3F784B.2000809@qbik.com> References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> <4F3F5234.2080406@qbik.com> <4F3F56E7.3080004@panozzo.it> <4F3F784B.2000809@qbik.com> Date: Wed, 22 Feb 2012 11:24:35 -0800 Message-ID: From: Brandon Long To: Adrien de Croy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlNDIg+HTV/NT3U9Ps+DAISC2bWMhQbxOyK9cHs/iVmi60nvCqtQXEmcpwb5v+E/EtcbPhbvY7u6JozMoFvEnJNVbL9OcI5lBSrllYC2Poeqgv6LObUkJh+XTNiKdxTuYDpyS6W Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:24:41 -0000 On Sat, Feb 18, 2012 at 2:07 AM, Adrien de Croy wrote: > > > On 18/02/2012 8:44 p.m., Giovanni Panozzo wrote: >> >> Il 18/02/2012 08:24, Adrien de Croy ha scritto: >>> >>> >>> We can't presume everyone has a full time internet connection. >> >> >> 100% agree. Store and forward is still required in some part of the >> world. I developed XATRN (http://xatrn.panozzo.it), and there are >> still very some (few, very few) users that use it with intermittent >> Internet connection. Yes, I think that the future will be for >> always-on connections, but there is no full world coverage of such >> kind of Internet access. >> >>>> They authenticate over sasl using some fancy >>>> federated authentication protocol (project moonshot) before being >>>> allowed >>>> to post to my inbox. >>> >>> >>> Personally I'd be tempted to mandate use of X.509 (SSL) client certs an= d >>> TLS. >> >> >> Maybe X509 can be one of the weapons against spam. But today spam >> comes from a "stolen" webserver (injectet PHP script) or from "stolen" >> PC (zombie PC, zombie network). >> Spam NEVER comes from the sender itself. SPAM comes from a stolen >> account :( > > > plenty of spam comes from the sender not stolen accounts. =A0That's why t= he > spammers do things like register their own domains and SPF records. > > >> Yes, better knowing the stolen account can help in fix the problem, >> linke telling the user to run antivirus/reinstall OS, or the webmaster >> to check its .PHP files. But I don't think that identifiyng the user >> with X509 cert or some other federated authentication will help. > > > the server will have a cert. =A0It can be seen as spamming, and its cert = can > be revoked. =A0That will cut it off. > > Having to get another cert will provide an incentive for the admin to car= e > about it. You seem to believe that all servers can always be entirely free from sending spam. That's pretty funny. Given that spam is in the eye of the beholder, there are plenty of messages which are spam to some and not to others. Do you consider the latest commercial offer from Target or Amazon as spam? Plenty of people mark it as such, even if they opted-in to receiving it. How about spam sent from a hijacked account? How many hijacked accounts a day do you think there are on a service with 1B email users? Or how much money do you think a spammer is willing to spend to buy an account, even on a free service? Or do you think its actually possible to force everyone who wants an email account to pay for it at this point? And if so, how much money? $5/year is cheap in parts of the world, and really expensive in others, should poor parts of the world be relegated to the email ghetto because their accounts are so cheap that spammer abuse them constantly, while they have the least resources to keep them out? And do you think that every person who runs a mail server wants to spend $100/year on a certificate? We already do it, but its not a big deal to us. How many people run servers on their personal box? Which is all pretty irrelevant, for most users today spam is already a solved problem. They don't see how much effort we put into it, and they know nothing about it until their account gets hijacked or one of their friends does and they get a mugged in London message. Or when some filter gets too aggressive and they don't get a message. Or when some company still thinks the spam world is black & white and uses a blacklist against their server. Any effort they would have to make to whitelist senders before they can send them mail is something they aren't likely to understand the need for. As for getting the Facebooks of the world to open up their social connection information to solve the spam problem for you, well, good luck with that. If you're Yahoo or Microsoft you can pay enough money to get access to that, and maybe its in the ToS to use it that way. Brandon From brong@fastmail.fm Wed Feb 22 11:36:49 2012 Return-Path: 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 9E31621F86E8 for ; Wed, 22 Feb 2012 11:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_50=0.001, 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 BzZo6U8cqrt4 for ; Wed, 22 Feb 2012 11:36:48 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 76B1421F86D1 for ; Wed, 22 Feb 2012 11:36:46 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E907621505 for ; Wed, 22 Feb 2012 14:36:45 -0500 (EST) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute2.internal (MEProxy); Wed, 22 Feb 2012 14:36:45 -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:in-reply-to:references:subject:date; s=mesmtp; bh= /M0XGPQzBsq0K3WV8LK6dAmBOv4=; b=ixNUqi9iRVjEy96A0PKHcUv9fkxplT8m EBZnBAJpAYSIaNdSEL6QNmvc+TFpyhwq10F2Q1glui2FQ4NbIDj3NjSqmDWyJ7Zq j/6sbgIkyC+Xl4c1MmJeby7RHuBNanp8FJbeIlsThfbpD3SE8IARFj6vscy1q4VG WDIshTseSUc= 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:in-reply-to:references :subject:date; s=smtpout; bh=/M0XGPQzBsq0K3WV8LK6dAmBOv4=; b=d0T iGHpZlWse+vo32dtzufUROU8J0fOS+NpiYZKvBJiv3t72D9a1bA8jXFzhdw0QOY/ A/bYT84b6+sqvAiJywLli0vguV/yj2q8xFJ6gzNtdTbgPFFC04ifwqGE7VM/Sz5o 7MwaHfEdyXTC3Xi5hKeQiMz4//ErfgsUXEFsAd5o= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 99084400EC; Wed, 22 Feb 2012 14:36:45 -0500 (EST) Message-Id: <1329939405.3389.140661039979197@webmail.messagingengine.com> X-Sasl-Enc: n/LEO4aH1nX9uwjWDs8zKZjgTfneJCXbGA71KxYziaIO 1329939405 From: Bron Gondwana To: Brandon Long , Adrien de Croy MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com><1329394296.953.140661037317197@webmail.messagingengine.com><4F3CFD35.10501@qbik.com><4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net><20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com><20120217171457.GB4503@dan.olp.net> <4F3F5234.2080406@qbik.com><4F3F56E7.3080004@panozzo.it> <4F3F784B.2000809@qbik.com> Date: Wed, 22 Feb 2012 20:36:45 +0100 Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:36:49 -0000 On Wed, Feb 22, 2012, at 11:24 AM, Brandon Long wrote: > You seem to believe that all servers can always be entirely free from > sending spam. That's pretty funny. Yeah, this. We're a lot smaller than you, and we are more strict about spam scanning what goes OUT than what comes in, but we still wind up with all the usual reasons why we have outbound spam :( > [...] They don't see how much effort we put into it, and > they know nothing about it until their account gets hijacked or one of > their friends does and they get a mugged in London message. Or when > some filter gets too aggressive and they don't get a message. Or when > some company still thinks the spam world is black & white and uses a > blacklist against their server. Or because someone's incoming rate limits are delaying their messages (just saying ;) - one of my major causes of notifications is someone who forwards all their email to gmail causing a massive outbound backlog when their monitoring service goes crazy and your inbound limits are stricter than our inbound limits... > Any effort they would have to make to > whitelist senders before they can send them mail is something they > aren't likely to understand the need for. There's some nice stuff you can do with semi-automatic whitelisting (up-rate things which are a response to something they have already sent, certainly up-rate addresses in their address book) - but we found you can't go too far there (like whitelisting "from self" because the spammers will exploit that. Same with whitelisting stuff from someone who has already spoken to them, because it just means you get targetted spam supposedly from someone else on a public mailing list. > As for getting the Facebooks of the world to open up their social > connection information to solve the spam problem for you, well, good > luck with that. If you're Yahoo or Microsoft you can pay enough money > to get access to that, and maybe its in the ToS to use it that way. The more I read (particularly from Bruce Schneier) about this, the more I realise that spam isn't solveable. Make it harder, and it will be more valuable to be able to get through, because the scammer is no longer competing against a ton of other scams. The flavour might change to more targetted, but unsolicited rubbish will always exist. The internet is not a special flower here. Bron. -- Bron Gondwana brong@fastmail.fm From adrien@qbik.com Wed Feb 22 12:23:06 2012 Return-Path: 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 C19C521E8062 for ; Wed, 22 Feb 2012 12:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-2.273, BAYES_50=0.001] 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 fgMjhGBYatF9 for ; Wed, 22 Feb 2012 12:23:04 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id A618521E804A for ; Wed, 22 Feb 2012 12:23:03 -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 3385)) with SMTP id <0018878206@smtp.qbik.com>; Thu, 23 Feb 2012 09:23:00 +1300 Message-ID: <4F454E97.2070306@qbik.com> Date: Thu, 23 Feb 2012 09:22:47 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Brandon Long References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> <4F3F5234.2080406@qbik.com> <4F3F56E7.3080004@panozzo.it> <4F3F784B.2000809@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:23:06 -0000 On 23/02/2012 8:24 a.m., Brandon Long wrote: > On Sat, Feb 18, 2012 at 2:07 AM, Adrien de Croy wrote: >> Having to get another cert will provide an incentive for the admin to care >> about it. > You seem to believe that all servers can always be entirely free from > sending spam. That's pretty funny. sorry, where do I propose that? I'm just proposing a system that allows the identification of organisations that inject and relay spam. That then allows enforcement of accountability. > Given that spam is in the eye of the beholder, there are plenty of > messages which are spam to some and not to others. of course > Do you consider > the latest commercial offer from Target or Amazon as spam? Plenty of > people mark it as such, even if they opted-in to receiving it. if they opted in, they indicated a willingness to receive whatever they get, within the terms of their opt-in > How about spam sent from a hijacked account? How many hijacked > accounts a day do you think there are on a service with 1B email > users? How many other crimes are there committed a day, do you propose we don't go after criminals? > Or how much money do you think a spammer is willing to spend to buy an > account, even on a free service? Or do you think its actually > possible to force everyone who wants an email account to pay for it at > this point? And if so, how much money? $5/year is cheap in parts of > the world, and really expensive in others, should poor parts of the > world be relegated to the email ghetto because their accounts are so > cheap that spammer abuse them constantly, while they have the least > resources to keep them out? why do you assume the system would be structured like this? Sounds like a system that would fail. > And do you think that every person who runs a mail server wants to > spend $100/year on a certificate? We already do it, but its not a big > deal to us. How many people run servers on their personal box? need to think outside the square a bit. > Which is all pretty irrelevant, for most users today spam is already a > solved problem. it certainly is not a solved problem for anyone. Ignorance is not the answer. Jut because a business doesn't know how many customers they are losing due to over-agressive spam filtering doesn't mean it has no cost to them. > They don't see how much effort we put into it, and > they know nothing about it until their account gets hijacked or one of > their friends does and they get a mugged in London message. Or when > some filter gets too aggressive and they don't get a message. if they find out they didn't get the message. > Or when > some company still thinks the spam world is black& white and uses a > blacklist against their server. Any effort they would have to make to > whitelist senders before they can send them mail is something they > aren't likely to understand the need for. > > As for getting the Facebooks of the world to open up their social > connection information to solve the spam problem for you, well, good > luck with that. If you're Yahoo or Microsoft you can pay enough money > to get access to that, and maybe its in the ToS to use it that way. > > Brandon The system (and I admit it's ambitious) would need co-operation from governments. there's no need for ma and pa to have a certificate, they can submit to their ISP. The ISP would need a certificate. There's no reason to assume the certs would be managed by the existing CA infrastructure. I'd propose that should be a function of Governments, and there are already special provisions for governments to issue certificates. They could be for long periods as well. The purpose is to identify and provide a means to revoke. Renewing annually seems like a waste of time for that, unless you think the certificate may be breached. Organisations wanting to deliver directly could get a certificate as well. As to determination about whether someone spams or not. Well most countries have systems to establish whether crimes are committed and go after and punish those responsible. There are already spamming laws all over the place. I'm proposing setting up a system that allows for identification of perpetrators and enforcement, and enables services to be set up to solve issues independently (e.g. if a government refuses to prosecute a spammer). Revokation of certificates would be a function of government after due process. People couldn't just buy new ones (unless they get them from corrupt government officials), because their previous spamming would be associated with them as a person. In short, treat spamming like any other crime - which it certainly is. I think if governments were aware of the costs of spamming they may take a different view on it. How many hours are wasted deleting spam? How much money is spent on anti-spam? How much network capacity (which costs money) is wasted transporting spam? How many opportunities are lost due to false positives? Personally I believe the real economic costs of spam are astronomical. Someone needs to do a study, and come up with some numbers they can back up. Otherwise we should just all join FB and just use that for communication and ditch mail altogether. Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From blong@google.com Wed Feb 22 13:29:01 2012 Return-Path: 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 5B35321E8034 for ; Wed, 22 Feb 2012 13:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 DrLQO3Z8w5Av for ; Wed, 22 Feb 2012 13:29:00 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4A29E21E801F for ; Wed, 22 Feb 2012 13:29:00 -0800 (PST) Received: by qan41 with SMTP id 41so686722qan.10 for ; Wed, 22 Feb 2012 13:28:59 -0800 (PST) Received-SPF: pass (google.com: domain of blong@google.com designates 10.229.134.199 as permitted sender) client-ip=10.229.134.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of blong@google.com designates 10.229.134.199 as permitted sender) smtp.mail=blong@google.com; dkim=pass header.i=blong@google.com Received: from mr.google.com ([10.229.134.199]) by 10.229.134.199 with SMTP id k7mr17454408qct.60.1329946139917 (num_hops = 1); Wed, 22 Feb 2012 13:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=xBooyYpdx2166dyPXQYmiAnHhmbgZgTrWFicFtCgNKU=; b=gAl6y0DbxBaCo695rf7vZieLFssKMQx6U1gwQzwzG4czfaZQ4Mx5f4d4czXkU0fsW9 92uwDAHDZ1768XQncxDpVBti4hZPUkBA0DBQsQ6fP4lFnpefRBDm+uJuybOPQl2FDmjq G7mnpKJVPk5Yv0mmmXlzs7mykAqnA8jfOjV7o= Received: by 10.229.134.199 with SMTP id k7mr14758259qct.60.1329946139739; Wed, 22 Feb 2012 13:28:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.134.199 with SMTP id k7mr14758244qct.60.1329946139499; Wed, 22 Feb 2012 13:28:59 -0800 (PST) Received: by 10.229.216.201 with HTTP; Wed, 22 Feb 2012 13:28:59 -0800 (PST) In-Reply-To: <4F454E97.2070306@qbik.com> References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <20120216224124.GC4578@dan.olp.net> <20120216232954.GB5356@dan.olp.net> <4F3DA4A6.5020304@qbik.com> <20120217171457.GB4503@dan.olp.net> <4F3F5234.2080406@qbik.com> <4F3F56E7.3080004@panozzo.it> <4F3F784B.2000809@qbik.com> <4F454E97.2070306@qbik.com> Date: Wed, 22 Feb 2012 13:28:59 -0800 Message-ID: From: Brandon Long To: Adrien de Croy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlwf1C/ztxd714Wrs6wgmIC/q6UubQbU78v3ZWlA6u7kf7y3gkflVoYB/8ABdoW4tAi3q/poq8R+XQSDNyt1cZzmQG7X59RhmVWQYR5jOS7hh8slZ85SFJrdI8jFYi0bPHggnU8 Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 21:29:01 -0000 On Wed, Feb 22, 2012 at 12:22 PM, Adrien de Croy wrote: > > > On 23/02/2012 8:24 a.m., Brandon Long wrote: >> >> On Sat, Feb 18, 2012 at 2:07 AM, Adrien de Croy =A0wrot= e: >>> >>> Having to get another cert will provide an incentive for the admin to >>> care >>> about it. >> >> You seem to believe that all servers can always be entirely free from >> sending spam. =A0That's pretty funny. > > > sorry, where do I propose that? You're proposing revoking a server's certificate for spamming. Based on what level? What level of fault? Would Gmail get its certificate revoked because 1% of the email it sends is spam? > I'm just proposing a system that allows the identification of organisatio= ns > that inject and relay spam. =A0That then allows enforcement of accountabi= lity. We can already do this via IP addresses and sender domains and SPF/DKIM authentication. Yes, its just a proxy and sometimes its wrong, but it works fairly well. >> How about spam sent from a hijacked account? =A0How many hijacked >> accounts a day do you think there are on a service with 1B email >> users? > > How many other crimes are there committed a day, do you propose we don't = go > after criminals? Heh. Do you know how many spam messages are sent a day? How large an enforcement organization do you propose to go after them all? And how long do you think that would take? Not to mention that multiple people and governments have different definitions of spam. When we see a new spam campaign, we need to be able to shut it down in less than hours. A recent time that we helped the US government go after a malware operation, it took them a year before the first arrests. A year where we had to leave the botnets and operations alone so they could gather the evidence necessary to make the arrests. Police action doesn't scale the same way that spammers do. >> Or how much money do you think a spammer is willing to spend to buy an >> account, even on a free service? =A0Or do you think its actually >> possible to force everyone who wants an email account to pay for it at >> this point? =A0And if so, how much money? =A0$5/year is cheap in parts o= f >> the world, and really expensive in others, should poor parts of the >> world be relegated to the email ghetto because their accounts are so >> cheap that spammer abuse them constantly, while they have the least >> resources to keep them out? > > > why do you assume the system would be structured like this? =A0Sounds lik= e a > system that would fail. Then who pays for this enforcement? Who pays for the certification? >> Which is all pretty irrelevant, for most users today spam is already a >> solved problem. > > it certainly is not a solved problem for anyone. =A0Ignorance is not the > answer. > > Jut because a business doesn't know how many customers they are losing du= e > to over-agressive spam filtering doesn't mean it has no cost to them. Of course it has a cost. I'm saying the cost of your solution is higher. > The system (and I admit it's ambitious) would need co-operation from > governments. As if all the governments of the world agree on anything, much less the definition of spam. > there's no need for ma and pa to have a certificate, they can submit to > their ISP. =A0The ISP would need a certificate. =A0There's no reason to a= ssume > the certs would be managed by the existing CA infrastructure. =A0I'd prop= ose > that should be a function of Governments, and there are already special > provisions for governments to issue certificates. =A0They could be for lo= ng > periods as well. =A0The purpose is to identify and provide a means to rev= oke. > =A0Renewing annually seems like a waste of time for that, unless you thin= k the > certificate may be breached. And what if the CA is breached? Ie, like the 2-3 that have happened in the last year? > Organisations wanting to deliver directly could get a certificate as well= . > > As to determination about whether someone spams or not. =A0Well most coun= tries > have systems to establish whether crimes are committed and go after and > punish those responsible. =A0There are already spamming laws all over the > place. =A0I'm proposing setting up a system that allows for identificatio= n of > perpetrators and enforcement, and enables services to be set up to solve > issues independently (e.g. if a government refuses to prosecute a spammer= ). Weee, now we're talking about extra-governmental authorities making the rules. Its always great to argue with an RBL maintainer about whether or not something is spam. Or maybe what you're proposing is more like SOPA/PIPA, we can have an organization like the RIAA deciding what's good. Even better, the government of Iran can just prevent their providers from accepting any mail certified by other governments. Or here's an even more fun one: We just emailed all of our users about the changes to our privacy policy, a move we made at the request of the US government. And we had RBL organizations complaining that it was spam. Who wins? Our answer is simple: the user decides what is spam, not someone else. Our job is to make our spam filter match each user's expectations. > =A0Revokation of certificates would be a function of government after due > process. =A0People couldn't just buy new ones (unless they get them from > corrupt government officials), because their previous spamming would be > associated with them as a person. =A0In short, treat spamming like any ot= her > crime - which it certainly is. No corrupt government officials in the world, that's for sure. And they already treat spamming as a crime, have for years. Done a lot of good at reducing the spam load, eh? > I think if governments were aware of the costs of spamming they may take = a > different view on it. =A0How many hours are wasted deleting spam? How muc= h > money is spent on anti-spam? =A0How much network capacity (which costs mo= ney) > is wasted transporting spam? Not as much as you'd think, turns out spam is much smaller than regular mail at this point, at least for consumers. A large percentage of mail, but on the order of 40x smaller in size (on average). And email in general is not generally a large user of network capacity. How many email messages, even at 100k average, does it take to equal a single iphone app download? Or a streamed video from Youtube? >=A0How many opportunities are lost due to false > positives? =A0Personally I believe the real economic costs of spam are > astronomical. =A0Someone needs to do a study, and come up with some numbe= rs > they can back up. Regardless of those costs, your proposal would cost more and still not solve the problem. > Otherwise we should just all join FB and just use that for communication = and > ditch mail altogether. We have the stats on what percentage of our users receiving mail mark messages as spam or not spam. Its tiny. For most people, they don't see the spam, and maybe they don't see enough to actually check their spam label, but its just not an issue. As to where the kids are going these days, who knows. Email is certainly not the only game in town. Brandon From adrien@qbik.com Wed Feb 22 17:51:16 2012 Return-Path: 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 872B711E8073 for ; Wed, 22 Feb 2012 17:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=-1.984, BAYES_05=-1.11, J_CHICKENPOX_46=0.6] 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 dJfL0ujZVU-Z for ; Wed, 22 Feb 2012 17:51:15 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id B04B811E8072 for ; Wed, 22 Feb 2012 17:51:14 -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 3385)) with SMTP id <0018878653@smtp.qbik.com>; Thu, 23 Feb 2012 14:51:12 +1300 Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.3] (WinGate SMTP Receiver v7.1.0 (Build 3386)) with SMTP id <0010064052@sago.qbik.com>; Thu, 23 Feb 2012 14:50:55 +1300 Message-ID: <4F459B7F.5070407@qbik.com> Date: Thu, 23 Feb 2012 14:50:55 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: "Discussion on drastically slimming-down IMAP." References: <4F4593FA.40200@qbik.com> In-Reply-To: <4F4593FA.40200@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAPRe: X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 01:51:16 -0000 On 23/02/2012 2:18 p.m., Brandon Long wrote: > On Wed, Feb 22, 2012 at 12:22 PM, Adrien de Croy > wrote: >> >> >> On 23/02/2012 8:24 a.m., Brandon Long wrote: >>> >>> On Sat, Feb 18, 2012 at 2:07 AM, Adrien de Croy>> qbik.com> wrote: >>>> >>>> Having to get another cert will provide an incentive for the admin to >>>> care >>>> about it. >>> >>> You seem to believe that all servers can always be entirely free from >>> sending spam. That's pretty funny. >> >> >> sorry, where do I propose that? > > You're proposing revoking a server's certificate for spamming. Based > on what level? What level of fault? Would Gmail get its certificate > revoked because 1% of the email it sends is spam? there would need to be some level. You'd hope it would be revoked if say 50% was spam. Or even a lot less. > >> I'm just proposing a system that allows the identification of >> organisations >> that inject and relay spam. That then allows enforcement of >> accountability. > > We can already do this via IP addresses and sender domains and > SPF/DKIM authentication. Yes, its just a proxy and sometimes its > wrong, but it works fairly well. SPF is only reliable to block spoof attempts from a limited set of well-known domains that use it. Since spammers register their own SPF records, you can't use it as a pass check for any domain. I don't know enough about DKIM. I thought it's optional, so therefore how can you rely on it? IP addresses is problematic as well, RBLs that block dynamic blocks for example is a big problem. Sender domains is a big administrative maintenance hassle. > >>> How about spam sent from a hijacked account? How many hijacked >>> accounts a day do you think there are on a service with 1B email >>> users? >> >> How many other crimes are there committed a day, do you propose we >> don't go >> after criminals? > > Heh. Do you know how many spam messages are sent a day? How large an > enforcement organization do you propose to go after them all? And how > long do you think that would take? I don't think the number of actual spammers is actually that high. It takes some serious infrastructure, which is a bit of a barrier to entry. e.g. http://krebsonsecurity.com/tag/mega-d/ some key players responsible for a vast proportion of all spam. Take them out and others will jump into their shoes though. > > Not to mention that multiple people and governments have different > definitions of spam. > > When we see a new spam campaign, we need to be able to shut it down in > less than hours. A recent time that we helped the US government go > after a malware operation, it took them a year before the first > arrests. A year where we had to leave the botnets and operations > alone so they could gather the evidence necessary to make the arrests. > > Police action doesn't scale the same way that spammers do. sure. In the end, with the certificates, basically we are tying the mail to a person somewhere to enable enforcement of accountability. Whether that happens quickly or not is another matter. Currently there's no such reliable tie. If it takes authorities ages to get someone now, it's because of difficulty of proof. Things might be a bit different if that problem were resolved. Then add large fines / jail terms for spamming, and there's your incentive. That's why there are so many parking and traffic cops here.... it's where the money is. > >>> Or how much money do you think a spammer is willing to spend to buy an >>> account, even on a free service? Or do you think its actually >>> possible to force everyone who wants an email account to pay for it at >>> this point? And if so, how much money? $5/year is cheap in parts of >>> the world, and really expensive in others, should poor parts of the >>> world be relegated to the email ghetto because their accounts are so >>> cheap that spammer abuse them constantly, while they have the least >>> resources to keep them out? >> >> >> why do you assume the system would be structured like this? Sounds >> like a >> system that would fail. > > Then who pays for this enforcement? Who pays for the certification? I imagine it would be a function for government, in the same way as dealing with any crime is. If the FBI put as much resource into it as copyright protection, I wonder what would happen (Kim Dotcom recently bailed in the town I live in). > >>> Which is all pretty irrelevant, for most users today spam is already a >>> solved problem. >> >> it certainly is not a solved problem for anyone. Ignorance is not the >> answer. >> >> Jut because a business doesn't know how many customers they are >> losing due >> to over-agressive spam filtering doesn't mean it has no cost to them. > > Of course it has a cost. I'm saying the cost of your solution is higher. quite possibly. But I think if spammers were identified, found and jailed effectively it would be more of a deterrent. The revokation of certs may not even be the key function of this. Currently pretty much anyone can send mail anonymously. IMO that's just plain wrong on a moral level. Incurring costs on other parties anonymously. > >> The system (and I admit it's ambitious) would need co-operation from >> governments. > > As if all the governments of the world agree on anything, much less > the definition of spam. well, you get the main ones to agree, and they can impose sanctions on those that continue to be a source of spam. And before you cry new world order, sanctions could be simply blocking incoming mail from those countries. > >> there's no need for ma and pa to have a certificate, they can submit to >> their ISP. The ISP would need a certificate. There's no reason to >> assume >> the certs would be managed by the existing CA infrastructure. I'd >> propose >> that should be a function of Governments, and there are already special >> provisions for governments to issue certificates. They could be for >> long >> periods as well. The purpose is to identify and provide a means to >> revoke. >> Renewing annually seems like a waste of time for that, unless you >> think the >> certificate may be breached. > > And what if the CA is breached? Ie, like the 2-3 that have happened > in the last year? what happens when any CA is breached? You need to start over, reissue all new certs from the CA root down. So best it's not breached. > >> Organisations wanting to deliver directly could get a certificate as >> well. >> >> As to determination about whether someone spams or not. Well most >> countries >> have systems to establish whether crimes are committed and go after and >> punish those responsible. There are already spamming laws all over the >> place. I'm proposing setting up a system that allows for >> identification of >> perpetrators and enforcement, and enables services to be set up to >> solve >> issues independently (e.g. if a government refuses to prosecute a >> spammer). > > Weee, now we're talking about extra-governmental authorities making > the rules. not enforcing them though, receivers would be free to use the service or not. > Its always great to argue with an RBL maintainer about > whether or not something is spam. sure, but people exercise their own rights to choose whether to use the RBL or not. > Or maybe what you're proposing is > more like SOPA/PIPA, we can have an organization like the RIAA > deciding what's good. hell no. More likely be a community-driven thing. > Even better, the government of Iran can just > prevent their providers from accepting any mail certified by other > governments. if they want. They can surely already block port 25 incoming if they want. > > Or here's an even more fun one: We just emailed all of our users about > the changes to our privacy policy, a move we made at the request of > the US government. And we had RBL organizations complaining that it > was spam. Who wins? decided in court if it gets that far. At least you can't escape, since you're identified. > > Our answer is simple: the user decides what is spam, not someone else. > Our job is to make our spam filter match each user's expectations. > >> Revokation of certificates would be a function of government after >> due >> process. People couldn't just buy new ones (unless they get them from >> corrupt government officials), because their previous spamming would be >> associated with them as a person. In short, treat spamming like any >> other >> crime - which it certainly is. > > No corrupt government officials in the world, that's for sure. > > And they already treat spamming as a crime, have for years. Done a > lot of good at reducing the spam load, eh? I wouldn't call the CAN-SPAM act criminalisation of spamming. Here in NZ people go to jail for it unless it's opt-in. > >> I think if governments were aware of the costs of spamming they may >> take a >> different view on it. How many hours are wasted deleting spam? How >> much >> money is spent on anti-spam? How much network capacity (which costs >> money) >> is wasted transporting spam? > > Not as much as you'd think, turns out spam is much smaller than > regular mail at this point, at least for consumers. A large > percentage of mail, but on the order of 40x smaller in size (on > average). And email in general is not generally a large user of > network capacity. How many email messages, even at 100k average, does > it take to equal a single iphone app download? Or a streamed video > from Youtube? sure, I guess it's actually changed a lot over the last 4 years or so. So maybe the network cost isn't such an issue. It's definitely more of an issue over long-haul submarine cables though. > >> How many opportunities are lost due to false >> positives? Personally I believe the real economic costs of spam are >> astronomical. Someone needs to do a study, and come up with some >> numbers >> they can back up. > > Regardless of those costs, your proposal would cost more and still not > solve the problem. hard to come to that conclusion without evaluating costs of both, which of course would be very difficult. For those hosting their own mail, even the cost of evaluating and testing anti-spam products is significant - before you get your wallet out to purchase software. I'm not claiming any of this would be easy. But humans have done some fairly difficult things in the past successfully. > >> Otherwise we should just all join FB and just use that for >> communication and >> ditch mail altogether. > > We have the stats on what percentage of our users receiving mail mark > messages as spam or not spam. Its tiny. maybe they gave up and now just delete it. Unless it's no more difficult to mark and delete than just delete, people will gravitate towards the lower-effort option, and you'll lose the information. > For most people, they don't > see the spam, and maybe they don't see enough to actually check their > spam label, but its just not an issue. > > As to where the kids are going these days, who knows. Email is > certainly not the only game in town. > > Brandon > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From adrien@qbik.com Wed Feb 22 18:26:35 2012 Return-Path: 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 7F25821F8517 for ; Wed, 22 Feb 2012 18:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=-0.910, 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 D0EQ8eHRqeuP for ; Wed, 22 Feb 2012 18:26:34 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3E721F8510 for ; Wed, 22 Feb 2012 18:26:34 -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 3386)) with SMTP id <0018878696@smtp.qbik.com>; Thu, 23 Feb 2012 15:26:32 +1300 Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.3] (WinGate SMTP Receiver v7.1.0 (Build 3386)) with SMTP id <0010064079@sago.qbik.com>; Thu, 23 Feb 2012 15:26:11 +1300 Message-ID: <4F45A3C4.3030305@qbik.com> Date: Thu, 23 Feb 2012 15:26:12 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: "Discussion on drastically slimming-down IMAP." References: <4F4593FA.40200@qbik.com> <4F459B7F.5070407@qbik.com> In-Reply-To: <4F459B7F.5070407@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAPRe: X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 02:26:35 -0000 On 23/02/2012 2:50 p.m., Adrien de Croy wrote: > SPF is only reliable to block spoof attempts from a limited set of > well-known domains that use it. Since spammers register their own SPF > records, you can't use it as a pass check for any domain. > > sorry, I got that the wrong way around. It's pretty good for detecting spoofing from any SPF domain. But it's only a pass for well known domains. and since SPF recommend everyone create SPF records that end in ~all (the fence-sitter) it's not that useful for most domains. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 is released! - http://www.wingate.com/getlatest/ From jkt@flaska.net Thu Feb 23 06:51:49 2012 Return-Path: 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 12A5921F87FC for ; Thu, 23 Feb 2012 06:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 AlhWJBYA1ZEz for ; Thu, 23 Feb 2012 06:51:48 -0800 (PST) Received: from serv132.fzu.cz (serv132.fzu.cz [147.231.26.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1609E21F87F3 for ; Thu, 23 Feb 2012 06:51:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIDAOdRRk+T5xpZgWdsb2JhbABEhTStHCIBARYmJ4FzAQEFI1URCxgJFgsCAgkDAgECAUUTCAEBiAasdoooiVEWgxlvBBUCAwECAoUWCQQCAToCBCEXggiBFgSOT4EbhU6SboFb X-IronPort-AV: E=Sophos;i="4.73,470,1325458800"; d="asc'?scan'208";a="4698806" Received: from freja.fzu.cz ([147.231.26.89]) by serv147.fzu.cz with ESMTP; 23 Feb 2012 15:51:45 +0100 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id E54B63DA82 for ; Thu, 23 Feb 2012 15:51:44 +0100 (CET) Message-ID: <4F465269.1040901@flaska.net> Date: Thu, 23 Feb 2012 15:51:21 +0100 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imap5@ietf.org References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDC2E6F5898E88A67807DAC0C" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:51:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDC2E6F5898E88A67807DAC0C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/20/12 11:52, Tony Finch wrote: > message/rfc822 is also good. IMO every message that is forwarded or > top-post replied should use message/rfc822 attachments rather than doin= g > some fucked up redaction of the original message. GMail still breaks [1] on such messages -- the web interface shows the message source and the IMAP server returns invalid BODYSTRUCTURE which doesn't allow accessing the attached message. Cheers, Jan [1] http://permalink.gmane.org/gmane.mail.imap.general/2637 --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enigDC2E6F5898E88A67807DAC0C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9GUm0ACgkQamXfqERyJRdv2QCeKa0JcqyVZOlD5EIEDc6A+W3v eW8AnRbLy7u4A5sDxLZe5mhdaVR+eyMf =GswG -----END PGP SIGNATURE----- --------------enigDC2E6F5898E88A67807DAC0C-- From tony@att.com Thu Feb 23 07:44:09 2012 Return-Path: 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 62FA521F8823 for ; Thu, 23 Feb 2012 07:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.152 X-Spam-Level: X-Spam-Status: No, score=-106.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 awrGHB3yi7C7 for ; Thu, 23 Feb 2012 07:44:08 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEE621F8820 for ; Thu, 23 Feb 2012 07:44:08 -0800 (PST) X-Env-Sender: tony@att.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1330011847!17019378!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10971 invoked from network); 23 Feb 2012 15:44:07 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Feb 2012 15:44:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1NFibeU010310 for ; Thu, 23 Feb 2012 10:44:37 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1NFiWe4010174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2012 10:44:33 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Thu, 23 Feb 2012 10:44:00 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q1NFhxl3023684 for ; Thu, 23 Feb 2012 10:43:59 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q1NFhvAA023647 for ; Thu, 23 Feb 2012 10:43:58 -0500 Received: from [135.70.166.212] (vpn-135-70-166-212.vpn.mwst.att.com[135.70.166.212]) by maillennium.att.com (mailgw1) with ESMTP id <20120223154136gw100e4lm0e> (Authid: tony); Thu, 23 Feb 2012 15:41:36 +0000 X-Originating-IP: [135.70.166.212] Message-ID: <4F465EBC.7090206@att.com> Date: Thu, 23 Feb 2012 10:43:56 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: imap5@ietf.org References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> In-Reply-To: <4F465269.1040901@flaska.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:44:09 -0000 Totally off topic: I wish I knew how to get them to fix that. I get bit=20 by it regularly. On topic: because gmail messes up in this area doesn't mean that we=20 should also mess things up in the same way. I am a firm believer in the use of message/rfc822 attachments. Tony Hansen On 2/23/2012 9:51 AM, Jan Kundr=E1t wrote: > On 02/20/12 11:52, Tony Finch wrote: >> message/rfc822 is also good. IMO every message that is forwarded or >> top-post replied should use message/rfc822 attachments rather than doi= ng >> some fucked up redaction of the original message. > GMail still breaks [1] on such messages -- the web interface shows the > message source and the IMAP server returns invalid BODYSTRUCTURE which > doesn't allow accessing the attached message. > > Cheers, > Jan > > [1] http://permalink.gmane.org/gmane.mail.imap.general/2637 From arnt@gulbrandsen.priv.no Thu Feb 23 07:57:53 2012 Return-Path: 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 8514C21F87E2 for ; Thu, 23 Feb 2012 07:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 H5RaXst4boI2 for ; Thu, 23 Feb 2012 07:57:53 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id DE39C21F87E0 for ; Thu, 23 Feb 2012 07:57:52 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id D7912F8CCC7; Thu, 23 Feb 2012 15:57:42 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1330012661-20846-20846/10/6; Thu, 23 Feb 2012 15:57:41 +0000 Message-Id: <4F466224.5050300@gulbrandsen.priv.no> Date: Thu, 23 Feb 2012 16:58:28 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> In-Reply-To: <4F465EBC.7090206@att.com> Content-Type: text/plain; charset=iso-8859-1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:57:53 -0000 On 02/23/2012 04:43 PM, Tony Hansen wrote: > On topic: because gmail messes up in this area doesn't mean that we > should also mess things up in the same way. > > I am a firm believer in the use of message/rfc822 attachments. Be a firm believer in having few features, each of which is used often. Arnt From mrc+ietf@panda.com Thu Feb 23 09:01:07 2012 Return-Path: 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 54F6921F8762 for ; Thu, 23 Feb 2012 09:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GYlthkeAMv11 for ; Thu, 23 Feb 2012 09:01:05 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id E6C1421F86CE for ; Thu, 23 Feb 2012 09:01:04 -0800 (PST) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Thu, 23 Feb 2012 09:00:59 -0800 X-MailFrom: mrc+ietf@panda.com Date: Thu, 23 Feb 2012 09:00:57 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Tony Hansen In-Reply-To: <4F465EBC.7090206@att.com> Message-ID: References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 17:01:07 -0000 On Thu, 23 Feb 2012, Tony Hansen wrote: > On topic: because gmail messes up in this area doesn't mean that we should > also mess things up in the same way. This is where we have the disconnect with the kids. The kids claim that "it doesn't work in [gmail | hotmail | yahoo | etc.], therefore it's useless and should be abolished." In turn, vendors that write this crapware are not made to give a damn. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From blong@google.com Thu Feb 23 15:12:53 2012 Return-Path: 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 C674721F88B5 for ; Thu, 23 Feb 2012 15:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.874 X-Spam-Level: X-Spam-Status: No, score=-102.874 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 6rwJ1GWDeu0e for ; Thu, 23 Feb 2012 15:12:53 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD79621F88B9 for ; Thu, 23 Feb 2012 15:12:52 -0800 (PST) Received: by qcsq13 with SMTP id q13so183603qcs.31 for ; Thu, 23 Feb 2012 15:12:52 -0800 (PST) Received-SPF: pass (google.com: domain of blong@google.com designates 10.229.135.11 as permitted sender) client-ip=10.229.135.11; Authentication-Results: mr.google.com; spf=pass (google.com: domain of blong@google.com designates 10.229.135.11 as permitted sender) smtp.mail=blong@google.com; dkim=pass header.i=blong@google.com Received: from mr.google.com ([10.229.135.11]) by 10.229.135.11 with SMTP id l11mr2507109qct.140.1330038772360 (num_hops = 1); Thu, 23 Feb 2012 15:12:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-system-of-record; bh=QRgvrkhX33Uvdfad+5O2k/+oE66g9wjUVfWvv17E9wE=; b=W4tCiyU/gm/XUAWtElVPQLy3mFG2sfC1GSa1ctjpV290l7gMrIwTCWETXmWO2nG/dc z0gZ0+jDgEWfeioERWQ9XiL+8GI1cN+UaeHxx1LquSq5e/Ce7nvWRM5VkVd3ZxpkKn7+ DUW5iH18SR/B07G1tDAwvbiJhd7GcBXZLSRnM= Received: by 10.229.135.11 with SMTP id l11mr2149110qct.140.1330038772257; Thu, 23 Feb 2012 15:12:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.135.11 with SMTP id l11mr2149094qct.140.1330038772021; Thu, 23 Feb 2012 15:12:52 -0800 (PST) Received: by 10.229.216.201 with HTTP; Thu, 23 Feb 2012 15:12:51 -0800 (PST) Date: Thu, 23 Feb 2012 15:12:51 -0800 Message-ID: From: Brandon Long To: Tony Hansen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQljh6Zg098gPo8DGYjHpPvzv3eiBFPI3Yz0tXm1XxtNJDaju+Mg0hQ9yI0qphJc7WmbWuyNmFRYPv95kidquKD5y0j1vQwh47WnpkIaL7vNwJ2cZ7bbP3Zaswm7E9v4wJG6di/p Cc: imap5@ietf.org Subject: [imap5] broken message/rfc822 handling X-BeenThere: imap5@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion on drastically slimming-down IMAP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 23:12:53 -0000 The bug was only happening on some messages, and kept falling behind other work. I've stolen it back and taken a look, and it was actually a deliberate change in our parser to handle some types of broken email, though I think the change was done incorrectly. Basically, its broken if the message/rfc822 message has a content-disposition of attachment, but works otherwise. The example message it was designed to fix attached an actual .eml file as message/rfc822 but base64 encoded it. base64 (or quoted-printable) encoding of a message/* is illegal per RFC 2045 section 6, so the correct solution was to consider the message/rfc822 not a multipart container if it was encoded, not if it was of disposition attachment. In theory, we could base64 decode the part, but that would be a much bigger change to the parser. Fix forthcoming. Brandon On Thu, Feb 23, 2012 at 7:43 AM, Tony Hansen wrote: > Totally off topic: I wish I knew how to get them to fix that. I get bit b= y > it regularly. > > On topic: because gmail messes up in this area doesn't mean that we shoul= d > also mess things up in the same way. > > I am a firm believer in the use of message/rfc822 attachments. > > =A0 =A0Tony Hansen > > > On 2/23/2012 9:51 AM, Jan Kundr=E1t wrote: >> >> On 02/20/12 11:52, Tony Finch wrote: >>> >>> message/rfc822 is also good. IMO every message that is forwarded or >>> top-post replied should use message/rfc822 attachments rather than doin= g >>> some fucked up redaction of the original message. >> >> GMail still breaks [1] on such messages -- the web interface shows the >> message source and the IMAP server returns invalid BODYSTRUCTURE which >> doesn't allow accessing the attached message. >> >> Cheers, >> Jan >> >> [1] http://permalink.gmane.org/gmane.mail.imap.general/2637 > > > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 From dave@cridland.net Thu Feb 23 15:16:01 2012 Return-Path: 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 C07DF21F8702 for ; Thu, 23 Feb 2012 15:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 Uk9Mxwhfyita for ; Thu, 23 Feb 2012 15:16:01 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 1633621E8018 for ; Thu, 23 Feb 2012 15:16:01 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id C3CCA1168087; Thu, 23 Feb 2012 23:15:57 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYCoS0QbCDfp; Thu, 23 Feb 2012 23:15:55 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 9DF4C1168067; Thu, 23 Feb 2012 23:15:54 +0000 (GMT) References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> In-Reply-To: <4F465EBC.7090206@att.com> MIME-Version: 1.0 Message-Id: <16456.1330038954.623322@puncture> Date: Thu, 23 Feb 2012 23:15:54 +0000 From: Dave Cridland To: Tony Hansen , "Discussion on drastically slimming-down IMAP\." Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 23:16:01 -0000 On Thu Feb 23 15:43:56 2012, Tony Hansen wrote: > Totally off topic: I wish I knew how to get them to fix that. And now you know... Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From blong@google.com Thu Feb 23 16:09:47 2012 Return-Path: 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 1F15721F866E for ; Thu, 23 Feb 2012 16:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.892 X-Spam-Level: X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 qC-ZnvF11Et6 for ; Thu, 23 Feb 2012 16:09:46 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 363FB21F8581 for ; Thu, 23 Feb 2012 16:09:46 -0800 (PST) Received: by qcsq13 with SMTP id q13so204939qcs.31 for ; Thu, 23 Feb 2012 16:09:45 -0800 (PST) Received-SPF: pass (google.com: domain of blong@google.com designates 10.229.111.165 as permitted sender) client-ip=10.229.111.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of blong@google.com designates 10.229.111.165 as permitted sender) smtp.mail=blong@google.com; dkim=pass header.i=blong@google.com Received: from mr.google.com ([10.229.111.165]) by 10.229.111.165 with SMTP id s37mr2669747qcp.80.1330042185850 (num_hops = 1); Thu, 23 Feb 2012 16:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=R0hop3jr/7zhib6lHr3KmvObRI5yRi8TZfrJXaB/Cp0=; b=xjc9/D+Q1aERs1WAgOsvIwm5j3hwxwZGKeaon+PyspW1+l6klsOOSvjU+CKyJs7QCu BMjiuWNOftA0CZssT4bzGdgqzJkkebbYt5kIRORcSeT/kluPZtxZG/ljahwF8jypZLRC zkblK+0d/RN8HWisqOmMtcaWqICFu0pUmtWNE= Received: by 10.229.111.165 with SMTP id s37mr2291806qcp.80.1330042185755; Thu, 23 Feb 2012 16:09:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.111.165 with SMTP id s37mr2291797qcp.80.1330042185596; Thu, 23 Feb 2012 16:09:45 -0800 (PST) Received: by 10.229.216.201 with HTTP; Thu, 23 Feb 2012 16:09:45 -0800 (PST) In-Reply-To: <16456.1330038954.623322@puncture> References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> <16456.1330038954.623322@puncture> Date: Thu, 23 Feb 2012 16:09:45 -0800 Message-ID: From: Brandon Long To: Dave Cridland Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmf4yodB4FTTUK36/08dWg9IErH3mNsiPnIOdwquslYdGYU+BXZzklMm7/m6xJEpI9Hs+MaPcBGHJsEj0T+NyJfh+V39XTAtVUMivqy+opNnr/MuSIVcU0/fWmsBDGUmrAEx+AE Cc: "Discussion on drastically slimming-down IMAP." 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:09:47 -0000 On Thu, Feb 23, 2012 at 3:15 PM, Dave Cridland wrote: > On Thu Feb 23 15:43:56 2012, Tony Hansen wrote: >> >> Totally off topic: I wish I knew how to get them to fix that. > > > And now you know... I'm sure there are other corner cases as well, just looking through the code there are all sorts of caveats and such to work around bugs generated by specific clients. To bring this back on-topic, if the goal is simpler, is it simpler for the server to implement parsing or to punt that to the client? This specific case could have been solved by the client implementing a viewer for rfc822, though obviously its heavier weight if the embedded message has many other levels. OTOH, its simpler on clients if they don't have to implement all of the work-arounds for broken mail that we do. Or maybe a much simpler flattened structure for messages as parsed by the server and you can download the whole thing to parse the original if you want higher fidelity. Of course, if we aren't parsing the messages on the server, we have to ask why we're implementing IMAP5 and not POP4 (still not sure if that statement will make Marc laugh or cringe). Brandon From arnt@gulbrandsen.priv.no Fri Feb 24 01:00:12 2012 Return-Path: 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 8DD6D21F85E6 for ; Fri, 24 Feb 2012 01:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 moqj1ZMU1xxi for ; Fri, 24 Feb 2012 01:00:12 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id E6B6821F85E1 for ; Fri, 24 Feb 2012 01:00:11 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 216CEF8C9BE; Fri, 24 Feb 2012 09:00:00 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1330073999-25139-25139/10/1; Fri, 24 Feb 2012 08:59:59 +0000 Message-Id: <4F4751C0.20709@gulbrandsen.priv.no> Date: Fri, 24 Feb 2012 10:00:48 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: imap5@ietf.org References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> <16456.1330038954.623322@puncture> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:00:12 -0000 On 02/24/2012 01:09 AM, Brandon Long wrote: > Of course, if we aren't parsing the messages on the server, we have to > ask why we're implementing IMAP5 and not POP4 Some time ago you wrote that IMAP is the de facto API for talking to gmail. I understand that you offer POP too, but IMAP's what people use, right? Arnt From blong@google.com Fri Feb 24 11:48:25 2012 Return-Path: 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 5B54021F8740 for ; Fri, 24 Feb 2012 11:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.904 X-Spam-Level: X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 AWzu5T7A1ajc for ; Fri, 24 Feb 2012 11:48:24 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7121F8745 for ; Fri, 24 Feb 2012 11:48:24 -0800 (PST) Received: by qcsq13 with SMTP id q13so710314qcs.31 for ; Fri, 24 Feb 2012 11:48:24 -0800 (PST) Received-SPF: pass (google.com: domain of blong@google.com designates 10.229.76.195 as permitted sender) client-ip=10.229.76.195; Authentication-Results: mr.google.com; spf=pass (google.com: domain of blong@google.com designates 10.229.76.195 as permitted sender) smtp.mail=blong@google.com; dkim=pass header.i=blong@google.com Received: from mr.google.com ([10.229.76.195]) by 10.229.76.195 with SMTP id d3mr3050010qck.40.1330112903998 (num_hops = 1); Fri, 24 Feb 2012 11:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=41tsgHxYadRCSM8MStKTbmhi3DqY0ynJZGL8Zp/i4w8=; b=wioQoh5dOLDqQ89OHhur9rBOdZHg3aTpyQfbIK02WO50AsD5dMTegWQkeUlLBzD2Eq 1imZSdKFv4eKBQIShdVtxv4SHIc0ChuhJBCH0DtetncEQQszSlAW7P7yErc2+ZgsN7ZG Rr7TWt3e/XS+RWxbh3BWWsH9jKoOHxeYB93WY= Received: by 10.229.76.195 with SMTP id d3mr2517924qck.40.1330112903904; Fri, 24 Feb 2012 11:48:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.76.195 with SMTP id d3mr2517911qck.40.1330112903646; Fri, 24 Feb 2012 11:48:23 -0800 (PST) Received: by 10.229.216.201 with HTTP; Fri, 24 Feb 2012 11:48:23 -0800 (PST) In-Reply-To: <4F4751C0.20709@gulbrandsen.priv.no> References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> <16456.1330038954.623322@puncture> <4F4751C0.20709@gulbrandsen.priv.no> Date: Fri, 24 Feb 2012 11:48:23 -0800 Message-ID: From: Brandon Long To: Arnt Gulbrandsen Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkpIfHLuhhuRH8XVYhY7qSWTFVq579JQAQ3K3O8lUppkbi4xn2lI5uyv6MPmqpy7av7TJqOclfEVZhgNoPSfwa2fMcmYUWAY4JYMTDpN8hbh0NNqDiVMX9ssfEhlu5tBFlXRxNo Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 19:48:25 -0000 On Fri, Feb 24, 2012 at 1:00 AM, Arnt Gulbrandsen wrote: > On 02/24/2012 01:09 AM, Brandon Long wrote: >> Of course, if we aren't parsing the messages on the server, we have to >> ask why we're implementing IMAP5 and not POP4 > > Some time ago you wrote that IMAP is the de facto API for talking to > gmail. I understand that you offer POP too, but IMAP's what people use, > right? Yes. For simple backups / migrations, they'll tend to use POP which is easier to deal with, but for anything that requires actually writing to the store or getting specific pieces of information, performing searches, obviously IMAP is the better choice. I was being mostly facetious about POP4. There may be an argument for a simpler protocol which does 2-way syncing in a log-like fashion with a side-order of mail sending. That's essentially what the Android Gmail client uses (our own http based two-way sync based on actual changes going across). But, I tend to be a believer in the off-line syncing clients instead of the always connected ones. Brandon From adrien@qbik.com Fri Feb 24 12:28:55 2012 Return-Path: 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 A84C521F881F for ; Fri, 24 Feb 2012 12:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=-0.897, 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 E1B4Zenuxvcm for ; Fri, 24 Feb 2012 12:28:54 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4933C21F8815 for ; Fri, 24 Feb 2012 12:28:54 -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 3386)) with SMTP id <0018882018@smtp.qbik.com>; Sat, 25 Feb 2012 09:28:50 +1300 Message-ID: <4F47F310.3040203@qbik.com> Date: Sat, 25 Feb 2012 09:29:04 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Brandon Long References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> <16456.1330038954.623322@puncture> <4F4751C0.20709@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imap5@ietf.org, Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 20:28:55 -0000 The obvious application for server-side parsing is providing the ability to search the store without having to download the whole thing first. In many cases it's simply not possible otherwise. I think it's a very compelling feature. Which for me means server-side parsing should stay. One could argue that to a certain level it could be simplified. Providing a complete nested body structure is only really relied on by some clients. Many just download the whole, or parts and then parse client-side. But I don't know to what level, and since we have an existing working mechanism. As for always connected vs offline & connect-as-required. I think these are 2 useful cases. In-house corporate use can benefit from always connected, but it doesn't scale well for huge providers. Being able to re-establish some state without having to go through the whole setup phase could be an interesting option to look into, e.g. some reusable token (good for a certain amount of time since last use) would allow the server to cache the "session" and the client to re-establish quickly. Adrien On 25/02/2012 8:48 a.m., Brandon Long wrote: > On Fri, Feb 24, 2012 at 1:00 AM, Arnt Gulbrandsen > wrote: >> On 02/24/2012 01:09 AM, Brandon Long wrote: >>> Of course, if we aren't parsing the messages on the server, we have to >>> ask why we're implementing IMAP5 and not POP4 >> Some time ago you wrote that IMAP is the de facto API for talking to >> gmail. I understand that you offer POP too, but IMAP's what people use, >> right? > Yes. For simple backups / migrations, they'll tend to use POP which > is easier to deal with, but for anything that requires actually > writing to the store or getting specific pieces of information, > performing searches, obviously IMAP is the better choice. > > I was being mostly facetious about POP4. There may be an argument for > a simpler protocol which does 2-way syncing in a log-like fashion with > a side-order of mail sending. That's essentially what the Android > Gmail client uses (our own http based two-way sync based on actual > changes going across). But, I tend to be a believer in the off-line > syncing clients instead of the always connected ones. > > Brandon > _______________________________________________ > imap5 mailing list > imap5@ietf.org > https://www.ietf.org/mailman/listinfo/imap5 -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From blong@google.com Fri Feb 24 13:23:10 2012 Return-Path: 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 4970121F8753 for ; Fri, 24 Feb 2012 13:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.913 X-Spam-Level: X-Spam-Status: No, score=-102.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 w0HfzUhM9YZd for ; Fri, 24 Feb 2012 13:23:09 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9D921F8650 for ; Fri, 24 Feb 2012 13:23:08 -0800 (PST) Received: by qcsq13 with SMTP id q13so753168qcs.31 for ; Fri, 24 Feb 2012 13:23:08 -0800 (PST) Received-SPF: pass (google.com: domain of blong@google.com designates 10.229.111.165 as permitted sender) client-ip=10.229.111.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of blong@google.com designates 10.229.111.165 as permitted sender) smtp.mail=blong@google.com; dkim=pass header.i=blong@google.com Received: from mr.google.com ([10.229.111.165]) by 10.229.111.165 with SMTP id s37mr3210959qcp.80.1330118588685 (num_hops = 1); Fri, 24 Feb 2012 13:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=zk8BceXMiurthXGz3HFSCm6cISwBHgabFjSSWTVEu7o=; b=xZAp2rFquCPw+84CH2mX3jClKlURo3fCiYTrKxzohAIyG/Lx82aan/2m7viTlJiucv 2CaoDJgYII6HKz45elOMlSYiydpfG+ytNvtXeyfXmWrv/Oz2msKIDlDidIiSpiXc+2eB pjA8RjacK/DkupDmPobQqIXSeVc+AgA75PkQ4= Received: by 10.229.111.165 with SMTP id s37mr2663701qcp.80.1330118588575; Fri, 24 Feb 2012 13:23:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.111.165 with SMTP id s37mr2663689qcp.80.1330118588257; Fri, 24 Feb 2012 13:23:08 -0800 (PST) Received: by 10.229.216.201 with HTTP; Fri, 24 Feb 2012 13:23:08 -0800 (PST) In-Reply-To: <4F47F310.3040203@qbik.com> References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> <16456.1330038954.623322@puncture> <4F4751C0.20709@gulbrandsen.priv.no> <4F47F310.3040203@qbik.com> Date: Fri, 24 Feb 2012 13:23:08 -0800 Message-ID: From: Brandon Long To: Adrien de Croy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQld5VKwpe8ncZLbG4auM66VZnVFuC9LvUWHWiJ+fVyAN0iflPBrrTq7wpX4SdZ/VFBy6zoHhRY/hzD1RXIDzsIPjDlXIyu5RdQR+Dm03j8rMJ5uui5xo1iMm1aIxxtmkJxplce+ Cc: imap5@ietf.org, Arnt Gulbrandsen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 21:23:10 -0000 On Fri, Feb 24, 2012 at 12:29 PM, Adrien de Croy wrote: > > The obvious application for server-side parsing is providing the ability = to > search the store without having to download the whole thing first. In man= y > cases it's simply not possible otherwise. > > I think it's a very compelling feature. =A0Which for me means server-side > parsing should stay. > > One could argue that to a certain level it could be simplified. =A0Provid= ing a > complete nested body structure is only really relied on by some clients. > =A0Many just download the whole, or parts and then parse client-side. > > But I don't know to what level, and since we have an existing working > mechanism. > > As for always connected vs offline & connect-as-required. =A0I think thes= e are > 2 useful cases. =A0In-house corporate use can benefit from always connect= ed, > but it doesn't scale well for huge providers. =A0Being able to re-establi= sh > some state without having to go through the whole setup phase could be an > interesting option to look into, e.g. some reusable token (good for a > certain amount of time since last use) would allow the server to cache th= e > "session" and the client to re-establish quickly. That was in the P-IMAP proposal, which I assume means it was discussed in lemonade, anyone recall why it didn't go anywhere? Granted, with qresync/condstore, session maintenance probably isn't as important. Brandon From dave@cridland.net Fri Feb 24 15:12:54 2012 Return-Path: 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 5378821F8620 for ; Fri, 24 Feb 2012 15:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 sJI17Ww0MtaG for ; Fri, 24 Feb 2012 15:12:53 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 598AE21F863D for ; Fri, 24 Feb 2012 15:12:53 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 479181168087; Fri, 24 Feb 2012 23:12:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whB7sXplrVK3; Fri, 24 Feb 2012 23:12:41 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id A357F1168067; Fri, 24 Feb 2012 23:12:40 +0000 (GMT) References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <4F3D6E57.8010301@qbik.com> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <20120219192604.GA11323@launde.brong.net> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> <16456.1330038954.623322@puncture> <4F4751C0.20709@gulbrandsen.priv.no> <4F47F310.3040203@qbik.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <16456.1330125160.642317@puncture> Date: Fri, 24 Feb 2012 23:12:40 +0000 From: Dave Cridland To: Brandon Long , "Discussion on drastically slimming-down IMAP\." , Arnt Gulbrandsen , Adrien de Croy Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 23:12:54 -0000 On Fri Feb 24 21:23:08 2012, Brandon Long wrote: > That was in the P-IMAP proposal, which I assume means it was > discussed > in lemonade, anyone recall why it didn't go anywhere? > > It forces scalability to be per-device, rather than per-user. It generally struck me as fairly fragile, too - typically, the server's going to erase older tokens after a while, and limit the numbers, and there's no fallback at all. > Granted, with qresync/condstore, session maintenance probably isn't > as > important. Right, and QRESYNC doesn't require *any* state beyond CONDSTORE's 64-bits per message and per folder. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade