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 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.
Aaron Stone wrote:
Paul J Stevens <[EMAIL PROTECTED]> said:
Ok so probably the mimeparser is adding spurious \r characters
in the string send to the client.
What's your take Aaron?
Yep, it's in the MIME parser. Somewhere, in the MIME parser. Early in the
2.0rc series, I had a fairly elegant and unified mechanism for receiving
messages, but the \r, \r\n, \r\r\n, etc. problems with the MIME parser
forced us to change to much heftier code that handled messages differently
if they came in over the network or from stdin.
Once we move to a more robust MIME parser in 2.1, we'll be able to throw
differently formatted messages at it and get better results. As for 2.0,
we'll just have to figure out a robust hack...
Aaron
--
_______________________________________________
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
