July 2012 - dovecot - dovecot.org

[Dovecot] indexer-worker
by Wojciech Puchar 03 Jul '12

03 Jul '12

why this process (which most probably do squat index/update) runs as root, not - like imap process - as user? 29413 root 1 76 0 22820K 9204K kqread 1 0:17 5.86% indexer-worker

2 3

[Dovecot] Proxy config help please
by Zac Israel 03 Jul '12

03 Jul '12

Hello, I am new to dovecot and I am initially trying to setup a basic imap proxy with password forwarding, I can start the dovecot service, connect and give it my password, and that is where I hang. My config is: root@imap-test:/etc/dovecot# doveconf -n # 2.0.19: /etc/dovecot/dovecot.conf # OS: Linux 3.2.0-24-generic x86_64 Ubuntu 12.04 LTS auth_debug = yes auth_verbose = yes debug_log_path = syslog first_valid_uid = 100 imap_capability = CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+ LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST last_valid_uid = 200 mail_debug = yes mail_gid = 107 mail_uid = 107 passdb { args = proxy=proxy_always nopassword=y host=172.16.0.13 port=143 proxy_timeout=5 starttls=y ssl=any-cert driver = static } protocols = imap service imap-login { inet_listener imap { address = * port = 143 } } ssl = required ssl_cert = </etc/courier/imapd.pem ssl_key = </etc/courier/imapd.pem verbose_ssl = yes The system at 172.16.0.13 is a zimbra proxy. I can see in the logs that it initially complains about my ssl cert, and if I remove ssl=any-cert it fails because my cert is self signed, so I know it is talking to the proxy and doing starttls which is a requirement of zimbra. Unfortunately I have not found a way to see the full exchange between dovecot and my zimbra proxy other than tcp dump, which just shows a small packet exchange. Please let me know if I can provide any other information and thanks in advance for any help. -Zac

3 3

[Dovecot] Dovecot 2.1 stable packages for Debian?
by Krzysztof Trybowski 02 Jul '12

02 Jul '12

Hello all, it is strange, but Dovecot 2.x still didn't make it into Debian (not even backports). It exists in testing, but that's still a long wait. OTOH there are official packages built every day (referenced from the download page). This puzzles me: why isn't there a build created from each stable, released version of Dovecot, so that users of Debian Stable could benefit from the new version, and run it on production environment? Could you (I mean — the Dovecot team) provide such packages? This wouldn't require any major amount of work, since you already have daily builds produced. You would just have to run that building system once per each released version and keep it available for download. The reason for this is relatively simple: I'm about to implement a new mail server, and I'd like to keep to Debian Stable while using Dovecot 2.x. This will make future updates much easier, as I won't have to face 1.2 -> 2.0 migration on a production system. Regards, KT

9 9

[Dovecot] RAID1+md concat+XFS as mailstorage
by Костырев Александр Алексеевич 02 Jul '12

02 Jul '12

Hello! somewhere in maillist I've seen RAID1+md concat+XFS being promoted as mailstorage. Does anybody in here actually use this setup? I've decided to give it a try, but ended up with not being able to recover any data off survived pairs from linear array when _the_first of raid1 pairs got down. thanks!

7 22

[Dovecot] [PATCH] GSSAPI authorization and virtual users
by Sam Morris 02 Jul '12

02 Jul '12

