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