October 2006 - dovecot

[Dovecot] child 29480 (auth) returned error 89, FC5, Postfix, MySql, mbox....arghhhh
by Kent Iverson 13 Oct '06

13 Oct '06

Hi all, I have been putting a small (simple?)dedicated email server together to (ultimately) host a couple of domains. I am currently getting the configuration to work with one domain w/local mbox users and then plan to extend it to virtual users and an additional domain. Dovecot has been a problem to integrate in the configuration. The basic pieces are FC5, Postfix, Dovecot, with Cyrus-sasl and MySql user/password databases. I have installed, configured, and verified Postfix, Cyrus-sasl, and MySql both separately and working together. All applications are standard Yum sourced FC5 binaries. Dovecot, however, stubbornly refuses to join the party. I have searched for clues on-line and have not found anything that has helped, thus this message. The problem seems to be tied tightly to using mySQL as an access mechanism for passdb/userdb information since if I remove that access mechanism Dovecot runs fine. The reason I am looking to use mySQL is that it seemed an easy way to have a common database for user name and domain identification with a single common FQDN login authentication format for current local users and future virtual users. As I understand it, the default PAM passwd doesn't support FQDN user names. The symptom: =========== Dovecot starts and immediately exits. Maillog shows the following immediately after executing /sbin/service dovecot start Oct 12 21:36:24 Playtime dovecot: Dovecot v1.0.beta8 starting up Oct 12 21:36:25 Playtime dovecot: child 29479 (auth) returned error 89 Oct 12 21:36:25 Playtime dovecot: child 29480 (auth) returned error 89 Oct 12 21:36:25 Playtime dovecot: Auth process died too early - shutting down Oct 12 21:36:25 Playtime dovecot: auth(default): net_connect_unix(/var/run/dovecot/auth-worker.29480) failed: Permission denied Oct 12 21:36:25 Playtime dovecot: auth(default): net_connect_unix(/var/run/dovecot/auth-worker.29479) failed: Permission denied It appears that the dovecot-auth process is immediately exiting with a non-specific error (89) and no collateral info. There are two sets of error 89's because the process count is set to 2 in dovecot.conf (see below). Looking at the messages log, you find a line reflecting the empty sockets as below: Oct 12 21:36:25 Playtime kernel: audit(1160714185.460:373): avc: denied { write } for pid=29479 comm="dovecot-auth" name="auth-worker.29479" dev=dm-0 ino=692358 scontext=user_u:system_r:dovecot_auth_t:s0 tcontext=user_u:object_r:dovecot_var_run_t:s0 tclass=sock_file There is nothing in the auth log other than happy noises from Postfix about its mySQL accesses. I am unaware of any other logs that might shed some light. Troubleshooting: ============= --- I have been using standard FC5 compiled binaries sourced through YUM for all applications. To the best of my knowledge, the package that Yum pulled for Dovecot is built --with-mysql and thus should support mysql access. I found this tidbit of info in the /usr/src/redhat/SPECS/dovecot.spec document. -- I have rolled back the dovecot.conf to remove the mysql passwd/userdb configuration leaving the default PAM configuration and found that Dovecot behaves correctly and joins the party. However, since Postfix is using mySQL data, the client FQDN login user names it uses don't match up with the simple UNIX user names that Dovecot's default PAM password mechanism is supporting (thus my attempt to get them both to use the mySql database.) So from this I know that the problem appears to be basic to startup of dovecot-auth and the mysql configuration. -- I have verified the location of the dovecot-sql.conf file as configured in dovecot.conf -- I have verified that the 'connect' parameters in the dovecot-sql.conf.work from a command line and the password_query syntax from inside mysql. Configuration details: dovecot.conf: ======================================================================= # things uncommented from defaults: base_dir = /var/run/dovecot protocols = imap imaps pop3 pop3s listen = * shutdown_clients = yes #for debug...seems to have made no difference. mail_debug = yes mbox_very_dirty_syncs = yes # authentication section # this next was left at default and I checked the ownership and it is correct. #auth_executable = /usr/libexec/dovecot/dovecot-auth #more debug auth_verbose = yes auth_debug = yes auth_debug_passwords = no # auth-worker process limit auth_worker_max_count = 30 #and into auth default: auth default { mechanisms = plain # default PAM passdb pam { } # SQL passdb sql { args = /etc/dovecot-sql.conf } # userdb userdb static { args = uid=690 gid=768 home=/var/mail/%n } #note there is no SQL userdb access defined. We will always use userdb static for now user = root count = 2 } ============================= dovecot-sql.conf ============================================================================== # Our mysql table actually is: (defined to support postfix password db) # CREATE TABLE users ( # id int(11) unsigned NOT NULL auto_increment, #table index # username varchar(255) NOT NULL default '0', #user part in user@userrealm # userrealm varchar(255) NOT NULL default 'firstdomain.com', #domain part in user@userrealm # userpassword varchar(255) NOT NULL default '94go283xc', #email password # auth tinyint(1) default '1', #Relay authority 1 = yes # active char(1) NOT NULL default 'y' #active Dovecot user? #}; driver = mysql connect = host=127.0.0.1 dbname=user_db user=dovecot password=xxxyy0x0 default_pass_scheme = PLAIN password_query = SELECT password FROM users WHERE username='%n' AND userrealm='%d' AND active='y' # there is no userdb sql access mechanism defined so this is left null user_query = ========================================================================================= Thats about it. I'm stumped....any thoughts or debug suggestions would be appreciated. Thanks -Kent I.

