I'm currently running fetchmail --idle on a somewhat flaky PPPoE link,
where my IP address tends to change quite often.

On every IP address change, the following happens:

- /etc/init.d/fetchmail awaken is run by the PPP/resolvconf script

- Fetchmail ignores the USR1 signal

- Upon expiration of the 28-minute IDLE timeout, when it is time to
  issue a DONE, fetchmail reports a timeout "waiting for server", and
  goes to sleep for <interval>.

- On the next cycle, it finally re-establishes a connection to the IMAP
  server.  (I guess I shouldn't have picked 3600 as the poll interval.)


It seems to me that fetchmail should react to a USR1 in IDLE just like
it does when polling.  (I realize that IDLE is run *within* the polling
loop, but it's conceptually presented as an *alternative* to polling, so
it should behave the same.)

underlying blocking read() from the socket, so we never break out of the
SSL_peek() with SIGUSR1.

This won't be fixed in fetchmail 6.3.X.