URL question

[bonecrusher]

I am curious about what may be a new form of link obfuscation:

sample follows, note the absence of the usual prefixes

>>link below )

gate.6ucibic4tccbao64t6omb6o6.dehairernfke.com

<<

If one deletes through "6o6" and inserts "www." Spamcop returns a valid URL

Edit: Jeff G. removed extraneous quote.

[Wazoo]

I am curious about what may be a new form of link obfuscation:

sample follows, note the absence of the usual prefixes

>>link below )

gate.6ucibic4tccbao64t6omb6o6.dehairernfke.com

<<

If one deletes through "6o6" and inserts "www." Spamcop returns a valid URL

32302[/snapback]

Nothing "new" here. dehairernfke.com is the Domain. Anything in front of that is a sub-Domain, to include www ..... In a "normal" situation, one would see a 404 error message on a sub-domain / web-page that didn't exist. Spammers have reversed that, setting things up to allow "anything" to end up on their "special" page .. as the leading garbage does not actually track to a "real" web-page .. typically it's just garbage code. If you want to go paranoid, it could be tracking data to see which idiot follows the link.

Post was pulled from the Topic/Discussion placed, as it has nothing to do with the FAQ entry it was placed into. PM sent to advise of the move.

[Jeff G.]

gate.6ucibic4tccbao64t6omb6o6.dehairernfke.com does in fact resolve for the parser at present (with reports to our friendly neighborhood chinatietong.com spam supporters) as well as for me as follows:

; <<>> DiG 9.2.3 <<>> [at]dns +trace gate.6ucibic4tccbao64t6omb6o6.dehairernfke.com

;; global options:  printcmd

.                    493674  IN      NS      L.ROOT-SERVERS.NET.

.                    493674  IN      NS      M.ROOT-SERVERS.NET.

.                    493674  IN      NS      A.ROOT-SERVERS.NET.

.                    493674  IN      NS      B.ROOT-SERVERS.NET.

.                    493674  IN      NS      C.ROOT-SERVERS.NET.

.                    493674  IN      NS      D.ROOT-SERVERS.NET.

.                    493674  IN      NS      E.ROOT-SERVERS.NET.

.                    493674  IN      NS      F.ROOT-SERVERS.NET.

.                    493674  IN      NS      G.ROOT-SERVERS.NET.

.                    493674  IN      NS      H.ROOT-SERVERS.NET.

.                    493674  IN      NS      I.ROOT-SERVERS.NET.

.                    493674  IN      NS      J.ROOT-SERVERS.NET.

.                    493674  IN      NS      K.ROOT-SERVERS.NET.

;; Received 436 bytes from 216.175.203.50#53(dns) in 60 ms

com.                    172800  IN      NS      A.GTLD-SERVERS.NET.

com.                    172800  IN      NS      G.GTLD-SERVERS.NET.

com.                    172800  IN      NS      H.GTLD-SERVERS.NET.

com.                    172800  IN      NS      C.GTLD-SERVERS.NET.

com.                    172800  IN      NS      I.GTLD-SERVERS.NET.

com.                    172800  IN      NS      B.GTLD-SERVERS.NET.

com.                    172800  IN      NS      D.GTLD-SERVERS.NET.

com.                    172800  IN      NS      L.GTLD-SERVERS.NET.

com.                    172800  IN      NS      F.GTLD-SERVERS.NET.

com.                    172800  IN      NS      J.GTLD-SERVERS.NET.

com.                    172800  IN      NS      K.GTLD-SERVERS.NET.

com.                    172800  IN      NS      E.GTLD-SERVERS.NET.

com.                    172800  IN      NS      M.GTLD-SERVERS.NET.

;; Received 504 bytes from 198.32.64.12#53(L.ROOT-SERVERS.NET) in 110 ms

dehairernfke.com.    172800  IN      NS      teok.boultergdgc.com.

dehairernfke.com.    172800  IN      NS      yona.boultergdgc.com.

