I already wrote to Timo, but I thought some others on this list may have had a similar situation. So here goes:
The scenario at Michigan Technological University stems from long standing traditions and policies that probably won't change. That said, two of the policies are 1.)we don't bounce mail and 2.)we guarantee delivery when we accept a piece of mail. The UW IMAP "snarf" capability was nice because it allowed us to introduce file system, per user quotas w/o worrying about the "INBOX" in an over quota situation. This is because the user could still read mail. The delivered mail would get "snarfed" from /var/mail/user when the user went back under quota.
In our test cases with switching to Maildir with Dovecot, we deliver directly to the user's INBOX instead of /var/mail/user so what do we do when the user is over quota because we can't bounce the mail?
After many lengthy discussions our thought was this. Could we symbolically link the user's "Maildir/new" to a non-quota file system such that the move from "new" to "cur" would fail if the user is over quota? What will Dovecot do in that failure situation? Do you have other suggestions? I would be more than willing to develop a patch that makes this an option in the config file. Probably similar to allowing the indexes and control files be on a non-quota file system. Again, it would only allow "Maildir/new" to be on a separate file system, not the whole "INBOX". I hope this conveys the idea well enough.
Any thoughts or ideas the list provides would be greatly appreciated.
-- Regards,