We receive our mail through our ISP. However some of the mail is stuck in their queue with the following error message "status=deferred (conversation with x.x.x.x timed out while sending RCPT TO. this is only for some users though and not all. i am also getting the following error in event viewer "source: MSExchangeTransport. category: SMTP Protocol. eventID 7010 Description: This is an SMTP protocol log for virtual server ID 1, connection #30. The client at "6.5.2.4" sent a "xexch50" command, and the SMTP server responded with "504 Need to authenticate first ". The full command sent was "xexch50 1092 2". This will probably cause the connection to fail.". i have tried the solutions provided on the Microsft Support website but they are not working. does anyone have any ideas.

The XEXCH50 means that Exchange thinks it is communicating with another Exchange server. Do you have anonymous authentication enabled on the Receive Connector? Any pattern between the email? Is it always email for the same users who cannot receive email? Exchange doesn't really care as long as it is an SMTP traffic flow. What else is on the server? Anything scanning SMTP traffic? Firewall, AV, antispam etc. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Hi Simon We do not have any connectors but we do have anonymous authentication enabled on the SMTP Virtual server. There about five users not able to receive mail from certain domains but not all. The server has no antispam but does have an AV ( I asume that is antivirus). Nothing is scanning SMTP traffic. There is a firewall but it is configured to pass through all SMTP traffic. I would Appreciate any help. Siku

For this issue "This is an SMTP protocol log for virtual server ID 1, connection #30. The client at "6.5.2.4" sent a "xexch50" command, and the SMTP server responded with "504 Need to authenticate first ". The full command sent was "xexch50 1092 2", you can refer to this document: How to troubleshoot the "504 need to authenticate first" SMTP protocol error http://support.microsoft.com/kb/843106 Thanks, EvanEvan Liu TechNet Community Support

Hi Evan, I already tried that kb article before I posted to the forum. The proposed solutions did not help. The problem still persists.

Hi, Can you enable pipeline tracing of e-mail messages, please find the below URL what does the pipeline tacing will do and how to enable it for specific user or organization wide. Pipeline tracing is a diagnostic feature in Microsoft Exchange Server 2007 that enables you to capture diagnostic information about e-mail messages as they encounter transport agents registered on Simple Mail Transfer Protocol (SMTP) events in the transport pipeline. http://technet.microsoft.com/en-us/library/bb125198(v=exchg.80).aspx http://technet.microsoft.com/en-us/library/bb125018(v=exchg.80).aspx Thanks

Hi, We are using Exchange 2003. Can pipeline tracing be enabled in this environment? From the little reading I have done it seems to have been introduced in Exchange 2007.

Yeah you are correct , pipeline was for 2007 only, as you have 2003 so i hope you have enabled the Diagnostic Logging - Exchange 2003's ultimate tool for troubleshooting email problems. Once you set Diagnostic logging, then you can collect extra information about any of the Exchange 2003 services, for example, MSExchangeTransport, SMTP. Pls find the URL which helps you to enable the same - http://www.computerperformance.co.uk/exchange2003/exchange2003_logs_diagnostic.htm Apart from this is your server patched recently , since how long your are facing this issue ? below URL having the same issues and seems to they also tried the same above mentioned KB which did not helped much but this one helped those guys so just check if you have the availablity of the same - http://support.microsoft.com/kb/885881/ Similar threads :- http://objectmix.com/microsoft-exchange/267156-event-id-7004-70006-7010-504-error-xexch50.html http://www.exchangeserverhelp.com/showthread.php/12662-SMTP-EventID-7010-xexch50-504-occur Thanks

The Exchange server will not be logging anything because until the email is actually delivered to your server, it is not under the control of Exchange. Message Tracking would show what is happening once the email has been delivered, but until that point, there is little that you can do - it is down to the other side to demonstrate the failure. Any reason why you are not having email delivered direct to the Exchange server? Have you munged the IP address? As 10.10.1.4 is not a valid internet IP address. Is that the IP address of your server? Do you have something between Exchange and the internet that accepts the email? Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Hi Simon, The reason why I am not having mail delivered directly to our servers is that mail was failing to come through for about five of the users in the domain. With mail being accepted by our ISP at least there is no NDR and the mail will be delivered once the problem is corrected. Also that was how I was able to obtain the error message pointed out above. The IP address is made up. We have a router between the exchange server and the internet. I am able to track the conversation our server holds with other servers when sending and receiving mail, using IIS and enabling logs. From the log files I can see that it does not resond to servers once the problem usernames is sent. This only happens to particular users in the receiving domain. Is there any way I can find out why it remains quiet? Could this possibly be a malicious script?

