June 2012 - dovecot - dovecot.org

[Dovecot] Problem with 'doveadm mailbox status -t' reporting cumulative vsizes after upgrading from v2.0.16 to v2.1.7
by Jase Thew 03 Jul '12

03 Jul '12

Hi, I upgraded from Dovecot v2.0.16 to v2.1.7 over night and I noticed this morning that one of my daily reports which lists summarised mailbox sizes per user has started listing nonsense for vsizes. The reporting script at its core calls : doveadm -f flow mailbox status -A -t 'messages vsize' '*' It appears that Dovecot 2.1.7 is not resetting the vsize after collating the sum total of mailboxes sizes for each user, so that vsize just constantly increases as it iterates over each user. Eg: # doveadm -f flow mailbox status -A -t 'messages vsize' '*' accounts(a)example.com messages=1 vsize=759 adam(a)example.com messages=0 vsize=759 amy(a)example.com messages=24 vsize=51699697 andy(a)example.com messages=5446 vsize=3220940815 anna(a)example.com messages=50 vsize=3224035563 careers(a)example.com messages=1 vsize=3224036311 craig(a)example.com messages=2471 vsize=4421343199 creative(a)example.com messages=189 vsize=4426884182 david(a)example.com messages=8 vsize=4440729729 davidw(a)example.com messages=0 vsize=4440729729 enquiries(a)example.com messages=1 vsize=4440730491 gemma(a)example.com messages=4109 vsize=6349098844 gin(a)example.com messages=86 vsize=6392599904 holly(a)example.com messages=2000 vsize=7200342663 ian(a)example.com messages=0 vsize=7200342663 info(a)example.com messages=4 vsize=7200558689 jackie(a)example.com messages=2 vsize=7200721146 jade(a)example.com messages=137 vsize=7210548548 jake(a)example.com messages=16667 vsize=15260532446 katie(a)example.com messages=1 vsize=15260533375 mark(a)example.com messages=0 vsize=15260533375 mike.a(a)example.com messages=9 vsize=15261474205 mike.s(a)example.com messages=296 vsize=15314352543 mike(a)example.com messages=6357 vsize=20631446344 nick(a)example.com messages=1184 vsize=21038046728 social(a)example.com messages=65 vsize=21038935461 will(a)example.com messages=85 vsize=21057572390 [SNIP] The same occurs with -u '*(a)example.com' in place of -A, and also for 'all' in place of 'messages vsize'. Is this expected behaviour in 2.1.x compared to 2.0.x, or have I stumbled upon a bug? Regards, Jase Thew.

2 2

[Dovecot] Additional passdb result status
by Jürgen Pabel 03 Jul '12

03 Jul '12

Dear Dovecot-Team, I am implementing a plugin (for the pop3/imap process) that requires some data to provided from the authentication phase (a derivative of the password). For that, I have now implemented a passdb plugin that generates this data and I would like to "pass" this data down to the mail process (pop3/imap) via extra_fields in the reply of the authentication. The general idea is that my custom passdb plugin calculates the data, sets the extra_field and returns some error (authentication was not successful) so that the "real" passdb backend can be invoked to "really" validate the authentication data. However, in auth_request_handle_passdb_callback() the extra_fields are reseted unless the return code is PASSDB_RESULT_USER_DISABLED. But if that return code is used then any following passdb's aren't invoked any more - which makes sense with respect to user authenticiation. I would therefore like to propose that some IGNORE/CONTINUE-status to be introduced in auth/passdb.h, that would be handled in that extra_fields and possible other values are not reseted in order to allow such propagation of data from authentication process down to the mail process (which could be extracted from the reply string by parsing it). As a further implementation alternative (to the parsing of the reply string), I also propose that some new "environment" item be introduced (in auth_request) in order to allow such data passing in a generic manner. I hope you consider my proposal to be reasonable. If desired, I could implement this myself and provide a patch for merging (based on 2.0.x). If my proposal is generally unfavored, it would be great if any alternative approaches for my situation were suggested. Thanks. Regards, Jürgen PS: please reply to my e-mail (or CC me), as I have not subscribed to the dovecot list

3 3

[Dovecot] userdb errors after upgrading to 2.1
by André Rodier 03 Jul '12

03 Jul '12

