|
|
Doing an strace of the SOGo process I can see a 2 seconds pause during the IMAP login:
10:48:09.580528 sendto(10, "1 login \"username@example"..., 54, MSG_NOSIGNAL, NULL, 0) = 54
10:48:09.580726 sendto(10, "\r\n", 2, MSG_NOSIGNAL, NULL, 0) = 2
10:48:09.580859 recvfrom(10, 0x5562fc27da30, 512, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
10:48:09.580934 poll([{fd=10, events=POLLRDNORM}], 1, 3600000) = 1 ([{fd=10, revents=POLLRDNORM}])
10:48:11.604256 recvfrom(10, "1 OK [CAPABILITY IMAP4rev1 SASL-"..., 512, 0, NULL, NULL) = 379
10:48:11.604717 sendto(10, "2 capability", 12, MSG_NOSIGNAL, NULL, 0) = 12
It is very strange, because talking directly to the IMAP server I cannot see any delay between the login command and the server response. |
|
|
Good news, finally! It turned out it was an IMAP issue indeed!
Our Dovecot IMAP authentication relies on two backends, where the first one (the Unix PAM subsystem) adds a 2-seconds delay on failures.
So the solution was to swap the order of authentication backends, because the PAM is used only as a fallback if the first one fails.
It was difficult to see that delay, because the IMAP daemon logs the login only once succeded, it does not log start and end timestamps. I used a send/expect script to measure precise IMAP login timing.
Sorry for bothering you all :-( |
