- dovecot - dovecot.org

[Dovecot] Squat indexing a Maildir of over 600 GB?
by John Wells 23 Jul '08

23 Jul '08

Guys, We have a very large maildir for email auditing purposes. It's currently at 600 GB and continues to grow. Can dovecot handle this with squat indexing, or am I out of my mind? Thanks! John

2 5

[Dovecot] openbsd macppc
by Scott Murman 23 Jul '08

23 Jul '08

i run my server (web, email, calendar, etc.) off a mac mini ppc. it's a beautiful thing for our modest needs (quiet, low power, stable), but i'm looking at switching it to a vanilla bsd. has anyone tried dovecot on an openbsd (or similar) install for macppc? -SM-

4 3

[Dovecot] 1.1.1-1 gotcha with Fedora Rawhide package
by Kenneth Porter 23 Jul '08

23 Jul '08

I just installed the Rawhide package on my CentOS 5 system. The one item that bit me is that the config file defaults to using interface "[::]" so it only listens on IPv6. (This is from a patch in the package that changes the upstream default of "*", so it only affects those using the Fedora package.) For those wanting to track the issue, here's the Bugzilla: <https://bugzilla.redhat.com/show_bug.cgi?id=453054> I rebuilt the package from the source RPM, to make sure it was "tuned" to the C5 distro. I got the source RPM here, from the Portland State mirror: <http://mirrors.cat.pdx.edu/fedora/linux/development/source/SRPMS/dovecot-1.…> Here's a full list of Rawhide mirrors: <http://mirrors.fedoraproject.org/publiclist/Fedora/development/> If you'd like to see all Red Hat bugs associated with dovecot, here's a suitable query: <https://bugzilla.redhat.com/buglist.cgi?component=dovecot>

4 6

[Dovecot] 1.0.14 -> 1.1.1: dovecot-uidlist errors
by Amitai Schlair 23 Jul '08

23 Jul '08

I've just updated from 1.0.14 to 1.1.1 (Maildirs). According to <URL:http://wiki.dovecot.org/Upgrading/1.1>, "dovecot-uidlist file is in a new format. The old format is automatically converted to new one." When I try to delete a message (which moves it to the IMAP Trash folder), I get the following looping sequence of errors until I cancel the delete operation in the mail client: ----- Jun 24 12:22:13 chicken-ac dovecot: IMAP(schmonz): fdatasync_path(/home/schmonz/Maildir/.Trash/cur) failed: Bad file descriptor Jun 24 12:22:13 chicken-ac dovecot: Panic: IMAP(schmonz): file maildir-uidlist.c: line 1217 (maildir_uidlist_sync_update): assertion failed: (ctx->first_unwritten_pos != (unsigned int)-1) Jun 24 12:22:13 chicken-ac dovecot: child 5170 (imap) killed with signal 6 Jun 24 12:22:14 chicken-ac dovecot: imap-login: Login: user=<schmonz>, method=PLAIN, rip=68.46.70.233, lip=160.39.240.17, TLS Jun 24 12:22:16 chicken-ac dovecot: IMAP(schmonz): fdatasync_path(/home/schmonz/Maildir/.Trash/cur) failed: Bad file descriptor Jun 24 12:22:16 chicken-ac dovecot: Panic: IMAP(schmonz): file maildir-uidlist.c: line 1217 (maildir_uidlist_sync_update): assertion failed: (ctx->first_unwritten_pos != (unsigned int)-1) Jun 24 12:22:16 chicken-ac dovecot: child 27601 (imap) killed with signal 6 Jun 24 12:22:17 chicken-ac dovecot: imap-login: Login: user=<schmonz>, method=PLAIN, rip=68.46.70.233, lip=160.39.240.17, TLS Jun 24 12:22:19 chicken-ac dovecot: IMAP(schmonz): fdatasync_path(/home/schmonz/Maildir/.Trash/cur) failed: Bad file descriptor Jun 24 12:22:19 chicken-ac dovecot: Panic: IMAP(schmonz): file maildir-uidlist.c: line 1217 (maildir_uidlist_sync_update): assertion failed: (ctx->first_unwritten_pos != (unsigned int)-1) Jun 24 12:22:19 chicken-ac dovecot: child 29637 (imap) killed with signal 6 Jun 24 12:22:20 chicken-ac dovecot: imap-login: Login: user=<schmonz>, method=PLAIN, rip=68.46.70.233, lip=160.39.240.17, TLS Jun 24 12:22:22 chicken-ac dovecot: IMAP(schmonz): fdatasync_path(/home/schmonz/Maildir/.Trash/cur) failed: Bad file descriptor Jun 24 12:22:22 chicken-ac dovecot: Panic: IMAP(schmonz): file maildir-uidlist.c: line 1217 (maildir_uidlist_sync_update): assertion failed: (ctx->first_unwritten_pos != (unsigned int)-1) Jun 24 12:22:22 chicken-ac dovecot: child 9143 (imap) killed with signal 6 Jun 24 12:22:22 chicken-ac dovecot: imap-login: Login: user=<schmonz>, method=PLAIN, rip=68.46.70.233, lip=160.39.240.17, TLS Jun 24 12:22:23 chicken-ac dovecot: IMAP(schmonz): Connection closed bytes=45/352132 Jun 24 12:24:23 chicken-ac dovecot: imap-login: Login: user=<schmonz>, method=PLAIN, rip=68.46.70.233, lip=160.39.240.17, TLS ----- Alternatively, sometimes I get an error dialog in the mail client: "The current command did not succeed. The mail server responded: BUG: Unknown internal error." Have I done something wrong? Can I provide more information to help narrow this down? Thanks, - Amitai

