Re: [Dbmail-dev] Delivery status in pipe and getopt support in main.. again

2004-02-26 Thread Ilja Booij
Hi, I guess I've found a reason why I got crashes and you didn't. I triggered a bug in bounce.c, because I was trying to send mail to a user whose mailbox would overflow. The trace message which logs the reason of the bounce had a typo, missing a comma between the string and the __FILE__

Re: [Dbmail-dev] unable to read mail on 2.x

2004-02-26 Thread Paul J Stevens
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.

Re: [Dbmail-dev] Error in calculation of mailbox-size

2004-02-26 Thread Ilja Booij
Found the problem. Using the new delivery chain, the size of a message is never stored, so the total size of the message (as stored in the messagesize field in the physmessage table) is only the size of the header. Aaron, could you take a look at this? I guess the total size of the message

Re: [Dbmail-dev] Delivery status in pipe and getopt support in main.. again

2004-02-26 Thread Aaron Stone
I just tried half a dozen -W...format... variations and could not get this error reported :-\ Looks like the problem is GCC doesn't believe that trace() is in the printf() family. Convince it of that, and the errors should abound. Turn on -pedantic and -std=c99 to get some interesting warnings,

RE: Re: [Dbmail-dev] Error in calculation of mailbox-size

2004-02-26 Thread Jesse Norell
Aaron, I've not looked at the delivery code, but in this you'd needd to make sure that any \r\n's were stripped to just \n when the message is saved. If that's not done, then you just need to add the number of header/body lines that had only \n (hence the imap server will change to \r\n), not

RE: Re: [Dbmail-dev] Error in calculation of mailbox-size

2004-02-26 Thread Aaron Stone
Which is to say, that some messages will arrive with \r\n and some with just \n, and we need to accept both of these, but when displaying a message, everything is sent as \r\n... which leads me to wonder if I should be *counting* the non-\r\n lines, or simply converting them to \r\n upon receipt,