windows server 2003 sbs event id 7010

Can look at this MS KB error to add the "SuppressExternal" value to the registry.

Additional symptoms that may accompany Event IDs 7004 and 7010

If the XEXCH50 command is not working correctly, as indicated by the 7004 events and by the 7010 events, you may see the following symptoms:...

The short summary is that the XEXCH50 verb, which is part of an Exchange-to-Exchange extension to SMTP, is sometimes tripped up by an intermediate firewall attempting to perform deep-inspection filtering on an SMTP connection. It gets confused and aborts mail delivery even though the Exchange servers would have been happy to talk to each other.
But even without firewall issues, Exchange logs an error in the Event viewer when the verb is used even though the mail goes through just fine. This is cluttersome.
Because this SMTP command word doesn't seem to be of any use in an SBS environment (it's rare for there to be two Exchange servers in an this kind of enterprise), turning this keyword off avoids the whole issue.

Note You will see Event IDs 7004 and 7010 only if you turn up diagnostic logging on the MSExchangeTransport event source to medium or higher.

The short summary is that the XEXCH50 verb, which is part of an Exchange-to-Exchange extension to SMTP, is sometimes tripped up by an intermediate firewall attempting to perform deep-inspection filtering on an SMTP connection. It gets confused and aborts mail delivery even though the Exchange servers would have been happy to talk to each other.

Hence it seems like "DoSing" your open SMTP server via "brute forcing" virtually .. but this can get worse when deep-inspection firewalls are involved: those that attempt to parse the SMTP conversation can be tripped up by the nonstandard XEXCH50 keyword. E.g. the firewall may decide to "fail closed" on a protocol violation rather than let unknown and possibly dangerous traffic through.

Furthermore, this only applies to direct Exchange-to-Exchange communications: sites that use third-party mailfiltering systems (such as Vlad's excellent Exchange Defender mail/spam filter service) won't have this direct connection, and are unlikely to ever see this issue arise.

for that "something" worth putting it to VirusTotal, ViRSCAN or Jotti for malice scan, maybe good to trace Source IP but it can be spoofed though. The FW and SMTP gateway should filter that IP for that instance if it is from single one..

Some reference
http://community.spiceworks.com/windows_event/show/152-msexchangetransport-7010

I read the above. This is the exact wording from the event id 7010 I do not get event id 7004

This is a SMTP protocol log for virtual server ID 1, Connection #95042. The client at "118.168.118.8128" sent a 'rcpt' command and the SMTP server responded with "550.5.7.1 Unable to relay for sally 5965319@yahoo.com.tw" The full command sent was "rcpt TO: <sally5965319@yahoo.com.tw>". This will probably cause the connection to fail.
screen-shot-7010-error-MSechange.doc

Based on the IP address that is already in some Blacklist - spambot type
https://www.robtex.com/ip/118.168.118.192.html

Likely it has poor reputation may have been caused by one of the following reasons:

Your email server contains a virus and has been sending out spam.
Your email server may be misconfigured.
Your PC may be infected with a virus or botnet software program.
Someone in your organization may have a PC infected with a virus or botnet program.
You may be utilizing a dynamic IP address which was previously utilized by a known spammer.
Your marketing department may be sending out bulk emails that do not comply with the CAN-SPAM Act.
You may have an insecure wireless network which is allowing unknown users to use your network to send spam.

The email is legit account but that doesnt mean it is used for legit purpose - minimally this is not via some open relay http://mxtoolbox.com/SuperTool.aspx?action=mx%3asally5965319%40yahoo.com.tw&run=toolpage#

and the "550.5.7.1 Unable to relay " is normally due to some software in that host trying to email relay - of course we would not know what service is running from that 'spambot'
-  a transport rule that prohibited service accounts from sending external email
- receive connector required TLS security, which was unchecked

e.g. http://social.technet.microsoft.com/Forums/en-US/48e11291-9484-4cb3-a131-1764f6ec6bdc/mail-relay-throwing-error-550571-unable-to-relay-for-domain

how do you find and get rid of spambot?

the email server should have some sort of anti-spam mechanism to deter spambot coming in to relay spam emails and email exchange relay (where possible) should not be open type whereby without any access control list and even allow ill reputed relays

for end user machine, it is more of scavenging which is the infected one but then the 'something' left behind may have already spread to many or targeted part of the network in your work enterprise. the machine host intrusion protection (HIPS) should be scanning it for any anomalous symptoms - see a discussion on (maybe) similar encounter

http://www.symantec.com/connect/forums/need-help-email-spambot-problem-infected-and-cant-find 

for more "holistic" strategy, I encourage you check out this CBL article which also stated tools http://cbl.abuseat.org/advanced.html

Most infections "drop" their malicious programs in Windows "system" directories. For example, the interesting directories on Windows/XP are C:\windows\system and C:\windows\system32.

It's often possible to see these programs by navigating to the system directories, switching to the "detailed view" and then sorting by date. There is a good chance that the malicious software on your machine was created within the past 30 days. If you find programs in these directories that are that young, and aren't explainable by a new software install or patch:

Google for the file name. You may find a web page from a reputable A/V vendor telling you what it is, whether it really is an infection or a legitimate program, and how to remove it if it doesn't belong.
Run a series of A/V tools to try to remove them.
If none of the above fixes the problem, you may have to reinstall the machine.

With a sniffer, you can try looking for outbound connections to unusually high numbered ports (eg: >10,000). In small environments, you could get everyone to shut down their web browsers, and watch for port 80, 8080, and 443 (all web based) connections when they shouldn't be made. If you find web connections when the source of the connection doesn't have a browser or mail reader running, there's a good chance you've found the infected machine - the machines to first run a toolkit tool like tcpview on.

In a relatively small environment, you may get a "feeling" for the IP addresses the sniffer is showing you as the destination. Eg: if you're in North America, seeing connections to IP addreses beginning with 200, 201, 202, 203, 59, 88, 89 etc, will mean that the computer is making connections to Asia or Europe. Especially if the local computer is idle, why is it making connections there? Again, a job for tcpview.

This means that a BOT sending lots of spam will do lots of MX queries. If you find a end-user computer or some other computer that shouldn't be doing email at all doing MX queries (especially lots of them), you've found the infected computer[s].

If you have your own DNS server (eg: a DNS cache), you should be able to get the DNS server to give you basic statistics of who is issuing MX queries to them. If you don't have your own DNS server, you could look for unusual sources of DNS MX queries via a sniffer. It may be easier to sniff all DNS traffic going to your DNS server than your firewall.

In summary of prev post key is also to stop the spam if ongoing or going to come again.
a- set your firewall to not allow outbound SMTP/POP except from the email server.
b- set your mail server to not allow outbound relay.

Then, you need to find the problem machine(s).
1- Look at the firewall logs to see which machine(s) are actually trying to do outbound mail and getting blocked. Those machines are infected.
2- Make sure each machine has current A/V, and do a thorough scan on each machine.
3- You may want to implement the Windows Firewall on each machine.
4- If still not found you will need to use a sniffer.

Which Sniffers do you recommend?