> * On 2003.03.12, in <[EMAIL PROTECTED]>,
> * "Simon Byrnand" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> But we have these few recalcitrant users who don't seem to know that
>>>>>> "Keep Messages On The Server" is bad. Really Bad. Especially when
>>>>>> these few people have mail spool files that are over 50 Mbytes in size.
>>>>>> Some of them even closer to 100 Mbytes (or over).
>
> Forgive me for jumping into the middle of a discussion here without
> reading all the background. I just joined the list, and had planned to
> wait and get cozy before posting, but what I wanted to post about is
> immediately relevant to this issue.
>
>>>>> IMHO users do this not because they're trying to be butt-heads, but
>>>>> because they're trying to get work done. If their mail is sitting on
>>>>> their desktop at work, they can't access it on the road. etc.
>>>>
>>>> The small group of recalcitrants is made up of a couple of people that
>>>> might fit that category, but the others are just lazy non-mobile
>>>> astronomers :-)
>
> That's what we've found, too, on both counts. A lot of our users have
> legitimate needs for leaving mail on the server, so we don't want to
> turn it off -- but some of those, and a lot of the others, are just
> oblivious or obstinate.
>
>>> I see the same problem from time to time - on a PIII-800. A user accessing
>>> a spool file >50MB causes IO starvation while the copying is going on and
>>> the load average shoots up, making the machine quite sluggish. If you find
>>> a solution I'd be interested to know what it is....
>>
>> Just looking at the possibility of using "server mode" for qpopper to solve
>
> We've enabled server mode, but it had limited effect -- there's still
> a maildrop copy for each connect. To solve the trouble for the longer
> term, and in a flexible way, we went another route: we've patched
> qpopper to implement a kind of rate limiting on heavy users.
>
> In essence, what we're now able to do is to enforce a certain delay
> between POP checks, and to make the length of this delay variable per
> user, dependent on how much mail is in their inbox. We can adjust the
> aggressiveness of this penalty on the fly, since it can be tuned in the
> popper.conf or on the command line. When we have strange server trouble
> we sometimes ratchet it up a little. This lets us continue providing
> service, just on a reduced schedule, while we find and implement other
> ways of improving performance.
>
> I've written up a web page describing the patch and the associated
> query/reset tool. Please feel free to download and have a look. This is
> not supported by the Univerity of Chicago, of course, but we've been
> using it on our central e-mail server for about 10 months, without
> revision, and without regret.
>
> http://home.uchicago.edu/~dgc/sw/qpopper/
Happymail sounds great.
Any chance of upgrading this patch to the latest Qpopper 4.0.5 release?
> The biggest social cost to us was that the POP authentication failure
> caused Eudora to forget people's passwords, but since we encourage users
> not to make Eudora remember their passwords anyway, that was a failure
> we could easily live with.
Can you explain this a little more? I'm not sure I've run into anything
similar to this phenomenon ...
- Greg
