RELAY?? But I fixed it already!..now what?

Hey all,

On my Exchange 5.5 I have setup the routing, as well as only except from authenticated sources.
Running McAfee GroupShield5.

yet .. currently the Queues is full with like 400-800 e-mails spinning through it constantly.
Destination is random, origin is "bluestell__@_______.___"
The underscores are random characters.
right after the bluestell, there are two characters that seem to follow the incremental rule with the alphabet.
starts out as "aa" and goes up to "zz" then restarts.
The domain after the @ seems to vary from e-mail to e-mail.
Mostly common domains, such as hotmail, yahoo, att.net..etc.

The headers seem to be missing, I can't figure out what IP or server it is coming from. Simply no header contents.

Anybody have any ideas? My usual daily 1500 e-mail traffic just went over last two days to 9000+ emails.

I just turned off notifications, and disabled outbound responses to reduce the e-mail count and processes...but I'm looking for a way to make sure this person can't connect to my server. Anybody have a similar case before?

Thanks,
-Peter

I have the exact same problem; running Norton on the server.
Ran an online scan from Trend; no virus.
Disconnected the server from the network, flush the queue, restart the IMC; Outbound queue still fills.
We're also seeing that the orignator is <>, along with bluestell...
Set the server to only accept Inbound; queue slowly fills with bluestell, but not <>. (BTW: Disconnected, set to accept Inbound & Outbound, queue fills with both, so it's not an external connection).

If anyone has ANY info on this, please help us. This is the most bizarre thing I've ever seen

We are receiving the same types of emails. Today there were 2,500 emails to send out in the queue. We have employees that need to POP their email and send from home so I have to have the "host and users that authenticate" checked otherwise they can't send emails. I also have "hosts and users with these IP addresses" checked but the table is empty (that's supposed to prevent relaying). The emails just keep coming into the queue. Any help for both of us would be greatly appreciated.

I have the same exact reasons why I can't close all connections to the outside. People use IMAP and POP.
I also have the <> empty origination issue on hand as well.

Any ideas on this bluestell??? Does anyone have any track of its origin? I'm guessing it must have an originating network block.. or IP address that we could block.

Regards,
-Peter

HELP>>>... it just hit for yesterday 26thousand e-mails getting transferred. Anybody know of a free snoffer or something???

26018 e-mails in one day is a bit too much! HELP!

-Peter

Check your NT accounts, especially Guest. I broke down and called MS on this and they said that is the most logical solution. On the network causing me problems, Guest was enabled (I know I didn't enable it). Disabled that, disabled all dormant accounts, removed and re-added the IMC and low and behold, all was clear. I'm giving it a few hours before I give the final cheer, but I'm pretty confident that was it.

I just checked... no guest account.
Also it doesn't seem to show a logon account creating the traffic. Is there a patch?
-p

With regard to the users popping their mail........The reason that we needed the "hosts and clients that successfully authenticate" ticked was so that users could send mail as well as receive it (or so I thought). The more I thought about it, the more I thought this was wrong. So I contacted my users' ISP. The users should be sending SMTP messages via their SMTP server, not our exchange box. With this particular ISP, that has to be setup so they put in a ticket for that. Anyway, what I found when I unticked the "hosts and clients that successfully authenticate" but left ticked the "hosts and clients with these IP addresses", I would no longer get the SPAM messages. My problem was two fold, I needed my users to be able to send SMTP messages. When I gave them that ability, I was getting SPAM messages as well. Now that I've figured out how they can send mail, I can untick the "hosts and clients that successfully authenticate" and stop the SPAM from coming in. Another note, I did have a guest account activated which I has since disabled. The SPAM is still coming in but not near as much as it was before disabling the guest account.

Thanks to all for the assistance and "sounding boards".

Well, that is a nice solution... but what if the users don't have any alternate SMTP options?

My scenario has become worse...now I'm seeing all random from outside addresses sending e-mails to outside random addresses.

It looks pretty much like a relay to me... but relay test websites, showed it being okay. Telnet tests showed it being okay and safe.
The only change lately, has been an upgrade of McAfee GroupShield4.x to GroupShield5.x
The new GroupShield blocks by subject line nicely.. but this relay/spaming is totally random, and I can't even lock on a sender's IP address, since the headers are completely missing. The most I see out of it, is notifications of failed outbound e-mails coming to the Admin box, with attachments.. that have no headers saved.

Anybody have any ideas? Perhaps run me through what to check for relaying?

I have the first two boxes checked in routing.
Authentication adn specify by IP. Both essential to my clients. Where else can e-mails come through???

This is a bit annoying.. because I go in to the que.. and see over 6000 e-mails in there.. I select all.. delete them.. and now I have 8000 e-mails.. new ones! to delete.

Would Exchange 2000 or.. Exchange 2003 solve this issue perhaps?

HELP!
thx
-peter

I am having the same issues.  I have over 2000 inbound and outbound message failures in my que, I kind of think that the relay is on for some odd reason, however, I don't know how to fix it.  

We have the exact same problem. Our Configuration is Win NT sp6a with MS Exchange 5.5 SP 4.
From 10 or maybe 11 of september, the mail server - That is Also Web and Proxy server And PDC - started to have 20000 mails in the queue each day. It seems like there is a proccess that i can't find that sends those mail to bluestell__@_______.__.All Scans for virus where clean .I Think of that because i tried to take the computer out of the LAN and cleal twice the queue but the problem was still there. All the settings in order to ensure open relay attacks are already done and tested.
I Think that maybe a virus or a hacker did that because i see your messages concerning the same problem all started after 11/09/2003.. If anybody have any idear, it will be helpful..

Thanks in Advance..

I’m having the same problem.  I just found this on the Microshaft site:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms02-011.asp

This was apparently not well publicized because Microshaft considers the severity to be “low”. I know this wasn’t installed on my server, so I’m giving it a shot.  

Hope this helps.  


Joe Klobedanz
Network Administrator
Oxford Instruments
600 Milik St.
Carteret NJ 07008

Phone: (732) 850-9387
Fax:      (732) 541-1845
Joe.klobedanz@ost.oxinst.com

http://www.Oxford-instruments.com

I've got the same issue.  I've tried the above patch with no luck.  My problem started September 3rd.  Server has not crashed, just gets bombed with the messages stuck in Outbound Queue.  Scanned with Trend online and Inoculan locally and nothing found.  My firewall log shows lots of traffic on Port 25 but it shows it as FTP instead of SMTP.  Also shows the inbound traffic as being received with a valid address.  Tried disabling all inactive accounts and restarting the IMC.  Made all users shut off PCs at night to see if traffic subsided but that didn't work either.  

Thanks,

Mapman04

Well, I downloaded that patch, took the server offline.
Deleted all items showing up in the que...and I guess there were more somewhere on the server still saved for future delivery that showed up after deleting everything from all four areas of the QUEUES.
So I had to select all items, delete, refresh... and repeat this like 15 times, until nothing else showed up anymore.
waited about 10-15 minutes.. and a couple more originating from <> showed up.

Weird.. server is physicly disconnected. Where did these come from??

So after clearing those out, I applied the patch, restarted the server, and reattached it to the network(plugged the network cable back in)
.. waited..waited..
and the bluestall stuff started showing up again.

So.. the patch was worthless as far as I could tell unfortunately. Has anyone started an issue ticket with Mocrosoft, or any anti-virus or anti-spam company yet?

My daily e-mails are up from 1500/day to 65000/day it is starting to effect the delivery times of proper e-mails.

thanks,
-Peter

FYI - I'm seeing this issue on an Exchange 2000 SP2 environment at a client site right now.  Still trying to dig into where exactly it's coming from.  Thus far I've done the following:

NetMon dump on Exchange filtering for TCP/25 traffic.  Although I noticed a lot of attempts going out from Exchange to the internet containing BlueStell addresses, I didn't see one occurance of an inbound SMTP connection that contained the BlueStell addressing info.  This leads me to believe that the email is coming from inside the network.  Perhaps a virus/worm.

Unfortunately, this doesn't leave me with many options for determining where the traffic is coming from because everyone here uses Outlook MAPI therefore all of the mail data is going to be tunneled in RPC which makes it more difficult to analyze the sniffer dumps.  I'm going to keep plugging away at it, but thought it would be helpful to pass along this info.  If you've found a solution, please post it to the thread so everyone can benefit.

Thanks.

Shawn

This bluestell is quite a hard worker!
I use Sybari's Antigen for Exchange with Spam Manager. When I first noticed bluestell in my outbound queue (9/15) I created a spam filter to block any inbound emails whose email address includes bluestell. Since then I catch an email every 5 seconds for about an hour at a clip, then a pause, then another hour of slamming. We need to catch this fool. I'll be analysing my smtp traffic further in hopes of finding the source.

Gene

We have been getting dumped with the same thing. It appears to be coming in internally because we have blocked smtp incoming traffic. The only way I get it to stop spamming other people is to block the range of IP's it sends to on the outgoing. Any help would be appreciate.

Turn your Diagnostic logging to Maximum for MSExchangeIMC -> SMTP Interface Events.

Look at all SMTP Interface Events in the Event logs.  Look for both 2010 Events (successful login) for accounts that SHOULD NOT BE AUTHENTICATING as well as 4183 Events (failed login).  It appears that what ever this is (virus/hacker/spammer) is using weak password attacks to authenticate against servers.  

The Guest account is only one of the accounts that are targeted.  Local Admin accounts are also being targeted.  There maybe other accounts as well.  

Looking at 4183 events will tell you which accounts you need to make sure are either disabled or have strong passwords.  
The 2010 events will show which accounts are being currently used to relay mail.

Thanks for the tip james3838.  I did just as you suggested and was able to find the account it was using.  I disabled it and the messages have appeared to stop!

Regards,

mapman04

Thanks for the tips guys/gals...

  I have an IP address linked to some suspecious failed logins (now that I've disabled the weak account). Not sure I should post it here, but it begins 211.158. anyone else? Perhaps this clown can be tracked down?

I am using Exchange 2003, and I can find the Diagnostic Logging screen, but the options are different. Does anyone know which option I need to set to maximum?

James3838 is right. It is a compromise on weak local account passwords. Change your local Administrator password, diasable guest, etc to fix the problem!

Glidman

James3838, your idea works on an Exchange 5.5 system, but do you know the MSExchangeIMC equivilant in Exchange 2000?

I think I found one of the companies responsible, they should be blacklisted:

BLUE STEEL:
Phone: 85 230158569
Fax: 85 230158571

If anyone has time, do your best to destroy them.

And a note, you have to be at SP4 on Exchange 5.5 to apply the patch mentioned above.  From what I've read about this though, it isn't supposed to help much.

"Turn your Diagnostic logging to Maximum for MSExchangeIMC -> SMTP Interface Events."

OK, I give. How do I do this please? I'm new to administering Exchange and all help is appreciated!

Thanks!

Corie

pmarsala,

I've determined the equivilant for Exchange 2000 to be MSExchangeTransport then choose SMTP.  It might be the same for 2003.  Give it a try.

Also, will it mess stuff up if I remove the group 'GUESTS'?
I have already disabled the user guest account, but the group includes the IUSR_servername and IWAM_servername accounts.
Is this necessary, or just a hole that hackers can exploit?

Thanks!

Corie

Exact steps for Exchange 5.5:

Start->Programs->Microsoft Exchange->Microsoft Exchange Administrator
Connect to your Org
Find your internet facing server
Select its properties (either select it and type <alt><enter> or hit the property button)
Select the Diagnostics Logging Tab
Select MSExchangeIMC
Select SMTP Interface Events
Change Logging Level to Maximum
Hit Apply
Wait for new messages to come in (it will only log starting from when you increased logging)
Start->Programs->Administrative Tools->Event Viewer
Select Application Log
Select View menu item
Select Filter
Change Event Source to MSExchangeIMC
Hit OK
Go through logs looking for suspicious 2010's and 4183's.


Exact steps for Exchange 2000/2003:
Start->Programs->Microsoft Exchange->System Manager
Find your internet facing server
Select its properties (either select it and type <alt><enter> or hit the property button)
Select the Diagnostics Logging Tab
Select MSExchangeTransport
(Exchange 2000) Select SMTP Protocol
(Exchange 2003) Select Authentication
Change logging to maximum
Hit Apply
Start->Programs->Administrative Tools->Event Viewer
Select Application Log
Select View menu item
Select Filter
Change source event to MSExchangeTransport
Look for Event ID's 1708 for suspicious successful logons.

Hi James3838, I have been following this thread. I tried looking for the user authentication you said. In the 2010 events, it says

"connection from <ip address> successfully authenticated (AUTH LOGIN) as \administrator."

However, we do not have any user account with the name adminsitrator in our domain!!

We are using Windows NT 4.0 Server. For your info, Our exchange server is the member server in the DOMAIN.

How can I know the exact login procedure used by the spammer?

Regards
KBADMIN

KBADMIN -

\administrator is the local machine administrator

Unfortunately I don't have any NT4 boxes around anymore, so I can give you details on how to change the password/disable the local administrator account, but look on the box itself for a local Administrator account.

Hopefully someone else can post exact details.

Hi Again..

After I tracked Messages Via The Event Viewer, I Saw that There are no succesfull authenticatoin events (2010) but only some 4183( Logon Failure ). The Ip Addresses From Which The 4183 Events Come are :

219.153.150.231,
219.153.153.201,
218.70.9.109,
218.70.10.129,
211.158.77.11,
218.70.8.5,
218.70.10.97,
219.153.152.44 and
211.158.76.167 so far.

The Account that is trying to authenticate and it seems that it can't is \webmaster.
In the Server, that as i mentioned in my previous mail is Primary Domain Controller,Proxy,Web and Mail server the webmaster account existed 2-3 years ago but i have deleted it because we did not longer needed it.So this is the reason that the spammer could not authenticate.

The Problem still Continues.Today, i found 45000 mails in the Administrator inbox. Those mails are reports for those undeliverable mails sent by the spammer.For The moment , i have stopped the mail service trying to clear the queues and the administrator mailbox.I have applied the patch mentioned above by jklobedanz
( http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms02-011.asp )
 but the problem still persists. I have Also Already applied another patch delivered by microsoft on 10/09/2003 ( http://www.microsoft.com/technet/treeview/?url=/technet/security/bulletin/MS03-039.asp )
but it did not did anything.
Anyway , this is my current status. I will continue to dig in the system trying to find something. If I find anything, you will be the first people to know.

If anyone have any idears, please share it with us. It will be very helpfull.  

Thanks in Advance..

SOLUTION FOUND !!!!!!!!!!!!!!!!!!!!!!

Dear All..

I Have Find A Temporary Solytion.

From The Routing Restriction Page On The Internet Mail Service Properties,( Internet Mail Service --> Properties -->Routing --> Routing Restrictions )Do The Following :

Last fields In the screen are :
Specify The Hosts And Clients That can NEVER Route Mail.
Add in this section The following Ip's :

219.153.150.231,
219.153.153.201,
218.70.9.109,
218.70.10.129,
211.158.77.11,
218.70.8.5,
218.70.10.97,
219.153.152.44 and
211.158.76.167 with subnet mask 255.255.255.0 to all.


After You Do That, Restart The IMService.
The Administrator Account Will Again Start Receiving Mails but not outbound, only inbound mails that after a few minutes will end.Clear the administrator mailbox for the junk mail and you are ok. The Outbound Queue Will stay empty with no problem.

If The user change ip address and the new one is not listed, then you must just add it to the NEVER ROUTE Mail Mask.

This Is only A temporary solution, worked fine to me for the moment.
I Hope that someone finds a better permanent solution.

Hope It Works for you all..

Hi all i just saw this thread. I had the same problem a couple of months ago.

check out my posts for resolution

Thread10-602113 must say that for about a week after i solve the problem i still had many failed authenticated attempts, but as the days passed the attempts slowly stopped

I tried looking for events 2010 and 4183 and none of them show up. Do I not have something configured to display these events?

Hi..All,

I hv been facing this peoblem since last one week...frequency of incoming mails are very high with sender name bluestell*@*.com/net.

I hv checked my system guest account..its disabled..is there any other way out...Pls.suggest..

Thanks in Advance..

Best Regards

All.

Solved issue at the client site I was at.  James3838 was right on with the diagnostic assistance.  In our particular scenario it was the local admin account that was being used.  However, I'd like to make everyone aware that the local admin account on the Exchange server in my client's environment had a very complex password.  I know for a fact because I had run the Baseline Security Analyzer against it a few weeks back and it never complained about a weak or blank password.  Plus the net admin there told me it was a complex password.  Which brings me to my next thing, how did someone get that password/set that password.  The only thing I can think of is there was a code exploit published around Sept 11, 2003 for the MS03-039 security bulletin (read info at http://www.microsoft.com/security/security_bulletins/ms03-039.asp - FYI this is the second RPC vulnerability/blaster patch).  Anyway, the exploit is capable of creating a local admin account.  Since the use of the Exchange server as a SPAM relay was using local Administrator in this case, I have to wonder if the machine was compromised with something due to the MS03-039 patch not being on the server yet.  (I know, I know - it should have been on there already but I'm only at this client site once a week so I have limited time to enact server changes, especially ones that require server reboots).  Anyway, we're applying MS03-039's patch now, but I STRONGLY urge anyone out there who is experiencing the bluestell issue to ensure they've patched ALL vulnerable servers AND workstations with MS03-039 as well as renamed all Admin/Guest accounts and reset passwords.  Keep in mind that if Exchange is set to allow authenticated users to relay then ANY workstation or server on your network is capable of relaying this SPAM through your Exchange server.  Good luck all.  FYI - the patch requires a reboot to be effective, don't forget!

Shawn

I fixed the problem and here is what I did.

First I did what James3838 suggested withthe SMTP connection and the event view.  I didn't get any events to pop up....so..

Through Group Policy I implemented the Password Complexity Requirement on all users.  Then forced each user to change the their password.  

After about 20 minutes, the emails stoped.  

When I walked in this morning I was receiving and sending about 4000 messages every minute and had 1096 connections in the queue.  

After I performed the Password change.  It has been running for 4 hours and I have only hav about 10 connnection in the queue and my network speed has increases 10X.  Even though I couldn't find the exact culprit changing the passwords fixed the issue.

Same here, when I checked the event log after enabling SMTP logging, I found that it was the CFO's account that was getting hit. I made him change the password on his account and so far, no more attacks.
I also added the list of IP's to the 'never route' table, and added the fix from MS.

Thanks again!

Corie

Hey All,

THANKS TO EVERYONE, it finally stopped!

Steps I took:

1) installed all recent patches
2) Maximized the logging, and looked, and found couple of odd user IDs.
3) deleted all unnecessary user login IDs
4) changed Administrator password (letters + numbers)

