On Wednesday 05 January 2005 07:09, Kazuo Moriwaka wrote:

...

I'm using Dovecot 0.99.11 (Debian Sarge), and all user information is stored in an LDAP database. Any suggestions?

Some bugs are fixed at ldap module after dovecot-0.99.11. Please check dovecot-0.99.12 or dovecot-1.0-test59. Out of curiosity, what exactly were the nature of the bugs? I'm stumped because it's so random; half of the users don't have any problems, while the other half does. As far as Dovecot is concerned, the only fields are uid, userPassword, mailAddress, and status. I've been over those, and can't see anything wrong. I even deleted the account for a user that wasn't able to log in, took the LDIF for a user that worked, and changed only the uid, password, and mailAddress for the first user, and got the same results. It's like the users have been mysteriously blacklisted by Dovecot, only because of their name! :Peter

On Thursday 06 January 2005 06:29, Kazuo Moriwaka wrote:

Please make a backtrace log as this page: http://www.dovecot.org/bugreport.html And please show some sample LDIF entries which does and doesn't cause this problem. It may be a help. When I ran 'gdb /usr/lib/dovecot/imap-login' I got "No debugging symbols found". Then I realized that since it's a Debian package, it's already been stripped. So let's try LDIF before I attempt to recompile the whole thing. The output of slapcat, first for a virtual account that works:

dn: uid=peter,ou=mailAccounts,dc=mydomain,dc=tld objectClass: userAccount objectClass: mailAccount uid: peter sn: Clark cn: Peter Clark userPassword:: <Removed> status: active mailAddress: peter@mydomain.tld mailDir: peter/Maildir/ structuralObjectClass: userAccount entryUUID: fc2c9e7e-f3f2-1028-858c-8ebe993cc366 creatorsName: cn=admin,dc=mydomain,dc=tld createTimestamp: 20050106055308Z entryCSN: 2005010605:53:08Z#0x0001#0#0000 modifiersName: cn=admin,dc=mydomain,dc=tld modifyTimestamp: 20050106055308Z

and now for an account that doesn't work:

dn: uid=natashia,ou=mailAccounts,dc=forrussia,dc=org objectClass: userAccount objectClass: mailAccount uid: natashia sn: Lastname cn: Natashia Lastname status: active mailAddress: natashia@mydomain.tld mailDir: natashia/Maildir/ structuralObjectClass: userAccount entryUUID: ad280f4a-f3f5-1028-9c71-f50f432a581f creatorsName: cn=admin,dc=mydomain,dc=tld createTimestamp: 20050106061224Z userPassword:: <Removed> entryCSN: 2005010606:14:20Z#0x0001#0#0000 modifiersName: cn=admin,dc=mydomain,dc=tld modifyTimestamp: 20050106061420Z

:Peter

On Thursday 06 January 2005 10:01, Kazuo Moriwaka wrote:

I found dc fields are different between them. - What is your LDAP server's root dn? - Can you find natashia's entry by ldapsearch? (slapadd and slapcat doesn't mind which entry dn is match for tree or not) - Can you find natashia's entry by ldapsearch? Oops, my bad, I was trying to hide the original root dn. I wiped out the LDAP database and started over,adding one account at a time, and somehow in the process everything corrected itself. For the life of me, I can't figure out what I changed, since I entered in the same information. I'll investigate further, and if I can pin the blame more specifically on something, I'll let you know. :Peter