Ilja Booij <[EMAIL PROTECTED]> said: >Paul said: >> 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?
I rather disagree that code to handle \r\n or \n-only should be any more complex. Or, at the very least, that it should be intrinsic to a low level enough handling routine that everywhere else the code doesn't need to care what the line endings are. *Real* parsers would have no trouble with this. The problem is that our current MIME handler is an over-extended hack that chokes on unexpected input and just about every corner case it can find. That's not to bash on Roel's code any more than is absolutely necessary, though :-P It's been my assumption for a while that GMIME would be able to handle both line endings. Ah, assumptions. We should probably make sure that it's true! Aaron --
