70 lines
3.5 KiB
Plaintext
70 lines
3.5 KiB
Plaintext
MBOX-Line: From snowjn at aol.com Wed Jun 16 20:58:45 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: John Snow <snowjn@aol.com>
|
|
Date: Fri Jun 8 12:34:44 2018
|
|
Subject: [Imap-protocol] COPY v. QUOTA
|
|
In-Reply-To: <alpine.BSF.2.00.1006161833050.38002@legolas.orthanc.ca>
|
|
References: <alpine.BSF.2.00.1006161833050.38002@legolas.orthanc.ca>
|
|
Message-ID: <4C199D75.8020502@aol.com>
|
|
|
|
|
|
|
|
Lyndon Nerenberg wrote:
|
|
> 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.
|
|
>
|
|
The quota issue occurs when a client is determined to use a move to
|
|
trash model instead of the designed flag as deleted in place. When that
|
|
user realizes that his mailbox is full, he try to do the right thing and
|
|
finally delete some old mail. The client tries to copy the message to a
|
|
trash folder, but the copy fails because the mailbox is full. Since the
|
|
copy fails, the user is stuck. This is the reason we added XAOL-MOVE.
|
|
Any RTT or database efficiencies we gained were just a bonus.
|
|
|
|
The move in this case would allow the client to do what it's trying to
|
|
do and move the message to the trash folder before Emptying the trash.
|
|
|
|
You're right, no new messages can be deposited until the user deletes
|
|
something.
|
|
|
|
> 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.
|
|
That's true as long as the client deletes the message in place. You
|
|
could bump the quota, but since there's no standard "Trash" folder, how
|
|
would the server know that the folder that the client is copying to is
|
|
the "Trash" folder and to ignore the quota for that copy. Sure you
|
|
could work around this issue with a pipelined copy/store/delete provided
|
|
you could stop between commands when something goes wrong, but why
|
|
process 3 commands when 1 command will do?
|
|
>
|
|
> 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.
|
|
>
|
|
That depends on the product rules of the mail system. Just because you
|
|
could make multiple references to one copy doesn't mean that it's
|
|
accounted for that way.
|
|
> --lyndon
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20100616/0b0e5ff4/attachment.html>
|