SC not catching obvious URL in reported Spam

[jongrose]

Occasionally, as most of us know and there has been discussions on the board in the past about SC not being able to resolve certain URLs ot pluck them out of some truncated code. However, lately I have been noticing some manual reports to SC that the reporting system doesn't seem to be picking up on very obvious embedded URLs.

Here is an example. (Note: This email contains some sexually explicit language, which I have censored in this post, but are clearly visible in the report - just as a warning for anyone who might be at work, etc.) In this UCE, the URL is encoded in plain HTML (although lacking a body and html start and end tag) with a few break tags thrown in there.

<br>Hey,<br>Bisexual Boy Gives Head & F*cking P*ssy<br>
<A href="http://www.fishfelt.com/gen_ads/gen_mail.php?grid=29&ape=gt16669">http://www.fishfelt.com/gen_ads/gen_mail.php?grid=29&ape=gt16669</A><BR><BR><BR>

Yet, when parsed through SC, it doesn't seem to pick up on this. I reloaded the page several times hoping SC would reparse the email and catch the URL, but it didn't seem to happen. Here is the URL of the report:

http://www.spamcop.net/sc?id=z1243228478z3...cc9f88fc28dfcez

Anyone have any clue why this is occurring? I can probably dig up some past examples if necessary.

Thanks,

Jon

[StevenUnderwood]

Occasionally, as most of us know and there has been discussions on the board in the past about SC not being able to resolve certain URLs ot pluck them out of some truncated code. However, lately I have been noticing some manual reports to SC that the reporting system doesn't seem to be picking up on very obvious embedded URLs.

Here is an example. (Note: This email contains some sexually explicit language, which I have censored in this post, but are clearly visible in the report - just as a warning for anyone who might be at work, etc.) In this UCE, the URL is encoded in plain HTML (although lacking a body and html start and end tag) with a few break tags thrown in there.

Yes. The email is labeled of format: Content-Type: text/plain; so any RFC following email client will not present the html text as anything but just that, text, not a link.

[jongrose]

Here is another example, which I believe has been brought up in other threads on the forum. I've uploaded the screenshot of what I'm referring to to ImageShack. I haven't linked it with a thumbnail, since there has been some aversion to that in the past, so here is the direct link to the image:

http://img297.imageshack.us/img297/4135/scloanucekj1.jpg

(If for some reason you can't view it due to it's size, here is a link to the image which should automatically adjust based on your screen resolution and allow you to click directly on it to increase the size, if necessary)

http://img297.imageshack.us/my.php?image=scloanucekj1.jpg

But, after reloading the page once, it reparsed the email and caught the URL.

Direct image link:

http://img297.imageshack.us/img297/8681/scloanuce2vc8.jpg

Resizable:

http://img297.imageshack.us/my.php?image=scloanuce2vc8.jpg

Here's the URL for the report:

http://www.spamcop.net/sc?id=z1243237636zf...2c55cf16f1365dz

Yes. The email is labeled of format: Content-Type: text/plain; so any RFC following email client will not present the html text as anything but just that, text, not a link.

But, if I'm pasting the plaintext source of the message, SC will still not pick it up? I use the SC Webmail interface, and not an email client. It seems like SC would just be able to pick up the URL embedded in the URL regardless of how it's declared content type, but I take it this is not the case?

[Wazoo]

But, if I'm pasting the plaintext source of the message, SC will still not pick it up? I use the SC Webmail interface, and not an email client. It seems like SC would just be able to pick up the URL embedded in the URL regardless of how it's declared content type, but I take it this is not the case?

As stated above .... your first sample headers said Content-Type: text/plain; but the body URL was embedded within HTML tags .....

Your second sample says Content-Type: text/plain and then in fact, the body URL is supplied in just that fashion.

[jongrose]

As stated above .... your first sample headers said Content-Type: text/plain; but the body URL was embedded within HTML tags .....

Right, I understand that much. But what I'm trying to figure out is why SC didn't parse the URL. I assume that SC reads the "Content-Type" in the header and then from there decides on whether or not it should look for URLs embedded within HTML or plaintext. Is this correct?

