From brong@fastmail.fm Sun Dec 2 15:03:09 2012 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 8A41621F881F for ; Sun, 2 Dec 2012 15:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.413 X-Spam-Level: * X-Spam-Status: No, score=1.413 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+0IlCoRgCPe for ; Sun, 2 Dec 2012 15:03:08 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7C321F881B for ; Sun, 2 Dec 2012 15:03:08 -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 151D020645; Sun, 2 Dec 2012 18:03:08 -0500 (EST) Received: from web4.nyi.mail.srv.osa ([10.202.2.214]) by compute4.internal (MEProxy); Sun, 02 Dec 2012 18:03:08 -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=Wavd9CP0wkAmqpHrU4Ctn2F 9w5A=; b=W395ui0T8FRp/p0hterFetLQ1DAFj0q2s6XfoZKlMVHNtW8kToHYEOs jtxNLrsWaot9xoJaEWWxCHkm8CiN9H1PEk8a6YfxmofLc80W3vcD7HzxfchCQfa6 deuxuEPFMkwkGMIzORQb1EwcEdyNB6H3FJoC7oht2GRgHe8yomiE= 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=Wavd9CP0wkAmqpHrU4Ctn2F9w5A=; b=KVX4m6tqlWG0owU19D6ZHXxX8mTC rAWqFQvTqSrrMiOiNS+HfceN37pS683o/fHQ3zQMcyq32FPUMxOF+taTIiUb6zrV Kc0QLXRisx0rJbIoyZQ9n0VlYawgLbxHnTky/gjzjGSszPu8v0ao1HWg0TzolFq4 tqtdv66RFoIcNxg= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id C3EDC3C4500; Sun, 2 Dec 2012 18:03:07 -0500 (EST) Message-Id: <1354489387.4917.140661160937461.1324AF11@webmail.messagingengine.com> X-Sasl-Enc: +km88nMcSRBHytehSdkZ2ziFoTrUL9AO3ow3j+lBYTls 1354489387 From: Bron Gondwana To: "imapext@ietf.org" , Cyrus Devel , Timo Sirainen , Greg Banks , David Carter MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html Date: Mon, 03 Dec 2012 00:03:07 +0100 Subject: [imapext] After MOVE - I propose DUMP/RESTORE format 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: Sun, 02 Dec 2012 23:03:09 -0000 Now that MOVE is settling down, I really want to explore a vendor-neutral DUMP and RESTORE format for IMAP mail stores. I haven't given up on the IMAP5 concept - though in discussion with Arnt recently we have both come to the conclusion that another stateful long-lived protocol is probably not right. What would be more useful to those of us trying to build large clustered solutions is a protocol which is more batch based, so it could be used in a connectionless way, without needing a complex stateful proxy in the middle. I'll come back to that. Anyway - DUMP/RESTORE and Replication. David (cc'd) did the initial work for replication in Cyrus, and I've built on that with with new protocol in Cyrus 2.4. It has some warts though - it exposes far too much Cyrus implementation specifics. I want to use the same concepts for a backup format which is durable, incremental, and can be restored in such a way that a client which connected again later can not tell that it's connecting to a restored copy of the mailbox rather than the original mailbox. I would also change our replication protocol for Cyrus to be based on making synthetic incremental backups and applying them to the replica - so that in theory any server which supported the DUMP/RESTORE format would be able to be a replication source or destination. Why do I think this is useful? ============================== For users: * ability to move between mail providers more easily (just import and export mailboxes) For providers: * ability to switch server software. * ability to take efficient incremental backups which can be restored exactly as taken (at least in the case of Cyrus, this doesn't currently exist - you can't backup an entire mailbox at a point in time without having to reconstruct afterwards to clean up the mess - it doesn't do snapshots) For us at FastMail/Opera: * replace our custom-built Cyrus backup tool which does under-the-hood locking magic with something standard. How Cyrus Replication works: ============================ We take advantage of the MODSEQ values from CONDSTORE/QRESYNC to work out what needs to be sent to bring the replica into date. At FastMail we test our replicas once per week by running a set of IMAP queries against both the master and replica (repeating multiple times in case of mismatch so we don't get too many false positives). These queries are designed to exercise all the interesting fields, so that we know the replication protocol is working correctly. To ensure integrity, we also calculate a "SYNC_CRC" value. This is the XOR of a CRC32 for each UID in the mailbox. The CRC32 for the individual UIDs is calculated on a string formatted from all the mutable fields of the message. This allows efficient updates, because you can just calculate the old and new values on each change, and XOR them together to get the new SYNC_CRC value. In the case of a SYNC_CRC mismatch, we download all the metadata (similar to FETCH 1:* (UID FLAGS INTERNALDATE MODSEQ)) for every record and calculate what changes need to be made on the replica to bring it back into sync. This is where UID promotion happens if the content of the message is different. We do mismatch detection with a GUID field (actually DIGEST.SHA1 on the RFC822 body) Here's an example from the wire: <13544886701354488670>OK DEFLATE active <13544886701354488670>OK success Creating two mailboxes: <13544886851354488685>OK success <13544886851354488685>OK success <13544886851354488685>OK success Appending two messages. First we query the remote end to see what's there now: <13544886871354488687>* MAILBOX %(UNIQUEID fa8673d7-471e-4d5b-9c7f-f3ee64106447 MBOXNAME user.foo LAST_UID 0 HIGHESTMODSEQ 2 RECENTUID 0 RECENTTIME 0 LAST_APPENDDATE 0 POP3_LAST_LOGIN 0 POP3_SHOW_AFTER 0 UIDVALIDITY 1354488684 PARTITION default ACL "foo lrswipkxtecdan admin lrswipkxtecd " OPTIONS P SYNC_CRC 0) OK success Then we try to reserve those messages (this is a waste of time really, it shouldn't bother trying, that's a bug): <13544886871354488687>* MISSING (196922b6d822b618c665874fb523b9058a0adb56 ec4a76ae5e5f772dee837494134c75069286623a) OK success <1354488687 To: test Some stuff in the body... . %{default ec4a76ae5e5f772dee837494134c75069286623a 372} Return-Path: Received: from local (slot2 [127.0.0.52]) by test_slot2_4092 (Cyrus git2.5+0) with LMTPA; Sun, 02 Dec 2012 23:51:26 +0100 X-Sieve: CMU Sieve 2.4 From: test To: test Message-ID: Date: Sun, 02 Dec 2012 23:51:26 +0100 Some stuff in the body... ) >1354488687>OK success And finally, now that the messages are spooled, we update the mailbox view. <13544886871354488687>OK success This is somewhat wasteful - it should be able to cache the remote state and speculatively calculate a diff against what it expects to be there and upload that as a single incremental dump. In the usual case that the other end hasn't changed, it could just apply that dump and return the successful result. NOTE though: SYNC_CRC 31431471. The remote end calculates that after applying these changes, and returns "OK" because it matched. You can also see plenty of the warts there - both the %() syntax and things like POP3_LAST_LOGIN and OPTIONS which are horribly vendor-specific. Interesting bits to consider: ============================= When backing up an entire user, you definitely want message de-duplication. For FastMail, we delay EXPUNGE for a week, and also back up the EXPUNGEd messages so that we our "restore from backup" feature can always find all messages EXPUNGEd in the last week, even if we lose a server. So this means there needs to be a way to cross-refererence a message in another mailbox. Cyrus uses SHA1 as the GUID, and uploads messages with that identifier first before applying the rest of the changes. For a standard I believ we don't want to use a hash that's already on its way out as the default, so we should look at an alternative to this. There needs to be a way to read just the essential metadata from a backup file quickly (that is uidvalidity,lastuid,highestmodseq) to calculate which UIDs need their data included in the new backup, and which also need their message bodies or XREFs included - similar to the "GET MAILBOXES ()" query in the example above. It also makes sense to have the format allow including an entire user's mailboxes rather than doing each mailbox individually, since the XREFs would otherwise be across backup files. The format needs to both support every piece of data needed for every current extension, and be extensible enough that new extensions' data can be added. Things I can think of immediately are METADATA/ANNOTATION information, and what we in Cyrus call DELETEDMODSEQ - strictly, the MODSEQ of the last EXPUNGEd message for which you have forgotten the metadata. Without this, you can't efficiently reply to QRESYNC queries, because you need to tell about every gap in the UID sequence in case the a message in there went away. Thanks you: =========== If you've read this far, thank you! My goal is a format which captures every piece of data which is required for any client connecting to the server to be unable to see that it's a different server than previously after a DUMP/RESTORE (assuming the server supports the same extensions of course). Anything which can be re-parsed from the message RFC822 doesn't belong in this format, only fields which are mutable (like FLAGS), set externally (like INTERNALDATE), or necessary metadata about the past (like MODSEQ and friends). The biggest question facing me up front - what does it look like on the disk/wire? The Cyrus protocol at the moment looks almost like IMAP, and parses almost like IMAP - with the added warts that it uses %() to designate a list with key/value pairs rather than a list of items, and it uses %{partition sha1 size} rather than {size+} to designate rfc822 messages. That is clearly bogus for a generally applicable protocol. The list of fields to include is quite clear - the only real consideration is whether to support backups without MODSEQ information in them. They make incremental backups a lot harder, since you have to read all the UID records from the old backup and compare them to the current values to determine if anything has changed (like naive clients doing FETCH 1:*). I would like a backup format that can support ANY server though, and be built over regular IMAP by a standalone tool. Regards, Bron. -- Bron Gondwana brong@fastmail.fm From thomas.dressler@1und1.de Mon Dec 3 01:35:54 2012 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 4DBBE21F8863 for ; Mon, 3 Dec 2012 01:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdvqPEs9oF5u for ; Mon, 3 Dec 2012 01:35:53 -0800 (PST) Received: from mxintern.schlund.de (mxintern.schlund.de [212.227.126.205]) by ietfa.amsl.com (Postfix) with ESMTP id A404F21F885A for ; Mon, 3 Dec 2012 01:35:53 -0800 (PST) Received: from [172.17.15.97] by mxintern.schlund.de with esmtp (envelope-from ) id 1TfSRM-000d8f-Eq; Mon, 03 Dec 2012 10:35:52 +0100 Message-ID: <50BC7278.40104@1und1.de> Date: Mon, 03 Dec 2012 10:35:52 +0100 From: Thomas Dressler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Timo Sirainen References: <20121129162637.28724.48381.idtracker@ietfa.amsl.com> <8305E0CF-DFC8-49E4-B95E-D3E0BB575DE0@iki.fi> In-Reply-To: <8305E0CF-DFC8-49E4-B95E-D3E0BB575DE0@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-UI-Msg-Verification: 9fedf9be7c17173f0dc98449ccad00b6 Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.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, 03 Dec 2012 09:35:54 -0000 On 29.11.2012 22:04, Timo Sirainen wrote: > I guess I should have read this more closely earlier: > >> When a message is moved to a target mailbox, if the server is capable >> of storing modification sequences for the mailbox, the server MUST >> generate a new modification sequence that is higher than the highest >> modification sequence of all messages in the mailbox and assign it to >> the moved message. > This seems to mean each moved message MUST have a new different modification sequence. My server gives the same new modseq for all of them. > > In general, maybe there shouldn't be any MUSTs at all in section 4? They may unintentionally add extra restrictions that aren't in the base documents. I now see another problem: > >> 4.3. RFC 4315, UIDPLUS >> >> Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in response to >> a UID MOVE command. > This shouldn't be a MUST, since it adds a restriction not present in RFC 4315: > > [RFC2359] implied that a server must always return COPYUID/APPENDUID > data; thus suggesting that in such cases the server should return > arbitrary data if the destination mailbox did not support persistent > UIDs. This document adds the UIDNOTSTICKY response code to indicate > that a mailbox does not support persistent UIDs, and stipulates that > a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY > (or APPEND) destination mailbox has UIDNOTSTICKY status. > > > also if no mail was moved? example: C: a SELECT a S: * 1 EXISTS S: * 1 RECENT S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Unlimited S: * OK [UIDNEXT 2] Predicted next UID S: * OK [UIDVALIDITY 1354526937] UIDs valid S: a OK [READ-WRITE] SELECT completed ... someone else remove this one mail. C: b UID MOVE 1 b S: * 1 EXPUNGE S: * 0 EXISTS S: * 0 RECENT S: b OK UID MOVE completed can we add an complete example with some asynchronus expunged mails? (one for UID MOVE and one with MOVE). -- Thomas Dressler Software-Entwickler 1&1 Internet AG - Mail System Development Brauerstrasse 48 DE-76135 Karlsruhe Telefon: +49 721 91374-6790 thomas.dressler@1und1.de Amtsgericht Montabaur / HRB 6484 Vorstaende: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen Aufsichtsratsvorsitzender: Michael Scheeren From tss@iki.fi Mon Dec 3 01:56:28 2012 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 9858721F844C for ; Mon, 3 Dec 2012 01:56:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUh5KMOoD0cv for ; Mon, 3 Dec 2012 01:56:28 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id F341921F841A for ; Mon, 3 Dec 2012 01:56:27 -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 7B6BB1AE876B; Mon, 3 Dec 2012 11:56:26 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <50BC7278.40104@1und1.de> Date: Mon, 3 Dec 2012 11:56:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08FEB723-D305-4482-A686-935ECA4136EF@iki.fi> References: <20121129162637.28724.48381.idtracker@ietfa.amsl.com> <8305E0CF-DFC8-49E4-B95E-D3E0BB575DE0@iki.fi> <50BC7278.40104@1und1.de> To: Thomas Dressler X-Mailer: Apple Mail (2.1085) Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.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, 03 Dec 2012 09:56:28 -0000 On 3.12.2012, at 11.35, Thomas Dressler wrote: >>> 4.3. RFC 4315, UIDPLUS >>>=20 >>> Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in = response to >>> a UID MOVE command. >> This shouldn't be a MUST, since it adds a restriction not present in = RFC 4315: >>=20 >> [RFC2359] implied that a server must always return = COPYUID/APPENDUID >> data; thus suggesting that in such cases the server should return >> arbitrary data if the destination mailbox did not support = persistent >> UIDs. This document adds the UIDNOTSTICKY response code to = indicate >> that a mailbox does not support persistent UIDs, and stipulates = that >> a UIDPLUS server does not return COPYUID/APPENDUID data when the = COPY >> (or APPEND) destination mailbox has UIDNOTSTICKY status. >>=20 >>=20 >>=20 > also if no mail was moved? >=20 > example: > C: a SELECT a > S: * 1 EXISTS > S: * 1 RECENT > S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) > S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] = Unlimited > S: * OK [UIDNEXT 2] Predicted next UID > S: * OK [UIDVALIDITY 1354526937] UIDs valid > S: a OK [READ-WRITE] SELECT completed > ... someone else remove this one mail. > C: b UID MOVE 1 b > S: * 1 EXPUNGE > S: * 0 EXISTS > S: * 0 RECENT > S: b OK UID MOVE completed >=20 > can we add an complete example with some asynchronus expunged mails? = (one for UID MOVE and one with MOVE). I think the server should return NO [EXPUNGEISSUED] reply in that case = just like it would for COPY (mine does). But yeah, the current move = draft itself allows OK reply as well. From alexey.melnikov@isode.com Mon Dec 3 06:22:15 2012 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 7D43521F86C7 for ; Mon, 3 Dec 2012 06:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hg-H5r-HKMb for ; Mon, 3 Dec 2012 06:22:14 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id BFA0221F8554 for ; Mon, 3 Dec 2012 06:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1354544533; d=isode.com; s=selector; i=@isode.com; bh=xlumeuHQiymlZ//98QVcjD2mVKMV+8uSYdvkjXtSdKw=; 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=KkrY9kJqKYDXsHm3r9SkfyqePuC2TDIC7T+197qDJjr2lBmE1IzN9bC0oxSx8QEZDg67Uj U2VVL3CK96p4VXme16n9NreJWNMK9mVMPOikBH+QCJbe9ed0Pa0WJQiuriZJUtSBSXYeyU 5D8e0Sy8cHccS3BO9vrqG30Bt/wsaRw=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 3 Dec 2012 14:22:13 +0000 Message-ID: <50BBB4C4.6070002@isode.com> Date: Sun, 02 Dec 2012 20:06:28 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen References: <16D79FAD-C79A-401A-947A-2979E5330AEF@iki.fi> <01ON7DHGEQX000008T@mauve.mrochek.com> <510DE073-65F1-4F35-AE1E-E4BE20A13CB0@iki.fi> <01ON7MK7EA9M00008T@mauve.mrochek.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Adrien W. de Croy" , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.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, 03 Dec 2012 14:22:15 -0000 On 30/11/2012 06:54, Timo Sirainen wrote: > On 30.11.2012, at 7.48, Ned Freed wrote: > >>>> RFC 4315 relaxes the COPYUID >>>> requirement, but only to a SHOULD (section 3), and specifies two >>>> exceptions: >>>> >>>> (1) When the mailbox is protected from reads but allows writes (SHOULD NOT >>>> return) >>> Oh, this is actually a good point that I hadn't noticed / thought of before. >>> If mailbox ACLs prevent read access, the COPY command shouldn't expose how many >>> messages it contains or when it gets new messages by sending COPYUID. This >>> would be important for MOVE as well. >> And when you put it that way, it's an information exposure issue that IMO >> requires us to use SHOULD. I'm therefore changing the paragraph to read: >> >> Servers supporting UIDPLUS [RFC4315] SHOULD send COPYUID in response to a UID >> MOVE command. For additional information see Section 3 of [RFC4315]. >> >> Does this address the issue? > Works for me. Looks good to me as well (speaking as a participant). From ned.freed@mrochek.com Mon Dec 3 12:06:13 2012 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 AFB6C21F84C2 for ; Mon, 3 Dec 2012 12:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ52nRqt8CRo for ; Mon, 3 Dec 2012 12:06:13 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 39BB221F87E7 for ; Mon, 3 Dec 2012 12:06:13 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ONCLK8VEM8002P5K@mauve.mrochek.com> for imapext@ietf.org; Mon, 3 Dec 2012 12:01:05 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ONCIHXR6S000008S@mauve.mrochek.com>; Mon, 3 Dec 2012 12:01:01 -0800 (PST) Message-id: <01ONCLK5Q3NU00008S@mauve.mrochek.com> Date: Mon, 03 Dec 2012 11:58:06 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 02 Dec 2012 20:06:28 +0000" <50BBB4C4.6070002@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <16D79FAD-C79A-401A-947A-2979E5330AEF@iki.fi> <01ON7DHGEQX000008T@mauve.mrochek.com> <510DE073-65F1-4F35-AE1E-E4BE20A13CB0@iki.fi> <01ON7MK7EA9M00008T@mauve.mrochek.com> <50BBB4C4.6070002@isode.com> To: Alexey Melnikov Cc: "Adrien W. de Croy" , Timo Sirainen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] I-D Action: draft-ietf-imapmove-command-05.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, 03 Dec 2012 20:06:13 -0000 The last paragraph regarding MODSEQ ended up as: When one or more messages are moved to a target mailbox, if the server is capable of storing modification sequences for the mailbox, the server MUST generate and assign new modification sequence numbers to the moved messages that are higher than the highest modification sequence of the messages originally in the mailbox. I plan on making this change at AUTH48. Ned From iesg-secretary@ietf.org Mon Dec 3 14:19:58 2012 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 A813521F8934; Mon, 3 Dec 2012 14:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kuk1QaoWi+76; Mon, 3 Dec 2012 14:19:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE121F8960; Mon, 3 Dec 2012 14:19:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121203221957.12477.36285.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 14:19:57 -0800 Cc: imapmove chair , imapmove mailing list , RFC Editor Subject: [imapext] Protocol Action: 'Internet Message Access Protocol (IMAP) - MOVE Extension' to Proposed Standard (draft-ietf-imapmove-command-05.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, 03 Dec 2012 22:19:58 -0000 The IESG has approved the following document: - 'Internet Message Access Protocol (IMAP) - MOVE Extension' (draft-ietf-imapmove-command-05.txt) as Proposed Standard This document is the product of the IMAP MOVE extension Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-imapmove-command/ Technical Summary This document defines an IMAP extension to move messages from one mailbox to another. This function (very common in MUA UIs) is not provided by stock IMAP, and clients have to use a combination of UID STORE, UID COPY and EXPUNGE, and cope with partial failures and side effects. The document is targeted to become as Standards Track document, which is appropriate for this type of document. Working Group Summary There was some discussion in the WG about whether MOVE command (as opposed to just UID MOVE) should be defined in the document or not. Consensus was that there was no reason not to define it (this preserves symmetry with other IMAP commands that operate on a group of messages.) There was also a discussion on whether multiple pipelined MOVE commands should be allowed or not. None of these discussions were particularly heated or long lived. Document Quality The document was extensively reviewed by IMAP experts and that is the most important type of review for it. There are multiple implementations of this IMAP extension in both clients and servers. More than 5 different servers implement it already. Personnel Alexey Melnikov is the document shepherd. Barry Leiba is the responsible AD. From barryleiba.mailing.lists@gmail.com Mon Dec 3 15:13:13 2012 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 33C2821F86F3 for ; Mon, 3 Dec 2012 15:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHOPLIn7QRHw for ; Mon, 3 Dec 2012 15:13:12 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27A8921F894B for ; Mon, 3 Dec 2012 15:13:11 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so2129923eek.31 for ; Mon, 03 Dec 2012 15:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=OdxBcKBHpmi8xsiuffzwomoRUY/iKsJtCfQeBXRvMi8=; b=PmZh5l4xPoCDWloGWhyXGMNrwvPsiMFcp9rVrst4NYY0yv/A7DQAHTTmSJWcS82ymn g6jjtQG6b297oLaFuYmrDtVXepeP6TX2RdWPwBApvedDaApnX6H4PzxK2JcdOyKSuXuX Wp5MX7FHUeuxqIilxQ1QzUpAiJcAiEwe93jMKK/pnSI5459bHBhg+ya73+LA6sOMaaOY oyO8dsTyhskeZMeGamkA0+Lf2cQ7ItaTk29PEcV8AplpRVAyBCkqytrFttTvXB41fppe +fS+/OL0ncCDoP/sCjkEtS330TeBpJskdh0XGqp1bu0oYPzPdRBVaQeMMrOoFNejJl5H iHJQ== MIME-Version: 1.0 Received: by 10.14.225.194 with SMTP id z42mr34505148eep.22.1354576390727; Mon, 03 Dec 2012 15:13:10 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.14.100.202 with HTTP; Mon, 3 Dec 2012 15:13:10 -0800 (PST) Date: Mon, 3 Dec 2012 18:13:10 -0500 X-Google-Sender-Auth: kpVahlDRn4zmcY1BitAa_wSNeTk Message-ID: From: Barry Leiba To: "imapext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [imapext] Implementation experience -- final charter item 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, 03 Dec 2012 23:13:13 -0000 The imapmove charter requires an analysis of implementation experience. I know that Alexey has an implementation, and rumour has it that there are several others. There's a wiki page for collecting and saving this: http://trac.tools.ietf.org/wg/imapmove/trac/wiki If you have an implementation of some version of this spec (whether or not it's the latest), please post any information you can about it. Let us know whether you have a server implementation, a client implementation, or both. Let us know what version of the spec you implemented, or whether you have an implementation of the initial idea from before the WG was formed. Let us know what experience you had in implementing it, and any experience you have with deployment. Let us know any interoperability testing you've done. Let us know whether it's in shipping code, beta test, lab test, or whatnot, and when-ish it's likely to be in shipping code if you're able to make an estimate. Please post messages about all this to the mailing list. The chairs can decide how they want to deal with putting it into the wiki. Thanks, Barry From jkt@flaska.net Tue Dec 4 03:34:32 2012 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 3A3DC21F8800 for ; Tue, 4 Dec 2012 03:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCgNMt1JC0zi for ; Tue, 4 Dec 2012 03:34:31 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDF821F87A2 for ; Tue, 4 Dec 2012 03:34:30 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 4BF3A61C22; Tue, 4 Dec 2012 12:34:31 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Tue, 04 Dec 2012 12:34:25 +0100 User-Agent: trojita/v0.3-1553-g3db4e5e; Qt/4.8.3; X11; Linux; MIME-Version: 1.0 Message-ID: <605a2a75-5b22-4ef5-b8d9-607879b30b83@flaska.net> In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] Re: Implementation experience -- final charter item 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, 04 Dec 2012 11:34:32 -0000 On Tuesday, 4 December 2012 00:13:10 CEST, Barry Leiba wrote:=0A> If yo= u have an implementation of some version of this spec (whether or=0A> n= ot it's the latest), please post any information you can about it.=0A> = Let us know whether you have a server implementation, a client=0A> impl= ementation, or both. Let us know what version of the spec you=0A> impl= emented, or whether you have an implementation of the initial idea=0A> = from before the WG was formed. Let us know what experience you had in=0A= > implementing it, and any experience you have with deployment. Let us= =0A> know any interoperability testing you've done. Let us know whethe= r=0A> it's in shipping code, beta test, lab test, or whatnot, and when-= ish=0A> it's likely to be in shipping code if you're able to make an es= timate.=0A=0AMy client (Trojita [1]) has supported the UID XMOVE comman= d as specified by draft-gulbrandsen-imap-move-01 since the end of May i= n a development version (which is actually used by some users); at that= time, I've tested against Bron's fastmail.fm IMAP service (Cyrus). Thi= s functionality was enabled upon seeing the XMOVE capability.=0A=0AI've= just enabled support for the latest version of the draft (the UID MOVE= command; Trojita won't issue seq-based MOVE; now it's based on the MOV= E capability). I've tested against Dovecot's 2.2 from their SCM (hg com= mit 266e24f1c78c). The UID XMOVE is no longer used.=0A=0ATrojita doesn'= t make use of the COPYUID response code at this time; when we add suppo= rt for that, it will work for copies and moves alike. COPYUID won't wor= k when message expunges are reported (VANISHED/EXPUNGED) before COPYUID= arrives -- which is why I welcome the untagged COPYUID variant.=0A=0AT= his code will be shipped in the next release (the ETA is "when it's rea= dy, it's ready" -- but a realistic estimate is later this month or in e= arly January). In absence of the MOVE extension, Trojita falls back to = UID COPY and UID STORE +FLAGS.SILENT and UID EXPUNGE. In absence of the= UIDPLUS extension (and hence no UID EXPUNGE command), no expunges are = performed.=0A=0AWith kind regards,=0AJan=0A=0A[1] http://trojita.flaska= .net/ From tss@iki.fi Mon Dec 10 22:15:08 2012 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 75A0B21F8543 for ; Mon, 10 Dec 2012 22:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wFfsRrJ0YXP for ; Mon, 10 Dec 2012 22:15:06 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id BB44521F84E8 for ; Mon, 10 Dec 2012 22:15:05 -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 CF7821AE87C4 for ; Tue, 11 Dec 2012 08:15:03 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Timo Sirainen In-Reply-To: Date: Tue, 11 Dec 2012 08:15:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F6E0D34-F94E-4ED7-8F4E-17B69078403D@iki.fi> References: To: imapext@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [imapext] Implementation experience -- final charter item 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, 11 Dec 2012 06:15:08 -0000 On 4.12.2012, at 1.13, Barry Leiba wrote: > If you have an implementation of some version of this spec (whether or > not it's the latest), please post any information you can about it. > Let us know whether you have a server implementation, a client > implementation, or both. Let us know what version of the spec you > implemented, or whether you have an implementation of the initial idea > from before the WG was formed. Let us know what experience you had in > implementing it, and any experience you have with deployment. Let us > know any interoperability testing you've done. Let us know whether > it's in shipping code, beta test, lab test, or whatnot, and when-ish > it's likely to be in shipping code if you're able to make an estimate. Dovecot v2.2 implements the latest version of MOVE using mostly the same = code as COPY. Internally most backends implement it as simply = copy+expunge, but there is a "moving" hint flag on the copy context, = which can be used by the backends/plugins. Most importantly quota code = ignores quota limit when it's set and ACL code checks already at copy = stage if user has also expunge-access. Dovecot v2.2 is still in alpha, but I'm hoping to get it stabilized = pretty soon. I've done no interoperability testing, other than heard = that Jan's client works. :) From adrien@qbik.com Tue Dec 11 02:39:25 2012 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 8211721F872C for ; Tue, 11 Dec 2012 02:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.563 X-Spam-Level: X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=-2.564, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3x3qc2LcqW8 for ; Tue, 11 Dec 2012 02:39:25 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id B625921F8578 for ; Tue, 11 Dec 2012 02:39:24 -0800 (PST) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.3.0 (Build 3471)) with SMTP id <0019400364@smtp.qbik.com>; Tue, 11 Dec 2012 23:40:14 +1300 From: "Adrien W. de Croy" To: "Timo Sirainen" , "imapext@ietf.org" Date: Tue, 11 Dec 2012 10:38:55 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <1F6E0D34-F94E-4ED7-8F4E-17B69078403D@iki.fi> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Implementation experience -- final charter item X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 10:39:25 -0000 ------ Original Message ------ From: "Timo Sirainen" >On 4.12.2012, at 1.13, Barry Leiba wrote: > > >> >>If you have an implementation of some version of this spec (whether or >>not it's the latest), please post any information you can about it. >>Let us know whether you have a server implementation, a client >>implementation, or both. Let us know what version of the spec you >>implemented, or whether you have an implementation of the initial idea >>from before the WG was formed. Let us know what experience you had in >>implementing it, and any experience you have with deployment. Let us >>know any interoperability testing you've done. Let us know whether >>it's in shipping code, beta test, lab test, or whatnot, and when-ish >>it's likely to be in shipping code if you're able to make an estimate. >> > > >Dovecot v2.2 implements the latest version of MOVE using mostly the same= code as COPY. Internally most backends implement it as simply copy+expunge= , but there is a "moving" hint flag on the copy context, which can be used= by the backends/plugins. Most importantly quota code ignores quota limit= when it's set and ACL code checks already at copy stage if user has also= expunge-access. > >Dovecot v2.2 is still in alpha, but I'm hoping to get it stabilized pretty= soon. I've done no interoperability testing, other than heard that Jan's= client works. :) > I'd recommend trying with Thunderbird. We've been using an extension named / advertised as "MOVE" with=20 versions of TB for nearly 2 years now. The only difference between the=20 spec they (and we) followed, and the current draft AFAICT relates to an=20 untagged COPYUID instead of the tagged one, and TB to my understanding=20 doesn't use it anyway. When I get around to it I'll change the COPYUID to untagged prior to=20 any EXPUNGE responses. Adrien > > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From slusarz@horde.org Tue Dec 11 12:57:03 2012 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 8F49511E80A6 for ; Tue, 11 Dec 2012 12:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.052 X-Spam-Level: * X-Spam-Status: No, score=1.052 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX1TeX1OA8v7 for ; Tue, 11 Dec 2012 12:57:03 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 1373D11E809B for ; Tue, 11 Dec 2012 12:57:03 -0800 (PST) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta01.emeryville.ca.mail.comcast.net with comcast id aChF1k00C0QkzPwA1Lx2l1; Tue, 11 Dec 2012 20:57:02 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta02.emeryville.ca.mail.comcast.net with comcast id aLx11k00S00qwSn8NLx1F5; Tue, 11 Dec 2012 20:57:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by bigworm.curecanti.org (Postfix) with ESMTP id D424F13034 for ; Tue, 11 Dec 2012 13:57:00 -0700 (MST) Received: from schrute.curecanti.org (schrute.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Tue, 11 Dec 2012 13:57:00 -0700 Date: Tue, 11 Dec 2012 13:57:00 -0700 Message-ID: <20121211135700.Horde.j769-Vvmph6do3D02l3eGQ8@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <1F6E0D34-F94E-4ED7-8F4E-17B69078403D@iki.fi> In-Reply-To: <1F6E0D34-F94E-4ED7-8F4E-17B69078403D@iki.fi> User-Agent: Internet Messaging Program (IMP) H5 (6.0.3-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355259422; bh=6rxZy3Y0StIPH2iyPL6jNInfCW1feqobLrzvAeuZlWg=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=DhRP/iC3CzdZTGuZLy2Z09KygKa2axp+pJOPuHi2queHNnW4FFEp0Tndcqs44Dizo 2DpVD+905DhI9vK4TKWVL8jv/ib/h3CoMpHP8OYhHse/6rn2gMY94eAEObtGCjFrF4 i5d463viLcLrqR+RfLhxttCkpb+03DNKnmpH2v5jDYB7Xd+4vRDAbKu8+c2WbqbI0T H6B2mx1yMOyCJPAOFokyGWSd8q8vBlvZetHBZk0foz2I/pRWgC2gAmy8DnfkPuVApS ziExIFsOpfwx197ACiYfQ+x+Q2qORNuMF1kOji06j1PRURm7Nd71G4dhx6n75gp9+R hlhFkqMnx37MQ== Subject: Re: [imapext] Implementation experience -- final charter item 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, 11 Dec 2012 20:57:03 -0000 Quoting Timo Sirainen : > On 4.12.2012, at 1.13, Barry Leiba wrote: > >> If you have an implementation of some version of this spec (whether or >> not it's the latest), please post any information you can about it. >> Let us know whether you have a server implementation, a client >> implementation, or both. Let us know what version of the spec you >> implemented, or whether you have an implementation of the initial idea >> from before the WG was formed. Let us know what experience you had in >> implementing it, and any experience you have with deployment. Let us >> know any interoperability testing you've done. Let us know whether >> it's in shipping code, beta test, lab test, or whatnot, and when-ish >> it's likely to be in shipping code if you're able to make an estimate. IMP (http://www.horde.org/imp/) supports the latest version of MOVE since November, 2012. This code is in the stable release. The existing move method was altered (only 4 lines changed!) to support MOVE over COPY/STORE/EXPUNGE if available. The recent COPYUID discussion does not affect our implementation - tagged or untagged COPYUID is handled the same. I can confirm the code works fine with Dovecot 2.2. I have also heard (hearsay) that the code works with Cyrus (unknown version). michael ___________________________________ Michael Slusarz [slusarz@horde.org]