Jump to content

Why can't Spamcop resolve "worldwarm.com"?


mikeobrien

Recommended Posts

I've been getting regular spam that makes it through the Spamcop filters, advertising a site called "worldwarm.com". When I report it, Spamcop is unable to resolve the hostname "worldwarm.com", so doesn't report it. I have had no problem resolving the site at any time over the past couple of weeks that the spam has been coming in.

Has someone gotten smart and put up a DNS resolver that returns bogus answers to queries coming from Spamcop, or is something else going on? Not once has Spamcop been able to resolve this; not once has my own system failed to do so.

Link to comment
Share on other sites

It is possible to check a link resolution in SC simply by pasting it into the webform submission on the SC member's page - ie ht tp://worldwarm.com (broken for this post)

When SC looks at this one that way it says

Cannot resolve ht tp://worldwarm.com/ (broken for this post)

No valid email addresses found, sorry!

* There are several possible reasons for this: The site involved may not want reports from SpamCop.

* SpamCop administrators may have decided to stop sending reports to the site to prevent listwashing.

* SpamCop uses internal routeing to contact this site, only knows about the internal method and so cannot provide an externally-valid email address.

* There may be no working email address to receive reports.

Abuse.net confirms there is no (specific) reporting address, DomainDossier shows an admin address [at]hanaro.com (network whois) which probably evades SC - or SC may have given up on Hanaro. DomainDossier also reveals the worldwarm.com domain has no mail exchange and, although the DNS record indicates "email: admin.worldwarm.com" the ipaddresslocation.org address checker shows there is no mail service to that subdomain either (not that anyone would want reports sent to the spammer but the question of network contact with the registrant arises). Hmmm - and there's no rDNS. They may have recently moved to Hanaro. They do seem to be playing some games, DomainDossier is unable to confirm any services at the location (or provide a snapshot) but a home computer can scan the webpage response just fine - using the IdServe downloaded utitlity:
Initiating server query ...

Looking up IP address for domain: worldwarm.com

The IP address for the domain is: 116.127.27.188

Connecting to the server on standard HTTP port: 80

[Connected] Requesting the server's default page.

The server returned the following response headers:

HTTP/1.1 302 Moved Temporarily

Server: nginx/0.7.61

Date: Wed, 30 Dec 2009 23:01:14 GMT

Content-Type: text/html

Transfer-Encoding: chunked

Connection: close

X-Powered-By: PHP/5.2.10

Location: secure.php?cmd=home

P3P: CP="CAO COR CURa ADMa DEVa OUR IND ONL COM DEM PRE"

Query complete.

Which (resisting public display) is probably SOP for a site flogging moody goods (knock-offs). Meantime, we can see from URIBL that worldwarm.com is comprehensively listed on URIBL and SURBL - though no thanks to SC, to be sure (there would be a listing on sc.surbl.org otherwise).

We can also see on McAfee SiteAdvisor quite a few 'love letters' from other spam sufferers and some further details about activity and listings.

Yes, it would be good to find out why SC is not reporting. Maybe the notoriety/criminality of the domain has driven it from other hosts in the past - see Domain Tools entries - so 'they' may not be entirely bulletproof (reports may do some good) but we must remember 'spamvertized' sites are not SC's main mission. Also, I suspect some of that jumping about may be just some spammers seizing on a vacated and (perhaps) hitherto reputable domain name.

Reporting? I would prefer bilateral torsional orchidectomy for that lot.

Link to comment
Share on other sites

It isn't that they don't report, it's that SC can't even get an IP address from the name, that's what's so weird about it.
Understood - that is tied up in my response above, admittedly in 'shorthand'. The process of resolving relies on getting the IP address as the first step. As you say, there is no evidence of the resolution getting even that far but it is (sort of) implied if the processing feedback talks about no valid reporting addresses rather than not finding the DNS records. And I mentioned some difficulties involved in that. But that could just be loose phrasing.
...I'll provide a tracking URL the next time one of their spams comes in. As I'm sure it will.
Thanks, yes, there are some leaps of imagination and suppositions made without that. Which is usually a waste of time but I was trying to highlight some (possibly) useful investigative measures through the links I provided.
Link to comment
Share on other sites

Understood - that is tied up in my response above, admittedly in 'shorthand'. The process of resolving relies on getting the IP address as the first step. As you say, there is no evidence of the resolution getting even that far but it is (sort of) implied if the processing feedback talks about no valid reporting addresses rather than not finding the DNS records. And I mentioned some difficulties involved in that. But that could just be loose phrasing.Thanks, yes, there are some leaps of imagination and suppositions made without that. Which is usually a waste of time but I was trying to highlight some (possibly) useful investigative measures through the links I provided.

