On Tue, 05 Oct 2004 21:50:07 +0200, Paul J Stevens <[EMAIL PROTECTED]> wrote: > Aaron, > > talking about the mime parser: why did you split rfcsize in to rfcheadersize > /rfcbodysize. I can't seem to > find them being used separately. I'll lump these two together and fix the > signatures accordingly where they > are passed around.
Do you mean the rfcheadersize variables defined in struct mime_message_t in dbmailtypes.h, or the body_rfcsize and header_rfcsize in the split_message() function in header.h? If you mean the latter: That was my doing. If I remember correctly, I first had some code that did use those variables separately, but later changed this. They can be thrown together without any problem as far as I can see. > > Do I understand correctly to assume that rfcsize as defined in the code is > the messagesize where the message > was converted to crlf lineendings ? I have some clean code from gmime to > split the message in messageblks and > get the rfcsize. I will see if I can get this into cvs-head nice and clean. Yep, rfc size is size, given \r\n line endings. Currently, we store messages in \n line endings. This is because of the following, historical reason: The pipe interface (dbmail-smtp) gives us \n line endings. However, whenever a message is being fetched (POP or IMAP), \r\n has to be added to all lines. It would probably make sense to store our messages in \r\n format (LMTP already hands us the messages like that). Of course, given the fact that current DBMail installations have messages stored as \n, we need 1. A conversion tool or 2. Code capable of handling both formats. option 2 is kind of backwards, because it would make code more complex, instead of simpler. Any thoughts on this? Ilja