3 3

[Dovecot] fcntl Bad file descriptor
by Bill Boebel 13 Oct '06

13 Oct '06

I've seen a couple of these in the log while testing the proxy too. Do you know what would cause this? Aug 10 23:30:29 director5 dovecot: imap-login: fcntl(-1, F_GETFL) failed: Bad file descriptor Aug 10 23:30:29 director5 dovecot: imap-login: fd_set_nonblock(-1) failed: Bad file descriptor Aug 10 23:30:29 director5 dovecot: child 14016 (login) returned error 89

2 1

Re: [Dovecot] Dovecot LDA
by Steven F Siirila 13 Oct '06

13 Oct '06

On Sun, Oct 08, 2006 at 10:25:53PM +0300, Timo Sirainen wrote: > On Fri, 2006-10-06 at 21:00 -0500, Steven F Siirila wrote: > > I am running Dovecot 1.0-rc6 along with dovecot-sieve from 2006-10-05 CVS. > > I am calling dovecot deliver from Postfix (main.cf): > > > > mailbox_command = /opt/dovecot/libexec/dovecot/deliver > > > > Upon switching to dovecot deliver, I observed two problems: > > > > 1) An extraneous "From " header now appears at the top of each message > > delivered, e.g.: > > > > From dovecot.deliver Fri Oct 06 19:59:57 2006 > > From sfs(a)tc.umn.edu Fri Oct 6 19:59:57 2006 > > Return-Path: <sfs(a)tc.umn.edu> > > > > Using Postfix delivery the first of these lines does not appear. > > This, of course, confuses MUAs. > > Don't give F flag to Postfix's pipe command. In looking into this further, I see what you're getting at. There are commands in postfix/master.cf which specify different flags depending on what external delivery program is used. However, I haven't touched that and none of the entries that came with the standard master.cf file reference Dovecot, so I'm not sure if any of those entries even apply. What I changed to cause Dovecot delivery to be initiated was simply the mailbox_command in postfix/main.cf: mailbox_command = /opt/dovecot/libexec/dovecot/deliver I have been unable to determine what, if any, changes are necessary in the master.cf file to customize what parameters are sent to Dovecot deliver. Anyone? > Although this reminds me that the "dovecot.deliver" is wrong in there.. > Hmm. I think I'll add a maildrop-compatible -f <envelope> parameter > here. Great. Now if I could only figure out how to get Postfix to specify that. :) > There, done in CVS. I'll also make 1.0rc8 release today. > > > 2) The "Content-Length:" header appears after a blank line, essentially > > putting it into the RFC822 body, e.g.: > > > > User-Agent: Mutt/1.4.2.1i > > X-UID: 11510 > > Status: > > X-Keywords: > > > > Content-Length: 200 > > > > test > > Are you sure it's a blank line? Dovecot adds lots of spaces after > X-Keywords which could just make it look like that. > > If it really is a blank line, then it's most likely something else than > Dovecot that changes the spaces that way. -- 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

