34 lines
1.6 KiB
Plaintext
34 lines
1.6 KiB
Plaintext
MBOX-Line: From lyndon at orthanc.ca Wed Jun 16 18:51:10 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: Lyndon Nerenberg <lyndon@orthanc.ca>
|
|
Date: Fri Jun 8 12:34:44 2018
|
|
Subject: [Imap-protocol] COPY v. QUOTA
|
|
Message-ID: <alpine.BSF.2.00.1006161833050.38002@legolas.orthanc.ca>
|
|
|
|
I seem to recall the expressed motivation for MOVE was to work around
|
|
failure of COPY when the target mailbox was at its quota limit. What I
|
|
can't figure out is how this is useful in the real world. Presumably it
|
|
only serves a purpose when the source and destination mailboxes are under
|
|
the same QUOTAROOT. So while MOVE allows messages to be shuffled amongst
|
|
folders under that root, it doesn't allow the introduction of new
|
|
messages.
|
|
|
|
I'm finding it very difficult to believe that this is such a common
|
|
scenario that it warrants an extension to the protocol. Especially when
|
|
the workaround is as simple as deleting a couple of messages, or bumping
|
|
the quota up a bit. And once you've hit the limit you are going to have to
|
|
do one or both of the above to carry on anyway.
|
|
|
|
Furthermore, the more I look at this the harder I'm finding it to imagine
|
|
a reasonable server implementation capable of implementing MOVE that could
|
|
not also provide a COPY operation that would not increase the quota usage
|
|
for the QUOTAROOT for a COPY operation within that root. Note that I said
|
|
"reasonable." Anyone can come up with examples of intractable environments
|
|
where it can't be done, but I don't consider someone's insistence on, say,
|
|
implementing their store on a FAT filesystem as justification for a
|
|
protocol workaround for a bad engineering decision.
|
|
|
|
--lyndon
|
|
|
|
|