Off list, as it covers things in a later reply which you may not have
seen.  By all means include the list in reply if you wish.

On Thu, 9 Mar 2006, Randall Gellens wrote:

> At 3:21 PM +0000 3/9/06, Hugh Sasse wrote:
> 
> >  Enabling server mode is not possible given some types of client (from
> >  my reading of the docs).  I don't know all the clients people use, so
> >  I must err on the side of caution.  Or is that paranoid in 2006?
> > 
> >  Caching requires server mode....
> 
> Server mode (and caching) should be fine as long as people access their mail
> using any POP client.
> 
> If you have any users who have shell accounts, and access their mail directly,
> disable server mode for those users.  You can enable and disable server mode
> on a per-user and/or per-group basis.

Per-user would suit us most...
> 
> You might also want to think about using the fast-io option, which renames the
> temp-drop to the spool instead of copying it.  This only works if the temp
> drop and spool are on the same filesystem.

That's the default, isn't it?  See my later mail because I ask how
these things interact.  For example, I'm not clear if there are
commands which can be set globally but not on a per user basis,
whether global commands which depend on qpopper being in server mode
will just be switched off for those users not in server mode, or if
that would be anomalous, and would generate an error. Caching can 
be set with a global option, but if only some users get server mode, 
do the others feel like it is off?

> 
> You might also want to think about setting update-status-headers to false.
> This is a trickier option, because some clients use the 'Status:' header, and
> some don't.  It also trades I/O for CPU.

We have lots of users and I don't know who uses what when.  They are
scattered over the site and it's hard to pin down, and I don't need the
flak of breaking anything... :-)  I think I'd best leave that one alone
for now.
> 
> See the Performance section of the GUIDE, and also the descriptions of the
> options.

Yes, I've read those, and believe I understand them in isolation.
> 
> One thing I've been trying to find time to do is take caching to the next
> step, which is maintaining the cache when new mail has arrived since the last
> mail check.  That would make a big difference when users leave mail on the
> server.
> 
> There are scripts that have been posted in the past that let you cull old
> mail.  Something else to think about.

It's the political consequences of inflicting that on senior academics
that is tricky :-).

        Thank you,
        Hugh

Reply via email to