dovecot - Mar 2008 - Cingular/ATT killing my IMAP/POP connections with bad TCP FIN packets?

Hello all,

I've got an issue I'm almost positive is not related to Dovecot, but was
wondering whether anyone else has had similar problems or could 
duplicate my results.  Please accept my apologies if this is considered 
off-topic or this issue is actually just a symptom of my own ignorance.  
Also, sorry for how long this email got, I knew I wouldn't be able to 
explain my issue in a paragraph.



I'm having issues connecting to my dovecot mail server, running with SSL 
under Solaris while connected via Cingular/ATT wireless, specifically 
via the wap.cingular access point.  This server is not firewall, either 
via software or hardware and sits on a fully routable internet IP 
address.  A few days after we made the transition from UW-IMAP to 
Dovecot, I could no longer connect from my Nokia E61i to our server 
(IMAP w/ SSL, port 993).  Until today, I just assumed I did something to 
anger the Nokia gods and just did without mobile email.

Today, someone walked in with an iPhone and could only connect to our 
server via wifi connections, not over Cingular/ATT's EDGE network.  When 
I looked into it, I saw the same behavior with my E61i which also has wifi.

Here's where it gets weird.  I can connect to other IMAP servers 
(imap.gmail.com, mail.columbia.edu) but not to our departmental mail 
server running dovcot (paradox.psych.columbia.edu).  All three are on 
port 993 using IMAP with SSL.  Ping, SSH and web traffic don't have any 
difficulty getting through, but IMAP/POP seems to be prematurely 
disconnected.  So I did a little digging, by tethering my Macbook with 
Thunderbird through my phone I saw the following traffic in Wireshark 
between me and my server (Paradox):

Me: SYN
Paradox: SYN, ACK
Me: ACK
Me: Client Hello
Paradox: ACK
Paradox: FIN, ACK
Me: ACK
Paradox: FIN, ACK
Me: ACK
-dead-

Maybe I'm misunderstanding something here, but it looks likely that ATT 
is sending a FIN which kills the connection before my mail client can 
even get out of the gate.  I thought it might be related to SSL so I 
setup a inetd to launch a secondary dovecot process listening on port 
997 without encryption.  I see the same behavior, without the "Client 
Hello" above.  I've also run it on other ports and seen the same 
behavior.  Needless to say, both SSL/noSSL work without issue from local 
and a variety of remote networks, except ATT.  Tomorrow I'll do some 
sniffing to confirm that Cingular is sending a fake TCP FIN packet, but 
I've got to wait till the network folks set me up a port in mirror mode.

I did not paste the full Wireshark output as it has long lines which 
would look hella ugly in email, so here it is nicely formatted:
http://duckies.org/~peter/damncingular.txt


Has anyone else seen similar behavior or know what might be causing 
this? It looks like ATT/Cingular is killing the connection before it 
really ever even gets started, but I have no idea why.  I've spent a 
couple hours on the phone with them and not been able to contact anyone 
who might know why this just started happening when it had been working 
before.

Can anyone replicate the same behavior, you shouldn't need an un/pw as 
it doesn't get that far, just need an ATT customer with tethering setup 
to capture an attempt at connecting to the server 
(paradox.psych.columbia.edu).

Ideas? I'm totally stumped, but it sounds a lot like the sort of thing 
Comcast was doing to Bittorrent for their users, except they were 
injecting RST instead of FIN.

Thanks in advance for any help anyone might be able to offer me.
--Peter

On Mon, Mar 10, 2008 at 08:12:37PM -0400, Peter Tripp wrote:

  Hello all,
  
  I've got an issue I'm almost positive is not related to Dovecot, but
was
  wondering whether anyone else has had similar problems or could duplicate 

  Me: SYN
  Paradox: SYN, ACK
  Me: ACK
  Me: Client Hello
  Paradox: ACK
  Paradox: FIN, ACK
  Me: ACK
  Paradox: FIN, ACK
  Me: ACK
  -dead-
  
  http://duckies.org/~peter/damncingular.txt

I notice a 6-7 second delay between the first ACK and the first FIN,ACK.
Is your dovecot server perhaps unable to do a DNS lookup on the connecting
IP?  It would be very informative to see what the dovecot server is sending
(or not sending) including generated traffic such as DNS queries, if you 
can isolate that.  Is anything in the dovecot logs?  Wondering if it is 
related to something like tcp wrappers.