Igor Brezac wrote:


On Mon, 10 Jan 2005, Nikola Milutinovic wrote:

Igor Brezac wrote:

Check the imapd.conf man page for debug_command. This may help you.



Good advice, but for some other occasion, see below.

What puzzles me is that this is OE specific. Mozilla works like a charm. And this is not 100% OE sessions, I'd say it is some 20-30%. So, one time out of three, OE will get itself kicked out, the user will not notice anything, since OE will start another and that's it.



Can you look at the traffic between OE and cyrus? You can also turn telemetry log on and see if cyrus will log some of that stuff for you.


Is it possible this is sasl problem? What mechs do you have enabled?



I have all possible mechs enabled.

So, I took "ethereal" and started one session from one of the offending machines.

The session shows one strange thing, OE starts 2 threads!

First, it starts one thread which normally communicates with IMAP server, authenticates and gets to IDLE command. And then nothing. Then about that


Do you run idled?


Yes.

time, it starts another thread which, again, authenticates and does all normal stuff, like

IDLE
SELECT
FETCH
and
LOGOUT

The first thread actually ceases to exist after or about the launch of the other thread. Is the launch of the second thread the cause or the effect of the first one dying is beyond me.
I don't think that attaching a debugger would help. What I see in logs is that IMAP reports "connection reset by pear"
and I expect to see the same thing with the debugger. What troubles me is that it happens on EACH new connection. Close OE and start it up again, the same thing - two threads, first one dying.


Do you still think it would be helpful to use a debugger?


Yes. You still do not know why the first process (imapd) is dying.


At this point I'm not exactly sure it is dying.

Am I wrong in blaming the MS OE?


It is possible, but imapd should not dump because of a poorly behaving mail client.


True, but what should the log look like in case OE or any other client just decides to cut the TCP connection? I mean, no "LOGOUT", but just "tcp_stream.close()" in the middle of the session?

I should be able to free one IMAP server soon and direct just one OE at it for a closer look.

Nix.
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Reply via email to