Jump to content

website not being LARTed


mrmaxx

Recommended Posts

Any idea why the URL in the spam would not be LARTed? It's as if the parser doesn't even *see* the URL... There are two URLs in the spam:

http://www.avtechdirectcomputers.com and http://www.computeradvice.org/unsubscribe.asp

(it's one of those "attention school admins..." etc. spams for cheap computers!)

The URL for the report is http://www.spamcop.net/sc?id=z658325043z4f...e3a935836bbdbbz

Link to comment
Share on other sites

I got quite a few of those recently but haven't checked if anything was missing in the reports. They are a nuisance because they make it look like an internal institutional e-mail, yet when you parse the headers they are obviously spam and likely a fraud as well.

PS. I went back to check on the history of this type of spam and remember distictly they forged my institutional domain in the header. I just wonder how many gullible people would fall for such scam (this is not thy best example but they all have the same content):

Return-Path: <admin[at]computeradmin.org>

Received: from mb2i1.ns.pitt.edu (mb2i1.ns.pitt.edu [136.142.11.140])

      by imap.srv.cis.pitt.edu with ESMTP (8.8.8/8.8.8/cisimap-7.2.2.4)

      ID <WAA24722[at]imap.srv.cis.pitt.edu> for <x>;

      Fri, 3 Sep 2004 22:55:52 -0400 (EDT)

Received: from CONVERSION-DAEMON by pitt.edu (PMDF V5.2-32 #41462)

id <01LEG4EF31N4001VX1[at]mb2i1.ns.pitt.edu> for x; Fri,

3 Sep 2004 22:55:51 EDT

Received: from psmtp.com ([12.158.38.155]) by pitt.edu (PMDF V5.2-32 #41462)

with SMTP id <01LEG4E83UWS0024CD[at]mb2i1.ns.pitt.edu> for x;

Fri, 03 Sep 2004 22:55:49 -0400 (EDT)

Received: from source ([200.35.111.14]) by exprod7mx15.postini.com

([12.158.38.251]) with SMTP; Fri, 03 Sep 2004 19:55:38 -0700 (PDT)

Received: from i0.65w1.com [65.210.134.54] by WLL-77-pppoe014.t-net.net.ve with

ESMTP id <159060-65247>; Sat, 04 Sep 2004 09:50:44 +0600

Date: Sat, 04 Sep 2004 09:50:44 +0000 (GMT)

From: Administrator <admin[at]computeradmin.org>

Subject: Staff Bulletin

To: x

Message-id: <8b40________________$7e1[at]p27.6l8p>

MIME-version: 1.0

X-Mailer: QUALCOMM Windows Eudora Version 5.1

Content-type: multipart/alternative;

boundary="Boundary_(ID_4e/r5phaqPrEGV9SB+lpTA)"

X-Priority: 1

X-MSMail-priority: High

X-pstn-levels: (S: 0.14395/92.89996 R:95.9108 P:95.9108 M:100.0000 C:78.1961 )

X-pstn-settings: 1 (0.1500:0.4500) gt3 gt2 gt1 r p m C

X-pstn-addresses: from <admin[at]computeradmin.org> forward (good recip) [1654/53]

This is a multi-part message in MIME format.

--Boundary_(ID_4e/r5phaqPrEGV9SB+lpTA)

Content-type: text/plain

Content-transfer-encoding: quoted-printable

Attention All Staff Members:

You Must Respond By 5 P.M. Tuesday, September 7, 2004.

Through a special arrangement, Avtech Direct is offering a limited

allotment of BRAND NEW, top of-the-line, name-brand desktop computers

at more than 50% off MSRP to all Staff Members who respond to this

message before 5 P.M., Tuesday, September 7, 2004

Link to comment
Share on other sites

Because the MIME boundries are messed up on this message

Content-Type: multipart/alternative;

boundary="EC95.43A.7_"

This is a multi-part message in MIME format.

--EC95.43A.7_

Content-Type: text/plain

Content-Transfer-Encoding: quoted-printable

--EC95.43A.7_--

text of spam

The entire text of the spam is after the closing boundry (--EC95.43A.7_--). This might be a spammer trying to get around spamcop parsing. I would bring this to the attention of deputies<at>spamcop.net.

Link to comment
Share on other sites

Because the MIME boundries are messed up on this message

The entire text of the spam is after the closing boundry (--EC95.43A.7_--).  This might be a spammer trying to get around spamcop parsing.  I would bring this to the attention of deputies<at>spamcop.net.

Or, is this yet another ad sample of a third-party scripting application used to work around the Outlook issue? It seems like everytime this "version" of MIME boundaries being shifted wrongly like this, one of these "helpers" ends up being part of the picture.

Link to comment
Share on other sites

Or, is this yet another ad sample of a third-party scripting application used to work around the Outlook issue?  It seems like everytime this "version" of MIME boundaries being shifted wrongly like this, one of these "helpers" ends up being part of the picture.

17024[/snapback]

Hmm... Could be. I'm using SpamDeputy with Outlook 2000 at work. Unfortunately, it's either that or don't report spam from work... I don't get a LOT of spam at my work address, but what I do get I like to LART! Could someone please call this to the attention of the deputies??? I no longer have the original spam, so I can't really do much...

Link to comment
Share on other sites

Hmm... Could be. I'm using SpamDeputy with Outlook 2000 at work. Unfortunately, it's either that or don't report spam from work... I don't get a LOT of spam at my work address, but what I do get I like to LART! Could someone please call this to the attention of the deputies??? I no longer have the original spam, so I can't really do much...

I'm not sure what you're looking for. All the Deputies have seen this, Don has seen this Julian has seen this, I've seen this ... but it's not a parsing or reporting thing .. the problem is whatever is causing the spam submittal to be provided in a hosed condition. I'm not saying that SpamDeputy sucks, I was only pointing out that everytime this "condition" shows up, a third-party tool to work around the Outlook issues was involved. I can tell that I cannot recall anyone ever troubleshooting the problem and coming back with a "here it is" answer. What's always been "needed" is to see the spam prior to the third-party tool (and Outlook) messing it about to figure out why things get so screwed up .. the problem there is that most folks who are saddled with using Outlook don't have other options, others don't have or want to spend the time, and this is all over some folks' heads ....

Link to comment
Share on other sites

Since I received almost exactly the same spam as the original poster (albeit from a different server and with slightly different MIME headers), I did some comparison. What I see is interesting.

If you compare the message from the OP:

http://www.spamcop.net/sc?id=z658325043z4f...&action=display

with the message I received:

http://www.spamcop.net/sc?id=z673154943z75...&action=display

The thing I find interesting are these two lines in the unmodified original:

Call Avtech Direct 1-800-884-9510 before 5 P.M. Wednesday, September 22, 2=

004

Note that the MIME-Encoding is quoted-printable. In the message I reported, the content is still in quoted-printable form, as indicated by the "2004" being split across lines with the "=".

However, in the OP's message as reported, that has been reformatted to:

Call Avtech Direct

1-800-884-9510 before 5 P.M. Tuesday, September 14, 2004

I wish there were more quoted-printable things (more "=", the "quoting" character used by quoted-printable) in the message to prove my hypothesis, but it sure looks to me like something along the line removed the actual quoted printable material from between the MIME headers and

the boundary marker:

--EC95.43A.7_

Content-Type: text/plain

Content-Transfer-Encoding: quoted-printable

--EC95.43A.7_--

As stated before, the message SHOULD be _above_ that MIME end marker, not below it.

The question is: did a mail system along the way do this, did the reporting mechanism do this, or did the spammer send it out this way (i.e. since it came via a different server than my message, was it modified before mailing by the spammer)? When this happens, is the body of the message always decoded from the encoding scheme indicated by the MIME headers?

/john

Link to comment
Share on other sites

I'm not sure what you're looking for.  All the Deputies have seen this, Don has seen this Julian has seen this, I've seen this ... but it's not a parsing or reporting thing .. the problem is whatever is causing the spam submittal to be provided in a hosed condition.  I'm not saying that SpamDeputy sucks, I was only pointing out that everytime this "condition" shows up, a third-party tool to work around the Outlook issues was involved.  I can tell that I cannot recall anyone ever troubleshooting the problem and coming back with a "here it is" answer.  What's always been "needed" is to see the spam prior to the third-party tool (and Outlook) messing it about to figure out why things get so screwed up .. the problem there is that most folks who are saddled with using Outlook don't have other options, others don't have or want to spend the time, and this is all over some folks' heads ....

17358[/snapback]

According to the SpamDeputy mailing list, it appears that the website is NOT LARTed because the spammer has intentionally broken SpamCop's parsing routines by adding a second content-type header in the middle of the email. I can post the "raw" email (as shown by SpamDeputy in the "view" option) if that would help... I tried using the "outlook" interface but SpamCop said it wasn't in a "b0rken" format, so that's not the problem... I guess I'll forward a copy to "deputies" and see if there's something they/Julian can do...

The fellow list user suggested altering the headers to force SpamCop to parse it, but IMNSHO, that violates the rules.. Here's what the fellow SD list member said to do:

For what it is worth, when I've experienced what you are reporting, I just

remove the old content type from the message and paste this:

  Content-Type: text/plain; charset=ISO-8859-1

Into the message so SpamCop will handle the reporting properly.

Good luck on getting the bugger reported.

Any deputies want to comment on the "legality" of changing the content type header to make it parse?

Link to comment
Share on other sites

Any deputies want to comment on the "legality" of changing the content type header to make it parse?

Not a Deputy, but .... this will be met with the "official" guidance of "no material changes" ... Yes, this might work for some spam. Other spam will end up with bad parsing results. And the problem is that if one allows this "guidance" to go forward, users that don't know the difference berween the spam constructs and contents will end up getting their accounts whacked, then complaining that they were following this "guidance" ....

If "correcting" the spam was to be attempted, it would make more sense to "correct" the Boundary Line data (positioning) ... but ... a this point, I have yet to be able to make the decision as to whether this problem is a spammer construct or something funky with these third-party work-arounds. I'm not accusing any of these other "solutions" as being screwed, just pointing out that in most, if not all, of the samples provided to demonstrate this problem, it's been by someone trying to work around their use of Outlook using these other tools.

because the spammer has intentionally broken SpamCop's parsing routines by adding a second content-type header in the middle of the email

Close, but not correct ... the issue displayed in all the samples I've seen thus far is that the "ending" Boundary Line has been moved up to immediately under the "starting" Boundary Line ... resulting in "no content" seen between the start and end definition lines .. the remainder of the actual spam seen from the parser as just additional garbage, like filter busting trash .... (for serious giggles, look at the samples provided by jrcovert in a previous post and compare the Boundary Line positions ... then dig back a bit and note what applications are involved in those two samples)

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...