Event ID/Source search
Keyword searchExample: Windows cannot unload your registry file
Event ID: 7004 Source: MSExchangeTransport
This is an SMTP protocol error log for virtual server ID 1, connection <connection>. The remote host "<host>", responded to the SMTP command "<command>" with "<error details>". The full command sent was "<full command>". This will probably cause the connection to fail.
|English: This information is only available to subscribers. An example of English, please!|
ME818222 worked for me. I was seeing a lot of 7004 errors with the XEXCH50 issue and outbound email stuck. I followed method #2 in the article and restarted the SMTP queue and email started flowing. Note that the method #2 steps are wrong for my Exchange 2003 SP2 server. The SMTP options mentioned are under Routing Groups and Connectors, not under Admin Groups as written.
This is a generic message recorded by the SMTP server component when it received a response from a remote SMTP server that indicates some type of problem with the email message it tries to relay. There can be many reasons for such a transfer to fail. The "full command" sent and the SMTP command that the remote server "responded" contain the relevant information about this problem and the next steps in troubleshooting this should be based on these command, especially the response from the remote server.
For example a response like "550 5.7.1 Unable to relay for ....<user email here>" indicates that the remote server is configured to reject any relay for that particular user and perceives this command (such as RCPT TO: ) as a relay attempt and in consequence will not accept the message.
I noticed this problem after upgrading an Exchange server from 2000 to 2003. Only mail sent to external exchange servers was affected. In highlighting the solution, it is helpful to outline the process that occurs when an Exchange Server 2003 or Exchange 2000 Server-based server tries to send mail to a host over the Internet.
1. It performs the equivalent of an Nslookup for the MX (mail exchanger) record of the remote domain.
2. It opens a TCP/IP connection to port 25 of the remote host.
3. It receives a banner from the remote host.
4. It sends an EHLO command followed by the local domain name to the remote host.
5. It receives a list of supported commands from the remote host.
6. It sends a MAIL FROM command followed by the e-mail address of the sender.
7. It receives an acknowledgement from the remote host.
8. It sends one or more RCPT TO commands followed by one or more recipient e-mail address.
9. It receives one of the following acknowledgements:
- One acknowledgement after a batch of RCPT TO commands if the remote host supports PIPELINING.
- One acknowledgement for each recipient.
10. If the remote host advertised support for the XEXCH50 command, the Exchange server sends the XEXCH50 command followed by the number of bytes that it intends to transfer, and then the numeral 2. For example, the following command indicates that the Exchange server intends to send 1124 bytes of data: XEXCH50 1124 2
11. It receives a 354 message from the remote host permitting it to send the data.
12. The Exchange server sends the number of bytes of data that it specified in step 10 of this process.
13. When the data has been sent, the Exchange server expects the remote host to immediately respond with an acknowledgement. If there is no more mail to send, the Exchange server sends a QUIT command.
14. The Exchange server receives an acknowledgement of the QUIT command from the remote host.
15. The Exchange server ends the session.
In this case, the remote host is an exchange server who advertises support for the XEXCH50 command and responded to the SMTP command "xexch50" with "504 Need to authenticate first". By Configuring the XEXCH50 registry subkey, we can suppress the sending of the XEXCH50 command to external domains and resolve the problem. To do so, follow these steps:
1. Click Run, type regedit in the Open box, and then click OK.
2. Locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\XEXCH50
Note If the XEXCH50 registry subkey is not present, create it. To do this, point to New on the Edit menu, and then click Key. In the New Key #1 box, type XEXCH50, and then press ENTER.
3. Right-click XEXCH50, point to New, and then click DWORD Value.
4. In the New Value #1 box, type SuppressExternal, and then press ENTER.
5. Right-click SuppressExternal, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Quit Registry Editor.
This information is pretty much a rehash of information found in ME818222.
I found that this was caused because I had the local domain name and not the publicly advertised name in the Fully Qualified Domain Name field of the SMTP server Delivery Advanced properties. As an example, my local domain could be Company.local, I had the Fully Qualified Domain Name field of the SMTP server MyServerName.Company.local. My ISP has my mail server advertised as mail.Company.Com. So when I put mail.Company.Com in this field it worked. The problem only occurred when I sent mail to an Exchange server. Mail to non-Exchange SMTP servers worked fine.
This problem occurs when the following conditions are true:
1.The server that is running Exchange Server 2003 has SMTP virtual servers that have a Fully Qualified Domain Name (FQDN) that does not match the server name.
2.The FQDNs for the SMTP virtual servers do not have a Service Principal Name (SPN) registration.
See ME914137 to solve this problem.
See ME925447 for additional information about this event.
According to Microsoft’s explanation, if you have Symantec AntiVirus Corporate Edition 9.0 installed on Exchange 2000 or Exchange Server 2003, and the Internet E-Mail Auto-Protect feature is enabled, this will happen.
By disabling the Internet E-Mail Auto-Protect feature of Symantec Antivirus Corporate Edition 9.X, messages can be delivered out.
As per Microsoft: " This issue may occur if the computer that is running Exchange 2000 or Exchange 2003 is listed as a messaging server that sends unsolicited commercial e-mail (UCE, also known as spam). This behavior may occur if the computer that is running Exchange 2000 or Exchange 2003 is an open mail relay". See ME843106, and ME895853 to fix this problem.
See ME821910 for information on how to troubleshoot for Exchange Server 2003 transport issues. See MSEX2K3DB for more details on this event.
From a newsgroup post: "This is an alert that a host has tried to pass an XEXCH50 command without passing authentication credentials first. The XEXCH50 command is normally only issued between Exchange servers in the same organization. If this is coming from an outside host, someone may be trying to implement a denial of service attack against your server. If you have not already installed the September post-SP3 rollup package for Exchange 2000, you may want to consider doing so".
From a newsgroup post: "If the only problem you are seeing is that XEXCH50 is being denied in some cases, but there is no mail flow problem, it sounds like everything is ok as long as XEXCH50 is only being denied from servers outside of your Exchange Organization and mail is still being received.
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. In this respect, Exchange 2003 behaves differently than Exchange 2000. Within a single Exchange organization, Exchange setup takes care of ensuring that all Exchange servers have the necessary "Send As" right on all of the SMTP virtual servers, through the ACL on the Exchange organization object in the AD which inherits down to all of the SMTP virtual server objects. Because of this, the XEXCH50 command should be properly sent and received between servers within a single Exchange organization. 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 are 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 are seeing this between servers in different Exchange organizations, it is normal expected behavior, and should not actually block mail flow. 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 to send their message data".
|Private comment: Subscribers only. See example of private comment|
|Links: ME818222, ME821910, ME843106, ME895853, ME914137, ME925447, Exchange 2000 Post-Service Pack 3, MSEX2K3DB|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (1) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated