Jump to content

Munge tracking HTML links, please


 GT 

Recommended Posts

Starting today, I get flooded with a new flavour of the old drug mafia spam where the HTML part hides links like these:

http://a4xxx____________________u777.tambourajl.com/?promo

http://a4xxx____________________r444.hamlaheh.com/?promo

http://a4xxx____________________9m44.ketchjl.com/?promo

http://eil.____________________idvv.tambourajl.com/?ahha

http://ieb.____________________gtbb.ketchjl.com/AhH?OLa

http://derb.____________________p22k.hamlaheh.com/?nzol

http://ieb.____________________gtbb.ketchjl.com/sHd?OsL

http://esgy.____________________niii.festallylh.com/?yne

http://esgy.____________________niii.festallylh.com/iAI?dqU

http://derb.____________________p22k.hamlaheh.com/?nzol

http://ieb.____________________gtbb.ketchjl.com/ewS?QRa

Through my suspicious eyes, this conspiciously looks like those 24 characters (from which I removed 20) encode my e-mail address and link it to the spamvertised “product” (including even “unsubscribe”). So just by clicking it or reporting it through Spamcop to the list-washing ISP, I confirm that my e-mail address is valid and may be sold for a better price to the next spammer.

Wouldn’t it be a nice feature to handle such links the same way like message IDs in Spamcop reports?

Link to comment
Share on other sites

I'd like to see the actual parser results from a spam with this many links involved.

Usually there were only 3 or 4 per message. I collected them from the first four or five, sent all to the same mailbox. Interestingly, some identical 24-character codes reappeared in different combinations and in different messages, though most seem to be unique.

Link to comment
Share on other sites

Report History only shows Tracking URLs for the Account to which those Tracking URLs belong.

36665[/snapback]

Given hyperlink shows all reports regarding issue ID 74449030, even those which were directed to mole[at]devnull.spamcop.net. You see them regardless whether you contributed a report on this issue or not.

That's different from "Past Reports" which selects only your own contributions.

Link to comment
Share on other sites

Given hyperlink shows all reports regarding issue ID 74449030, even those which were directed to mole[at]devnull.spamcop.net. You see them regardless whether you contributed a report on this issue or not.

That's different from "Past Reports" which selects only your own contributions.

36716[/snapback]

Having only a "free reporting" account, your offered link doesn't do anything for me. So still boils down to, if you want help, you'll need to try a little harder ...

Link to comment
Share on other sites

Having only a "free reporting" account, your offered link doesn't do anything for me ...

36718[/snapback]

Not to put too fine a point apon it, half the readership (including Wazoo and me) ends up at a 401 error handler if they try your link. And they feel a bit aggieved, not inclined to offer further help at all. Which is why "we" ask for tracking URLs. People usually humor us on this.
Link to comment
Share on other sites

Readers that don't have SpamCop Email System Accounts may benefit somewhat from http://www.spamcop.net/mcgi?action=showhis...id;val=74449030, but only " GT " can see and relay to us the Tracking URLs at that URL or the one " GT " posted.

36724[/snapback]

?"Authorization failure, no username provided by server; action = showhistory"
<title>SpamCop.net - Authorization failure</title>

Do you mean ... that DO have SpamCop Email System Accounts ...?

Link to comment
Share on other sites

?"Authorization failure, no username provided by server; action = showhistory"
<title>SpamCop.net - Authorization failure</title>

Do you mean ... that DO have SpamCop Email System Accounts ...?

36730[/snapback]

Please log in to www.spamcop.net before using that link http://www.spamcop.net/mcgi?action=showhis...id;val=74449030, or alternatively http://members.spamcop.net/mcgi?action=sho...id;val=74449030 if you prefer basic HTTP authentication to cookies. Thanks!
Link to comment
Share on other sites

Starting today, I get flooded with a new flavour of the old drug mafia spam where the HTML part hides links like these:

<snip>

http://ieb.____________________gtbb.ketchjl.com/ewS?QRa

Through my suspicious eyes, this conspiciously looks like those 24 characters (from which I removed 20) encode my e-mail address and link it to the spamvertised “product” (including even “unsubscribe”). So just by clicking it or reporting it through Spamcop to the list-washing ISP, I confirm that my e-mail address is valid and may be sold for a better price to the next spammer.

Wouldn’t it be a nice feature to handle such links the same way like message IDs in Spamcop reports?

36633[/snapback]

I think I am finally beginning to understand the question.

In which case the Tracking URL is not actually necessary (though it would be good for GT to learn what a Tracking URL is and how to post one as it is necessary to post one when asking for help on specific parsing and blocking issues).

This appears to be more of a general issue so I will give it a stab.

The html links (in which you replaced 20 characters with 20 "_" characters) remain valid clickable links. Your guess that your email address is embedded in that string seems valid and it appears to be a tool used by the spammer to identify the source email address that was redirected to the web site.

Your request that the parser "handle such links the same way like message IDs in Spamcop reports" would appear to make sense on the surface, but suffers from one major problem which is massive amount of programming that would be necessary to train the parser to identify personal data contained in the link (which is not necessary to open the link but only servers to feed additional data to the sever on which the link resides) and then to munge that personal data yet at the same time be sure not to munge any portion of the link that is necessary to identify it from all the billions of other html links. If it were only an issue of pulling out your email address it might be possible, but the email address might not be formatted in the same manner or it might be represented by an account number or other reference number which there would be absolutely no way of identifying.

