similar to: doveadm backup doesn't transfer mail from root INBOX

Hello, I migrated our mail infrastructure to Dovecot on Ubuntu 18.04 some months ago. It works fine, but recently some users told me that they sometime receive duplicated emails. Same email content, same headers including message-id. I'm using two dovecot servers on two sites. Both server are in cluster. We don't use shared folders. All users that reported this issue so far are using the

On Aug 12, 2019, at 12:18 AM, Sami Ketola via dovecot <dovecot at dovecot.org> wrote: > > "1. What's the first mail's saved-timestamp? > doveadm fetch -u user date.saved mailbox Junk 1 Well... this is giving me strange results. For myself, when I run this command, I get: [~]# doveadm fetch -u cepheid date.saved mailbox Junk 1 date.saved: 2019-07-15 01:42:56

On Aug 12, 2019, at 8:54 PM, Thomas Zajic via dovecot <dovecot at dovecot.org> wrote: > > * Amir Caspi via dovecot, 12.08.19 22:01 > >> [~]# doveadm mailbox status -u cepheid firstsaved Junk >> Junk firstsaved=1563154976 >> >> I can't tell how that timestamp corresponds to a human-readable date, however. > > [zlatko at disclosure:~]$ date -d

* Amir Caspi via dovecot, 12.08.19 22:01 > [~]# doveadm mailbox status -u cepheid firstsaved Junk > Junk firstsaved=1563154976 > > I can't tell how that timestamp corresponds to a human-readable date, however. [zlatko at disclosure:~]$ date -d @1563154976 Mon Jul 15 03:42:56 CEST 2019 HTH, Thomas

On 13 Aug 2019, at 5.57, Amir Caspi via dovecot <dovecot at dovecot.org> wrote: > > On Aug 12, 2019, at 8:54 PM, Thomas Zajic via dovecot <dovecot at dovecot.org> wrote: >> >> * Amir Caspi via dovecot, 12.08.19 22:01 >> >>> [~]# doveadm mailbox status -u cepheid firstsaved Junk >>> Junk firstsaved=1563154976 >>> >>> I

The mailbox is too big. ---Aki TuomiDovecot oy -------- Original message --------From: Ian Bobbitt <ibobbitt at globalnoc.iu.edu> Date: 23/02/2018 17:52 (GMT+02:00) To: dovecot at dovecot.org Subject: Assertion during dsync receive Hi, I'm getting an assertion failed on the receiving side, causing syncs to fail for one user. The servers are setup so that only one is receiving any

Once you cache grows bigger than 0x4000000 you have problems ---Aki TuomiDovecot oy -------- Original message --------From: Ian Bobbitt <ibobbitt at globalnoc.iu.edu> Date: 23/02/2018 20:33 (GMT+02:00) To: dovecot at dovecot.org Subject: Re: Assertion during dsync receive Thanks. I've had the user clear out that mailbox, and replication is working fine for them again.

Are you sure you have deleted mails and not just Trashed mails? Aki On 26.07.2018 19:23, Johan Huldtgren wrote: > hello, > > on the wiki, https://wiki2.dovecot.org/MailboxFormat/dbox, it says that one can > use either doveadm fetch or doveadm import, however I can find no correct syntax > with fetch that'll actually work. Is the idea to simply override the > mail_location

Thanks. I've had the user clear out that mailbox, and replication is working fine for them again. Is there a better way to catch this than watch for crashes and read the backtrace to find what mailbox needs to be shrunk? Where is the threshold for "too big"? -- Ian On 2/23/18 11:33 AM, Aki Tuomi wrote: > The mailbox is too big. > > > > --- > Aki Tuomi >

hello, on the wiki, https://wiki2.dovecot.org/MailboxFormat/dbox, it says that one can use either doveadm fetch or doveadm import, however I can find no correct syntax with fetch that'll actually work. Is the idea to simply override the mail_location with -o ? That seems to work for doveadm mailbox but not for doveadm fetch or search # doveadm -f table mailbox status -u johan all dovecot

with dovecot --version 2.3.10.1 (a3d0e1171) exec of doveadm -v -o mail_fsync=never backup -R -f -u testuser at example.com imapc: currently fails, here, with Error: Mailbox INBOX sync: mailbox_delete failed: INBOX can't be deleted checking lists, this has been seen before @ https://dovecot.org/pipermail/dovecot/2016-January/102988.html On 24 Jan 2016, at 18:47, Timo Sirainen

Hi, I'm getting an assertion failed on the receiving side, causing syncs to fail for one user. The servers are setup so that only one is receiving any traffic other than replication at any time. The one that's only receiving replications is the one that's failing. I've tried deleting the user's home on the receiving server, but it still crashes during the sync. Oddly, the

https://dovecot.org/releases/2.2/rc/dovecot-2.2.30.rc1.tar.gz https://dovecot.org/releases/2.2/rc/dovecot-2.2.30.rc1.tar.gz.sig There are a couple of changes still coming, but now would be a good time to make sure anything unexpected hasn't broken. The final release should be out early next week. * auth: Use timing safe comparisons for everything related to passwords. It's unlikely

https://dovecot.org/releases/2.2/rc/dovecot-2.2.30.rc1.tar.gz https://dovecot.org/releases/2.2/rc/dovecot-2.2.30.rc1.tar.gz.sig There are a couple of changes still coming, but now would be a good time to make sure anything unexpected hasn't broken. The final release should be out early next week. * auth: Use timing safe comparisons for everything related to passwords. It's unlikely

> On 10 Aug 2019, at 3.15, @lbutlr via dovecot <dovecot at dovecot.org> wrote: > > On 8 Aug 2019, at 13:03, Amir Caspi <cepheid at 3phase.com> wrote: >> IMHO the setting should apply regardless of protocol, but is that actually the case in practice? > > It seems to be broken. > > I have > > namespace inbox { > inbox = yes > location = >

> On 23 Dec 2019, at 11.57, Philip Colmer <philip.colmer at linaro.org> wrote: > > I'm trying to diagnose a really strange situation where certain emails, when submitted to the mailbox by Postfix, are not considered to be unseen by Dovecot. > > During testing, I've shut down anything else on the server that might want to access the mailbox. I submit the email to the

On 30 May 2017 at 21:16, Timo Sirainen <tss at iki.fi> wrote: > https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz > https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz.sig > > * auth: Use timing safe comparisons for everything related to > passwords. It's unlikely that these could have been used for > practical attacks, especially because Dovecot delays

I'm trying to diagnose a really strange situation where certain emails, when submitted to the mailbox by Postfix, are not considered to be unseen by Dovecot. During testing, I've shut down anything else on the server that might want to access the mailbox. I submit the email to the local postfix instance which then says it has delivered it to the mailbox: Dec 23 09:51:35 ip-10-35-194-108

https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz.sig * auth: Use timing safe comparisons for everything related to passwords. It's unlikely that these could have been used for practical attacks, especially because Dovecot delays and flushes all failed authentications in 2 second intervals. Also it could have worked only

https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz.sig * auth: Use timing safe comparisons for everything related to passwords. It's unlikely that these could have been used for practical attacks, especially because Dovecot delays and flushes all failed authentications in 2 second intervals. Also it could have worked only