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. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
