Hi Clifton

Thanks for your reply which was most informative and set us here thinking.

The main query was did your approach of copying temporary pop-drop files to 
a different partition (and back) slow the process down at all ?  Currently 
our pop-drops reside in the users' home directory the same as their Mailbox 
you see.

Best regards

Peter


At 10:24 09/10/01 -1000, Clifton Royston wrote:
>On Tue, Oct 09, 2001 at 02:28:19PM +0100, Sean Kelly wrote:
> > 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
>
>--
>  Clifton Royston  --  LavaNet Systems Architect --  [EMAIL PROTECTED]
>    WWJD?   "JWRTFM!" - Scott Dorsey (kludge)   "JWG" - Eddie Aikau


Reply via email to