[SC-Help] Re: Spamcop failing to detect true originating IP

[Ellen]

"wskrispy" <wskrispy at EXCISEoptonline.net> wrote in message
news:db3jt2$32l$1 at news.spamcop.net...
> Ellen wrote:
> > "wskrispy" <wskrispy at EXCISEoptonline.net> wrote in message news:db1fa1>
> >
> >>Here's a tracker from a spam that Spamcop choked on, complete with SA
> >>headers:
> >>
>
>>http://www.spamcop.net/sc?id=z785186974zfb5c4d04f5694f362a90b200bac251bfz
> >>
> >
<snip>
> >
> > You will have to discuss this with your ISP/hosting company admin/tech
> > support to find out what the problem is.  It may be that if some other
user
> > at the ISP/hosting company is sending the spam/virus/phish that the
headers
> > are as above as the mail was just shuffled around internally.
> >
> > Ellen
> > SpamCop
> >
>
> Thanks for the response, Ellen. I must say I'm a bit confused at this
> point. No doubt I need to bone up a bit more on spam lore, not to
> mention smtp basics, etc.,.
>
>  From one vantage point I'm almost tempted to say that, well, it looks
> like the spammer has outwitted Spamcop. You say "there is no way that SC
> has (can) determine the source of the spam". If that's so, wouldn't you
> agree the spammer has found a spoofing method that confounds Spamcop?

No I would say that your ISP/hosting company is not stamping adequate
Received headers for some reason and that has nothing to do with the spammer
outwitting SC.


> This server is a Virtual Private Server under a hosting company. I
> administer it for an artist's studio. I'm a retired programmer, not an
> Admin. But I know enough to get LANs up and running and to provide basic
> WWW/FTP/Email services and troubleshoooting for small businesses. As far
> as I can tell, this server is configured with typical options and its
> primary mailer program (Exim) is not writing anything unusual to emails,
> nor deleting or scrambling headers.

There is nothing that SpamCop - or anyone doing it manually -- can do to
determine injection if the Received headers are inadequate and these are
inadequate. That Received header is stamped by *your* hosting company. The
hosting company server is supposed to know and to include the IP of the
server connecting to deliver the email.


>
> On the other hand, the hosting company originally providing this VPS,
> after a period of good service, totally crashed and burned (as so many
> companies in the lower price tiers do) and was "merged" with a provider
> called "WebHostPlus". WebHostPlus has a shady past (it is apparently run
> by a group of NYC-area Russian emigrés with Russian-mobster-like
> business ties) and I have been meaning to move my client (the artist's
> studio) to a different provider. I wonder if WebHostPlus is low enough
> to sell a certain service to spammers whereby they can appear as an
> internal user to VPS accounts?

There is an old saying -- when you hear hoofbeats think horses not zebras.
It may be something as simple as a misconfigured server in their server
farm. It may be that if their backup MX is being used then for some reason
the proper headers areb't stamped. Who knows -- no one but them. Over the
years I have seen all sorts of oddball things and in 99.9% of the cases the
reason turned out to be misconfigured server software or something similar.

>
> If I were a proper Admin I'd probably already have this sorted out. I
> think I'll take a look at the server logs, try to see if anyone from
> strange IPs has been logging in or hijacking daemons in some way. I'll
> let you know what I discover.

OK. As I say I saw a couple of other instances of these sort of borked
headers in your report history.

See my next email.

Ellen