Hello everybody, I am running debian wheezy for development and test, and I recently upgrade to dovecot 2.1.7 I am using LDAP lookups, and virtual users with the same UID/GID. Everything was working fine before, but now, I have this error when I try to send an email to a local account: -------------------------------------------------------- Jun 26 15:46:52 lapetus dovecot: lmtp(24518): Error: user user.test(a)indienet.com: Auth USER lookup failed Jun 26 15:46:52 lapetus dovecot: auth: Error: userdb(user.test(a)indienet.com,127.0.0.1): client doesn't have lookup permissions for this user: userdb reply doesn't contain uid (change userdb socket -------------------------------------------------------- However, even if I set the permissions to 0666, I still have the same error. Can you point me in the right direction to fix this, please? Kind regards, André Rodier

2 1

[Dovecot] Wrong headers in dovecot-crlf
by Matthieu RAKOTOJAONA 03 Jul '12

03 Jul '12

Hello everyone, I'm using the very good imaptest [0] tool to test my little imap server implementation. I've tried to use the dovecot-crlf [1] file, but it looks like there are some major issues : $ grep -n "In-Reply-To.*;" tests/data/dovecot-crlf 479:In-Reply-To: <20020806175441.GA7148(a)linux.taugt.net>; from rueckert(a)informatik.uni-rostock.de on Tue, Aug 06, 2002 at 07:54:41PM +0200 525:In-Reply-To: <20020806234054.GA30820(a)carpa.ciagri.usp.br>; from marcelo(a)carpa.ciagri.usp.br on Tue, Aug 06, 2002 at 08:40:54PM -0300 564:In-Reply-To: <20020806234054.GA30820(a)carpa.ciagri.usp.br>; from marcelo(a)carpa.ciagri.usp.br on Tue, Aug 06, 2002 at 08:40:54PM -0300 673:In-Reply-To: <20020807231956.GA11240(a)carpa.ciagri.usp.br>; from marcelo(a)carpa.ciagri.usp.br on Wed, Aug 07, 2002 at 08:19:56PM -0300 795:In-Reply-To: <20020808131329.GA30775(a)carpa.ciagri.usp.br>; from marcelo(a)carpa.ciagri.usp.br on Thu, Aug 08, 2002 at 10:13:30AM -0300 964:In-Reply-To: <20020808193533.GA28619(a)carpa.ciagri.usp.br>; from marcelo(a)carpa.ciagri.usp.br on Thu, Aug 08, 2002 at 04:35:33PM -0300 21545:In-Reply-To: <1046294808.30811.66.camel@hurina>; from tss(a)iki.fi on Wed, Feb 26, 2003 at 11:26:48PM +0200 22042:In-Reply-To: <1046373554.18310.4.camel@hurina>; from tss(a)iki.fi on Thu, Feb 27, 2003 at 09:19:14PM +0200 23712:In-Reply-To: <20030227212127.A10927(a)pcx3332.desy.de>; from Juergen.Kahnert(a)DESY.de on Thu, Feb 27, 2003 at 09:21:27PM +0100 25498:In-Reply-To: <OFF6D684CA.26838A7C-ON42256CE8.003A8EFC-42256CE8.003B49AC(a)icoc.org>; from Leslie_Viljoen(a)icoc.org on Thu, Mar 13, 2003 at 12:44:52PM +0200 30654:In-Reply-To: <1048667343.30187.100.camel@hurina>; from tss(a)iki.fi on Wed, Mar 26, 2003 at 10:29:03AM +0200 31126:In-Reply-To: <1048704303.31565.214.camel@hurina>; from tss(a)iki.fi on Wed, Mar 26, 2003 at 08:45:03PM +0200 31313:In-Reply-To: <1048928723.6856.21.camel@hurina>; from tss(a)iki.fi on Sat, Mar 29, 2003 at 11:05:23AM +0200 31820:In-Reply-To: <1049101161.884.126.camel@hurina>; from tss(a)iki.fi on Mon, Mar 31, 2003 at 11:59:21AM +0300 31890:In-Reply-To: <Pine.LNX.4.44.0303311009510.17234-100000(a)vegemite.nssg.mitel.com>; from charlieb-dovecot(a)e-smith.com on Mon, Mar 31, 2003 at 10:12:22AM -0500 32037:In-Reply-To: <Pine.LNX.4.44.0303311414410.17234-100000(a)vegemite.nssg.mitel.com>; from charlieb-dovecot(a)e-smith.com on Mon, Mar 31, 2003 at 02:19:27PM -0500 32463:In-Reply-To: <1049243642.11879.25.camel@hurina>; from tss(a)iki.fi on Wed, Apr 02, 2003 at 03:34:02AM +0300 As you can see, many of the "In-Reply-To" headers are polluted with some junk. The situation is the same for many "Message-ID" headers. I don't know why they are here, but I think it's a mistake. I thought I would let you know. [0] http://imapwiki.org/ImapTest [1] http://www.dovecot.org/tmp/dovecot-crlf Regards, -- Matthieu RAKOTOJAONA

2 1

[Dovecot] Setting up mixed mbox and maildir
by Jonathan Ryshpan 03 Jul '12

03 Jul '12

I'm trying to set up a dovecot server for which mail arrives in an mbox, and mail is stored in a maildir. The wiki (see http://wiki.dovecot.org/Namespaces) refers to this as "Mixed mbox and Maildir". It advises handling this situation by creating two namespaces: one for the mbox and the other for the maildir. Each of these namespaces starts with namespace private { On the other hand the sample configuration in the documentation puts inbox in a namespace starting with: namespace inbox { # Namespace type: private, shared or public #type = private It appears that there has been a change in the configuration syntax after the wiki was written, and that the word following namespace no longer gives a property of the namespace, but rather its name. Is this correct? In any case, how should the configuration be modified to handle mixed mailboxes? Thanks - jon

4 7

[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