Fake Bounce

[Tim P]

http://www.spamcop.net/sc?id=z688577509z56...158b922a67b934z

There is no parse for the last rec'vd line.

SC parser is counting this message as a bounce and that it is too old.

Wrong on both. I just got this one and it has java scri_pt in the body. Note also the multiple To: recipients.

Please fix this parsing problem

If this is an exploit, please indicate if it is.

Thanks

[Wazoo]

The last Received line is simply a crappy "fake" line, probably inserted by some lousy spammer software. It is totally bogus, thus not worth even discussing.

The "it's a bounce" exploit is currently driven by at least three (currently common) different items in the spam construct. Your spam contains one of these constructs, so yes, spammer did this intentionally to screw up the SpamCop parser (or was a genuine attempt at doing the social engineering game to get you to open the spam to find out why it bounced)

Your comment that the parser found this to be "too old" is in error. The message you see is "Message is old" which is in lieu of the "Yum, spam is fresh" .... that decision point being that the spam was submitted to the parser within two hours of receipt (date/time taken from the topmost valid received line [note announcements recent post that this is now supposed to read as topmost "trusted" line])

[dbiel]

<snip>

[note announcements recent post that this is now supposed to read as topmost "trusted" line])

19547[/snapback]

Don't you mean botom most trusted line?

Trusted or valid are reasonably synonymous, I think, when looked at from the point of view of the parser  -- if you have MH then it will be taken from the oldest trusted/mailhosted header and if you don't have MH then it is the oldest header that the system thinks is associated with the reporter which is usually the ISP header. While there were not a huge number of cases of big lags in timestamps between adjacent headers (i.e. the spam languished on a server for a while for some unknown reason) there were enough cases so that this made sense to do.

So basically this is a refinement in the process of trying to figure out when the spam first arrived at the user server where user server is the server that handles the mail that the spam was addressed to, which may or may not be the server which finally delivers the mail into the user's end mailbox.

Ellen

[Wazoo]

Don't you mean botom most trusted line?

Let me put it this way. I know what I meant, and I know how it used to work. I'm having to wait and actually (remember to look and) see what is going on, and to do this, I only get the opportunity while trying to analyze someone else's spam submittal problems (that is onfigured to use MailHost) At this point, I'm not even sure if this is going to be possible, only being able to try to catch the "Yum - fresh" or "message is old" comment, see what date/time was used in that calculation, and all that is going to be based on the coincidence of someone posting a "fresh" Tracking URL and that I catch that post quickly. Until I see this and can see what it's really doing, I'm a bit in the dark. Again, I know what I have in my head from the historical, I can read what Ellen has said, but I haven't worked out just what Julian may have actually coded that goes along with Ellen's description, tripping a bit on the phrase "the oldest header that the system thinks is associated with the reporter" .... that one's a bit scary to try to second guess at what's behind that decision process ...

[Jeff G.]

I think the decision process is as follows:

• Parse Received Header Lines normally, until you determine which one indicates being from the spammer (the one you'd suggest for reporting).
  
• Compare the date on that Received Header Line to "Now".
  
• If the comparison indicates that the spam is over 48 hours old, reject the submission on that basis.
  

[Wazoo]

I'm still laughing over Mike Easter's presentation of how he's trying to interpret that same thing over in the newsgroups, ... happy that I'm not lone in the guessing game ...

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

The latest pasted statement is

"The parser takes the date from the earliest trusted received line.

Rather than what it used to do, which was take the date from the

top-most received line."

I'm not perfectly 100% clear what 'earliest' means in this context, but

I think I understand. What I'm assuming it means is 'the furthest down'

or 'bottommost' trusted line. Using a word like 'earliest' in the

context of time makes it sound like the parser is comparing /times/

between trusted lines, which I doubt.

A line is trusted if it belongs to your mailhost. A line is trusted if

it is the topmost. A line is trusted if it belongs to a server which is

trusted to be a server.

-=-=-=-=-=-

I'd say we're all in agreement .. nobody but Julian actually knows what he's got the code doing right now <g>

[Tim P]

The last Received line is simply a crappy "fake" line, probably inserted by some lousy spammer software.  It is totally bogus, thus not worth even discussing.

The "it's a bounce" exploit is currently driven by at least three (currently common) different items in the spam construct.  Your spam contains one of these constructs, so yes, spammer did this intentionally to screw up the SpamCop parser (or was a genuine attempt at doing the social engineering game to get you to open the spam to find out why it bounced)

19547[/snapback]

So, in the future how would one parse messages like this to reveal the source. The line after the MH is not Postmaster[at]Yahoo- and what exploit tells (or fools) the parser into calling it a "bounce" message?

That is...would there be an mx record in the header (somewhere) that would show postmaster[at]yahoo actually sent this message?

[Wazoo]

So, in the future how would one parse messages like this to reveal the source.  The line after the MH is not Postmaster[at]Yahoo-

That is...would there be an mx record in the header (somewhere)  that would show postmaster[at]yahoo actually sent this message?

I'm not sure I follow the question. I just looked at your tracking URL and basically, it identified the cource of the e-mail. Based on the "bounce" situation, the next step would be to compose your own complaint to that address (However noting that in reality, the address offered up in this case actually appears to be an "internal routing address" .. something worked out between the SpamCop Admin folks and btinternet, so you'd really want to look up a "real / public" address to send your report to, in this case .... abuse[at]btbroadband.com)