And sure enough, another spam was forthcoming:

http://www.spamcop.net/sc?id=z3620302945z4...a1ab7eac167baez

Link to comment
Share on other sites

Apparently, stuff changing while time goes on .... when I started looking at this ....

12/31/09 06:21:02 dig worldwarm.com [at] 208.67.220.220

Dig worldwarm.com[at]ns2.worldwarm.com (116.127.27.188) ...

failed, couldn't connect to nameserver

Dig worldwarm.com[at]ns1.worldwarm.com (116.127.27.188) ...

failed, couldn't connect to nameserver

Dig worldwarm.com[at]208.67.220.220 ...

Non-authoritative answer

Recursive queries supported by this server

Query for worldwarm.com type=255 class=1

worldwarm.com A (Address) 116.127.27.188

worldwarm.com NS (Nameserver) ns1.worldwarm.com

worldwarm.com NS (Nameserver) ns2.worldwarm.com

Normal guidance for srtting up a 'good' hosting environment is to use two separate (geographicly separated) DNS servers .... certainly not using the exact same server as the 'hosted' system. Easuest guess at the existing scenario is that there isn't any DNS service running on the end system.

dig worldwarm.com

;; QUESTION SECTION:

;worldwarm.com. IN A

;; ANSWER SECTION:

worldwarm.com. 387 IN A 116.127.27.188

;; AUTHORITY SECTION:

worldwarm.com. 387 IN NS ns2.worldwarm.com.

worldwarm.com. 387 IN NS ns1.worldwarm.com.

;; ADDITIONAL SECTION:

ns1.worldwarm.com. 387 IN A 116.127.27.188

ns2.worldwarm.com. 387 IN A 116.127.27.188

nslookup 116.127.27.188 worldwarm.com

;; connection timed out; no servers could be reached

nslookup ns1.worldwarm.com worldwarm.com

Server: worldwarm.com

Address: 116.127.27.188#53

Name: ns1.worldwarm.com

Address: 116.127.27.188

strange rresults for a 'good' hosting set-up

whois -h whois.crsnic.net worldwarm.com ...

Redirecting to CHINA SPRINGBOARD INC.

whois -h whois.namerich.cn worldwarm.com ...

DomainName : worldwarm.com

RSP: China Springboard Inc.

URL: http://www.namerich.cn

Name Server: NS2.SRVSECURE.COM

Name Server: NS2.GLOWSTRONG.COM

Name Server: NS1.GLOWSTRONG.COM

Name Server: NS1.SRVSECURE.COM

Status: clientTransferProhibited

Status: clientDeleteProhibited

Creation Date: 2009-12-22

Expiration Date: 2010-12-22

Last Update Date: 2009-12-22

Registrant ID: V-X-65663-25033

Registrant Name: cheng hong

Registrant Organization: cheng hong

Registrant Address: changchunludongfanglu12hao

Registrant City: chang chun

Registrant Province/State: HeiLongJiang

Registrant Country Code: CN

Registrant Postal Code: 456325

Registrant Phone Number: +86.044556987458

Registrant Fax: +86.044556987458

Registrant Email: qingpenghaoyou12[at]sina.com

Ignoring the probable bogus address and shiny new construct date, note the different DNS servers identified ...

