- dovecot - dovecot.org

[Dovecot] Odd error message
by Steven F Siirila 27 Mar '07

27 Mar '07

We are running Dovecot 1.0-rc27 and have run across what seems to be a fatal error (SIGSEGV) in the past few days (4 times total in past 6 days). It appears to have been 5 separate users, 5 separate remote IP addresses. Two of these have this format: Mar 26 15:13:10 myhostname dovecot: imap-login: Authenticate PLAIN failed: Don't send unrequested data: user=<rmtuser>, method=PLAIN, rip=10.9.9.9, lip=10.1.1.1, TLS The other three have this format: Mar 26 09:41:45 myhostname dovecot: imap-login: Authenticate PLAIN failed: Don't send unrequested data: method=PLAIN, rip=10.9.9.9, lip=10.1.1.1, TLS Here's the first one a bit more expanded, showing the SIGSEGV (signal 11): Mar 26 15:13:10 myhostname dovecot: auth(default): client in: AUTH 1 PLAIN service=IMAP secured lip=10.1.1.1 rip=10.9.9.9 Mar 26 15:13:10 myhostname dovecot: auth(default): client out: CONT 1 Mar 26 15:13:10 myhostname dovecot: auth(default): client in: CONT<hidden> Mar 26 15:13:10 myhostname dovecot: auth(default): pam(rmtuser,10.9.9.9): lookup service=IMAP Mar 26 15:13:10 myhostname dovecot: auth(default): client out: OK 1 user=rmtuser Mar 26 15:13:10 myhostname dovecot: auth(default): master in: REQUEST 675645 3333 1 Mar 26 15:13:10 myhostname dovecot: auth(default): passwd(rmtuser,10.9.9.9): lookup Mar 26 15:13:10 myhostname dovecot: auth(default): master out: USER 675645 rmtuser system_user=rmtuser uid=99999 gid=9999 home=/home/r/rmtuser Mar 26 15:13:10 myhostname dovecot: imap-login: Authenticate PLAIN failed: Don't send unrequested data: user=<rmtuser>, method=PLAIN, rip=10.9.9.9, lip=10.1.1.1, TLS Mar 26 15:13:10 myhostname dovecot: imap-login: Disconnected: user=<rmtuser>, method=PLAIN, rip=10.9.9.9, lip=10.1.1.1, TLS Mar 26 15:13:10 myhostname dovecot: child 3333 (login) killed with signal 11 What can I do to further diagnose this problem? -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs(a)umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593

2 1

[Dovecot] imaps listen only at localhost
by Dirk Schleicher 26 Mar '07

26 Mar '07

Hello list, I try to get dovecot listen only at localhost. I try listen localhost:993 and it did not work. The installation I made from http://holl.co.at/howto-email/ How it is possible that dovecot with imaps only work on localhost? Thanks for the help. Best regards Dirk

2 2

[Dovecot] netapp/maildir/dovecot performance
by bofh list 26 Mar '07

26 Mar '07

We are seeing some poor performance recently that is focused around users with large mailboxes (100,000 message /INBOX, 80,000 message subfolders, etc). The performance problem manifests as very high system% utilization - basically iowait for NFS. There are two imap servers with plenty of horsepower/memory/etc. They are connected to a 3050c cluster via gig-e. Here are the mount options: rw,tcp,nfsvers=3,rsize=8192,wsize=8192,nosuid,nodev,soft,intr,noac,actimeo=0 I need to get this system% utilization brought down because it is starting to slowdown imap performance for other users (it goes up to 95% on a regular basis, with users that have folders with many messages). My thought is to try removing the noac option and bump up the actimeo value from 0 to 30. Unfortunately I don't have access to use a SLB to direct traffic to individual servers. My understanding is that the worst that can happen is index corruption (which will result in rebuilding them when it happens). Any thoughts? I'm running RC24.

3 5

[Dovecot] authentication process fails when starting 2nd dovecot
by Cipriano Groenendal - TransIP 26 Mar '07

26 Mar '07

