Spammer using Exchange 5.5 for mail relay!!!

First things first, have you checked to see if it is relaying? Simply go to http://abuse.net/relay.html and test your exchange server by using the external ip of the server.

Second, you do realize that if relaying is disabled all accounts that can successfully authenticate can still relay. With this in mind, you might want to perform a full password change across the board, this will stop him from relaying. Simple passwords allow for this. In the future, get yourself a linux box and setup sendmail/mailscanner/spamassassin to sit in front of your exchange server, it won't happen again.


Cheers

Brad

Nope, it's not relaying, and as for the "successfully authenticate" what do you mean by that?  Would that be ANY user on the network that has their account linked to a mailbox in Exchange?

-Javin

Additional Note:  I'm actually the programmer for the network, and if nothing else, my next step is to write an app as a relay for our SMTP traffic that simply drops off anything that's not destined for our domain, if I can't find another option.

-Javin

By default, exchange 5.5 servers  allowed relaying. To turn off relaying you had to check the box that said "all users can relay that succefully authenticate" within the Internet Mail Connector. That's how Outlook Express relays mail through an exchange server, it "successfully authenticates" hence your username and password for the smtp portion of outlook express. If someone were to "guess" a username and password for your domain or somehow obtain an account they could relay. Don't waste your time writing an app, a simple linux sendmail server could act as a relay for your domain, why re-invent the wheel?

Cheers

Brad

Mostly because we can't have a Linux server on our network.  (Requirement by the customer.)  But please explain this "all users can relay that succefully authenticate" thing.  I've not seen anything in Exchange with that kind of syntax.  I've seen stuff where you would require authentication before someone could make a connection, but that's useless since it kills all incoming connections except from "authenticated" sources which rules out AOL, YAHOO, etc.  Maybe I'm not following you, but what "username and password for the domain" are you talking about?  Chances of them just "guessing" one of our user's passwords are slim to none with our password requirements, and also include the fact that they figured out how to get in BEFORE any users were actually added to the network.

-Javin

Specify the hosts and clients that can route mail when the following conditions have been met.
Hosts and clients that successfully authenticate:


If this is not checked , anyone can relay through your server. if it is checked, someone has a password, it's the only way someone can send mail through your server.

Sorry this has taken so long.

As it turns out, the problem comes from a known bug and security issue in Exchange 5.5:
http://support.microsoft.com/default.aspx?scid=kb;en-us;310669&Product=ech

However, the "hotfix" supplied by Microsoft admittedly (by them) does not work on all systems.  Ours being one of them.  They simply threw their hands up in the air and said, "I guess you'll  have to buy Exchange 2003!"  They did still charge us for the tech support call, though.  Alot.

At any rate, the solution I came up with was to write a simple SMTP filter myself that watches for E-Mails trying to be sent to any user not on our list, and if it finds one, IT rejects the user with a 550 error without giving Exchange a chance to even see the user.  

In the span of all of this, I've done an incredible amount of research on the E-Mail protocols we use.  It really is phenominal just how simple SMTP and POP3 is.  It's even more amazing that Microsoft has gone to such lengths to make it appear so complex, to the extent of leaving a gaping security hole that *I* can fix with a 10 minute app written in VB.  Needless to say, I am not even remotely impressed with Microsoft anymore.

I'll go ahead and split out the points to those who tried.

-Javin

Hey , even if your server is not relaying, it will atleast send NDRS(nON DELIVERY REPORT).If your spammer is not using a valid email address then where will your exchange send the NDR to???.You have to stop these NDRs.
There is a new hotfix that will allow Exchange 5.5 administrators to prevent the creation and delivery of NDRs.  
HotFix:837794.Its free.call microsoft, they will give you.
Dominic

 

You can disable NDRs in Exchange 2000 and Exchange 2003…and now you can disable NDRs in Exchange 5.5 too.  Due to some of the recent email viruses and worms, email is being sent to organizations that have invalid addresses causing a lot of NDRs to be generated.  This was bogging down the Exchange 5.5 IMS.  This hotfix updates the Internet Mail Service and forces it to read a registry value.  This registry setting can be changed by the administrator to any 1 of 4 options (see below) that allows them to control how NDR generation is handled.

 