I also had to change the password for a few services in the services control panel, that use Administrator as the logon.
Services include: SQL server, Exchange server and each of its services, McAfee GroupShield and its services(like 5 different services)

Did this around 1am, so it wouldn't disrupt anyone.
Rebooted the boxes, forced a Domain Syncronization.

now it is 11am, and last night the queue had like 2000 e-mails in it.. now it is 4.

once again THANKS TO EVERYONE!
-Peter

Here is what the the culprit looked like for me.

Come to find out it was an administrator account on a TRUSTED domain.  Then perhaps it should be TRUSTED if they put their administrator password as "password".  What were they thinking.


--------------------------


Event Type:    Information
Event Source:    MSExchangeTransport
Event Category:    SMTP Protocol
Event ID:    1708
Date:        9/18/2003
Time:        9:37:24 AM
User:        N/A
Computer:    <SERVER>
Description:
SMTP Authentication was performed successfully with client "exceeded".  The authentication method was "LOGIN" and the username was "<DOMAIN>\<USER>".

The Bluestell messages are authenticated spam. Someone has compromised your systems and have one of your usernames and passwords. That is how they are getting in. In Exchange 5.5, if you go to Exchange Admin - Internet Mail Service - Routing tab - Make sure it is set to "Reroute" - then go to Routing restrictions button. Unselect the Hosts and Clients that successfully authenticate, then OK on out and restart the IMS service. This should stop the authenticated spam. This will be a problem if you have pop3 users however. They would have to have static ip's and be added in the second box of the Routing restrictions.

This is from one who knows.....

I have done extensive testing today on this problem and even when I've disconnected the server from the network, the IN and OUT directories under the IMC folder still repopulate.  It only does this when IMS is running.  Stopping IMS prevents this from reocurring.

By changing the local passwords for admin and IUSR accounts, this stopped the repopulation of these directories.  I still am wary of the presence of a malicious app on the server, however.

I've also noticed outside attacks as well.

I too have been hit by this freak.... It started with code loaded in the Explorer Bar found by searching the registry for bluestell.. Apparently this is a chat/IM link that is corrupted from one of my users on a YAHOO I/M personal page crap install, very much a security risk since it opens up a pipe thru your firewalls. I suggest you limit this type of activity to none for your users. I pulled the machine off the network but damage was already done. This link is coming from CHINANET Chongging province network(www.senderbase.org/search -use the found IP to track) and I have blocked about 50 or more addresses but to no avail since these people have over 9,000 IP's to work with. I used a program called Active Ports from www.downloads.com to monitor Port 25 SMTP and capture the IP Addresses being used. I also followed James's advice on the monitoring and it works to find your weakness. Good Luck and I hope MicroCramp figures out a way to bolster their software to give us a chance in the future.

Matt

Hi Everyone,

I followed James instructions and found that the attack had used a TEST account that i had created a while back. Since the account was no longer needed i deleted it and that stopped submission of new messages into my queue. This account did have a strong password.

The problem that i had however was there was still a LOAD of messages in the outbound waiting to be delivered queue. I had sorted by orginator and deleted 10,000 at a time. Which certainly took it's toll on our mailsserver performance. Deleting 10000 messages from the queue would take about 15-30 minutes each time.

you where all a INVALUABLE resource on this problem.. Thanks everyone.

If this indeed a Virus/Worm and your topology DOES NOT require end users to submit to your internet facing machines via SMTP, then I would highly recommend turning off authenticated relay!

For those that have been hit by this (I have not), do you see lots of failed logon attempts?  I would expect to see the log flooded with them if it was a dictionary attack.  If its a virus or worm though, they may have another way to obtain/modify the password.

More information from those affected would be appreciated.

Have'nt been exactly flooded with them. However i am getting roughly 40 failed authentication attempts per hour.

Each failed login (4183) is trying to use the \test account. Never any other account.

There are no sucsuful logins since i deleted the test account. (2010) I did not have maximum loggin of IMC on during sucsesful authentications.

The IP address the 4183's are coming from are
219.153.153.254
211.158.76.227
211.158.89.77
211.158.51.203 (the vast majority of them are from this address)
218.70.136.247
218.70.137.148


hope this helps at all

I betcha this is the w32.swen.a@mm.html
See w32.swen.a@mm.html" TARGET="_new">http://www.sarc.com/avcenter/venc/data/w32.swen.a@mm.html for details.

Check out step 12 for why I think its this virus.  It is prompting infected users for authentication information.

James3838,