The attached patch makes it possible for Kerberos principals to be associated with a password database entry by adding a new "k5principals" passdb setting. A client that successfully authenticates using GSSAPI will be able to log in as any user who has been associated with the client's Kerberos principal. This means that users can now use their Kerberos identities to access virtual mail accounts. The patch definitely needs review by someone familiar with Dovecot. It works for me on a small test installation using the passwd-file backend. Things that should probably be improved: 1. The list of authorized principals is stored in struct auth_request. I would prefer to store it in struct gssapi_auth_request, but auth-request.c does not know about structs that are specific to the different authentication plugins. This could be fixed in a more general way by adding a new function to struct mech_module to allow authplugins to read fields during passdb lookups. 2. The gssapi authplugin now does a credential lookup in order to trigger parsing of the k5principals setting. In order for this to work, auth_request_set_username is now called before mech_gssapi_userok. AFAICT the only impact of this is that messages logged by this function (and the functions it calls) will now use the name of the virtual account. 3. The credentials lookup triggers an info log message saying that credentials for GSSAPI were requested, "but we have only (e.g.) MD5-CRYPT". The authplugin doesn't actually want the credential, but I think that the only way the authplugin can trigger a passdb lookup is by requesting it. 4. The final part of the code in mech_gssapi_unwrap was moved to the callback that's triggered when the credentials lookup is complete. The code still needs access to the GSSAPI data, so the buffer pointer & length are now stored in struct gssapi_auth_request, making the inbuf parameter to the mech_gssapi_{sec_context,wrap,unwrap} functions superfluous. The parameters should be removed. 5. The k5principals list won't be processed on Solaris. The code added to the end of mech_gssapi_krb5_userok would have to be moved to a separate function and then be called from the Solaris code. 6. GCC tells me about assignment to incompatible pointer types in the code that iterates through gssapi_k5principals. I must be missing something. The patch is licensed under the MIT license. Please let me know what you think. -- Sam Morris <sam(a)robots.org.uk>

2 4

[Dovecot] UTF-8 mailbox name STATUS response
by Ewald Dieterich 02 Jul '12

02 Jul '12

STATUS in Dovecot 2.1.7 returns the UTF-8 decoded folder name in a string literal: . CREATE "INBOX.Euro &IKw-" . OK Create completed. . LIST "" "INBOX.Euro &IKw-" * LIST (\HasNoChildren) "." "INBOX.Euro &IKw-" . STATUS "INBOX.Euro &IKw-" (MESSAGES) * STATUS {14} INBOX.Euro € (MESSAGES 0) . OK Status completed. Is this intended? My Perl script based on Mail::IMAPTalk doesn't like it and I wonder if there are other clients that don't cope with it.

2 3

[Dovecot] lmtp proxy timeout while waiting for reply to DATA reply
by Daniel Parthey 02 Jul '12

02 Jul '12

Hi, we are experiencing similar sporadic data timeout issues with dovecot 2.0.20 as in http://dovecot.org/pipermail/dovecot/2011-June/059807.html at least once a week. Some mails get temporarily deferred in the postfix queue since dovecot director lmtp refuses them and the mails are delivered at a later time. The problem applies to mails delivered to single users as well as distribution lists where the mails gets delivered to several mailboxes by postfix. The postfix log shows the following output: postfix.log.7.gz:Apr 21 18:48:46 10.129.3.233 postfix/lmtp[15868]: 88062C08E: to=<username(a)example.org>, orig_to=<username(a)example.org>, relay=127.0.0.1[127.0.0.1]:20024, delay=35, delays=5.4/0.01/0/30, dsn=4.4.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.4.0 Remote server not answering (timeout while waiting for reply to DATA reply) (in reply to end of DATA command)) The dovecot.log (mailbox and director log there via syslog) shows the following output: Apr 21 18:46:53 10.129.3.233 dovecot: lmtp(15869): Debug: none: root=, index=, control=, inbox=, alt= Apr 21 18:46:53 10.129.3.233 dovecot: lmtp(15869): Connect from 127.0.0.1 Apr 21 18:46:53 10.129.3.233 dovecot: lmtp(15869): Debug: auth input: user=username(a)example.org proxy port=19024 host=10.129.3.190 proxy_refresh=450 Apr 21 18:46:53 10.129.3.233 dovecot: lmtp(15869): Disconnect from 127.0.0.1: Client quit (in reset) Apr 21 18:47:29 10.129.3.233 dovecot: lmtp(15869): Debug: none: root=, index=, control=, inbox=, alt= Apr 21 18:47:29 10.129.3.233 dovecot: lmtp(15869): Connect from 127.0.0.1 Apr 21 18:47:29 10.129.3.233 dovecot: lmtp(15869): Debug: auth input: user=username(a)example.org proxy port=19024 host=10.129.3.190 proxy_refresh=450 Apr 21 18:47:29 10.129.3.233 dovecot: lmtp(15869): Disconnect from 127.0.0.1: Client quit (in reset) Apr 21 18:48:15 10.129.3.233 dovecot: lmtp(15869): Debug: none: root=, index=, control=, inbox=, alt= Apr 21 18:48:15 10.129.3.233 dovecot: lmtp(15869): Connect from 127.0.0.1 Apr 21 18:48:15 10.129.3.233 dovecot: lmtp(15869): Debug: auth input: user=username(a)example.org proxy port=19024 host=10.129.3.190 proxy_refresh=450 Apr 21 18:48:46 10.129.3.233 dovecot: lmtp(15869): Disconnect from 127.0.0.1: Client quit (in reset) One cannot identify the lmtp log origin from the log_format prefixes, but it seems that the "lmtp($PID)" log originated from the director, since proxy port 19024 is mentioned in the logs, which is our dovecot mailbox backend. Config for dovecot (mailbox) and director (proxy) is attached. mail_debug is yes for both dovecot and director. How can we find out more information? Shall I apply the following patches from http://dovecot.org/pipermail/dovecot/2011-June/059987.html or are they already included with version 2.0.20? Regards, Daniel