HOTFIX 837794 (bug # 240575)
Version 2658.3
msexcimc.exe & imcmsg.dll

 

Registry description
-----------
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIMC\Parameters

 

Value name: SuppressNDROptions
Data type: REG_DWORD

 

Setting_________Result______________________________________________________

If enabled 0x0001, IMS doesn’t send any NDR message out.
If enabled 0x0010, IMS don’t created NDR message. This include two parts.
1> If send message to a certain test@bogus.com, the rejected mail should be NDRed to the sender, this NDR message will not be generated.
2> If receive a message, and the user address can’t be resolved, NDR will be generated and sent back to the sender. Those NDR will not be generated. So when this bit is set, bit ox0001 is useless, no NDR for IMS to send at all.
If enabled 0x0100, IMS doesn’t deliver messages without SMTP return address. This include NDR, DR.  

 

More clarification on the settings:

0x0000 is NOT set

0x0001 is set - no NDRs are sent outbound.

0x0010 is set - no inbound NDRs will be received and no NDRs are sent outbound.

0x0100 is set - no DSNs are sent including NDRs, delivery receipts (DR), etc.

 

Article link (unfinished):

 

837794 for Exchange:240575 IMC: block generation of NDR messages
  http://kb/article.asp?id=Q837794

 

Related: How to disable/suppress NDRs with Exchange 2000 and Exchange 2003:

 294757 How to Control Non-Delivery Reports Using Exchange 2000
http://support.microsoft.com/?id=294757

I appreciate the information (especially considering the points were already awarded.)  It's good info, and good to know.  However, with the SMTP Filter I wrote, NDRs aren't even an issue.  The filter simply sits between the Exchange Server, and the Internet, and it "hands off" all SMTP traffic to the Exchange server, but checks it first to see if the addresses being sent are on a predetermined list.  If they're not, it never even sends the RCPT TO: command to the exchange server.  Instead, it returns a 550 error to the sending server, which in turn causes the sending server to send a QUIT command, usually, or just disconnect.  If this happens, my app then sends an RSET to Exchange before terminating the connection, thus, an NDR is never generated.

Good info to know, though!  Thanks!

-Javin

Javin,

I'm having the same spam problem with my exchange 5.5 server.  How can I go about getting a copy of the SMTP Filter you wrote?  The schools old e-mail server (where I work) is getting hammered and I haven't found a good solution anywhere else on the net.  They do not want to relay any messages and only want to allow messages to be received that are for the domain users.   Any help would be greatly appreciated.

Thanks

Ted

Ted-

I'd never actually intended to package and send this out, but if you want to give it a shot, you're welcome to it.  I added some ability to customize it so you can use it.

http://www.Javin-Inc.com/Software/SMTPFilter.exe

Things you need to know:

To set it up, you will need to either a.) Have a second PC that mail will relay through, or b.) Change the incoming SMTP port on your Exchange server. (Possible, but much more difficult.)  Take this new second PC, and give IT your Mail server's IP address.  Then give your mail server any other IP address.  Keep in mind that if your firewall blocks OUTGOING SMTP traffic except from your mail server, you'll need to reconfigure your firewall to the new IP of the mail server.

Essentially, what you're doing is having the mail come IN to your SMTP Filter app, and the filter app then just hands it off to your actual mail server.  In the meantime, it's keeping an eye out for any mails that are sent to illegal recipients, and sending a rejection message when it sees them.  Your mail server will never see a bad RCPT TO, since that's being caught at the Filter, and rejected.

Once installed, go to C:\Programs\SMTP Filter\peeker.cfg and make some changes.  Put the new IP for your mail server under [Mail Server] - IP (standard INI format).

That should be the only thing you really need to do until you want to get funky with it.  

Now, under users.txt, open that and put either a wildcard showing your whole address:  *@YourCompany.Com
OR, put each user's address in individually:
User1@YourCompany.Com
User2@YourCompany.Com
User3@YourCompany.Com
(One address per line)

I prefer the latter (if you don't have too many users) so you can also bounce out E-Mails that no longer exist on your server, but used too.  Exchange 5.5 accepts THOSE, too, but then like December41991 said, it ALSO generates an NDR report, causing TWICE the workload on your server.  (I suppose I could have it check the Exchange server to see what addresses are in it, if I knew where Exchange stored that info, but I haven't had a reason to bother.)

When the "peeker" (as we've affectionately dubbed it) is running, it'll be a small mail icon in your SysTray.  Double-click on that to open the "peeker" and you'll be able to "peek" at all traffic transpiring between your mail server and the internet.  Keep in mind that this only holds 5000 bytes before it's dumped to a log file and the screen is wiped.  If you really need to study something that's happened, go to the application's folder under "Logs" to look at them.  If you do this, make SURE you make a COPY of the log before opening it, since you'll crash the app if it tries to open the log to do a dump while you've already got it open.  This logs EVERYTHING.  Now, if you're like us, you won't get but MAYBE 50 megs of traffic in a month, so that's not a bad deal, and is handy for going back and checking on things later.  However, if you're generating 100 megs of traffic a DAY, you'll want to turn logging off.  (Best to do this in the .cfg file and restart the peeker).

There's also an Ignore List.  If you notice someone from a certain IP address consistently trying to screw with your servers, just add his IP (or his IP block) to the ignore list just like you did with the users list.  (One IP per block.)  This also supports wildcards, ie: 208.127.41.*

It'll be pretty obvious when the peeker is and isn't working.  If you see it "chatting" with the mail server, then it's working.  That's all there is to it.  It's not that complex.  Just remember to add the list of allowed E-Mail destinations to the Users.txt and you should be good to go.

Let me know how it works out for ya, or if you run into any problems.  (Keep in mind I didn't design this as an app I was going to distribute, so it could throw some fits once you install it.)

-Javin

Anyone got that Hotfix 837794 and want to save me a call to M$ft?

*heh*  Good luck.  When it doesn't work, you're welcome to use the filter app, too.

http://support.microsoft.com/default.aspx?scid=kb;[LN];837794

-Javin

It was a lot easier than I thought to get - I just called their 1-800 number, they didn't even ask for a Product ID # - It was very odd.  Anyway, I installed the hotfix, did their registry tweaks, brought the system back up - AND GOT THE SAME SH!T.

I then deleted the IMS Connector, re-installed it - and now I have no NDRs, no matter the setting of their registry key.

My only thought is that my computer was compromised and that someone replaced my msexchangeimc.exe file (or whatever the IMS exe is).

Anyway, it's now been hours with no BS mail...  Time to head home..

Thanks again for all the help.

Hey cshorter, you wouldn't happen to have that hotfix file on you would you? I don't want to wait til Monday to call MS and if you had it handy and could email it to mfindlay@speakeasy.net that would be so helpful!

Thanks everyone for the above info!
Mark

Hi 'c chorter' and 'rascal' - can you tell me where I can find this hotfix or send it to me at sas@softwide.com ....pleeeze.... I'm getting a bit desperate... and whilst I'm pleased for you two that your contact with MS in the US was a 'cool' experience, I can't really say the same here in the UK.
I really would appreciate it - in the meantime I'm sinking to a 'hotspot' account on our 5.5 SP4 Exchange server but the traffic is bursty and hits us flat for 5mins at a time, several times a day.
Please?