- dovecot - dovecot.org

Core dump at imap process
by Dominik Breu 16 May '15

16 May '15

hello list, testing the 2.18 release i got following core dump. Maybe Timo you can get a look at it. greetings dominik Core Dump: root@hbs-buko:/var/vmail/hbs-buko.info/dominik.breu# gdb /usr/lib/dovecot/imap core GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/dovecot/imap...Reading symbols from /usr/lib/debug//usr/lib/dovecot/imap...done. done. [New LWP 4069] Core was generated by `dovecot/imap'. Program terminated with signal SIGSEGV, Segmentation fault. #0 imap_msgpart_contains_body (msgpart=0x0) at imap-msgpart.c:311 311 imap-msgpart.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt full #0 imap_msgpart_contains_body (msgpart=0x0) at imap-msgpart.c:311 No locals. #1 0x00007f4eba177054 in fetch_state_update_stats (msgpart=<optimized out>, ctx=0x7f4ebacfa910, ctx=0x7f4ebacfa910) at imap-fetch-body.c:169 No locals. #2 0x00007f4eba17747b in fetch_rfc822_header (ctx=0x7f4ebacfa910, mail=0x7f4ebad08a10, context=<optimized out>) at imap-fetch-body.c:529 msgpart = 0x0 str = <optimized out> #3 0x00007f4eba1754cc in imap_fetch_more_int (ctx=ctx@entry=0x7f4ebacfa910, cancel=false) at imap-fetch.c:506 h = <optimized out> _data_stack_cur_id = 4 state = 0x7f4ebacfa960 client = 0x7f4ebacf9bb0 count = <optimized out> ret = <optimized out> __FUNCTION__ = "imap_fetch_more_int" #4 0x00007f4eba1765ca in imap_fetch_more (ctx=0x7f4ebacfa910, cmd=cmd@entry=0x7f4ebacfa7b0) at imap-fetch.c:558 ret = <optimized out> __FUNCTION__ = "imap_fetch_more" #5 0x00007f4eba169864 in cmd_fetch (cmd=0x7f4ebacfa7b0) at cmd-fetch.c:286 client = <optimized out> ctx = 0x7f4ebacfa910 args = 0x7f4ebace2b08 next_arg = <optimized out> list_arg = 0x7f4ebad03b50 search_args = 0x0 qresync_args = {qresync_sample_seqset = 0x7f4ebacd71f8, qresync_sample_uidset = 0x1} messageset = 0x7f4ebace2c70 "353" send_vanished = <optimized out> ret = <optimized out> #6 0x00007f4eba173cbc in command_exec (cmd=cmd@entry=0x7f4ebacfa7b0) at imap-commands.c:167 hook = 0x7f4ebace00f0 diff = <optimized out> finished = <optimized out> #7 0x00007f4eba172b32 in client_command_input (cmd=0x7f4ebacfa7b0) at imap-client.c:828 client = 0x7f4ebacf9bb0 command = <optimized out> __FUNCTION__ = "client_command_input" #8 0x00007f4eba172f2d in client_handle_next_command (remove_io_r=<synthetic pointer>, client=0x7f4ebacf9bb0) at imap-client.c:926 No locals. #9 client_handle_input (client=0x7f4ebacf9bb0) at imap-client.c:938 _data_stack_cur_id = 3 remove_io = false handled_commands = false client = 0x7f4ebacf9bb0 #10 0x00007f4eba1732f5 in client_input (client=0x7f4ebacf9bb0) at imap-client.c:980 cmd = 0xea880 output = 0x7f4ebacfa5d0 bytes = 2 __FUNCTION__ = "client_input" #11 0x00007f4eb99a2b6c in io_loop_call_io (io=0x7f4ebacfa6c0) at ioloop.c:501 ioloop = 0x7f4ebacdf740 t_id = 2 __FUNCTION__ = "io_loop_call_io" ---Type <return> to continue, or q <return> to quit--- #12 0x00007f4eb99a3ba5 in io_loop_handler_run_internal (ioloop=ioloop@entry=0x7f4ebacdf740) at ioloop-epoll.c:220 ctx = 0x7f4ebace0460 io = <optimized out> tv = {tv_sec = 1799, tv_usec = 999300} events_count = <optimized out> msecs = <optimized out> ret = 1 i = 0 j = <optimized out> call = <optimized out> __FUNCTION__ = "io_loop_handler_run_internal" #13 0x00007f4eb99a2bd9 in io_loop_handler_run (ioloop=ioloop@entry=0x7f4ebacdf740) at ioloop.c:548 No locals. #14 0x00007f4eb99a2c58 in io_loop_run (ioloop=0x7f4ebacdf740) at ioloop.c:525 __FUNCTION__ = "io_loop_run" #15 0x00007f4eb9941243 in master_service_run (service=0x7f4ebacdf5d0, callback=<optimized out>) at master-service.c:581 No locals. #16 0x00007f4eba16696c in main (argc=1, argv=0x7f4ebacdf390) at main.c:431 set_roots = {0x7f4eba38b940 <imap_setting_parser_info>, 0x0} login_set = {auth_socket_path = 0x7f4ebacd7048 "\001", postlogin_socket_path = 0x0, postlogin_timeout_secs = 60, callback = 0x7f4eba17ccc0 <login_client_connected>, failure_callback = 0x7f4eba17c930 <login_client_failed>, request_auth_token = 1} service_flags = <optimized out> storage_service_flags = <optimized out> username = 0x0 c = <optimized out>

2 2

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