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