[Scspamcop] Re: Possible Error In Spamcop Parsing of Headers

[Mike Easter]

Blue Rock wrote:

> Here is what Spamcop said about the headers:
>
>    0: Received: from mail.sunshinecable.com

The 0: numbering of the verbose lines means that you are a mailhosted
account.

>    dreamhost received mail from sending system 209.52.200.3

That is the last 'good' Received traceline, from the SC algo's
perspective.

>    Internal handoff by trusted site 209.52.200.3

The term 'trusted site' means in this context that the
mail.sunshinecable.com which resolves both ways is trusted/known to be a
mailserver -- because SC has encountered it before and has become familiar
with it and has already sent it to the relay testers for testing as an
open relay.

It does not mean that the server hasn't be used to relay spam or anything
else -- just that it is a known mailserver, and SC's target is not the
output server for a spam, but instead the target is the user IP behind the
output server.  But the sunshinecable server doesn't provide a userIP
behind the server, so SC is only able to chain the headers back to the
output server, because all of the other tracelines are 'no good' for algo
chaining, as they only contain non-routing IPs.

Here's where you go to login to use the horde webmail server for
sunshinecable  http://mail.sunshinecable.com/horde/login.php

... but I don't think that is how the item was injected, because normally
a mail injected there looks like this example at PSBL
http://psbl.surriel.com/evidence?ip=209.52.200.3&action=Check+evidence

Your spam's headers are different from the PSBL headers, which show the
source IP behind the sunshinecable server.  Perhaps there is some other
website that uses the same sunshinecable server which has been hacked via
formmail or something.

>    Internal handoff at dreamhost

I disagree with those words which are /located/ under 2:

> What makes mail.sunshinecable.com a "trusted site"?

Trusted site = recognized/known mailserver, previously seen and submitted
to relay testers.

> The third header (2:) is the really puzzling one.  Why does it say that
> this was an internal handoff at "dreamhost"?  Dreamhost is my own
> domain host. At that point in the header chain, the message should have
> been in sunshinecable's system.  Dreamhost has never added headers for
> internal handoffs like this, in any message I have received.  And it
> has never added a header that would be out-of-sequence like this.

You are correct sir.  Those SC words in the verbose are outawhack as I
mentioned above.  However, if you lose the words, the parse went as
expected.

> In the end, it looks like the spam was correctly reported to
> sunshinecable.com, despite the messed-up interpretation of the headers.
> But, I wanted to call this to the attention of someone at Spamcop,
> because it suggests an error in the parsing algorithm (where it thinks
> that third header was somehow linked to Dreamhost).

SC has a history of putting words into the verbose seemingly in the wrong
places.  When you are reading SC verbose, you have to mentally say
something like, "SC probably was just now saying something that it was
thinking earlier, further up."



--
Mike Easter
kibitzer, not SC admin