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

[Mike Easter]

Mike Easter wrote:
> Andrzej Filip wrote:

>> Spamcop has "found" Received headers to parse *inside*
>> "X-SA-Preview:" header.
>
> You are correct that SC tried to make something out of what the XSA
> was junking up the headers with.

I'm going to revise and amend/extend some of my remarks.

> There's too much noncompliance in the original headers and the junked
> up XSA headers your mailserver added and whatever SC tried to do with
> the mess to try to make any sense of it.

I understand better now that I see what the pnbon MX did with the
original item.

> If I remove all of the extra headers which have been added by various
> servers since the beginning, what I see at the bottom is a spam with
> noncompliant headers and noncompliant construction vis content-type
> and also boguslines.

The original spam has boguslines.  It was designed to look like it was
from homeunix.  Its content type construction isn't noncompliant or
disparate, it is simply html and it did not originally have boundary
delimiters until pnbon added them above and below the original ps/so.

> We'll call that bottom headers item 'subject psegnahc from sofyan' or
> ps/so for short.  That spam item is a big mess in terms of its headers
> and body before the rest of sthe mess started happening to it and then
> the pnbon server messed up its construction some more by attaching
> things above and below it.

It had 2 bogus Received tracelines when injected.  Otherwise its
structure was OK.

> That server stamps its headers badly all over the place and calls
> itself noncompliantly, but it received and accepted the ps/so spam for
> delivery.

The Received traceline it stamped when it received the original ps/so
item was noncompliant because it was calling itself local in the 'by'
field, but that's not really so bad because that item wasn't actually
going 'out'.  It was a 'temporary' stamp.

> The pnbon server is the one which created all of the boundary
> delimiters above and below the original item, as the original spam
> had none.

That's what initially fooled me about thinking how noncompliant the
header content type vs actual body construction appeared to be a
mismatch -- but that appearance was caused by the extra parts added by
the pnbon server.

The pnbon server isn't listed anywhere yet for backscatter.

-- 
Mike Easter
kibitzer, not SC admin