Ive been doing some more testing and debugging on this problem. I think
the problem is in imap4.c
Client issues a close.
Server continues reading and writing on closed streams.
Client responds with RST packets.
Server barfs on EPIPE.
There is no check in the code before each read/write on whether the
stream is still open. I would guess that all read/write actions on the
streams should check their state.
Perhaps the fgets and fprintf call should be moved to wrapper calls that
do proper error handling. Any takers ?
Paul J Stevens wrote:
I've done some more testing. It's real simple to trigger this bug:
simply telnet on port 143 and quit without doing anything.
Even though the client sends a FIN,ACK to the server, the server still
responds with * BAD No tag specified. It should respond by closing the
streams instead.
Doesn't solve the problems with mozilla though :-(
Aaron Stone wrote:
What's an active close?
Going off on a tangent, I started reading over severchild.c to see what I
could see, and I noticed this big FIXME towards the end of
PerformChildTask()
db_disconnect();
auth_disconnect();
connected = 0; /* FIXME a signal between this line and the
previous one
* would screw things up. Would like to have all
this in
* db_disconnect() making 'connected' obsolete
*/
To prevent the signal problem, create a noop function and set it as the
universal signal handler right before the disconnection code. Any signals
coming in during the "critical shutdown zone" would basically be ignored.
Right, and now back to our regularly scheduled bug hunt ;-)
Aaron
Paul J Stevens <[EMAIL PROTECTED]> said:
As promised: I've zoomed in on a tcp session that goes haywire.
I've attached such a session in a pcap file: see attachment.
Looks like mozilla initiates an active close after receiving a 'OK
STATUS completed' but dbmail failes to properly close the session,
leading to the client sending RST packets that trigger the broken
pipe problem.
I guess serverchild.c needs some serious refactoring... :-)
Paul J Stevens wrote:
I don't really think its the acl stuff that's causing this. 1.2.3
has similar problems with mozilla type clients, it just got much
worse on 2.x.
I'll investigate and see what I can come up with.
Aaron Stone wrote:
I see this with Mozilla 1.6, too. In fact, it was driving me nuts
when I was
testing my latest patch because I thought I had ruined the delivery
chain...
only to try KMail instead and discover that things really were
working ;-)
Someone should sit down with a tcpdump or ethereal-type protocol
analyzer and
try getting to the bottom of this! KMail does not support the
Namespace
extension, and might not support ACL either. So something about one
or both
must be a little bit buggered, either by us or Mozilla; only a true
patch will
tell :-)
Aaron
""Blake Mitchell"" <[EMAIL PROTECTED]> said:
This sounds very similar to the problems I am having with
Mozilla/Thunderbird and 2.0rc2. Only access to the INBOX, doesn't
check for
mail when I tell it to, etc. So far my only solution has been to
use Outlook
:-/
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Paul J Stevens
Sent: Tuesday, February 24, 2004 8:18 AM
To: dbmail-dev@dbmail.org
Subject: Re: [Dbmail-dev] unable to read mail on 2.x
I'm guessing it's a client related issue.
This occurs when I access dbmail-2 from a thunderbird-0.5 client
that has several accounts with many folders configured.
I've also moved my dbmail-2 imap server around to a UML instance
on the same machine as my dbmail-1 server, and also to a totally
different machine in the same network.
In all cases: thunderbird triggers the closed pipe error, whereas
squirrelmail and ilohamail work just fine.
I've finally tested this with mozilla-1.6 with only one account:
same problem. One additional thing I noticed though: on first
accessing a new account, mozilla and thunderbird hang while
'Getting folder ACL'.
Closing and restarting the client gives me access to the INBOX,
but no other folders. weird...
I've tested with balsa and with sylpheed. Oops. Same broken-pipe.
No problems reading email though.
...
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
