* On 2005.09.26, in <[EMAIL PROTECTED]>, * "Daniel Senie" <[EMAIL PROTECTED]> wrote: > > Ultimately, I really don't want to use the file system quota > mechanism to deal with limiting users' mailbox sizes. Perhaps quotas > work for you (other than the obvious qpopper question you asked > about) but they seem like the wrong tool for the job.
That was our conclusion. We ran sendmail, and had a script which nightly ran through all users' mailboxes (both the shared IMAP/POP/NFS inbox and the IMAP folder hierarchy). We had a colon-delimited file listing people's quotas, with a special entry for the default quota. Another CDF listed people who were known to be over quota already, and indicated how many days they had until quota was enforced. Any time the script found someone to be over quota, it looked in the second CDF. If the user was found, then their day cound would be decremented. If not, they'd be added with the maximum number of days. Once a user hit zero days, the script formulated an entry for sendmail's access file blocking new delivery. I believe these were stored in a separate file, and a Makefile in /etc/mail compiled all our various access files into a single access map. It wasn't hard to put together, really. Unfortunately we don't still run this, so I can only describe it. It worked pretty well, but we gave it up when we saw the light of the Mail God and purchased an enterprise tur[n]key mail solution which solves all our problems in less time, with less labor, and at lower expense -- except when it doesn't, which is most of the time. If I had it to do again I think I'd make it a constantly-running process. Rather than running nightly, it would run again as soon as it finished a cycle. Instead of storing quota days in the CDF, it would mark timestamps that a user was first and most recently observed to be over quota, and a separate script would periodically (more often than daily) update /etc/mail/access from the difference between those timestamps. -- -D. [EMAIL PROTECTED] NSIT University of Chicago
