May 2015 - dovecot - dovecot.org

Dovecot Replication - Architecture Endianness?
by Reuben Farrelly 16 May '15

16 May '15

Hi all, I've had an interesting use case come up which - to cut the story short - one way to solve the problem I am looking at may be to replicate a small number of mailboxes to a third remote server. I've currently had replication running between my main dovecot machine and another remote VM for some time and working well (so I'm not new to replication and I've got a good working config), but I've a need to add a third to the mix for a select number of mailboxes. The arch on both of those is Gentoo x86_64 and with latest 2.1.16 -hg. I have attempted this so far by rsync'ing the initial Maildirs and then once the bulk of the data has been transferred rely on dovecot's replication to keep things in sync. I figure that this should in theory mean that the subsequent updates in both directions are incremental and the bulk of the data gets moved while the device is here on my desk using rsync. I've attempted to do this using a Raspberry Pi as a remote device, but when I set it up the dovecot replication process seems to need to start the replication over from scratch even after the rsync is done. I know this is happening as the disk utilisation on the Pi skyrockets once the replication starts and I end up with thousands of double ups of all the mails ... which defeats the entire point of the process. If I do an identical configuration but on a third Gentoo x86_64 VM locally it all works as expected. No double ups of mails and the "catchup" between the two devices is practically instant. Same filesystem even. The only difference appears to be the system architecture. So main my question is this. Is there a known architecture/endian limitation on replication? I guess cross-arch replication is not something many people try but is it supposed to work anyway? Has anyone else got replication working across different arch's? Also is there a way to restrict replication users aside from a crude hack around system first and last UIDs? Thanks, Reuben

3 10

Re: imap_logout_format improvements
by Joseph Tam 16 May '15

16 May '15

Timo Sirainen wrote: > So all in all, you can now add to imap_logout_format: >... > Any thoughts on what else would be useful? Maybe quota stats like number of quota errors, or quota usage? Bytes used by Email marked \Deleted? Joseph Tam <jtam.home(a)gmail.com>

2 1

Re: [Dovecot] IMAP and POP3 operations log per user
by Miloš Dukić 16 May '15

16 May '15

On 05/14/15 23:49, Jorge Bastos wrote: > Hi, > > > > I'd like to have a log per user, and protocol (imap+pop3), where this log > would tell me/save the message sender+subject+operation (deleted, marked to > expunge/other/was read/other). > > Is there something similar to this that already exists? > > > > If not is there something like this on the TODO/whishlist? > > > > Thanks in advanced, > > Jorge Bastos > . > Jorge, Per user loggin is not available. You can enable Dovecot events in 10-logging.conf. Just uncomment mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename in plugin section. Depending on your setup, it will be logged to /var/log/maillog, or whatever you defined in your syslog configuration.

1 0

Released Pigeonhole v0.4.8 for Dovecot v2.2.18
by Stephan Bosch 15 May '15

15 May '15

Hello Dovecot users, Here is the final 0.4.8 release. No significant changes were committed since the last release candidate. Changelog v0.4.8: * LDA Sieve plugin: Dovecot changed the deliver_log_format setting to include %{delivery_time}. This prompted changes in Pigeonhole that make this release dependent on Dovecot v2.2.17. + Implemented magic to make sieve_default script visible from ManageSieve under a configurable name. This way, users can see the default rules, edit them and store a private adjusted version. This could also be achieved by copying the default script into the user's script storage, but updates to the global sieve_default script would be ignored that way. + ManageSieve: Implemented support for reporting command statistics at disconnect. Statistics include the number of bytes and scripts uploaded/downloaded/checked and the number of scripts deleted/renamed. - Fixed problem in address test: erroneously decoded mime-encoded words in address headers. - extprograms plugin: Fixed failure occurring when connecting to script service without the need to read back the output from the external program. - Fixed bug in script storage path normalization occurring with relative symbolic links below root. - Fixed and updated various parts of the documentation - ManageSieve: Used "managesieve" rather than "sieve" as login service name, which means that all managesieve-specific settings where ignored. - Managesieve: Storage quota was not always enforced properly for scripts uploaded as quoted string. Nobody uses that, but it is allowed in the specification and we support it, so it should work properly. The release is available as follows: http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.8.tar… http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.8.tar… Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for more information. Have fun testing this new release and don't hesitate to notify me when there are any problems. Regards, -- Stephan Bosch stephan(a)rename-it.nl

1 0

Many Duplicated messages after migrate from 2.0.19 to 2.2.15
by Listas＠Adminlinux 15 May '15

15 May '15

Hi, In my company, we have several failover clusters (~50k accounts per cluster) with Ubuntu12.04 and Dovecot-2.0.19 (without dsync, replication at block level with DRBD). We are migrating to active/active clusters with Ubuntu14.04 and Dovecot-2.2.15 with replication via dovecot-dsync. Each new cluster consists of two machines and each machine runs two instances of Dovecot (one for backend and the other for proxy Dovecot-director). We did the migration of message files, indexes and sieve scripts using rsync to one of the backends. After we turn on the second backend and let the dsync work in replication for him. Now, many accounts are with duplicated messages and some new emails delivered are also being duplicated. Doveadm deduplicate doesn't work for me. I ran: doveadm deduplicate -u <user> -m ALL Does do the migration of files with rsync was a mistake ? We are using mdbox on both clusters. My confs with doveconf -n for both clusters: http://www.adminlinux.com.br/newcluster_doveconf.txt http://www.adminlinux.com.br/oldcluster_doveconf.txt Thanks and regards, Thiago Henrique

1 0

v2.2.18 released
by Timo Sirainen 15 May '15

15 May '15

