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>