September 2006 - dovecot

[Dovecot] [BUG(let)] Dovecot does not recognize threaded/reentrant mysql libs
by OpenMacNews 28 Sep '06

28 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, i build mysql (currently v5.0.22) on OSX 10.4.7 w/ threading enabled. i.e., i build the reentrant libs: libmysqlclient_r.dylib rather than the 'usual': libmysqlclient.dylib currently, to make Dovecot 'play nice' and recognize the reentrant libs, I: perl -pi -e 's/AC_CHECK_LIB\(mysqlclient,/AC_CHECK_LIB\(mysqlclient_r,/g' configure.in perl -pi -e 's/mysql_lib=\"\-lmysqlclient \-lz \-lm"/mysql_lib=\"\-lmysqlclient_r \-lz \-lm\"/g' configure.in then: autoreconf -i -f before configure, etc. subsquent build/exec/function all seem OK with this mod, and the linked, reentrant mysql lib: ls -al /usr/local/dovecot/libexec/dovecot/dovecot-auth -rwxr-xr-x 1 root wheel 950616 Sep 28 09:59 /usr/local/dovecot/libexec/dovecot/dovecot-auth otool -L /usr/local/dovecot/libexec/dovecot/dovecot-auth /usr/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libpam.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/local/mysql/lib/mysql/libmysqlclient_r.15.dylib (compatibility version 16.0.0, current version 16.0.0) /usr/local/lib/libreadline.5.1.dylib (compatibility version 5.0.0, current version 5.1.0) /usr/local/ncurses/lib/libncurses.5.5.dylib (compatibility version 5.5.0, current version 5.5.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.6) /usr/local/ssl/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/local/ssl/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) once verified that these changes are sufficient (anybody else got eyeballs on this?), a conditional in configure should do ... richard - -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iEYEARECAAYFAkUcAcUACgkQlffdvTZxCMYQXACgustNRKkqu97hWI88CTQwxZG7 q10AniSAcnhYesxf68x4y5Z7pg6uf/2f =py2/ -----END PGP SIGNATURE-----

1 0

[Dovecot] LDA and chroot
by Uldis Pakuls 28 Sep '06

28 Sep '06

Hi, I'd like to ask: is it possible to use Dovecot's LDA with mail_chroot variable set, e.g. "mail_chroot = /serv/storage19/vmail"? Without "mail_chroot" set all works fine. If mail_chroot is set and user database contains relative paths to home directory (without chroot part like "domain.net/user") deliver ignores this and tries to work at real root, while imap and pop3 processes founds home directory correctly. If users database contains full paths deliver works correctly, but imap/pop3 processes tries to access chroot directory + full path (and fails). Home directory in form "/chroot/path/./domain.net/user" solves the problem..., but as I understand, it is jut form to override default. Thus I can't find a way to correctly set default chroot path. Any suggestions? Tnx, Uldis

1 0

[Dovecot] LDA directly to Maildir/cur
by Scott Murman 28 Sep '06

28 Sep '06

i'm tired of dealing with buggy clients so i'm moving more processing into the server-side. i configured procmail as LDA with maildir-style mailboxes. i would like to simulate an automatic "mark as read" feature during procmail processing. simplest way looks to be forcing delivery directly to Maildir/cur instead of Maildir/new, but i suspect this may screw up dovecot. will this work? is there another (better) method? -SM-

3 3

[Dovecot] dovecot checkpassword passdb and vmailmgr
by Mij 28 Sep '06

28 Sep '06