http://dovecot.org/releases/2.2/dovecot-2.2.18.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.18.tar.gz.sig Oops, director was somewhat broken in 2.2.17. I thought I tested the last changes in it well enough, but looks like not. To avoid all existing Dovecot director installations from breaking I decided to make 2.2.18 release quickly afterwards.. BTW. We're planning on making some changes soon to how version control is used in Dovecot development, which should help avoid these kind of problems. The main problem now is that everything gets directly committed to the master branch (although we have a separate more stable dovecot-ee repo also). The new plan is to do something like this: http://nvie.com/posts/a-successful-git-branching-model/ Besides some minor compiling issues and other small changes, the important ones are: - director: Login UNIX sockets were normally detected as doveadm or director ring sockets, causing it to break in existing installations. - sdbox: When copying a mail in alt storage, place the destination to alt storage as well.

3 2

Best practice for getting sieve scripts replicated?
by Michael Grimm 15 May '15

15 May '15

Hi — I do have replication between two servers running, and mail is replicated without any issues. I do have sieve running at both servers without any issues. But replication of sieve scripts doesn't work as "expected": Whenever I do modify my default script und upload it via "doveadm sieve put -u abc -a default < default" it becomes uploaded to the home directory of user abc as expected, but it will not be replicated to the partner server. Whenever I do deactivate the default script by "doveadm sieve deactivate -u abc", followed by a deletion "doveadm sieve delete -u abc default" plus subsequent upload of the script "doveadm sieve put -u abc -a default < default", replication takes place instantly. Questions: Is a modification of a sieve script supposed to be triggered the latter way? Or am I doing it the wrong way? Thanks and regards, Michael

2 5

Alternate Storage altmove not working bug
by Daniel van Ham Colchete 15 May '15

15 May '15

Hello everyone! I would like to report a bug here. We are using dovecot's sdbox with alternate storage here. From time to time my SSD partition gets full and I always find users with lots of e-mails stuck there, and altmove just won't move them. It moves most of the e-mails correctly, but a few was getting stuck everyday. So, I think I have found the problem! When a user moves the message from one mailbox to another, the move will keep all the flags! Including MAIL_INDEX_MAIL_FLAG_BACKEND 0x40. So, altmove think this message was already moved and doesn't do anything. I did a doveadm dump on the destination mailbox's index and what I see is a lot of this: RECORD: seq=104, uid=104, flags=0x48 (Seen) - ext 0 keywords : (0000) - ext 1 modseq : 12 (0c00000000000000) - ext 3 cache : 14004 (b4360000) - cache offset=14004 size=76, prev_offset = 0 - mime.parts: (48000000b404000000000000cc04000000000000e542000000000000fd4300000000000018010000) (pos=0 hdr.p=1204 hdr.v=1228 body.p=17125 body.v=17405 flags=48) - size.physical: 18329 (9947000000000000) - date.received: 1418235366 (e68d8854) Although the 0x40 flag is set, the file still lives on the main/ssd storage area. My config: http://pastebin.com/8Wk4bfRK Dovecot version: 2.2.5-0~auto+22 Host is Xeon E3 64bit, running Debian 7. Filesystem is plain local ext4 on both storage areas I know my version is outdated but I didn't find anything related to this there. Just one last question: how can I remove that flag from the message? I have taken a look at doveadm-flags(1) but it doesn't seem to allow anything on that flag. Thank you very much! Best, Daniel Colchete

2 2

Return code 139 when enabling auth debugging
by Stefan Midjich 15 May '15

15 May '15

Hi I'm running dovecot 2.2.10 installed from base repos on CentOS 7. I'm trying to use sqlite as an auth backend but it's not working so I enabled some auth debugging settings in conf.d/10-logging.conf and then dovecot refused to start. sudo dovecot -F produced 139. Here is doveconf -n: http://dpaste.com/2BNB2F7 Unfortunately when I have these settings enabled doveconf does not work and only produces the first comment line. So here is the output of sudo grep -v '^#' /etc/dovecot/conf.d/10-logging.conf | grep -v '^$': http://dpaste.com/0G0VVK8 And when these settings are uncommented dovecot -F produces return code 139 and no output. So I'm having a hard time troubleshooting my authentication when I can't even troubleshoot my debug options not working. ;) -- Hälsningar / Greetings http://Stefan.Midjich.name

1 0

Re: [Dovecot] IMAP and POP3 operations log per user
by Steffen Kaiser 15 May '15

15 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 14 May 2015, Jorge Bastos wrote: > I'd like to have a log per user, and protocol (imap+pop3), where this log > would tell me/save the message sender+subject+operation (deleted, marked to > expunge/other/was read/other). > Is there something similar to this that already exists? Check out the mail_log plugin. You'll have to break the logfiles by users via script. - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVVWSGHz1H7kL/d9rAQLIzAf/ZtNOLa1n12LnxwhMaS1B+6LEHDOCZWtw ldTarGE0uovu/OH84PEq4MkE5Y1Oww+VWmA+b2csBx1C0bZmcQeF2g7O65fESYsI Qu/xSuJLhOyUm4sppE62Zqyxba+rG2tyj9XpKMrHI6nU3ZTCOhVu/RJ2TB2WkhkB 21pgYEpkBYvRZK2PPqRwl+Lwc3oGQvWoYHcyniXL0v2P5tNNQj1gTuGVm53dPliM cFm9p4EjAOKEZyFgQokBljDpp03OMpEu16GT8XjCg8Fxg2BkF2XHBx/Wvv8DxQCC vyLA1SFMLNNRoizwF+xVlUJu4AW8fWBLhCgvOAFw4mFXkbMoi+lUwQ== =vRwJ -----END PGP SIGNATURE-----

1 0