URLs not reported, SC finds, but does not offer to LART! Options

[mrmaxx]

Ahh... Interesting. I'll have to remember that. Thanks.

[mrmaxx]

Ok... got another which SC didn't find the URLs in...
http://www.spamcop.net/sc?id=z745272461zdd...684d1b29593d2cz

Spamvertised URL:
http://qwsyujirgf.com/wgeMo0v4TYjRKeFMvFCr...xQTA0gBAT4=.htm

Spamvertised 4 times, plus another "img src" URL as well for the same domain. It's standard spammer crap with the multiple mime-type lines below the headers, which I think is what's tripping SpamCop up.

I, for one, really think SC ought to revisit this issue and maybe try to tweak the parser so it finds the URLs when there are multiple "content type" lines.

[trpted]

...Sorry, SpamCop is a wonderful tool, but even it can not tell you where to report websites that don't exist:

CODE

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

K:\>ping -n 1 bzqcqokvhn.qklenders.com
Unknown host bzqcqokvhn.qklenders.com.

K:\>ping -n 1 ntyjttkqbm.qklenders.com
Unknown host ntyjttkqbm.qklenders.com.

But I did a whois look up on the primary domain qklenders.com (the domain ntyjttkqbm.qklenders.com is a subdomain of qklenders.com)

http://dnsstuff.com/tools/whois.ch?ip=qklenders.com&email=on

domain: qklenders.com
status: lock
organization: none
owner: Danny Lieberman
email: dannylieberman[at]mail.ru
address: 971 Krokozhia Ave
city: Predensk
state: --
postal-code: 798199
country: BT
admin-c: dannylieberman[at]mail.ru#0
tech-c: dannylieberman[at]mail.ru#0
billing-c: dannylieberman[at]mail.ru#0
nserver: ns1.lambir726.com
nserver: ns2.lambir726.com
registrar: JORE-1
created: 2005-03-04 19:16:57 UTC JORE-1
expires: 2006-03-04 14:16:55 UTC
source: joker.com


db-updated: 2005-03-15 18:03:41 UTC

**********

http://dnsstuff.com/tools/whois.ch?ip=qkle...he=off&email=on


domain: qklenders.com
status: hold,invalid-address
organization: none
owner: Danny Lieberman
email: dannylieberman[at]mail.ru
address: 971 Krokozhia Ave
city: Predensk
state: --
postal-code: 798199
country: BT
admin-c: dannylieberman[at]mail.ru#0
tech-c: dannylieberman[at]mail.ru#0
billing-c: dannylieberman[at]mail.ru#0
nserver: ns1.lambir726.com
nserver: ns2.lambir726.com
registrar: JORE-1
created: 2005-03-04 19:16:57 UTC JORE-1
modified: 2005-03-23 08:23:26 UTC JORE-1
expires: 2006-03-04 14:16:55 UTC
source: joker.com


db-updated: 2005-03-24 00:46:38 UTC

[heym0n]

http://www.spamcop.net/sc?id=z745338151z56...958b662e37407az


I have the original email...I just got it 5 minz ago.......just wondering if there is anything missing or if someone else can check it out. I recopied the full header and body 3 times and got the same response.

[heym0n]

Here is another reference link. The first one I posted had Opera HTML code for the body.

http://www.spamcop.net/sc?id=z745339072z73...;action=display

[Wazoo]

Are you going to state that the original e-mail looks anything like what I just looked at in the provided Tracking URL (then clicking on the "View entire message" link) ... I sure don't recognize the format of the body content, espcially when looking at it as something for the parser to chew on ....

A bit later: second link posted while typing my response to the first post .... second link is not a Tracking URL, only the display .... no data to work with, other than going with what I thought I was originally going to do .. Merge this Topic into the existing one dealing with body URL parsing results ....

[swingspacers]

heym0n, I don't think you have the full headers. Some Received: lines are missing. The spam you posted only has a Received: line that look like a forgery. Somehow you need to get your system to reveal the full headers, including the Received: line that links the whole thing to the servers in your mailhost configuration.

Alternatively, maybe your server configuration has changed and you need to update your mailhosts, or you received this on an account that you have not yet properly registered with mailhosts?

second link is not a Tracking URL, only the display .... no data to work with

I got the normal tracking URL by removing the ";action=display" from the posted link. It turns out to be the same message, just with all the HTML removed (IMG:style_emoticons/default/smile.gif)

This post has been edited by swingspacers: Mar 23 2005, 10:29 PM

[heym0n]

I too have been coming across SPAM that comes up nothing to do from spamcop but what I found out to work is by waiting a few minutes later and spamcop reports it correctly.

[Jeff G.]

heym0n,

Are you a USA.NET Customer or a Net[at]ddress Registered User?

Do you normally get email with just one Received Header Line that was Received "by usa.net"?

What email client are you using, on what OS?

Thanks!

This post has been edited by Jeff G.: Mar 24 2005, 08:07 AM

[mrmaxx]

Got another one here... SC doesn't find any URLs in the body, but there ARE URLs....
Tracking URL: http://www.spamcop.net/sc?id=z745788701zed...ce47d97566c42bz


Spamvertised URL:
http://sfbeiradg.net/uMi01tMOsN23nCw406oYK...BAT4=.htm"

And it does appear to be up and running:

$ host sfbeiradg.net
sfbeiradg.net has address 222.36.41.209
$ ping sfbeiradg.net
PING sfbeiradg.net (219.153.0.200) 56(84) bytes of data.
64 bytes from 219.153.0.200: icmp_seq=0 ttl=43 time=865 ms
64 bytes from 219.153.0.200: icmp_seq=1 ttl=43 time=864 ms

Not sure if THAT particular page is up and running as I was going to use Links to try and pull it up and it didn't seem to want to come up immediately so I cancelled it.

Still, my contention is that SC is being "tricked" by spammers using mangled mime headers as follows:
[snip headers]
Received: from columbuslogistics.it (mail.columbuslogistics.it [81.208.124.42])
by imagineeringart.com with esmtp
id 488BDD8A76 for <jaldrich[at]covista.com>; Thu, 24 Mar 2005 23:38:23 -0800
Message-ID: <100101c5310d$7f5eef75$5cdae305[at]columbuslogistics.it>
From: "Casanova R. Locals" <postmarks[at]columbuslogistics.it>
To: x
Subject: Reply: the most cheap Cialis, Viagra delivreed fast
Date: Thu, 24 Mar 2005 23:38:23 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0006_7B517CEE.4896FE59"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-AntiVirus: Checked by Dr.Web (http://www.drweb.net)

This is a multi-part message in MIME format.

------=_NextPart_000_0006_7B517CEE.4896FE59
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

------=_NextPart_000_0006_7B517CEE.4896FE59
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0006_7B517CEE.4896FE59--

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Windows-1252">
[snip body]

As you can see, there are "extra" mime headers, which is probably designed to break SC but show up just fine in MS Lookout and LookOut Express, etc.

A SamSpade browser session reveals that the spamvertised URL is just forwarded using dns-forward2.com to freehostedpages.com.

I LARTed everyone I could find related to the dns-forward, the original URL and the end URL. Hopefully this site will be closed down completely, not just the referring page!

This post has been edited by mrmaxx: Mar 25 2005, 08:50 AM

[StevenUnderwood]

For me, right now, that domain resolved to 218.7.112.242 and is not pingable:
C:\>ping sfbeiradg.net

Pinging sfbeiradg.net [218.7.112.242] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 218.7.112.242:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\>

[swingspacers]

It resolves fine from my location, in the same way as posted my mrmaxx. The problem is that SpamCop does not even see the URL and therefore does not try to resolve it.

The culprit is this one extra MIME line:
------=_NextPart_000_0006_7B517CEE.4896FE59--

When you take it out, SpamCop suddenly finds the link just fine:
http://www.spamcop.net/sc?id=z745815702z76...91e517973c6429z

[Wazoo]

Got another one here... SC doesn't find any URLs in the body, but there ARE URLs....
Tracking URL: http://www.spamcop.net/sc?id=z745788701zed...ce47d97566c42bz

Still, my contention is that SC is being "tricked" by spammers using mangled mime headers as follows:
[snip headers]
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0006_7B517CEE.4896FE59"
[snipped even further]

This is a multi-part message in MIME format.

------=_NextPart_000_0006_7B517CEE.4896FE59
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

------=_NextPart_000_0006_7B517CEE.4896FE59
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0006_7B517CEE.4896FE59--

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Windows-1252">
[snip body]

As you can see, there are "extra" mime headers, which is probably designed to break SC but show up just fine in MS Lookout and LookOut Express, etc.

It's not "mangled MIME headers, it's an issue with the cinstruct of the spam (body) itself.

It resolves fine from my location, in the same way as posted my mrmaxx. The problem is that SpamCop does not even see the URL and therefore does not try to resolve it.

The culprit is this one extra MIME line:
------=_NextPart_000_0006_7B517CEE.4896FE59--

When you take it out, SpamCop suddenly finds the link just fine:
http://www.spamcop.net/sc?id=z745815702z76...91e517973c6429z

Which of course runs afoul of the "material alteration" rule. Granted that there is data existing, and it is spammer material, but .... properly rendered by an e-mail client, this would/should appear as a "blank" e-mail wih an HTML attachment. The parser is seeing this "end boundary" line and following normal RFC standards, is making the call that the "end of the message" has been found. Not trying to discount all the other issues, just pointing out that the recipient of this particular spam shouldn't be able to see the spamvertised URLs either. (Whereas in my case, receiving and looking at e-mail "as Plain Text only" I do see the spam contents and notice this 'problem' right off the bat.)