;; Received 146 bytes from 192.5.6.30#53(A.GTLD-SERVERS.NET) in 130 ms

gate.6ucibic4tccbao64t6omb6o6.dehairernfke.com. 7200 IN A 222.39.47.14

dehairernfke.com.    7200    IN      NS      yona.boultergdgc.com.

dehairernfke.com.    7200    IN      NS      teok.boultergdgc.com.

;; Received 162 bytes from 222.39.47.14#53(teok.boultergdgc.com) in 570 ms

Note that name server yona.boultergdgc.com [221.11.133.63] is not responding and dehairernfke.com doesn't accept email, as verified by http://www.dnsreport.com/tools/dnsreport.c...ehairernfke.com.

[bonecrusher]

gate.6ucibic4tccbao64t6omb6o6.dehairernfke.com does in fact resolve for the parser at present (with reports to our friendly neighborhood chinatietong.com spam supporters) as well as for me as follows:Note that name server yona.boultergdgc.com [221.11.133.63] is not responding and dehairernfke.com doesn't accept email, as verified by http://www.dnsreport.com/tools/dnsreport.c...ehairernfke.com.

32305[/snapback]

Thanks, that is interesting, since when I pasted the complete spam, Spamcop handled the header but said no links in body.

[Wazoo]

Thanks, that is interesting, since when I pasted the complete spam, Spamcop handled the header but said no links in body.

32310[/snapback]

Probably another issue entirely, but without a Tracking URL ....?????

[bonecrusher]

Probably another issue entirely, but without a Tracking URL ....?????

32311[/snapback]

Correct; paste entire spam "no links"; paste only the last portion with "www" it gives links.

[Wazoo]

Correct; paste entire spam "no links"; paste only the last portion with "www" it gives links.

32313[/snapback]

There was a bit of a hint in my last ... if you want "us" to talk about your specific issue, "we" need to see the data ... the Tracking URL of the spam submittal would be the perfect starting point.

[turetzsr]

The Track # I think you refer to is <1500070862>

If that is not it let me know.

<snip>

32343[/snapback]

...Nope, that's not it. Please refer to SpamCop Glossary entry "Tracking URL" and FAQ entry "NEW! Getting a Tracking URL from a Report ID".

[bonecrusher]

...Nope, that's not it.  Please refer to SpamCop Glossary entry "Tracking URL" and FAQ entry "NEW! Getting a Tracking URL from a Report ID".

32345[/snapback]

How's this:

Here is your TRACKING URL - it may be saved for future reference:

http://www.spamcop.net/sc?id=z802021042z44...86248d8ceff91fz

[Wazoo]

How's this:

http://www.spamcop.net/sc?id=z802021042z44...86248d8ceff91fz

32350[/snapback]

Great! The reason for the "no links found" is based on the header line;

Content-Type: text/plain

And the construct of the alleged "link" is simply that ... a long string of text without any of the 'markings' needed to make it a clickable link in any kind of e-mail reader/browser ... so spammer says "link" and the parsers says "garbage string" ...

[StevenUnderwood]

How's this:

Here is your TRACKING URL - it may be saved for future reference:

http://www.spamcop.net/sc?id=z802021042z44...86248d8ceff91fz

32350[/snapback]

OK, and what bit of software is turning those random characters into a link? I can see the parser being made to look for dotted strings that begin with www but to look for any set of dotted strings would be silly, I think.

[Jeff G.]

OK, and what bit of software is turning those random characters into a link?

32352[/snapback]

Defective synapseware

to look for any set of dotted strings would be silly, I think.

32352[/snapback]

yes.agreed.supersilly.deprecated. (Some people actually type in dotted strings sometimes.)

[bonecrusher]

Great! The reason for the "no links found" is based on the header line;

Content-Type: text/plain

And the construct of the alleged "link" is simply that ... a long string of text without any of the 'markings' needed to make it a clickable link in any kind of e-mail reader/browser ... so spammer says "link" and the parsers says "garbage string" ...

