From internet-drafts@ietf.org Tue Oct 8 07:11:25 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C54911E8195; Tue, 8 Oct 2013 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 yC0B7uy-IdjE; Tue, 8 Oct 2013 07:11:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E195D11E81AB; Tue, 8 Oct 2013 07:11:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 07:11:22 -0700 Cc: imapext@ietf.org Subject: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 14:11:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IMAP QRESYNC Extension Working Group of t= he IETF. Title : IMAP Extensions for Conditional STORE Operation or Quick= Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchroniza= tion (QRESYNC) Author(s) : Alexey Melnikov Dave Cridland Filename : draft-ietf-qresync-rfc5162bis-03.txt Pages : 47 Date : 2013-10-08 Abstract: Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document additionally defines another IMAP extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-qresync-rfc5162bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexey.melnikov@isode.com Tue Oct 8 07:18:30 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92CC21E819C for ; Tue, 8 Oct 2013 07:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 R-VIGnlu1yw8 for ; Tue, 8 Oct 2013 07:18:30 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0952B21E809B for ; Tue, 8 Oct 2013 07:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1381241907; d=isode.com; s=selector; i=@isode.com; bh=0W4TqxqZqo/vujlv7P4F9gzZ+Ye2SThNxNrgpNWCbnA=; 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=A3PQwYhC5rScR0sc/4AEWoJZMOWJCMy6rGgISJtyCjOyzAggBQhbCTvtO8WFgQ4XrQ+cKh e02/B8/GJcIYtQATMJl0Ks1I0wRHdoUpd7QxrMJLEwcBapB4KVaARXC59FcY+SkpA+qak/ EdVILHBUiGEOe05MZyphfQxq2uf3ZQA=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 8 Oct 2013 15:18:27 +0100 Message-ID: <52541433.4000705@isode.com> Date: Tue, 08 Oct 2013 15:18:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: imapext@ietf.org References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> In-Reply-To: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 14:18:30 -0000 On 08/10/2013 15:11, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IMAP QRESYNC Extension Working Group of the IETF. > > Title : IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) > Author(s) : Alexey Melnikov > Dave Cridland > Filename : draft-ietf-qresync-rfc5162bis-03.txt > Pages : 47 > Date : 2013-10-08 > > Abstract: > Often, multiple IMAP (RFC 3501) clients need to coordinate changes to > a common IMAP mailbox. Examples include different clients working on > behalf of the same user, and multiple users accessing shared > mailboxes. These clients need a mechanism to synchronize state > changes for messages within the mailbox. They must be able to > guarantee that only one client can change message state (e.g., > message flags) at any time. An example of such an application is use > of an IMAP mailbox as a message queue with multiple dequeueing > clients. > > The Conditional Store facility provides a protected update mechanism > for message state information that can detect and resolve conflicts > between multiple writing mail clients. > > The Conditional Store facility also allows a client to quickly > resynchronize mailbox flag changes. > > This document additionally defines another IMAP extension, which > gives an IMAP client the ability to quickly resynchronize any > previously opened mailbox as part of the SELECT command, without the > need for server-side state or additional client round-trips. This > extension also introduces a new response that allows for a more > compact representation of a list of expunged messages (and always > includes the Unique Identifiers (UIDs) expunged). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-qresync-rfc5162bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-qresync-rfc5162bis-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-qresync-rfc5162bis-03 I finally got around to producing a merged CONDSTORE+QRESYNC spec. I have a small list of editorial changes to do, but this should be largely complete. A fresh review of the combined spec would be greatly appreciated! From dave@cridland.net Tue Oct 8 08:20:01 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD29321E80A6 for ; Tue, 8 Oct 2013 08:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 6z8gIgIRdRME for ; Tue, 8 Oct 2013 08:20:01 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CAADA21E80A5 for ; Tue, 8 Oct 2013 08:20:00 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so6912394lbh.19 for ; Tue, 08 Oct 2013 08:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nkka04Bx8RQhUYjUvYHEfTw7Fnj8Hk3sjShSWAAySVc=; b=FxSGHboTFlBUEMNQYlShTp/VO240tbGY21ko8PEXZmP0VyLIZ58/RpNdPUUlm7esO6 CZFFzrkDPPpqu4SIIZ2c5WoBJnsQcwEPPSK5q+BHWj07KV07FP8VXZJvVcig/3KvKiDw h18TH5nl40e9Cyi0E1AN7Ih/awOBgGeEPhlfE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Nkka04Bx8RQhUYjUvYHEfTw7Fnj8Hk3sjShSWAAySVc=; b=XAx0IxyEqGVZjWDPywyXm1anofuJDlaQql7sKyfPieQVZBXVs0m1bVpIKNKukirfwA PJLftw5A2OkIwUqpeEi9dajl7HzBFr0u4hiAMJ0jt6euZW+Dmn9+ktcjR7x7vp5r7Asm s8ete/yymj8CKGVqdHyWlk+ODwGKE8D9/jN65OxT4CVxhWh1CAO0adEn0RTHbXuzKJPW VYLhBIyJgduo3faHQa6MIsYZIW9Mv+MnOofvOdI+xgOoW+IeqwUOGK2t/lpuZSf7Q8Am ipmB0I3KpCkzUKImr6NKUf/M7iUksY1No0v3ZgtMwgrXcHyYbSa3biIuHjUEG/nKrO6A 3Zow== X-Gm-Message-State: ALoCoQlrwYDtU7UfKmP/ulPdNQgg3HPqrHIjT22sfKEzkC/mBxBEkSmCxzE6AW4Wh43wOI3CMe4p MIME-Version: 1.0 X-Received: by 10.112.167.3 with SMTP id zk3mr2889188lbb.23.1381245599443; Tue, 08 Oct 2013 08:19:59 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Tue, 8 Oct 2013 08:19:59 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Tue, 8 Oct 2013 08:19:59 -0700 (PDT) In-Reply-To: <52541433.4000705@isode.com> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <52541433.4000705@isode.com> Date: Tue, 8 Oct 2013 16:19:59 +0100 Message-ID: From: Dave Cridland To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11c264a44d7da404e83c4ddf Cc: imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 15:20:01 -0000 --001a11c264a44d7da404e83c4ddf Content-Type: text/plain; charset=ISO-8859-1 On 8 Oct 2013 10:18, "Alexey Melnikov" wrote: > I finally got around to producing a merged CONDSTORE+QRESYNC spec. > > I have a small list of editorial changes to do, but this should be largely complete. A fresh review of the combined spec would be greatly appreciated! Thanks for this Alexey. I know I'll be reading this through - who else is willing to read through it? Dave. --001a11c264a44d7da404e83c4ddf Content-Type: text/html; charset=ISO-8859-1


On 8 Oct 2013 10:18, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:
> I finally got around to producing a merged CONDSTORE+QRESYNC spec.
>
> I have a small list of editorial changes to do, but this should be largely complete. A fresh review of the combined spec would be greatly appreciated!

Thanks for this Alexey.

I know I'll be reading this through - who else is willing to read through it?

Dave.

