On Wed, Feb 08, 2006 at 02:18:06PM -0500, Todd Piket wrote:
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?
Why do you do this? What would be the problem with something like
default_mail_env = maildir:~/Maildir:INBOX=/var/spool/mail/%uwhich if I've understood correctly means that the user's stored mail is in his home directory Maildir, while new mail is delivered into /var/spool/mail/%u.
I've never had reason to try this, but these are obviously on different filesystems, and it seems to me as if it would be functionally equivalent to having Maildir/new on a different file system.
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?
See Timo's response.
In a more general way, how do you deal with people keeping all their mail in the INBOX? Is it only that it's annoying to have your mail marked "new"?
HTH.