The obvious clue as to an e-mail from Postmaster[at]Yahoo ... it would have come directly from a Yahoo server ...???

and what exploit tells (or fools) the parser into calling it a "bounce" message?

I'm not sure I want to actually explain it. The spammers that already know these things, use them. Those that don't, well, why make it easy for them to add to your misery?

[Jeff G.]

So, in the future how would one parse messages like this to reveal the source.

19609[/snapback]

Just like you did. The parser correctly rejected the Received Header Line which blamed reserved IP Address 124.104.86.150.

would there be an mx record in the header (somewhere)  that would show postmaster[at]yahoo actually sent this message?

19609[/snapback]

Yes, if someone actually authorized by Yahoo! to use the address postmaster[at]yahoo.com had in fact sent it. AFAIK, Yahoo! doesn't send to Yahoo! addresses through BellSouth or BT.

[Tim P]

Just like you did.  The parser correctly rejected the Received Header Line which blamed reserved IP Address 124.104.86.150.Yes, if someone actually authorized by Yahoo! to use the address postmaster[at]yahoo.com had in fact sent it.  AFAIK, Yahoo! doesn't send to Yahoo! addresses through BellSouth or BT.

19613[/snapback]

Precisely my point.

Why wouldn't the parser determine this?

[Wazoo]

Precisely my point. 

Why wouldn't the parser determine this?

What did I miss? The parsing output made no mention of an issue pointing to Yahoo.

[Jeff G.]

What did I miss?  The parsing output made no mention of an issue pointing to Yahoo.

19619[/snapback]

It appears that:

• The spammer sent the spam from BT for that Yahoo! account to BellSouth.
  
• For some reason (perhaps a forward or a compromised SMTP/AUTH system), BellSouth sent the spam along to Yahoo! for delivery to the OP's Yahoo! account.
  
• popgate grabbed the spam from Yahoo! for the OP.
  

[Tim P]

Sorry for the confusion...

I did that to add spam tracker data (from Yahoo!) to the headers. The Bellsouth addy is my spammed box and I have it auto-forwarded to a Yahoo! account.

The BT mail is the first IP that should have been identified as the source of the forged bounce. The fact that "postmaster[at]yahoo.com" was used should have alerted the parser:

.

Received: from host81-154-159-178.range81-154.btcentralplus.com

([81.154.159.178]) by imf15aec.mail.bellsouth.net

(InterMail vM.5.01.06.11 201-253-122-130-111-20040605) with SMTP

id <20041103150731.WKHJ27621.imf15aec.mail.bellsouth.net[at]host81-154-159-178.range81-154.btcentralplus.com>;

Wed, 3 Nov 2004 10:07:31 -0500

.

That is ... a dynamic IP address listed in the databases. If Yahoo! authorized postmaster "bounce" messages from a home computer, then I will go dancing in the streets nude.

This problem (and others I will not divulge here) are becoming more prevalent- particularly within the last month.

It needs some attention.

[Jeff G.]

Sorry, the parser isn't that smart yet. However, the more misparsed fake bounces you send to the Deputies, the smarter the parser will get.

[Tim P]

Sorry, the parser isn't that smart yet.  However, the more misparsed fake bounces you send to the Deputies, the smarter the parser will get.

19631[/snapback]

Will do that..

[tiredofspam_2004]

Here is one more faked bounce message that actually contains an executable. Hopefully, the parser will be updated soon to handle these kinds of emails.

http://www.spamcop.net/sc?id=z690582361z1b...01f75d43e2eefbz

[Wazoo]

Personally, your sample looks more like an infected system that is spewing garbage ... as compared to a bounce ... and reporting this stuff is also against the rules.