--001a11c264a44d7da404e83c4ddf-- From chris.newman@oracle.com Mon Oct 21 10:51:39 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4797411E8178 for ; Mon, 21 Oct 2013 10:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 DgQ4C2Wv8O+8 for ; Mon, 21 Oct 2013 10:51:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DC1B411E820F for ; Mon, 21 Oct 2013 10:51:14 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LHpCqN028773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 17:51:12 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LHpBCG025616; Mon, 21 Oct 2013 17:51:11 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPA id <0MV10075Y5L8PF00@gotmail.us.oracle.com>; Mon, 21 Oct 2013 10:51:10 -0700 (PDT) Date: Mon, 21 Oct 2013 10:51:07 -0700 From: Chris Newman To: Dave Cridland , Alexey Melnikov Message-id: <75656BCB8A6D8A5AFA520D35@96B2F16665FF96BAE59E9B90> In-reply-to: References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <52541433.4000705@isode.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:51:39 -0000 I'll read it. - Chris --On October 8, 2013 16:19:59 +0100 Dave Cridland wrote: > On 8 Oct 2013 10:18, "Alexey Melnikov" wrote: >> I finally got around to producing a merged CONDSTORE+QRESYNC spec. >> >> I have a small list of editorial changes to do, but this should be > largely complete. A fresh review of the combined spec would be greatly > appreciated! > > Thanks for this Alexey. > > I know I'll be reading this through - who else is willing to read through > it? From dave@cridland.net Mon Oct 21 11:10:00 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AE811E8122 for ; Mon, 21 Oct 2013 11:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 geS4W+O0yGEj for ; Mon, 21 Oct 2013 11:09:54 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9E74C11E832F for ; Mon, 21 Oct 2013 11:08:47 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id o14so1618051lbi.37 for ; Mon, 21 Oct 2013 11:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fI82EqfbgWivJ8KSfQyznwviF0uPGvjxnNsPowr+Qfo=; b=RTPEDkUTe2Z88mg7WAhhwSCE3umaBA2M9HDsXth6qR9ULC5DvhsiSy8kMNXV/U4yQG RnlWuBqOf1terMcY2v+c6Gvmak7Xjsyb3n6OK/nwgYjk4uu7Yji/fjJ5aQ5NmyqADMEZ adhFMZ8QSBhEgPN4WR2KTnxDiGt1gd6E+FBuk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fI82EqfbgWivJ8KSfQyznwviF0uPGvjxnNsPowr+Qfo=; b=akGQKiiA39BJHhIgApMa14y/qmX3pSpmphNAQuR3G68o8oiHHp8T7IoLroBr+od1lh X/IL77hKv6MpZjNAD0P3zTJzQtQeUr5t14ZVrY8CfrxCOWUaH3sfI/C/a8ojqHrfGq1C czN/uVrQB8P0Sv89KvOgTkYODyTwv07hm3OAcKMBaGZQTtZNIXkVXXnehgayH5f0YFAo Pij69prdFDioEz/78FfjcP1TqYpv5G33IqvaAQj446Dv4/fsOnQDkm1hjJsZ61M46qZW SdBukWHI1xTLSJmFvhfrMWfAIrBRTYC+2k2WIiFTZmB8RwbxQCZyAlQEUxO0b/mo+JrR g6+A== X-Gm-Message-State: ALoCoQlcz8QjpnJ/JLD8SCk6bdr7+nDmxgyo3lJu4eCpEYqfff2sxRHgSn/ZAHuaQbxliDqYESv8 MIME-Version: 1.0 X-Received: by 10.152.10.99 with SMTP id h3mr14814565lab.13.1382378926434; Mon, 21 Oct 2013 11:08:46 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Mon, 21 Oct 2013 11:08:46 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Mon, 21 Oct 2013 11:08:46 -0700 (PDT) In-Reply-To: <75656BCB8A6D8A5AFA520D35@96B2F16665FF96BAE59E9B90> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <52541433.4000705@isode.com> <75656BCB8A6D8A5AFA520D35@96B2F16665FF96BAE59E9B90> Date: Mon, 21 Oct 2013 19:08:46 +0100 Message-ID: From: Dave Cridland To: Chris Newman Content-Type: multipart/alternative; boundary=001a1132f26adafd2f04e9442ca6 Cc: Alexey Melnikov , imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:10:01 -0000 --001a1132f26adafd2f04e9442ca6 Content-Type: text/plain; charset=ISO-8859-1 On 21 Oct 2013 10:51, "Chris Newman" wrote: > > I'll read it. Thanks, Chris. I could really use an additional few reviewers for this; can anyone else commit to reviewing over the next couple of weeks? Dave. --001a1132f26adafd2f04e9442ca6 Content-Type: text/html; charset=ISO-8859-1


On 21 Oct 2013 10:51, "Chris Newman" <chris.newman@oracle.com> wrote:
>
> I'll read it.

Thanks, Chris.

I could really use an additional few reviewers for this; can anyone else commit to reviewing over the next couple of weeks?

Dave.

