[Scspamcop] Re: new twist on unreportable spam

[Mike Easter]

Gary wrote:
> The tracking URL that I reported today's spam from my POP3 account is
www.spamcop.net/sc?id=z2386669421z8fd318d1b9845e8082b9e74e1658f7f0z.

That is a spam which SC refuses to parse for notify because it is
deficient in header elements.  There is no subject, To, from, date, or
messageid.  Besides the 3 Xlines, there are 6 'other' header elements
besides the Received tracelines, but not the basic ones which SC
'requires' (looks for).

> The tracking URL for the Google Mail version of the message is
www.spamcop.net/sc?id=z2386822367z57a73f2991003585a733df61231c37fdz.

That is a spam which SC parsed and which is not deficient in header
elements.  It has all of:  subject, To, from, date, messageid, + 10 Xlines
and 9 other header elements besides the Received tracelines.

These 2 html spams are similar in that the payload is a b64 encoded .jpg
whose name is ful.jpg and they are sourced from the same IP, but they are
not identical -- separate from the difference in the header elements.

> The report from the Google Mail version is what I would expect.
>
> A couple of questions:
> 1. Why can Spamcop parse the Google Mail version properly?

Its headers are properly populated with elements which SC expects;  looks
for and requires.  SC doesn't expect much, but the spam can't be deficient
in _all_ of the headerlines that SC looks for.  It needs to have at least
one.

> 2. Please confirm that the Google Mail version does not implicate Google
> Mail as a spammer. I don't think that it does.

Neither the source nor spamvertiser determination implicate gmail.




-- 
Mike Easter
kibitzer, not SC admin