Best solution for mail server?

[Tim]

Tim:
>> In my rc.local files I have lines like the following (below).  And each
>> user has their ~/.fetchmailrc file set for whatever servers their
>> accounts will poll.
>> 
>> su tim -c "/usr/bin/fetchmail -d 900"
>> su john -c "/usr/bin/fetchmail -d 1200"
>> su jane -c "/usr/bin/fetchmail -d 1500"
>> 
>> I picked different polling periods so that mail runs will not run at the
>> same time as each other (spreading the workload around).  Any user can
>> stop their own automatic poll, and restart it, if they want to.

Bill Davidsen:
> Why would you not just have a single cron job which runs fetchmail 
> without the -d? I used to just kick off the "poll all" script every 12
> minutes.
> 
> Ideally you would have all mail for all of your users put to a single 
> mail account, poll that, and let local mail delivery hand it out. 
> Clearly that takes cooperation from the server you're polling. 

One of those, things that progressed, and just stayed at the last way it
was set up, since it seems to work quite well...

It started out with individual users just running their own fetchmail
daemons, with their own configuration files.  This drags their mail into
their mail spool file, and they can use their own clients as they see
fit (we have a local mail server, so any client on the network can do
mail from any terminal).  They can also configure their fetchmail
daemons as they see fit, on their homespace on the server.  The last bit
being one thing that'd be more work to do with a centrally managed
polling system, and wouldn't be appreciated by anyone who didn't like
telling someone else their passwords.

Then, later on, I put a few lines in the rc.local file to automatically
restart the daemons if there's a system reboot.

Some of the fetchmail configurations polled umpteem external servers,
each.  So, every few minutes the dial-up internet connection could get
swamped by the traffic (broadband came much later).  Thanks to that
network drag, I decided to have the polling staggered a bit.  Mail
polling and something like doing a "yum update" simultaneously was
really painful.

I haven't really looked at at doing it via a CRON job, so I don't know
whether this sort of thing would be easy to do that way, too.  With this
system, if fetchmail is idly waiting for the next poll, and the user
needs to check mail urgently, they can type the fetchmail command, it
does a poll immediately, then goes back to auto polling.  If the user
asks to it do a poll while it's already doing one, it seems to handle
that fine, too.  I haven't done any testing to see if it only handles
that while in daemon mode, or will also handle the user running it
twice, while not in daemon mode.

The next step, which I've never got around to organising, is IMAP folder
filtering on the server (dovecot).  Evolution is incredibly painfully
slow at doing filtering, Thunderbird may be faster but I can't stand how
it re-interprets *all* mail into psuedo-HTML, and other mails I've tried
have been hideous for other reasons.

I don't bother about spam filtering.  I get about five a day, compared
against a hundred, or so, real e-mails.  It's not worth the effort
trying to automate it.  Dealing with false positives and negatives would
be more effort than just pressing delete.

-- 
(This computer runs FC7, my others run FC4, FC5 & FC6, in case that's
 important to the thread.)

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.