Jump to content

Blank subject, blank TO:, blank body:


flagginator

Recommended Posts

For the past couple of months about 5% of my spam has blank TO:, blank SUBJECT, and blank BODY

The majority of them are from overseas, but sometimes they're rr.com, aol.com, and so forth.

Any ideas what's up with this?

Here's a sample tracking # and URL:

1326740863

http://www.spamcop.net/mcgi?action=gettrac...rtid=1326740863

The "BODY" is what comes up when I do a VIEW SOURCE of the email, so the emails are sent HTML, not plain text.

Why would a blank email be sent HTML?

What are they testing for with these blank emails?

Are others getting a fair number of these too?

Should I report these as spam? They are annoying.

Link to comment
Share on other sites

Report ID numbers are good ... However, only SpamCop staff and admin can use them to query the database. For the "rest of us" it's just an intersting bit of data that leads nowhere. Sorry.

The terminology used gets a bit baffling. One can accept that vaious header lines are empty. But the flip-flop between "No/Blank Body" and "here's what's in the body, a bunch of HTML" doesn't jive. A "blank body" e-mail has nothing in the body. An e-mail that contains a "bunch of HTML" isn't blank, it's more likely that your e-mail application isn't rendering the HTML (probably because you configured it that way) ...

I get "blank" e-mails, though I'd describe mne more as broken, as the headers are almost always incomplete also. Your other 'version' of blank e-mails I can't say I've seen, but that's because I don't allow HTML to render, so all I see is in fact the actual e-mail and all it's full contents (the HTML and anything else showing as plain text) ... so one could say that they may "appear" blank from one view, noting that the e-mail size is 22k suggests that there's something there beyond just a bit of header data.

Link to comment
Share on other sites

I did not log the Tracking URL before submission. Is there a way to recover the tracking URL after the fact? All I find is the Report ID #.

Right, since I don't render HTML the email body looks blank. A plain text email if right-clicked on the body will not show the option of "View Source". However, all these "blank" emails do have the View Source on right-click in body option. So, I assume they're being sent HTML.

I'll save a Tracking URL when I get the next batch in.

What extra information would be gleaned from providing an actual Tracking URL?

My main questions are:

1. Why would anybody spam "blank" emails?

2. Is anybody else getting a significant percentage of these?

These blank ones started showing up shortly after the current blizzard of "Rolex Watch" spam variations.

Link to comment
Share on other sites

PS: I believe if you go to the Report ID, and click on the Parse link, you'll seeĀ  virtually all the information that a proper Tracking URL would have provided.

If I had your account name and password, perhaps <g>

Error message I get when trying to follow your link;

Could not find header, or not authorized (you are not the report sender or recipient).

Link to comment
Share on other sites

I did not log the Tracking URL before submission. Is there a way to recover the tracking URL after the fact? All I find is the Report ID #.

Re-submit the spam, capture the Tracking URL, cancel the report, post the Tracking URL.

What extra information would be gleaned from providing an actual Tracking URL?

My/Our ability to see the actual spam in question.

My main questions are:

1. Why would anybody spam "blank" emails?

If one goes with a fully-formed e-mail, then the answer would probably be that the targets are for the masses that don't have a clue, thus they "see" what's included and act accordingly. Again, for those clueless enough to follow links in a spam, their systems probably aren't showing a "blank" <g>

In all honesty, I can't seem to think like a spmmer <g> I recall one client, really upset at all the garbage coming in, spoiling his business e-mail something fierce, bitching about those low-life individuals that did this, and asking how they got his e-mail address in the first place. On another day, this same client calls me up and wants my opinion on some kewl software he'd just bought ... just program in a few things and the sucker would go through newsgroups and build lists of e-mail addresses .. figuring that anyone posting in "that" newsgroup (or two, why limit yourself) would be interested in hearing about his product .... (Picture the brick-wall-head-banging that went on before trying to sit down and explain things from the top all over again <g>)

2. Is anybody else getting a significant percentage of these?

These blank ones started showing up shortly after the current blizzard of "Rolex Watch" spam variations.

Again, a bit hard to answer. I couldn't tell you how many of your blank e-mails I get, as they don't show that way here, I don't 'read' them anyway, .... but that you'd be the only one on the world getting them is pretty doubtful <g>

If you go with the "broken" spams, I've probably seen 50+ in the last month. It's still never been decided whether these were broken spamware, clueless users, busted servers/compromised machines, spew stopped in mid-stream, or a quicker way to gather bounces of bad addresses ...???

