- dovecot - dovecot.org

[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

[Dovecot] Deliver mail as 'read'?
by Peter Collinson 21 Jul '08

21 Jul '08

I'd like to be able to deliver certain mail as 'read' from procmail. My procmail rules call deliver with -m to directly to inject filtered mail to maildir based directories. I like to keep copies of mail I've sent by cc'ing it to myself and using procmail to filter and store copies in the appropriate directory. I cannot seem to find a way of delivering cc'd mail from me to me as 'read'. I'm running dovecot-1.0.7-2.el5 on a CentOS 5 distribution. Any hints on how I may achieve this are welcomed. Happy to upgrade if needs be. Thanks. _____________________________________________ Peter Collinson

4 5

[Dovecot] The case of the disappearing INBOX's - upgrade to 1.1.1 from 1.0.7 and based on Email client type
by Jack Stewart 21 Jul '08

21 Jul '08

Hi, I apologize if this has already been answered. I looked for an identical message but had no luck. I'm also not convinced this is a bug or if it is a bug that I want it fixed. The problem gives me a great reason to change our configuration to something more modern. Here is the situation. Our 1.0.7 configuration has the following, and only, namespace definition. namespace private { separator = . prefix = Mail. inbox = yes } This configuration was implemented years ago in order to simplify the upgrade from mail spool to IMAP for people who use mutt and pine. The interesting part is that after upgrading to 1.1.1, the INBOX would disappear from Thunderbird after clicking on a different folder. Now mutt worked just fine, which was even worse. Changing the configuration so that the INBOX appeared on Thunderbird caused the INBOX to disappear (or be unreachable) on mutt. After trying multiple configurations with every permutation, and making several wall dents with my forehead, I finally found this configuration. namespace private { separator = . prefix = INBOX. inbox = yes hidden = no list = yes } namespace private { separator = . prefix = Mail. hidden = yes list = no } For the most part, this works just fine. INBOX appears for every client I've tested and the migration is largely transparent. The only time I found issues is when the Trash, Sent, etc. folders were manually specified in a GUI client such as Thunderbird. Still the real question remains. Is this supposed to happen? If so, what are some of the reasons? Naturally my management would prefer that the original configuration works the same so that things are transparent. Personally, the second configuration feels better to me especially on a going forward basis. Thanks in advance for any answers or hints. ---Jack -- Jack Stewart jstewart(a)caltech.edu http://www.imss.caltech.edu

2 2

[Dovecot] No password in reply
by M. Rodrigo Monteiro 21 Jul '08

21 Jul '08

Found http://www.mailinglistarchive.com/dovecot@dovecot.org/msg03185.html, but I don't think this is my problem because using ldapsearch I can search using dovecot. # /usr/local/openldap/bin/ldapsearch -x -h localhost -b DC=XXXXX,DC=ce,DC=gov,DC=br -D cn=dovecot,dc=XXXXX,dc=ce,dc=gov,dc=br -w XXXXX -LLL -z 0 -E pr=100/noprompt dn: mail=rodrigo(a)XXXXX.ce.gov.br,jvd=XXXXX.ce.gov.br ,o=mail,dc=XXXXX,dc=ce,dc=gov,dc=br objectClass: top objectClass: JammMailAccount mail: rodrigo(a)XXXXX.ce.gov.br mailbox: XXXXX.ce.gov.br/rodrigo/ homeDirectory: /home/vmail/domains userPassword:: e0NSWVBUfVlaSlpOa0JrMzgxZ2c= cn: M. Rodrigo Monteiro accountActive: TRUE lastChange: 1216410148 delete: FALSE My confs are: 0# /usr/local/dovecot/sbin/dovecot -n # 1.1.1: /usr/local/dovecot/etc/dovecot.conf log_path: /var/log/dovecot.log info_log_path: /var/log/dovecot-info.log ssl_disable: yes disable_plaintext_auth: no login_dir: /usr/local/dovecot/var/run/dovecot/login login_executable: /usr/local/dovecot/libexec/dovecot/imap-login valid_chroot_dirs: /home/vmail/domains first_valid_uid: 200 last_valid_uid: 200 first_valid_gid: 200 last_valid_gid: 200 mail_location: maildir:/home/vmail/domains/%d/%n auth default: user: dovecot-auth verbose: yes debug: yes debug_passwords: yes passdb: driver: ldap args: /usr/local/dovecot/etc/dovecot-ldap.conf userdb: driver: ldap args: /usr/local/dovecot/etc/dovecot-ldap.conf # grep -v '^ *$#.*$\?$' /usr/local/dovecot/etc/dovecot-ldap.conf hosts = localhost dn = cn=dovecot,dc=XXXXX,dc=ce,dc=gov,dc=br dnpass = XXXXXXXXXXX ldap_version = 3 base = o=mail, 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 # cat dovecot-info.log dovecot: Jul 21 10:04:51 Info: auth(default): client in: AUTH 1 PLAIN service=imap lip=XXX.XXX.XXX.43 rip=XXX.XXX.XXX.55 lport=143 rport=2320 dovecot: Jul 21 10:04:51 Info: auth(default): client out: CONT 1 dovecot: Jul 21 10:04:51 Info: auth(default): client in: CONT 1 AHJvZHJpZ29Ac2VkdWMuY2UuZ292LmJyAHRlc3Rl dovecot: Jul 21 10:04:51 Info: auth(default): ldap(rodrigo(a)XXXXX.ce.gov.br,XXX.XXX.XXX.55): pass search: base=o=mail, dc=XXXXX, dc=ce, dc=gov, dc=br scope=subtree filter=(&(objectClass=JammMailAccount)(mail=rodrigo(a)XXXXX.ce.gov.br)(accountActive=TRUE)(delete=FALSE)) fields=mail,userPassword dovecot: Jul 21 10:04:51 Info: auth(default): ldap(rodrigo(a)XXXXX.ce.gov.br,XXX.XXX.XXX.55): result: mail(mail)=rodrigo(a)XXXXX.ce.gov.bruserPassword(userPassword)={CRYPT}YZJZNkBk381gg dovecot: Jul 21 10:04:53 Info: auth(default): client out: FAIL 1 user=rodrigo(a)XXXXX.ce.gov.br temp mail=rodrigo(a)XXXXX.ce.gov.bruserPassword={CRYPT}YZJZNkBk381gg # cat dovecot.log dovecot: Jul 21 11:28:09 Error: auth(default): ldap(rodrigo(a)XXXXX.ce.gov.br,XXX.XXX.XXX.55): No password in reply In phpLDAPadmin, the userPassword attribute is {CRYPT}YZJZNkBk381gg, the same as in dovecot-info.log -- M. Rodrigo Monteiro falecom(a)rodrigomonteiro.net "Free as in Freedom, not free as in free beer" Linux User # 403730

2 1

Re: [Dovecot] litte problems upgrade from 1.0.x to 1.1.1
by Andre Hübner 21 Jul '08

21 Jul '08

Hi, > Dovecot does not use mail messages to store folder meta-data as far as I > know > so I highly doubt this message was created by Dovecot (does Dovecot even > send > out messages except when going over quota?). Also notice the date of > 2006-09-18, which is almost two years in the past. The message was > probably > created by some client and was somehow (willingly) ignored or flagged as > deleted. Could be that upgrading Dovecot to 1.1 made the message visible > again for whatever reason. > and > Anyway, this is most certainly not a Dovecot-internal message. > this case is really suspicious to me. don't hang on the old date 2006-09-18. I can recreate it with dovecot 1.1.1 running on my machine. I create completly new mbox, write to it and when i view mbox in console i see just this mail. After deleting (pop3) this mail with our webmailer or OutLook Express etc. I see this internal message with current date. I do not belive in Clients that put internal mesages by pop3-protocol, but what should it be else? pop/imapserver is dovecot 1.1.1 And why this case just happens by updateing from 1.0.x to 1.1.1 and not during further updates from 1.0.x to 1.0.x+1 ? If you say this is not dovecot related i have to accept this but i am a little bit doubtful... Unfortunately i have now a more annoying error in imap processing. Sometimes it happens that dovecot seems to be out of sync. My Log says: Jul 7 11:22:44 servername dovecot: IMAP(loginname): Next message unexpectedly lost from 156756352 Jul 7 11:22:44 servername dovecot: child 21652 (imap) killed with signal 11 Jul 4 13:41:09 servername dovecot: imap-login: Login: user=<loginname>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Jul 4 13:41:10 servername dovecot: IMAP(loginname): Next message unexpectedly lost from 156715931 Jul 4 13:41:10 servername dovecot: IMAP(loginname): Disconnected: Logged out bytes=459/3359 Jul 4 13:41:32 servername dovecot: imap-login: Login: user=<loginname>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Jul 4 13:41:32 servername dovecot: IMAP(loginname): Next message unexpectedly lost from 156715931 Jul 4 13:41:32 servername dovecot: IMAP(loginname): Next message unexpectedly lost from 156715931 Jul 4 13:41:32 servername dovecot: Panic: IMAP(loginname): file message-parser.c: line 770 (message_parser_parse_next_block): assertion failed: (ctx->input->eof || ctx->input->closed || ctx->input->stream_errno != 0 || ctx->broken) Jul 4 13:41:32 dd10636 dovecot: IMAP(loginname): Raw backtrace: imap [0x80c2cf0] -> imap [0x80c2d4a] -> imap [0x80c265c] -> imap(message_parser_parse_body+0) [0x80bbfa0] -> imap(index_mail_cache_parse_continue+0x22) [0x8087172] -> imap(mbox_save_continue+0x9c) [0x807054c] -> imap(mail_storage_copy+0xe4) [0x8091684 ] -> /usr/lib/dovecot/imap/lib20_mail_log_plugin.so [0xb7f5ed1a] -> imap(cmd_copy+0x1d2) [0x805a1c2] -> imap [0x805edfc] -> imap [0x805eea5] -> imap [0x805f65 5] -> imap(client_input+0x5e) [0x805f86e] -> imap(io_loop_handler_run+0x100) [0x80ca590] -> imap(io_loop_run+0x28) [0x80c9738] -> imap(main+0x46b) [0x806736b] -> /lib/libc.so.6(__libc_start_main+0xdc) [0xb7e4887c] -> imap [0x8059211] Jul 4 13:41:32 dd10636 dovecot: child 10768 (imap) killed with signal 6 Hmm, if we got more errors with 1.1.1 on our servers we have to downgrade to 1.0.15 and stop installing new version and wait for 1.1.x alltogether we have ~2000 servers, but most of them are running still 1.0.x This is my configure-line, dovecot is packaged by my self ./configure \ --prefix=/usr \ --sysconfdir=/etc \ --localstatedir=/var \ --mandir=/usr/share/man \ --with-ssl=openssl \ --with-storages=mbox,maildir,raw \ --with-pam \ --with-passwd This is my dovecot.conf ## Dovecot configuration file #protocols = imap imaps pop3 pop3s protocols = imap imaps pop3 pop3s ssl_disable = no ssl_cert_file = "/path/*.domainname.crt" ssl_key_file = "/path/*.domainname.com.key" ssl_ca_file = "/path/*.domainname.com.bundle.crt" disable_plaintext_auth = no syslog_facility = mail login_user = dovecot login_process_per_connection = no login_processes_count = 1 login_greeting = domainname.com mailserver ready. login_log_format_elements = user=<%u> method=%m rip=%r lip=%l %c login_log_format = %$: %s max_mail_processes = 100 verbose_proctitle = yes auth_verbose = yes mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u #default_mail_env = mbox:~/mail:INBOX=/var/spool/mail/%u mail_cache_min_mail_count = 30 mmap_disable=no mail_debug=no lock_method = flock mbox_read_locks = dotlock mbox_write_locks = dotlock fcntl mbox_dirty_syncs = yes mbox_very_dirty_syncs = yes mbox_lazy_writes = no ## ## IMAP specific settings ## protocol imap { login_executable = /usr/libexec/dovecot/imap-login imap_client_workarounds = outlook-idle netscape-eoh tb-extra-mailbox-sep delay-newmail mail_plugins = mail_log } ## ## POP3 specific settings ## protocol pop3 { ssl_disable = no login_executable = /usr/libexec/dovecot/pop3-login mail_executable = /usr/libexec/dovecot/pop3 pop3_no_flag_updates = no pop3_uidl_format = %08Xu%08Xv pop3_client_workarounds = oe-ns-eoh outlook-no-nuls } System is suse 10.1 Thank you Andre

2 5

[Dovecot] recursive acl problem
by Robert Schetterer 21 Jul '08

21 Jul '08

Hi, i ve got a problem with recursive acl, using not a vfile global backend. ( no default acl) In my understanding every folder(directory) needs a seperate dovecot-acl files with permissions. This works fine, but my tests showed using a shared namespace like i.e. namespace shared { separator = / prefix = "users/%d/" location = dbox:/usr/local/virtual/%d/ inbox = no list = yes subscriptions = yes hidden = no } and have dovecot-acl in usr/local/virtual/%d/ with authenticated l which means lookup, leads that all folders and subfolders of /usr/local/virtual/%d/%u/ are imap browseable, which means its recursive somekind. ( people will not like seeing folder names of their mailboxes until they dont gave permissions explicit to others) In my meaning this shouldnt be so only names of ( names of directories) at /usr/local/virtual/%d/%u/ should be shown , subfolders in them should only be imap browseable if there is another dovecot-acl in them which permits lookup i may fail here , anyone which has some enlightment for me outside? -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria

2 3

[Dovecot] Mails "invisible" (index corrupted?)
by Patrick Nagel 21 Jul '08

21 Jul '08

Hi, I got a complaint from a user today, that a few mails "disappeared" from her Inbox, both when accessing via IMAP with Thunderbird and in the IMAP Webmail client (RoundCube Webmail, caching deactivated). Searching (in Subject or From header) within the Inbox turned up the missing messages though. After checking all relevant client settings (filter rules etc.), restarting Thunderbird multiple times, etc., I tried deleting her dovecot.index.cache file, restarting Thunderbird again, but that didn't change anything. Only after deleting dovecot.index.*, everything went back to normal. I can't find anything useful in the log. Setup: x86, CentOS Linux, dovecot 1.1.1 (current stable binary from ATrpms), maildir storage, mail_debug is turned on Any hints on what could have caused this? Where to look? I backed up dovecot.index, dovecot.index.cache and dovecot.index.log before I deleted them, but they probably contain sensitive information, so I won't post them to the list. Thanks, Patrick. -- STAR Software (Shanghai) Co., Ltd. http://www.star-group.net/ Phone: +86 (21) 3462 7688 x 826 Fax: +86 (21) 3462 7779 PGP key: https://stshacom1.star-china.net/keys/patrick_nagel.asc Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005

2 3