I've been using fetchmail to poll a series of pop3 servers for a long time. Recently I added a single imap server to the list, and asked fetchmail to use idle on that connection. Today I found out that messages from my other mailboxes were no longer arriving. Restarting fetchmail retrieved these messages, but new messages after startup weren't recognized by fetchmail. Removing the "idle" option from fetchmailrc allowed me to receive new mails again. So this is a workaround until fetchmail gets fixed. I assume that the imap idle implementation doesn't return control back to the loop over my different servers, so that fetchmail gets stuck on that single account. This is a guess, though, as I haven't yet understood the sources at first glance. I guess it would be useful if someone else could confirm that other servers aren't polled at all. My live connections are all encrypted, so I can't simply wireshark them. I could setup a test system, with full dovecot, fetchmail and some app where fetchmail could drop its mail, but this would take serious time, so if someone else has an unencrypted setup he can simply adjust, I'd be very happy. My fetchmailrc looks like this: set syslog defaults proto pop3 fetchall fetchlimit 500 ssl sslcertck sslcertpath /etc/ssl/certs poll mail1.example.com user "user1" pass "pass1" is localUser poll mail2.example.com user "user2" pass "pass2" is localUser poll mail3.example.com user "user3" pass "pass3" is localUser poll mail4.example.com proto imap user "user4" pass "pass4" idle is localUser
(In reply to comment #0) > My live connections are all encrypted, so I can't simply wireshark them. Not a particularly good excuse. ;-) Had a look at the (still encrypted) connections. Indeed, with the idle option, the server polls all hosts, keeps the last connection open, and sends one packet every 120 seconds on that connection. Without it, every connection will be terminated after a short time (presumable once the poll is complete), and the hosts will all be connected to after the next timeout.
OK, my fault: it's already documented in the man page: > On the other hand, an IDLE connection will eat almost all of your > fetchmail's time, because it will never drop the connection and allow other > polls to occur unless the server times out the IDLE. So this is a known and coumented limitation. What do you make of this report? INVALID as behaviour matches documentation, WONTFIX as I'll have to accept suboptimal behaviour, or Severity=enhancement as this now becomes a wish?
Well, it's hard to say what exactly to do, but since it's documented behaviour I'll close this bug anyway.
