Re: [fetchmail-devel] Re: BUG (?) fetchmail 6.3.2 hangs with 'idle' on OpenBSD

[Casper G. <cas...@ko...>]

On Wed, Mar 01, 2006 at 01:35:16PM +0530, Sunil Shetye wrote:
> As far as the delay part goes, even with IMAP servers supporting IDLE,
> a delay of one minute is expected as IMAP servers checkpoint the
> folder every one minute or so. Of course, it will actually depend on
> the IMAP server configuration and implementation, 

Ok I see. On the IMAP server I use the mail delivery is instant. 
I tried it with direct telnet to the smtp server, and as soon as 
I send the mail I see it on the IMAP side. There is absolutely 
no delay.

> but the point is
> that a small delay is acceptable. Here, the maximum delay will be 28
> seconds, which should be acceptable.
>
> Could you log to syslog and send the output (with your patch)? I want
> to see the time aspect of this. In particular, I want to see if there
> is a delay between the "NOOP" response and the "EXISTS" response. If
> there is a delay, then your average delay will actually be 14 seconds.

Here is the output. I cleaned it up a bit, and it includes my
mta output too, so you can see when my testmail leaves my machine.

11:51:10 : 0 messages waiting after first poll
11:51:10 : IMAP> A0004 NOOP
11:51:10 : IMAP< A0004 OK NOOP completed
11:51:38 : IMAP> A0005 NOOP
11:51:38 : IMAP< A0005 OK NOOP completed
11:51:54 sendmail[16018]: k219psZR016018: from=casper, size=60, class=0, nrcpts=1, msgid=<200603010951.k219psZR016018@xxxxx>, relay=casper@localhost
11:51:55 sm-mta[30673]: k219psb5030673: from=<casper@xxxxx>, size=392, class=0, nrcpts=1, msgid=<200603010951.k219psZR016018@xxxxx>, proto=ESMTP, daemon=MTA, relay=casper@localhost [127.0.0.1]
11:51:55 sendmail[16018]: k219psZR016018: to=cas...@ko..., ctladdr=casper (1000/1000), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30050, relay=localhost. [127.0.0.1], dsn=2.0.0, stat=Sent (k219psb5030673 Message accepted for delivery)
11:51:55 : IMAP< * 1 EXISTS
11:51:55 : IMAP> A0006 EXPUNGE
11:51:55 : IMAP< * 1 RECENT
11:51:55 : IMAP< A0006 OK EXPUNGE completed
11:51:55 : 1 message waiting after expunge
11:51:55 : IMAP> A0007 SEARCH UNSEEN NOT DELETED
11:51:55 : IMAP< * SEARCH 1
11:51:55 : 1 is unseen
11:51:55 : IMAP< A0007 OK SEARCH completed
11:51:55 : 1 is first unseen
11:51:55 : 1 message for xxxxx at mail.kolumbus.fi.

> The problem with your patch is that it forces recentcount to be equal
> to count. You have a simple setup where all mails are always
> downloaded and deleted from the server. In this scenario, the number
> before EXISTS and RECENT will always be equal. However, there are
> people who have a setup where some seen mails are there on the
> mailserver and fetchmail is running with "no fetchall". So, forcing
> recentcount to count is not correct.

Ok. Right. It was a shoot from the hip fix. I just wanted to avoid the
delay if possible. But if it's not avoidable in any proper way then
that is the way it is. I guess people can live with getting their 
e-mails a few seconds later, it's not THAT critical :) But for me
the delay in there will still bother me..can't help it, sorry :)
For anyone else, I guess they will never know. I would have never
known hadn't I started investigating the problem anyway.

Casper