[Dovecot] 0.99.10.6 -imap flag update problem still present
Hi,
the email status problem that I reported for Dovecot 0.99.10.5 on June 3rd does still show up in 0.99.10.6. Quoting myself:
(1) When new mail is delivered to the inbox, the last read mail(s) change(s) to "unread". Clients: Eudora 6 (Mac), Mozilla 1.6 (NetBSD, Linux, Win XP), MS Outlook.
(2) When you attempt to move mails from the inbox to another folder with Mozilla (1.6 on win32, Linux, NetBSD), they are not removed from the inbox, effectively performing a copy instead of a move.
And, while I am at it,
(3) I see a regular log entry from a MS Outlook 2000 SP 3
Jun 3 10:26:23 bounce imap-login: SSL_read() syscall failed: EOF [130.83.XXX.XXX]
The setup here: OS NetBSD 2.0beta, MTA sendmail 8.12.11, LDA maildrop 1.3.9, dovecot 0.99.10.6, OpenSSL 0.9.7d
Any ideas? My users are starting to nag...
hauke-- Institut für Nachrichtentechnik /~\ The ASCII Ribbon Campaign FG Signalverarbeitung \ / No HTML/RTF in email TU Darmstadt X No Word docs in email Ruf +49-6151-16-3281, Fax -3778 / \ Respect for open standards
On Thu, 2004-06-24 at 17:48, Hauke Fath wrote:
the email status problem that I reported for Dovecot 0.99.10.5 on June 3rd does still show up in 0.99.10.6. Quoting myself:
(1) When new mail is delivered to the inbox, the last read mail(s) change(s) to "unread". Clients: Eudora 6 (Mac), Mozilla 1.6 (NetBSD, Linux, Win XP), MS Outlook.
Is this with maildir?
(2) When you attempt to move mails from the inbox to another folder with Mozilla (1.6 on win32, Linux, NetBSD), they are not removed from the inbox, effectively performing a copy instead of a move.
Probably same reason why 1) happens.
It seems like flags cannot be changed at all? There's nothing in Dovecot's logs? Did it used to work before?
(3) I see a regular log entry from a MS Outlook 2000 SP 3
Jun 3 10:26:23 bounce imap-login: SSL_read() syscall failed: EOF [130.83.XXX.XXX]
ssl_verbose = no. That's the reason it's no by default, the messages aren't very useful.
Timo Sirainen wrote:
On Thu, 2004-06-24 at 17:48, Hauke Fath wrote:
the email status problem that I reported for Dovecot 0.99.10.5 on June 3rd does still show up in 0.99.10.6. Quoting myself:
(1) When new mail is delivered to the inbox, the last read mail(s) change(s) to "unread". Clients: Eudora 6 (Mac), Mozilla 1.6 (NetBSD, Linux, Win XP), MS Outlook.
Is this with maildir?
No, mbox.
(2) When you attempt to move mails from the inbox to another folder with Mozilla (1.6 on win32, Linux, NetBSD), they are not removed from the inbox, effectively performing a copy instead of a move.
Probably same reason why 1) happens.
It seems like flags cannot be changed at all? There's nothing in Dovecot's logs?
Nothing.
Did it used to work before?
No. I set up the server two months ago with 0.99.10.4, iirc. The issue is most annoying for Mozilla users since deleted mail is only flagged (which does not work), so you get duplicates after every move. Eudora physically removes the original mail, so the problem only shows up with the 'read' flag.
(3) I see a regular log entry from a MS Outlook 2000 SP 3
Jun 3 10:26:23 bounce imap-login: SSL_read() syscall failed: EOF [130.83.XXX.XXX]
ssl_verbose = no. That's the reason it's no by default, the messages aren't very useful.
:)
Okay, I'll change that.
hauke-- Hauke Fath /~\ The ASCII Ribbon Campaign Institut für Nachrichtentechnik \ / No HTML/RTF in email TU Darmstadt X No Word docs in email Ruf +49-6151-16-3281 / \ Respect for open standards
On Thu, 2004-06-24 at 18:12, Hauke Fath wrote:
(1) When new mail is delivered to the inbox, the last read mail(s) change(s) to "unread". Clients: Eudora 6 (Mac), Mozilla 1.6 (NetBSD, Linux, Win XP), MS Outlook. Is this with maildir?
No, mbox.
Oh. This all pretty much sounds like Dovecot sees users INBOX as read-only so it won't modify flags and won't expunge messages.
You could check this with eg. telnet:
telnet localhost imap2 x login user pass x select inbox
and see if it sends READ-ONLY or READ-WRITE tag.
I think the only reason for it to be treated as read-only is if the file permissions really are such.
Am 28.06.2004 um 12:42 Uhr +0300 schrieb Timo Sirainen:
Oh. This all pretty much sounds like Dovecot sees users INBOX as read-only so it won't modify flags and won't expunge messages.
You could check this with eg. telnet:
telnet localhost imap2 x login user pass x select inbox
and see if it sends READ-ONLY or READ-WRITE tag.
I think the only reason for it to be treated as read-only is if the file permissions really are such.
From /etc/dovecot.conf:
# Sync this with "DEFAULT" in /etc/courier/maildroprc default_mail_env = mbox:~/Mail/:INBOX=%h/Mail/INBOX
[hf@bounce] ~ > cd Mail [hf@bounce] ~/Mail > ll INBOX 27008 -rw------- 1 hf spgmit 27610472 Jun 28 12:00 INBOX [hf@bounce] ~/Mail > telnet localhost imap2 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.
- OK dovecot ready. x login hf XXXXXXXX x OK Logged in. x select inbox
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft NotJunk Junk NonJunk)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft NotJunk Junk NonJunk \*)] Flags permitted.
- 604 EXISTS
- 3 RECENT
- OK [UNSEEN 573] First unseen.
- OK [UIDVALIDITY 1054653796] UIDs valid
- OK [UIDNEXT 5280] Predicted next UID x OK [READ-WRITE] Select completed.
Hum...
hauke-- Institut für Nachrichtentechnik /~\ The ASCII Ribbon Campaign FG Signalverarbeitung \ / No HTML/RTF in email TU Darmstadt X No Word docs in email Ruf +49-6151-16-3281, Fax -3778 / \ Respect for open standards
On Mon, 2004-06-28 at 13:07, Hauke Fath wrote:
Am 28.06.2004 um 12:42 Uhr +0300 schrieb Timo Sirainen:
Oh. This all pretty much sounds like Dovecot sees users INBOX as read-only so it won't modify flags and won't expunge messages. .. x OK [READ-WRITE] Select completed.
So, not that then. Are any flag changes permanent? If you modify seen flag, is "Status: RO" header ever written in the mbox? They aren't updated immediately, only after the mailbox is closed. And if moving mails didn't work, did simply expunging them?
Anyway, this sounds pretty strange. I haven't heard of anything similiar before and 0.99.10.6 is used with mbox by many people..
Timo Sirainen wrote:
On Mon, 2004-06-28 at 13:07, Hauke Fath wrote:
x OK [READ-WRITE] Select completed.
So, not that then. Are any flag changes permanent? If you modify seen flag, is "Status: RO" header ever written in the mbox?
Where would I see that? In a telnet session? In the headers in the mailbox file?
They aren't updated immediately, only after the mailbox is closed. And if moving mails didn't work, did simply expunging them?
Anyway, this sounds pretty strange. I haven't heard of anything similiar before and 0.99.10.6 is used with mbox by many people..
8/ ...
There are actually two problems that are reported to me:
(1) People are reading mail, and when the next mail comes in, the mails just read change status to 'unread'. I've seen this myself with a variety of clients, not strictly reproducibly, but... it happens.
(2) People move read mail from the inbox to some other folder (or delete it) and find two copies - one in the new folder (or trash), and one in the old one. This I have not seen myself, and those who have seen it have not yet reported it for 0.99.10.6.
hauke-- Hauke Fath /~\ The ASCII Ribbon Campaign Institut für Nachrichtentechnik \ / No HTML/RTF in email TU Darmstadt X No Word docs in email Ruf +49-6151-16-3281 / \ Respect for open standards
On Mon, 2004-06-28 at 17:28, Hauke Fath wrote:
Timo Sirainen wrote:
On Mon, 2004-06-28 at 13:07, Hauke Fath wrote:
x OK [READ-WRITE] Select completed.
So, not that then. Are any flag changes permanent? If you modify seen flag, is "Status: RO" header ever written in the mbox?
Where would I see that? In a telnet session? In the headers in the mailbox file?
Well, both would work with 0.99.10.6. Probably easier to check from mbox file itself. But if the problems didn't always happen, I guess that's not the problem itself.
There are actually two problems that are reported to me:
(1) People are reading mail, and when the next mail comes in, the mails just read change status to 'unread'. I've seen this myself with a variety of clients, not strictly reproducibly, but... it happens.
Seeing what Dovecot and IMAP clients talk when it happens would help.. Enabling rawlog (last chapter in http://dovecot.org/bugreport.html) would do that.
One explanation would be that Dovecot sees the new mails (or that mbox has changed), then syncs the whole file again, but for some reason the UIDs don't match in right order, or some other data didn't match right, so Dovecot expunges those messages and creates new UIDs for them, forgetting about the old flag changes which wheren't yet written to disk. For example some older MUAs used to sort mbox, if Dovecot's X-UID header ordering was changed it generated new ones.
(2) People move read mail from the inbox to some other folder (or delete it) and find two copies - one in the new folder (or trash), and one in the old one. This I have not seen myself, and those who have seen it have not yet reported it for 0.99.10.6.
Could be the same problem.. Dovecot moves the mails, then tries to expunge the messages only to find out they were already gone.
I'd almost suggest trying 1.0-tests, but I guess they still have some problems too which might just make things worse (corrupt the mboxes), although I've been running them fine for a week or so..
participants (2)
-
Hauke Fath
-
Timo Sirainen