On 31/08/11 07:43, SL wrote: > Hello > >>> Then you did not reproduce my test conditions. Please try a CRLF >>> message with lineStripping disabled. Do you get garbage? >> >> This is reproducable with git master/HEAD. I actually noticed this >> behaviour already last week while working on something else, but did >> not >> have time yet to look further into it. > > Thanks. > >>> If yes, please try my patch, still with lineStripping disabled. >> >> The nominal case is that incoming data has CRLF linefeeds, thus the >> empty line between headers and body contains CRLF. In decode.c, this >> means that this line contains CR. >> >> While processing the nominal input (CRLF) and not in daemon mode, >> this >> only works with Broken Linestripping enabled, which is not the >> default. >> Your patch fixes this, so I can only agree. > > Could you please take a little more time and tell me what you think > about this: I have the feeling the lineStripping option could be > completely removed, along with its code.
According to the documentation in dspam.conf and CHANGELOG "Broken lineStripping" is targetted at stripping (multiple) ^M's from message lines. It does this both in client and daemon mode. When checking the output of a CRLF'ed message with a multiline body, enabling lineStripping (not in daemon mode) replaces CRLF with LF on all lines in the body (i.e. after the CRLF line that separates header and body), and in linebreaks in multiline headers. The header lines keep having CRLF at the end. Note that this produces an output with mixed CRLF and LF lines while the input was CRLF only, which is not correct according to RFC, IIUC. I'm still not sure what the use case for adding this feature was, but it has nothing to do with fixing your issue. When run in daemon mode (and interrogated through dspamc --deliver=stdout), all linebreaks are converted to LF somewhere (with or without lineStripping enabled), so this issue does not occur at all. How this compares to the CRLF stuff in the RFC is unsure to me, but I've never seen issues with it, I think. > > I am asking because I don't really see a use case that would not > already be covered by the code. Your fix does not cover all aspects of the behaviour of lineStripping, we just don't know what use case lineStripping would have. Anyway, fixing your issue by applying your fix is fine with me, but removing the lineStripping feature altogether is something different. Fix was committed, thank you for reporting. -- Tom ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
