Chuck,
I want to start off by thanking you for attempting to assist me,
but I'm afraid I'm going to have to disagree with you on a few points
here. Quota systems may not have been intended for mail just like mail
systems were never intended for spammers, but things evolve over time and
requirements change. I don't know of any ISPs that don't use a quota
system to enforce email limits, it's now a necessity.
There are other popper programs that have quota systems built in just for
this reason. In qpopper 3.x if the write to /var/mail failed, the mail
simply got left in the temp directory. Still a problem but it didn't lead
to corrupted mailboxes which require a sysadmin to fix instead of a first
tier support rep. It seems to me that qpopper should be able to play
nicely in the types of environments it will run in.
Obviously there is no way for qpopper to know what the quota is if any
until it hits that quota. This could easily be accomplished by copying the
.user.pop file back to the spool directory under a different filename,
then once successful it could rename the file.
The solution that occured to me is that qpopper could keep the user's
mailspool locked during the entire process so that no new mail could be
delivered while the user is downloading mail. Although I haven't read the
rfc from front to back, I did get some indication that this was considered
legal.
The bottom line is that I need a pop server that plays nicely with quotas,
corrupted mailboxes cause too many support issues. Customers get upset
even though they created their own problem by turning on options they
don't understand (leave mail on server). It would be nice to see a built
in quota feature, or a locking option in a future release of qpopper that
would solve this problem.
Writing scripts to police mailboxes might be a nice warning feature for
our customers (something I considered) but it's not a solution for corrupt
mailboxes. If qpopper can't write the file out to a filesystem, it should
leave the file behind in the temp drop. Corrupting files is not what I
would consider "failing gracefully".
Thanks again for your help.
Regards,
Chris
On Thu, 6 Mar 2003, Chuck Yerkes wrote:
> System quotae were intended to keep users from storing too
> much on the machines in their HOME DIRECTORIES.
>
> That was the intent of quota systems.
>
> So we can use it as a hack to limit mailboxes size. But recall
> that it's a hack, so we have to work around some of the quota intent
> of offering a hard ceiling. Users don't duplicate their home
> directories a lot.
>
> The Right Answer is not to (mis)use the system quotae, but rather,
> put the checking in the delivery agent and let it use the soft
> quota as an advisory - you could get the info from LDAP if you
> wanted. But it's work on your part, at this moment.
>
> Quoting Alan Brown ([EMAIL PROTECTED]):
> > On Thu, 6 Mar 2003, Chuck Yerkes wrote:
> >
> > > However, using the disk system to enforce mail quota's is inherently
> > > a hack, given that there will be, for a moment, two spools.
> >
> > The only way around system quotas is to have the files in 2 different
> > partitions, but that is a _huge_ performance hit.
> >
> > Server mode makes user.pop handling a lot safer, but you need to ensure
> > that there is no direct access to the spool (eg, pine or mail) (Pine can
> > be configured to use pop in /etc/pine.conf or /etc/pine.conf.fixed), or
> > the direct access program.
> >
> > As Chuck says, pop is not designed for a lot of this high-end stuff.
> >
> > AB
> >
>