If so, should I make a feature request for this to be modified in the SC parsing engine? We all know that spammers use all sorts of forgeries in the headers in order to fool systems like SC, so it seems obvious to me that SC should just ignore the content-type header and parse the email looking for spamvertized URLs regardless.

I realize that the main focus of SC is to look for the source of the email and not what is contained in the body, but nonetheless, it seems a fairly simple solution for the SC parser to check for this. Since the major elements of spam are forgery, deception and fraud, why would SC believe the listed Content-Type as defined by the sender, since most of all the other elements of the email headers & body are forged.

Your second sample says Content-Type: text/plain and then in fact, the body URL is supplied in just that fashion.

Well, I wasn't exactly trying to compare the two, insofar as what is causing the issues I brought up. In the second email I posted I was just pointing out the fact that it seems, at least from my experience (that for whatever reason), SC doesn't attempt to do a DNS lookup on some embedded spamvertized URLs. On occasion, it takes several reloads before it will attempt to do this, and in some instances, it never does and then I will usually look it up manually and report it through the user notification field. I'm not sure if there is something going on behind the scenes that would cause this behavior. As it doesn't give anymore information after it says "Resolving link obsfucation", listing the URL, and then bypassing it.

These seem to be two different issues (although they both have to do with SC's URL reporting functionality), so I apologize if I didn't make that clear.

So, in summary:

1. In the first email, it seems that the spammer "fooled" the SC reporting engine into ignoring the embedded URL by attempting to disguise itself as a plaintext email, when the body is in fact HTML (albeit malformed and improperly implemented HTML).
   
2. In the second email example, the SC parser just seemed to ignore the embedded URL at first, until I reloaded the page at which point it looked up the reverse DNS of the URL and found the correct abuse reporting addresses to send the reports to them.
   

If I am wrong in either of these assumptions, please feel free to correct me.

[Bumpkin]

Same thing happening to me... headers show text/html

Here's a link: http://www.spamcop.net/sc?id=z1247387968z2...8b972d044aac4bz

It did not parse the website time after time after time, even after cancelling and trying the submission again. NOW that I decide to share the report here, it is showing who the reports should have gone to.

%$#[at]

Now you see it, now you don't. 3 minutes later (after re-checking the link before posting this note) and the link parse is gone. Does anyone else see or not see it?

Spamcop acting like my ex-husband??

[dra007]

We discussed ad nauseum why the parser is inconsistent about detecting url's. Spammers simply redirect and slow things down to stop such automated tracking. Perhaps an admin can link this to previous discussions?

[Wazoo]

We discussed ad nauseum why the parser is inconsistent about detecting url's. Spammers simply redirect and slow things down to stop such automated tracking. Perhaps an admin can link this to previous discussions?

Actually a bit hard to do, when as you state, there are simply so many previous Topics/Discussions on this issue ... This Admin is so far behind on so many other things, he's just going to point out the the existing SpamCop FAQ entries here aboult 'resolving URLs' and such yet again ...

[Farelf]

... Now you see it, now you don't. 3 minutes later (after re-checking the link before posting this note) and the link parse is gone. Does anyone else see or not see it?...

Shown as resolved at this instant - merely reflects the hosting being moved around or redirected as dra007 said. Some spammers prefer not to pay for their webspace and constantly move their domains within the period of grace before the first hosting bill has to be paid. Others get kicked out due to complaints and promptly re-establish elsewhere ... others use botnet hosting which means they tend to be resolve to different addresses every few minutes (and the "host" is mostly totally unaware) and so on ... (loads of other wrinkles amd reasons for SC "failing" in this peripheral functionality in specific instances). FWIW LinkScanner was showing The web page you requested [http://www.nzdirectory.co.nz] is either currently not available or cannot be used to transmit exploits. at the same time (within seconds) of SC actually resolving the link - you will appreciate that the SC parses stay "live", redoing their work every time they are pulled up.

Spammers don't care, as long as some sucker's browser will get through to the spamvertized link "most of the time". Be happy this at least makes the spam less effective than it might be.

Spamcop acting like my ex-husband??

Heh heh ... if he spent his days trying to nail jelly to a tree, this might be so. But no, SC is not inconsistent/evasisve - merely shows what is out there, more or less real-time.