mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

[Imap-protocol] Expunges and copying

E-mail headers
From: Timo Sirainen <tss@iki.fi>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 1236195778.8159.156.camel@timo-desktop permalink / raw / eml / mbox 
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..
-------------- 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/80491d85/attachment.sig>
Reply
E-mail headers
From: markrcrispin@panda.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: alpine.OSX.2.00.0903041151330.8004@hsinghsing.panda.com permalink / raw / eml / mbox 
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.
Reply
E-mail headers
From: tss@iki.fi
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: 1236197047.8159.163.camel@timo-desktop permalink / raw / eml / mbox 
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>
Reply
E-mail headers
From: markrcrispin@panda.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:42 -0000
Message-ID: alpine.OSX.2.00.0903041255150.8004@hsinghsing.panda.com permalink / raw / eml / mbox 
On Wed, 4 Mar 2009, Timo Sirainen wrote:
> Previously we've been talking mainly about FETCH, not COPY. I think
> there's some kind of a difference between them.

I don't.

> 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.

Interesting.  This is a case where a client needs to disregard unknown 
UIDs just as a server must.

-- 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.
Reply