I'm not sure I buy into W32.swen as being the source of the authentication breach.  Remember that most people have been affected via local user accounts such as Guest, Test, Administrator, etc. on the local machine.  There shouldn't be any users in receipt of email for those local user accounts and none of the users would have access to those passwords.  I still question whether or not we are seeing a rootkit created that takes advantage of the MS03-039 exploit.  Sample code was already published on a Chinese website on Tuesday (funny that's where most of the IPs are coming from too).  I don't know for sure as this is all speculation, but it seems odd to me that the sample code for the MS03-039 exploit allows the attacker to create a local admin account and set it's password.  It just seems like too much of a coincidence.  Although it could just be that.  Anyone else have thoughts on this?

Sbass2 - That is quite possible.  But I've also seen people reporting non-guest/admin accounts being compromised that had strong passwords.  Since W32.swen asks for this information, its the best target at this point, especially for the non-generic account compromise scenarios.

Its also possible that W32.swen has code to compromise MS03-039 as well, since it would be easier to exploit inside a firewall as a result of user infection.  BTW - this is not limited to MS MTA's.  If you browse through other MTA message boards, you will see this problem being reported there as well, also indicating the W32.swen connection.

In any case what ever is causing this is making me a lot more cautious and watchful of my machines, and end users.  A friendly reminder to end users from the IT department about how upset we get when we are forced to work overtime because of end user virus infections has already been sent.  We are also contemplating sacraficing a virgin employee as an example just to empasize our point.

On my NT4/Exchange5.5 it must have been Administrator or Test account. Or both.
As soon as I deleted the test and changed the password on Administrator, all spaming slowed.. things in the que had to be deleted for about an hour more since e-mails must have backed up in buffers or any temporary storage areas, but after that... they've been gone!

My Administrator account's password was all lower case 6 characters. The new password is twice as long with numbers and some special characters.

The test account was a more probable cause, since its password was "test". Little bit too easy.. eh?
So I deleted that.

The Guest account was disabled to begin with, so no trouble there.

My recommendation to everyone, is to look over all accounts.
Delete any unused accounts. And for all others change passwords.
Especially the Administrator account, make it a complex password, and try not to use that account often. Keep it as a backup. Also... remember, if you run FTP...everything is in clear text, and any logins' password can be snatched too easily (I've been there.. it wasn't pretty)

Latest issue.. the microsoft patch virus e-mails..too many different ones to filter'm out easily.

Any suggestions?

Thanks, -Peter

Thank you all. While in my case (Exchange 2000 behind PIX Firewall) I could not find the failed logons, resetting everyone's password seems to have at least slowed the bluestell down. I also blocked all incoming traffic to port 25 and the mail still showed up. So it seems to be internal.

I also placed a delete rule in our Trend Scanmail to delete anything with "bluestel*" in the from field. This is the first rule and at least reduced the load on the server for incoming mail and prevented about 60,000 messages per hour ending up in the queues.

I worked on this all night and the early reports from the office are that the mail server is up, there is no delay in outgoing mail, and people hate strong passwords.

Thanks to james3838 for the "step by step".

I know this is not over, but perhaps it's at least temporarily mitigated. Any thoughts on no failed logins?

Thanks, Noah

Aloha!

I have nothing useful to add, sorry, but I'd just like to say "Thanks" to everyone who has posted.  The Exchange 5.5 box I'm responsible for has "bluestell" and this seems to be the only place on the Net that is aware of the problem.  As they say, misery loves company.

Using advice posted here I found through event 2010 that someone from an outside ip addy (which changed) was authenticating as Administrator.  I still frankly find this hard to believe as the Administrator account pw was quite strong, but I made it stronger.  

This slowed substantially (still not sure completely) the flood of bluestell traffic, though I still see mail being generated with <> in the from field.  This mail is also spam.

Sorry I can't offer a definitive solution, but thanks everyone for posting!

Jim

The <> e-mails are a different issue. Those are generated more or less by Exchange server itself.
For example... some junk mail is being sent to your company zyx.com
The e-mail is sent to userxyz@xyz.com
But...you don't have a username: userxyz, nor any alias accounts.
Exchange will respond, and will send an e-mail noting, that no such e-mail account was found. These usually endup being <>(empty).  Now, when the original sender's e-mail address or mainly domain name doesn't exist, they can get stuck in the queue for a while until it times out. The reason it shows in Exchange as <>(empty) is to avoid an infinite loop. Other wise servers could pass e-mails back and forth saying.. I don't have such account.. and the other replies, I don't have such account.

This can be pretty annoying for Administrators looking at a list of <>(empty) e-mails queued up. But they will time out and that's the end of them.

If anybody finds a solution to that...let me know!
I suppose that would need to be a separate thread perhaps.

Thanks,
-Peter

James3838:

I've been hit with this problem . . . Event ID 3024 warned that the SMTP queue exceeded 25000 items and wouldn't accept any more.

Two issues.

First, I receive a lot of 4183s (over 500 4183s) but no 2010s since July 10.  Shouldn't each logon, including mine, be recorded?

Second, I disabled / changed passwords on most accounts, but I have two accounts that generate an Active Directory eror, "Windows cannot disable object useraccount because:  Insufficient access rights to perform the operation," when I try to change password or disable them.  Any clues about this?

Thanks!

In addition to investigating spurious logins and scrubbing passwords, as described above, we also installed the MS02-011 (Q289258engi386.EXE) patch as discussed in this thread by lfour and jklobedanz, but with disconcerting results.  First, we found thousands of messages in the queue.  What's worse, the event log shows tens of Event IDs 2003 (e.g., "A new TCP/IP SMTP connection has been made to host 216.127.87.1 (for skis-zveza.si).  Logfile: <none>", and some Event IDs 3010 ("An attempt to connect to host webtopmail.com failed.").  I don't really know what a 2003 is, but I have no reason to believe that this server should be connecting to _any_ other SMTP host.  Anyone familiar with this connection process?

For those that have succesful authentications of non existing domain users the problem is low security and a flaw in smtp service that allows that behaviour.

These are the accounts , the spammer was using when i had the same problem.
 
 administrator
 admin
 root
 webmaster
 www
 data
 server
 test
 abc

Try this :

1) Take the server offline IF possible if not create the above usernames in usermanager for domains and secure them with a good password. In that way you ll still have connections but they ll be failed and you wont get any more spam to relay.

2) Empty the inbound and outbound queues . Be careful not to delete legit mail.

3) Read these articles

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q310669

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms02-011.asp

and download and apply this fix

http://support.microsoft.com/default.aspx?scid=kb;en-us;304115

THE FIX IS POST SP4.

4) Change the passwords of all administrative accounts. Combine letters with numbers and symbols. Upon reboot  many services will fail to start due to the account change. Go to control panel>services > double click on every failed to start service and fill in the new password.(the most propable services to fail are exchange services, antivirus services)

5) Check one by one if possible every account to see if it s been added to other groups (admin group etc) or modified recently.

6) Delete the admin accounts previous administrators have left in the server. (If any)

7) Disable the guest account. Dont delete it.

8) Disable all the NDRs. You can do that in exchange admin>configuration>connections>Internet Mail Settings. on the upper right corner there is a button "notifications" click and uncheck all the boxes. (you choose send notifications for those non delivery reports and you have everything UNchecked below)

9) Make sure you have all the latest patches from microsoft installed (not only for exchange but for the os as well)

10)Make sure you are relay secure. And test the server with ordb.org etc.

11)Check the contents of c:\ and c:\winnt\ for suspicious folders and content. The previous admin didnt bother with updates and patches and i found lots of trojans and malicious software in the server.

12) Except from your antivirus a trojan scanner - remover would be a good idea. I used tauscan for a while.

13) (Optional) To increase my server's security i opened
exchange admin>configuration>connections>Internet Mail Settings. Went to the tab called Delivery restrictions and selected the accept messages from > list , pressed the modify button and added all my legit domain users. Applied and restarted ims. (you can put the all the usernames the spammer uses in the reject from list except administrator of course)

14) Delete the accounts you created in step 1

15) You ll propably have lots of failed authentication attempts after that but dont bother slowly they ll go away

16) If you also want to stop the connections you can ban them on your router or firewall but i wouldnt suggest that as you might cut off legit mail.

Thats all if i remember something else i ll post.

Good luck
George

Georgeks, you can't disable NDR's in exchange 5.5, the step listed in #8 will disable the notifiactions, for the events you have selected, to the mailbox listed to the left of the "Change" button. (usually the Administrator mailbox)

The most important thing you can do if your be plaqued by Bluestell attacks, is like James and others have said. Under "Routing--> Routing restrictions, remove the tick from "hosts and clients that sucsufully authenticate"

Unless you have remote clients that are legit using your exchange server to send mail.. (like laptop users on the road using exchange for SMTP)

P.S. about 4 days after disabling the comprimised account, and removing the check for hosts and clients that sucsuffuly authenticated, my 4183's have stopped. I have FINALLY cleared the queues of outbounds, and things are back to normal.

Folks, I just want to extend a sincere, heart-felt thanks to you for the help in dealing with this situation. I too was under attack and I thank God that I was able to find not only this thread, but this website.

Thank you!

Here, here!

   Thanks all! My attacks have also stopped, due to techniques applied, which I learned from this thread! Thanks again!

Joe

I was getting thousands of bluestell messages before i found this thread in a Google search. After turing on the Event logging for SMTP it was found they were coming from a User Account 'backup". Resetting the password to some gobbledy-gook one fixed it. Thanks for everyone on this forum. I am clean now and although I feel violated and a bit embarrassed (someone turned me in to SpamCop) I haven't been blocklisted.

I am glad that the European Union has declared spam illegal, but our own government has taken another tack and are working on a "no call list" like they have for telemarketers. Last week a judge declared spam to be legal, under the First Amendment, but I think the courts need to look at relay. If it is legal, what is to stop people from nailing billboards on the side of our homes to target ads to our neighbors. Personally, I think SMTP Relay should be a felony, and not protected by the First Amendment.

Wow. I don't know why I didn't check here first! I've been fighting this thing since September the 9th when the first 10000 e-mails in queue brought my 5.5 Exchange server to a halt. I finally today found that by checking the 'Clients can only submit if homed on this server' check box on the connections tab under IMS properties that this halted the slamming that I was taking. I've spent more time in the last 3 days on this server than I have in the last three years! Thanks for all the help!

Hello All,

  Thanks again for assistance fixing the bluestell issue...

   for a while I have seen messgages in the outgoing queue originating from <> I have checked the logs for allowed logons, they aren't coming from anyone listed there. Anyone know where they may be coming from?

Thanks
Joe

OK, same thing happens to me yesterday but I was able to discern the senders IP address by turning on SMTP Protocol and Interface logs.  I blocked the address 211.158.88.246, which is another CHINANET Chongging province network IP address.  There's a couple of things I've found out while researching this problem that might answer a few questions I've seen posted here.

1st:  "I've deleted all the messages in the queue and restarted the service with the machine unplugged from the network but more messages keep showing up."

This one boggled my mind too for a while but an in-depth search of the system log produced this:  

"Event ID:3038    An attempt to remove processed messages from the outbound store que has failed.  The removal will be retried later.  If the messages are not removed before the service is shut down, the mail will be resent at service startup causing duplicate mail."

The only way to avoid this is to shut down the service, go into the exchsrvr\imcdata folder and delete the contents of the "out" folder and the queue.dat file and then restart the service.  Microsoft KB324059 article details this process.  So there is no internal source or virus spamming your server....

2ND: "I've applied all the patches and my system still allows e-mail to be relayed."

Yup, tore out handfuls of hair on this one too but I kept digging and found out that this is by design and that not everything you might think is happening, is actually happening.   If someone sends and e-mail formatted like this name%otherdomain.com@yourdomain.com to your Exchange server, it will accept it and generate a NDR after failing a directory lookup.  Microsoft says this is acceptable as it does not forward the message.  Well, a great lot of help that is to us as our servers still have to process it. This is effectivly a DOS on our servers by flooding it with requests that the server will queue and attempt to process.  This is all detailed BTW in Microsoft KB304897 article (look at example six) and can be verified at http://members.iinet.net.au/~remmie/rela...;(look at the last test and then check you IMS queues)

The only true solution seems to be to go third party for a spam killing type of appliance or software as Exchange just doesn't cut the mustard.

Hope this helps!

ImWoody

This is what finally stopped the relaying in my domain:

set routing to route the domain to inbound, click on restrictions, and choose Hosts and Clients with these IP addresses, and leave the field blank. This effectively shuts the relay door. You can test by typing the following at a command prompt:

telnet servername 25

where servername is the name of your Exchange server. The Exchange server will respond with a message similar to 220 host.domain.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2650.10) ready. Then enter the following commands. The commands are case-sensitive, and the punctuation (e.g., colons, angle brackets—< >) is important, so include all the marks.

1 type
HELO me
The server will respond with 250 OK and possibly identify your IP address and your host name.

2 type
MAIL FROM: someaddress@somedomain.com
Again, the server will respond with 250 OK.

3 type  
RCPT TO: nobody@afakedomain.com
The server will respond with 550 Relaying prohibited.

Using a valid address from your GAL, enter
RCPT TO: thegaladdress@yourdomain
The IMS will reply with 250 OK when it accepts the address.

To close the session, type
QUIT


If you do not get the 550 RELAYING PROHIBITED message, you need to try again.

So this stopped the main problem, now all I have to worry about is the 529 errors that pop up every 12 seconds on the security log...

Thread10-659407 this helps!

Corie

The <> messages are typically NDR or (Non Delivery Report) messages from the Postmaster. Most often, this is what is called NDR spam which is a loophole in the RFC.

The fix in Exchange 5.5 and Exchange 2000 is a third party utility such as Praetor from cmsconnect.com or Mailsweeper. The best fix is Exchange 2003 where all this (and more) magically disappears! Exchange 2003 has RBL listing capabilities as well as the abilities to remove NDR spam.

You are absolutely right about what it is.

IMWOODY - -

"If someone sends and e-mail formatted like this name%otherdomain.com@yourdomain.com to your Exchange server, it will accept it and generate a NDR after failing a directory lookup."  You are correct!

"Microsoft says this is acceptable as it does not forward the message.  This is effectivly a DOS on our servers by flooding it with requests that the server will queue and attempt to process.  This is all detailed BTW in Microsoft KB304897 article (look at example six) and can be verified at http://members.iinet.net.au/~remmie/rela...;(look at the last test and then check you IMS queues)"