4 12

[Dovecot] you got chocolate in my peanut butter?!
by Logan Shaw 13 Oct '06

13 Oct '06

Hey everyone, Ran into something positively perplexing today. A user came to me and said that this morning when they checked their mail, they got about 120 strange new messages. Upon further inspection, it seems the "new" messages are all addressed to a certain other different user and are all 3 or 4 months old. And looking in that other user's /var/mail/(username) mailbox, I see the same messages that arrived mistakenly. And they're not in the /var/mail mailbox of the user whose desktop computer they ended up on. So it would appear that, possibly, when this user connected to the server, they got someone else's messages! Messages that, in fact, came from an account they don't even have the password to! I'm really curious if anyone has seen something like this before. We're using dovecot-1.0.beta9, and have been since mid-June. I've never seen anything happen like this before. I'm perfectly willing to upgrade to the latest release candidate, but it's hard for me to "upgrade and see if that fixes it", because it happens so rarely and it won't be easy to know empirically. So what I'm really hoping for is confirmation that this is/was a known problem, if in fact it is. Of course, I don't know that this is a dovecot bug, but I could imagine that it might be (maybe a daemon forgets to switch users after one session is closed and another is opened?), so I thought I'd ask. I did see what looked like TLS fixes and login fixes in the changelogs, so it doesn't seem out of the question that such a bug could've existed. Some more information: I checked the user's settings on their desktop computer, where the unexpected messages appear, and sure enough, there is only one POP server account configured there, and it has the correct username. What's more, I asked them what time this happened, and they said probably at 7:00am or maybe a little earlier. Looking at my dovecot logs, I see this (where 'theuser' is the user who received the messages): Sep 28 06:59:49 myhostname dovecot: pop3-login: Disconnected: user=<theuser>, method=PLAIN, rip=192.168.1.245, lip=192.168.1.20, TLS Sep 28 06:59:55 myhostname dovecot: pop3-login: Login: user=<theuser>, method=PLAIN, rip=192.168.1.245, lip=192.168.1.20, TLS Sep 28 06:59:55 myhostname dovecot: POP3(theuser): Disconnected: Logged out top=0/0, retr=0/0, del=0/9, size=130585 So, it would seem that the user did login at the time they claimed and it was at that time (or close to it) that the weird messages appeared. Also, I checked the logs for logins from the person whose messages accidentally got downloaded, and it doesn't show them logging in until several hours later. Oh, and there are no log entries for either of the two users in question before that, at least not for over 12 hours before that. The user is running Outlook 2003, with POP3 + TLS access to the mailbox. My dovecot.conf has nothing fancy in it: base_dir = /var/run/dovecot/ ssl_cert_file = /etc/mail/certs/server.crt ssl_key_file = /etc/mail/certs/server.key protocols = imap imaps pop3 pop3s disable_plaintext_auth = no login_dir = /var/run/dovecot/login syslog_facility = local0 first_valid_uid = 100 protocol imap { } protocol pop3 { pop3_lock_session = yes pop3_uidl_format = %08Xv%08Xu } auth default { mechanisms = plain user = root passdb shadow { } userdb passwd { } } The accounts are all coming out of LDAP via nsswitch (and this is all happening on Slackware 10.2), but I'm fairly sure that's irrelevant since "getent passwd", etc. all show the right stuff. Thanks for any help anyone can give... - Logan

5 9

