Streaming MOVE commands
Dear Dovecot devs,
is streaming multiple MOVE commands by clients allowed?
I am getting duplicated messages with the GNUS mail client, the interchange looks like this:
*stream two moves to different folders*
9019 UID MOVE 4062,4066,4068 "folder0" 9020 UID MOVE 4063:4064,4067,4069:4072 "folder1" *the messages are copied*
- OK [COPYUID 1424475218 4062,4066,4068 376:378] Moved UIDs.
- OK [COPYUID 1424475231 4063:4064,4067,4069:4072 26:32] Moved UIDs. *however expunge fails to clean 4063, 4064, and 4067*
- VANISHED 4062,4066,4068:4072
thus 4063, 4064, and 4067 end both in inbox and folder1 producing duplicate messages (more details at [1]).
At the GNUS mailing list, we were wondering about what should be the correct reading of RFC6851.
Version and config information below.
Best regards, Emilio
[1] More details in the thread http://permalink.gmane.org/gmane.emacs.gnus.general/86813
[2] Version $ /usr/sbin/dovecot --version 2.2.13
[3] Config
$ /usr/sbin/dovecot -n # 2.2.13: /etc/dovecot/dovecot.conf # OS: Linux 3.2.0-4-amd64 x86_64 Debian 8.3 ext4 mail_location = maildir:/home/%u/Maildir managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave
namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } protocols = " imap sieve" ssl_cert = ... ssl_key = ... userdb { driver = passwd }
On 14 Feb 2016, at 06:17, Emilio Jesús Gallego Arias gallego@cri.ensmp.fr wrote:
Dear Dovecot devs,
is streaming multiple MOVE commands by clients allowed?
I am getting duplicated messages with the GNUS mail client, the interchange looks like this:
*stream two moves to different folders*
9019 UID MOVE 4062,4066,4068 "folder0" 9020 UID MOVE 4063:4064,4067,4069:4072 "folder1" *the messages are copied*
- OK [COPYUID 1424475218 4062,4066,4068 376:378] Moved UIDs.
- OK [COPYUID 1424475231 4063:4064,4067,4069:4072 26:32] Moved UIDs. *however expunge fails to clean 4063, 4064, and 4067*
- VANISHED 4062,4066,4068:4072
thus 4063, 4064, and 4067 end both in inbox and folder1 producing duplicate messages (more details at [1]).
At the GNUS mailing list, we were wondering about what should be the correct reading of RFC6851.
Thanks, looks like this was broken with Maildir and mbox formats. It also caused expunges in some other situations to be lost. Fixed:
https://github.com/dovecot/core/commit/950a6e61d6c2dac961ce031bdd8b2895bc32b...
Hello Timo,
Timo Sirainen tss@iki.fi writes:
Thanks, looks like this was broken with Maildir and mbox formats. It also caused expunges in some other situations to be lost. Fixed:
https://github.com/dovecot/core/commit/950a6e61d6c2dac961ce031bdd8b2895bc32b...
Thanks a lot for the fix, testing it now!
Is this patch suitable of being backported to 2.2.13? (Debian stable)
Best regards, E.
On 21 Feb 2016, at 13:46, Emilio Jesús Gallego Arias gallego@cri.ensmp.fr wrote:
Hello Timo,
Timo Sirainen tss@iki.fi writes:
Thanks, looks like this was broken with Maildir and mbox formats. It also caused expunges in some other situations to be lost. Fixed:
https://github.com/dovecot/core/commit/950a6e61d6c2dac961ce031bdd8b2895bc32b...
Thanks a lot for the fix, testing it now!
Is this patch suitable of being backported to 2.2.13? (Debian stable)
Should be.
BTW. This bug only meant that some expunges were ignored, which at worst caused unwanted email duplicates. It didn't corrupt the mailbox state or the client state in any way.
On Mon, 22 Feb 2016, Timo Sirainen wrote:
On 21 Feb 2016, at 13:46, Emilio Jesús Gallego Arias gallego@cri.ensmp.fr wrote:
Hello Timo,
Timo Sirainen tss@iki.fi writes:
Thanks, looks like this was broken with Maildir and mbox formats. It also caused expunges in some other situations to be lost. Fixed:
https://github.com/dovecot/core/commit/950a6e61d6c2dac961ce031bdd8b2895bc32b...
Thanks a lot for the fix, testing it now!
Is this patch suitable of being backported to 2.2.13? (Debian stable)
Should be.
This will definitely go into the upcoming 2.2.21 packages. (After a long period of stasis we're going to bring everything up to date again soon.)
I don't know if the release team will allow it for stable even though it is a minor change but I'll definitely bring it up for their consideration.
-- Jaldhar H. Vyas jaldhar@debian.org
Thanks a lot both for your help!
On Mon, 22 Feb 2016, Timo Sirainen wrote:
Is this patch suitable of being backported to 2.2.13? (Debian stable)
Should be.
BTW. This bug only meant that some expunges were ignored, which at worst caused unwanted email duplicates. It didn't corrupt the mailbox state or the client state in any way.
Thanks for the update. Testing on 2.2.13.
"Jaldhar H. Vyas" jaldhar@debian.org writes:
I don't know if the release team will allow it for stable even though it is a minor change but I'll definitely bring it up for their consideration.
Timo said the bug doesn't corrupt data, but IMVHO a case could be made for stable-updates.
I get around 100-200 duplicated mails a day, so it really hampers the usability of the package with my mail client (gnus).
Also, it seems that the bug be prevent people to use dsync and other sync tools with Dovecot.
Luca, does the patch fix your dsync issues?
Unfortunately, I can't properly test the patch with 2.2.13, my mail servers have really low mail volume to consider them "testing".
Best, Emilio
Hi,
Timo Sirainen tss@iki.fi writes:
Thanks, looks like this was broken with Maildir and mbox formats. It also caused expunges in some other situations to be lost. Fixed:
https://github.com/dovecot/core/commit/950a6e61d6c2dac961ce031bdd8b2895bc32b...
Is this patch suitable of being backported to 2.2.13? (Debian stable)
Should be.
BTW. This bug only meant that some expunges were ignored, which at worst caused unwanted email duplicates. It didn't corrupt the mailbox state or the client state in any way.
The GNUS mail client developers would like to add quirk to workaround this problem in its mail client, any idea which version should be affected by this problem?
Thank you & best regards, Emilio
participants (3)
-
gallego@cri.ensmp.fr
-
Jaldhar H. Vyas
-
Timo Sirainen