Re: SPAMassassin headers missplaced and follow message body

[Justin Mason <jm...@jmason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


BTW I've seen some similar messages -- as far as I can see, when it
happens in my case, it's one of postfix, procmail or my MUA which is
interpreting the message structure wrongly due to the whitespace
wierdness.

Since SpamAssassin 3.1.0 now puts the X-Spam headers at the *start* of the
header block, it's ceased to be a problem for me. ;)

- --j.

Eric A. Hall writes:
> On 5/11/2005 2:51 PM, Kevin W. Gagel wrote:
> >>On 5/11/2005 6:58 AM, Martin G. Diehl wrote:
> 
> >>I haven't really looked into this much yet, but it appears
> >>that some embedded CR or LF characters are getting
> >>processed by SA and then fed back to Postfix, which then
> >>cleans up the message and splits the headers where it sees
> >>the bare CR or LF. The result is two sets of headers, the
> >>second of which naturally becomes part of the body.
> > 
> > SpamAssassin does not alter the message.
> 
> Like I said, I haven't really looked into very closely and I don't know
> who's doing the conversion of bare CR/LF into CRLF pairs.
> 
> How sure are you that SA doesn't do conversion?
> 
> I don't have much doubt that postfix cleanup is doing this, but frankly it
> seems more likely to be SA.
> 
> > All MTA's will interpret the first blank line as the
> > begining of the body.
> 
> No kidding. The problem we are seeing happens when there is a EOL marker
> at the end of a header, and when that is cleaned up we have two CRLF pairs
> all of a sudden, with all of the headers which follow suddenly being part
> of the message body.
> 
> Trying to figure out who/where this is happening is the exercise
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFCglz7MJF5cimLx9ARAttZAKClcjxUwxqdL5OyTGjSuvsS43/NrQCfWYmA
88TpYJN9qSmmoaRJXGE46Js=
=m7tx
-----END PGP SIGNATURE-----

Re: SPAMassassin headers missplaced and follow message body

["Eric A. Hall" <eh...@ehsco.com>]

On 5/11/2005 3:28 PM, Justin Mason wrote:

> BTW I've seen some similar messages -- as far as I can see, when it
> happens in my case, it's one of postfix, procmail or my MUA which is
> interpreting the message structure wrongly due to the whitespace
> wierdness.

That's possible too, if whitespace is wrapped improperly it can be read as
a blank line.

My setup is arranged so that postfix SMTP recieves the mail, hands it off
to spamassassin while the session is still open, and then examines the
message that comes back from SA for header flags. If the headers show that
the message is spam, then postfix rejects the message, but otherwise
accepts the mail and then hands it off to cleanup agent.

Looking at the headers that come in and out of spamassasin is what leads
me to believe that it's doing the mangling. In particular, we can assume
that SA didn't see the blank line in the headers that it read (or else it
would have appended the lines at the end of the top block, not the second
block), so it seems kind of likely that "writing a new headers block" is
what causes the conversion to happen, and results in CR/blanks/whatever
getting turned into a blank line.

OTOH, I know that postfix does some cleanup before it performs analysis
(it adds Message-ID and does other stuff), so it is entirely possible that
it is doing a CR/null conversion as part of that.

Very annoying whatever it is

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/