RE: Relaying Problem question - still fighting it!

  • From: "Allen, Chris" <CAllen@xxxxxxxxxxxxxxxx>
  • To: "[ExchangeList]" <exchangelist@xxxxxxxxxxxxx>
  • Date: Tue, 30 Sep 2003 15:10:39 -0400

Disallowing the authenticated users will do it, but it does open other
issues. I would recommend a mass password change, but if you can figure
out the account(s) that is/are compromised, it would be a lot quicker to
fix. If you are certain the spam is not originating in your domain, you
might want to give the solution a look. I have had no unauthorized
relays since unchecking that box.


-----Original Message-----
From: KEN MORRIS [mailto:KMORRIS@xxxxxxx] 
Sent: Tuesday, September 30, 2003 3:03 PM
To: [ExchangeList]
Subject: [exchangelist] RE: Relaying Problem question - still fighting


I saw your previous email and added the IP's on Monday, however it
appears that what ever user has been compromised, they have gone to town
with it and given it out to others. I am now finding my queues filling
up with many others and the Bluestell group is not able to get in. So
this is why I question a forced change on the entire domain for


So now my next question is.... How do I effectively stop the newest


Thank you for your help.


        -----Original Message-----
        From: Allen, Chris [mailto:CAllen@xxxxxxxxxxxxxxxx]
        Sent: Tuesday, September 30, 2003 2:20 PM
        To: [ExchangeList]
        Subject: [exchangelist] RE: Relaying Problem question - still
fighting it!

        I was in the exact same boat. This is what we did to resolve it:


        In Exchange System Manager ->Administrative Groups->site
name->Servers->server name->Protocols->SMTP->Default Smtp Virtual Server
properties, select the Access tab, then click the relay button. In the
Relay Restrictions window, we allowed "All except the list below" and
added the firewall's internal IP as our firewall NATs all traffic
including SMTP making all inbound email to appear to be coming from the
firewall IP. What this does for us is lets our internal users relay
since we have some apps that must be able to, but at the same time,
stops all outbound traffic from relaying. This may differ for you.
Chances are, you will need to select "Only the list below" and put in
your internal network range. 


        Now, the important part, Uncheck the "Allow all computers which
successfully authenticate to relay, regardless of the list above." What
this will do is confine relaying to the internal IPs, No longer will an
external user be able to relay using an authenticated user's


        We were having issues with a spam gang out of the Chongqing
province of china. They brute force attacked our network in an attempt
to find valid user-name/passwords and then, when found, started relaying
through us regardless of our IP restrictions.  Unchecking the box put a
stop to that. It is still a good idea to reset passwords though as you
really don't know which accounts have been compromised. Yeah its an
inconvenience, but not as much as some malicious entity using your
network to wreak havoc. 


        Is the spam all originating from bluestellnn@xxxxxxxxxx where is some random, yet valid domain (ie and the nn is
an enumeration? If so, it is the same gang and you might want to add
their ip range to a deny rule in your firewall. It is as follows:



        After doing these steps, the spam has disappeared from my


        If this works for you, we might want to see if we can get
Microsoft to document this in their knowledge base. 


        Chris Allen

        Systems Administrator

        Metron North America


        -----Original Message-----
        From: KEN MORRIS [mailto:KMORRIS@xxxxxxx] 
        Sent: Tuesday, September 30, 2003 1:32 PM
        To: [ExchangeList]
        Subject: [exchangelist] Relaying Problem question - still
fighting it!




        Our server has been compromised by an outside session using an
internal name/password, and our E2K server queues keep on filling up. I
have had up to 400 queues created over night and some of the queues can
have well over 600 messages each waiting to be sent (I have frozen most
of my queues as a precaution). These relays are being set up after we
are closed. 


        I am curious to see if anyone can answer the question of who
would have the rights to create a remote session to relay? Does it have
to be an admin account or can it be a standard user? 

        I have eliminated the Fire Wall by placing it on the
restrictions for the SMTP. and have unchecked the allow all to relay. So
I am stumped as to how they are still being able to set up the relaying.
My next plan is a forced network wide password change, after that......
I have to come up with a "Plan C". 


        I am having the problem of trying to convince the powers that
be, that all user accounts need to have their passwords changed in order
to eliminate this hack. I am also recommending that our Domain Admin
accounts be made into guest accounts and new Domain Admin accounts be
created. Does anyone have any other suggestions and or reading that I
could do. So far I have found very little on this type of attack.


        Thanks for your help!




List Archives:
Exchange Newsletters:
Exchange FAQ:
Other Internet Software Marketing Sites:
Leading Network Software Directory:
No.1 ISA Server Resource Site:
Windows Security Resource Site:
Network Security Library:
Windows 2000/NT Fax Solutions:
You are currently subscribed to this Discussion List as:
To unsubscribe send a blank email to

Other related posts: