On Tue, Jun 1, 2010 at 12:58, Del Stoliker <dstoliker@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 restart
It 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.