[Scgeeks] Re: [Bug] headers parsing bug [extra Received: headers found]

[Andrzej Filip]

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

Mike Easter wrote:
> Andrzej Filip wrote:
>> Mike Easter wrote:
> 
>>> The reason SC erred by trying to rearrange the whitespace of the XSA
>>> line which contained a standard Received traceline content which was
>>> 'mangled' in the opinion of the algo was because the algo is 'taught'
>>> how to handle many different kinds of suboptimal header submissions.
>>>
>>> You Andrzej are not going to be able to convince the algo coder to
>>> dumb down the algo so that it won't misparse your wild XSA preview
>>> lines when those lines are all junked up with header elements which
>>> don't belong up there in a header field value.
>> Look at the *original* submission:
>>
> http://www.spamcop.net/sc?id=z1574530141zb39c8a082e6c406ee01039820dfd8f34z;action=display
> 
> I did.  I still think that the XSAPreview field in this example is a
> 'mess' and I'm not very sympathetic about SC messing it up some more.
> 
>> The problem is that spamcop "parsed" content of "X-SA-Preview:" -
>> the header should be simply skipped.
> 
> And I think that xsapreview shouldn't be copying all of that header
> information from the mailbody about a header up into a different header
> a field.

The X-SA-Preview: header contains "preview" generated by SpamAssassin.
I include it to help make spam "more readable".

- --
[pl>en: Andrew] Andrzej Adam Filip : anfi at priv.onet.pl : anfi at xl.wp.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHasa3qmxEvGofXN0RAszPAJ4ozTCxJVeqPKRi7DTXFJlolZAGJgCdFutv
H4alwv8kWHxK2GiNc170rA8=
=j/Dq
-----END PGP SIGNATURE-----