The SMTP protocol is fairly complex and attempting to troubleshoot a problem sometimes requires an in depth knowledge of how SMTP works before you can fix the problem. You could read through the SMTP RFC 2821 and probably fall asleep within 10 minutes, so to help diagnose SMTP delivery problems I put together the more important elements of SMTP that can help you diagnose SMTP delivery problems.
Before we get started I have to mention that the information in this post is directly from RFC 2821 and the Full Copyright Statement is included at the bottom of RFC 2821.
http://www.ietf.org/rfc/rfc2821.txt
Common SMTP codes. SMTP response codes include success, intermediate, transient, and permanent responses. The SMTP protocol requires that server/client responses consist of a series of commands that will specify sender and recipient(s) and eventually the delivery of email. Responses are successional, which in my opinion helps when analyzing mail server logs. For example, when an email client makes a connection to the mail server the mail server must respond to the clients connection, after the server responds the client must respond, and so on and so on... receiving or not receiving a response can help isolate problems because of the successional requirement of SMTP.
Code Definitions
2xx codes = Success
3xx codes = Intermediate
4xx codes = Transient Negative reply
5xx codes = Permanent Negative reply
Common Reply Codes in Numeric Order
211 - System status, or system help reply
214 - Help message
220 -
221 -
250 - Requested mail action okay, completed
251 - User not local; will forward to
252 - Cannot VRFY user, but will accept message and attempt delivery
354 - Start mail input; end with
421 -
450 - Requested mail action not taken: mailbox unavailable
451 - Requested action aborted: local error in processing
452 - Requested action not taken: insufficient system storage
500 - Syntax error, command unrecognized
501 - Syntax error in parameters or arguments
502 - Command not implemented
503 - Bad sequence of commands
504 - Command parameter not implemented
550 - Requested action not taken: mailbox unavailable
551 - User not local; please try
552 - Requested mail action aborted: exceeded storage allocation
553 - Requested action not taken: mailbox name not allowed
554 - Transaction failed
Command Reply Sequences. In the sequence example below each command is listed with its usual possible replies. The client connects, the mail server responds (greeting message), the client responds (EHLO name), the mail server responds (250 OK), client responds (MAIL FROM: client@domain.com), etc... The prefixes used before the possible replies are 'I' for intermediate, 'S' for success, and 'E' for error. Since some servers may generate other replies under special circumstances, and to allow for future extension, SMTP clients should, when possible, interpret only the first digit of the reply and must be prepared to deal with unrecognized reply codes by interpreting the first digit only. SMTP servers must not transmit reply codes to an SMTP client that are other than three digits or that do not start in a digit between 2 and 5 inclusive.
Specific sequences are:
Conclusion. Using the sequences above and referencing them to your SMTP logs will provide you with a guide to what type of failure occurred, at what point in the SMTP session it failed, and whether the SMTP session completed successfully with the QUIT command.
Why is it important to know when the failure occurred? Most mail servers have a host of security features that are implemented at certain command sequences, for example, after the MAIL FROM command your mail server may run ESMTP size checks, rDNS, MX record check, or DNSBL. If these tests fail your mail server will respond appropriately, with a 4xx or 5xx error which will end the SMTP session. Another example would be after the DATA command, any failures after the DATA command would indicate that your mail server ran tests for message headers, body, virus, or spam, then takes action based on the condition. The test may reject, delete, or accept (whitelist) the message. It is important to know where the failure occurred so you can review specific features on your mail server and make corrections or concede valid rejection.