32351[/snapback]

So, should one or should one not, when pasting to the Spamcop, edit the "link" to make it be a recognisable one.

Also, does the presence of tracking URL on this board expose one to spam? If so please now delete them.

Thanks

[Jeff G.]

So, should one or should one not, when pasting to the Spamcop, edit the "link" to make it be a recognisable one.

32365[/snapback]

One should not edit the "link" to make it be a recognisable one.

does the presence of tracking URL on this board expose one to spam?

32365[/snapback]

Pasting a Tracking URL here will only expose one's email address to spammers if one is not munging one's Reports.

[bonecrusher]

One should not edit the "link" to make it be a recognisable one.Pasting a Tracking URL here will only expose one's email address to spammers if one is not munging one's Reports.

32367[/snapback]

I am a bit confused on this. When I paste the spam into Spamcop, I do not alter it.

After SC processes it, it appears that there is no ID of mine left, so I would assume SC has done the munge. I looked at the tracked URL and the only thing I could recognise was name of my ISP. I did not see any link back from the tracked URL to the source document.

Thanks

[Wazoo]

After SC processes it, it appears that there is no ID of mine left, so I would assume SC has done the munge.    I looked at the tracked URL and the only thing I could recognise was name of my ISP.  I did not see any link back from the tracked URL to the source document.

32370[/snapback]

Follow the View entire message link. Yes, there is an attempt to mung your personal data, some header data bits ...

[bonecrusher]

Follow the View entire message link.  Yes, there is an attempt to mung your personal data, some header data bits ...

32373[/snapback]

Thanks, did that and saw <To: Customer <x>> so SC at least in this case removed the ID from the header. I would assume it is a good idea to check the body for ID.

[dbiel]

This probably should have been started as a new topic but is actually a reply to Wazoo and Jeff G. regarding the munging.

The following was copied from one of my past report files.

Report spam Mailhosts Statistics Past Reports Preferences Webmail Held Email

Parse

Return-Path: <scg-50-return-551-yyyyyyy~charter.net[at]aljw.com>

Delivered-To: x

Received: (qmail 15709 invoked from network); 15 Aug 2005 19:35:46 -0000

Received: from unknown (192.168.1.101)

by blade4.cesmail.net with QMQP; 15 Aug 2005 19:35:46 -0000

Received: from mtai05.charter.net (209.225.8.185)

by mailgate.cesmail.net with SMTP; 15 Aug 2005 19:35:45 -0000

