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?

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.

- 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

Reply via email to