Thank you Timo and Lorens for your quick responses. Timo, I thought as much in regards to the rename()s, but I was hoping.
Lorens, the INBOX in /var/spool/mail/%u would keep the INBOX on a non-quota file system. This means Dovecot reads the user's INBOX from /var/spool/mail/%u which is not what we want. We want the INBOX to be in the home directory. Users could leave mail in /var/spool/mail/%u and it would never go over quota. That is, obviously, not what we want. We need to never bounce mail yet deliver the mail that has built up for an over quota user as quickly as we can once that user goes below quota. If Dovecot moved the mail from /var/spool/mail/%u to the user's homedir then that is exactly what I want. As long as it fails gracefully if the user is over quota.
Other reasons keep us from creating separate mail queues and attempting to redeliver at intervals. Mainly, volume of mail.
Regards,
| Todd Piket | Email: todd@mtu.edu | | Programmer/Analyst | Phone: (906) 487-1720 | | Distributed Computing Services | | | Michigan Technological University | |
Lorens wrote:
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.