Right again, although it is not just Microsoft that says this. It is an RFC standard. The RFC requires the ability to send an NDR and you WANT this ability. Just for grins, what if I sent your company an email that would save you 10 million dollars and fumble-fingered the address? What if you didn't know I was sending it? You would never get the message and I would "assume" that you got it.

You wouldn't really know without calling or getting the NDR.

All the major spam lists only care if the message actually is relayed (not just accepted). Otherwise, EVERYONE would be on spam lists!!

--Alan

Well a friend of mine and I found a possible problem, we are still scanning the drives right now and have found two trojans so far. Netspy and executer, they scan random unassigned ports and steal passwords.

You can download the scanner from here,

http://www.softandco.com/download/Anti-T...

Make sure it's updated and run a full scan. I was running Anasil network monitor and seen random port scans coming from the IP of the Exchange server. It would only try and connect to ports that were unassigned to other services or programs.

I'm sure he'll post later to fill y'all in with more details, but from reading through the thread it seems as if nobody has run a trojan scan yet. Norton Corporate didn't pick up either one of these trojans either.

Give it a try and see if it helps, we still don't know the full results yet because the scan isn't finished, but it can't hurt to try.

If you want to try Anasil, you can get a demo copy from here,
http://www.anasil.net/

Thanks to everyone on this list for helping me find the problem with my server. Bluestell has sent 100,000 messages through my machine since September 2nd.
Here's something that might help others:

- Turn on SMTP Protocol logging to maximum.
- Wait for spammer to start using your open relay.
- Shut down IMS.
- Examine the protocol logs in \exchsrvr\imcdata\log
- Search for 'LOGIN authentication successful'
If found, you will see log entries like this:

9/11/03 6:12:54 AM : <<< AUTH LOGIN
9/11/03 6:12:54 AM : >>> 334 VXNlcm5hbWU6
9/11/03 6:12:54 AM : <<< YmFja3Vw
9/11/03 6:12:54 AM : >>> 334 UGFzc3dvcmQ6
9/11/03 6:12:54 AM : <<< ########
9/11/03 6:12:54 AM : >>> 235 LOGIN authentication successful

- Use a base-64 converter such as http://www.wc.cc.va.us/dtod/base64/ to decode the characters above, and you will see what account is being used to break into your server.

9/11/03 6:12:54 AM : >>> 334 Username:
9/11/03 6:12:54 AM : <<< backup
9/11/03 6:12:54 AM : >>> 334 Password:
9/11/03 6:12:54 AM : <<< ########
9/11/03 6:12:54 AM : >>> 235 LOGIN authentication successful

Some helpful (hopefully) information about our Blue Steel mystery person...

I visited the Blue Steel website, or at least one of them, and in the FAQ (www.grasphere.com/twt/faq.html)found the toll-free number, (888-271-1767).  Of course I called and left a message, (no, not for their product...) :) , and then I searched out that number on Google and found it on another site, (www.devineworld.com), which has the phone number 310-459-2111, so I traced that number and found the following information listed in Google.

Ruedi Devine, (310) 459-2111, 18219 Coastline Dr, Malibu, CA 90265
R Schinz, (310) 459-2111, 18219 Coastline Dr, Malibu, CA 90265

Hope this helps.

Let me know if there is anything from this...  I am sick of spam...

fINSTER (tHE rEAL oNE)

fINSTER, what does any of this have to do with a company called Blue Steel??  Don't bother those poor people!  All of the spam being talked about in this thread is using a bluestell** email address (bluestell, not bluesteel) and is coming from China.

===================

To quote Posapay,

"On my Exchange 5.5 I have setup the routing, as well as only except from authenticated sources.
Running McAfee GroupShield5.

yet .. currently the Queues is full with like 400-800 e-mails spinning through it constantly.
Destination is random, origin is "bluestell__@_______.___"
The underscores are random characters.
right after the bluestell, there are two characters that seem to follow the incremental rule with the alphabet.
starts out as "aa" and goes up to "zz" then restarts.
The domain after the @ seems to vary from e-mail to e-mail.
Mostly common domains, such as hotmail, yahoo, att.net..etc."

===================

Return-Path: <bluestellfg@hotmail.com>
Return-Path: <bluestellem@msn.com>
Return-Path: <bluestellkg@aol.com>
Return-Path: <bluestellod@msn.com>
Return-Path: <bluestelllj@earthlink.net>

Please forgive me if I'm wrong, but aren't the spam in question just a little like the ones I have listed above?  Perhaps we're getting different spam.  If so, I apologize.

If your spam, and my spam ARE from the same people, whom I like to think of as 'The Penis People', then the information I posted before should at least be considered a lead.

Roxanne, I could be WAY off base here, and I definately don't want to send the dogs after the wrong fox, so to speak.  I found this thread because of my search for the people responsible for the spam in my inbox.  I don't want to have to change my email address or email domain because of some yahoo.  (pun intended).

If our spam IS the same stuff, simply follow the trail I outlined in my first post and check it out for yourself...

BTW, I'm not even sure there is anything we can do realistically or legally with this matter anyway.  At least not from my out-of-country perspective.  My tiny home-based business can muster little.

Anyway.  Please respond and let me know if I am really this clever or not.

Thanks.

fINSTER

fINSTER and roxannes,
you both have made a point, and while you both have your argument for it, these won't solve the issue with Exchange.

The patches are great.. the password changing is nice fix.
But I'm assuming, if one "person/company/hacker" was able to do it, then can others also do the same?

Can easy passwords be compromised in the future?
What can be done against it, and how are these passwords compromised?

I don't care if people like bluestell are out there or not, as long as the servers have proper protection, their existence won't even be known.

So how does a password compromise start?
What type of software is used for that, and how?
Any particular ports in use that admins should watch and log?


BTW...I wouldn't mind smacking the person that spamed my server...but unfortunately that won't solve the server's vulnerability.
Also... THANKS TO EVERYONE FOR YOUR HELP!
-Peter

hi, i did all what they said here to solve the problem described in the 2 first sections.
1/took the server offline
2/monitoring
3/after resetting the passwords and deleting unknown administrator accounts i saw indeed a backup user trying to connect
4/applied the post sp4 fix (ms02-11) included and all nt hotfixes available
5/queue kept on filling so i added all internal recepients to the restrictions tab and turned on relay to these ipadresses with all others blank
result : bluestell stopped ; a few <> appeared for 10 minutes and then mailserver was clean

i tried sending / receiving after applying all this and left
now i'm getting 550 5.7.1 relaying prohibited when sending to that domain.
telnetting is blocked so i can't check remote.
any suggestions on this ?
thanks

Can you post more details? Have you checked www.ordb.org to see whether you re blacklisted or not? Misconfigured client / server? CAn you say more about what you did in step 5? The procedure i described above, except my exchange server has also being applied to 23 more exchange servers (in different domains)without any complications. Can you describe the configuration of your routing restrictions. Normally you dont have to fill in any ips . Sorry for the late post but i m out of the office most of the time.
Good luck and keep us informed
George

I have the same problem "Bluestell" spam mail.
I have followed all the Georgeks steps but the problem still exist.
I have changed all administrator users password with very strong password but I have always the same problem, in the event log I found:
Connection from 211.158.51.155 was successfully authenticated (AUTH LOGIN) as \administrator.
And many message in the outboud queue.
PLEASE HELP ME!!!!THANKS!!!

I am having the same symptons on our server.  Here are the steps I tackled to date:

1 - took the server out of production and updated all the patches for Exchange 5.5
2 - enabled all the logging to look for an account that might be used to send SPAM
3 - changed the password for every user, service, etc. on the NT box
4 - cleared out the pending emails
5 - basically, did everything listed here but the SPAM is STILL coming...

We run Norton Anti-Virus and a Trojan/Worm program, but they find nothing.

Anybody have any more ideas to resolve?

Add every IP you find in the event log to the 'IP addresses that can NEVER relay' box that under 'relay restrictions' on the routing tab.
Also, uncheck the box next to 'hosts and clients that successfully authenticate'.
Check the box next to 'hosts and clients with these IP addresses', but leave that box blank!

Hope this helps.

Corie

Ok, I had this problem last week and it took about 6 or 7 hours to resolve. I tried everything that was posted up here through 9/23 but nothing worked. Ultimately, I applied the MS patch, stopped Exchange, deleted the in and out queues (yes emails will be lost) and then removed the Internet Mail Service and then re-created it. The user's Exchange box has been bluestell and NDR free for a week solid now, although I can see remote machines trying to connect using an \abc and an \administrator account. This might be worth a shot if you've tried everything else.

I had the bluestell spam here as well, and when I followed several of the steps above I found that the account that was connecting to our exchange server was one that did not exist on the machine at all. (nor on our domain).

It was "admin". So I created the Admin account on the local machine, gave it a secure password, then disabled it. Spam stopped immediately and hasn't come back for 3.5 days now.

Hope this helps.

Cheers
David

Well the same here,
but found out that the abused login (test) was not a local account, but an account from a trusted domain.
Disabled it and now waiting to see what happens in the next hours.

I want to thank paddy138 for the useful information.  We were experiencing the same exact problems, and your suggestions worked for us.  We applied the patch from MS that you mentioned, removed and reinstalled the IMC.  So far, so good.

We also noticed that our "guest" account was enabled and used for authentication (even though we originaly had it disabled).  I hope they find the little S.O.B. that created this one!

We have experienced this issue with bluestell as well and I think we have fixed it by changing our passwords.  It's been 4 hours and I haven't had any new queues or emails sent.  My problem now becomes cleaning up the 800 queues that were created.  I am on exchange 2000 sp4.  Any quick solutions that I can use to delete all messages in all queues that contain "bluestell*@*.*" would be helpful.

It seems that my attacks have been stopped for two days now, due to techniques from this site. Thanks!!

I'm not sure but this morning i was hit again instead of bluestell**@* it uses blueinfo**@*
It uses the admin account although this is not excisting.

We had 20-30,000 emails in the last few days. After finally deleting all of the 'Bluestell*' emails, we turned on the logging as suggested. 4 more Bluestell emails came through, but we didn't see any 2010 or 4183 errors. Next, we checked for unused accounts and disabled them. Overnight, about 8 '4183' failed logon errors showed up from 211. & 218. domains. It was trying to use our \test user account which was disabled yesterday. So far, no more Bluestell...Thanks for the help, everyone - Jim

I adjusted the expiry dates on our server and this cleared up the queues.  Thanks all for posting here.

I was also getting pounded by Bluestell** and Blueinfo**.  Turning on the logging per James3838 (9-17) allowed me to pinpoint my weak point.  

They were using \administrator, which is the LOCAL Administrator account.  I'm on NT so I wasn't able to change it using the UserManager for Domains.  

Instead, CRTL+ALT+DEL, choose change password, select administrator for "MACHINE NAME" (not domain) and hope you know the old password. (Try empty field because there's a good chance there wasn't one originally).

Exchange 5.5
NT 4.0 sp6a
All patches
Not open relay
Changed Domain Admin password
Removed/Disabled unneeded users
Have POP users


Kudos to James3838 and Georgeks for the detailed info!!

An additional preventive measure to add to the layers in the previous posts:

1) Create a security group containing just your user accounts that have Exchange mailboxes (and that use your server for auth. SMTP).

2) Set in the Exchange server's local security policy for "Access this computer from the network" to only Admins and the security group created in step 1.

This will help prevent user accounts that we sometimes create and forget about (test and temporary accounts, etc.) from being able to connect to your Exchange server even if the account is compromised.

Also, if you would like some quick ways to search for specific details in Event logs, try the free tool EventComb from Microsoft:
http://www.microsoft.com/technet/treevie...
(see "Monitoring for Intrusion and Security Events")

