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?
>>>> 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 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
------------------------------------------------------------------------------
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
