On Tue, Sep 28, 2010 at 06:52:55PM +0100, Timo Sirainen wrote:
> On Tue, 2010-09-28 at 10:26 +0200, Adam Borowski wrote:
> 
> > The version of dovecot in Lenny notified its IMAP clients both when a mail
> > arrived and when it was deleted.  In Squeeze, only the former works.  If you
> > delete something using anything outside the mail client -- be that mutt or a
> > cron job harvesting manually tagged spam, the mail in question will appear
> > to be still there even after telling the client to check the mail server.
> > Only disconnecting and connecting again rectifies the problem.

Sorry for the delay, I've been having some trouble reproducing this.
Before reporting this, I tried various clients, believing it's something
related to them rather than dovecot.
After reporting, I suddenly stopped getting this problem at all for several
days -- which made me believe it might be something related to not
restarting dovecot after the upgrade or something.
But then, it happened randomly and persisted until the mail client was
closed but didn't happen again until another day, despite attempts to
trigger it somehow.

So whatever is the cause, the bug seems to be acting erratically.

> What mailbox format?

Maildir.

> dovecot -n output?

# 1.2.13: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.26-2-vserver-amd64 x86_64 Debian squeeze/sid 
log_timestamp: %Y-%m-%d %H:%M:%S 
protocols: imaps pop3s
ssl_listen(default): *:993
ssl_listen(imap): *:993
ssl_listen(pop3): *:995
ssl_cert_file: /etc/ssl/certs/mail.jkm.net.pl
ssl_key_file: /etc/ssl/private/mail.jkm.net.pl
login_dir: /var/run/dovecot/login
login_executable(default): /usr/lib/dovecot/imap-login
login_executable(imap): /usr/lib/dovecot/imap-login
login_executable(pop3): /usr/lib/dovecot/pop3-login
mail_privileged_group: mail
mbox_write_locks: fcntl dotlock
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/modules/imap
mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3
auth default:
  verbose: yes
  passdb:
    driver: pam
  userdb:
    driver: passwd


> Do you know if the clients are using IDLE or even without it?

It's only the case for ones that do use it.  But then, clients without IDLE
are kind of useless unless you enjoy not knowing about new mail for 10
minutes or whatever the time of hammering the server is set.

For example, right now the bug is manifesting itself, and I have open
icedove 3.1.4-1 (supports IDLE) and claws-mail 3.7.6-2 (no such support). 
Icedove believes there are three unread mails, all of them have been deleted
using mutt already -- and when a new one arrives, it will keep showing them
regardless of their status.  Claws on the other hand forces you to manually
check the mail, and disconnects between those checks -- a check will notice
the now-deleted ones are gone.

So it's definitely something related to IDLE.

-- 
1KB             // Microsoft corollary to Hanlon's razor:
                //      Never attribute to stupidity what can be
                //      adequately explained by malice.



-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to