Greetings list!
We've been experiencing an intermittent issue in which none users are able
to log into the mail server for about 10 to 20 minutes.
This issue first appeared on our CentOS 4 box running dovecot 1.2.11 after
upgrading from the stock version 0.99. The issue persists after migrating our
users to a CentOS 5 server - also running version dovecot 1.2.11 but now in the
64-bit flavor.
Our users authenticate against LDAP via PAM in case that might be relevant.
I've yet to find anything "of interest" in the logs covering the
outages. But here is what I've noticed:
* Users on our internal network are still able to authenticate and login.
* Users from the outside are "Disconnected for inactivity"
* Immediately after the restart, external users were able to log in again.
It almost sounds like the firewall is blocking external access except that:
* The version of dovecot was the thing that changed
* Everything starts working again after a dovecot restart
If anyone could provide some insight, I'd sure appreciate it.
Output of dovecot -n
# 1.2.11: /etc/dovecot.conf
# OS: Linux 2.6.18-164.15.1.el5 x86_64 CentOS release 5.4 (Final)
listen: *
shutdown_clients: no
login_dir: /var/run/dovecot/login
login_executable(default): /usr/libexec/dovecot/imap-login
login_executable(imap): /usr/libexec/dovecot/imap-login
login_executable(pop3): /usr/libexec/dovecot/pop3-login
login_process_per_connection: no
login_trusted_networks: x.x.x.x/x
login_max_processes_count: 164
max_mail_processes: 2048
mail_max_userip_connections: 50
mail_location: maildir:~/Maildir
mail_executable(default): /usr/libexec/dovecot/imap
mail_executable(imap): /usr/libexec/dovecot/imap
mail_executable(pop3): /usr/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/lib64/dovecot/imap
mail_plugin_dir(imap): /usr/lib64/dovecot/imap
mail_plugin_dir(pop3): /usr/lib64/dovecot/pop3
pop3_no_flag_updates(default): no
pop3_no_flag_updates(imap): no
pop3_no_flag_updates(pop3): yes
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
lda:
postmaster_address: postmaster at domain.com
sendmail_path: /usr/sbin/sendmail
auth default:
passdb:
driver: pam
userdb:
driver: passwd
On Tue, Jun 1, 2010 at 12:58, Del Stoliker <dstoliker at alphagraphics.com> wrote:> It almost sounds like the firewall is blocking external access except that: > * The version of dovecot was the thing that changed > * Everything starts working again after a dovecot restartIt sounds like the firewall is doing something to the connections. I know that at least my IMAP client (Evolution) likes to hang on to an existing connection, even if nothing responds on the other end, for at least 15 minutes. By then the TCP layer drops it. For testing purposes, I've piped that connection coming from my desktop into a local port listened to by a program that relays all traffic to a connection it makes to the IMAP server. I can see it making requests and getting no answers if the server isn't responsive. If I kill that relay program, the client remakes the connection and all is well if a new connection can be established. I have seen a related issue with another service which was due to the firewall shifting the TCP sequence numbers for security purposes, combined with routing asymmetry where return packets bypassed the firewall sometimes (the packets are discarded, rather than exposing an easy TCP takedown by forgery). In your case, outside users are the ones involved, so this scenario would only apply for you if there is a way for outsiders to get around the firewall. Otherwise, your firewall may be losing connection state info and discarding further traffic without sending a TCP reset (usually they don't, but if you can configure it to do so, that can at least let new connections be made faster than the TCP stall timeout). Else, more memory or paid features or whatever for the firewall to hold more connection states. Or maybe it can be configured to pass all of this particular traffic without any TCP connection management features. Look at TCP packets on each side of the firewall for the IMAP service and see if the sequence numbers or even source port numbers are different.