search for: test67

Hello, I've been trying to figure out what's wrong with authentication against an ldap pass/user db with test67 as test62 was working fine. [ The problem is the same as previously described in this list : - FreeBSD-5.3 - dovecot-1.0-test67 - openldap-2.1.27 --> "ldap(dovetest,127.0.0.1): No password in reply" --> "NO Temporary authentication failure." or -- dovecot: Apr 12 18:...

Hello, I'm wondering if the following situation is valid (though I think it isn't since I still cannot authenticate with ldap pass/userdb on test67 running on FreeBSD-5.3). Is it normal that the passdb_ldap_conn->attr_names second element (for instance) "turns to" "homeDirectory" as the following step by step gdb run sample shows ? : -- Breakpoint 1, userdb_ldap_preinit (args=0x80796d0 "/usr/local/dovecot/etc/dov...

http://dovecot.org/test/ Hopefully better release than last one. Fixes several problems test66 had and also some older problems reported in this list. It also contains a pretty large mbox code cleanup, fixing several problems (especially related to X-IMAP/X-IMAPbase headers) and making it a bit faster. Maybe I'll backport it to 1.0-stable too when it looks like it's stable.. BTW. mbox

Hello Timo, your patch introducing pass_attr_names and user_attr_names fixed the problem of the 'shared' attr_names member of [passdb|userdb]_ldap_conn as I answered in the relative thread. Now I think there is a problem while comparing user-provided and ldap-provided passwords causing a false 'password mismatch' situation, while using PLAIN mechanism with LDAP authentication.

Just a note, I backported some larger mbox changes from 1.0-test67. Hopefully works, but if you're going to try it test it well first :) Should fix some issues related to X-IMAP/X-IMAPbase header handling and maybe some other mbox related problems as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: appl...

...n 32607 ? S 0:00 dovecot/auth -s 3 Or if I should name the binaries all as dovecot-config, dovecot-log, etc. One nice thing with the above is that it also shows imap and imap-login processes while grepping for dovecot. You can get the tarball from http://dovecot.org/tmp/dovecot-1.0-test67-mrewrite.tar.gz (it has all the test73 changes despite the name..) Example configuration file (with bare minimals) is at http://dovecot.org/tmp/dovecot.conf I think I'll create a separate dovecot-master.conf for those service-blocks in the above config file (after I add include-directive...

...a day.. I'd love to track it down.. I've seen this on Fedora Core 1 (i386 server) and also on a PPC Linux system running an older kernel (on a Buffalo Linkstation if you know what that is).. Below is the current set of dovecot processes running on my FC1 box : [rickf at srv1 dovecot-1.0-test67]# ps aux | grep dove root 748 0.0 0.0 3380 720 ? S 11:30 0:00 dovecot-auth dovecot 749 0.0 0.0 2440 668 ? S 11:30 0:01 imap-login dovecot 760 0.0 0.0 2788 700 ? S 11:30 0:01 imap-login root 709 0.0 0.0 2312 688 ? S 11:3...

Timo or anyone, This may be a bug or maybe a design decision. Either way I am curious to hear comments. Why do the dovecot-0.99.14 server's .imap.index files contain a cached copy of each message's date and time as supplied by the filesystem, as opposed to the date and time found in each message header? When testing various imap clients (eg. tbird-1.0.2, evolution-2.0, outlook2003,