[Dovecot] bug: very strange behavior with pop3
Hello,
We have some strange problem which could be related to authentication here.
All our user info is in an openldap directory. We normally use pam/getpwent in dovecot to access our user accounts, via nss_ldap/pam_ldap, but we tried to connect directly to the ldap server, with the very same results.
We have one user (out of 100) which just cannot use dovecot with pop3. His login/password are accepted, and then dovecot doesn't say anything. I am sure it isn't a client issue: same result with Eudora, Thunderbird and while directly connecting through openssl to POP3s port and "talking POP3". Here is some session transcript:
+OK dovecot ready. USER rinstalle +OK PASS M=/)p365 +OK Logged in.
And it then stops responding (without giving a reason, breaking the connection). Nothing in the logs, it sees this as a regular login and that's all...
Now, it seems that when I copy this user in ldap, the new one occasionaly works. I first thought it did depend on the user name (uid or dn), but it doesn't seem to be the case. I think it is just random.
Here is an ldif of this user: dn: uid=rinstalle,ou=divers,ou=login,ou=Autres,ou=Personnes,dc=inma,dc=ucl,dc= ac,dc=be uid: rinstalle cn: compte foireux homeDirectory: /home/xx sn: xxxx uidNumber: 9999 objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: posixAccount gidNumber: 999
... And getent result (with nss_ldap): #getent passwd rinstalle rinstalle:x:9999:999:compte foireux:/home/xx:
To be complete, I should mention that it _does_ work when using local password files...
I solved the user problem just by copying his entry a few times. Now, I don't think it is purely ldap-related, as the login _is_ accepted.
Is there some guru out here who could help us?
Thank you,
--
Yannick Majoros http://www.inma.ucl.ac.be/~majoros Informaticien AUTO-INMA/FSA/UCL
CSAM 4, avenue G. Lemaître B-1348 Louvain-la-Neuve Belgium Tel: +32-10-47.80.10 Fax: +32-10-47.21.80 #JAPH : http://www.inma.ucl.ac.be/~majoros/japh.txt Si vous avez des problèmes pour afficher ce message (accents qui ne passent pas, signature électronique, ...) votre système de mail n'est pas conforme aux standards, voir http://www.inma.ucl.ac.be/~majoros/email.html
On 1.7.2005, at 20:01, Yannick Majoros wrote:
We have one user (out of 100) which just cannot use dovecot with pop3. His login/password are accepted, and then dovecot doesn't say anything. I am sure it isn't a client issue: same result with Eudora, Thunderbird and while directly connecting through openssl to POP3s port and "talking POP3". Here is some session transcript:
+OK dovecot ready. USER rinstalle +OK PASS M=/)p365 +OK Logged in.
And it then stops responding (without giving a reason, breaking the connection). Nothing in the logs, it sees this as a regular login and that's all...
So it's Dovecot that disconnects just after logging in, even if you try with openssl client directly? Then there should be something in Dovecot's logs..
Now, it seems that when I copy this user in ldap, the new one occasionaly works. I first thought it did depend on the user name (uid or dn), but it doesn't seem to be the case. I think it is just random. .. ... And getent result (with nss_ldap): #getent passwd rinstalle rinstalle:x:9999:999:compte foireux:/home/xx:
To be complete, I should mention that it _does_ work when using local password files...
I solved the user problem just by copying his entry a few times. Now, I don't think it is purely ldap-related, as the login _is_ accepted.
It sounds like either home directory is wrong, or the uid/gid doesn't have access to it. Or maybe you have set LDAP to return "mail" entry too which is wrong? In any case after the "OK Logged in" message Dovecot doesn't even know how it got its information, it only cares that home/uid/gid is correct.
Timo Sirainen wrote:
And it then stops responding (without giving a reason, breaking the connection). Nothing in the logs, it sees this as a regular login and that's all...
So it's Dovecot that disconnects just after logging in, even if you try with openssl client directly? Then there should be something in Dovecot's logs..
Sorry, I was wrong in my reporting: it _doesn't_ break the connection. It is still connected, but it doesn't respond to anything. Even bad commands don't give "-ERR Unknown command." anymore. That's one reason why I think it is strange...
I solved the user problem just by copying his entry a few times. Now, I don't think it is purely ldap-related, as the login _is_ accepted.
It sounds like either home directory is wrong, or the uid/gid doesn't have access to it. Or maybe you have set LDAP to return "mail" entry too which is wrong? In any case after the "OK Logged in" message Dovecot doesn't even know how it got its information, it only cares that home/uid/gid is correct.
But why does it work after just copying it a few times?
--
Yannick Majoros http://www.inma.ucl.ac.be/~majoros Informaticien AUTO-INMA/FSA/UCL
CSAM 4, avenue G. Lemaître B-1348 Louvain-la-Neuve Belgium Tel: +32-10-47.80.10 Fax: +32-10-47.21.80 #JAPH : http://www.inma.ucl.ac.be/~majoros/japh.txt Si vous avez des problèmes pour afficher ce message (accents qui ne passent pas, signature électronique, ...) votre système de mail n'est pas conforme aux standards, voir http://www.inma.ucl.ac.be/~majoros/email.html
Hello,
The problem I mentionned earlier _seems_ to be related to locking (fcntl). I managed to "repair" a broken user account by removing dozens of "dead" locks on user's mailbox (killing owner processes).
So, shouldn't dovecot check for locks when trying to access mailboxes?
Sincerely,
--
Yannick Majoros http://www.inma.ucl.ac.be/~majoros Informaticien AUTO-INMA/FSA/UCL
CSAM 4, avenue G. Lemaître B-1348 Louvain-la-Neuve Belgium Tel: +32-10-47.80.10 Fax: +32-10-47.21.80 #JAPH : http://www.inma.ucl.ac.be/~majoros/japh.txt Si vous avez des problèmes pour afficher ce message (accents qui ne passent pas, signature électronique, ...) votre système de mail n'est pas conforme aux standards, voir http://www.inma.ucl.ac.be/~majoros/email.html
On Mon, 2005-07-04 at 16:29 +0200, Yannick Majoros wrote:
The problem I mentionned earlier _seems_ to be related to locking (fcntl). I managed to "repair" a broken user account by removing dozens of "dead" locks on user's mailbox (killing owner processes).
So, shouldn't dovecot check for locks when trying to access mailboxes?
It does, which is probably why it gets stuck there? Are you using v0.99.x? Since you're killing lots of process of the same user, the problem may just be that the user's POP3 client is broken and leaves connections hanging.
1.0-stable/test releases use much less locks, maybe they would help..
participants (2)
-
Timo Sirainen
-
Yannick Majoros