When I got back to the house and continued on, things have changed (though noting that results aren't much better at present)

12/31/09 13:03:06 dig worldwarm.com [at] 208.67.220.220

Dig worldwarm.com[at]ns2.glowstrong.com (222.241.13.241) ...

failed, couldn't connect to nameserver

Dig worldwarm.com[at]ns1.glowstrong.com (221.203.168.175) ...

Failed, socket error

Dig worldwarm.com[at]ns2.srvsecure.com (222.241.13.241) ...

failed, couldn't connect to nameserver

Dig worldwarm.com[at]ns1.srvsecure.com (221.203.168.175) ...

Failed, socket error

Dig worldwarm.com[at]208.67.220.220 ...

Non-authoritative answer

Recursive queries supported by this server

Query for worldwarm.com type=255 class=1

worldwarm.com A (Address) 116.127.27.188

worldwarm.com NS (Nameserver) ns1.srvsecure.com

worldwarm.com NS (Nameserver) ns2.srvsecure.com

worldwarm.com NS (Nameserver) ns1.glowstrong.com

worldwarm.com NS (Nameserver) ns2.glowstrong.com

dig worldwarm.com

;; QUESTION SECTION:

;worldwarm.com. IN A

;; ANSWER SECTION:

worldwarm.com. 578 IN A 116.127.27.188

;; AUTHORITY SECTION:

worldwarm.com. 578 IN NS ns1.glowstrong.com.

worldwarm.com. 578 IN NS ns1.srvsecure.com.

worldwarm.com. 578 IN NS ns2.glowstrong.com.

worldwarm.com. 578 IN NS ns2.srvsecure.com.

;; ADDITIONAL SECTION:

ns1.srvsecure.com. 107131 IN A 221.203.168.175

ns2.srvsecure.com. 107131 IN A 222.241.13.241

ns1.glowstrong.com. 107131 IN A 221.203.168.175

ns2.glowstrong.com. 107131 IN A 222.241.13.241

The complaint about the "browser experience" of "resolving the site" is really a reflection on the garbage 'allowed' by vatious browsers, so as to 'create a wonderful user expeience' .. in contrast to actually 'following the rules' about 'good' hosting and record-keeping details for a 'correct' set of hosting/location details. For instance, as in detrails provided in Farelf's browser-request details, the "Location:" data gets appended to the original Domain request and the browser tries again with the expanded URL .... which then results in a page being displayed. In this case, a Ultimate Replicas : Luxury at affordable prices! web-page, as Rick pointed out. However, noting also that this action only occurs on a browser written/configured/allowed to folow such redirects. This (somewhat) faulty browser action, although usefull in some case, is not the same as actually trying to look-up and analyze the actual data involved, so there isn't really a good comparison between a lookup action and a browser (re)action.

Let me stop at simply suggesting that the spammer is still at work, trying to make things work correctly,

Link to comment
Share on other sites

An additional thought on this one... As I recall, the SC parser is pretty intolerant of delays in resolving a domain name.

A human can tolerate a slight delay whereas the parser simply times out. This makes sense since the main purpose of the parser is not to report domains.

Andrew

Link to comment
Share on other sites

I don't know where the "browser experience" comment comes from: I used "dig", not a browser, in my own investigation into whether or not I could resolve the hostname locally.

Oh, and FWIW, there was no delay whatsoever when waiting for Spamcop to fully parse the spam email I pasted in. It was not a DNS timeout; SC's DNS resolver was returning failure immediately.

Link to comment
Share on other sites

I don't know where the "browser experience" comment comes from:

The vast history of browsers accepting all sorts of mangled, screwed up, encoded, etc. URLs to actually end up landing on a web-page ... in contrast to 'knowing' it was a manufactured string of code made to specifically use a browser 'problem' mode.

I used "dig", not a browser, in my own investigation into whether or not I could resolve the hostname locally.

And your dig results differed from mine how? The failed, couldn't connect to nameserver was the data I was keying on for the 'parser failure' result.

Oh, and FWIW, there was no delay whatsoever when waiting for Spamcop to fully parse the spam email I pasted in. It was not a DNS timeout; SC's DNS resolver was returning failure immediately.

Back to the "no connection" problem scenario. On my systems, there was anywhere from 1 to 4 seconds elapsed to offer up that data, whereas the parser only spends/waits a few milliseconds making that query and looking for a result. No response, no action taken beyond the "can't resolve" remark.

Link to comment
Share on other sites

Whatever. Spamcop can't resolve the hostname, my system can, hence spammers win.

That presumes that reports of website URLs make any difference and there is little evidence that they do.

The reports that feed the SCBL are the primary value so your report was helping in a significant way. There are, IMO, better ways of reporting spamvertised website URLs.

So thanks for reporting.

Andrew

Link to comment
Share on other sites

Spammers have been evading SpamCop reporting for a while (years?) now...hence the reason why they will split up their domain name.....adding spaces, using ASCII "art", even "images" depicting a browser address bar, showing the user where to "enter" the domain name.

I have a feeling there ARE some "hosts" that DO in fact take SpamCop reports seriously, which is why the spammers go so far as to evade spam filtering by splitting up their domain names (rx pills dot com, rxpills . com, etc other methods...to evade URL filtering, automated NSLOOKUPS, etc) even though we may not receive a reply from the host.

The most probable cause regarding this issue is the spammer nameserver is blocking Ironport/SpamCop DNS queries....so then Spamcop's parser sees the domain as "dead"...

Here's an example:

http://www.spamcop.net/sc?id=z3625825284z4...4eff9dc93c3b03z

Tracking link: http://delivokay.com/

No recent reports, no history available

Cannot resolve http://delivokay.com/

I know sometimes, if you "Refresh" the page, to let SC parse it again, it may "take" (resolve) and give you the contact addresses.....but then there are some domains which SpamCop will not/ever resolve(see my tracking URL, this is one of them); because the criminal entities that control the nameserver(s) behind that domain have blocked IronPort's DNS queries....

delivokay.com is a "Dr. MaxMan" spambrand; previously known as "Herbal King" (these guys change their alias every 6 months.....my take is their marketing team must suck, can't find any customers, so they keep renaming in hopes of picking some customers up.), and you can find a whole bunch of details regarding the scam at the spamtrackers wiki:

http://www.spamtrackers.eu/wiki/index.php/Dr.MaXman

In my domain case, delivokay currently points to a server at 112.145.157.64, and well, it's blocklisted at Spamhaus too even: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL83594

112.145.157.64/32 is listed on the Spamhaus Block List (SBL)

19-Dec-2009 05:28 GMT | SR15

reason: spam sites

So, in the future, if you wanted to take a pro-active measure to domains that don't resolve with spamcop, you could.

nslookup the domain.

input the returned address into spamcop's form (http://www.spamcop.net/sc?track=112.145.157.64)

And mail the abuse contacts listed.

You can find decent templates for contacting these addresses at the spamtrackers wiki too:

http://spamtrackers.eu/wiki/index.php?title=Hijacked_host

towards the bottom of the page

Link to comment
Share on other sites

Spammers have been evading SpamCop reporting for a while (years?) now...hence the reason why they will split up their domain name.....adding spaces, using ASCII "art", even "images" depicting a browser address bar, showing the user where to "enter" the domain name.

I have a feeling there ARE some "hosts" that DO in fact take SpamCop reports seriously, which is why the spammers go so far as to evade spam filtering by splitting up their domain names (rx pills dot com, rxpills . com, etc other methods...to evade URL filtering, automated NSLOOKUPS, etc) even though we may not receive a reply from the host.

The most probable cause regarding this issue is the spammer nameserver is blocking Ironport/SpamCop DNS queries....so then Spamcop's parser sees the domain as "dead"...

Here's an example:

http://www.spamcop.net/sc?id=z3625825284z4...4eff9dc93c3b03z

Tracking link: http://delivokay.com/

No recent reports, no history available

Cannot resolve http://delivokay.com/

I know sometimes, if you "Refresh" the page, to let SC parse it again, it may "take" (resolve) and give you the contact addresses.....but then there are some domains which SpamCop will not/ever resolve(see my tracking URL, this is one of them); because the criminal entities that control the nameserver(s) behind that domain have blocked IronPort's DNS queries....

delivokay.com is a "Dr. MaxMan" spambrand; previously known as "Herbal King" (these guys change their alias every 6 months.....my take is their marketing team must suck, can't find any customers, so they keep renaming in hopes of picking some customers up.), and you can find a whole bunch of details regarding the scam at the spamtrackers wiki:

http://www.spamtrackers.eu/wiki/index.php/Dr.MaXman

In my domain case, delivokay currently points to a server at 112.145.157.64, and well, it's blocklisted at Spamhaus too even: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL83594

So, in the future, if you wanted to take a pro-active measure to domains that don't resolve with spamcop, you could.

nslookup the domain.

input the returned address into spamcop's form (http://www.spamcop.net/sc?track=112.145.157.64)

And mail the abuse contacts listed.

You can find decent templates for contacting these addresses at the spamtrackers wiki too:

http://spamtrackers.eu/wiki/index.php?title=Hijacked_host

towards the bottom of the page

Oh, actually, I already do that, but thanks for the clear documentation for others to follow - I highly recommend it.

FWIW, "worldwarm.com" has now been replaced by "worldcalm.com", I think at the same address - certainly the same network (and reporting address):

http://www.spamcop.net/sc?id=z3635830579zc...c9e8b39daa47c8z

It's equally unresolvable by Spamcop. As you say, they're probably blocking Ironport's queries. Ironport could battle this with some work, using the spammers' own tricks: proxy their DNS queries through other networks. It'd probably result in an unacceptable slowdown on report parsing, though. Perhaps they could make it an option for batch processing only, let it trickle by in the background.

Link to comment
Share on other sites

Yes, I'm sure they could battle it. But all through SpamCop history, primary emphasis seems to be on reporting/mailing/blocking the machines/addresses that are doing the actual mailing of the spam, rather than the domains appearing IN the spam e-mail.

As far as

FWIW, "worldwarm.com" has now been replaced by "worldcalm.com", I think at the same address - certainly the same network (and reporting address):

I don't know about "replaced by" - lol. These domains are fly by night, and seems that the sponsoring registrar has taken action and decided to suspend the domain :)

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...