similar to: Replication milestone 1

Changes: - Added goal 8 and rewrote mailbox synchronization plan. - Added new SELECT command to change active mailbox and removed mailbox ID from command parameters Goals ----- 1. If a single (or configurable number of) server dies, no mails must be lost that have been reported to IMAP/SMTP clients as being successfully stored. 2. Must be able to automatically recover from a server

I'll probably be implementing multi-master replication this summer. My previous thoughts about it are here: http://dovecot.org/list/dovecot/2007-December/027284.html Below is a description of how the replication protocol will probably work. It should work just as well for master-slave and multi-master setups. Comments welcome. I'll write later a separate mail about how it'll be

I wrote a mostly-working CONDSTORE support for Dovecot today. You can try it with: hg clone http://hg.dovecot.org/dovecot-condstore/ There are a few problems left: - STORE FLAGS.SILENT should be sending FETCH MODSEQ updates - When SELECTing a mailbox while CONDSTORE hasn't yet been enabled in the session, Dovecot returns a higher HIGHESTMODSEQ than what's used after CONDSTORE is

I merged all the new features and latest v1.1 changes under one tree: http://hg.dovecot.org/dovecot-1.2/ The changeset order is kind of weird though. The timestamps jump all around. Wonder if there's a way to reorder them so that it looks more sane.. The status of the new features: 1. CONDSTORE extension is probably the largest change. It adds new "modification sequences" for

http://dovecot.org/releases/1.2/alpha/dovecot-1.2.alpha1.tar.gz http://dovecot.org/releases/1.2/alpha/dovecot-1.2.alpha1.tar.gz.sig This is the only v1.2.alpha announcement I'm going to send to dovecot-news list. Next announcement will be for either v1.2.beta1 or v1.2.rc1. I'm hoping that v1.2 stabilizes pretty soon. There are no huge changes like there were in 0.99->1.0 or

http://dovecot.org/releases/1.2/alpha/dovecot-1.2.alpha1.tar.gz http://dovecot.org/releases/1.2/alpha/dovecot-1.2.alpha1.tar.gz.sig This is the only v1.2.alpha announcement I'm going to send to dovecot-news list. Next announcement will be for either v1.2.beta1 or v1.2.rc1. I'm hoping that v1.2 stabilizes pretty soon. There are no huge changes like there were in 0.99->1.0 or

Running into a weird issue in a mailbox that has 26+ keywords. In one session, I do this: S: 2 SELECT "INBOX" (QRESYNC (1255685337 78608 [...uids...])) S: [...] S: * OK [HIGHESTMODSEQ 78608] Highest S: * OK [UIDVALIDITY 1255685337] UIDs valid S: 2 OK [READ-WRITE] Select completed. C: 3 UID STORE 48386 (UNCHANGEDSINCE 78608) +FLAGS AAAAAAAA S: * 8 FETCH (UID 48386 MODSEQ (78609) FLAGS

First a list of all the new features and their state: 1. http://hg.dovecot.org/dovecot-threadindexes/ THREAD=REFERENCES indexes. Missing NFS flushes, support for mmap_disable=yes, breaks when more than one session modifies at the same time. Not tested much if the replies are really correct at all. Also started THREAD=X-REFERENCES2 but it doesn't work as expected. 2.

Hello, I'd like to follow up on someone else's old thread: http://dovecot.org/list/dovecot/2012-April/082624.html I understand that Dovecot (that 2012 discussion was about version 2.0.18) can return "HIGHESTMODSEQ 1" upon SELECT if persistent modseq tracking was never enabled for a mailbox. I'd like to get a clarification on how to enable proper persistent modseq

On Tue, 04 Apr 2017 11:07:26 +0000 Luca Bertoncello <lucabert at lucabert.de> wrote: > Hi all, > > i've got a strange behaviour with a BlackBerry Classic Phone (BBOS > 10.3.2.2876) in combination with Dovecot 2.2.13 while trying to > fetch mails. > > Before burying myself into debugging sessions, i try to get an > understanding if the following is a Client-

RFC 5162 [3.1] states that a QRESYNC should return all changes in a SELECT/EXAMINE since the given modseq. In the following case, it looks like there is an off-by-1 error somewhere: C: A64 SELECT "TestMailboxTest" (QRESYNC (1224531494 6 1,3:5)) [MMS: MODSEQ given is 6] S: * OK [CLOSED] S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Answered \Flagged

Hi all, i've got a strange behaviour with a BlackBerry Classic Phone (BBOS 10.3.2.2876) in combination with Dovecot 2.2.13 while trying to fetch mails. Before burying myself into debugging sessions, i try to get an understanding if the following is a Client- or a Server-specific error in the behaviour: CIGA8 UID FETCH 10009:10035 (UID FLAGS) (CHANGEDSINCE NOMODSEQ) CIGA8 BAD Error

Hi Timo - hope things are well :) Playing around with the CONDSTORE (RFC 4551) stuff while testing the IMAP lib I am writing and I think I have found a bug in Dovecot 1.2. RFC 4551 [4] identifies the FETCH response to a MODSEQ request as follows: fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")" with 'permsg-modsequence' defined as:

