similar to: mdbox, sis, zlib

It's apparent I have some level of corruption in my mailboxes - something to do with the combination of mdbox, sis, and zlib. I should note that I know I have a mix of compressed and raw messages - if that makes any difference in identifying the problems. I think I need to somehow regenerate the mailboxes with issues. Is there a suggestion for how to accomplish this? Should I perhaps use

Continuing to see errors on this with some new messages. Is it possible this has anything to do with zlib plugin, or possibly having a mix of zlib compressed & uncompressed messages with mdbox? I recently added zlib to deliver plugin list. -- Daniel L. Miller, VP - Engineering, SET AM Fire & Electronic Services, Inc. [AMFES] dmiller at amfes.com 702-312-5276

Why things happen is one of the great mysteries and joys of being a sysadmin... As for cleaning up SIS, I believe the "doveadm purge" command takes care of it. I have a daily cronjob which includes: #!/bin/sh # Permanently expunge old Trash doveadm expunge -A mailbox Trash savedbefore 2w # Optimize mdbox storage doveadm purge -A # Update fts indexes doveadm fts rescan -A -- Daniel

Is anyone currently using zlib with mdbox? Any issues? -- Daniel

You can use mdbox_deleted driver to access mails with refcount 0. See https://wiki2.dovecot.org/MailboxFormat/dbox Aki On 10.11.2020 12.42, Daniel Sch?tze wrote: > > Yesterday I had to recover an e-mail which a user had deleted.? If I > understand this correctly the message was expunged but not purged > (doveadm purge had not been run). > > This e-mail was clearly still in the

So with "fts_autoindex=yes" enabled in plugins, is there anything I should be running regularly, other than the expunge/purge, to ensure Solr indexes are updated? I have a daily Solr optimize, and Solr autocommit enabled. I have an hourly "doveadm index -A *" command - is that unneeded? -- Daniel On 4/12/2015 6:53 AM, Timo Sirainen wrote: > On 10 Apr 2015, at 21:55,

I've been running continous dsync backups of our Maildirs for a few weeks now, with the destination dsync server using mdbox and SIS. The idea was that the destination server would act as a warm copy of all our active users data. The active servers are using Maildir, and has: $ df -h /usr/local/atmail/users/ Filesystem Size Used Avail Use% Mounted on /dev/atmailusers

Yesterday I had to recover an e-mail which a user had deleted. If I understand this correctly the message was expunged but not purged (doveadm purge had not been run). This e-mail was clearly still in the mdbox stored with zlib compression as I could tell using the doveadm dump command (doveadm dump -t dbox filename). I could however not reveal the e-mail with the normal doveadm fetch -u

> On 10/11/2020 20:07 Daniel Sch?tze <dms at cwa.uk.com> wrote: > > > Dear Aki > Thank you. Unfortunately I'm struggling to get the right syntax for this as it looks like someone else was here too > https://dovecot.org/pipermail/dovecot/2018-July/112441.html > The location in my dovecot.conf is > >

Came across this in the logs... Nov 3 16:08:00 bubba dovecot: imap(dmiller at amfes.com): Error: Attachment file /var/mail/attachments/dc/73/dc7398c85dd02efe8a14fe6cc019b2cf07eec600-d5ca962aaae7d14c587400003bc41c5f size mismatch: 122626 != 165655 There's about a dozen different file entries listed in the error log. I'm using 2.0.6, mdbox, and the mails are stored on a local XFS

Trying to clean up the last of the corruption caused by my own stupidity. I now have two mailboxes for one user that give errors such as: doveadm(fax at amfes.com): Error: zlib.read(/var/mail/amfes.com/fax/mdbox/storage/m.9): gz trailer has wrong CRC value at 20065618 doveadm(fax at amfes.com): Error: read(/var/mail/amfes.com/fax/mdbox/storage/m.9) failed: Invalid argument (uid=238)

Having had a week with the system I'm now inclined to believe that the issues I've seen are not necessarily related to SIS and zlib but may be due to replication instead. After experiencing these issues and looking at historical mailing list posts I wrote a basic script (as was suggested as a possible diagnostic approach for SIS before SIS was even implemented!) which pulled all the

Hello: In case it is defined to use zlib compression, does SIS save attachments compressed? I have found this question replied in the past (2012) and the answer was NO. I ask again just to know if there have been changes or if it is in the roadmap to add compression. I have been testing to migrate from maildir+zlib to mdbox+zlib+sis and the results, in terms of space used, and worst than

Getting some errors like: Feb 26 12:19:43 bubba dovecot: imap(dmiller at amfes.com): Error: read(attachments-connector(/var/mail/amfes.com/dmiller/mdbox/storage/m.7089)) failed: read(/var/mail/attachments/f6/f4/f6f4f3b882bf3488af632389d4aaba8adc332b12-60ab750a1aa4b554da1600009db5accb[base64:18 b/l]) failed:

That works for a one-time migration, or perhaps via a cron-job, but what I want is basically a constant one-way backup and it seems replication could do it more elegantly & efficiently. -- Daniel On 9/1/2018 11:14 PM, Aki Tuomi wrote: > You don't need to setup replication for that. See > https://wiki2.dovecot.org/Migration/MailFormat > > --- > Aki Tuomi > Dovecot oy

On 10 Apr 2015, at 21:55, Daniel Miller <dmiller at amfes.com> wrote: > > Why things happen is one of the great mysteries and joys of being a sysadmin... > > As for cleaning up SIS, I believe the "doveadm purge" command takes care of it. I have a daily cronjob which includes: > > #!/bin/sh > # Permanently expunge old Trash > doveadm expunge -A mailbox

Where I used to be able to access the server without incident, I can no longer receive mail on the mobile device. I'm seeing this in the server log: Nov 27 23:45:05 bubba dovecot: imap-login: Login: user=<dmiller at amfes.com>, method=PLAIN, rip=173.117.196.198, lip=192.168.0.72, mpid=17422, TLS Nov 27 23:45:07 bubba dovecot: imap(dmiller at amfes.com): Error: FETCH [1.2] for

Hi, i have setup with mail_attachment single instance store + replication + zlib and got this bug when i try to replicate one test mailbox: On master1 in mail.log: Apr 10 13:25:22 master1 dovecot: dsync-local(zzz at blabla666.sk): Error: read(/nfsmnt/mailnfs1/attachments1/6b/57/6b57ad34cf6c414662233d833a7801fde4e1cdcb-92b5052558774653a728000013e2b982[base64:18 b/l]) failed: Stream is larger than

My next bonehead maneuver - was more of the first! location = virtual:/var/mail/%%d/%%n/mdbox/mailboxes/virtual was adapted from my definition for my shared namespace. Which was intended to share OTHER users - which is why the '%%' prefixes are used. Changing to: location = virtual:/var/mail/%d/%n/mdbox/mailboxes/virtual Now I can actually view something! But I still have a

Ok... Now that I've got the niggling issues resolved, on to bigger and better things. I want to convert everyone from Maildir to dbox and enable SIS (our users use a lot of large attachments), and after some reading/googling, I think it may be better to use dsync instead of rsync for the actual migration after all since it will do this at the same time as the syncing. If I'm not