[Dovecot] Login process died before initialization - FIX
by Timo Sirainen 13 Oct '06

13 Oct '06

I think this should do it: http://dovecot.org/list/dovecot-cvs/2006-October/006504.html

1 0

[Dovecot] parser bug
by DINH Viêt Hoà 13 Oct '06

13 Oct '06

hello Timo (and maybe other Dovecot developers), It looks like the MIME parser won't parse this correctly : Content-type: text/html Note the lower-case '-type' in 'Content-type'. -- DINH V. Hoa

2 1

[Dovecot] Feature req: auth_cache_relookup
by Bill Boebel 13 Oct '06

13 Oct '06

With auth_cache_size set to a value greater than zero, when our users change passwords their accounts stop working for a few minutes, because they are trying to log in with their new password, but Dovecot is comparing that against the cached old password. It would be nice if an option could be added so that if the login password does not match the cached password, the cache value is dropped and dovecot-auth queries the userDB, but only if the previous login was successful (to avoid frequent queries for bad logins). Maybe this option could be called "auth_cache_relookup" Bill

2 1

[Dovecot] default_mail_env renaming
by Timo Sirainen 13 Oct '06

13 Oct '06

I was thinking about renaming default_mail_env to something that is more understandable. I'll keep it working for backwards compatibility anyway. How about: # Location for users' mailboxes. This is the same as the old default_mail_env # setting. The default is empty, which means that Dovecot tries to find the # mailboxes automatically. This won't work if the user doesn't have any mail # yet, so you should explicitly tell Dovecot the full location. # # If you're using mbox, giving a path to INBOX file (eg. /var/mail/%u) isn't # enough. You'll also need to tell Dovecot where the other mailboxes are and # where Dovecot can place its index files. # # There are a few special variables you can use, eg.: # # %u - username # %n - user part in user@domain, same as %u if there's no domain # %d - domain part in user@domain, empty if there's no domain # %h - home directory # # See doc/variables.txt for full list. Some examples: # # mail_location = maildir:/var/mail/%1u/%u/Maildir # mail_location = mbox:~/mail/:INBOX=/var/mail/%u # mail_location = mbox:/var/mail/%d/%n/:INDEX=/var/indexes/%d/%n # # http://wiki.dovecot.org/MailLocation # #mail_location =

2 2

[Dovecot] Todo page?
by Francisco Reyes 13 Oct '06

13 Oct '06

Is there a Todo list? Looking for it in search function I think I saw one in CVS.. Is there a web CVS interface? I found the changelog in http://dovecot.org/nightly/, but did not see a Todo.

2 2

[Dovecot] 1.0.rc8 released
by Timo Sirainen 13 Oct '06

13 Oct '06

I've still over 200 mails unread in the mailing list, and important things left in TODO. This release is an improvement over rc7 anyway, hopefully I'll have time to fix the rest soon. http://dovecot.org/releases/dovecot-1.0.rc8.tar.gz http://dovecot.org/releases/dovecot-1.0.rc8.tar.gz.sig * GSSAPI: Changed POP3 service name to "pop", which is what the standard says * "mbox:/var/mail/%u" no longer works as the mail location. You'll have to specify the mail root explicitly, just like the examples always have: "mbox:~/mail:INBOX=/var/mail/%u" + SHA1, LDAP-MD5, PLAIN-MD5, PLAIN-MD4: The password can be now either hex or base64 encoded. The encoding is detected automatically based on the password string length. + Allow running only Dovecot master and dovecot-auth processes with protocols=none setting + deliver: -f <envelope sender> parameter can be used to set mbox From_-line's sender address + deliver: Log all mail saves and failures + Tru64 SIA passdb support. Patch by Simon L Jackson. - INBOX was listed twice in mailbox list if namespace prefix was used - INBOX-prefixed namespaces were a bit broken - kqueue: Fix 100% CPU usage - deliver: Duplicate storage was a bit broken - dictionary code was broken (ie. dict quota) - SIGHUP caused crashes sometimes

3 14