Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 7010 Source: MSExchangeTransport

This is an SMTP protocol log for virtual server ID 1, connection #<connection number>. The client at "<ip address>" sent a "<command>" command, and the SMTP server responded with "<response>". The full command sent was "<full command>". This will probably cause the connection to fail.
I had been getting this same error and complaints from an e-mail sender that we were rejecting their sent e-mails. After reviewing the SMTP logs on my Exchange 2003 server, I found that the sending host was not using their FQDN to begin a session (EHLO) with our server, instead, they were using their internal domain host name (default setting). This resulted is some very bizarre behavior, whereas, plain text messages would get through, but HTML and e-mails with attachments would be intermittently denied.
- Command: rcpt, response: "501 5.5.4 Invalid Address" - See ME925447 to solve this problem.

As per Microsoft: "This event is logged when the Exchange server sends an SMTP command to a remote server and receives a response that is not valid. The virtual server ID indicates which SMTP virtual server issued the command. The remote host indicates the fully qualified domain name of the remote server that responded to the command. The actual command issued, and the response received, are also mentioned in the event.

Possible causes for this event include faulty network card drivers and network cards that are configured incorrectly". See MSEX2K3DB for additional information about this event.
We had this problem in a front-end back-end exchange environment. The front end server is the relay for POP3, IMAP4 and SMTP. It just stopped authenticating SMTP for no apparent reason after working perfectly for the previous 18 months. The solution was to restart the IAS service on the authenticating back-end server.
In our case, we had just changed to a new ISP when many mail servers started rejecting mail from us. It was not a relay issue since the recipients were mailboxes on the servers we were talking to. It turns out that our new ISP had no PTR (Reverse DNS) entry for our new public IP address and many servers now require this to help weed out spam sources. I called the ISP who put in an entry like PTR
Now when those receiving mail servers do a lookup on the IP address that our packets are coming from, they get something that includes our domain name. Having done this we get no more 7004 errors and mail flows to the domains that were bouncing us.
ME895853 provides information on how to troubleshoot mail relay issues in Exchange Server 2003 and in Exchange 2000 Server.
- command: xexch50, response: 504 Need to authenticate first, full command: xexch50 976 2
From a newsgroup posts:
- "Your server is talking to another Exchange server and it tried to send the XEXCH50 command. Your server, quite correctly, refuses to accept that command from from unauthenticated connections.
Since you cannot stop your server from advertising the XEXCH50 keyword in response to a EHLO command there's nothing to be done."

- "Exchange 2003 only accepts XEXCH50 protocol data from clients who authenticate and have been granted "Send As" permission on the receiving SMTP virtual server object in the AD. It is expected that Exchange 2003 will block inbound XEXCH50 data from other Exchange organizations by default, and in this regard the fact that it is responding with "504 Need to authenticate first" is actually correct, if the remote server is not part of the same Exchange organization.

If you're seeing this between servers in the same Exchange organization, that is potentially an authentication or ACLing problem that should be looked into. You can use ADSIEdit.msc to investigate the ACLs of the Exchange objects in the configuration container if you suspect that the necessary Exchange server security groups have not been granted the Send As access that they need on the SMTP virtual servers.

If you're seeing this between servers in different Exchange organizations, it is normal expected behavior, and should not actually block mailflow.

When Exchange 2003 rejects an inbound XEXCH50 attempt, it allows the client to continue without the XEXCH50 data. When Exchange 2000 or 2003 attempt to send an XEXCH50 command and are denied, they continue to try and send their message data."

- command: helo, response: 501 5.5.4 Invalid Address, full command: "helo <host name>"
From a newsgroup post: "This problem may occur if the sending server is not in accordance with the Request for Comments (RFC) 821 and RFC 1869 documents. The receiving Exchange computer expects either a host name only or a fully qualified domain name (FQDN) following the EHLO/HELO command. See ME291828, "501 5.5.4 Invalid Address" error message from a sending UNIX server."

An example of host name that may cause this kind of problem is "". The trailing dot after .ca is not accepted by the Exchange server. See ME291828 for an workaround this issue.

From a newsgroup post: My server was sending "lhr-mail (Internet FAX)" as host name in the "helo" command. I solved the issue by removing the host name from the configuration file on the smtp document scanner. According to Panasonic, this is a known issue and they instruct Exchange users not to use the host name parameter.

- Command: xexch50, response: "504 Need to authenticate first" - See ME843106 to fix this problem.
- command: rcpt, response: 550 5.7.1 Unable to relay for <email address>, full command: "rcpt to: <email address>" - This indicates that someone tried to relay email through your server.

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to



Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.