5 10

[Dovecot] Namespaces
by Jason Frisvold 22 Jul '08

22 Jul '08

Hi all, I'm working to convert from a bincIMAP setup to a Dovecot setup. I've tried messing around with namespaces to make the conversion transparent, but I'm getting nowhere. Are namespaces necessary? Or can I proceed by recursively renaming the folders on the server? A transparent solution would be wonderful, but I can't get it to work for me.. Any help would be appreciated. Thanks! -- Jason 'XenoPhage' Frisvold XenoPhage0(a)gmail.com http://blog.godshell.com

2 3

[Dovecot] Sieve plugin should recompile when symbolic link changes [patch]
by Frank Behrens 22 Jul '08

22 Jul '08

The sieve plugin compares the modification dates of sieve source and compiled script and compiles the script only if necessary. When the managesieve extension is used, it creates a symbolic link for the script. In order to switch between scripts managesieve changes the link only. Therefore the sieve plugin should include the modification date of an symlink in its decision about compilation. The attached patch adds this functionality. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.

2 2

[Dovecot] ACL in sub-folders (take two)
by Imobach González Sosa 22 Jul '08

22 Jul '08

Hi all, I've read this not on the v1.1.2 release candidate announce: > If you haven't received an answer to your question, resend it. So, I've sent this message some days ago and I've got no answer (that's fine, no problem). So, I'm posting my question again: I've set up some shared folders and I'm controlling the access to them with the ACL plugin. As far as I know, ACL rules are not applied to sub-folders, right? So, when a user adds a new sub-folder, I need to add a dovecot-acl file granting read permissions to others users, right? Does exists any way to implement it using some dovecot feature? Or must I find my way? Just to be sure :) Thank you in advance. -- Imobach González Sosa Banot.net http://www.banot.net/

3 3

[Dovecot] Permission problems
by M. Rodrigo Monteiro 22 Jul '08

22 Jul '08