Has it ever worked for those five users? Have you attempted an internal telnet test to try and deliver email to those users? Anything unique about those users that is different to everyone else? Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

It used to work for the five users. I have attempted a telnet an internal telnet and it has worked. They are able to receive mail. The problem seems to be for specific users in the receiving domain. For example she/he can receive from pat@domain.com but not ted@domain.com. There are no individual settings on the exchange server or AD that has been done to the users. Is it possible for them to block the users from the client machines in outlook and thereby stop exchange from receiving the mail?

On Sun, 15 Apr 2012 16:18:48 +0000, Siku_ns wrote: > > >It used to work for the five users. > >I have attempted a telnet an internal telnet and it has worked. They are able to receive mail. The problem seems to be for specific users in the receiving domain. For example she/he can receive from pat@domain.com but not ted@domain.com. I doubt it has anything to do with the individual. If I understand what you've said so far, the SMTP conversation stops once the RCPT TO command has been received. Have you verified that the RCPT TO has been accepted by your Exchange server ? Was a status code sent by your server to the sending server? Use the SMTP protocol logs to verify that the SMTP conversation (at least as seen by your server) is progressing normally. >There are no individual settings on the exchange server or AD that has been done to the users. > >Is it possible for them to block the users from the client machines in outlook and thereby stop exchange from receiving the mail? No. If I've understood your explanations so far the problem lies solely at the SMTP protocol level. Do you have any Anti-Spam software installed on the Exchange server? Is there any device between your Exchange server and the Internet that may be interfering with the SMTP conversation (Cisco firewalls, for example, although that would interfere with ALL users, not just a few)? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Which Cisco router is it? Cisco devices have a feature called FIXUP SMTP or Mailguard which can block certain commands. Notorious for causing email delivery issues with Exchange. The feature needs to be disabled. The problem is so common, Microsoft have an article about it on their own KB: http://support.microsoft.com/kb/320027 Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

On Mon, 16 Apr 2012 09:59:38 +0000, Siku_ns wrote: > > >My exchange server does not respond to the rcpt to. Below is an excerpt of the conversation from the SMTP logs mx.externaldomain.com EHLO #NAME? >mx.externaldomain.com MAIL +FROM:<ted@externaldomain.com> >mx.externaldomain.com RCPT +TO:<ann@mydomain.com> >mx.externaldomain.com QUIT mx.externaldomain.com Okay, what do YOUR SMTP protocol logs show you? You've already established that the sending domain doesn't receive a response to the RCPT TO command, but you haven't demonstrated that the Exchange server receives the RCPT TO command or that it hasn't sent a status code back to the sending server that just didn't get there. >The error message after the external domain has failed to send the message is "conversation with x.x.x.x timed out while sending RCPT TO." Is there any way I can find out why my server just keeps quiet. You don't know that it does! Or, at least you haven't demonstrated that it does. Look at YOUR server's SMTP protocol log and see what's going on. >Would it have something to do with the ehlo instead of helo sent at the beginning of the conversation. Unlikely. >No anti spam software and there is only a cisco router in between the server and the internet. no firewall. It wouldn't be the first time I've seen Cisco screw up a SMTP conversation. But let's see your server's SMTP protocol log before jumping to conclusions. If you see the RCPT TO in your server's SMTP protocol log and you see a status code sent by your server then the next thin you'll have to do is put a network monitor between your router an the Internet and watch the traffic on port 25 to/from the other server's IP address. If your server's SMTP protocol log shows a status code being sent byt you don't see it in the network monitor then it's your Cisco Router. If the status code DOES show up in the SMTP log file AND in the network monitor trace then the problem lies somewhere between your router and the sending server. Good luck involving the ISP with that! One other thing to have the sending server do is to use a network monitor and watch the port 25 traffic for your IP address. If the status code shows up in the network monitor trace then the problem lies with THEIR router/firewall/proxy. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP