Re: X-Spam-Status leaking into mail bodies

[Dan Nelson]

In the last episode (Mar 16), Carl Brewer said:
> I recently ugraded to spamassassin 3.1.1, which introduced a change
> in how headers are dealt with, which leads to headers leaking into
> mail bodies.
> 
> Excerpt from my discussion on the spamassassin mailing list.
> 
> (Theo Van Dinter) :
> >The problem is caused by a specific feature that was added into
> >SpamAssassin in 3.1.1 -- namely that we'll use the same line endings
> >that the original message uses (LF vs CRLF).  spamass-milter relied
> >on the previous behavior (always use LF), which happened to work
> >well with what libmilter expected.

Libmilter should be expecting CRLF, I think, since that's what RFC 2822
messages use.  Not that it ever sees EOLs except within the message
body, though.  Headers are just text strings with no EOL markers (
http://www.milter.org/milter_api/xxfi_header.html ).

The only way a header could leak into the body would be if spamassassin
added a LFLF or CRLFCRLF pair to a header line, since that's what
spamass-milter uses to detect the header/boundary border.

The messages spamass-milter generates for spamassassin to process
always have CRLF-trailing headers.  The message itself isn't touched,
although it's probably also CRLF-encoded since that's RFC 2822. 
Headers retrieved from spamassassin are parsed by looking for LF and
stripping a preceding CR if it exists, so it should be pretty tolerant
of whatever spamassassin decides to do.

If you run spamassassin with the '-d spamc' flag, you should be able to
see the raw data sent to and received from spamassassin.

-- 
        Dan Nelson
        address@hidden