Re: Two problems with new FC3 x86_64 install

[Willem Riede <wriede riede org>]

On 12/28/2004 01:10:33 PM, Pawel Salek wrote:
> I have misunderstood you. I thought I meant that balsa does not
> discover these mails by itself. It is dovecot that does not discover
> them, is that correct?

Well, that's hard to say. Dovecot does know to tell Balsa that there are  
recent new mails when Balsa opens the box, that info just doesn't get across  
if new mail arrives while Balsa has the box open.

> IMAP server sends * xxx EXISTS response to notify the client about new
> mail. You can run balsa with -D option and grep the output for EXISTS.

The only time EXISTS appears in the debug output is immediately after Balsa  
startup, as Balsa opens the box:

IMAP C: 3 CAPABILITY
IMAP S: * CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT  
LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED NAMESPACE AUTH=PLAIN
3 OK Capability completed.
IMAP C: 4 LOGIN "wriede" (password hidden)
IMAP S: 4 OK Logged in.
IMAP C: 5 LIST "" ""
IMAP S: * LIST (\Noselect) "." ""
5 OK List completed.
IMAP C: 6 LIST "" "%"
IMAP S: * LIST (\HasNoChildren) "." INBOX
* LIST (\HasNoChildren) "." "Sent"
6 OK List completed.
IMAP C: 7 SELECT "Sent"
IMAP S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags  
permitted.
* 3077 EXISTS
* 299 RECENT
* OK [UNSEEN 2] First unseen.
* OK [UIDVALIDITY 1104167159] UIDs valid
* OK [UIDNEXT 3078] Predicted next UID
7 OK [READ-WRITE] Select completed.
IMAP C: 8 SEARCH 1:3077 UNSEEN
9 SEARCH 1:3077 DELETED
<lots of output follows>


> I have checked the dovecot documentation, and I can see that dovecot
> can be configured not to send this response under certain
> circumstances. Check out "client_workarounds" keyword in
> /etc/dovecot.conf - its value should preferably be empty. You probably
> might want to set "mailbox_check_interval" to some low value (30?).

I set both mailbox_check_interval and mailbox_idle_check_interval to 10  
(seconds). The latter has a 30 second default, but the former appears to be  
off by default. Didn't help.

> dovecot is in a bit special because it treats NOOP command (No
> Operation) as CHECK while the only purpose of this command is to give
> the server opportunity to send responses it is forbidden to send in
> response to some other commands. It also breaks IMAP standard in some
> more obscure cases, too (when APPEND command fails, the server's
> response will be nonconformant and hang the client). I had used dovecot
> (0.99) for few months in a medium size environment, got hurt few times
> and went back to UW-IMAP (with mbx as the default mailbox format), at
> least for now - 1.x that is under development is supposed to have many
> of these problems fixed. Your mileage may vary, as they say. This is
> off-topic, though.

If it is a Dovecot problem, yes, understood. But at this time, with my limited  
domain knowledge, I don't know whether Balsa isn't asking the right question,  
or Dovecot isn't giving the right answer!

This is what I see in the -D log in idle conditions:

32 OK Fetch completed.
IMAP C: 33 NOOP
IMAP S: 33 OK NOOP completed.
IMAP C: 34 LIST "INBOX" "%"
IMAP S: 34 OK List completed.
IMAP C: 35 NOOP
IMAP S: 35 OK NOOP completed.
IMAP C: 36 LIST "INBOX" "%"
IMAP S: 36 OK List completed.
IMAP C: 37 NOOP
IMAP S: 37 OK NOOP completed.
IMAP C: 38 LIST "INBOX" "%"
IMAP S: 38 OK List completed.

Only "INBOX" is monitored for changes? What about the box "Sent" that was  
opened above? I set the scan depth to 2, to see if that makes a difference,  
but it doesn't.

[IMAPFolderScanning]
ScanDepth=2
[FolderScanning]
LocalScanDepth=1
ImapScanDepth=2

So for now, your continued help is appreciated. Willem Riede.