- dovecot - dovecot.org

Re: [Dovecot] SSL errors
by Bill Boebel 29 Sep '06

29 Sep '06

On Fri, September 29, 2006 11:23 am, Bill Boebel <bill(a)webmail.us> said: > I have a Dovecot server set up as a proxy and getting a ton of these errors, but > I'm not sure where to begin troubleshooting it. I'm hearing frequently that > Outlook users who use IMAP with SSL are getting disconnected often as a result. > Any suggestions?... > > Sep 29 11:12:07 director4 dovecot: imap-login: SSL_accept() failed: > error:1409C041:SSL routines:SSL3_SETUP_BUFFERS:malloc failure [64.81.197.28] > > Sep 29 11:12:07 director4 dovecot: imap-login: SSL_accept() syscall failed: EOF > [24.236.204.154] > Actually, I found in the archives that I should increase login_process_size if I'm not running with login_process_per_connection. I have done this and that seems to have taken care of the malloc failure. However I am still getting a ton of these every few seconds: Sep 29 11:30:06 director4 dovecot: imap-login: SSL_read() syscall failed: EOF [70.171.61.190] Sep 29 11:30:06 director4 dovecot: imap-login: SSL_read() syscall failed: EOF [24.236.204.154] Sep 29 11:30:06 director4 dovecot: imap-login: SSL_read() syscall failed: EOF [70.171.61.190] Sep 29 11:30:08 director4 dovecot: imap-login: SSL_read() syscall failed: EOF [65.242.19.3]

2 1

[Dovecot] Passdb passwd on FreeBSD
by Jim Flowers 29 Sep '06

29 Sep '06

I am trying to use dovecot for both virtual and local pop3 mailboxes. When I try to access a local account, I get an "unknown user" reject from 'passdb sql', as expected. However, I also get a reject from 'passdb pam' with the message: dovecot: auth(default_with_listener): pam(username(a)domain.tld,###.###.###.###): pam_authenticate() failed: authentication error. Is this because it is trying to authenticate username(a)domain.tld instead of just username? What can I do about it? Although I have a block for 'passdb passwd' following the 'passdb pam' block, there is nothing in the log. Why is this, I wonder? Any help to point me in the right direction will be appreciated. Thanks. -- Jim Flowers <jflowers(a)ezo.net> -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

[Dovecot] Quota plugin rewrite
by Timo Sirainen 28 Sep '06

28 Sep '06

Backported from CVS HEAD to branch_1_0. You can get it as a patch from http://dovecot.org/patches/1.0/quota-rewrite.diff New features include support for multiple quota roots, so you could have eg. per-user quota and a larger domain quota (although no backend actually supports this yet..). The more important feature is that you can configure specific mailboxes to have a bit more space available for them, such as Trash or Spam. The configuration has also changed. Normally you'd use something like this: quota = maildir # 1GB quota in general quota_rule = *:storage=1048576 # Trash mailbox gets 100MB more (so max. 1,1GB) quota_rule2 = Trash:storage=102400 # Spam mailbox gets also +100MB (still maxes at 1,1GB, not 1,2GB) quota_rule3 = Spam:storage=102400 You can place all the above into plugin { .. } section in dovecot.conf. In userdb if users have different quotas you'd then need to override only quota_rule (not quota, quota_rule2 and quota_rule3). I tested quickly that this seemed to work as described above. Please test and report. :)

2 6

[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