Hello, With dovecot running already, (accidently) starting another dovecot seems to break the authentication process of the first dovecot. Login will be impossible untill dovecot is restarted. # dovecot Fatal: listen(143) failed: Address already in use ## Wait several seconds. # telnet localhost 143 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. * OK Dovecot ready. 0: logout * OK Waiting for authentication process to respond.. 0: logout * OK Waiting for authentication process to respond.. -- Also, in the logfiles the following entries will appear: -- Mar 26 12:11:21 virt6 dovecot: pop3-login: No authentication sockets found Mar 26 12:11:21 virt6 dovecot: child 38054 (login) returned error 89 Mar 26 12:11:23 virt6 dovecot: imap-login: No authentication sockets found Mar 26 12:11:23 virt6 dovecot: child 38058 (login) returned error 89 -- Running dovecot-1.0.r22 on FreeBSD 6.2-STABLE, amd64 architecture. Standaard FreeBSD UFS fs. -- dovecot config -- # /usr/local/etc/dovecot.conf protocols: imap pop3 ssl_disable: yes disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login verbose_proctitle: yes first_valid_gid: 0 mail_extra_groups: mail mail_location: mbox:~/mail:INBOX=/var/mail/%u mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 imap_client_workarounds(default): delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(imap): delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(pop3): outlook-idle pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh namespace: type: private separator: / prefix: #mbox/ location: mbox:~/mail:INBOX=/var/mail/%u inbox: yes hidden: yes namespace: type: private separator: / location: maildir:~/Maildir auth default: passdb: driver: pam userdb: driver: passwd ------ Met vriendelijke groet, Cipriano Groenendal -- Transip BV | http://www.transip.nl/ Hoogwaardige Innovatie | Aangename Zekerheid

2 1

[Dovecot] Unwanted INBOX. prefix issues
by Kevin Bowling 26 Mar '07

26 Mar '07

I have a strange problem. I installed Dovecot and had my trash folder and such in the root of my maildir, and everything was working great. I then installed SquirrelMail which created folders in with the INBOX. prefix. I manually removed these from the maildir, but the INBOX.Trash is still shown in the folder listing of Thunderbird. This leads to some strange behavior, such as the delete button not working. Is there a way I can reset the folder list, and take the INBOX.* items out? Any help would be appreciated. Regards, Kevin

2 4

[Dovecot] Rpm builders: Dovecot spec file
by Egbert Jan 26 Mar '07

26 Mar '07

Maybe best asked to Axel... I'm re-building my server from scratch (the old one was MDK 10.1 -> Mandriva 2006.0 with Postfix/Courier) and I want to install the latest versions postfix/mysql/postfixadmin/dovecot/squirrelmail. I've been building Dovecot (and postfix) from tarballs/srpm in the past so I know more or less how it all fits together. But I wonder if 'old' patches still need to be included/applied in the building of the latest rc's. I still see references to those patches in the spec file. Unfortunately the latest 'official' rpm for Mandriva (I'm running 2007.0) is rc7 and I never succeeded getting in contact with the Mandriva maintainer to ask the same question. In the Axel's AT rpm I still see some patches included but others than in the Mandriva rc7 spec file. Are those patches not already applied to the latest sources by Timo? Tnx Egbert Jan NL

2 2

[Dovecot] assertion failure with nopassword
by Johannes Berg 26 Mar '07

26 Mar '07

Hm, so my mailing list archive is up, but when I add nopassword to the list of settings in my passdb passwd-file I get: file auth-request.c: line 924 (auth_request_set_field): assertion failed: (request->passdb_password == NULL) Raw backtrace: dovecot-auth [0x806be11] -> dovecot-auth [0x806bd8c] -> dovecot-auth(auth_request_set_field+0x277) [0x80547d7] -> dovecot-auth [0x8060418] -> dovecot-auth [0x8060509] -> dovecot-auth(auth_request_verify_plain+0xb3) [0x80559b3] -> dovecot-auth [0x8055ac2] -> dovecot-auth(auth_request_verify_plain_callback+0x30) [0x8055b50] -> dovecot-auth [0x8060dbe] -> dovecot-auth(io_loop_handler_run+0x152) [0x806f1c2] -> dovecot-auth(io_loop_run+0x28) [0x806e508] -> dovecot-auth(main+0x2fb) [0x805aaab] -> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc8) [0xb7a3fea8] -> dovecot-auth [0x8050ff1] This is with rc27. I don't seem to be able to get the passdb_password to NULL with passwd-file. johannes

2 2

[Dovecot] Bug tracking system
by Timo Sirainen 26 Mar '07

26 Mar '07