Hello. This is the first time I'm using Dovecot... I'm using Debian Etch (updated), and all bundled (Postfix + OpenLDAP + Dovecot + SASL), and Jamm. This is the guide I'm using: http://wanderingbarque.com/howtos/mailserver/mailserver.html # dovecot --version 1.0.rc15 # tail -4 /etc/passwd cyrus:x:107:8:Cyrus Mailsystem User,,,:/var/spool/cyrus:/bin/sh vmail:x:1001:1001::/home/vmail:/bin/sh dovecot:x:108:109:Dovecot mail server,,,:/usr/lib/dovecot:/bin/false dovecot-auth:x:1002:1002::/usr/lib/dovecot:/bin/sh # tail -4 /etc/group postdrop:x:108: vmail:x:1001: dovecot:x:109: dovecot-auth:x:1002: # id dovecot uid=108(dovecot) gid=109(dovecot) grupos=109(dovecot) # id vmail uid=1001(vmail) gid=1001(vmail) grupos=1001(vmail) # dovecot -n # /etc/dovecot/dovecot.conf log_path: /var/log/dovecot.log info_log_path: /var/log/dovecot-info.log log_timestamp: %Y-%m-%d %H:%M:%S ssl_disable: yes disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login valid_chroot_dirs: /home/vmail/domains verbose_proctitle: yes first_valid_uid: 108 last_valid_uid: 108 first_valid_gid: 109 last_valid_gid: 109 mail_privileged_group: vmail mail_location: maildir:/home/vmail/domains/%d/%n auth default: user: dovecot-auth verbose: yes debug: yes debug_passwords: yes passdb: driver: ldap args: /etc/dovecot/dovecot-ldap.conf userdb: driver: ldap args: /etc/dovecot/dovecot-ldap.conf # grep -v '^ *$#.*$\?$' dovecot-ldap.conf hosts = localhost dn = cn=dovecot,dc=XXXXXX,dc=ce,dc=gov,dc=br dnpass = XXXXXX ldap_version = 3 base = o=hosting,dc=XXXXX,dc=ce,dc=gov,dc=br deref = never scope = subtree user_attrs = mail,homeDirectory,,,, user_filter = (&(objectClass=JammMailAccount)(mail=%u)(accountActive=TRUE)(delete=FALSE)) pass_attrs = mail,userPassword pass_filter = (&(objectClass=JammMailAccount)(mail=%u)(accountActive=TRUE)(delete=FALSE)) default_pass_scheme = CRYPT user_global_uid = 108 user_global_gid = 109 # testsaslauthd -u rodrigo2(a)XXXXXX.ce.gov.br -p XXXXXX 0: OK "Success." Here is tha Dovecot log: dovecot: 2008-07-17 11:31:30 Error: Logins with login process UID 108 (user rodrigo2(a)XXXXXX.ce.gov.br) not permitted (see login_user in config file). dovecot: 2008-07-17 11:31:30 Error: IMAP(rodrigo2(a)XXXXXX.ce.gov.br): mkdir(/home/vmail/domains/XXXXXX.ce.gov.br/rodrigo2/.Trash) failed: Permission denied dovecot: 2008-07-17 11:31:33 Error: IMAP(rodrigo2(a)XXXXXX.ce.gov.br): mkdir(/home/vmail/domains/XXXXXX.ce.gov.br/rodrigo2/.Trash) failed: Permission denied dovecot: 2008-07-17 11:31:34 Error: Logins with login process UID 108 (user rodrigo2(a)XXXXXX.ce.gov.br) not permitted (see login_user in config file). dovecot: 2008-07-17 11:31:34 Error: IMAP(rodrigo2(a)XXXXXX.ce.gov.br): file_dotlock_open() failed with file /home/vmail/domains/ XXXXXX.ce.gov.br/rodrigo2/dovecot.index.log: Permission denied dovecot: 2008-07-17 11:31:34 Error: IMAP(rodrigo2(a)XXXXXX.ce.gov.br): file_dotlock_open() failed with file /home/vmail/domains/ XXXXXX.ce.gov.br/rodrigo2/dovecot.index.log: Permission denied As it says in the guide, I create the dir (domain/user - XXXXX.ce.gov.br/rodrigo2) and send an "greeting" e-mail for the creation of directories. Then I can login to the account, but can't retrieve mail from them. Can anyone help me? Regards, Rodrigo. ps: sorry about my english. -- M. Rodrigo Monteiro falecom(a)rodrigomonteiro.net "Free as in Freedom, not free as in free beer" Linux User # 403730

4 9

[Dovecot] Dovecot LDA with Postfix - question?
by kbajwa 22 Jul '08

22 Jul '08

