That helped. Ethereal kicks ass :-)
What happens in your case:
Your clients sends a FETCH BODY.PEEK[..] command which requires dbmail
to retrieve and parse a *lot* of messages. While dbmail is happily
sending back the results, thunderbird sends a logout command which is
ignored by dbmail since it's busy. Dbmail keeps sending back results
where thunderbird is trying to close the socket, which in turn triggers
thunderbird into sending RST packets, destroying the socket.
Ilja: the return value from ci_write can in many cases be ignored but
probably be respected in most cases. Perhaps the ci_write wrapper should
be replaced by a macro like
#define CI_WRITE(fd, template, ...) \
if ((int result = ci_write(fd, templace, ...))
return result;
Blake Mitchell wrote:
Not to beat a dead horse, but I'm still curious about this, as it seems
to time out too quickly. So I did a tcpdump on the same operation I
posted the log from. It is here:
http://barkingspoon.com/imap.tcpdump.txt or
http://barkingspoon.com/imap.tcpdump for the raw tcpdump file. It looks
to me as if some of the header information is successfully transfered
back to the client, even though it never shows up there. Although I have
very little experience looking at packet logs, and none at all with the
imap protocol. Anyone more adept care to take a look?
Blake
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