Received: from mxsf08.cluster1.charter.net ([10.20.201.208])

      by mtai05.charter.net

      (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP

      id <20050815193545.IARH2874.mtai05.charter.net[at]mxsf08.cluster1.charter.net>

      for <x>; Mon, 15 Aug 2005 15:35:45 -0400

Received: from mxip28a.cluster1.charter.net (mxip28a.cluster1.charter.net [209.225.28.187])

    by mxsf08.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j7FJZjGv006758

    for <x>; Mon, 15 Aug 2005 15:35:45 -0400

Received: from 200.49.63.71.akuc.com (HELO akuc.com) ([200.49.63.71])

by mxip28a.cluster1.charter.net with SMTP; 15 Aug 2005 15:35:37 -0400

X-IronPort-AV: i="3.96,108,1122868800";

  d="scan'208,217"; a="97058255:sNHT478490624"

Received: (qmail 6280 invoked from network); 15 Aug 2005 19:35:17 -0000

Received: from unknown (HELO aljw.com) (192.168.1.20)

by akuc.com with SMTP; 15 Aug 2005 19:35:17 -0000

Message-ID: <2005_______________________1200[at]aljw.com>

From: "Christian Loan Advice" <ChristianLoanAdvice[at]aljw.com>

To: x

Subject: Get Mortgage rate quotes from ChristianFamilyLoans.com

The red line (I added the color) I found most interesting (portion in green was munged by me) Apparently some spammers are including the orignal "send to" address in the reply line and by removing the "[at]" and replacing it with "~" making it a valid address, which of course will not get munged by SpamCop.

Also interesting to note is all of the munging that SpamCop did even though my settings are "Leave spam copies intact" (SpamCop munging is indicated in red)

[Wazoo]

This probably should have been started as a new topic but is actually a reply to Wazoo and Jeff G. regarding the munging.

Or even worse, yet another FAQ entry <g>

The red line (I added the color) I found most interesting (portion in green was munged by me) Apparently some spammers are including the orignal "send to" address in the reply line and by removing the "[at]" and replacing it with "~" making it a valid address, which of course will not get munged by SpamCop.

Also interesting to note is all of the munging that SpamCop did even though my settings are "Leave spam copies intact" (SpamCop  munging is indicated in red)

32382[/snapback]

Second item is easier .... the "main" codebase over the years attempted to do some munging. Let's call that the "mainline" branch of code. Somewhere down the line, there was the change to allow some ISPs to request unminged copies. So there was a branch placed on the 'Send Reports' area of the code ... the 'mainline' still handles the munged version, building the reports for "all other" targets, ... the unmunged bit of code would basically reach back and grab a copy of the original submittal to include in that report.

A bit later on, after the IronPort investment, some monster hard drives were installed, and the collected copies of the spam submittals started being maintained, thus leading to the current use of Tracking URLs. These "stored" items are developed from the "mainline" mung stuff codebase, leaving the basic spam available, but with most of the personal data 'fixed' This does lead back into issues that each parse is done 'real-time' such that results can vary over time due to changing data, resources, flags, and settings of certain key items in each spam. There is also an aginf off process, I believe somewhere arounda month or two that the Tracking URLs no longer point to anything.

The munging itself ... problematic, to say the least. Balancing the "protect the user" amd leaving enough data intact for the whitehat ISP to actually do something with the spam report (i.e. find the traffic in his/her log files) Anyway, the 'easy' stuff here .. a partial on the Message-ID: ... looking at the To: address for the normally/assumed spam recipient's e-mail address .. set that as a varible and replace with <x> everywhere seen ... the rest of it is all up for grabs .. problem being trying to recognize a bit of text as something meaningful ...

Then one adds in that the majority of spam e-mail doesn't actually 'track' back to the spammer him/herself directly, so the odds of the spammer ever seeing the complaint/report start going down. That the embedded coding may be something more benign ... 7 spaces in the thrid line of text in spam tun #1, 9 spaces for spam run #2, the string of nonsense characters actually being a ROT-9 of the e-mail address, etc. etc. etc. .... the laws of diminishing returns and trying to keep up the thousands of reports sent daily ....

thinking that I'm starting to ramble at present ...????

[bonecrusher]

This probably should have been started as a new topic but is actually a reply to Wazoo and Jeff G. regarding the munging.

The following was copied from one of my past report files.The red line (I added the color) I found most interesting (portion in green was munged by me) Apparently some spammers are including the orignal "send to" address in the reply line and by removing the "[at]" and replacing it with "~" making it a valid address, which of course will not get munged by SpamCop.

Also interesting to note is all of the munging that SpamCop did even though my settings are "Leave spam copies intact" (SpamCop  munging is indicated in red)

32382[/snapback]

Looking at several of my past reports, I note that none of them had the "return path" that you noted. So it would appear that that is not a mandatory e-mail field; is that correct? Also follows that one should watch for it and any field other than "To" and munge any ID. Is this sound thinking? I am, as shown, a newbie in this field.

[dbiel]

As I stated before, I do not munge any data, so for me it is not an issue at all. But for those who are concerned about revealing their email address, this is one place that can expose that data. It would be nearly imposible for the parser to identify and munge this type of data. Then to keep things in perspective, this was the only time that I have seen this done, so the chances of this being a "problem" are very slight.