2.3.8 traditional murder POP3 proxy

[Ken Murchison]

Shawn Nock wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> We rolled out 2.3.8 a few months ago (configuration specifics are at the
> end of the message)... and for the most part things have gone very well
> (After Bron solved our Reiserfs deadlock problem... he finds all the
> good bugs!)
> 
> A persistent problem in the new config is Outlook 2003 clients using POP3.
> 
> Short summary: Outlook 2003 (with all available updates) intermittently
> (about est. 10-15% of sessions) gets confused and, in turn, confuses our
> frontend. Client software in three confirmed cases is Outlook 2003 SP2
> using POP3 SSL on alternate port. Failure rate seems not be related
> statistically to message size, content, or total message count.
> 
> Protocol logging reveals that the client successfully connects and list
> messages in the box. The client then starts receiving messages. In the
> middle of a message the session stalls. Pop3d sits in select() waiting
> for input to be available on the socket to the client, the client (also
> apparently waiting for input) reaches timeout and bails on the
> connection. The frontend keeps the backend connection to the backend
> alive for 10min (ala RFC) even after the client gives up.

Has the backend completed sending the response to whatever command 
client the client sent?

Are all of the documented cases using the same SSL/TLS cipher?


> It seems clear that the "problem" is an outlook bug.

How did you determine that its an Outlook bug?  Not that I'm anxious for 
it to be a Cyrus one.


> Manually unlocking
> the box and "send/receiving" w/ outlook will cause the problem again (at
> the same point in the same message). If outlook is restarted however,
> the next session will function successfully.

Is the point at which it gets "stuck" a consistent amount of data sent 
either way?


> My real question to the cyrus list (surprisingly, it isn't "can you fix
> outlook"). Is two fold:
> 
> 1. Looking at the code, if the client side of bitpipe is closed... I
> can't see a scenario where the backend of the bitpipe is kept alive. The
> clean up code seems pretty much bullet proof, yet the behavior I am
> seeing is that the client side of bitppipe is closed and the connection
> to the backend is left open until POP3 timeout (what I see is pop3d on
> the backend waiting on select(). What could cause this? (*note* I doubt
> seriously that resolving this question will do anything to ease the
> symptoms of this bug in outlook).

Don't know, I'll have to take a look.


> 2. Are other large sites using a (traditional) murder configuration
> seeing problems like this? I'd imagined that a bug this annoying in
> Outlook, combined with the large number of Cyrus-imapd deployments,
> would have raised quite a few alarms... but in my searches I find no
> mention of this issue.

To my knowledge, we haven't seen this at CMU, but we don't "officially" 
support Outlook, and I don't think we have a ton of POP3 users.

UMich has a larger install than us, but I'm sure they would have 
complained by now.


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University