Need to find IP of SPAMMERS on Exchange 5.5 Server 2

[chucksel]

Hello,

I am not much of a Exchange 5.5 server so if someone can point me to a good document on how to trace down the IP addresses of SPAMMERS, I would be grateful. I have my "routing" locked down by choosing to only relay mail from addresses on our private subnets and also only authenticated users (for those that POP3/SMTP remotely). Somehow these spammers are submitting bulk mail to my server and I am getting NDR reports such as:

Notification: Outbound Mail Failure - Message timed out

A mail message was not sent because the maximum time for delivery has expired. The message was not delivered to the following addresses:

The message that caused this notification was:

To: <horoscope@horoscope.wingowin.com>
From: <>
Subject: Undeliverable: Lauren, Your free daily horoscope


I am thinking that there MUST be some way of tracking these people down and blocking their source IP address if one is determined to make an effort to do so. I know that I could just turn off the notification but my users need to know when their legitimate mail is not being delivered.

Any ideas?
Chuck
LAN Admin.
Chuck, MCSE, CCNA
CSS-1 in training

 

[Alshrim]

There is also a way to limite who sends thru the server by ensuring that only people on your server can send out.

This is located in the IMS properties - within the Connection tab. This will ensure that nothing is going out your smtp service without their having an account already on the server.

You can also check you queues -- to see the message caught in your outgoing queue. Openning it up may give you some information - tho' I don't know how much. If you get a DNS host name ... use nslookup -- see what that fosters...

Tracking something like this isn't easy, that's for sure. Alshrim
System Administrator
MCSE, MCP+Internet

 

[devastator]

You can't stop this type of SPAM unless you, 1. Block the originating domain, or 2. Get 3rd party software or hardware that will filter out bogus emails to your domain.

These NDR's are cause by SPAMMMERS that send email to anything@yourdomain.com You Exchange Server is set to accept everything that is to your domain and any sub-domains by default unless you put #yourdomain.com which is just email for your domain only, no sub-domains in the routing tab. So anything@yourdomain.com uses up resources to try to see if there is such an address in you GAL and when it finds out there isn't tries to send back to the bogus email address of the SPAMMER which of course just sits in your mail que.

I have a firewall that filters SMTP that I can put real email addresses in the accept to field thus bouncing all other emails that don't match. This is fine for 100 users or less but would be much more difficult to administor with a larger business. Now I only get a few notifications a week from legitimate out going emails sent from within my domain.


Dev

 

[devastator]

Another solution for you is when you actually get SPAM mail at least in Outlook, you can go to view, options, and see Internet headers at the bottom to see how this message was delivered and from who by scrolling down and seeing the Message ID. You can also cut and paste this information and plug it into this website and run a trace / report.

http://www.3dmail.com/spam/

Dev

 

[Alshrim]

Right .. or .. do an nslookup .. this will actually give you the dns name of the mail exchanger.. and possibly even the ISP info ...

With that info .. you can further email their support or abuse email address and have the spammers bumped.

But like we said.. tracking them is really difficult.... Alshrim
System Administrator
MCSE, MCP+Internet

 

[chucksel]

Thanks for the tips guys. I really appreciate it.

Dev, what firewall allows you to put the addresses in that are legitimate?

Chuck Chuck, MCSE

 

[devastator]

Yep.

I use a WatchGuard Firebox II and there is an option for relaying in the SMTP to put *yourdomain.com for incoming. Instead I deleted that and put in me@mydomain.com, and every other internal user / email. That way everything else is bounced that doesn't match.


Dev

 

[chucksel]

Do you know of any software that runs on the Exchange Server or on a server acting as an SMTP server in front of the Exchange server that acts like that? (bounces messages that are not addressed EXACTLY to a realname@domain.com)

We use an NT 4.0 server that is running Trend's Viruswall virus scanner that is our public SMTP server that scans the incoming mail and then forwards the e-mail to our Exchange server. It can only be configured to accept entire domains ( *@domain.com ) and not individual mailboxes. Chuck, MCSE

 

[devastator]

No not off hand. Was a nice selling point (WatchGuard) when I found out that it could be configured like that.


Dev

 

[saiyan9]

I use SurfControl's SuperScout, and it bouces bogus relays. They have 2 flavors, SMTP and Exchange add-on. Use SMTP, the exchange version cripples your exchange server. You can also place the SMTP version on your Exchange server. You can try it for free, full version for 30 days.

 

[nhyujm]

Health Warning, developer pretending to be an admin here...

Shouldn't you be looking for
&quot;
Notification: Inbound Mail Failure

The following recipients did not receive the attached mail. Reasons are listed with each recipient:

<abogusentry@example.COM> abogusentry@example.COM
MSEXCH:IMS:ORG:UNIT:SERVER 0 (000C05A6) Unknown Recipient

The message that caused this notification was:
&quot;


In addition to the routing restrictions under the Routing tab, our admin has us set &quot;delivery restrictions&quot; to &quot;Accept messages From&quot; a distribution list containing the valid users.

The asianetwork and datapipe spammer's bots have tried and walked away from each server after a day or 2, and we're not blacklisted despite regular ORDB scans so it appears to work ok.

Users and mail administrator still get their outgoing mail failure errors.

We've got the inbound reports, cleared up using a server side rule, when the server got &quot;tried out&quot; but nothing outgoing.

You've checked your ip with ORDB.org and the like to reassure yourself that no spam is actually outgoing, due to a user's poor choice of password or suchlike.

An alternative but remote possibility is that you've an open proxy server on your subnet, allowing the mail to be sent through there. If this were the case, they would probably send out packets directly.
I'd suggest removing the allow subnet routing rule, if it's not too inconvenient.

I'm sure the experts here can rip this to shreads if I'm talking nonsense, but it appears to work.

 

[devastator]

You may be correct on one part about receiving notifications such as if someone mispells ones name (my employees) by a letter or 2 but usually our members call and find out exactly what the email address is and why they are having problems (rarely happens). Also I log that through the Firewall as well so I can see mail that is bounced and who the sender was by IP and Email address.
So with that out of the way, I don't want to recieve inbound notifications that jennajameson@mydomain.com doesn't exist. I know it doesn't and further more why would I want my exchange server to put in the que an NDR back to the SPAMMER that there is no jenna @ my domain. The SPAMMER most likely didn't use a legitimate email address anyway so thus the NDR (<>) just sits in my que waiting for my default setting for mail delivery to stop trying and generate a notification report with originator <> to joeblow@aol.com was undeliverable.

I do recieve all outgoing notifications so that if one of my employees send something out and the email is incorrect or the members server is down that we get the notification back that the mail was undeliverable and with the errors you exampled above.

Remember that I was refering to email coming in to our domain to addresses that don't exist internally on our GAL, that would generate an NDR from our Exchange Server back out to the sender (SPAMMER).

Dev
Dev

 

[devastator]

P.S.

I have nothing against your post or Jenna Jameson.........just trying to shed some light.......