Hi Rob, Thanks for replying, you folks at Carnegie Mellon have created a fantastic tool and we certainly appreciate your work and dedication.
Rob Siemborski wrote: > On Fri, 20 Jun 2003, John Wade wrote: > > > I was thinking about this yesterday as I worked with our help desk folks > > to mollify another angry user who could not figure out how to manage > > their mailbox and ended up over quota. While I agree with the design > > of Cyrus in principle (delete in place and expunge), in practice, there > > are enough mail clients that use the "move to trash" model and an > > expectation in the user community that this is how computers work (based > > on the delete model in both the Windows and Macintosh worlds) that I > > think I need to figure out a way to accomodate them. > > There are ways to implement a trash folder within the delete/expunge > model. (Through a virtual folder, for example). This is much better for > interoperability between clients, and has been discussed to death on IETF > lists. > Sounds appealing as a future direction. > > > When we upgrade our Cyrus version to 2.1.x or 2.2 later this summer, > > (curently on 2.0.16) I was planning to see if I could put a patch > > together to have COPY not enforce quotas. Or maybe for the really > > paranoid, not enforce quotas if the destination mailbox is > > user.<username>.Trash ) This would seem to solve most of the "move > > to trash" delete quota problems. While I could see ways that this could > > lead to abuse of the mail server, I think for the vast majority of > > users, the shutdown of delivery of new messages woul be sufficient > > incentive to fix the over quota status and the risk of abuse is > > relatively small/ > > Since the IMAP Server has no concept of a trash mailbox, this doesn't make > any sense. > After thinking about this further, I would not special case the Trash mailbox, I would simply remove the requirement that a COPY command check the quota before copying a message from one mailbox to another. The quota check would still occur on deliver or on append, just not on copy. This means that no new messages can enter the inbox from the client or MTA. The only danger is from messages copied from a mailbox with a different quota root, but the users will continue to receive over quota alerts and no new message until they go back under quota. > > > Does anyone have any thoughts on this idea? Is this a really bad idea? > > Yes. Point taken :-) > > > > Any tips on where in the code to look? I spent a few minutes looking at > > imapd.c, index.c and append.c in 2.0.16 and I am guessing that if I > > change the quotacheck argument to -1 in the append_setup call in > > index_copy it will bypass the quota check on copy. Have not actually > > tried this yet. > > I suspect a simple implementation that just does this will break the quota > subsystem. (You also need to be sure to not affect quota roots when you > expunge the trash folder, etc) > I just tried this fix in 2.0.16 and it appears to work properly. The "ignore quota" option is already in place on append_setup to allow the lmtpd to deliver to overquota mailboxes, I am just extending this to work with imapd copy command execution. None of this interferes with the recording of quotas when the message is actually copied. The behavior I see with the patch in place is that when I first login to an overquota mailbox, the client receives the "Over Quota" IMAP alert. (I modified the error message to suggest that the user delete messages and/or empty the trash.) The client can still copy files from one mailbox to another, including moving to trash and then trigger a delete/expunge to empty the trash. The client can not copy messages from the local mail to the imap server or append new messages into a Sent folder. Mail delivery is deferred in the MTA until the overquota condition is rectified. > If you really care about trying to support this sort of behavior, why not > set a separate quotaroot on user.foo.trash? This doesn't require the > server to have special handling of random user mailboxes, and has less > questions from a server implementation perspective. This was my first thought a year ago and I played with it extensively. ( I hate to hack a beautiful system like Cyrus without good reason) The problem with the separate quota root on the trash mailbox is that many novice users don't know about the need to empty (delete/expunge) the Trash mailbox. As a result, they are happily moving messages to trash and then they start getting a quota warning message from the Trash mailbox. Since the IMAP alert does not specify the mailbox that the quota warning applies to, the user assumes that it is the inbox and continues to try and delete messages until they go over quota on trash, at that point, they call the help desk since they can no longer delete messages. No real gain in user satisfaction although experienced users may try to empty the trash and thus resolve the problem on their own. I don't think my fix should be a standard part of Cyrus, but for those of us who want to support clients with move to trash biases, it seems like it could be a helpful patch. I don't really see the downside for us except the vulnerabilty to malicious users copying messages from other mailboxes outside of their own quota root to use up all of our disk space. Thanks, John