There are three reasons why I haven't really bothered setting up a bug tracking system for Dovecot: 1) They're all kind of annoying to use. 2) They all require a lot of stuff like PHP, SQL server, etc. which I don't really want to put into dovecot.org. 3) Probably most importantly: If people start reporing bugs in there, I'm pretty much the only person who will ever read them and reply to them. Currently when people report bugs in here, it's quite useful to have other people read them too. They may already know the bug and say they've reported it, they may have an idea what's causing it, they may know a workaround, etc. All in all, moving things to BTS would most likely cause my life to be harder and it might be more difficult to get some bugs fixed. A couple of days ago I started thinking about this and then I figured out a way to solve all of this nicely with a new and great Dovecot based bug tracking system. :) Just so I won't forget it, here's the plan: Dovecot BTS ----------- The preferred way to report bugs is to send them to dovecot-bugs(a)dovecot.org. The only thing it does is prefix the subject line with [BUG #nnn] and forward it to dovecot(a)dovecot.org. Now everyone can reply to it just as it was a normal mailing list mail. As long the subject contains the "[BUG #nnn]" prefix, it's part of the bug. Existing mailing list threads can also be turned into bugs by replying to the thread's root message with To: dovecot-bugs(a)dovecot.org. This again causes the new reply to contain [BUG #nnn] prefix. Then comes the web part. There's no SQL database or anything, everything is stored in a mailbox in the IMAP server. The mailbox contains the whole dovecot(a)dovecot.org archive. Bug metadata such as priority, status, etc. is stored using IMAP ANNOTATE extension, which allows setting key=value pairs to messages. Unfortunately Dovecot doesn't yet support that extension. Bugs' root messages contain the annotations for the whole bug thread. So to get a list of all bugs, the BTS issues an IMAP SEARCH ANNOTATE command to list all messages with some specific "bug=yes" type of annotation. For those messages then it can fetch the subject and whatever else metadata it wants. Newly created bugs don't have annotations though. To fix that, the BTS also uses ANNOTATEMORE (or is it METADATA nowadays?) extension to keep "last seen message in BTS" state in the mailbox's annotations. It then issues a SEARCH SUBJECT "[bug #" command for the new messages and does THREAD command for them to see if they're the bug root, or if they were replies to another message which should be treated as the bug root. When viewing a bug, the bug metadata comes from the annotations. Annotation history could also be kept, possibly as messages in another history mailbox. The messages for a bug can be viewed by issuing a THREAD (REFERENCES) command and showing all the mails that exist under the bug root. So, any volunteers to implement the web part, if I implement the ANNOTATE extension? :) It would actually even be possible to implement multiple frontends. All I need to do is give you access (read-only, or read-write for some) to the bug tracking mailbox, and you can use whatever frontend you wish, even a non-web one!

17 39

[Dovecot] Dovecot LDA issues
by Steven F Siirila 26 Mar '07

26 Mar '07

We've seen two issues come up with Dovecot LDA, both of which have caused us problems: 1) If the user's home directory does not exist, or is not owned by them, deliver fails and causes the mail message to bounce back to the originator. In our environment this happens when our user is moved to another server (where we move their files, but for up to 24 hours afterwards, continue to re-mail their /var/mail INBOX). This no longer works because the user has no home directory, causing deliver to fail with "Permission denied" when attempting to create their home directory for the purposes of creating INBOX index files. 2) If the user is over quota (in their home directory), deliver fails with a temporary error, causing requeues until the user is back under quota (which in our environment could be a long time, days). Since we've never had quotas on the user's INBOX (in /var/mail), this is a problem for us. I'd propose for both of these cases that deliver issue WARNING messages to its logs, and simply not create index files for the INBOX. If the INBOX index files already exist, and the user is over quota in /home, neither deliver nor any other Dovecot process should attempt to update them, and instead issue WARNING messages. This allows the e-mail to be delivered instead of requeued, or worse yet, rejected. Index files are supposed to make things perform better, not worse, in ALL cases. :) -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs(a)umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593

2 3

[Dovecot] deliver: -m, sieve and -n
by Jim Horner 26 Mar '07

26 Mar '07

Hi, I took a stab at editing the wiki ... the changes disappeared? I guess I was overruled. The wiki (http://wiki.dovecot.org/LDA) states -m <mailbox>: Destination mailbox (default is INBOX). If the mailbox doesn't exist, it's created (unless -n is used). If message couldn't be saved to the mailbox for any reason, it's delivered to INBOX instead. I tried to add a little note that the sieve plugin takes precedence. For example if at the end of the a .dovecot.sieve there is a line like: fileinto "CompanyFolders.general"; then the -m <mailbox> is ignored. I am not sure about the use of 'stop'. -n: If the destination mailbox doesn't exist, don't create it. This affects both -m parameter and fileinfo action in Sieve scripts. The fallback is to deliver mail to INBOX. (typo: fileinto not fileinfo) My testing shows that if the mailbox does not exist then the mail is rejected like so: === Your message was automatically rejected by Dovecot Mail Delivery Agent. The following reason was given: Mailbox doesn't exist: mail-lists.debian === I like the wiki's solution better. Jim

2 3