[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: X-Spam-Status leaking into mail bodies

From: Dan Nelson
Subject: Re: X-Spam-Status leaking into mail bodies
Date: Wed, 15 Mar 2006 23:05:54 -0600
User-agent: Mutt/1.5.11

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 ( ).

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]