On 29.08.2011 20:54, SL wrote:
> Hello
Hello,
>>> I ran into an issue with my mail filtering which I solved by
>>> activating "Broken lineStripping", which converts any CRLF to LF
>>> from the input mail.
>>>
>>> I would like to know why LF is expected as a line terminator, in
>>> particular because I thought that a MTA would feed an RFC 2822
>>> compliant mail to dspam, therefore using CRLF.
>> I think RFC 2822 (and 2821) are using using CR followed by LF.
> Precisely :) The nominal case is CR followed by LF, so why does dspam
> require LF only?
Require? That is a hard word. DSPAM does not care at all abut line
terminator. The only time DSPAM cares about it is when it is sending the
message back over SMTP/LMTP or sending the message to the DSPAM daemon.
Otherwise DSPAM really does not care if you use CRLF or LF. Off course
this is more complicated than just what I have written regarding
SMTP/LMTP. As soon as DSPAM is adding headers things can get complicated
and you could end up in a mixed case of CRLF / LF. But for DSPAM it self
all this mambo jambo about the line terminator is not important.
>>> 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?
>> In daemon mode DSPAM will normalize the mail and replace wrong \n
>> with \r\n.
>> With Broken lineStripping DSPAM will remove broken ^M from lines
>> while reading the message stream line by line.
> What do you call "broken ^M"?
>
> From the read_stdin function in agent_shared.c
>
> /* Strip CR/LFs for admittedly broken mail servers */
>
> if (_ds_match_attribute(agent_config, "Broken",
> "lineStripping")) {
> size_t len = strlen(buf);
> while (len>1&& buf[len-2]==13) {
> buf[len-2] = buf[len-1];
> buf[len-1] = 0;
> len--;
> }
> }
>
> This converts CRLF to LF.
Yes.
>> If you have a mixed CRLF and LF in your message then your source
>> was/is already broken and it's not DSPAM fiddeling around with the
>> message at all. I say that because if you would use daemon mode
>> then for sure there would not be a mixed CRLF and LF because the
>> code would fix that into normalized CRLF.
> My mail is piped by imapfilter to procmail, from an IMAP dovecot
> server. It is RFC2822 compliant, that is with CRLF. Then my first
> procmail recipe is to pipe to dspam. There is no mixed CRLF and LF in
> the original message.
>
> Here's an example:
>
> $ cat -A testCRLF
> Message-Id:<1...@mail.net>^M$
> From: "Alice"<al...@mail.net>^M$
> To: "Bob"<b...@mail.net>^M$
> Subject: CRLF^M$
> Date: Sun, 28 Aug 2011 15:26:23 +0200^M$
> ^M$
> Test for dspam with CRLF^M$
Okay. I am going to use the same file to do the test.
theia ~ # cat -A testCRLF
Message-Id: <1...@mail.net>^M$
From: "Alice" <al...@mail.net>^M$
To: "Bob" <b...@mail.net>^M$
Subject: CRLF^M$
Date: Sun, 28 Aug 2011 15:26:23 +0200^M$
^M$
Test for dspam with CRLF^M$
theia ~ #
> $ cat testCRLF | dspam --deliver=stdout
> Message-Id:<1...@mail.net>
> From: "Alice"<al...@mail.net>
> To: "Bob"<b...@mail.net>
> Subject: CRLF
> Date: Sun, 28 Aug 2011 15:26:23 +0200
> :
> : st for dspam with CRLF
> X-DSPAM-Result: Innocent
> X-DSPAM-Processed: Mon Aug 29 20:33:44 2011
> X-DSPAM-Confidence: 0.9104
> X-DSPAM-Probability: 0.0000
> X-DSPAM-Signature: 4e5bdb88123901139819873
That looks IMHO wicked. What is that colon there? In my setup I get this:
theia ~ # cat testCRLF | dspam --user ste...@bajic.ch --deliver=stdout |
cat -A -
Message-Id: <1...@mail.net>^M$
From: "Alice" <al...@mail.net>^M$
To: "Bob" <b...@mail.net>^M$
Subject: CRLF^M$
Date: Sun, 28 Aug 2011 15:26:23 +0200^M$
X-DSPAM-Result: Innocent^M$
X-DSPAM-Processed: Mon Aug 29 23:15:10 2011^M$
X-DSPAM-Confidence: 0.9896^M$
X-DSPAM-Improbability: 1 in 9538 chance of being spam^M$
X-DSPAM-Probability: 0.0001^M$
^M$
Test for dspam with CRLF$
theia ~ #
>
>
>
> $ cat -A testLF
> Message-Id:<1...@mail.net>$
> From: "Alice"<al...@mail.net>$
> To: "Bob"<b...@mail.net>$
> Subject: LF$
> Date: Sun, 28 Aug 2011 15:26:23 +0200$
> $
> Test for dspam with LF$
theia ~ # cat -A testLF
Message-Id: <1...@mail.net>$
From: "Alice" <al...@mail.net>$
To: "Bob" <b...@mail.net>$
Subject: LF$
Date: Sun, 28 Aug 2011 15:26:23 +0200$
$
Test for dspam with LF$
theia ~ #
> $ cat testLF | dspam --deliver=stdout
> Message-Id:<1...@mail.net>
> From: "Alice"<al...@mail.net>
> To: "Bob"<b...@mail.net>
> Subject: LF
> Date: Sun, 28 Aug 2011 15:26:23 +0200
> X-DSPAM-Result: Innocent
> X-DSPAM-Processed: Mon Aug 29 20:37:48 2011
> X-DSPAM-Confidence: 0.8364
> X-DSPAM-Probability: 0.0000
> X-DSPAM-Signature: 4e5bdc7c124583687219774
>
> Test for dspam with LF
>
theia ~ # cat testLF | dspam --user ste...@bajic.ch --deliver=stdout |
cat -A -
Message-Id: <1...@mail.net>^M$
From: "Alice" <al...@mail.net>^M$
To: "Bob" <b...@mail.net>^M$
Subject: LF^M$
Date: Sun, 28 Aug 2011 15:26:23 +0200^M$
X-DSPAM-Result: Innocent^M$
X-DSPAM-Processed: Mon Aug 29 23:18:14 2011^M$
X-DSPAM-Confidence: 0.9896^M$
X-DSPAM-Improbability: 1 in 9538 chance of being spam^M$
X-DSPAM-Probability: 0.0001^M$
^M$
Test for dspam with LF$
theia ~ #
>
>
> $ 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$
> From: "Alice"<al...@mail.net>^M$
> To: "Bob"<b...@mail.net>^M$
> Subject: CRLF^M$
> Date: Sun, 28 Aug 2011 15:26:23 +0200^M$
> ^M: $
> Test for dspam with CRLF^M: $
> X-DSPAM-Result: Innocent$
> X-DSPAM-Processed: Mon Aug 29 20:38:51 2011$
> X-DSPAM-Confidence: 0.9761$
> X-DSPAM-Probability: 0.0000$
> X-DSPAM-Signature: 4e5bdcbb124921353114664$
> $
IMHO this looks like DSPAM is not capable to differentiate between
header and body of the message and is adding the header part into the
body (because it thinks there is no body part in your message).
>
> 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
> Thanks
> --
> Sylvain
>
>
Stevan
------------------------------------------------------------------------------
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