Good morning, I use ?doveadm backup -R -m foo -s $state? to create a local mirror of an imapc remote folder. When I run that command, wait for it to finish, deliver a new message to the remote folder, and run that command again, the new message does not get downloaded from the remote. I'll attach the rawlog, doveconf, etc at the end. Allow me first to summarize what I've already

Greetings, I'm new to the list. I have encountered what I believe to be a bug in the return of HIGHESTMODSEQ when talking to a IMAP client. HIGHESTMODSEQ does not appear to be incrementing when a new message arrives. The exact steps I took are: 1) Create a new mail account 2) Send a mail to the account, check that you can receive the email. Send a second mail to the account. 3) perform a

One more data point Timo: On Tue, Mar 12, 2019, at 9:58 AM, Kostya Vasilyev via dovecot wrote: > Timo, > > On Tue, Mar 12, 2019, at 3:56 AM, Timo Sirainen via dovecot wrote: >> On 10 Mar 2019, at 10.14, Kostya Vasilyev via dovecot <dovecot at dovecot.org> wrote: >>> >>> My mail is stored under ~/mail/.imap (not sure what this format is called), I mean not

I've been seeing the following wonky behavior with Dovecot. Currently this is with Dovecot 2.0.19, but I was also seeing it in earlier versions as well, including versions from the 1.x series. Some background, this is from Horde's ActiveSync library, when it is trying to determine what UIDs have recently been expunged. I can guarantee that when this command was sent, there was

Timo, On Wed, Mar 13, 2019, at 12:39 AM, Timo Sirainen wrote: > On 12 Mar 2019, at 10.21, Kostya Vasilyev via dovecot <dovecot at dovecot.org> wrote: >> >> It makes no difference if the IDLE connection does SELECT or SELECT (CONDSTORE) prior to going IDLE. >> >> But then as far as I know (?) - in Dovecot, once any connection uses CONDSTORE ever, even once,

On 20 Mar 2017, at 13.24, C?dric ML <cedric.bassaget.ml at gmail.com> wrote: > > Hello, > > I'm trying to migrate mail accounts from an old server to a new one. > As I need to migrate dozens of accounts which take about 1G each, I need to do stateful sync to make my migration in two times : > > 1 - I run a : > doveadm -D -o mail_fsync=never -o

On 12 Mar 2019, at 10.21, Kostya Vasilyev via dovecot <dovecot at dovecot.org> wrote: > > It makes no difference if the IDLE connection does SELECT or SELECT (CONDSTORE) prior to going IDLE. > > But then as far as I know (?) - in Dovecot, once any connection uses CONDSTORE ever, even once, Dovecot creates data structures to track MODSEQ values, and those data structures are