CyberianPrime
asked on
Exchange 5.5 outbound messages queue overload
Hi,
My client is running Exchange 5.5 on NT service pack 6a. I just received complaints that people are unable to send outgoing email - in the network is fine, but ougoing doesn't go. So I looked in the IMS outgoing delivery queue and noticed THOUSANDS of awaiting outgoing messages. However, these messages do not originate from any known internal user. Lots of them have this domain "seed.net.tw" and are going to a host I've never seen before. Lots of jarbled characters and actually some asian looking characters. Something looks fishy here.
This screams "spam" to me, but I don't know what to do to stop these outbound mails. I think this is the reason for the users being unable to send mail outside the network.
Last thursday I opened port 25 on the router as I'm about to make some changes to Exchange and how mail is delivered. Could that have triggered an onslaught of this spam? Has someone hacked/hijacked the exchange server?
I have read about some spam/DoS attack called Bluestell that many others have had problems with. It seems that the symptoms are exactly like mine, but I haven't noticed "bluestell" anywhere. Then again, I have not looked hard. I've been trying to clear the queue, but it seems to choke things up.
Any ideas as to how to remedy this?
My client is running Exchange 5.5 on NT service pack 6a. I just received complaints that people are unable to send outgoing email - in the network is fine, but ougoing doesn't go. So I looked in the IMS outgoing delivery queue and noticed THOUSANDS of awaiting outgoing messages. However, these messages do not originate from any known internal user. Lots of them have this domain "seed.net.tw" and are going to a host I've never seen before. Lots of jarbled characters and actually some asian looking characters. Something looks fishy here.
This screams "spam" to me, but I don't know what to do to stop these outbound mails. I think this is the reason for the users being unable to send mail outside the network.
Last thursday I opened port 25 on the router as I'm about to make some changes to Exchange and how mail is delivered. Could that have triggered an onslaught of this spam? Has someone hacked/hijacked the exchange server?
I have read about some spam/DoS attack called Bluestell that many others have had problems with. It seems that the symptoms are exactly like mine, but I haven't noticed "bluestell" anywhere. Then again, I have not looked hard. I've been trying to clear the queue, but it seems to choke things up.
Any ideas as to how to remedy this?
ASKER
I don't beleive I am. Where would I check for that in Exchange 5.5?
Is it possible that there is someone logging into the server and being authenticated to start relaying spam? Perhaps I should change the admin password?
Is it possible that there is someone logging into the server and being authenticated to start relaying spam? Perhaps I should change the admin password?
Give us your email domain and server IP and we'll check. It could be a harvest attack. That's a spammer trying to gather your addresses by sending tons of email to random addresses.
Here is an article with instructions on securing your relay:
XCON: How to Prevent Mail Relay in Exchange Server 5.5 SP1 or Later
http://support.microsoft.com/default.aspx?scid=kb;en-us;315687
OneHump
Here is an article with instructions on securing your relay:
XCON: How to Prevent Mail Relay in Exchange Server 5.5 SP1 or Later
http://support.microsoft.com/default.aspx?scid=kb;en-us;315687
OneHump
ASKER
How can you tell from my domain and IP if it's a harvest attack? Don't you need to see the guts of Exchange and event logs for that?
Domain: JBBBS.ORG
IP: 65.96.109.53
Step 3 in the Microsoft doc you linked says this: Select Reroute incoming SMTP mail, and then add all inbound mail domains. (This setting is required for POP3/IMAP4 support.) Would all inbound mail domains be their domain, JBBBS.ORG?
FYI - I have turned off Port 25 on the router as we currently use Internet Mailbridge to retreive POP3 email from our mail hosting provider - then redistributes to Exchange accounts. I opened port 25 briefly as i stated above and I believe that is the cause of this.
Domain: JBBBS.ORG
IP: 65.96.109.53
Step 3 in the Microsoft doc you linked says this: Select Reroute incoming SMTP mail, and then add all inbound mail domains. (This setting is required for POP3/IMAP4 support.) Would all inbound mail domains be their domain, JBBBS.ORG?
FYI - I have turned off Port 25 on the router as we currently use Internet Mailbridge to retreive POP3 email from our mail hosting provider - then redistributes to Exchange accounts. I opened port 25 briefly as i stated above and I believe that is the cause of this.
I can't tell for your domain/IP if it's a harvest attack. It's just a common problem with similar symptoms.
Since you blocked port 25, I can't connect and therefore cannot relay. This means your relay is closed for now. You can use this URL to test on your own when you open that port back up:
http://www.abuse.net/relay.html
In the routing tab, you want to specify routes there for every domain you want to relay for. For domains that Exchange is the final destination for, you will route "Inbound". For others, you will specify the appropriate remote MTA. What you need to be careful of there is the routing restrictions part. You don't want internal hosts email to remote domains to bounce with "relaying denied". Be sure to test test test.
I checked your domain in dnsreport.com. It looks good from an email perspective.
http://www.dnsreport.com/tools/dnsreport.ch?domain=jbbbs.org.
OneHump
Since you blocked port 25, I can't connect and therefore cannot relay. This means your relay is closed for now. You can use this URL to test on your own when you open that port back up:
http://www.abuse.net/relay.html
In the routing tab, you want to specify routes there for every domain you want to relay for. For domains that Exchange is the final destination for, you will route "Inbound". For others, you will specify the appropriate remote MTA. What you need to be careful of there is the routing restrictions part. You don't want internal hosts email to remote domains to bounce with "relaying denied". Be sure to test test test.
I checked your domain in dnsreport.com. It looks good from an email perspective.
http://www.dnsreport.com/tools/dnsreport.ch?domain=jbbbs.org.
OneHump
ASKER
Since Port 25 is closed, I assume the spam/overload in the outbound queue should stop once i manage to clear it?
I will eventually open it back up once we get rid of Internet Mailbridge. However, I am very unfamiliar with relaying and Exchange. Shouldn't relaying be turned off completely? Is it necessary to have relaying activated if I just want it to allow inbound mail for all "jbbbs.org" users? How would I set Exchange to filter out this outgoing spam crud that is clogging the queue up once I open Port 25 again? Please spell it out as I'm a newbie at relaying and the guts of Exchange.
Many thanks.
I will eventually open it back up once we get rid of Internet Mailbridge. However, I am very unfamiliar with relaying and Exchange. Shouldn't relaying be turned off completely? Is it necessary to have relaying activated if I just want it to allow inbound mail for all "jbbbs.org" users? How would I set Exchange to filter out this outgoing spam crud that is clogging the queue up once I open Port 25 again? Please spell it out as I'm a newbie at relaying and the guts of Exchange.
Many thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Also, enforce a periodic password changing policy with some kind of complexity requirement. Sometimes the attackers might get a hold of one of your users' ID and password and can therefore start to relay after they "authenticated".
- Info
- Info
ASKER
Thanks guys. I appreciate the help. I'll have to do some more reading from here once we open up port 25 again. Now I just have to figure out how to clear the oubound queue of it's 10,000 spam messages. :)
You could NDR them all from the queue if you want. You could also set your retry intervals really low so they get dealt with faster and just let Exchange clear them out.
OneHump
OneHump
ASKER
Not sure what you mean by NDR them, but I'm going to try the steps listed in this kb article to clear the queue:
http://support.microsoft.com/?kbid=324059
http://support.microsoft.com/?kbid=324059
That's a good article, but it won't result in a returned message for legitimate email. By NDR them, you go into the queue in Exchange Administrator and delete them en masse. It will ask you if you want to send a non-delivery report. You say yes. This will allow legitimate senders to know their email didnt arrive.
If you don't care and just want to be done with this, follow that article; it's good.
OneHump
If you don't care and just want to be done with this, follow that article; it's good.
OneHump
ASKER
I will try that. When I attempted this the other day via pcAnywhere/VPN, something froze or got clogged up. Now the server is down completely. My client's office is in a Jewish Community Center, so it has been and will be closed 'till Thurs AM. So, I'm assuming the server just froze up and puked. I'll have to hard reboot it on Thurs and try visitng that queue again.
Thanks for the help.
Thanks for the help.
Maybe the server is observing passover. :)
ASKER
LOL. A Jewish server.
CyberianPrime I seem to be having a very similiar problem and was wondering what you found to be the cause of your problem.
Thanks,
Ryan
Thanks,
Ryan
ASKER
Ryan,
You won't like this explanation. The server actually crashed soon after, so I just scrapped everything and installed W2K. Best move ever.
However, I would read the messages from OneHump carefully - including the links. He had some great ideas which worked until things went to hell.
You won't like this explanation. The server actually crashed soon after, so I just scrapped everything and installed W2K. Best move ever.
However, I would read the messages from OneHump carefully - including the links. He had some great ideas which worked until things went to hell.
- Info