On Tue, 30 Aug 2011 14:48:27 +0200, SL wrote:
> Hello
>
Hello,
>> DSPAM does not care at all abut line
>> terminator.
>
> Then I don't understand two things:
> - what is the purpose of the lineStripping option?
> - if line terminators don't matter, why does activating lineStripping
> fix my problem?
>
have you read the part where I have written that the line stripping is
only important when DSPAM is inserting headers and/or when DSPAM is in
the mode to classify/process messages (aka: NOT documents).
>>>>> When doing something like "cat myCRLFmail | dspam
>>>>> --deliver=stdout"
>>>>> (without Broken lineStripping of course), your mail is garbaged
>>>>> with
>>>>> a mix of CRLF and LF and added colons.
>>>> Added colons? Where? Usually DSPAM does not touch the message at
>>>> all
>>>> except two cases:
>>>> 1) You have turned on Broken lineStripping
>>>> 2) You are using DSPAM in daemon mode
>>> Well, I have this behaviour with Broken lineStripping commented
>>> out,
>>> and not using daemon mode.
>> So you are saying that DSPAM is modifying your original mail in such
>> a
>> way that at the end of the processing with DSPAM you have a mixed
>> CRLF
>> and LF line termination?
>
> Yes, as shown in the examples in my previous mail.
>
>>> $ cat testCRLF | dspam --deliver=stdout> dspam.out
>>> $ file dspam.out
>>> dspam.out: ASCII text, with CRLF, CR, LF line terminators
>>> $ cat -A dspam.out
>>> Message-Id:<1...@mail.net>^M$
>
> OK
>
>>> From: "Alice"<al...@mail.net>^M$
>
> OK
>
>>> To: "Bob"<b...@mail.net>^M$
>
> OK
>
>>> Subject: CRLF^M$
>
> OK
>
>>> Date: Sun, 28 Aug 2011 15:26:23 +0200^M$
>
> OK
>
>>> ^M: $
>
> NOK. After dspam processing, we end up having CR, then a colon, a
> space, and LF. I traced this down to decode.c line 995. The empty
> line
> between the header and the mail body contains CRLF. Mail lines are
> split
> with LF (decode.c 106), so the analysis is done on a line content of
> "CR" only. With verbose debug, this line raises a warning saying that
> this "CR" header line is missing a colon. That is because it was
> incorrectly fed to _ds_create_header_field in the
> _ds_actualize_message
> function.
>
> In _ds_actualize_message, the empty line between the header and the
> body is detected by this code:
> else if (line[0] != 0)
> {
> ds_header_t header = _ds_create_header_field (line);
>
> if (header != NULL)
> {
> _ds_analyze_header (current_block, header, boundaries);
> current_heading = header;
> nt_add (current_block->headers, header);
> }
>
>
> /* line[0] == 0; switch to body */
>
> } else {
> block_position = BP_BODY;
> }
>
> line[0] is CR, so 13, so passed for header analysis. I patched
> else if (line[0] != 0)
> into
> else if (line[0] != 0 && line[0] != 13)
> and it now works flawlessly (for both LF and CRLF cases).
>
>
> So, to answer my own question, lineStripping fixes the issue because
> it
> makes the mail go through the line[0] == 0 case. I don't know why my
> CRLF example works on your configuration, are you sure lineStripping
> is
> disabled?
>
I have lineStripping ENABLED.
>>> I observe this on Debian, running dspam
>>> 3.9.1~rc1+git20110514.347379b+dfsg-1.
>> Please use 3.10.x and do not use the older RC1 from 3.9.1
>
> I switched to 3.10.x (but it has not yet reached Debian testing).
> --
> Sylvain
>
--
Kind Regards from Switzerland,
Stevan Bajić
------------------------------------------------------------------------------
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