Or Log Parser:
http://www.microsoft.com/downloads/detai...
(there's an update to 2.1 in the IIS 6.0 reskit)

Or if you're more adventuresome, try using some the Query Event Logs scripts from the MS Script Center:
http://www.microsoft.com/technet/treevie...

techjulie,

To change local administrator password in User Manager for Domain.  Use 'Select Domain' from user menu.  Enter your local computername instead of domain name.  Then you will see all local accounts.  Reset the password of local administrator from here.

Greetings.  I have no new tech data to add, as all above is quite thorough, I just wanted to broaden the scope of your reported issue; this mutant spammer isn't just limiting him/herself to hacking Exchange rigs, I had my MDaemon server just pegged by this bottom-feeder "bluestelxxx@varieddomains.com."  This guy had run a dictionary attack on the default accounts (that shouldn’t have been there in the first place), and while I had the server set to pop before sending, no relay of foreign domains, and other logical precautions he/she was coming in and authenticating under this compromised account name/password.  
In response to a couple of the posts, what happened to in my situation is that this hoser would peg our T-1 in off-hours and fill our remote queue up with thousands of spams of schlock, so that even when I'd bring the server down, "secure" everything, and bring it up the que was still full and start its SMTP'ing.  I had to delete who knows how many legit emails to dump this guy, and notify my users to resend critical data.
He/she is also responsible for getting my corp's domain name blacklisted by various authorities and caused me much time and money to get cleared again, and clean up his/her mess.
This person was and coming in from varied IPs and varied ISP accounts, and couldn't be blocked easily.
This guy is obviously not an amateur and does this for a living, maybe even off http://spamhaus.org/rokso/index.lasso list. ?  I hope threads like this help to nail this looser, as he needs a strong and harsh lesson.

Toolburn

I am looking at my event viewer and am not seeing any entries ay all in my security log.  Logon attempts seem to be showing in my application log is this normal.  How can I get then in my security log?

Hi Guys and Girls

One of my clients has just been hit by this nasty piece of work.

They run Win 2k Server and use the latest version of FTPGateOffice (Floosietek Ltd).

This is the only place where quality information exists on bluestell.... But I wanted to post this because unlike anyone else, this company doesn't use Exchange as it's mail client, instead they use Floosietek's FTPGateOffice. So the procedure has been very different for us . . . . and much simpler  lol !!

The system crashed yesterday and we quickly realised, from posts on this forum, what we were dealing with.

Luckily, after some head scratching and 90,000 emails later, our fix was quite simple.

It is essential that you all have the latest Microsoft Cumulative Patch as mentioned in the Microsoft Security Bulletin MS03-039 at http://www.microsoft.com/technet/treevie.... I know everyone here has emphasised this, but it's true.

Firstly, get this patch installed and bring your server back up.

Then you will need to check the folders within FTPGates file structures.

You should have a folder in the Root of your drive called 'spool'. Within this folder are 2 sub folders called 'Inbox' and 'Internet'.

If you access the 'internet' folder it contains a second sub folder called 'internet'. This second folder contains a backup of all the queued emails. delete the top internet folder and re create it.

Finally, go back up the tree and access the 'Inbox' folder. There is a sub folder here called 'scanfldr'. You will have to delete this folder and re create it, because there is a hidden binary file called NIL.txt that is lurking there.

Word of warning: The deletion process will take a while lol

The servers been running for 3 hours and all is stable . . . . let's wait and see  

Good luck

Tim

*****Spam mails never come back again*****

Dear all,

Thanks for all of you to share the experience to us on this forum. Now I want to share my experience to the one who hates the spam mails.

As far, I have spent a whole week to find out how can I let my Exchange 2000 server to get rid of a thousands spam emails during a day. Originally, I reset the administrator password, disable guest account and changed the smtp port, disable relay function, but still has a lot of spam mails through my server to relay  and sent out the spam emails. I doubt MS Exchange 2000 SMTP server relay disable function is work or not. Finally, I found out a solution to get out of spam mails. The steps is as follow:

1. You should have two network cards on your MS exchange 2000 server. (One for inbound mail, one for outbound mail. if outbound network card is internal IP, but it can be routed to another external IP address router for seccond smtp virtal server that is ok.)

2. Go to Start->Programs->Microsoft Exchange->System Manager->administrative group->Server->Protocol->SMTP->Default STMP Virtual server->[right clik]->Perproties->Delivery tag->(change all fields to 1 or 1 MINUTE on delivery page)->click Outbound Connections button to change TCP port to 1.

3. Above 2nd procedure let outside email to deliver to a wrong port if it is a relay email and retry time out for one minute. It it is an organization email, it will deliver to the mailbox.

4. Add Second SMTP Virtural Server by using right click on SMTP object. On General tag, select second IP address network card on your server and change the port number to any other different from 25 (not conflit with any port number) in the Advice button. On Access tag's Authencation button, uncheck Anonymous Access.

5. Above 4th procedure to let internal users can send out emails through second network card.

6. Change all Outlook Express SMTP IP address and Port number setting to match second network card's configuration in order to send out the email.

7. The spam emails will not be dilivered via your STMP email server successfully. They will never come back again.

ANDY (MIS)

WE HAD THE SAME PROBLEM FOR A FEW DAYS. WE MADE ALL GUEST AND ANNONYMOUS USER ACCOUNTS DISABLED ON OUR EXCHANGE SERVERS (5.5). WE ALSO ENABLED SECURTIY LOGGING. IMMEDIATLY THE MESSAGES STOPPED AND WE SAW WHERE THEY WERE TRYING TO USE OUR GUEST ACCOUNT. THIS WILL FIX YOUR PROBLEM.

Fantastic.  I too have been hit by this problem.  I am currently running WinNT 4.0 and Exchange 5.5 -- ALL with the latest service packs.

Furthermore, I've been following this thread and trying everything to stop this user from gaining access to my computer.

Without know so, some one actually did mention the method for seeing "which" account was gaining access.  When I saw the event ID and the message that an IP address was authenticaing, I quickly had the Network Administrator's account password changed.  After this attempted failed, I had ALL the accounts that are in the Domain Admin grp (total of 2) passwords changed.  Still it wasn't working.... although I did notice that a LARGE amount of emails where being prvented from relaying.   However, I still was getting around 4k of emails.

Today I logged on again and saw a post by TechJulie that for somereason (maybe it was the wording) turned on a light bulb.  It is NOT the Network admin account but the "LOCAL" admin account.  Hello!?!

I changed the password (which was blank!) to the Local Administrator's account and that fixed it!

On my event logs I'm seeing the IP Address and server address of the REAL person that is sending out this spam.

In short:  change the password to the LOCAL computer administrator's account!  (I apologize to those techies that are reading this email saying "hello....that is what I've been saying!").

Here's the information of the culprit attempting to relay message from my server:
Host122.200-43-88.telecom.net.ar

Thank you to all regarding this issue.

Hi All

I have been doing some digging and there are 2 ways that this attack can happen.

Firstly, via SMTP AUTH hijacking as we've discussed. My clients had an email account called 'Test' and it is probable that this account had a weak password and was breached. All unused and test accounts are now disabled and their system is secure.

Secondly, via an email worm known as W32.Frethem.E@mm (or possibly Frethem.F, there are multiple variations of this worm). This worm has been in circulation for almost 1 year and the IP addresses used (from inside China) tie up with those associated with W32.Frethem.

It can be enabled by previewing or opening the email that contains it. This worm affects Win 98, NT, 2k, XP and exploits incorrect MIME header/IFRAME vulnerabilities. These vulnerabilities can be addressed by downloading the latest cumulative patch from Microsoft's web site and most anti virus programs will remove it.

I received an email, on a PC at a different location entirely, on Friday afternoon which was from  . . . you guessed it bluestell**@*.*

So previewing or opening anything with 'bluestell' in the email address will also result in the worm becoming embedded on a users system if it is not adequately protected.

I have some guidelines (thanks Symantec) for manually removing the worm should anyone need it.

Tim

Firstly thanks all for help with the authentication vulnerability - seemed to work a treat.

However, I now have a secondary problem (probably not related to the above).  I am getting quite alot of messages sent to gobly-de-gook@hotmail or ucn70.tjxpi@foredu.com.cn or shift12@shark007.systes.net and anderson@ip_address / howard@ip_address (where the IP address is the IP address of our gateway) accounts from a blank originator (sender) <>.  i.e it appears my server is the sender.

I do not know where these are coming from but I am getting several per minute and know this is a new phoenomina on my server.  It seems to be an even greater problem when I have notifications turned on - as I get what appears to be an ever increasing circle of Emails which eventually bring the server to a slow-down.  Basically what appears to happen is that the <> sender uses Exchange to send to spurious looking Email accounts - usually yahoo/hotmail - then I get many many undeliverable reports from yahoo/hotmail.  Does anyone else have experience of this???

Looking at the notifications I get the content of the mails seems to be predominantly Chinese!?!  Any input would be really appreciated as I'm coming to the end of my tether with this kind of Exchange issue.  Prompt reply would be very much appreciated.

Cheers, Simon

Bigkav.

First of all, disconnect the server from the network and stop the SMPT service.  Next make sure that you have installed the lasted virus defs and Ms Patches.  

Finally Clear the queues of the unwanted email and start the SMPT services again.  With the server still disconencted from the network, check the queues to see if they are filling again.  Oh,  You will want to run a virus scan of the server to ensure that it is clean.  If the queues do not fill again, then reconnect the server to the network and see what happens.

Thanks johndpatriort

Does this mean this is a virus?????  I am up-to date and dont believe I have any viruses.  What makes you think it is?

Simon

Just the way yuo have described the problem leads me to believe this is possibly a virus.  That and it''s best to rule that out right away, otherwise you could spend alot of time chasing something that could be relatively easy to fix.

Have you tried removingthe server from the network and emptying the queues.  This will help determine if the problem is on the server or not.

We got struck with this bugger late yesteday, and this place seems to be the only site with any info!  Do a search on Google, and see what I mean.

Our Exchange 5.5 (NT4 SP6a) is also our BDC, so we have no local admin, however I have changed the Domain admin password (which was only 4 letters!), and disabled/deleted accounts not in use.

Problem now however is mail is coming in, but not going out. (Outlook 2000 clients).

Any advice?

Thanks
Horness

I have the same problem as Horness. I can receive mail internal/external, but can not send mail externally?\

Any advice?

How do I empty to queues with SMTP turned off??

gbutts, go to the drive that Exchange is installed on, and remember it could be spread throughout multiple drives, then go to \exchsrv\imcdata\

In the imcdata folder you will see an In and Out folder. All of my bluestell messages were in my out folder.

Help!! Still can not send external email!!

Gbutts,

what server version are your on.  What SP?

What are your settings for the virtual SMTP service as far as relaying is concerned.  Have you made changes?

I ran across this thread when I found a slew of 4183 errors in my App log on my Exchange Server, and decided I needed to find some more info. What I read pretty much confirmed everything I had decided - that this was a concerted, if cursory, effort to authenticate for relay purposes. However, I wanted to share something I found that hadn't been touched on yet:

georgeks, above, rattled off the accounts that are being attacked, and my experience bears this out as well. In addition, my logs are showing - consistently - 23 separate and consecutive attempts per account. This leads me to believe that the same 23 passwords are being attempted over and over again, in the hopes that someone has left that hole open.

I also found that, of the three attempts I saw over the past two weeks, all three came from China, specifically from CHINANET. Two of them were from allocated but not assigned IPs. But one was assigned to an elementary school!

Here's the assigned IP I had trouble with, from codeflux.com's whois tool using whois.apnic.net:

whois '218.7.157.254@whois.apnic.net':  
[whois.apnic.net]
% [whois.apnic.net node-1]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

inetnum:      218.7.157.192 - 218.7.157.255
netname:      FOURTH-ELEMENTARY-SCHOOL
descr:        Da Qing city department fourth elementary school
country:      CN
admin-c:      BG63-AP
tech-c:       BG63-AP
changed:      gaobh@mail.hl.cn 20030610
mnt-by:       MAINT-CNCGROUP-HL
status:       ASSIGNED NON-PORTABLE
source:       APNIC

person:       Binghui Gao
nic-hdl:      BG63-AP
e-mail:       gaobh@mail.hl.cn
address:      Communication Corporation Internet Enterprise Division of HLJ
phone:        +86-451-2804465
fax-no:       +86-451-2804442
country:      CN
changed:      gaobh@mail.hl.cn 20030221
mnt-by:       MAINT-CNCGROUP-HL
source:       APNIC

Note: This IP address belongs to a Class C network (up to 28 hosts)


From that, I've got to say that either the hacker/spammer is spoofing IPs or a script-kiddy has gotten hold of the tools originally used.

I found the account that they were using, it was from the 211.158.XXX.XXX IP. But now, I can not change the setting or disable the "test" account, it say that I don't have the priveleges to make changes!!! Please help!

I am running NT4.0 sp6 on exchange 5.5 sp4

Use a Domain Admin to over ride the local admin accounts rights and gain access the then local Admin.  Next cheeck if your test account is in the admin group.  Just my thoughts..

Hi Guls and Gays
i have readed all the above things and tried all the thing i got no guest account no local administrator account we are runing exchance 5.5 with ISA server. I have done all the things including deleting the IMS my IP has been blocked i am reciving mails from out side but cannot send any thing i also tried event view but no help. But when i talked to my ISP he gave me another Ip it worked for five to six days but now this Ip is also blocked and Que is filed with nearly 20000 pending bluestlle and other . can any body help whould be thankful.

Finally traced ours to a \test account, which did not exist in the domain that the email server was located, but did exist in another domain that had trusts setup.

Key points (for us anyway)

 - Apply updates
 - Change Administrator password
 - Delete/Disable any accounts which are not used
 - CHECK ALL DOMAINS trusted to the one your email server is located in.
 - Block the IP addresses mentioned earlier on your firewall

I'm now going through changing everyone's password, and re-writing the password guidelines.

Thanks everyone.

Horness.

PS: Reason we could not send - our firewall had closed the outgoing SMTP port due to high volumes.  Re-opened it, and presto!

Congrats Horness

I now have found and fixed the problem. It was a test account on our BDC. I have disabled the account, because we don't need or use it anyway, and cleared the queue. That was at 7:00 pm last night and now 11 hours later all is well.

First I did the same as johndpatriort wrote on oct 7th.
After that no mail appeared for one day.

This morning it started all over again.
A friend made me a suggestion to look for the local user:
TsInternetUser. We uses Windows 2000 Terminal Server.
This user exists and had no password. So here's what I did:
I gave the Local Administrator, Local Guest and Local TsInternetUser a very strong password and then disabled login for Local Guest and Local TsInternetUser.
(Rightclick on My Computer -> Manage -> Local Users and Groups -> Users. Rightclick -> Properties. Rightclick -> Set Password).
After that the spam/relay stopped. I hope forever.
Let see what tomorrow brings!

I was called to a clients site due to their Outlook clients locking up.  The clients were locking up because the server was running out of drive space.  The server was out of drive space due to HUNDREDS OF THOUSANDS of bluestell spams in the queues, and over 250,000 (a QUARTER MILLION) non-delivery reports in the Administrators mailbox.

Their Administrator account password was 'password'.

Changed password and spamming stopped.  Double-checked all the other accounts (domain AND local) for secure passwords.

This is an Exchange 5.5 SP4 on NT4 SP6a that already had relaying disabled.

Thanks sincerely for this thread.

Take a look at this :

http://www.securiteam.com/windowsntfocus...

There is nothing you can do else closing smtp.

bye

I have seen nasty stuff like this before. In Fact 2 Clients have has the same problem.. And they went undetected for DAYS!!!.. Well its a SIMPLE solution and I use the solution for Excessive Spam, Port 25 Attacks Etc...

You have to use some sort of Reliable Spam Gateway Service. that can Filter Mail..We use somebody in PA
. What the service does is Filter Spam and viruses through email. All Mail MX records are sent through a group of Scanning Servers and Delivered to My clients Exchange Server. So what I do on the Router is BLOCK (BY IP Address) ALL port 25 TRAFFIC except for the Scanning Servers..
Its that easy...
 MY Mail Servers Essentially have port 25 Shut Down. I only allow the scanning Servers and a Queing server access..

All of your Dsl & T1 router usually have this feature...
Check it out .. Cisco has Access List..

Send me mail if you need Assistance.. The Spam Server is about 2.25/email... so for 50 emails you pay about $115 month but your protect from SPAM,Viruses, other attacks, etc.. I makes me sleep at night and I look like a hero...!!
My clients usually need a solution for spam anyway and I didnt have to go crazy finding a product..
The other neat feature of the service is that the Spam get quarrented (spell eek :() to end user Viewing...

Frank
njnetfixer@aol.com

Ok, I have the same issue and this is where i tracked down the last instance of this bluestell_@ crap. I have the same issue and have locked the server down, and have the same prob. I will continue reading to find an answer, but if anyone cares or if anyone knows any good DOS attacks. All of the info for this spammer is below. I am more than happy to assist in knocking out this a@*holes spamming campaign. email me: michael@reconnectsystems.com if you are interested in taking out his server with me.


Enjoy.....

michael

//Info follows//

tolast55.com
 

tolast55.com resolves to 61.144.129.128

www.tolast55.com resolves to 61.144.129.128



whois -h magic tolast55.com
tolast55.com is registered with XIN NET CORP. - redirecting to whois.paycenter.com.cn

whois -h whois.paycenter.com.cn tolast55.com
The Data in Paycenter's WHOIS database is provided by Paycenter
for information purposes, and to assist persons in obtaining
information about or related to a domain name registration
record.
Paycenter does not guarantee its accuracy.  By submitting
a WHOIS query, you agree that you will use this Data only
for lawful purposes and that, under no circumstances will
you use this Data to:
(1) allow, enable, or otherwise support the transmission
of mass unsolicited, commercial advertising or solicitations
via e-mail (spam); or  
(2) enable high volume, automated, electronic processes that
apply to Paycenter or its systems.  
Paycenter reserves the right to modify these terms at any time.
By submitting this query, you agree to abide by this policy.
        
Domain Name:tolast55.com


Registrant:
guang an
120 ma shi ti road
638000



Administrative Contact:
guang an
guang an
120 ma shi ti road
guang an Sichuan 638000
China
tel: 86 0826 2342570
fax: 86 0826 2342570
bingwued3@yahoo.com.cn

Technical Contact:
guang an
guang an
120 ma shi ti road
guang an Sichuan 638000
China
tel: 86 0826 2342570
fax: 86 0826 2342570
bingwued3@yahoo.com.cn

Billing Contact:
guang an
guang an
120 ma shi ti road
guang an Sichuan 638000
China
tel: 86 0826 2342570
fax: 86 0826 2342570
bingwued3@yahoo.com.cn

 Registration Date: 2003-09-29
       Update Date: 2003-09-29
   Expiration Date: 2004-09-29

    Primary DNS:  ns0.nameicq.com 218.22.13.23
  Secondary DNS:  ns1.nameicq.com 219.153.0.212





traceroute tolast55.com
 

tolast55.com resolves to 61.144.129.128

Do not contact either Los Nettos (ln.net) or Centergate Research Group (centergate.com) based on the results of this traceroute.

 3    130.152.180.21   6.264 ms   isi-1-lngw2-atm.ln.net [AS226] Los Nettos origin AS
 4    38.118.132.97    8.969 ms   DNS error [AS174] Performance Systems International, Inc
 5    66.28.4.201      147.091 ms p15-1.core01.lax01.atlas.cogentco.com (DNS error)
 6    154.54.2.214     3.413 ms   p2-0.pr01.lax05.atlas.psi.net (DNS error)
 7    154.54.10.198    7.343 ms   chinatelecom.lax05.atlas.psi.net (DNS error)
 8    202.97.51.193    151.553 ms DNS error
 9    202.97.33.153    147.733 ms DNS error
10    61.140.0.22      146.080 ms POS8-0-R1-C-GZ-A.gd.cn.net
11    61.140.1.2       145.660 ms DNS error
12    61.144.8.18      290.087 ms DNS error
13    218.19.176.11    147.458 ms DNS error [AS4813] GUANGDONG PROVINCE BACKBONE NETWORK
14    61.144.129.128   237.623 ms DNS error
15    61.144.129.128   219.633 ms DNS error



Sam Spade Home © Contact Change Skin Search

Still clean after 5 days!

He's only still trying because I had last weekend 659 attempts: 4183 Events failed login in my application log.
The accounts used are: \administrator, \abc, \data, \server, \backup, \www, \web, \master, \test, \root, \admin and \webmaster.

So beware!

I have tried many of the tips here and nothing seems to stop the queue from filling up.  I am using NT Server 4 with service pack 6  and Exchange 5.5 SP 4.  The queue fills up even when the server is disconnected from the network.  We've installed all the patches and renamed the accounts on the network to no avail.  Any help on this would be wonderful.

Hey Everyone,

I've seen this clown as well. All the account rules are correct. That's always a must in administration! With Exchange5.5 if you have not tried this open> IMS > Routing >
Set to > re-route Incoming SMTP to your local domain > Edit > should be set to Inbound as well.

Next be sure to add any conflicting domains to your routing restrictions table > Specify the hosts and clients who can NEVER route mail. This keeps the fools from ever comming back from that given network.

Setup your routing restrictions in a way the makes sense to your local network. For example, in the 1st section add your local domain internal address space to make sure that all your users can safely email outbound.
Usually you would select the check box for hosts and clients who succesfully authenticate.

Next, Get a progam such as AY-Spy to keep track of any suspect items in your que. When one is found simply look at the details of that qued relay, and slap it into the AY-Spy
program to see where it takes you. Hopefully you'll get the IP address of the culprit, Or a Domain where it's comming from. If you cannot find out the IP address, maybe you can add the NS server that the Domain is using. Next once an IP is found, simply add that IP to the Restricted routing table mentioned above. There done after that! No exceptions.

If by chance, you are one of the users who sees more ques after you've removed your server from your network, it is possible that the intruder created his/her own account that may be emmbedded within an existing Exchange mail user. Sounds crazy but it is true. If so, then you would need to
remove each users SMTP mail address one at a time until the
smap stops. once you've found the correct account simply remove that account and create a new SMTP email address for that user. I know it sucks, but it will work. However, once you find the user account responsible, if it's not the admin on the server itself, you will need to completely clean that machine of the virus causing the continued outboud emails.

Others from above are correct as well, such as Kiver! Thanks! Also keep a close watch on your applications log in the event viewer, It's the best way to see all the activity on your server. Remember you MUST have the diagnostic logging set to maximum for your given item to watch.

Hope any of this helps!

Thanks Everyone.

2nerZ

Okay everyone, here is the riddle solved.....  (I apologize for not reading through the entire thread but) it seems like no one has a definitive answer yet...  I work for a company that makes software that competes with Exchange, but since whatever software it is, if it is using SMTP then it is the same, and we are starting to get a lot of support calls that are similar to the symptoms that are described here, and as others have said typing in BLUESTEL in Google turns up this site and none other [except for the actual spam messages and porn related sites, etc].

Anyway, after taking a LAN trace of the problem occuring we were able to determine that despite the fact that the SMTP server was NOT an open relay this person/entity/program is actually AUTHENTICATING to the SMTP server as an authorized user.  You can look at a LAN trace too, look for AUTH LOGIN, you will find something similar...

The trace showed
Server: "220 xxxxxxxxxx"
Client: "EHLO excepted"
Server: "250-xxxxxxxxxx"
Client: "AUTH LOGIN"
Server: "334 VXNlcm5hbWU6"
  Note this is Base-64 encoded, you can use pages like the following http://www.opinionatedgeek.com/dotnet/tools/Base64Decod... to decode base 64, in this case it means:
"Username:"
Client: [base 64 encoded username]
Server: "334 UGFzc3dvcmQ6" [Password:]
Client: [base 64 encoded password]
Server: "235 Authentication Successful"
Client: "MAIL FROM:<Bluestellxx@xxx.xxx>
etc

Anyway, we decoded the Base64 username and password (in this case they were the same username as password--IE VERY INSECURE).

I hope that this helps you guys in finding which accounts are being utilized to turn your server into the equivalent of an "OPEN RELAY".

You can use ETHEREAL a FREE LAN trace tool to help you if you don't have access to something like SnifferPro etc.  Anyway, like I said I work for a competing company, but wanted to share the information with the rest of the internet community because this is the ONLY site that mentions the problem.


Please secure all your accounts.  DON'T use the same username as password (like postmaster/postmaster) Check all your accounts, and as has already been stated remove/delete/disable any account that doesn't need access.

sorry, I realize that other people HAVE posted the information already, I didn't have the time to read through the thread before, I didn't see that joeg701 already posted the same thing.  Anyway, I hope Bluestell dies!!

Thanks for the tips.

I still see in my logs where my Exchange 5.5 SP4 server is still accepting email to users that do not exist in my domain.  Someone is using my domain with invalid users and are still getting a 250 OK.

lpoulin below is not a user on my domain, shouldn't the server reply with something other than 250 OK when the user does not exist?


250 OK 10/15/03 9:47:40 AM : <<< MAIL FROM: <kpbx667lt@yahoo.com>
10/15/03 9:47:40 AM : >>> 250 OK - mail from <kpbx667lt@yahoo.com>                                       

10/15/03 9:47:40 AM : <<< RCPT TO: <lpoulin@theauditgroup.com>
10/15/03 9:47:40 AM : >>> 250 OK - Recipient <lpoulin@theauditgroup.com>                                 

10/15/03 9:47:41 AM : <<< DATA
10/15/03 9:47:41 AM : >>> 354 Send data.  End with CRLF.CRLF                                                   

That means you're still relaying email. Open Internet Mail Service in Exchange Administrator, click on the routing tab and make sure your setting is REROUTE INCOMING SMTP EMAIL.
Sent to should be YOURDOMAIN.COM and route to should be INBOUND.
Then click on ROUTING RESTRICTIONS and UNcheck the box next to 'Hosts and Clients that successfully authenticate'
and CHECK the box next to 'Hosts and Clients with these IP Addresses:'.  LEAVE THAT BOX BLANK!

Next, restart the IMS service and try the telnet command again.

Also, you can add the IP addresses that have been posted in this thread to the "Hosts and clients that can NEVER route email" box.

Hope this helps.

Corie

Hi Thanks for the Reply.

I did that and it still accepts messages for invalid users as long as they have my domain (@theauditgroup.com).  This is causing the server to create many many NDR reports and clogging up my queues.

Is there any way to refuse the connection if the user is from my domain but not valid (not in the GAL)?

You now need to go through all your user accounts, local and domain. Some here have found a local admin or guest account enabled, or a domain user account that has been added. Enable SMTP logging to maximum and see which account is being accessed. Once you do that, the problem should clear up.

Corie

I am now receiving a new varient dfkcaxxx@msn.com from the

tolast55.com resolves to 61.144.129.128

www.tolast55.com resolves to 61.144.129.128

mentioned above

I just set up a forward to send anything with the above config back to all emails related to their servers. Its all I could think of...

tsd

***ALL***
I worked with Microsoft to work out my problem...here is the solution that is working the best.
Key items: strong passwords and turning of authenticated relay.

Thanks,
Marcus
__________________________________________________________

Issue:
======
Exchange server being used to relay spam to the internet.

Resolution:
===========
Local Administrator account was changed from null password last night.
Attempting to detect the account being used for relay: Turned on SMTP protocol logging on the server Disabled all relay on the server (No POP/IMAP users on the server)

Checking queues on the server- Outbound queue (IMCDATA\OUT) 20k items in queue.
MTS-OUT on the server ~147k messages in queue.
These are all non-delivery reports.

To clear the queues, we renamed the IMCDATA\OUT directory and removed the Internet Mail Service.

After reinstallation of the Internet Mail Service, we were able to send/receive internet email.

Checking logs to determine if we caught an attempt to authenticate.  We did not.
Suggest, as we have removed all ablility to relay through this server, the problem will not happen again.

There may be some non-delivery reports occur on the server as a result of the ealier spam attack, but that there should be no real accumulation of queues on the server after taking the above steps.

If you required POP connectivity through the server, we would need to find the account that is being used to authenticate through the server. Do this with the following steps:

1) Enable SMTP protocol logging on the Internet Mail Service's Diagnostic Logging Tab**
2) Stop and Restart the Internet Mail Service
3) Monitor the Internet Mail Service's Queue's; Look for messages destined outbound with an external sender.
4) Once a relay is detected, view the protocol logs in EXCHSRVR\IMCDATA\OUT
5) Find or Search for the word "Authentication"
6) Prior to the words Authentication Successful, you will see 4 hashed commands; 2 from Exchange and 2 from the client.
7) Use a base64 decrypter to determine the Account that is being used to relay through the server.