hello some times ago I posted some patches to workaround vmailmgr not fitting into dovecot's passdb-checkpassword authentication module. Yesterday I spent some spare time for carrying out a cleaner solution for this problem. Check out these patches. If you're not interested in merging them, I will make them available at the same page I used for the former solution [ http://mij.oltrelinux.com/net/dovecot-qmail-vmailmgr ]; there were some 20 people/month that checked it out. This is a brief explanation of the patches: The root of all evil is that the checkpassword interface [ http://cr.yp.to/checkpwd/interface.html ] leaves room to interpretation when the scope is not system login. Vmailmgr and vpopmail, for example, collapse many mail users on the same system account. So, what "home" is here is not specified. In the case of vmailmgr, it's "checkvpw" sets HOME to the system user's home, and returns the path of the actual mail user differently. The solution I applied for this problem is to generalize the process that fetches authentication data (what currently is "checkpassword- reply"). I was set up for a specific passdb-vmailmgr module, but this would have seen a lot of code replication. Similarly (but I did not inspect further), I guess vpopmail can fit in this solution as well. So 1) provide a module "vmailmgr-reply", with the same behavior as checkpassword-reply, that's aware of the way checkvpw returns accounting information and pass this back to dovecot transparently so, this patch ships vmailmgr-reply along with checkpassword-reply (name them "fetcher"s for brevity) The idea is that every checkpassword-compatible module may have its own fetcher for passing correct info back to dovecot. Now with this generalization, the user must be able to specify if its checkpassword module needs a custom fetcher, and if it does, what's its path. So 2) modify auth/passdb-checkpassword.c and pump "args =". By default it takes the path of the checkpassword module (e.g. "checkvpw"), now it can be appended another field, that is the path of the custom fetcher. If this optional is omitted, the default checkpassword-reply will be used, and the cp module is supposed to behave like dovecot expects from it. Otherwise, a comma appear after the first path. e.g. passdb checkpassword { args = /xyz/checkvpw,/libexec/vmailmgr-reply } if one needs to specify paths with commas in the first one, commas can be escaped with \ (eg args=first\,path,second_path) Last but not least, the patch addresses again the problem with colons in paths. Currently, dovecot dictates no colons can exist in mailbox path names. In UNIX, no such constraint exist. Moreover, paths with colons are common when working specifically with qmail (see dot-qmail). When dovecot encounters ':', it truncates the path. This way, for example, if the authentication module returned home "/ path/name:surname", dovecot will truncante it to "/path/name". If name exist, name:surname will browse his mail without effort. All this comes from dovecot parsing params on MAIL environment (INDEX, INBOX, CONTROL), but it also happens if none of them was actually specified. So 3) modify lib-storage/index/maildir/maildir-storage.c for fixing the parsing problem with the mail environment. [ I did not provide the same fix for the remaining storages, but this can easily be done by copy/paste if convenient ]. For simplification and without loss of generality, this fix mandates ":INBOX=", ":INDEX=" and ":CONTROL=" params to follow in this order, if they appear. [ a minor patch agains auth/Makefile.am is provided for including vmailmgr-reply when building the rest of the auth stuff ] Any comment on this is welcome for discussion. bye

1 0

[Dovecot] Big sites using Dovecot
by Jonathan 28 Sep '06

28 Sep '06

Hi, Are there any big Dovecot sites (say 50,000-100,000) users on this list? What sort of hardware do you use. What sort of problems do you see? Many thanks, Jonathan.

14 22

Re: [Dovecot] syslog messages
by Rich West 27 Sep '06

27 Sep '06

After commenting out the "passdb pam" section and uncommenting "passdb ldap", with the "args = /etc/dovecot-ldap.conf", the syslog messages went completely away, and everything continued to work. I just thought I would mention it in the event that anyone else was seeing similar problems in the future. :) -Rich > > (I sent this last night, but to the wrong address.. argh) > > After an upgrade to FC5, and a rebuild and install of dovecot 1.0RC7, > > I've been getting a LOT of syslog messages like the following: > > Sep 26 21:47:55 myhost dovecot-auth: nss_ldap: reconnected to LDAP > > server ldap://ldap.mydomain.com after 1 attempt > > > > Now, everything is working fine as far as I can tell (it's only been a > > rocky day since the upgrade.. and that was littered with other LDAP > > related problems), but I was wondering why it was even using > > nss_ldap... I have dovecot configured to connect to LDAP directly. > > > > My dovecot.conf contains: > > auth default { > > # Space separated list of wanted authentication mechanisms: > > # plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi > > mechanisms = plain > > ... > > passdb pam { > > } > > ... > > # LDAP database > > #passdb ldap { > > # Path for LDAP configuration file, see doc/dovecot-ldap.conf for > > example > > #args = > > #} > > ... > > # LDAP database > > userdb ldap { > > # Path for LDAP configuration file, see doc/dovecot-ldap.conf for > > example > > args = /etc/dovecot-ldap.conf > > } > > > > And I am wondering if I missed something obvious here... > > > > I'm going to try commenting out the "passdb pam" section, uncommenting > > the "passdb ldap" section and see if that allows for everything to go > > directly to LDAP (and not rely on nss_ldap or pam_ldap). > > > > -Rich > > >

1 0

Re: [Dovecot] support for UW-style mbox
by Rich West 27 Sep '06

27 Sep '06

> UW-IMAP will automatically append the contents of /var/spool/mail/user to > ~user/mbox (and then clear /var/spool/mail/user) if ~user/mbox exists. > I'd like to mimic that action with Dovecot. (I'm probably going to be unlucky, > as an earlier respondent pointed out). > > Sorry to show my ignorance, but I thought delivery was a function > of the MTA (Exim in my case), which would require a change to my exim > config file, and would probably not then be a per-user thing. > (i.e. with UW-IMAP, if ~user/mbox doesnt exist, mail gets left in > /var/spool/mail/user). > I need to read about dovecot.conf No, you are correct. Delivery is handled by the MTA. Dovecot just needs to know where to access it. By default, for example, with Sendmail, it will place the email in /var/spool/mail (unless you change some back-end code somewhere along the line), and then you can use procmail (with a global procmailrc file in /etc) to place the mail where you want it to go.. I haven't used UW-IMAP in a while now (well over a year and a half). I stopped using it at all of my supported sites because, even though it was simple to manage, it was just way too slow. From what I remember, the UW implementation is such that UW-IMAP will read from the user's mbox file if it exists, and if it doesn't, it will read from <spooldir>/<username> (in this case, /var/spool/mail/user). UW-IMAP (or any IMAP) wouldn't actually do the delivery, so writing to the spool directory temporarily and then moving it to the home directory shouldn't actually happen. However, I don't truly remember how it worked under the hood, but that just doesn't seem right to me (too much chance for conflict). I do remember (back in the day) the headaches we would get when trying to debug a "lost mail" problems (with a centralized /var/spool/mail directory) and it turned out the user in question had created an mbox file which had next to nothing in it. :) -Rich