3 10

[Dovecot] director directing to wrong server (sometimes)
by Angel L. Mateo 02 Jul '12

02 Jul '12

Hello, I have discovered a strange behaviour with director proxying... I have a user, its assigned server is 155.54.211.164. The problem is that I don't know why director sent him yesterday to a different server, because my server was up all the time. Moreover, I'm using poolmon in director servers to check availability of final servers and it didn't report any problem with the server. I have two load balanced director servers. Logs at these servers are: * logs directing him to the correct backend server Jun 28 08:38:18 myotis42 dovecot: auth: Debug: master in: PASS#0111#011<user>@um.es#011service=lmtp#011lip=155.54.211.185#011lport=24#011rip=155.54.212.168#011rport=52255 Jun 28 08:38:18 myotis42 dovecot: auth: Debug: static(<user>,155.54.212.168): lookup Jun 28 08:38:18 myotis42 dovecot: auth: Debug: master out: PASS#0111#011user=<user>#011proxy#011proxy_timeout=150 Jun 28 08:38:18 myotis42 dovecot: lmtp(15889): Debug: auth input: user=<user> proxy proxy_timeout=150 host=155.54.211.164 proxy_refresh=450 Jun 28 08:39:59 myotis42 dovecot: auth: Debug: master in: PASS#01118#011<user>@um.es#011service=lmtp#011lip=155.54.211.185#011lport=24#011rip=155.54.212.166#011rport=40008 Jun 28 08:39:59 myotis42 dovecot: auth: Debug: static(<user>,155.54.212.166): lookup Jun 28 08:39:59 myotis42 dovecot: auth: Debug: master out: PASS#01118#011user=<user>#011proxy#011proxy_timeout=150 Jun 28 08:39:59 myotis42 dovecot: lmtp(15361): Debug: auth input: user=<user> proxy proxy_timeout=150 host=155.54.211.164 proxy_refresh=450 * now, the other director server sends him to an incorrect backend server Jun 28 09:01:12 myotis41 dovecot: auth: Debug: static(<user>,155.54.66.38): lookup Jun 28 09:01:12 myotis41 dovecot: auth: Debug: static(<user>,155.54.66.38): Allowing any password Jun 28 09:01:12 myotis41 dovecot: auth: Debug: client out: OK#01134556#011user=<user>#011proxy#011proxy_timeout=150#011pass=<hidden> Jun 28 09:01:12 myotis41 dovecot: auth: Debug: static(<user>,155.54.66.38): lookup Jun 28 09:01:12 myotis41 dovecot: auth: Debug: static(<user>,155.54.66.38): Allowing any password Jun 28 09:01:12 myotis41 dovecot: auth: Debug: client out: OK#01152763#011user=<user>#011proxy#011proxy_timeout=150#011pass=<hidden> Jun 28 09:01:12 myotis41 dovecot: imap-login: proxy(<user>): started proxying to 155.54.211.162:143: user=<<user>>, method=PLAIN, rip=155.54.66.38, lip=155.54.211.186 Jun 28 09:01:12 myotis41 dovecot: imap-login: proxy(<user>): started proxying to 155.54.211.162:143: user=<<user>>, method=PLAIN, rip=155.54.66.38, lip=155.54.211.186 Jun 28 09:01:13 myotis41 dovecot: auth: Debug: static(<user>,155.54.66.38): lookup Jun 28 09:01:13 myotis41 dovecot: auth: Debug: static(<user>,155.54.66.38): Allowing any password * Now, the first director sends him to the incorrect one too Jun 28 09:33:50 myotis42 dovecot: auth: Debug: master in: PASS#01132#011<user>@um.es#011service=lmtp#011lip=155.54.211.185#011lport=24#011rip=155.54.212.168#011rport=46830 Jun 28 09:33:50 myotis42 dovecot: auth: Debug: static(<user>,155.54.212.168): lookup Jun 28 09:33:50 myotis42 dovecot: auth: Debug: master out: PASS#01132#011user=<user>#011proxy#011proxy_timeout=150 Jun 28 09:33:50 myotis42 dovecot: lmtp(17284): Debug: auth input: user=<user> proxy proxy_timeout=150 host=155.54.211.162 proxy_refresh=450 I haven't found any error log for the correct backend server between the correct redirection and the incorrect one. In fact, I have lot of logs of other users directed to it, and logs of the same director directing connections to the correct server. -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 868887590 Fax: 868888337

