Re: Spamcop failing to detect true originating IP

"Ellen" <[email protected]>
Newsgroups gmane.mail.spam.spamcop.help
Organization SpamCop
Message-ID <[email protected]>

"wskrispy" <[email protected]> wrote in message
news:[email protected]...
> Ellen wrote:
> > "wskrispy" <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.