> Date: Wed, 10 Oct 2001 08:25:35 -0400 > From: Steve Perrault <[EMAIL PROTECTED]> > > My concern is what occurs when a user is at quota. How does Qpopper > make room to add the X-UIDL lines if the person is already at quota?
What happens is that qpopper does not have to worry about the quota since the underlying file system does the worrying. What happens is that the file does not get modified and written back because the user is out of space (over quota). I would submit that this is not a Good Way (tm) to do business. I submit that users should have a high limit (with notification sent at the time the user goes over this quota saying something like "you are over limit. Unless you go below x MB/GB/whatever in (x period of time), you will be locked out.) The user should also have a 'no-more-write' limit at say, 2x the high limit. And finally, the user have a hard "you shall not exceed this limit" quota at say, 2.5x high limit: At "high limit" (soft quota), the user gets a warning message and the clock starts ticking towards end of grace period. at 2x high limit - no more writes to disk. at hard high limit - no more logins until they talk to some systems person and get their disk area cleaned up. My thoughts. Your own may vary. > Also, has anyone implemented an expire mechanism to Qpopper? As in > "delete all messages older than x days, and delete all read messages > older than y days". Admittedly, it would only affect people who > actually CHECK their email, but it would be cleaner than my Perl code > to do the same thing. This is most normally a function of the client side MUA. As for the answer, there was some discussion on this a short while ago (say a month-6weeks ago). There were several solutions proposed but nothing emerged as the clear winner. There was 'preenmail' (I was most interested in this so grabbed a copy) and some others. Regards, Gregory Hicks > > - SteveP > > > > > Hi there, > > > > > > After failing to find anything about this subject in the list > > > archives for the past few months I thought I would ask the > > > list. > > > > > > One of my POP servers has e-mail for various users delivered to > > > and collected from /var/spool/mail/whoever. I have a need to > > > implement maximum mailbox size restrictions on the various mailboxes. > > > First I looked at my mail server, but that's just the transfer agent > > > and as such I don't think it should deal with quotas. > >... > > > > > > When I was reviewing it a month or two ago, I found a surprising > >scarcity of web information on setting up mail quotas; you'd think > >everyone would want to do it, but there's not much information out > >there, at least not that I could find in Google. I wanted to do it via > >file-system (kernel-level) quotas, but had to make sure that all > >components of the mail system would handle it well. > > > > There actually is one important Qpopper related fact for implementing > >mail quotas: > > > > > > If you implement quotas at the file system level, you want to > >configure Qpopper so the temporary pop-drop files are on a different > >partition from your mail spools, without user quotas. Otherwise, once > >a user hits their quota, they will be unable to pop their mail to > >reduce their mailbox below quota. > > > > > > That aside, quota enforcement is the work of the local mail delivery > >agent; that may be either your MTA, or delegated by the MTA to some > >other program. We use procmail for local mail delivery, and our > >testing showed that it was very quota-aware, and able to communicate > >over-quota conditions back to the MTA which invoked it. After a little > >tweaking on how our MTA reported these erorrs, I enabled and set user > >quotas on our mail spool partition two weeks ago, and have not had any > >problems with it so far. If users are near quota, any new mail coming > >in which would put them over-quota gets bounced back to the sender > >instead of being delivered. > > > > > > -- Clifton > --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: [EMAIL PROTECTED] "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