3 3

[Dovecot] Config off by a nuance or a gross?
by Michael Brian Bentley 01 Jul '12

01 Jul '12

Hi, I am trying to establish an IMAP mail service accessible using a current Thunderbird on a laptop. I used Macports to install Dovecot2 (2.1.5) on an older Snow Leopard Mac mini with Intel Core Duo (specifically a Macmini1,1). My goal is to be able to run sieve under dovecot2 and offload the email triage from my work laptop to the little mail server. Mail appears to show up on the server just fine. I'm having trouble getting Tbird to log in and access properly. Because there are so many components in play (Tbird, pam, Dovecot2, macports, OS X Snow Leopard 10.6.8) (dovecot by itself seems to have quite a few settings), it is hard to tell what bit is out of whack. The message I get from Tbird 13.0.1 for OS X (on Lion) is: Alert: The IMAP server bentley on TheMini does not support the selected authentication method. Please change the 'Authentication method' in the 'Account Settings | Server settings'. When I set up the account, Tbird's automatic configuration invents a fake mail service based on my domain name, but appears to configure things sensibly once I switch to the manual configuration and fill in the relevant IP information. It does not appear to care whether it has a password or not. When I set up the account manually on TBird, I let it set up as: IMAP (ipv4)xx.xxx.xx.xx Port: 143 Connection security: None Authentication method: Password, transmitted insecurely SMTP xxxxxxxx.com Port: 587 The dovecot.conf tree includes these: passdb { driver = pam } userdb { driver = passwd } default_login_user = _dovenull default_internal_user = _dovecot service imap-login { executable = /opt/local/libexec/dovecot/imap-login inet_listener imap { address = * port = 143 } } service imap { executable=/opt/local/libexec/dovecot/imap process_limit = 1024 } service lmtp { unix_listener lmtp { } } Issuing the command: dovecot --build-options produces: Build options: ioloop=kqueue notify=kqueue ipv6 openssl io_block_size=8192 Mail storages: shared mdbox sdbox maildir mbox cydir imapc pop3c raw SQL drivers: Passdb: checkpassword pam passwd passwd-file Userdb: checkpassword passwd prefetch passwd-file The /etc/pam.d/dovecot file contains: # pop3, imap, smtp : auth account password session auth required pam_opendirectory.so account required pam_permit.so password required pam_deny.so session required pam_permit.so Dovecot provides the following debug messages on the console when I add args = failure_show_msg=yes to passdb in the relevant dovecot conf file: Jul 1 11:12:38 xx-xxx-xx-xx-nerewhon dovecot[3871]: auth: Debug:auth client connected (pid=5047) Jul 1 11:12:40 xx-xxx-xx-xx-nerewhon dovecot[3871]: imap-login: Disconnected (no auth attempts in 2 secs): user=<>, rip=192.168.xx.xx, lip=xx.xxx.xx.xx I recently discovered doveadm and used it with: doveadm config to create what I think is the current dovecot.conf file. I hesitate to inflict that on the list without being told, "yeah, we need that," there may be digest subscribers out there... I also see these messages show up; they appear unrelated to what I do with Tbird: Jul 1 11:37:33 xx-xxx-xx-xx-nerewhon dovecot[3871]: auth: Debug: Loading modules from directory: /opt/local/lib/dovecot/auth auth: Debug: auth client connected (pid=5094) auth: Debug: client in: AUTH 1 PLAIN service=imap secured lip=127.0.0.1 rip=127.0.0.1 lport=143 rport=49774 auth: Debug: client out: CONT 1 auth: Debug: client in: CONT 1 AGJlbnRsZXkAZ3IxbmNo auth-worker(5100): Debug: Loading modules from directory: /opt/local/lib/dovecot/auth auth-worker(5100): Debug: pam(bentley,127.0.0.1): lookup service=dovecot auth-worker(5100): Debug: pam(bentley,127.0.0.1): #1/1 style=1 msg=Password: auth-worker(5100): pam(bentley,127.0.0.1): pam_authenticate() failed: authentication error (password mismatch?) (given password: whatever) auth: Debug: client out: FAIL 1 user=bentley reason=Password: auth: Debug: client in: AUTH 2 PLAIN service=imap secured lip=127.0.0.1 rip=127.0.0.1 lport=143 rport=49774 resp=AGJlbnRsZXkAZ3IxbmNo auth-worker(5100): Debug: pam(bentley,127.0.0.1): lookup service=dovecot auth-worker(5100): Debug: pam(bentley,127.0.0.1): #1/1 style=1 msg=Password: auth-worker(5100): pam(bentley,127.0.0.1): pam_authenticate() failed: authentication error (password mismatch?) (given password: whatever) auth: Debug: client out: FAIL 2 user=bentley reason=Password: imap-login: Disconnected (auth failed, 2 attempts in 9 secs): user=<bentley>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured auth: Debug: Loading modules from directory: /opt/local/lib/dovecot/auth