**Make sure to disable SMTP Protocol logging after logging is complete

The only way to stop this action is to shut off Port 25 to the outside world...

With the Tons and Tons of email thats hitting your mail server things can be pretty slow... And so what these guys will figure another way in.. Correct Isn't it Microsoft??

If you get all your mail through a mail gateway service and only a couple ip addresses, you can block off Port 25 off from the World!!(at the router level)

Wouldnt you want Cisco handling the traffice not the Mail Server..

1. Port 25 would be CLOSED and hackers won't even know its OPEN!! ya got me??
2. Spam or attacks arent goin to direct hit your mail server.
3. No Harvest Attacks to your use list..

Anybody that has this problem could be fixed up in an hour .. I still these crazy things ALL the time... I manage about 110 Mail servers... I'm here to help..

Frank

I've looked through all my event logs & through for the 2010's & 4183's & I come up with the user that is being used is \backup. I'm assuming that is going to be a local system account on one of my servers however I can't seem to find it anywhere. I'm getting nailed by over 25000 relays a day, & now several domains have banned my domain from being allowed to email them & unfortunately a couple of them are domains we actually send mail to on a regular basis.

Little help?

Nuero

Try creating the backup account on that server, and then desabeling it.
Also, double check with relay checking sites, to make sure you are not listed on their blacklists. You might need to request to be unlisted once everything is good.
good luck