--001a1132f26adafd2f04e9442ca6-- From murch@andrew.cmu.edu Mon Oct 21 11:12:01 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974BA11E8415 for ; Mon, 21 Oct 2013 11:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 sP3hYiYUDkT1 for ; Mon, 21 Oct 2013 11:11:55 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.61]) by ietfa.amsl.com (Postfix) with ESMTP id C463911E8221 for ; Mon, 21 Oct 2013 11:11:40 -0700 (PDT) Received: from [192.168.137.22] (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id r9LIBcdS000851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Oct 2013 14:11:39 -0400 Message-ID: <52656E5A.5040702@andrew.cmu.edu> Date: Mon, 21 Oct 2013 14:11:38 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dave Cridland References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <52541433.4000705@isode.com> <75656BCB8A6D8A5AFA520D35@96B2F16665FF96BAE59E9B90> <32189_1382379015_r9LIAEDr000702_CAKHUCzwHbAZ1Xt-qws7niM+vdxhBT1yeDkkz9=Q3FTOrE4T1uQ@mail.gmail.com> In-Reply-To: <32189_1382379015_r9LIAEDr000702_CAKHUCzwHbAZ1Xt-qws7niM+vdxhBT1yeDkkz9=Q3FTOrE4T1uQ@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------060901060100030608020402" X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.18.170322 X-SMTP-Spam-Clean: 8% ( HTML_50_70 0.1, HTML_NO_HTTP 0.1, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_HTML 0, __HAS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_POOLED_2 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 8% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.61 Cc: Alexey Melnikov , imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:12:01 -0000 This is a multi-part message in MIME format. --------------060901060100030608020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/21/2013 02:08 PM, Dave Cridland wrote: > > > On 21 Oct 2013 10:51, "Chris Newman" > wrote: > > > > I'll read it. > > Thanks, Chris. > > I could really use an additional few reviewers for this; can anyone > else commit to reviewing over the next couple of weeks? > Dave, I will read it. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------060901060100030608020402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/21/2013 02:08 PM, Dave Cridland wrote:


On 21 Oct 2013 10:51, "Chris Newman" <chris.newman@oracle.com> wrote:
>
> I'll read it.

Thanks, Chris.

I could really use an additional few reviewers for this; can anyone else commit to reviewing over the next couple of weeks?


Dave,

I will read it.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------060901060100030608020402-- From chris.newman@oracle.com Mon Oct 21 13:03:16 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAFD11E8254 for ; Mon, 21 Oct 2013 13:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 1dMS3tibnLkC for ; Mon, 21 Oct 2013 13:03:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5AA11E8273 for ; Mon, 21 Oct 2013 13:02:55 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LK2r3c025128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 20:02:54 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LK2qcr016325; Mon, 21 Oct 2013 20:02:52 GMT MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPA id <0MV10076QBOPPF00@gotmail.us.oracle.com>; Mon, 21 Oct 2013 13:02:51 -0700 (PDT) Date: Mon, 21 Oct 2013 13:02:48 -0700 From: Chris Newman To: Nigar Sultana , Alexey Melnikov Message-id: <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> In-reply-to: <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-transfer-encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: imapext@ietf.org Subject: Re: [imapext] RFC 3501 - IMAP CREATE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:03:16 -0000 I just submitted a draft describing the mechanism we've used for this=20 scenario: The basic approach for the service acting on behalf of multiple users is to = use SASL PLAIN to authenticate as the target user (authorization identity)=20 with administrative credentials (authentication identity). The service can=20 then issue standard IMAP commands as that user, and then UNAUTHENTICATE to=20 reuse the connection. The problem with authenticating as the admin and using namespace tricks is=20 then the admin has no access to per-user information such as per-user \seen = flags or annotations. So it doesn't work as a general solution. - Chris --On September 10, 2013 21:10:42 +0800 Nigar Sultana=20 wrote: > Dear Alexey and Dave, > > In my previous mail might be i have not given the complete scenario. > thanks for the response. > > Following are the elements that connect to IMAP server. "3rd party > application" and "end user through mobile"=C2=A0 > > The scenarios IMAP server should support is:=C2=A0 > 1. 3rd party application can store messages on IMAP server on behalf of > end user, in end user mailbox (it should be in user's default = folder).=C2=A0 > example: end user has done messaging through mobile and those messages > 3rd party application should store in user mailbox. Each message sent in > a particular session should be a folder. End user here - User-A and the > hierarchy of storage structure should be:=C2=A0 > User-A->defaultFolder->session1->Msg1......Msgn > User-A->defaultFolder->session2->Msg1.......Msgn > Here session1 and session2 is folder. Msg1 to Msgn are messages > > > 2. End user through mobile can access to mailbox and sync those message > in case of multi-device. Additional functionality can be end users can > also create user-folders and copy the messages from default-folders > > > Now to achieve scenario#1: 3rd party application should first create the > folder in end user's mailbox and then do an APPEND to store the messages > in users mailbox (example is given above). The IMAP server what we are > planning to design will not explicitly create end user folder, instead > will have the mapping to link to user's default folder mailbox. So when > the 3rd party application will use CREATE command (as per RFC 3501) then > IMAP Server should do the parsing, if parsing is introduced then the > process becomes heavy, this is what the opinion our team has. So is there > any easy step which can be used to simplify the processing on IMAP > server???. If we use the NAMESPACE does it simplify??? > > spec wise if we go then the command will be: > CREATE /User-A/defaultFolder/session1 > APPEND mailbox {length} message > > > Is there any other method where we can split the mailbox path into > "UserId + mailbox path" like: so that the process need not do parsing and > hence the process will not become heavy: CREATE User-A > /defauleFolder/session1 > APPEND User-A mailbox=C2=A0 > > So our team were of opinion to introduce IMAP extension to CREATE and > APPEND. for this response i got from Alexe is not a good idea > > Can we solve this with the use of NAMESPACE?=C2=A0 > > Regards > Nigar S=C2=A0 > > > ________________________________ > From: Alexey Melnikov > To: Nigar Sultana > Cc: "imapext@ietf.org" > Sent: Tuesday, 10 September 2013 3:50 PM > Subject: Re: [imapext] RFC 3501 - IMAP CREATE > > > > On 10/09/2013 09:58, Nigar Sultana wrote: > > Hello All, > Hi, > > We have to design IMAP server which allows a third party application to > store the messages on behalf of end user.=C2=A0 >> >> >> If we use "CREATE" command as per spec (RFC 3501) then IMAP server >> processing becomes heavy because it should parse the path and then store >> the messages in user's mailbox and we should also have the parsing logic >> to distinguish whether the connection is from third party or end user. > I am not entirely sure what you are trying to do, but I think > http://www.rfc-editor.org/rfc/rfc2342.txt (IMAP NAMESPACE) should solve > your problem. > > > Is there an "extension CREATE" commands where the third party can > indicate the "end user information" and "mail box path" in separate > arguments >> Example: CREATE abc@test.com INBOX/TemporaryFolder > Using a namespace prefix, this can become something like this (you > can pick a different prefix): > CREATE "Other Users/abc@test.com/INBOX/TemporaryFolder" > > > As an alternate option can we implement IMAP extension commands prefixed > with "X" Probably not a good idea. > > Best Regards, > Alexey From tss@iki.fi Mon Oct 21 13:14:10 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAB211E864B for ; Mon, 21 Oct 2013 13:14:10 -0700 (PDT) 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 V4ATBQ3ICHIj for ; Mon, 21 Oct 2013 13:14:05 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 31AD211E862E for ; Mon, 21 Oct 2013 13:14:02 -0700 (PDT) Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 7AAA31AE884B; Mon, 21 Oct 2013 23:14:00 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Timo Sirainen In-Reply-To: <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> Date: Mon, 21 Oct 2013 23:14:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <920FE75F-A0C2-49F8-96A6-466F98C1C6EB@iki.fi> References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> To: Chris Newman X-Mailer: Apple Mail (2.1510) Cc: imapext@ietf.org Subject: Re: [imapext] RFC 3501 - IMAP CREATE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:14:10 -0000 On 21.10.2013, at 23.02, Chris Newman wrote: > I just submitted a draft describing the mechanism we've used for this = scenario: >=20 > >=20 > The basic approach for the service acting on behalf of multiple users = is to use SASL PLAIN to authenticate as the target user (authorization = identity) with administrative credentials (authentication identity). The = service can then issue standard IMAP commands as that user, and then = UNAUTHENTICATE to reuse the connection. >=20 > The problem with authenticating as the admin and using namespace = tricks is then the admin has no access to per-user information such as = per-user \seen flags or annotations. So it doesn't work as a general = solution. Seems a bit scary extension to me. I'm going to try to avoid = implementing it, although I guess there could be a time when someone = really really wants it. But perhaps at that point it would be better to = use something else entirely than IMAP. > For efficiency reasons, it is > desirable for these clients to reuse the same connection, > particularly if SSL has been negotiated. I've understood TLS session reuse would make this much faster? I haven't = bothered to implement it so far yet though. From cyrus@daboo.name Mon Oct 21 13:29:57 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A624C11E853E for ; Mon, 21 Oct 2013 13:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 6Z6qOPUExAR0 for ; Mon, 21 Oct 2013 13:29:51 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6285611E8432 for ; Mon, 21 Oct 2013 13:29:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C95154F262F3; Mon, 21 Oct 2013 16:29:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yiYJTxGefUn; Mon, 21 Oct 2013 16:29:34 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id E7AC14F262E1; Mon, 21 Oct 2013 16:29:32 -0400 (EDT) Date: Mon, 21 Oct 2013 16:29:25 -0400 From: Cyrus Daboo To: Timo Sirainen , Chris Newman Message-ID: In-Reply-To: <920FE75F-A0C2-49F8-96A6-466F98C1C6EB@iki.fi> References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> <920FE75F-A0C2-49F8-96A6-466F98C1C6EB@iki.fi> 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=1262 Cc: imapext@ietf.org Subject: Re: [imapext] RFC 3501 - IMAP CREATE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:29:57 -0000 Hi Timo, --On October 21, 2013 at 11:14:00 PM +0300 Timo Sirainen wrote: >> The problem with authenticating as the admin and using namespace tricks >> is then the admin has no access to per-user information such as per-user >> \seen flags or annotations. So it doesn't work as a general solution. > > Seems a bit scary extension to me. I'm going to try to avoid implementing > it, although I guess there could be a time when someone really really > wants it. But perhaps at that point it would be better to use something > else entirely than IMAP. Would it be reasonable to require the authentication after an UNAUTHENTICATE to use the same "authentication identifier" as was used in the original authentication? i.e. it is OK to change the authorization identity within the same connected IMAP session, but it is not OK to change the authentication identity? I think that covers the main use case whilst adding a little more security. Also, I would imagine servers would have a config option to only enable UNAUTHENTICATE once authentication has been done, and the authenticated user is a known "trusted" user (i.e., one of the admin accounts). Certainly allowing UNAUTHENTICATE for "arbitrary" users would be scarier. -- Cyrus Daboo From cyrus@daboo.name Mon Oct 21 13:29:57 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85F411E8432 for ; Mon, 21 Oct 2013 13:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 GqLXZNSmMf+Z for ; Mon, 21 Oct 2013 13:29:57 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8839911E864B for ; Mon, 21 Oct 2013 13:29:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C95154F262F3; Mon, 21 Oct 2013 16:29:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yiYJTxGefUn; Mon, 21 Oct 2013 16:29:34 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id E7AC14F262E1; Mon, 21 Oct 2013 16:29:32 -0400 (EDT) Date: Mon, 21 Oct 2013 16:29:25 -0400 From: Cyrus Daboo To: Timo Sirainen , Chris Newman Message-ID: In-Reply-To: <920FE75F-A0C2-49F8-96A6-466F98C1C6EB@iki.fi> References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> <920FE75F-A0C2-49F8-96A6-466F98C1C6EB@iki.fi> 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=1262 Cc: imapext@ietf.org Subject: Re: [imapext] RFC 3501 - IMAP CREATE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:29:57 -0000 Hi Timo, --On October 21, 2013 at 11:14:00 PM +0300 Timo Sirainen wrote: >> The problem with authenticating as the admin and using namespace tricks >> is then the admin has no access to per-user information such as per-user >> \seen flags or annotations. So it doesn't work as a general solution. > > Seems a bit scary extension to me. I'm going to try to avoid implementing > it, although I guess there could be a time when someone really really > wants it. But perhaps at that point it would be better to use something > else entirely than IMAP. Would it be reasonable to require the authentication after an UNAUTHENTICATE to use the same "authentication identifier" as was used in the original authentication? i.e. it is OK to change the authorization identity within the same connected IMAP session, but it is not OK to change the authentication identity? I think that covers the main use case whilst adding a little more security. Also, I would imagine servers would have a config option to only enable UNAUTHENTICATE once authentication has been done, and the authenticated user is a known "trusted" user (i.e., one of the admin accounts). Certainly allowing UNAUTHENTICATE for "arbitrary" users would be scarier. -- Cyrus Daboo From tss@iki.fi Mon Oct 21 15:19:09 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8AD11E859F for ; Mon, 21 Oct 2013 15:19:09 -0700 (PDT) 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 UMnAyi7VL8H0 for ; Mon, 21 Oct 2013 15:18:56 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4966A11E86E9 for ; Mon, 21 Oct 2013 15:18:53 -0700 (PDT) Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id C9A4E1AE8802; Tue, 22 Oct 2013 01:18:51 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Timo Sirainen In-Reply-To: Date: Tue, 22 Oct 2013 01:18:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <44B65158-A652-4C3B-A104-42610C9D1138@iki.fi> References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> <920FE75F-A0C2-49F8-96A6-466F98C1C6EB@iki.fi> To: Cyrus Daboo X-Mailer: Apple Mail (2.1510) Cc: Chris Newman , imapext@ietf.org Subject: Re: [imapext] RFC 3501 - IMAP CREATE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:19:09 -0000 On 21.10.2013, at 23.29, Cyrus Daboo wrote: > --On October 21, 2013 at 11:14:00 PM +0300 Timo Sirainen = wrote: >=20 >>> The problem with authenticating as the admin and using namespace = tricks >>> is then the admin has no access to per-user information such as = per-user >>> \seen flags or annotations. So it doesn't work as a general = solution. >>=20 >> Seems a bit scary extension to me. I'm going to try to avoid = implementing >> it, although I guess there could be a time when someone really really >> wants it. But perhaps at that point it would be better to use = something >> else entirely than IMAP. >=20 > Would it be reasonable to require the authentication after an = UNAUTHENTICATE to use the same "authentication identifier" as was used = in the original authentication? i.e. it is OK to change the = authorization identity within the same connected IMAP session, but it is = not OK to change the authentication identity? I think that covers the = main use case whilst adding a little more security. Hmm. That would definitely help. Most normal users could then log in = back only as themselves. Maybe even disable that command entirely unless = auth and authz IDs differ. > Also, I would imagine servers would have a config option to only = enable UNAUTHENTICATE once authentication has been done, and the = authenticated user is a known "trusted" user (i.e., one of the admin = accounts). Certainly allowing UNAUTHENTICATE for "arbitrary" users would = be scarier. Yeah. Still, it's not something I'm looking forward to implementing. = Dovecot's security model makes it slightly difficult to implement for = some configurations (switching between different UNIX UIDs - possible of = course, but not nice). From blong@google.com Mon Oct 21 15:49:04 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A333011E87B0 for ; Mon, 21 Oct 2013 15:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 4Vo6ZcQuz6kh for ; Mon, 21 Oct 2013 15:49:00 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id CF73811E87CE for ; Mon, 21 Oct 2013 15:46:16 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so325673iet.35 for ; Mon, 21 Oct 2013 15:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QZdpw+ft2bkaOVYjKB/jMWi0yB4AU2Hd4txBGV+x+vE=; b=aSNyTVfLHzrpzvuPkDTY0wyO1O6uvwexhEmIDV7MJwzPHAcF6KqRFGpZB9V33B7BHx w/2dnT0G/Jczl2NdL38AOzoFit/9kmzORVTPC0mqW6kNza9d4Y6CKTqmK1p5mAFBG1Sd SKWIotLW0lOTDfe0XLsomTU0wl3cD27EjlxCm0d7WlTvSjUeA5JAskshzWMUeVJI/2vj SNs1Q8izrczsdYRwg6rT+7aqmwet/ewp9/xKiqw74NSRXWUht/AUWpZUFHPHVcgMts0A JyPmdcGn3WolwKYPh3ecjkz4dU7pNvSVgakbydcwG0RY9xBCc4zuin0Dh8Fsm0iT7h6r HOFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QZdpw+ft2bkaOVYjKB/jMWi0yB4AU2Hd4txBGV+x+vE=; b=A1UX32CuKJYgXFzL6ZNpp9b7YgQb4KkbcS+KbHQwnqZmUFVDqtQDK/e7rI43F/RyVV 4CO70H8Hi9peho47RZhKX/+JZMjDZ5bfdgXcXsoE+yipQ2jWAYZyBxnmENN63C5QhaNC I7kzrZQ3kiow9xHxPN3y4kv+4MxSM9aXDb+w8i8TxuWh2fSphsKzIXuIPc5IIvGlnh79 bTmJXJfhHiHBUuflzlbh6RkX9DZcHe8fp7kf+rroT+02jdv3bhFNNuXtDRChc4ZysjuW CLtKIJibunjsbc/q4hYW50tAeWspkO8spEE51t1HbYtquMgDQZMJQgSycZh3uKG64JYx 5zeQ== X-Gm-Message-State: ALoCoQlps38DShCXGBrao2JsasLmhl7sxzexjTNjycVobb4Di63SxBL94bLxanGhKVjywPKIvx4GAGP1ZRTDUdvR3hOdvaOxr8rhij0q0hgMO17q1Wb5UiAfaWpP3dAu8btEEv67SOcxpbfF8RTrHsGjl6k/GngZs9eHR2kOi4xfPyyW/UZvTFLO0jKid7rusZUjYOjwuSeV MIME-Version: 1.0 X-Received: by 10.50.40.103 with SMTP id w7mr10897519igk.53.1382395572815; Mon, 21 Oct 2013 15:46:12 -0700 (PDT) Received: by 10.64.146.35 with HTTP; Mon, 21 Oct 2013 15:46:12 -0700 (PDT) Received: by 10.64.146.35 with HTTP; Mon, 21 Oct 2013 15:46:12 -0700 (PDT) In-Reply-To: <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> Date: Mon, 21 Oct 2013 15:46:12 -0700 Message-ID: From: Brandon Long To: Nigar Sultana Content-Type: multipart/alternative; boundary=089e0122ebb00ea81e04e9480d03 Cc: Alexey Melnikov , imapext@ietf.org Subject: Re: [imapext] RFC 3501 - IMAP CREATE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:49:04 -0000 --089e0122ebb00ea81e04e9480d03 Content-Type: text/plain; charset=ISO-8859-1 You're saying that parsing /user/foo@bar.com/inbox is more expensive than parsing foo@bar.com inbox? That makes no sense. Brandon On Sep 10, 2013 6:10 AM, "Nigar Sultana" wrote: > Dear Alexey and Dave, > > In my previous mail might be i have not given the complete scenario. > thanks for the response. > > Following are the elements that connect to IMAP server. "3rd party > application" and "end user through mobile" > > The scenarios IMAP server should support is: > 1. 3rd party application can store messages on IMAP server on behalf of > end user, in end user mailbox (it should be in user's default folder). > example: end user has done messaging through mobile and those messages 3rd > party application should store in user mailbox. Each message sent in a > particular session should be a folder. End user here - User-A and the > hierarchy of storage structure should be: > User-A->defaultFolder->session1->Msg1......Msgn > User-A->defaultFolder->session2->Msg1.......Msgn > Here session1 and session2 is folder. Msg1 to Msgn are messages > > 2. End user through mobile can access to mailbox and sync those message in > case of multi-device. Additional functionality can be end users can also > create user-folders and copy the messages from default-folders > > > Now to achieve scenario#1: 3rd party application should first create the > folder in end user's mailbox and then do an APPEND to store the messages in > users mailbox (example is given above). The IMAP server what we are > planning to design will not explicitly create end user folder, instead will > have the mapping to link to user's default folder mailbox. So when the 3rd > party application will use CREATE command (as per RFC 3501) then IMAP > Server should do the parsing, if parsing is introduced then the process > becomes heavy, this is what the opinion our team has. So is there any easy > step which can be used to simplify the processing on IMAP server???. If we > use the NAMESPACE does it simplify??? > > spec wise if we go then the command will be: > CREATE /User-A/defaultFolder/session1 > APPEND mailbox {length} message > > > Is there any other method where we can split the mailbox path into "UserId > + mailbox path" like: so that the process need not do parsing and hence the > process will not become heavy: > CREATE User-A /defauleFolder/session1 > APPEND User-A mailbox > > So our team were of opinion to introduce IMAP extension to CREATE and > APPEND. for this response i got from Alexe is not a good idea > > Can we solve this with the use of NAMESPACE? > > Regards > Nigar S > > ------------------------------ > *From:* Alexey Melnikov > *To:* Nigar Sultana > *Cc:* "imapext@ietf.org" > *Sent:* Tuesday, 10 September 2013 3:50 PM > *Subject:* Re: [imapext] RFC 3501 - IMAP CREATE > > On 10/09/2013 09:58, Nigar Sultana wrote: > > Hello All, > > Hi, > > We have to design IMAP server which allows a third party application to > store the messages on behalf of end user. > > If we use "CREATE" command as per spec (RFC 3501) then IMAP server > processing becomes heavy because it should parse the path and then store > the messages in user's mailbox and we should also have the parsing logic to > distinguish whether the connection is from third party or end user. > > > I am not entirely sure what you are trying to do, but I think > http://www.rfc-editor.org/rfc/rfc2342.txt (IMAP NAMESPACE) should solve > your problem. > > Is there an "extension CREATE" commands where the third party can > indicate the "end user information" and "mail box path" in separate > arguments > Example: CREATE abc@test.com INBOX/TemporaryFolder > > > Using a namespace prefix, this can become something like this (you can > pick a different prefix): > CREATE "Other Users/abc@test.com/INBOX/TemporaryFolder" > > As an alternate option can we implement IMAP extension commands prefixed > with "X" > > > Probably not a good idea. > > Best Regards, > Alexey > > > > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > > --089e0122ebb00ea81e04e9480d03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

You're saying that parsing /user/foo@bar.com/inbox is more expensive than parsing foo@bar.com inbox?

That makes no sense.

Brandon

On Sep 10, 2013 6:10 AM, "Nigar Sultana&quo= t; <nigarsultana_n@yahoo.c= o.in> wrote:
<= div>Dear Alexey and Dave,

In my previ= ous mail might be i have not given the complete scenario. thanks for the re= sponse.

Following are the elements that connect to IMAP server. "3rd party app= lication" and "end user through mobile"=A0

=
The scenarios IMAP server should support is:=A0
1. 3rd party application can store messages on IMAP serv= er on behalf of end user, in end user mailbox (it should be in user's d= efault folder).=A0
example: end user has done messagi= ng through mobile and those messages 3rd party application should store in = user mailbox. Each message sent in a particular session should be a folder. End user here - User-A and the hierarchy of storage structure should be:=A0<= /div>
User-A->defaultFolder->session1->Msg1......Msgn
User-A->defaultFolder->s= ession2->Msg1.......Msgn
<= span style=3D"background-color:transparent"> Here session1 and session2 is folder. Msg1 to Msgn are messag= es

2. End user through mobile can access to mailbox and sync those message in = case of multi-device. Additional functionality can be end users can also cr= eate user-folders and copy the messages from default-folders


Now to achieve scenario#1: 3rd party application should first create the fo= lder in end user's mailbox and then do an APPEND to store the messages = in users mailbox (example is given above). The IMAP server what we are plan= ning to design will not explicitly create end user folder, instead will hav= e the mapping to link to user's default folder mailbox. So when the 3rd= party application will use CREATE command (as per RFC 3501) then IMAP Serv= er should do the parsing, if parsing is introduced then the process becomes= heavy, this is what the opinion our team has. So is there any easy step wh= ich can be used to simplify the processing on IMAP server???. If we use the= NAMESPACE does it simplify???

spec wise if we go then the command will be:
CREATE /User-A= /defaultFolder/session1
APPEND mailbox {length} message


Is there any other method where we can split the mailbox path into "UserId + mailbox path" like= : so that the process need not do parsing and hence the process will not be= come heavy:
CREATE User-A /defa= uleFolder/session1
APPEND User-A mailb= ox=A0

So our team were of opinion to introduce IMAP extension to CREATE and APPEN= D. for this response i got from Alexe is not a good idea

Can we solve this with t= he use of NAMESPACE?=A0

Regards
Nigar S=A0
From: Alexey Melnikov <alexey.melnikov@isode.com&g= t;
To: Nigar Sultana <= ;nigarsulta= na_n@yahoo.co.in>
Cc: "imapext@ietf.org" <imapext@ietf.org= >
Sent: Tuesday,= 10 September 2013 3:50 PM
Subject:= Re: [imapext] RFC 3501 - IMAP CREATE

=20 =20 =20
On 10/09/2013 09:58, Nigar Sultana wrote:
Hello All,
Hi,
We have to design IMAP ser= ver which allows a third party application to store the messages on behalf of end user.=A0

If we use "CREATE&quo= t; command as per spec (RFC 3501) then IMAP server processing becomes heavy because it should parse the path and then store the messages in user'= s mailbox and we should also have the parsing logic to distinguish whether the connection is from third party or end user.

I am not entirely sure what you are trying to do, but I think http://www.rfc-editor.org/rfc/rfc2342.txt (IMAP NAMES= PACE) should solve your problem.

Is there an "extensio= n CREATE" commands where the third party can indicate the "end user information= " and "mail box path" in separate arguments
Example: CREATE abc@test.com INBOX/TemporaryFolder

Using a namespace prefix, this can become something like this (you can pick a different prefix):
CREATE "Other Users/abc@test.com/INBOX/Tempora= ryFolder"

As an alternate option can= we implement IMAP extension commands prefixed with "X"

Probably not a good idea.

Best Regards,
Alexey




_______________________= ________________________
imapext mailing list
imapext@ietf.org
https://www.ietf.org/mailman/listinfo/imapext

--089e0122ebb00ea81e04e9480d03-- From blong@google.com Mon Oct 21 16:03:21 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03A411E8723 for ; Mon, 21 Oct 2013 16:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 6jB80dn0XZua for ; Mon, 21 Oct 2013 16:03:19 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3947A11E8798 for ; Mon, 21 Oct 2013 16:02:55 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id e14so331613iej.39 for ; Mon, 21 Oct 2013 16:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bsiq4pXyAylEZBq80niNOfUfVfMkVNPzx7JYn6JWwMg=; b=ZfwJMR9iipaQIQiKy68QjZz+Q5piPIlXBsnXDNikz3Z1lgsl7x+Ki/+Vp/O0fb+86x Dv/MfYxHbyJXE2CwtmD0azGiECAg3JsjQv6cMWiY3ozWxnADk5iqx3T22Xw6PvA5jB4N wGFz062k+7/gHP9u7KDDoJizGq3yp+jmRBVerkwh8gWkJi3sd6xJm067Y+g5fCfGIPjX r5fRgrQ7CyN5SwvovpccuFLX00KOOrJzRfn5mhB5o7iWBphCZv1yXSvDHCwVXqGfvo8x F/9HAMPPQ6w2wHoraJAUlWMw8PXERQrygcYkLXUPLgpQFNYj3w3vgriNuhxV/xIuI0TD 3Uqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bsiq4pXyAylEZBq80niNOfUfVfMkVNPzx7JYn6JWwMg=; b=KJi8WYI2JYQDZV2qXr2wIPEO3nRNJOfzxDhc/3F1ZG0At9N+FZO0bXsa8kNpoSXwxU LOqrIbDcjFzwrx9tIikA8cZZmzZtbEFg6YhkaPDYzQcJ1f1KZwuAAMjsTqAz9LaDOUGF vjtokiG1vGFhg/zxBSOxC3FI51MFtIqxlp6xi7s7IMi2AHSTiihXYXL09RnmEsEDpzo+ /gVPc4EU3z4LB4u4suni58uHABRzYv0WoBxegSPiypklTrsxjM50oKNXw8rQJE2Gbx4P WE95U/2Bc9H/eV1LHL6/otaJ6pEZytP2gqj+/c/jv7gSUpIar9GSDQq7lZfSOCze/9sQ Y+nA== X-Gm-Message-State: ALoCoQkydyUj6pnX9vbEjOA57mDjDJvNyFeIfVtqKP9FsuQz70QgQbOe22Mo4TdKPMbrm9ydCuStWgeUwU0icCUci5vK/XkiP6Y81Utpx+1foHXFebP3/mKXJHR0yDoCQqjQNbZ4/C7XHiNy5jvKe6LJOmUaNJpDo3jmLBWEFusou6/abkPswl7SGMSGyz4n7Xjl9slLEim0 MIME-Version: 1.0 X-Received: by 10.42.77.8 with SMTP id g8mr293562ick.47.1382396574480; Mon, 21 Oct 2013 16:02:54 -0700 (PDT) Received: by 10.64.146.35 with HTTP; Mon, 21 Oct 2013 16:02:54 -0700 (PDT) Received: by 10.64.146.35 with HTTP; Mon, 21 Oct 2013 16:02:54 -0700 (PDT) In-Reply-To: <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> Date: Mon, 21 Oct 2013 16:02:54 -0700 Message-ID: From: Brandon Long To: Chris Newman Content-Type: multipart/alternative; boundary=20cf30063f22c2eda904e94848d2 Cc: Alexey Melnikov , Nigar Sultana , imapext@ietf.org Subject: Re: [imapext] RFC 3501 - IMAP CREATE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:03:22 -0000 --20cf30063f22c2eda904e94848d2 Content-Type: text/plain; charset=ISO-8859-1 I find it hard to believe that connection reuse here has that much of an advantage as to be worth the implementation challenge for many environments. Certainly, there is high overhead in setting up an imap connection beyond connect, but most of those things are also reset in this proposal (see for ex the connection resume proposal a while back). As we run in the proxy model outlined in the doc, handling this would be challenging and require oob data on internal connection close. I would also expect this to impact the throughput of the system as the third party queues updates to reuse connections instead of just applying them in parallel. Brandon On Oct 21, 2013 1:03 PM, "Chris Newman" wrote: > I just submitted a draft describing the mechanism we've used for this > scenario: > > > > > > The basic approach for the service acting on behalf of multiple users is > to use SASL PLAIN to authenticate as the target user (authorization > identity) with administrative credentials (authentication identity). The > service can then issue standard IMAP commands as that user, and then > UNAUTHENTICATE to reuse the connection. > > The problem with authenticating as the admin and using namespace tricks is > then the admin has no access to per-user information such as per-user \seen > flags or annotations. So it doesn't work as a general solution. > > - Chris > > --On September 10, 2013 21:10:42 +0800 Nigar Sultana < > nigarsultana_n@yahoo.co.in> wrote: > > Dear Alexey and Dave, >> >> In my previous mail might be i have not given the complete scenario. >> thanks for the response. >> >> Following are the elements that connect to IMAP server. "3rd party >> application" and "end user through mobile" >> >> The scenarios IMAP server should support is: >> 1. 3rd party application can store messages on IMAP server on behalf of >> end user, in end user mailbox (it should be in user's default folder). >> example: end user has done messaging through mobile and those messages >> 3rd party application should store in user mailbox. Each message sent in >> a particular session should be a folder. End user here - User-A and the >> hierarchy of storage structure should be: >> User-A->defaultFolder->**session1->Msg1......Msgn >> User-A->defaultFolder->**session2->Msg1.......Msgn >> Here session1 and session2 is folder. Msg1 to Msgn are messages >> >> >> 2. End user through mobile can access to mailbox and sync those message >> in case of multi-device. Additional functionality can be end users can >> also create user-folders and copy the messages from default-folders >> >> >> Now to achieve scenario#1: 3rd party application should first create the >> folder in end user's mailbox and then do an APPEND to store the messages >> in users mailbox (example is given above). The IMAP server what we are >> planning to design will not explicitly create end user folder, instead >> will have the mapping to link to user's default folder mailbox. So when >> the 3rd party application will use CREATE command (as per RFC 3501) then >> IMAP Server should do the parsing, if parsing is introduced then the >> process becomes heavy, this is what the opinion our team has. So is there >> any easy step which can be used to simplify the processing on IMAP >> server???. If we use the NAMESPACE does it simplify??? >> >> spec wise if we go then the command will be: >> CREATE /User-A/defaultFolder/session1 >> APPEND mailbox {length} message >> >> >> Is there any other method where we can split the mailbox path into >> "UserId + mailbox path" like: so that the process need not do parsing and >> hence the process will not become heavy: CREATE User-A >> /defauleFolder/session1 >> APPEND User-A mailbox >> >> So our team were of opinion to introduce IMAP extension to CREATE and >> APPEND. for this response i got from Alexe is not a good idea >> >> Can we solve this with the use of NAMESPACE? >> >> Regards >> Nigar S >> >> >> ______________________________**__ >> From: Alexey Melnikov >> To: Nigar Sultana >> Cc: "imapext@ietf.org" >> Sent: Tuesday, 10 September 2013 3:50 PM >> Subject: Re: [imapext] RFC 3501 - IMAP CREATE >> >> >> >> On 10/09/2013 09:58, Nigar Sultana wrote: >> >> Hello All, >> Hi, >> >> We have to design IMAP server which allows a third party application to >> store the messages on behalf of end user. >> >>> >>> >>> If we use "CREATE" command as per spec (RFC 3501) then IMAP server >>> processing becomes heavy because it should parse the path and then store >>> the messages in user's mailbox and we should also have the parsing logic >>> to distinguish whether the connection is from third party or end user. >>> >> I am not entirely sure what you are trying to do, but I think >> http://www.rfc-editor.org/rfc/**rfc2342.txt(IMAP NAMESPACE) should solve >> your problem. >> >> >> Is there an "extension CREATE" commands where the third party can >> indicate the "end user information" and "mail box path" in separate >> arguments >> >>> Example: CREATE abc@test.com INBOX/TemporaryFolder >>> >> Using a namespace prefix, this can become something like this (you >> can pick a different prefix): >> CREATE "Other Users/abc@test.com/INBOX/**TemporaryFolder >> " >> >> >> As an alternate option can we implement IMAP extension commands prefixed >> with "X" Probably not a good idea. >> >> Best Regards, >> Alexey >> > > > > > ______________________________**_________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/**listinfo/imapext > --20cf30063f22c2eda904e94848d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I find it hard to believe that connection reuse here has tha= t much of an advantage as to be worth the implementation challenge for many= environments.=A0 Certainly, there is high overhead in setting up an imap c= onnection beyond connect, but most of those things are also reset in this p= roposal (see for ex the connection resume proposal a while back).

As we run in the proxy model outlined in the doc, handling t= his would be challenging and require oob data on internal connection close.=

I would also expect this to impact the throughput of the sys= tem as the third party queues updates to reuse connections instead of just = applying them in parallel.

Brandon

On Oct 21, 2013 1:03 PM, "Chris Newman"= ; <chris.newman@oracle.com> wrote:
I just submitted a draft describing the mechanism we've used for this s= cenario:

=A0<http://www.ietf.org/id/draft-newman-imap-unauth-00.= txt>

The basic approach for the service acting on behalf of multiple users is to= use SASL PLAIN to authenticate as the target user (authorization identity)= with administrative credentials (authentication identity). The service can= then issue standard IMAP commands as that user, and then UNAUTHENTICATE to= reuse the connection.

The problem with authenticating as the admin and using namespace tricks is = then the admin has no access to per-user information such as per-user \seen= flags or annotations. So it doesn't work as a general solution.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Chris

--On September 10, 2013 21:10:42 +0800 Nigar Sultana <nigarsultana_n@yahoo.co.in> wrote:

Dear Alexey and Dave,

In my previous mail might be i have not given the complete scenario.
thanks for the response.

Following are the elements that connect to IMAP server. "3rd party
application" and "end user through mobile"=A0

The scenarios IMAP server should support is:=A0
1. 3rd party application can store messages on IMAP server on behalf of
end user, in end user mailbox (it should be in user's default folder).= =A0
example: end user has done messaging through mobile and those messages
3rd party application should store in user mailbox. Each message sent in a particular session should be a folder. End user here - User-A and the
hierarchy of storage structure should be:=A0
User-A->defaultFolder->session1->Msg1......Msgn
User-A->defaultFolder->session2->Msg1.......Msgn
Here session1 and session2 is folder. Msg1 to Msgn are messages


2. End user through mobile can access to mailbox and sync those message
in case of multi-device. Additional functionality can be end users can
also create user-folders and copy the messages from default-folders


Now to achieve scenario#1: 3rd party application should first create the folder in end user's mailbox and then do an APPEND to store the message= s
in users mailbox (example is given above). The IMAP server what we are
planning to design will not explicitly create end user folder, instead
will have the mapping to link to user's default folder mailbox. So when=
the 3rd party application will use CREATE command (as per RFC 3501) then IMAP Server should do the parsing, if parsing is introduced then the
process becomes heavy, this is what the opinion our team has. So is there any easy step which can be used to simplify the processing on IMAP
server???. If we use the NAMESPACE does it simplify???

spec wise if we go then the command will be:
CREATE /User-A/defaultFolder/session1
APPEND mailbox {length} message


Is there any other method where we can split the mailbox path into
"UserId + mailbox path" like: so that the process need not do par= sing and
hence the process will not become heavy: CREATE User-A
/defauleFolder/session1
APPEND User-A mailbox=A0

So our team were of opinion to introduce IMAP extension to CREATE and
APPEND. for this response i got from Alexe is not a good idea

Can we solve this with the use of NAMESPACE?=A0

Regards
Nigar S=A0


________________________________
=A0From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Nigar Sultana <nigarsultana_n@yahoo.co.in>
Cc: "imapext@iet= f.org" <i= mapext@ietf.org>
Sent: Tuesday, 10 September 2013 3:50 PM
Subject: Re: [imapext] RFC 3501 - IMAP CREATE



On 10/09/2013 09:58, Nigar Sultana wrote:

Hello All,
Hi,

We have to design IMAP server which allows a third party application to
store the messages on behalf of end user.=A0


If we use "CREATE" command as per spec (RFC 3501) then IMAP serve= r
processing becomes heavy because it should parse the path and then store the messages in user's mailbox and we should also have the parsing logi= c
to distinguish whether the connection is from third party or end user.
I am not entirely sure what you are trying to do, but I think
htt= p://www.rfc-editor.org/rfc/rfc2342.txt (IMAP NAMESPACE) should s= olve
your problem.


Is there an "extension CREATE" commands where the third party can=
indicate the "end user information" and "mail box path"= in separate
arguments
Example: CREATE abc@test.= com INBOX/TemporaryFolder
Using a namespace prefix, this can become something like this (you
=A0 =A0 can pick a different prefix):
CREATE "Other Users/abc@test.com/INBOX/TemporaryFolder"

As an alternate option can we implement IMAP extension commands prefixed with "X" Probably not a good idea.

Best Regards,
Alexey




_______________________________________________
imapext mailing list
imapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/imapext
--20cf30063f22c2eda904e94848d2-- From arnt@gulbrandsen.priv.no Mon Oct 21 23:58:14 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7ED11E848E for ; Mon, 21 Oct 2013 23:58:14 -0700 (PDT) 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.001, 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 stQO2evPpuOT for ; Mon, 21 Oct 2013 23:58:09 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 34B2E11E8487 for ; Mon, 21 Oct 2013 23:58:04 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5B385FA007D; Tue, 22 Oct 2013 06:58:03 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1382425082-17357-17356/11/38; Tue, 22 Oct 2013 06:58:02 +0000 Date: Tue, 22 Oct 2013 08:58:02 +0200 From: Arnt Gulbrandsen To: Chris Newman Message-Id: <20131022065758.GA12483@gulbrandsen.priv.no> References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> In-Reply-To: <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexey Melnikov , Nigar Sultana , imapext@ietf.org Subject: Re: [imapext] RFC 3501 - IMAP CREATE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 06:58:14 -0000 JFYI, consider it a digression, I know someone else who does the same thing and uses Oauth. The IMAP server supports an Oauth SASL mechanism, the user blesses the agent, and the agent logs in with Oauth credentials. Arnt From chris.newman@oracle.com Tue Oct 22 13:54:28 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A6C11E8282 for ; Tue, 22 Oct 2013 13:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 8+XlTfW2ZRvt for ; Tue, 22 Oct 2013 13:54:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3E03C11E81CD for ; Tue, 22 Oct 2013 13:54:23 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9MKsBng021480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Oct 2013 20:54:12 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9MKs9iC003146; Tue, 22 Oct 2013 20:54:10 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPA id <0MV300B738Q6NG00@gotmail.us.oracle.com>; Tue, 22 Oct 2013 13:54:08 -0700 (PDT) Date: Tue, 22 Oct 2013 13:54:05 -0700 From: Chris Newman To: Timo Sirainen , Cyrus Daboo , Brandon Long Message-id: In-reply-to: <920FE75F-A0C2-49F8-96A6-466F98C1C6EB@iki.fi> <44B65158-A652-4C3B-A104-42610C9D1138@iki.fi> References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> <920FE75F-A0C2-49F8-96A6-466F98C1C6EB@iki.fi> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Alexey Melnikov , Nigar Sultana , imapext@ietf.org Subject: Re: [imapext] RFC 3501 - IMAP CREATE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:54:28 -0000 --On October 21, 2013 23:14:00 +0300 Timo Sirainen wrote: >On 21.10.2013, at 23.02, Chris Newman wrote: >> I just submitted a draft describing the mechanism we've used for this scenario: >> >> >... > Seems a bit scary extension to me. LDAP has UNBIND in the base specification. I think UNAUTHENTICATE is only 'scary' because I bothered to think through the security implications and write them down. > I'm going to try to avoid implementing > it, although I guess there could be a time when someone really really > wants it. But perhaps at that point it would be better to use something > else entirely than IMAP. I'm proposing this as an extension that's useful for the server-acting-on-behalf-of scenario. I don't think every IMAP server should implement it; only those that need it. Of course if my server is the only implementation then there's no point going standards track. Is anyone else interested in implementing this? If you're interested in traffic isolation, I've been contemplating the idea of running IMAP on two ports with different behaviors -- an end-user port and an admin port. If I do that, in addition to having UNAUTHENTICATE only on the admin port, I'd make SASL-admin-proxy authentication only work on the admin imap port. If the admin imap port is blocked at the firewall, that's better security then doing everything on 143/993. I'm thinking of mentioning this as a mitigation in the security considerations. Any thoughts on whether it would be helpful to register a well-known port for admin imap? >> For efficiency reasons, it is >> desirable for these clients to reuse the same connection, >> particularly if SSL has been negotiated. > > I've understood TLS session reuse would make this much faster? I haven't > bothered to implement it so far yet though. Does it help if it isn't implemented? ;-) TLS session reuse still requires multiple round-trips for TCP setup and a round trip for TLS setup. And the code is far more complex than unauthenticate in many cases. Plus the requirement we get from these peer servers is always "we need a way to reuse open connections", not "we need a relatively efficient TLS session reuse mechanism". Implementers like the model with which they're familiar. --On October 21, 2013 16:29:25 -0400 Cyrus Daboo wrote: > Would it be reasonable to require the authentication after an > UNAUTHENTICATE to use the same "authentication identifier" as was used in > the original authentication? i.e. it is OK to change the authorization > identity within the same connected IMAP session, but it is not OK to > change the authentication identity? I think that covers the main use case > whilst adding a little more security. That makes the security model more complex and increases the size of the security sensitive code (thus increasing the attack surface). I'd then have to save the identity information between authentication session contexts, provide a way to pass in previous-identity information, and provide behavior variations based on previous-identity information. It adds some new rather complex test cases. I'm not a fan of this idea. > Also, I would imagine servers would have a config option to only enable > UNAUTHENTICATE once authentication has been done, and the authenticated > user is a known "trusted" user (i.e., one of the admin accounts). > Certainly allowing UNAUTHENTICATE for "arbitrary" users would be scarier. This is an excellent idea. The code to do this is all post-authentication so there's no impact to the primary attack surface. I'll add it to the next version of the specification. --On October 22, 2013 1:18:51 +0300 Timo Sirainen wrote: > Yeah. Still, it's not something I'm looking forward to implementing. > Dovecot's security model makes it slightly difficult to implement for > some configurations (switching between different UNIX UIDs - possible of > course, but not nice). I wouldn't recommend implementing UNAUTHENTICATE in a server with the different UNIX UID security model. It's a classic performance-vs-security tradeoff, and if you implemented the different UNIX UID model, you're already on the security side of that tradeoff and I doubt the value of unauthenticate would be worth the cost in that case. I'll note that a smart proxy could implement UNAUTHENTICATE even if the back-end server does not so that may be one way to get some of the benefits without impacting the back-end security model. --On October 21, 2013 16:02:54 -0700 Brandon Long wrote: > I find it hard to believe that connection reuse here has that much of an > advantage as to be worth the implementation challenge for many > environments. Certainly, there is high overhead in setting up an imap > connection beyond connect, but most of those things are also reset in this > proposal (see for ex the connection resume proposal a while back). For our backend IMAP server, the implementation was almost trivial as it involved splitting the IMAP context datastructure cleanup code already used by LOGOUT into two parts -- an unauthenticate part and a logout part. Then walk through and zero out most of the other datastructure fields in the unauthenticate routine. So this was a very good cost/benefit for us. > As we run in the proxy model outlined in the doc, handling this would be > challenging and require oob data on internal connection close. We presently use the same proxy model, but I think this is one of the lesser problems with that model and think moving to a full smart proxy is the right way to address this. The proxy problem can be avoided if the peer servers that use unauthenticate bypass the proxy and connect directly to the user's mailHost. > I would also expect this to impact the throughput of the system as the > third party queues updates to reuse connections instead of just applying > them in parallel. I expect they use the standard connection-pool model. If a re-usable connection is idle in the pool, then use it, if not then create a new connection if below the max pool connection limit. Our embedded LDAP client does this and it works great as long as you don't over-design it. - Chris