1 0

[Dovecot] ot: trying to understand log entries, etc
by Voytek Eymont 01 Jul '12

01 Jul '12

totally of, I'm trying to understand what's happening, aka, 'how does email works' ? I have Dovecot 1.x, all works fine I noticed in the logs failed access from no-longer-hosted account/user, physical account deleted/removed, most likely from user's BBerry, every ~15 minutes: from /var/log/maillog --- Jun 24 07:31:25 dovecot: imap-login: Disconnected: Inactivity (auth failed, 1 attempts): user=<vvv@tld>, method=PLAIN, rip=101.222.222.222, lip=111.111.111.111 --- I recreated account/physical path /var/mail/.../tld/vvv@tld I logged in with webmail, all works, webmail logged out I physically copied some emails (from another account) to physical path ../../tld/vvv@tld/new after a while, I see the email files NO LONGER in ../../../new BUT now in ../../tld/vvv@tld/cur Q: that means the email was accessed, doesn't it ? BUT, I don't see any more access in the /var/log/maillog, not failed, not OK I did see one, after I recreated account Jun 30 20:01:53 dovecot: IMAP(vvv@tld): Disconnected: Logged out bytes=32/666 NONE since, but email files move from new to cur ?? if I observe email files moving from 'new' to 'cur' shouldn't I see some action logged in /var/log/maillog to correspond ? perplexed.... -- Voytek

1 0