- dovecot - dovecot.org

[Dovecot] Imap segfault on login with version 2.0.8 & 2.0.11
by Nicholas VonHollen 09 Apr '11

09 Apr '11

Hi everyone, I'm trying to upgrade/test our configuration files from Dovecot 1.2 to 2.0.11. I used the Dovecot config convert command, created a RHEL 5 x86_64 rpm, and tested it. I can connect, but once I login, the IMAP service segfaults. I've also reproduced this on version 2.0.8. I installed the debug RPM (for the stripped symbols), took a look at the core dump in gdb, and just got the _start method in ld_preload and a broken pointer in the backtrace. I tried to strace everything but the segfault doesn't happen then :-). I'm not sure what to do to get better information. I attached my client session, dovecot -n output, gdb trace, maillog, and the core dump. I published the RPMs I made at: http://c3205012.r12.cf0.rackcdn.com/dovecot-2.0.11-1_125.x86_64.rpm http://c3205012.r12.cf0.rackcdn.com/dovecot-debuginfo-2.0.11-1_125.x86_64.r… My platform is RHEL 5 with kernel 2.6.18 on x86_64. Is there anything else I can provide for more info? Thanks, Nick Nick VonHollen Rackspace Software Developer Desk: 540-443-2003 (internal 505-2003) Personal Cell: 757-710-7038

4 7

[Dovecot] restarting director
by Cor Bosman 08 Apr '11

08 Apr '11

Hi all, anyone having any problems with restarting the director? Every time I bring down 1 of the director servers, reboot it, or just restart it for whatever reason, im seeing all kinds of problems. Dovecot generally always gives me this error: Jan 20 22:49:55 imapdirector3 dovecot: director: Error: Director 194.109.26.173:444/right disconnected before handshake finished It seems the directors cant agree on forming a ring anymore, and this may be leading to problems with clients. I mostly have to resort to bringing down all directors, and restarting them all at once. Not really a workable solution. As an example, last night for a few hours we were getting complaints from customers about being disconnected, and the only obvious error in the log was the one above, after one of my colleagues had to restart a director because of some changes in the syslog daemon. After I restarted all directors withing a few seconds of each other, all complaints disappeared. Timo, i know ive asked similar questions before, but the answer just eludes me. If I have 3 director servers, and need to take one down and restart it, what is the proper method to reconnect the ring? In practice, I cant seem to work it out and I mostly end up with the above error until I just restart them all. Not fun with 20.000 clients connected. Cor

3 4

[Dovecot] Thunderbird 3.1 unable to delete subfolder of Trash under mdbox
by William Blunn 08 Apr '11

08 Apr '11

