I hoping this is an RTFM ... and somebody can point me at the correct
'FM' :-)
I've just spent a while setting my new Debian , allways-on box in what I
suspect is a generally useful configuration.
I have fetchmail(1) collect mail from many mailboxes via pop3.
I store these mails in different mboxs according to rules in procmail(1)
I then offer these out to the household via imap in dovecot(1) .
I have fetchmail(1) set to poll the ISPs every 5 minutes, this seems to
work fine, but there are two issues:
1: The constant polling keeps the disk spinning for no good reason
(most of the time)
2: If I check my mail via a mail reader using imap to the local
mboxes ...there could be mail sitting on the ISP servers I don't see
(for 5 mins)
Now what would be much nicer, would simply be to have dovecot(1) issue
the fetchmail(1) command whenever it it got an imap request.
I general what I guess I would like is:
"When a request comes in (via imap) fork off a command who's name
is
given in the conf file. ... imap_pre_cmd="xxx"
--
Graeme
Graeme Vetterlein wrote:> I hoping this is an RTFM ... and somebody can point me at the correct > 'FM' :-) > > I've just spent a while setting my new Debian , allways-on box in what I > suspect is a generally useful configuration. > > I have fetchmail(1) collect mail from many mailboxes via pop3. > > I store these mails in different mboxs according to rules in procmail(1) > > I then offer these out to the household via imap in dovecot(1) . > > > I have fetchmail(1) set to poll the ISPs every 5 minutes, this seems to > work fine, but there are two issues: > > 1: The constant polling keeps the disk spinning for no good reason > (most of the time) > 2: If I check my mail via a mail reader using imap to the local > mboxes ...there could be mail sitting on the ISP servers I don't see > (for 5 mins)Graeme, I'm surprised that the polling is an issue. I've been running a very similar configuration for the family email server since 1999, and throughout that time fetchmail has been polling every 2 minutes! It's true that I've never tried to have the hard disk spin-down on the server - it seemed to me that other things would keep it spinning anyway. One suggestion would be to run the fetchmail on a slug (Linksys NSLU2) which can run Debian off a USB memory stick (I have one running like this for the last year, doing rsync backups off the server). Then the disk activity would be confined to the memory stick. Still, Dovecot can be made to do almost anything and "When a request comes in (via imap) fork off a command who's name is given in the conf file. ... imap_pre_cmd="xxx" " is a neat idea..... John -- John and Catherine Allen Bofferdange, Luxembourg allen at vo.lu http://www.homepages.lu/allen
On Sat, 2008-05-31 at 17:46 +0100, Graeme Vetterlein wrote:> Now what would be much nicer, would simply be to have dovecot(1) issue > the fetchmail(1) command whenever it it got an imap request.I've thought about this before too, but haven't bothered to implement such plugin. Wouldn't be too difficult. But: 1. Do you have IMAP client running all the time? If yes, this won't really help because: 2. Many IMAP clients simply issue an IDLE command and wait for new data to become available from server. So the server has to decide when to poll for new mail anyway. 3. All commands should check for new mail. But of course you wouldn't want fetchmail to be executed multiples times per second. So there should be some limit like max "once a minute". 4. If there are multiple connections (and many clients do that), Dovecot creates multiple processes. Only one process should be calling fetchmail. So I think the best solution would be to use post-login scripting: http://wiki.dovecot.org/PostLoginScripting Create a script something like: #!/bin/sh if ! ps|grep fetchmail-runner.sh; then # start calling fetchmail every n minutes fetchmail-runner.sh & fi /usr/local/libexec/dovecot/imap if ! ps|grep imap$; then # this was the last imap process. killall fetchmail-runner.sh fi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20080531/c73b8452/attachment-0002.bin>