• On 2003.03.26, in 1048697679.31484.40.camel@rocket,
• "Mike Machado" mike@innercite.com wrote:

I have seen this suggestion elsewhere and would be perfect. The customer only needs a few extra kilobytes when their quota is full, so the hard quota could be just a bit bigger with a long/unlimited grace. The hard part is to get procmail or whatever local delivery agent to stop at the SOFT quota. I could probably quite some funky procmail rules, but that will add an unwanted amount of load to an already busy system. Anyone know if their are some built in sendmail/procmail checking that can aide here?

None that I know of. Hard quotas are terrible for a mail system, in my experience. Part of the trouble is the automation -- we run across a lot of cases where automated management isn't very nice to users. There are always exceptions -- Professor Jones is doing field research in Egypt, or somesuch, and has limited access. For such cases, we want longer quota warning periods.

We have a nightly job that checks everyone's mail usage nightly. If someone's usage goes above what we consider good, it decrements a counter, set initially to 7 days (5 working days). Each day that this counter is set, it mails the user a warning that mail will be blocked in N days, and when a counter reaches 0 it mails us, the admins, and we run a script to block access. Part of this is sticking a helpful entry in /etc/mail/access to block incoming mail. (We use sendmail.) So that's where you can cause SMTP blocks, but you need your own scripts for managing it.

There are two loopholes here -- people can still store as much mail as they want to the server via IMAP, and people can neglect their overuse for as long as they want to. Those might be weaknesses or advantages, depending on how you look at it. But most people want new mail via SMTP, too, and they don't get it until they clear their IMAP. But since we have so many users, the relatively small number of troublesome users never cause major trouble -- their abuses are relatively small. IOW, we don't generally need to keep individuals reined in, just the masses.

-- -D. dgc@uchicago.edu NSIT University of Chicago "The whole thrust of the text adventure was one picture was worth a thousand words and we would rather give you the thousand words." - Dave Lebling, Implementor

On Wed, Mar 26, 2003 at 10:29:03AM +0200, Timo Sirainen wrote:

On Wed, 2003-03-26 at 01:48, Mike Machado wrote:

...

Mar 25 14:54:27 penguin1 imap(bob): file_set_size() failed with index data file /home/bob/mail/.imap/INBOX/.imap.index.data: Disk quota exceededMar 25 14:54:27 penguin1 imap(bob): mmap_istream.madvise(): Function not implemented Mar 25 14:54:28 penguin1 last message repeated 65 times

Oh, write() returns EDQUOT instead of ENOSPC when quota is full? Didn't know that before. I'll fix it so that they're both checked. After that Dovecot will just use memory instead if it can't create the index files.

That would be great. (Suffering from the same issue here.)

mm