For those of us who do not munge reports this is not a problem as the personal data is already being forwarded in the reports.

For those who do munging it can be a problem as embedded personal data will be transmitted with the munged data (another reason to review the reports before sending them).

For mole reporters this is not a problem as no reports are sent anyway, so nothing is disclosed.

Link to comment
Share on other sites

Through my suspicious eyes, this conspiciously looks like those 24 characters (from which I removed 20) encode my e-mail address and link it to the spamvertised “product” (including even “unsubscribe”). So just by clicking it

36633[/snapback]

And why would you be clicking on links in your spam? Haven't you taken The Boulder Pledge?
or reporting it through Spamcop to the list-washing ISP, I confirm that my e-mail address is valid and may be sold for a better price to the next spammer.

36633[/snapback]

If you are really that concerned about spammers selling your email address, I'd suggest Mole Reporting.
Link to comment
Share on other sites

I think I am finally beginning to understand the question.

??? Possibly confused by the Title of this Topic, using the term "Tracking HTML" and then the requests for Tracking URLs ...????

In which case the Tracking URL is not actually necessary (though it would be good for GT to learn what a Tracking URL is and how to post one as it is necessary to post one when asking for help on specific parsing and blocking issues).

My first request was to verify that the magic number 7 had been coded around ... The next was to see the actual spam constructs ... after that, I got tired of asking.

This appears to be more of a general issue so I will give it a stab.

The html links (in which you replaced 20 characters with 20 "_" characters) remain valid clickable links.

Not sure if you actually "checked" them, but this is an issue with DNS ... this leading garbage would normally be defined as a sub-Domain of the register Domain. Normally, if the sub-Domain was not actually in existence, one would receive the infamous 404 - Page not available screen .. However, spammers started adding in wild-card handling, such that they could "allow" for these millions of different non-existent sub-Domains to end up actually being "resolved" .. basically as the receiving system isn't actually looking for a 'real' sub-Domain designation to steer 'your' browser request to that specific page. Usually, anything placed in front of the Domain name will end up pulling up the same web-page/code ....

Your guess that your email address is embedded in that string seems valid and it appears to be a tool used by the spammer to identify the source email address that was redirected to the web site.

Could be that, could be nothing, could be random crap generated by the garbage spam software ... one would think that if it was an "encrypted e-mail address" all samples would be the same .. that the samples show different "lead-in" character strings changing, it would seem more likely that there would be some other tie-in to what that character string actually connects to ... but, as only the spammer knows, it's pretty useless to come up with all the possibilities. Had an actual Tracking URL been provided, there may have been sufficient data to go take some kind of comparitive look in "Sightings" to see how often the same data showed up to other users, thus possibly ruling out the "encrypted e-mail address" thoery, but ....

Your request that the parser "handle such links the same way like message IDs in Spamcop reports" would appear to make sense on the surface, but suffers from one major problem which is massive amount of programming that would be necessary to train the parser ....

36740[/snapback]

Yeah, agree with the majority of the commentary here .. first of all, a URL is used to generate a report and the munging of a URL kind of makes that report much more than simply useless. (Yes, you can choose to argue "this example" but that's not how code gets written.) Trying to add in the processing and analysis time to determine that "this is one of those type spam/URLs" would seem self-defeating in the long run. There are already too many time-based decisions in the process that impact the parsing process. One could also add in that trying to add in code that actually looks at the "content" of the spam is not the SpamCop focus ... there are other tools out there for that kind of analysis.

And of course, lest one forget, there is nothing to stop one from generating their own spam complaints ... I do it all the time.

Link to comment
Share on other sites

And why would you be clicking on links in your spam?

36741[/snapback]

Not actually left-clicking on it, though it couldn't cause much harm to my sandbox with no scripting and not executing active contents. If ever, I'd C&P it to Sam Spade.

However, if these were tracking URLs (i.e. tracking the spam recipient, not SpamCop's URLs to spam-tracking info), this probably would also trigger off the "valid address" signal.

Fortunately, identical codes are spammed to others as well, so it seems save to follow the URL and see were it redirects to. But that's no longer a topic of a feature request.

If you are really that concerned about spammers selling your email address, I'd suggest Mole Reporting.

36741[/snapback]

Not really. But how can I complain about spam if I'm eager to attract it? The decision is to send a munged report to a suspicious spam host or to send no suicidal report.

Link to comment
Share on other sites

...Fortunately, identical codes are spammed to others as well ...

36744[/snapback]

Nevertheless, even when my address is in clear in the message body (whether appended to an "opt out" URL or not), it has always struck me as odd that SpamCop doesn't munge it. I Just experimented with a manufactured example (no actual example conveniently to hand) and that still seems the case. Codes are a bit hard but I think there is a point to be made to "lift the bar" by extending the offer to muge to include the body. Being a mole, it doesn't affect me directly of course but others may feel it worthwhile. The problem is, there are so many more subtle ways to secrete a tracking facility in a message. But the concept of not fixing anything because everything can't be fixed is not one we should support.
Link to comment
Share on other sites

Archived

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

×
×
  • Create New...