On Thu, 22 Apr 2010, Yiorgos Adamopoulos wrote:
I've been using tmail_quota() in order to set a maximum size for the INBOX with no problems. Thank you for providing the hook Mark! Now where should I dive into and use a similar function if I want to set a maximum size for other folders too?
This is a much more difficult problem. tmail is a consumer of the c-client append routines, used specifically for mail delivery. To review the status quo: The c-client append routines attempt to handle kernel-enforced hard quotas by catching an append-write exception and rolling back the mailbox to its previous state. In some cases, c-client calculates the size needed, and appends a sufficient amount of NULs to the file so that it occupies that space. If that gets an exception, it truncates the file back to its size prior to the NULs. Otherwise, it assumes that all is well and does the real write. Sadly, this doesn't always work. Certain systems, including that from a recently-deceased major UNIX workstation vendor (one that I regularly criticized and complained about here), keep the over-quota error status "hot" even after the truncation. This stymies c-client's effort to roll back; and c-client gets quite dismayed at finding that it is forbidden to overwrite space on the disk that it already occupies (as opposed to being forbidden from occupying more). So, most people have learned not to rely upon hard quotas except as a last-ditch measure against abuse. Hitting a hard quota leads to corrupted mailboxes when c-client is unable to undo things due to the issue in the previous paragraph (it's one thing to say "don't box yourself into a corner"; it's quite enough to spring a trap that closes the exit...). tmail's tmail_quota() hook, and the associated hook in dmail, offers a way to query a policy module from mail delivery. Note that this is specific to mail delivery, not INBOX. tmail_quota() sits on top of the c-client append reoutines within tmail; it does not in any way alter the behavior of any other consumer of c-client. The idea here is that rather than using some hard disk quota number, your policy enforcement is of the form "given such-and-such mailbox with such-and-such messages totaling such-and-such bytes, is it alright to add a message of X bytes" rather than "is it alright to add X+Y bytes, where X is the size of the message and Y is the overhead space for that form, to an existing mailbox of N+M bytes where N is the size of all the messages and M is the overhead space". Hard quotas do the latter; you really want the former. So, there's your problem. One way is to create a similar task to the tmail_quota() hook for the other consumers to c-client that you care about; at a minimum, imapd (ipop3d does not matter). If you have a server on which imapd and ipop3d are the only c-client consumers, this may be your best best. What you need to do is to insert some sort of policy hook akin to tmail_quota() before mail_copy() and mail_append() are called. On the other hand, if you have lots of direct consumers of c-client (e.g., Pine and Alpine doing local access) then you need to go into the c-client library itself. Again, modifying mail_copy() and mail_append() based upon gross policy (as I discussed above) is probably better than having to dig into each driver to include overhead in the enforcement. It's a non-trivial task in any case. I hope that it's just a matter of imapd hacking for you. Good luck! -- 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-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
