MBOX-Line: From tss at iki.fi  Wed Mar  4 12:04:07 2009
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:42 2018
Subject: [Imap-protocol] Expunges and copying
In-Reply-To: <alpine.OSX.2.00.0903041151330.8004@hsinghsing.panda.com>
References: <1236195778.8159.156.camel@timo-desktop>
	<alpine.OSX.2.00.0903041151330.8004@hsinghsing.panda.com>
Message-ID: <1236197047.8159.163.camel@timo-desktop>

Previously we've been talking mainly about FETCH, not COPY. I think
there's some kind of a difference between them. One thing I just thought
of was with UIDPLUS, it could return:

1 COPY 1 elsewhere
* 1 EXPUNGE
1 OK [COPYUID 1234567890 1 43]

So the COPYUID refers to UID 1 which was already expunged. I suppose
that's not necessarily a problem, but perhaps it could confuse/break
clients that dropped all knowledge of the UID 1 message when receiving
EXPUNGE.

BTW. The reason I'm thinking about this is because I'm finally
implementing a mailbox format where this would be allowed unless I
prevent it explicitly.

On Wed, 2009-03-04 at 11:54 -0800, Mark Crispin wrote:
> I think that this is allowed, and that a server that does not implement it 
> correctly by copying the message is broken.
> 
> I have said many times that I do not agree with RFC 2180 sections 4.1.2 
> and 4.1.3.  This is an excellent example of why.
> 
> On Wed, 4 Mar 2009, Timo Sirainen wrote:
> > What do you think, should this be allowed:
> >
> > Sessions 1 and 2 have selected a mailbox and have an identical view of
> > it. Then:
> >
> > C1: 1 EXPUNGE
> > S1: * 1 EXPUNGE
> > S1: 1 OK
> >
> > C2: 2 COPY 1 elsewhere
> > S2: * 1 EXPUNGE
> > S2: 2 OK
> >
> > i.e. the second session can copy a message that was already expunged in
> > the first session? I guess this isn't all that much different from being
> > able to FETCH the message, but somehow it feels to me like allowing COPY
> > could be bad..
> 
> -- Mark --
> 
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20090304/1b6a8636/attachment.sig>