[mrmaxx]

It's not "mangled MIME headers, it's an issue with the cinstruct of the spam (body) itself.
Which of course runs afoul of the "material alteration" rule.  Granted that there is data existing, and it is spammer material, but .... properly rendered by an e-mail client, this would/should appear as a "blank" e-mail wih an HTML attachment.  The parser is seeing this "end boundary" line and following normal RFC standards, is making the call that the "end of the message" has been found.  Not trying to discount all the other issues, just pointing out that the recipient of this particular spam shouldn't be able to see the spamvertised URLs either.  (Whereas in my case, receiving and looking at e-mail "as Plain Text only" I do see the spam contents and notice this 'problem' right off the bat.)

Well, I hate to be the bearer of bad news, Wazoo, but it shows up just fine here in my MS LookOut 2000 client. Maybe you can pass the word on to Julian, et al that the spammers appear to be intentionally breaking SC by adding extra mime headers. Maybe the parser could be tweaked a bit to look for more data past these extra mime headers??? I think it's pretty clear now that spammers know how SC works and are trying to get around it by doing stuff so that the spam actually works but SC doesn't parse it correctly.

This post has been edited by mrmaxx: Mar 25 2005, 12:10 PM

[swingspacers]

Which of course runs afoul of the "material alteration" rule.

Which is why I cancelled the report (and of course, it's not my own spam) (IMG:style_emoticons/default/smile.gif) .

Does it make a difference that the MIME boundary that Outlook seems to overlook has "--" in the end, unlike the boundary defined in the header and used in other places in the same message?

EDIT: I just looked it up. It means that this was the final body part. So it looks like a bug in Outlook if it overruns this?

This post has been edited by swingspacers: Mar 25 2005, 12:18 PM

[StevenUnderwood]

Does it make a difference that the MIME boundary that Outlook seems to overlook has "--" in the end, unlike the boundary defined in the header and used in other places in the same message?

Yes. The trailing -- indicates "no further body parts will follow". You should contact Mcrosoft and explain that there is a security risk in the way they are handling MIME boundries.

According to the RFC I found with this information, there may be newer RFC's covering this, however: http://www.faqs.org/rfcs/rfc1521.html

The encapsulation boundary following the last body part is a
distinguished delimiter that indicates that no further body parts
will follow.  Such a delimiter is identical to the previous
delimiters, with the addition of two more hyphens at the end of the
line:

              --gc0p4Jq0M2Yt08jU534c0p--

[swingspacers]

Thanks for clarifying this. RFC 1521 looks obsolete and has been replaced by RFC 2046 (and other RFCs). It preserves the language you quoted. Further down it says:

There appears to be room for additional information prior to the
first boundary delimiter line and following the final boundary
delimiter line.  These areas should generally be left blank, and
implementations must ignore anything that appears before the first
boundary delimiter line or after the last one.

(emphasis added). So SpamCop seems to be doing it right and Outlook doing it wrong.

[Wazoo]

Well, I hate to be the bearer of bad news, Wazoo, but it shows up just fine here in my MS LookOut 2000 client.  Maybe you can pass the word on to Julian, et al that the spammers appear to be intentionally breaking SC by adding extra mime headers. Maybe the parser could be tweaked a bit to look for more data past these extra mime headers??? I think it's pretty clear now that spammers know how SC works and are trying to get around it by doing stuff so that the spam actually works but SC doesn't parse it correctly.

I'm having some issues parsing this bit of additional data. I took another look at your Tracking URL and I don't see the normal signs of the provided spam having been processed by the "two-part entry form" that was developed as a hack to get around the MIME handling issues of Outlook ..??? (Pointing out that Julian knows only too well the problems with MIME) .. Thus, I'm left wondering how you are actually obtaining the spam that has the MIME lines mis-positioned and further, how are you submitting these spam items? There may be much more to this part of the "missing the URLs" in this case.

[turetzsr]

Thanks for clarifying this. RFC 1521 looks obsolete and has been replaced by RFC 2046 (and other RFCs). It preserves the language you quoted. Further down it says:
<snip>
So SpamCop seems to be doing it right and Outlook doing it wrong.

...Shocking, absolutely shocking!! (IMG:style_emoticons/default/biggrin.gif) <big g>

[swingspacers]

mrmaxx, maybe you can solve your problem by updating Outlook. I have tested the exact message you posted, and it comes up as completely blank for me in the most recent versions of Outlook and Outlook Express. These programs now seem to respect the MIME specifications just fine and ignore everything behind the final boundary delimiter.

The good news is, if the spam was really sent as posted, the spammer has wasted his time for all recipients who have properly working email clients (IMG:style_emoticons/default/tongue.gif)