Hello: CentOS 5.2 Postfix 2.3.3 (part of CentOS install) Dovecot 1.0.7 (part of CentOS install) Dovecot 1.1.1 (Updated from www.atrpms.net) Postfix & Dovecot are working fine. While reading "Dovecot LDA with Postfix" document at http://wiki.dovecot.org/LDA/Postfix , I read the following statement: --------------------- Dovecot LDA with Postfix System users If you wish you use deliver for all system users on a single domain mail host you can do it by editing mailbox_command parameter in /etc/postfix/main.cf (postconf(5)): mailbox_command = /usr/local/libexec/dovecot/deliver # or mailbox_command = /usr/libexec/dovecot/deliver # or mailbox_command = /usr/lib/dovecot/deliver # or wherever it was installed in your system. Then run postfix reload and that is it. --------------------- Here is the problem; I do not find location of ".../dovecot/deliver" anywhere on the system! 1. Did I do any mistake during the Postfix and/or Dovecot install/configuration? 2. Next, I plan to install "Dovecot-Sieve". Do I need the "mailbox_command" for "Dovecot-Sieve" to work? Kirti

2 1

[Dovecot] A couple of dovecot issues I've noted recently...
by Dan Price 21 Jul '08

21 Jul '08

Timo et al., I haven't been reading the list in a while, but wanted to report back that we've transitioned to dovecot 1.0.15 and things look to be working very nicely. The platform is Solaris "Nevada" running on x86. I have been saving up a couple of issues to bring to your attention. On our server, we gather all core files, and so we get a good taste of the different things which are causing crashes. One problem which we see on an occasional basis is a crash in which the internal fatal error handling code goes horribly wrong. Here is an example. The complete stack trace is hugely long-- it appears that we recurse until we run totally out of stack. In gdb this looks like repeated calls like this: ... #14507 0x080b22b6 in i_internal_fatal_handler (status=83, fmt=0x0, args=0x76b95d8 "\020") at failures.c:410 #14508 0x080b1e1e in i_fatal_status (status=83, format=0x80cdd64 "mem_block_alloc(): Out of memory when allocating %u bytes") at failures.c:201 #14509 0x080b1652 in mem_block_alloc (min_size=0) at data-stack.c:192 #14510 0x080b1811 in t_malloc_real (size=16, permanent=true) at data-stack.c:244 #14511 0x080b1890 in t_malloc0 (size=16) at data-stack.c:279 #14512 0x080b8715 in pool_datastack_create () at mempool-datastack.c:51 #14513 0x080bda2b in t_str_new (initial_size=512) at str.c:17 #14514 0x080b21f3 in internal_handler (log_type=70 'F', format=0x80cdd64 "mem_block_alloc(): Out of memory when allocating %u bytes", args=0x76b96d8 "\020") at failures.c:383 #14515 0x080b22b6 in i_internal_fatal_handler (status=83, fmt=0x0, args=0x76b96d8 "\020") at failures.c:410 #14516 0x080b1e1e in i_fatal_status (status=83, format=0x80cdd64 "mem_block_alloc(): Out of memory when allocating %u bytes") at failures.c:201 #14517 0x080b1652 in mem_block_alloc (min_size=0) at data-stack.c:192 #14518 0x080b1811 in t_malloc_real (size=16, permanent=true) at data-stack.c:244 #14519 0x080b1890 in t_malloc0 (size=16) at data-stack.c:279 #14520 0x080b8715 in pool_datastack_create () at mempool-datastack.c:51 #14521 0x080bda2b in t_str_new (initial_size=512) at str.c:17 #14522 0x080b21f3 in internal_handler (log_type=70 'F', format=0x80cdd64 "mem_block_alloc(): Out of memory when allocating %u bytes", args=0x76b97d8 "\020") at failures.c:383 #14523 0x080b22b6 in i_internal_fatal_handler (status=83, fmt=0x0, args=0x76b97d8 "\020") at failures.c:410 #14524 0x080b1e1e in i_fatal_status (status=83, format=0x80cdd64 "mem_block_alloc(): Out of memory when allocating %u bytes") at failures.c:201 #14525 0x080b1652 in mem_block_alloc (min_size=0) at data-stack.c:192 #14526 0x080b1811 in t_malloc_real (size=16, permanent=true) at data-stack.c:244 #14527 0x080b1890 in t_malloc0 (size=16) at data-stack.c:279 #14528 0x080b8715 in pool_datastack_create () at mempool-datastack.c:51 #14529 0x080bda2b in t_str_new (initial_size=512) at str.c:17 #14530 0x080b21f3 in internal_handler (log_type=70 'F', format=0x80cdd64 "mem_block_alloc(): Out of memory when allocating %u bytes", args=0x76b98d8 "\020") at failures.c:383 #14531 0x080b22b6 in i_internal_fatal_handler (status=83, fmt=0x0, args=0x76b98d8 "\020") at failures.c:410 #14532 0x080b1e1e in i_fatal_status (status=83, format=0x80cdd64 "mem_block_alloc(): Out of memory when allocating %u bytes") at failures.c:201 #14533 0x080b1652 in mem_block_alloc (min_size=0) at data-stack.c:192 #14534 0x080b1811 in t_malloc_real (size=16, permanent=true) at data-stack.c:244 #14535 0x080b1890 in t_malloc0 (size=16) at data-stack.c:279 #14536 0x080b8715 in pool_datastack_create () at mempool-datastack.c:51 #14537 0x080bda2b in t_str_new (initial_size=512) at str.c:17 #14538 0x080b21f3 in internal_handler (log_type=70 'F', ... At the top of the stack, I see this-- unfortunately I can't use gdb to view it-- it core dumps after about 50,000 frames. In dbx: [327610] i_internal_fatal_handler(status = 83, fmt = (nil), args = 0x8047798 "^P"), line 410 in "failures.c" [327611] i_fatal_status(status = 83, format = 0x80cdd64 "mem_block_alloc(): Out of memory when allocating %u bytes", ...), line 201 in "failures.c" [327612] mem_block_alloc(min_size = 134510504U), line 192 in "data-stack.c" [327613] t_malloc_real(size = 0, permanent = 0), line 244 in "data-stack.c" [327614] t_buffer_get(size = 0), line 319 in "data-stack.c" [327615] _vstrconcat(str1 = (nil), args = 0x8047834 "\x9d?^L^H", ret_len = 0x8047808), line 229 in "strfuncs.c" [327616] t_strconcat(str1 = 0x100e77f0 "tmp/compiler/venus/handoff/build20.2/CDROM/sol-x86/kits/j2sdk_1.4.2_08/patches/J2SE_Solaris_8_x86_Recommended/108994-44/SUNWcsr/.svn/prop-base", ...), line 335 in "strfuncs.c" [327617] mbox_list_next(ctx = 0x80f6348), line 273 in "mbox-list.c" [327618] mbox_mailbox_list_next(_ctx = 0x8047928), line 209 in "mbox-list.c" [327619] mail_storage_mailbox_list_next(ctx = 0x8047948), line 317 in "mail-storage.c" [327620] cmd_list_continue(cmd = 0x80eff2c), line 184 in "cmd-list.c" [327621] client_destroy(client = (nil), reason = 0x80479d8 "Ã¸y^D^HcÂ±^F^HÃ¨Ã¾^N^HÃx^L^H^Hz^D^HmÂ¨^K^H^P\x8b^N^H^B"), line 94 in "client.c" [327622] idle_timeout(context = (nil)), line 522 in "client.c" [327623] io_loop_handle_timeouts(ioloop = (nil), update_run_now = 1U), line 294 in "ioloop.c" [327624] io_loop_handler_run(ioloop = 0x80ed6e0), line 159 in "ioloop-poll.c" [327625] io_loop_run(ioloop = (nil)), line 329 in "ioloop.c" [327626] main(argc = 1, argv = 0x8047afc, envp = 0x8047b04), line 290 in "main.c" I wondered if anyone else has seen similar problems? It seems like once we fall into i_internal_fatal_handler(), dovecot should really try hard to avoid further dynamic memory allocation, as heap corruption seems to make that a bit of a disaster. As for the crash in mbox_list_next, we see that one too with some frequency. A final problem, and this one affects me personally, is that we see some errors like this: dovecot: Jul 09 11:52:10 Error: IMAP(dp): FETCH for mailbox mail/tmp-inbox UID 92086 got too little data: 6054 vs 6057 dovecot: Jul 09 11:52:10 Info: IMAP(dp): Disconnected: Disconnected This is frustrating because I wind up with "poisonous" messages in my inbox which cause dovecot to disconnect me when I try to read them. Across all of our users, we see this happen about 1000 times per month. -dp -- Daniel Price - Solaris Kernel Engineering - dp(a)eng.sun.com - blogs.sun.com/dp

2 3