[Dovecot] very frequent disconnections
I've installed dovecot 1:1.1.11-0ubuntu4.1 on my jaunty system. Access from the same host works well, but when I access remotely (from various MUAs and networks) I get *very* frequent disconnects. Authentication is fine, and I can usually open a mail folder, but larger operations such as copying 20 messages into an imap folder always get disconnected.
I can reconnect, but I often get disconnected again in a few seconds, especially if I do more than very light access.
I've enabled all the logging I'm aware of, but I don't see any explanations. I get things like
Oct 7 20:19:38 jdc dovecot: auth(default): new auth connection: pid=390 Oct 7 20:19:39 jdc dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=imap^Isecured^Ilip=129.100.75.85^Irip=65.95.132.250^Ilport=143^Irport=62044^Iresp=<hidden> Oct 7 20:19:39 jdc dovecot: auth-worker(default): pam(jdc,65.95.132.250): lookup service=dovecot Oct 7 20:19:39 jdc dovecot: auth-worker(default): pam(jdc,65.95.132.250): #1/1 style=1 msg=Password: Oct 7 20:19:39 jdc dovecot: auth(default): client out: OK^I1^Iuser=jdc Oct 7 20:19:39 jdc dovecot: auth(default): master in: REQUEST^I2^I367^I1 Oct 7 20:19:39 jdc dovecot: auth(default): passwd(jdc,65.95.132.250): lookup Oct 7 20:19:39 jdc dovecot: auth(default): master out: USER^I2^Ijdc^Isystem_user=jdc^Iuid=1000^Igid=1000^Ihome=/home/jdc Oct 7 20:19:39 jdc dovecot: IMAP(jdc): Effective uid=1000, gid=1000, home=/home/jdc Oct 7 20:19:39 jdc dovecot: IMAP(jdc): maildir: data=~/Maildir Oct 7 20:19:39 jdc dovecot: IMAP(jdc): maildir++: root=/home/jdc/Maildir, index=, control=, inbox=/home/jdc/Maildir Oct 7 20:19:40 jdc dovecot: IMAP(jdc): Connection closed bytes=303/1423
and
Oct 7 20:43:54 jdc dovecot: auth(default): new auth connection: pid=6620 Oct 7 20:43:55 jdc dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=imap^Isecured^Ilip=129.100.75.85^Irip=65.95.132.250^Ilport=143^Irport=62633^Iresp=<hidden> Oct 7 20:43:55 jdc dovecot: auth-worker(default): pam(jdc,65.95.132.250): lookup service=dovecot Oct 7 20:43:55 jdc dovecot: auth-worker(default): pam(jdc,65.95.132.250): #1/1 style=1 msg=Password: Oct 7 20:43:55 jdc dovecot: auth(default): client out: OK^I1^Iuser=jdc Oct 7 20:43:55 jdc dovecot: auth(default): master in: REQUEST^I5^I6594^I1 Oct 7 20:43:55 jdc dovecot: auth(default): passwd(jdc,65.95.132.250): lookup Oct 7 20:43:55 jdc dovecot: auth(default): master out: USER^I5^Ijdc^Isystem_user=jdc^Iuid=1000^Igid=1000^Ihome=/home/jdc Oct 7 20:43:55 jdc dovecot: imap-login: Login: user=<jdc>, method=PLAIN, rip=65.95.132.250, lip=129.100.75.85, TLS Oct 7 20:43:55 jdc dovecot: IMAP(jdc): Effective uid=1000, gid=1000, home=/home/jdc Oct 7 20:43:55 jdc dovecot: IMAP(jdc): maildir: data=~/Maildir Oct 7 20:43:55 jdc dovecot: IMAP(jdc): maildir++: root=/home/jdc/Maildir, index=, control=, inbox=/home/jdc/Maildir Oct 7 20:44:00 jdc dovecot: IMAP(jdc): Disconnected in APPEND bytes=1081/1965
The output of dovecot -n is:
1.1.11: /etc/dovecot/dovecot.conf
OS: Linux 2.6.28-15-generic x86_64 Ubuntu 9.04
log_timestamp: %Y-%m-%d %H:%M:%S ssl_cert_file: /etc/ssl/certs/dovecot.pem ssl_key_file: /etc/ssl/private/dovecot.pem verbose_ssl: yes login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login login_greeting_capability: yes max_mail_processes: 25 mail_max_userip_connections: 20 mail_privileged_group: mail mail_location: maildir:~/Maildir mail_debug: yes maildir_copy_preserve_filename: yes auth default: verbose: yes debug: yes passdb: driver: pam userdb: driver: passwd
The clients I have tried are Gnus (with starttls and gnutls-cli) and evolution, on a jaunty system; and k9mail-beta on an HTC Dream cell phone. All four configurations show similar connection issues, and the jaunty client system has a solid DSL connection to the server. The clients don't have informative error messages either. To them it just appears that the connection was closed.
Any idea what could be causing this? Or how to debug it?
Thanks,
Dan
-- Dan Christensen jdc@uwo.ca
Dan Christensen <jdc@uwo.ca> writes:
If I configure dovecot to listen on a different port, I don't have these troubles. So I suspect some network throttling of imap data somewhere. My contact at the university doesn't think this happens, and I'd be surprised if my ISP does this, but I can't think of any other explanation.
Dan
On Wed, 2009-10-07 at 20:55 -0400, Dan Christensen wrote:
Oct 7 20:19:40 jdc dovecot: IMAP(jdc): Connection closed bytes=303/1423 Oct 7 20:44:00 jdc dovecot: IMAP(jdc): Disconnected in APPEND bytes=1081/1965
The connection just got closed from Dovecot's point of view.
Have you tried without SSL?
Anyway I can't think of anything besides some weird network issue or maybe some firewall/antivirus in the middle.
Some clients also support "imap over ssh", you could try that. Basically use "ssh server dovecot --exec-mail imap" as the command.
Timo Sirainen <tss@iki.fi> writes:
The very frequent dropped connections don't happen if I don't use TLS. To summarize:
- they happen with TLS to port 143
- they don't happen with a plain connection to port 143
- they don't happen with a TLS connection to port 11143
- they don't happen if I connect using ssh jdc.math.uwo.ca dovecot --exec-mail imap
Very strange. I can trigger the drop 100% of the time by copying 20 or 30 messages from a local folder to a remote imap folder.
Anyway I can't think of anything besides some weird network issue or maybe some firewall/antivirus in the middle.
Could be. But now it's clear that it's not affecting all traffic to port 143, only tls traffic. Weird.
Some clients also support "imap over ssh", you could try that. Basically use "ssh server dovecot --exec-mail imap" as the command.
That works well and is also quite fast to connect, so I'll probably stick with it.
Thanks for the help,
Dan
On Fri, 2009-10-09 at 16:09 -0400, Dan Christensen wrote:
This clearly indicates some firewall/antivirus/IDS in the middle believing that port 143 only has plaintext traffic and then get entirely confused when they see TLS traffic and at some point decide to kill the connection. I guess using imaps on port 993 would also fix it?
participants (2)
-
Dan Christensen
-
Timo Sirainen