Link to comment
Share on other sites

Based on the contents of that sample, I'd really like to see a 'real' e-mail. The lack of data far exceeds even those I'd been describing as "broken" ... I'm not even sure what's tripping the error flag to offer up the message;

Finding links in message body

Header data found in body, aborting link detection

Other than the e-mail is so incomplete, this is just where the parse gave up and made a 'best-guess' at the condition ..???

I am kicking your data to another rr user over in the newsgroups to see what light can be shed by him.

Link to comment
Share on other sites

[Munged by parser]

Parse

>>>>

Return-Path: <RLLZBGCP[at]doramail.comE>

Delivered-To: x

Received: from cs2416211-226.houston.rr.com (24.162.11.226:4277)

by xmailserver.test with [XMail 1.20 ESMTP Server]

id <S102D7F> for <x> from <RLLZBGCP[at]doramail.comE>;

Thu, 30 Dec 2004 10:44:51 -0500

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>

<BODY></BODY></HTML>

<<<<

Link to comment
Share on other sites

OK, I'll bite. This last post looks like one I had deleted previously, as it (still) appears to be the same item pointed to by the Tacking URL you provided. Why the second / re-posting of the same thing?

OK, now a bit later, working on something else ... old dusty bells went off in the back of the mind .... is this another instance where I have "Show Technical Details" ticked and you don't ... thus you don't see the link View entire message .....????? (It's been a while since this came up)

Link to comment
Share on other sites

Mike's analysis just reinforces the strangeness I saw ...

-=-=-=-=-=-=-

WazoO wrote:

> Gmail - query on a sample spam received via rr server http://www.spamcop.net/sc?id=z707855236z40...bd26589d1233caz

>Discussion at http://forum.spamcop.net/forums/lofiversio....php/t3333.html

> It's hard to even call this an actual e-mail, but .... have you seen this stuff .. or did the user do this before / while submitting it?

I can't see anything in the mail that would have me not post here.

spamcop.net/sc?id=z707855236z40adc0865406f78715bd26589d1233caz

When I was RR I never saw anything like even the only Received line.

That is to say, that is not a RR received mail, not a RR server in the 'by'.

The item is /from/ a RR IP [see below] on an oddball port to some kind

of screwy noncompliant server:

Received: from cs2416211-226.houston.rr.com (24.162.11.226:4277) by

xmailserver.test with [XMail 1.20 ESMTP Server]

What is an exmailserver.test domainname supposed to be? What is it

doing smtp/ing on 4277?

What does this SC mailhost verbose mean?

Hostname verified: cs2416211-226.houston.rr.com

www.aabbco.com received mail from sending system 24.162.11.226

That doesn't make any sense to me. SC's verbose is bad enough when I'm

trying to figure out 'ordinary' parsing. When it is doing its 'mailhost

thing' sometimes it is completely baffling.

Supposedly the XMail ware will compile under multiple different kinds of

OSes, /n/x of various iterations including Solaris, Win nt/2k/xp

The only 4277 I know is vrml multiuser system, and I don't know what

that has to do with mail. I don't know of trojans with that.

The source IP itself is listed all over the place and is in sightings;

without the 4277 attached. It is also SCbl listed as a source and cbl

as a proxy/trojan. It is also listed in MyNetWatchman as smtp incidents

--

Mike Easter

kibitzer, not SC admin

Link to comment
Share on other sites

Now I'm ticked off: SpamCop is supposed to munge the reports. But, by adding

;action=display

to a TRACKING URL, you can get the unmunged message.

Because of that I'm sorry I ever started this thread. :angry:

Now, I'm really going to get spammed.

Please delete this entire thread, and please go to the other forum and ask them to delete all references too.

Thanks. Sorry to bother you.

Here's what my preferences look like, and I clearly stated I want the reports to be munged:

>>>>

[x] spam Munging

[x] Obscure identifying information

[ ] Leave spam copies intact

[ ] Become a "mole" - Don't even send reports (mostly pointless)

SpamCop usually tries to obscure (munge) your email address and other identifying information from spam reports before they are sent. However, some ISPs will not accept this type of report.

If you select munging, SpamCop will not send to ISPs which refuse munged reports by default (you will be given a default-off option when using the web-interface). If you select intact spam copies, SpamCop will send all reports unmodified.

It has become painfully obvious that spammers are able to identify your email address by using tracking codes - even after SpamCop's attempts to munge them. It has also become plain that even the largest and most well-respected ISPs forward complaints intact to the accused.

In response, we now offer the ability to send reports silently. These reports are not emailed and are not available to anyone but SpamCop administrators and will not be shared (except as aggregate counts).

<<<<

Link to comment
Share on other sites

Delivered-To: x

Received: from cs2416211-226.houston.rr.com (24.162.11.226:4277)by xmailserver.test with [XMail 1.20 ESMTP Server]id <S102D7F> for <x>

Certainly looks well and truly munged ...???? The only other address showing is the alleged address of the originator of the e-mail ... if the same as the recipient, the parser would normally have munged it ... if this is the address that has you ticked off, there has to be something more to what's actually going on, between the e-mail itself, how/where it originated, and how you are handling the submittal. I admit to being even more baffled at this point.

Link to comment
Share on other sites

discussion went further while I was off doing other things .. leave it to Mike to make things even more interesting <g> ....

-=-=-=-=-=-=-=-

WazoO wrote:

> "Mike Easter"

>> What does this SC mailhost verbose mean?

>>

>> Hostname verified: cs2416211-226.houston.rr.com

>> www.aabbco.com received mail from sending system 24.162.11.226

>>

>> That doesn't make any sense to me. SC's verbose is bad enough when

>> I'm trying to figure out 'ordinary' parsing. When it is doing its

>> 'mailhost thing' sometimes it is completely baffling.

>

> In this case (and as I understand it ... use you own judgement <g>)

> whoever first went through the MailHost configuration on their

> reporting account had the "oppotunity" to give their e-mail host/ISP

> a "name" .. that user chose www.aabbco.com to "name" this place that

> handled their e-mail. Being cute, testing the waters, something to

> keep things straight in their own mind, who knows why this was chosen

> as the "name" ...

>

> The catch is, the database is a bit "shared" .. such that the next

> person that comes along and runs through the MailHost configuration

> on their account, but also happens to be an "xmailserver.test"

> customer can "name" their e-mail Host/ISP whatever they want,

> but the "alias" (?) has already been assigned by the first user.

Well, I understand that 'concept' all right, but look at what the

verbose words say, and then play it out from there.

Hostname verified: cs2416211-226.houston.rr.com

That 'statement' has nothing to do with the hostname. The only thing

which can possibly be the hostname is what is in the 'by'.

Here's the line in question:

Received: from cs2416211-226.houston.rr.com (24.162.11.226:4277) by

xmailserver.test with [XMail 1.20 ESMTP Server]

So/then here's the next part of the verbose

www.aabbco.com received mail from sending system 24.162.11.226

So, here's where the 'whatever' hostname name comes up. The 'by' sez

xmailserver.test, so somehow xmailserver is the mailhost, not what the

preceding line said but the mail host is actually aabbco which might not

even be the appropriate domainname but a made up one - which aabbco

really /is/ a domain name with the IP 66.36.240.136 - which, BTW, rDNSes

to sls-da1p10.dca2.superb.net

So, we have SC saying the mailhost is the RR bad user IP - which we know

is untrue.

We 'know' that the /real/ mailhost is in the 'by' - but the by sez

xmailserver but that is really aabbco which is I don't know what which

also rDNSes to superb.

--

Mike Easter

kibitzer, not SC admin

-=-=-=-=-=-=-

Link to comment
Share on other sites

After adding the ;action=display

it's revealing my Mailhost(s) and the TO:, and that's not cool.

I'm seeing exactly the same thing that you posted in the item I deleted, then you re-posted as Post #13 in this Topic/Discussion. Are we actually talking about the same thing? In the spam submittal seen via the Tracking URL, there is no To: line, only the previously mentioned Delivered-To: .... which is part of the confusion as to just what you submitted and how this sample was obtained. You started with stating that some header items were blank .. in your sample, they flat don't exist ...???? Then, add in the digging that Mike did (embarassed a bit that I didn't bother to scratch the surface at all before asking him to take a look) .. and there's the bit of wodering if there's a server configuration/handling issue involved.

Link to comment
Share on other sites

Whether or not you add ";action=display" to a Tracking URL, you will get munging unless you are using the account that created the Tracking URL. If you are seeing the unmunged version and you want to see the munged version, please logout and retry. Thanks!

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...