Thunderbird 3.1.9 over Windows 7. Dovecot 2.0.11 (2:2.0.11-0~auto+41 from http://xi.rename-it.nl/debian/ source on 8 Apr 2011) over Ubuntu 10.04 LTS. Trying to set up a Dovecot system with mdbox. But I also wanted to keep some Maildir. So I ended up with both mdbox and Maildir side-by-side and noticed an issue. On this system, Dovecot's global mail location is configured with maildir:~/Maildir I have a two users configured in a password-file passdb/userdb: One using the Dovecot global mail location (maildir:~/Maildir) the other with an override mail location (userdb_mail) of mdbox:~/mdbox (The only other configurations different to the default were to turn off the default system password passdb and userdb, and enable my local password-file-format passdb and userdb.) I have configured two IMAP accounts in Thunderbird 3.1.9, one to access each of the two users above. The test procedure is: In Thunderbird, create a folder at the top level (i.e. alongside Inbox), say "foo". In Thunderbird, delete the folder just created. This results in Thunderbird "moving" the folder to "Trash", resulting in a folder "Trash/foo". Up to this point, both the Maildir and mdbox users behave OK. Then in Thunderbird, delete the trashed folder "Trash/foo". At this point, things start to happen differently. With the Maildir user, the folder "Trash/foo" deletes successfully. But with the mdbox user, Thunderbird pops up an error: The current command did not succeed. The mail server for account <accountname> responded: Invalid mailbox name: Trash/foo/. The folder does disappear from the Thunderbird folder pane, but if Thunderbird is "prodded" to refresh what folders it thinks are there, then the folder reappears. If we check the user's mdbox directory, we can see that indeed the mailbox has not been deleted. Whatever I then do, I am unable to delete this folder in the mdbox user through Thunderbird. The only way I have found to safely delete the folder is to use "doveadm mailbox delete", but this requires root privilege on the server, which is not really a practical solution. It maybe a Thunderbird problem, but the question then arises: Why does it work under Maildir but doesn't work under mdbox? Any ideas? Bill

2 4

[Dovecot] fstat no such file or directory error
by Mark Dieterich 08 Apr '11

08 Apr '11

Periodically, we will have users IMAP sessions get hung. Their client sees a message like: The server responded: 'SERVERBUG] Internal error occurred. Refer to server log for more information On the server, we see the following in the logs: IMAP(<username>): Transaction log dovecot.index.log: duplicate transaction log sequence (37) IMAP(<username>): fscking index file dovecot.index IMAP(<username>): fstat() failed with index file dovecot.index: No such file or directory After the fstat message shows up, there doesn't appear to be anything on the user side that can be done to fix the problem. We've seen multiple instances where the file dovecot is complaining about not existing is visible, readable, and writable by the user in question, but dovecot is convinced it's not. The only way we've found to fix this issue is to kill off all user connections. When the user reconnects, then all appears to work fine. We have not found a way to recreate this problem. Some details: # 1.2.15: /etc/dovecot/dovecot.conf # OS: Linux 2.6.26-2-686 i686 Debian 5.0.8 Mail files are stored on NFS. All imap connections for a given user are are mapped to a particular server at any given time. We have a script in place that watches our logs for this order of events, so the problem self corrects relatively quickly. But it would certainly be nice not have this happen at all. Thanks, Mark -- ---------- I'd rather be burning carbohydrates than hydrocarbons

2 4

[Dovecot] a strange doveadm behavior
by fakessh ＠ 08 Apr '11

08 Apr '11

hi timo very very good job you realize for the community here I have a very strange problem with doveadm I actually use a configuration file parameters in which the parameters are placed carefully My problem appears when I run this command doveadm expunge -A mailbox Trash savedbefore 30d i post command and result to the terminal [fakessh@r13151 ~]$ doveadm expunge -A mailbox Trash savedbefore 30d doveadm(fakessh): Error: userdb lookup: connect(/var/run/dovecot//auth-userdb) failed: Permission denied (euid=514(fakessh) egid=100(users) missing +r perm: /var/run/dovecot//auth-userdb, euid is not dir owner) doveadm: Error: Failed to iterate through some users [root@r13151 ~]$ chmod +r /var/run/dovecot/auth-userdb [fakessh@r13151 ~]$ doveadm expunge -A mailbox Trash savedbefore 30d doveadm(fakessh): Error: userdb lookup: connect(/var/run/dovecot//auth-userdb) failed: Permission denied (euid=514(fakessh) egid=100(users) missing +w perm: /var/run/dovecot//auth-userdb, euid is not dir owner) doveadm: Error: Failed to iterate through some users [root@r13151 ~]# chmod og+w /var/run/dovecot/auth-userdb [fakessh@r13151 ~]$ doveadm expunge -A mailbox Trash savedbefore 30d doveadm(dkimproxy): Fatal: seteuid(0) failed: Operation not permitted [fakessh@r13151 ~]$ any kind of discussion would be welcome -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7

2 5

[Dovecot] quota_exceeded_message
by Jim Knuth 08 Apr '11

08 Apr '11

Nevertheless, there is this option: plugin { quota_exceeded_message = Quota exceeded, please go to http://www.example.com/over_quota_help for instructions on how to fix this. } If one can write even more text, with word wrap? As an example: plugin { quota_exceeded_message = Quota exceeded, please go to http://www.example.com/over_quota_help for instructions on how to fix this. Please call: +49 0000 00000000 between 10:00 - 15:00 } -- Mit freundlichen Grüßen, Jim Knuth P.S.: Bitte HTML-Mails! Zufallszitat: Aus der Kriegsschule des Lebens: Was mich nicht umbringt, macht mich härter. [Nietzsche]

5 8

[Dovecot] shared folder: messages become invisible
by Burckhard Schmidt 08 Apr '11

08 Apr '11

Hello, after dealing with shared folder within version 2.0 rc* I started using it with a group of users. user1 shares a folder to user2. user2 has access to messages of this shared folder. After a "random" time (minutes up to several days) user2 doesn't see those messages anymore. user1 (the owner) hasn't changed anything inside this folder. All messages are still in place and normal visible for him. If user1 copies (whit TB) a messages into that folder user2 can see sometimes all messages again. But after a "random" time it happens again. user2 sees an empty shared folder. Deleting dovecot.index.log and dovecot.index.cache does not help. I have version 2.0.11 (2.0.10 same problem). mail_gid = sysdov mail_uid = sysdov namespace { inbox = yes list = yes location = prefix = separator = / subscriptions = yes type = private } namespace { list = yes location = maildir:%%h/maildir:CONTROL=~/control/FremdeOrdner/%%u:LAYOUT=fs prefix = FremdeOrdner/%%u/ separator = / subscriptions = no type = shared } mail_location = maildir:~/maildir:INDEX=/addons/index/%u:CONTROL=~/control:LAYOUT=fs I checked in a dialog: user1: 1 login user1 ... 1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS ACL RIGHTS=texk] Logged in 1 list "" "*" ... * LIST (\HasChildren) "/" "94ssl" #this one is shared to user2 * LIST (\HasNoChildren) "/" "94ssl/ansicht" #this one too user2: 1 login user2 ... 1 OK [CAPABILITY ... 1 list "" "*" ... * LIST (\HasChildren) "/" "FremdeOrdner/user1/94ssl" * LIST (\HasNoChildren) "/" "FremdeOrdner/user1/94ssl/ansicht" ... user1: 1 examine 94ssl * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS ()] Read-only mailbox. * 2 EXISTS # 2 messages * 0 RECENT * OK [UIDVALIDITY 1301570235] UIDs valid * OK [UIDNEXT 3] Predicted next UID * OK [HIGHESTMODSEQ 4] Highest 1 OK [READ-ONLY] Select completed. 1 examine 94ssl/ansicht * OK [CLOSED] Previous mailbox closed. * FLAGS (\Answered \Flagged \Deleted \Seen \Draft unknown-0) * OK [PERMANENTFLAGS ()] Read-only mailbox. * 6 EXISTS # 6 messages * 0 RECENT * OK [UIDVALIDITY 1301570236] UIDs valid * OK [UIDNEXT 7] Predicted next UID * OK [HIGHESTMODSEQ 14] Highest 1 OK [READ-ONLY] Select completed. user2 1 examine FremdeOrdner/user1/94ssl * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS ()] Read-only mailbox. * 0 EXISTS # no message, should be 2 * 0 RECENT * OK [UIDVALIDITY 1301570944] UIDs valid * OK [UIDNEXT 6] Predicted next UID * OK [HIGHESTMODSEQ 11] Highest 1 OK [READ-ONLY] Select completed. 1 examine FremdeOrdner/user1/94ssl/ansicht * OK [CLOSED] Previous mailbox closed. * FLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk unknown-0) * OK [PERMANENTFLAGS ()] Read-only mailbox. * 0 EXISTS # no message, shold be 6 * 0 RECENT * OK [UIDVALIDITY 1301570943] UIDs valid * OK [UIDNEXT 33] Predicted next UID * OK [HIGHESTMODSEQ 37] Highest 1 OK [READ-ONLY] Select completed. user1/control/94ssl/dovecot-uidlist: 3 V1301570235 N1 G8406fb358864944d710300000cd09d4f 1 :1301570819.M719509P910.suncom2,S=1319,W=1348 2 :1301585261.M338176P881.suncom2,S=23758,W=24220 user1/control/94ssl/ansicht/dovecot-uidlist: 3 V1301570236 N1 G3e8f0f00b862944d6f0300000cd09d4f 1 :1301570366.M22178P901.suncom2,S=1149,W=1173 2 :1301575917.M12924P1028.suncom2,S=1035,W=1055 3 :1301576897.M502460P1043.suncom2,S=1156,W=1183 4 :1301580697.M399644P1089.suncom2,S=1147,W=1174 5 :1285149220.M287482P15434.suncom2,S=1122,W=1149 6 :1301582382.M287792P1196.suncom2,S=1019,W=1039 user2/control/FremdeOrdner/user1/dovecot-uidvalidity: 4d946580 user2/control/FremdeOrdner/user1/dovecot-uidvalidity.4d946580 user2/control/FremdeOrdner/user1/94ssl/dovecot-uidlist: 3 V1301570944 N6 G9536eb178474944db10300000cd09d4f 3 :1301585261.M338176P881.suncom2,S=23758,W=24220 4 :1301570819.M719509P910.suncom2,S=1319,W=1348 user2/control/FremdeOrdner/user1/94ssl/ansicht/dovecot-uidlist: 3 V1301570943 N33 G5efdb6247f65944d880300000cd09d4f 21 :1301570366.M22178P901.suncom2,S=1149,W=1173 22 :1301575917.M12924P1028.suncom2,S=1035,W=1055 23 :1301576897.M502460P1043.suncom2,S=1156,W=1183 24 :1301580697.M399644P1089.suncom2,S=1147,W=1174 25 :1301582382.M287792P1196.suncom2,S=1019,W=1039 26 :1285149220.M287482P15434.suncom2,S=1122,W=1149 -- regards --- Burckhard Schmidt

2 1

[Dovecot] Debug messages
by Tolga 08 Apr '11

08 Apr '11

Here's everything after I enabled auth_verbose, auth_debug_passwords and auth_debug. Apr 06 16:20:47 auth(default): Info: new auth connection: pid=27885 Apr 06 16:20:47 auth(default): Info: client in: AUTH 1 PLAIN service=imap secured lip=184.82.40.118 rip=193.255.135.1 lport=143 rport=52150 Apr 06 16:20:47 auth(default): Info: client out: CONT 1 Apr 06 16:20:47 auth(default): Info: client in: CONT 1 AGJpbGdpAGJpbGdpOTg3 Apr 06 16:20:47 auth(default): Info: passwd-file(bilgi,193.255.135.1): lookup: user=bilgi file=/etc/dovecot/passwd Apr 06 16:20:47 auth(default): Info: passwd-file(bilgi,193.255.135.1): unknown user Apr 06 16:20:49 auth(default): Info: client out: FAIL 1 user=bilgi Apr 06 16:20:54 auth(default): Info: client in: AUTH 2 PLAIN service=imap secured lip=184.82.40.118 rip=193.255.135.1 lport=143 rport=52150 resp=AGJpbGdpAGJpbGdpOTg3 Apr 06 16:20:54 auth(default): Info: passwd-file(bilgi,193.255.135.1): lookup: user=bilgi file=/etc/dovecot/passwd Apr 06 16:20:54 auth(default): Info: passwd-file(bilgi,193.255.135.1): unknown user Apr 06 16:20:56 auth(default): Info: client out: FAIL 2 user=bilgi Apr 06 16:21:06 imap-login: Info: Disconnected (auth failed, 2 attempts): user=<bilgi>, method=PLAIN, rip=193.255.135.1, lip=184.82.40.118, TLS

2 1

[Dovecot] doveadm search doesn't update fts
by metro_domain_admin＠fastmail.fm 08 Apr '11

08 Apr '11

Hello, Doveadm search is failing to update our Squat indexes. The search itself works fine but the dovecot.index.search* files remain unchanged. I tried: doveadm search -u test mailbox INBOX body sometext doveadm search -u test mailbox INBOX text sometext I also tried the exact syntax Timo expressed in an earlier post: doveadm search -A body asdf If I run the same search through IMAP, the index files update as expected. The searches finish with a clean exit status and nothing shows up in the logs. I upgraded from 2.0.0 to 2.0.11 but the problem remains. >From doveconf -n: plugin { fts = squat } protocol imap { mail_max_userip_connections = 16 mail_plugins = $mail_plugins fts fts_squat } Thank you, Tony

2 1

[Dovecot] Permission Denied - cannot create inbox
by Joseph Tam 08 Apr '11

08 Apr '11

tlmoore(a)gmail.com writes: > Apr 7 07:44:51 fs1 dovecot: imap(tim): Error: > chown(/home/tim/mail/.imap/INBOX, -1, 97(dovecot)) failed: Operation not > permitted (egid=500(tim), group based on /var/mail/tim) > > How do I give permissions to dovecot program to create these? I am trying > not to chmod 777 every mailbox. I was going to write about the same problem. This got me over the hump: chmod 0600 /var/spool/mail/* All my user's mailboxes used to be group=mail mode=0660. I think these settings were left over from Solaris' mail.local: I can't reproduce these permissions now, even for new mailboxes. Maybe it's because the spool directory is now mode=1777 (not g+s mail). Not too keen on these permissions either, but it seems to work. Dovecot seems to transfer group permissions of the mailbox to its corresponding cache. If it can't set group ownership, you get the fatal error message above. If the original mailbox is mode 0600, dovecot is smart enough not to set group ownership. I couldn't find this information: shouldn't it be documented here? http://wiki2.dovecot.org/SharedMailboxes/Permissions This situation could also happen if a user is revoked from a group's membership. Would it be useful to make this a configurable behaviour whereby a chgrp() failure of cache files will fall back to chown'ing to user=owner, mode=0600 instead? Or just leave the user to scratch their head? Joseph Tam <tam(a)math.ubc.ca>

3 3