MBOX-Line: From brendan at kublai.com  Wed Sep  9 23:08:46 2020
To: imap-protocol@u.washington.edu
From: Brendan Cully <brendan@kublai.com>
Date: Wed Sep  9 23:09:03 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
 messages?
In-Reply-To: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
Message-ID: <20200910060846.GA32325@3c22fbbbbb47.ant.amazon.com>

I also use COPY to COPY and would be upset if the messages in my
source folder disappeared withou my asking them to :)

I think you'd be better off implementing https://tools.ietf.org/html/rfc6851
even though it relies on clients to notice and use the implementation.

On Wednesday, 09 September 2020 at 10:27, Andris Reinman wrote:
> Hi,
> 
> As the subject states, is there actually any valid use case these days for
> COPY to just copy messages instead of being a poor substitute for MOVE
> (that is COPY+EXPUNGE)?
> 
> If an IMAP server would mark COPYied messages with \Delete and
> expunge these immediately after a message has been copied, would it break
> any real-use expectations?
> 
> Why I'm asking is that I'm building a database backed email server (
> https://wildduck.email), we have a moderately sized cluster of emails
> (100k+ users, ~50TB+ of data, few hundred million emails) and when an IMAP
> client tries to copy all messages from one large folder to another then
> copying takes a lot of time (eg 'COPY 1:* target' where * is 10 000) as
> listing the database entries and copying these around takes time. And as
> there is no response until messages have been fully copied the client might
> think that TCP connection has been lost and retries the same action, ending
> up doing multiple COPY calls.
> 
> So I was wondering if we could simply delete the already copied message
> from the source folder, as most probably the client would do it anyway once
> COPY is fully completed. Basically COPY would be an alias for MOVE.
> Obviously non-standard behavior but would we actually break something
> client side by doing this?
> 
> Regards,
> Andris Reinman
> https://wildduck.email

> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

