While many an admin can probably work for years without having to look at an SMTP log or network trace, they wouldn’t be email admins. As email admins sharpen their troubleshooting skills, learning the standard SMTP codes that are a part of every data exchange between servers will not only make parsing logs faster, it can help resolve issues with something as basic as a network trace.

The current RFC for the SMTP protocol is 5321. It defines all of the protocol exchanges between servers, and assigns a numeric response code to each. While vendors might implement their own text responses for a particular purpose, the numeric codes will be consistent across platforms.

Recognising the codes, and the pattern they exhibit during normal email transfers will not only help you validate that a server is functioning, but quickly identify when a server is not. In my post  Using telnet to test your mail server I cover the normal way that email servers transfer mail. You can click that link to get more detail, but here’s a brief recap.

220-You’ve made a connection
250-Your input is acceptable
354-The server is ready to accept your message
221-Your connection has closed

You will see those codes in an SMTP log, but sometimes, a log doesn’t show everything you need to resolve an issue. Remember, the numeric codes are standardised by the RFCs, but vendors can do practically anything they want with the text that accompanies the code. I once ran into a problem sending email to a remote recipient whose mailbox I knew was on the remote system, but I kept getting a 550 response back. A 550 means “Requested action not taken: mailbox unavailable.” Extended logging showed me a 5.7.1, and that usually indicates a “Relay not allowed.” Again, knowing the destination was local to the server that was bouncing my messages, the logging seemed to be pointing me in the wrong direction. Using WireShark to take a network trace, I finally saw what the destination server was saying

The IP you’re using to send mail is not authorized to 550-5.7.1 send email directly to our servers. Please use the SMTP relay at your 550-5.7.1 service provider instead. Learn more at 550 5.7.1 http://mail.google.com/support/bin/answer.py?answer=10336 j1si6349282ybe.14 ##

And that helped me resolve the issue. Without knowing the response codes, and that what they indicated was not valid, I would never have taken a trace, and would never have seen the response message. You can read more about that here if you are curious. However, if you have limited time, spend it learning the table below. These are the codes that you need to know when debugging SMTP.

Be Sociable, Share!

•