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, ------------------------------------------------------------ | Todd Piket | Email: todd at mtu.edu | | Programmer/Analyst | Phone: (906) 487-1720 | | Distributed Computing Services | | | Michigan Technological University | | ------------------------------------------------------------
On Wed, 2006-02-08 at 14:18 -0500, Todd Piket wrote:> 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.There's one problem with this. rename() doesn't work across filesystems, so if you did this it would have to be done by first copying the mail to tmp/, then rename()ing it to cur/ and unlink()ing from new/. That also has the problem that it's not atomic. If Dovecot was the only software reading the maildir, it perhaps wouldn't matter as Dovecot locks the whole maildir while it's synchronizing the mailbox. Also if it got interrupted in the middle and the unlink() wasn't done, the mail would get duplicated (the base filename should be changed while copying to make this problem less worse). Actually you'd need to have two tmp/ directories, one which the delivery agent uses and rename()s the mail into new/, and second which the new/ -> cur/ copying uses. Perhaps the potential duplication-in-error-conditions could also be avoided with some even more maildir standard breaking. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20060208/1f2bde5b/attachment.bin>
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/%u which 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.