2 2

[Dovecot] syslog messages
by Rich West 27 Sep '06

27 Sep '06

(I sent this last night, but to the wrong address.. argh) After an upgrade to FC5, and a rebuild and install of dovecot 1.0RC7, I've been getting a LOT of syslog messages like the following: Sep 26 21:47:55 myhost dovecot-auth: nss_ldap: reconnected to LDAP server ldap://ldap.mydomain.com after 1 attempt Now, everything is working fine as far as I can tell (it's only been a rocky day since the upgrade.. and that was littered with other LDAP related problems), but I was wondering why it was even using nss_ldap... I have dovecot configured to connect to LDAP directly. My dovecot.conf contains: auth default { # Space separated list of wanted authentication mechanisms: # plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi mechanisms = plain ... passdb pam { } ... # LDAP database #passdb ldap { # Path for LDAP configuration file, see doc/dovecot-ldap.conf for example #args = #} ... # LDAP database userdb ldap { # Path for LDAP configuration file, see doc/dovecot-ldap.conf for example args = /etc/dovecot-ldap.conf } And I am wondering if I missed something obvious here... I'm going to try commenting out the "passdb pam" section, uncommenting the "passdb ldap" section and see if that allows for everything to go directly to LDAP (and not rely on nss_ldap or pam_ldap). -Rich

1 0

Re: [Dovecot] Big sites using Dovecot
by Bill Boebel 27 Sep '06

27 Sep '06

On Thu, September 21, 2006 1:14 pm, Jonathan <dovecot(a)redigloo.org> said: > Are there any big Dovecot sites (say 50,000-100,000) users on this > list? Yes, Webmail.us. Many multiples of that number :) > What sort of hardware do you use. 80 backend IMAP servers. 5 front-end IMAP-proxy servers. All running Dovecot. The boxes are single AMD CPU, 1GB RAM, and 4 SATA drives. DRBD used to replicate data between servers. > What sort of problems do you see? Dovecot doesn't need much CPU, but it needs a lot of disk. So give it lots of spindles, either in one big box or many small boxes like we do. Right now the only problem we have is the Dovecot proxy software sometimes disconnects imap sessions that it should not disconnect. Since Timo is very busy, we are working on a patch for this. http://www.dovecot.org/list/dovecot/2006-August/015401.html Bill

3 2

[Dovecot] SSL_accept failed
by Timothy Martin 26 Sep '06

26 Sep '06

Hello, I'm new to dovecot. I just installed it a few days ago on FreeBSD via the ports and got it up and running without too much trouble. Although yesterday I turned on the SSL/TLS features and tried to get secure connections to work. I don't get any error messages when launching dovecot, I saw it successfully create the SSL parameters after first enabling the feature yet I can't seem to get a successful connection. Normal non- ssl connections work fine. What happens: 1) my client claims to be attempting the connection. 2) things go on for some time with nothing happening 3) finally the dovecot log pops up with these messages dovecot: Sep 09 02:25:23 Warning: imap-login: SSL_accept() syscall failed: EOF [x.x.x.x] dovecot: Sep 09 02:25:23 Info: imap-login: Disconnected: rip=x.x.x.x, lip=x.x.x.x, TLS handshake dovecot: Sep 09 02:26:23 Info: imap-login: Disconnected: Inactivity: rip=x.x.x.x, lip=x.x.x.x, TLS handshake FYI: I've regenerated a fresh cert and key, just for dovecot and I'm using Mac OS X's Mail client. Any clues? .tim

6 17