I've created a user in our Active directory called Backup however it doesn't seem to be slowing down or stopping, I have also applied the patch that James3838 mentioned earlier in this forum from Microsoft for Exchange 5.5, I haven't rebooted yet but I will through the night tonight & hope for the best, I'll let you guys know ASAP.

Thanks,

Nuero

A reboot, and an emptying out the que should help.
You still might see for a short time some cached e-mails go through, but it should stop if nothing else was wrong.

Well here's what I've done...

1. Created a user called backup & gave it a ridiculously long password (48characters with Some CAPS & Numbers & Symbols)
2. Applied the Microsoft Patch for Exchange 5.5
3. Emptied the queues & rebooted the server.
4. Checked on the server about 30 after the reboot, & there was 378 messages stuck in the outbound queue.

Here's the latest 2010 Event.
11/28/2003
MSExchangeIMC
Information
Event : 2010
Connection from RJ202164.user.veloxzone.com.br was successfully authenticated (AUTH LOGIN) as \backup.

So it's still happening, any ideas how to track that \backup user???

Nuero

Well It's Tuesday & the mail is REALLY flooding thru now. We're talking about Thousands of emails every 10-15 minutes.

My internal mail works, but even trying to stop/restart my internet mail service is DEADLY slow, usually about 5 miutes before it fails & says it's taken too long & just gives up.

I think I know what server the \backup user is on, but cannot figure out how to get rid of it. Any ideas?

It's an old NT4 server, that before the upgrade to 2000 on the other servers was a Domain Controller.

Can you remove the Old NT server?

Yes & no. I can pull the NT server out of the domain fairly quickly but I can't do it during the day (Business hours) because that is the server that still hosts about 90% of our data. I plan on moving the data from that server & demolishing the old NT box with a hammer if it is the cause of my frustrations.

johndpatriort (IS/IT--Manageme) Dec 2, 2003
Can you remove the Old NT server?

try logging onto the domain server Locally (if you allow that in the policy) and create the backup account.  I assume that you have a new "domain/ad" structure.

Sorry if you may have stated this before but i don't see it.  Do you have POP accounts outside?  If not you can unselect the option for successful authentication.  If you do use POP have you tried to block or not allow relaying to 200.223.8.81 which is veloxzone.com.br?  Is this the domain that is alway authenticating?

I have created a Backup user in our domain & gave it a insanely long password, then disabled it. The problem is that I cannot find this \Backup user. I cannot log on locally to the NT4 Server but I can onto the Windows 2000 Domain Controller which doesn't have a \Backup user.

johndpatriort (IS/IT--Manageme) Dec 2, 2003
try logging onto the domain server Locally (if you allow that in the policy) and create the backup account.  I assume that you have a new "domain/ad" structure.

Actually I do have POP accounts outside of the building. And unfortunately if veloxzone.com.br was the only domain hitting us I'd just ban them. But unfortunately I'm getting hit from about 50000000 directions at once. I've been watching carefully, the messages are all the same, so they are coming from the same place but are bouncing their way through to me differently.

devastator (IS/IT--Manageme) Dec 2, 2003
Sorry if you may have stated this before but i don't see it.  Do you have POP accounts outside?  If not you can unselect the option for successful authentication.  If you do use POP have you tried to block or not allow relaying to 200.223.8.81 which is veloxzone.com.br?  Is this the domain that is alway authenticating?

Check these settings:
Open Internet Mail Service in Exchange Administrator, click on the routing tab and make sure your setting is REROUTE INCOMING SMTP EMAIL.
'Sent to' should be YOURDOMAIN.COM and 'route to' should be INBOUND.
Then click on ROUTING RESTRICTIONS and UNcheck the box next to 'Hosts and Clients that successfully authenticate'
and CHECK the box next to 'Hosts and Clients with these IP Addresses:'.  LEAVE THAT BOX BLANK!

Restart IMS and that should end the relaying problem you're having.

Next you need to find that account. Check every server in your domain for local and network accounts, it's somewhere.

Open a telnet session and test your setting for relaying.
You can test by typing the following at a command prompt:

telnet [servername] [25]

where [servername] is the name of your Exchange server and [25] is the port it runs on. The Exchange server will respond with a message similar to '220 host.domain.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2650.10) ready'.

Then enter the following commands. The commands are case-sensitive, and the punctuation (e.g., colons, angle brackets—< >) is important, so include all the marks.

1 type
HELO me
The server will respond with 250 OK and possibly identify your IP address and your host name.

2 type
MAIL FROM: someaddress@somedomain.com
Again, the server will respond with 250 OK.

3 type  
RCPT TO: nobody@afakedomain.com
The server will respond with 550 Relaying prohibited.

Using a valid address from your GAL, type
RCPT TO: thegaladdress@yourdomain
The IMS will reply with 250 OK when it accepts the address.

To close the session, type
QUIT


If you do not get the 550 RELAYING PROHIBITED message, you need to try again.


Hope this helps,

Corie

that will stop the relaying but his pop accounts won't be able to authenticate and logon.

I'm having a similar problem.. I have made sure of all those settings, but now I'm getting spammers who are typing abcd@mydomain.com and trying to send spam that way.  

Below is taken from the log file.

12:37 PM 12/3/0312/3/03 12:34:31 PM : A connection was accepted from u1056535.ul.warwick.net.
12/3/03 12:34:32 PM : <<< IO: |HELO u1056535.ul.warwick.net
|
12/3/03 12:34:32 PM : <<< HELO u1056535.ul.warwick.net
12/3/03 12:34:32 PM : >>> 250 OK

12/3/03 12:34:33 PM : <<< IO: |MAIL FROM: <bb5zilaed@yahoo.com>
|
12/3/03 12:34:33 PM : <<< MAIL FROM: <bb5zilaed@yahoo.com>
12/3/03 12:34:33 PM : >>> 250 OK - mail from <bb5zilaed@yahoo.com>

12/3/03 12:34:33 PM : <<< IO: |RCPT TO: <mlegare@mydomain.com>
|
12/3/03 12:34:34 PM : <<< RCPT TO: <mlegare@mydomain.com>
12/3/03 12:34:34 PM : >>> 250 OK - Recipient <mlegare@mydomain.com>

12/3/03 12:34:34 PM : <<< IO: |RCPT TO: <vimal@mydomain.com>
|
12/3/03 12:34:34 PM : <<< RCPT TO: <vimal@mydomain.com>
12/3/03 12:34:34 PM : >>> 250 OK - Recipient <vimal@mydomain.com>

12/3/03 12:34:35 PM : <<< IO: |RCPT TO: <sill@mydomain.com>
|
12/3/03 12:34:35 PM : <<< RCPT TO: <sill@mydomain.com>
12/3/03 12:34:35 PM : >>> 250 OK - Recipient <sill@mydomain.com>

12/3/03 12:34:36 PM : <<< IO: |DATA
|
12/3/03 12:34:36 PM : <<< DATA
12/3/03 12:34:36 PM : >>> 354 Send data.  End with CRLF.CRLF

12/3/03 12:34:37 PM : <<< IO: |Received: from [173.239.220.205] by u1056535.ul.warwick.net SMTP id UNwRco6FIjJRC5; Wed, 03 Dec 2003 21:42:21 +0100
Message-ID: <rx$bzw$v9z$95-p$74-l@qtc.a.dtl.0aq>
From: "Frank Bradford" <bb5zilaed@yahoo.com>
Reply-To: "Frank Bradford" <bb5zilaed@yahoo.com>
To:
Subject: NEW Soma.a Vicodin.n Valium.m Xanax.x ynxkiae ry
Date: Wed, 03 Dec 03 21:42:21 GMT
X-Mailer: MIME-tools 5.503 (Entity 5.501)
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary=".6331A9A619E_A7..26_CCFD"
X-Priority: 3
X-MSMail-Priority: Normal
|
12/3/03 12:34:38 PM : <<< IO: |

--.6331A9A619E_A7..26_CCFD
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable

Many Specials running this week

(Blah Blah Blah normal spam message)

