Jump to content

What is bad_tracking@devnull.spamcop.net


newhorizon

Recommended Posts

Tracking link: http://888-luvu.com/z/

Resolves to 111.222.111.1

Routing details for 111.222.111.1 <-- click on this to get the following>

Reports routes for 111.222.111.1:

routeid:7138734 96.0.0.0 - 126.255.255.255 to:bad_tracking[at]admin.spamcop.net

Administrator interested in all reports

and the reason for the "bad tracking" decision is;

NetRange: 96.0.0.0 - 126.255.255.255

NetType: IANA Reserved

OrgName: Internet Assigned Numbers Authority

the IP is within a block of "reserved" numbers that shouldn't be showing up on the 'net' ...

and as there is nothing here that ties to an "e-mail" reporting issue, this is being moved back over to the Help Forum.

Link to comment
Share on other sites

Tracking link: http://888-luvu.com/z/

Resolves to 111.222.111.1

...

the IP is within a block of "reserved" numbers that shouldn't be showing up on the 'net' ...

I'm still lost, but for a different reason. At

http://www.spamcop.net/sc?track=http%3A%2F...luvu.com%2Fz%2F we see:

>Parsing input: http://888-luvu.com/z/

>host 222.222.48.37 (getting name) no name

>

>Reporting addresses:

>renbin[at]mail.he.cn

>ct-abuse[at]abuse.sprint.net

>anti-spam[at]chinanet.cn.net

So it's looking like 888-luvu.com resolves to 111.222.111.1 in

one case but resolves to 222.222.48.37 in another case?

Maybe I'm missing something painfully obvious...? :blink:

Link to comment
Share on other sites

not made obvious in your second query, that output was accomplished by using the "single-line" input to the parsing engine. To keep things simple, I'm only going to state that the single-line input uses a different sequence and tool-set bits to come up with abuse addresses ... the actual spam-parsing bit uses a whole different approach at parsing the entire header structure .... for any deeper detail you'll have to try to deal with Julian on trying to get those tidbits ... there are DNS issues, WHOIS data, and outside databases that come into play in the whole-spam-parse ....

Link to comment
Share on other sites

That's funny, maybe the parser is broken on this one, I get:

Offical Name = 888-luvu.com

Aliases =

Addresses = 222.222.48.37

222.222.48.37 - IP hosts 367 Total Domains and they are all spam domains.

222.222.48.0/24 is listed on the Spamhaus Block List (SBL)

holdtiff.com (Malena Management) / ITCT World Trade Company

http://www.spamhaus.org/sbl/sbl.lasso?query=SBL18652

Link to comment
Share on other sites

... the actual spam-parsing bit uses a whole different approach at parsing the entire header structure ....

That doesn't explain it, imho.

Going back to my tracking URL (shown in post #1), it now shows:

>Resolving link obfuscation

>http://888-luvu.com/z/

> host 222.222.48.37 (getting name) no name

>Tracking link: http://888-luvu.com/z/

>[report history]

>Resolves to 222.222.48.37

>Routing details for 222.222.48.37

[... etc ...]

Which is different than what you (Wazoo) and I saw earlier where this same URL resolved the same domain to 111.222.111.1.

So I guess something changed.

And now I've learned that a given tracking URL can change what it shows us over time. Me-thinks that the dynamic content of a tracking URL makes it difficult for folks (like us) to have a discussion about what happened at the time the reports were sent...? :huh:

Link to comment
Share on other sites

That doesn't explain it, imho.

Actually, yes it does, based on that last line about DNS issues and external databases ...

Which is different than what you (Wazoo) and I saw earlier where this same URL resolved the same domain to 111.222.111.1.

So I guess something changed.

Yep, DNS changed. It's really odd the legitimate sites hate changing IPs and such, as getting the new data "out there" can sometimes take days. Contrast that to some spammers that rotate IPs at something like a 15 minute interval ... you have to start with the idiot spammer that is already going for the .00001% return rate for idiots trying to "see" the great stuff ... and how many of those idiots are going to set there and keep hitting the "Refresh" button until the web site finally shows up ....

And now I've learned that a given tracking URL can change what it shows us over time.  Me-thinks that the dynamic content of a tracking URL makes it difficult for folks (like us) to have a discussion about what happened at the time the reports were sent...? :huh:

Yes, the dynamics do cause some issues, leaving some of use with nothing more to offer than a shrug for specific answers as "it works now" .... yet, actually things like your example are known issues, so usually the answers can be delved ...

Link to comment
Share on other sites

I see a report being sent to bad_tracking[at]devnull.spamcop.net

( http://www.spamcop.net/sc?id=z673954712zaa...2f08fdf877da99z ).

A first for me.

I shor am powerful curious to know what this "bad_tracking" business means....?

17635[/snapback]

When a url resolves to an unrouted IP then the reports are sent to bad_tracking. Or if the header parse results in an unrouted or reserved IP. I see further down the thread that the url is now resolving to a routeable IP so they were playing DNS games.

Link to comment
Share on other sites

Yes, the dynamics do cause some issues, leaving some of use with nothing more to offer than a shrug for specific answers as "it works now" .... yet, actually things like your example are known issues, so usually the answers can be delved ...

17653[/snapback]

Well, you know better than I about how folks react to all this schtuff. But lemme nevertheless audaciously submit that it's reasonable for us run-of-the-mill spam victims to assume that the "reference URL" always shows what was shown at the time of the report. When those expectations are dashed, me-thinks it's a bit of an "ouch" for them, even if only a shrug for you.

Not looking for a reply. Just throwing an opinion out there...

Link to comment
Share on other sites

I'm not sure you took that in the way it was intended ... "we" have learned that the parser paints the picture as of the moment ... the "shrug" was meant to indicate that there's nothing "we" can do to hazard a guess at what the parser might have shown an hour before, unless it's stated by the user asking the question. But the rotating DNS issue is most definitely a well known spammer exploit, thus it was easy to "guess" at what happened in your sample spam changing numbers as time went on ....

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...