On Tue, 10 Sep 2002 17:22:35 +0200 Xavier Nodet <[EMAIL PROTECTED]> wrote:
XN> In pop3.c, there is a function XN> unsigned long pop3_cache (MAILSTREAM *stream,MESSAGECACHE *elt) XN> XN> One line of this function is XN> LOCAL->txt = netmsg_slurp (LOCAL->netstream,&elt->rfc822_size, XN> &LOCAL->hdrsize); XN> XN> This netmsg_slurp function creates a temporary file to hold the whole XN> message. But the connexion goes down before a single byte can be XN> received (in fact, it is the sending of the RETR command that makes the XN> connexion go down, I believe). I didn't see this from the log file you sent, but maybe you're right... XN> So it returns a handle (stored in LOCAL->txt) to an empty file. This XN> emptiness is shown by the fact that elt->rfc822_size (the total size of XN> the message, if I understood correctly) is equal to 0. Yes, it's indeed the total size. If it's set to 0 it means that we don't have the message (yet) for c-client. XN> The problem, IMO, comes from the fact that pop3_cache is called from XN> pop3_text, which only checks for LOCAL->txt, but not for the size of the XN> retrieved message. Or, alternatively, the problem is that netmsg_slurp XN> should return a null file handle if there is a problem. I still don't see how could it result in messages having header from one message and body from another one though: in the situation you describe pop3_text() should return empty string, not a body from another message... You can try to simulate the connection by replacing netmsg_slurp() call with pop3_fake() call. Can you reproduce the problem in this way? Thanks! VZ ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