|12/3/03 12:34:38 PM : >>> 250 OK
12/3/03 12:34:39 PM : <<< IO: |QUIT
|12/3/03 12:34:39 PM : <<< QUIT
12/3/03 12:34:39 PM : >>> 221 closing connection


** These recipients are not vaild on my servers nor exchange server.  So they are coming back as invaild addresses.  This then creates a ton of NDRs, i've gone through and disabled them.  But they still fill up the outbound queue.  Since the outbound queue is getting backed up this prevents any normal outbound messages from being delivered.  How can I stop this on my server?**

Your server will accept everything to your domain including false addresses.  Your only options are to turn of NDR's in Exchange or find a 3rd party software where you can plug in just your valid addresses on your exchange server or upgrade to Exchange 2003 which now allows this and some other filtering.

Try Open Relay Filter from Vampsoft, it can work with AD and prevent SMTP sessions to non-existing users.

But isn't the open relay filter only work with 2000 and higher?  I'm running 5.5.

Ignor the previous post, I found the information on the vampsoft site talking about using the program with 5.5.  But one other question, I've been seeing others talking about exchange verifying the recepients address by looking at the GAL list?  Where is this setup within exchange?  If I could prevent messages from coming in to users who aren't on the list, this would help reduce my problem.

Thanks,
Sean

Are you hosting your own smtp mail or are you using pop3 connector?

I'm hosting my own.

Now I'm also on Spamcop.net's blacklist.

I migrated completely to Exchange 2003 last night & managed to find the \backup account in question, it was actually a old BackupExec service account that was set up on one of our remote branches (Trusted Domain with VPN access). I've disabled the account now & no new mail seems to be coming in but I've still got this MASSIVE queue to empty.

Does anyone know of any quick ways to get off of everyones blacklists?

Nuerodancer

go to  www.winnetmag.com and search out document id 7696.
Follow all steps that start after heading Making the changes to the letter (in the last paragraph there is a section that refers to checking a box in the routing restrictions DO THIS!! it will cause the MTA to check the local GAL for local delivery) Microsoft fails to mention the last point.

Test it with Confirming the configuration section of the document > Important!!
Once you confirm and get the same results and pass the telnet test then visit the site below.  Key in ip address of your server and search.  you will have to visit each and every site and request removal from open relay and dns blacklists.

http://www.openrbl.org/

I've read Doc 7696 on winnetmag.com and have made sure that the settings are correct.  But when I do test for seeing if GAL is being check, if I type blah@mydomain.com it still comes back with 250 OK message.  

I need 5.5 to basically reject a message that is being sent to a vaild recepient.  Maybe this isn't possible with 5.5.

Thanks,
Sean

I have solved this, at least temporarily, on my system. I used the tools mentioned here, and one important additional idea. You may need to know our system configuration.

We host our own email server, but not our web site. We do NOT use OWA for outside emails. Our remote folks authenticate using ports 110 and 25 for the mail server.

Our firewall had been allowing port 80 to be used by the spammer to put outbound emails on our Exchange system. I don't understand how they could have done this using port 80, but read on. So, I closed port 80 from all traffic initiated from OUTSIDE our network. Anything that is initiated from INSIDE our system OUTBOUND goes without a hitch. However, anything that ORIGINATES from an external IP address is refused and effectively killed.

We've been spam free for the past 2 days now, and it was like I flipped a switch. There are no longer thousands of emails in the outbound queue. Only those that have JUST been sent by our authenticated users.

The disclaimer is this. It may not work for you as well as it did for me, but this is just another way you can try to stop the flood...

Hope this helps someone.....

hi
i have the same problem with alot of outbound from my exchange server 5.5.  i have already removed few thousand queues.  however now i am facing the worst situration. it is that the internet mail service failed to start.  which means i cant even get into the queue in the internet mail service at all.  i cant remove queues anymore and there is still alot of outbound via the exchange server according to the Microsoft Exchange Server IMS Queues status chart.  can anyone help please help me out??  i tried everything to bring up the internet mail service such as, change administrator password, disable unuse accounts, reinstalled windows service packs and reinstalled exchange server 5.5 service packs 4.  none of them help at all.  how i just sit here and hope anyone could help me to clean up the queue.

HELP~~~~

What error is showing up in your event log?
If you're getting error 4003 or 4020, do this:

RESOLUTION
To resolve this behavior, remove the TCP/IP protocol, reinstall the TCP/IP protocol, and then reapply the latest Microsoft Windows NT 4.0 service pack and the latest Exchange Server 5.5 service pack:
1 On the Windows taskbar, click Start, point to Settings, and then click Control Panel.
2 In Control Panel, double-click Network, and then click the Protocols tab.
3 In the Protocols properties page, click TCP/IP Protocols, and then click Properties. Record the settings from the TCP/IP properties page.
4 In the Protocols properties page, click TCP/IP Protocols, click Remove, click OK, and then restart the Exchange Server computer.
5 On the Windows taskbar, click Start, point to Settings, and then click Control Panel.
6 In Control Panel, double-click Network, and then click the Protocols tab.
7 In the Protocols properties page, click Add, click TCP/IP, and then click OK.
8 Configure the TCP/IP protocol, using the settings you noted in Step 3, and then restart the Exchange Server computer.
9 Apply the latest Windows NT 4.0 service pack and the latest Exchange Server 5.5 service pack. Restart the Exchange Server computer.
10 If IMS does not restart, in Control Panel, double-click Services, click Microsoft Exchange Internet Mail Service, and then click Start.


Also, there seems to be a problem with Exchange SP4.
This article gives more info.
http://support.microsoft.com/?kbid=279798

hope this helps!

Corie

thanks tahoe2!!!

i am going to try those steps see if it help.  well..  let me explain more.  it tries to start the service but it hung during the startup.  and i have tried to start the service in contral panel -> service.  it takes like 5 mins and then came out the error.  even if i remove the IMS in exchange administration.  and reinstall it, then it will try to start the service during the IMS installation.  it also hangs in that step too..   let see your steps will help or you have a better idea of fixing this??

thanks.

I had to get the fix from MS to help me resolve the issue. For several weeks, the Internet Messaging Service wouldn't start when the server was restarted (Event log error 7001). It would take me an hour of shutting down and restarting various services before it would start, and finally one day, nothing I did would start the service.
I got the patch from MS and no more worries. I hope it's that easy for you!

Corie

oh.. nice..  thats exactly what happen to me here.  so can you give me the link for that patch?  i hope it wont take me few days for this problem.  i will be dead for that much of time..  thanks again tahoe2.

Hi All,

I had faced the same problem earlier of getting tons of mails in IMC queue and IMC not getting started after rebotting the server but now I had got it fixed. Solution in my case is :

During installtion of WinNT for our Exchange Server we had left the loacl admin password blank. After changing this password we are not facing this problem.

Just check if u had done the same.

Best of Luck.

PSingh

hi all, I think I've found solution. I don§t know where is it from, but it really works. If you can't find patches mail me: banovec@nbc.sk

RE: Sara's Comment...I have tried all the options given and suggested in the forum and in the article and I still can't stop relaying in Exchange 5.5 SP4 (we use POP3 and IMAP4)...

Well, Sara found the fix and helped me out as well. I did not have to apply all these fixes myself, as we do not need to relay at all. However, for most of you who do, here's the fix:

First, for those that don’t have a need to relay, don’t. Select “Do Not Reroute Incoming SMTP Mail".

If you realize you need to allow relaying, I suggest going through the fix I sent:

Must backup first. Then install (or reinstall) Exchange 5.5sp4 followed by:

1. 09/04/2001 01:01 AM 1,624,280 Q289606engi386.EXE
2. 08/06/2001 01:01 AM 567,680 Q301361i386.EXE
3. 19/07/2001 01:01 AM 7,162,240 Q304062engi386.EXE
4. 09/08/2001 01:01 AM 3,209,600 Q283238engi386.EXE
5. 05/09/2001 01:01 AM 588,176 Q307195engi386.EXE
6. 22/10/2001 01:01 AM 1,153,408 Q289258engi386.EXE *
7. 05/12/2001 01:01 AM 1,218,960 Q313576engi386.EXE
8. 16/05/2002 01:01 AM 1,161,560 Q312273engi386.EXE

Go to http://support.microsoft.com/default.aspx?scid=fh;en-us... and down the bottom of the page, enter the name of the .exe file, and you will find a patch to download.

You must apply them to your Exchange server in this order.

[Of the 8 files to download and install, all are available except the 6th one. When you go to the Q Article it says to contact Microsoft for it and obviously you have to pay. Go around that by downloading Q289258engi386.EXE here: http://online.securityfocus.com/bid/4205/solution/ (free to download).]

Once this is done and reboots are complete. Go to Connections, Internet Mail Connector, Routing, and make changes accordingly.

The changes I made to my routing restrictions were to allow Hosts and Clients that Authenticate, and also Hosts and Clients with these IP Addresses (with the IP and the Mask in the box). I looked through my logs in “imcdata” and found that it was sending “550 Rerouting is Prohibited” messages to people who were attempting to use my exchange server.

In regards to the mail queues, you will need to delete those occasionally because sometimes they still manage to connect to your server and will attempt to send mail, and it gets refused, but it will sit in queues. Just delete the queues when you remember. You'll probably find a lot of them come from an originator with "<>" as the name. I also suggest turning up your Diagnostic Logging up to the maximum for all the options, just for a few weeks. It can take up a bit of space, but it's worth going to the “imcdata” folder and having a look to see if Exchange doing what it's supposed to be doing.

Don't forget you have to apply those patches in that order...otherwise it won't work, some of the preceding ones have bugs and applying the patches in order fixes the previously installed bugged patches!

I have the problem with getting a ton of messages in my oubound queues from <>.  It seems these are coming from the exchange server itself as replies for non delivereable recipients.  Someone was spamming our servers and the exchange server was just replying to them that there was no such mailbox.  We turned on accept only mail from approved senders and the messages decreased immediately.

use steps in my previous post and then install:

09 - Q326322enui386.EXE                07/24/2002
10 - Exchange5.5-KB818709-x86-enu.EXE         08/02/2003
11 - Exchange5.5-KB829418-x86-enu.EXE        10/07/2003
12 - Exchange5.5-KB829436-x86-enu.EXE        10/13/2003
13 - Exchange5.5-KB828489-v2-x86-enu.EXE    10/21/2003

now Exchange 5.5 shouuld be patched...

I'am doing this treatment :
Open Internet Mail Service in Exchange Administrator, click on the routing tab and make sure your setting is REROUTE INCOMING SMTP EMAIL.
'Sent to' should be YOURDOMAIN.COM and 'route to' should be INBOUND.
Then click on ROUTING RESTRICTIONS and UNcheck the box next to 'Hosts and Clients that successfully authenticate'
and CHECK the box next to 'Hosts and Clients with these IP Addresses:'.  LEAVE THAT BOX BLANK!

restart the IMS, and everything back normally!!!!

aeh, me too solve the problem with your treatment
did u understand why it works?

this log was find after the treatment:
Refused to relay <benteski@netzero.net> for 23397.bhz.virtua.com.br (200.167.233.97).  Client was authenticated as \backup.

what is \backup?

\backup is the local account the hacker is logging in as. Check your machines. find and disable this account.

This process works because you are essentially closing all relay doors by allowing only certain addresses, but adding no addresses to the sucessfully authenticate area.

Hope this helps,
Corie

Hello you have an open relay.  Go to www.winnetmag.com and search for document id # 7696
Do all things and ensure you do the telnet test to make sure you have set it right.
As well you may notice that you will be blacklisted on DNS and email lists due to this problem.  Correct it as fast as you can
peace.

Excerpt from the winnetmag article
"What the Microsoft article and online Help don't spell out is that when you select a routing restriction, you can choose not to enter any IP information. The trick is that you can select the Hosts and clients with these IP addresses check box but not specify any IP addresses. Unless you have a specific need to have your Exchange server relay, don't enter any IP addresses on this page. This selection changes the rules that the IMS uses when evaluating the SMTP protocol. Instead of letting the IMS accept the RCPT TO specification blindly, this selection causes the IMS to check for local delivery before letting it upload a message. If the recipient isn't local, the IMS will return 550 Relaying prohibited"

lol had to do it :)

I know this is a litle late because you probably have your problem solved by now but if you still need a little help and have a little money to spend try the Barracuda Spam Firewall.  I was having the same problem with the message queues getting thousands of messages a day and since I installed the Barracuda that has stopped.  It also has a lot of other great features that are helpful in the age of spamming.