SMTP Status Codes
This document describes the set of extended status codes for use within the SMTP mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status.
- These codes are documented in RFC 3463
Status Code Structure
This document defines a new set of status codes to report mail system conditions. These status codes are used for media and language independent status reporting. They are not intended for system specific diagnostics.
The syntax of the new status codes is defined as:
status-code = class "." subject "." detail
class = "2"/"4"/"5" subject = 1*3digit detail = 1*3digit
White-space characters and comments are NOT allowed within a status-code. Each numeric sub-code within the status-code MUST be expressed without leading zero digits.
Status codes consist of three numerical fields separated by “.”. The first sub-code indicates whether the delivery attempt was successful. The second sub-code indicates the probable source of any delivery anomalies, and the third sub-code indicates a precise error condition.
Example: 2.1.23
The code space defined is intended to be extensible only by standards track documents. Mail system specific status codes should be mapped as close as possible to the standard status codes. Servers should send only defined, registered status codes. System specific errors and diagnostics should be carried by means other than status codes.
New subject and detail codes will be added over time. Because the number space is large, it is not intended that published status codes will ever be redefined or eliminated. Clients should preserve the extensibility of the code space by reporting the general error described in the subject sub-code when the specific detail is unrecognized.
Status Codes
| Error Code | Meaning | Notes |
| 1.0.1 | Cannot open connection | Typically your SMTP server or email program is unable to even start an SMTP session. Typical replies will be “SMTP Error 101, Error opening connection” or “SMTP Error 101, cannot open SMTP stream”. All SMTP Error 101 errors usually point to a configuration problem, such as an incorrectly spelt SMTP server, or an IP address that does not exist, or an SMTP port that does not exist or which the recipient will not accept SMTP connections on, or some other process is already using the default SMTP port, port 25. |
| 1.1.1 | Connection refused | Typically from Linux based email systems such as SquirrelMail and Mailman. The message will usually go like this : “Connection refused, 111 Can’t open SMTP stream”. All SMTP Error 111 errors usually point to an inability of your server to communicate with the remote SMTP server (either the recipient’s SMTP server or your ISP’s SMTP server) or to a Linux/SMTP software configuration problem, typically /etc/hosts not being world readable, or a newly installed or reconfigured firewall preventing connection to the remote SMTP server, or incorrect hostnames and/or domains (e.g. does your sending hostname match your IP address in a reverse lookup?), or exim not running. Telnet and logs should help you home in on the problem. |
| Status Code 2.X.X - Success Messages | ||
| 2.1.1 | System Status message or System Help Reply | SMTP status 211 prefaces a message about the Mail Server status or a System Help reply to the user requesting help information. You might for example issue a command to the mail server to display a list of commands you can use and the server replies with an SMTP Reply 211 followed by the list you requested. |
| 2.1.4 | Help Reply message | SMTP status 214 is usually in reply to the “HELP” command.It displays information about the server, usually a URL to the FAQ page of the SMTP software running on the server. As a result this “error” is normally called a reply, as in SMTP Reply 214. |
| 2.2.0 | <Server Name> service is running | This is normally the first message you will get back from the server. It means the mail service is running (ie. your mail server is running). It will normally contain a welcome message and/or the title of the SMTP software and, sometimes, the version number of the mail server software.SMTP Reply 220 is effectively a “Hi There, I have just this second finished starting up – I am ready to go and at your command” informational message. |
| 2.2.1 | The domain service is closing the transmission channel | The server is ending the mail session – it is closing the conversation with the ISP as it has no more mail to send in this sending session. SMTP Status 221 is often misconstrued as an error condition, when it is in fact nothing of the sort. The mail server is simply telling you that it has processed everything it was given in this particular session, and it is now going back into waiting mode. Because SMTP status 221 is often misinterpreted, with some mail servers the Network Administrators have changed the default text of SMTP Reply 221 to something more meaningful and less alarming. For example, a typical SMTP reply 221 might say “221 Goodbye” or “221 Closing connection”, or the most irritating one we’ve seen “221 Bye”, Arrrgghh–can you blame anyone for thinking there might be a problem? Of course not! So some Network Administrators are these days being quite imaginative by changing the default text of SMTP reply 221 to more user friendly messages like : “221 Thank you for your business”(I love that one!),or “221 All messages processed successfully in this session, SMTP connection is closing”. |
| 2.1.4 | Help Reply message | SMTP status 214 is usually in reply to the “HELP” command. It displays information about the server, usually a URL to the FAQ page of the SMTP software running on the server. As a result this “error” is normally called a reply, as in SMTP Reply 2.1.4. |
| 2.2.0 | <Server Name> service is running | This is normally the first message you will get back from the server. It means the mail service is running (ie. your mail server is running). It will normally contain a welcome message and/or the title of the SMTP software and, sometimes, the version number of the mail server software. SMTP Reply 220 is effectively a “Hi There, I have just this second finished starting up – I am ready to go and at your command” informational message. |
| 2.2.1 | The domain service is closing the transmission channel | The server is ending the mail session – it is closing the conversation with the ISP as it has no more mail to send in this sending session. SMTP Status 221 is often misconstrued as an error condition, when it is in fact nothing of the sort. The mail server is simply telling you that it has processed everything it was given in this particular session, and it is now going back into waiting mode. Because SMTP status 221 is often misinterpreted, with some mail servers the Network Administrators have changed the default text of SMTP Reply 221 to something more meaningful and less alarming. For example, a typical SMTP reply 221 might say “221 Goodbye” or “221 Closing connection”, or the most irritating one we’ve seen “221 Bye”, Arrrgghh – can you blame anyone for thinking there might be a problem ? Of course not ! So some Network Administrators are these days being quite imaginative by changing the default text of SMTP reply 221 to more user friendly messages like: “221 Thank you for your business” (I love that one!), or “221 All messages processed successfully in this session, SMTP connection is closing”. |
| 2.5.0 | Requested mail action OK completed | The mail server has successfully delivered the message! This is the best SMTP reply (250) to receive - your message has been accepted and transmitted OK ! :) Yippee. 250 is effectively a status code rather than an error code – there is no such thing as an SMTP error 250. |
| 2.5.1 | User not local will forward | |
| 2.5.2 | Cannot VRFY (verify) the user – the server will accept the message and attempt to deliver it | The user account appears to be valid but could not be verified, however the server will try to deliver the message. There are sometimes circumstances where an email address appears to be valid but cannot be verified as definitely valid during the SMTP session between the sending server (your server) and the next server to accept your message. This can happen for example in very large corporation where the first email receiving server might only be an email exchanger server, a gateway server to the eventual server which holds the user mailboxes and which can verify if the intended recipient exists in that organization. When this happens the gateway server will reply with an SMTP Error 252 telling your sending server that it cannot verify the user part of the email address, that the domain part is OK, and that it will forward your email to a server which can do the checking and eventually deliver to the user mailbox if it exists. |
| Status Code 3.X.X - Informational | ||
| 3.5.4 | Start mail input end with <CRLF>.<CRLF>, or, as a less cryptic description – “FROM and TO information received, now please provide message body and mark its end with <CRLF>.<CRLF>” | This is normally in response to the DATA command. The server has received the From and To information and is now asking for the “Message Body”, the main part of the message which should be ended by two blank lines separated by a dot (period). Therefore, on receiving an SMTP Reply 354 the sending server should send the body of the message to the receiving server and indicate the end of the message body with <CRLF>.<CRLF> (note the full stop between the two Carriage_Return-Line_Feed’s). |
| Status Code 4.X.X - Persistent Transient Failure | ||
| 4.2.0 | Timeout communication problem encountered during transmission. This is a Novell GroupWise SMTP error | In our experience only Novell GroupWise servers use this error (we use GroupWise!). You will get a GroupWise GWIA (GroupWise Internet Agent) 420 TCP Write Error or 420 TCP Read Error if there are communication problems during transmission of the actual message after the sending and receiving servers have actually connected. A small number of 420 SMTP errors is normal as occasional peaks of Internet usage may delay the transmission of an email with attachment so much that a timeout occurs. When a timeout occurs on a GWIA send, the message is queued up in the <Domain>\WPGATE\DEFER directory for processing at a later time (as defined in ConsoleOne or GWIA.CFG). If you experience 420 errors only with specific recipient then it is quite likely that the recipient’s antispam firewall does not like your server, your server’s external IP address, or that your server’s HELO command uses an outbound identification that does not match your server’s external IP address (check that your sending domain’s DNS is set up correctly). In an ideal world a well behaved recipient server should really be issuing your GroupWise server with a 554 error rather than timing out and causing the GroupWise GWIA to fault with a 420 error. If you experience too many 420 errors with all email communications, then you have a physical communication problem somewhere. This could be your server’s network card, the network point that your server is plugged into, your switch(es), your router(s), your firewall, or your Internet line – problems caused by routers with different MTU sizes is a classic issue. Unless the logs of all those various problem points can give you an instant answer, the only way you will get to the bottom of the problem is to use a packet tracing and inspection program like Ethereal or Wireshark, its successor, if you’re running GroupWise on a Windows or Linux server; on NetWare your only choice is PacketScan which you can get here http://support.novell.com/docs/Readmes/InfoDocument/2967287.html. In the final analysis, if the tracing of packets, and the changing of hardware does not help then do not discount a slightly faulty hard disk being the cause of all your problems (even if your RAID controller or your hard disk testing software does not detect any problem!). |
| 4.2.1 | The SMTP service/server you use has a limit on the number of concurrent SMTP streams your server can use | The Mail transfer service is unavailable because of a transient event. SMTP reply 421 can be caused by many things but generally indicates that the mail server which returns this status code is currently unavailable but may be available later. For example, the server administrator may have stopped the mail service to troubleshoot a problem, or the mail server is right in the middle of rebooting, or the mail server is currently processing too many incoming messages or incoming requests, etc… Note : “Mail Server” in this case can be any of the mail servers on the message’s route – the sending server (your server), the ISP SMTP server, or the recipient’s mail server. Clearly, if you repeatedly receive an SMTP status 421 then the problem is no longer of a transient nature and you need to investigate or inform the relevant network administrator, ISP tech support, or the recipient. SMTP Response 421 can also be received as a result of your message server sending an email where the total number of TO, CC, and BCC users results in a number of simultaneous SMTP connections that is in excess of the number of connections your ISP or SMTP service allows. A typical error message for this situation would be : “421 Too many concurrent SMTP connections from this IP address; please try again later”. Typically, when this happens your server will have sent some of the messages (note that for all servers, each email sent by a user always gets broken down into individual separate emails to each of the recipients in the TO, CC, and BC fields), and will automatically retry a little later to send the remaining messages. |
| 4.2.2 | The recipient’s mailbox is over its storage limit ( OR ) The size of the message exceeds the recipient’s size limits for incoming email | Either the recipient’s mailbox is over its storage limit or the message delivery directory (folder) on the recipient’s mail server is currently over a size limit imposed by the Network Administrator (e.g. possibly as a result of the mail server having been down for some time, having been repaired, and currently in the process of collecting thousands of queued up messages). However, SMTP response 422 can also be received if the email being sent is larger than the incoming emails size limit in operation at the recipient’s mail server (particularly when that recipient’s mail server is Exchange Server). |
| 4.3.1 | The recipient’s mail server is experiencing a Disk Full condition | The recipient’s mail server is experiencing a Disk Full error condition, or an Out of Memory (too many file handles) error condition (Microsoft Exchange). |
| 4.3.2 | The recipient’s Exchange Server incoming mail queue has been stopped | This is an SMTP status response specific to Microsoft Exchange Server. It indicates that the recipient’s mail queue on their Exchange Server has been stopped (frozen), probably while the Network Administrator troubleshoots some problem. |
| 4.4.1 | The recipient’s server is not responding | This is an error emanating from your server indicating that the recipient’s server is not responding. Your server will automatically try again a number of times – how many depends on how your server has been configured. |
| 4.4.2 | The connection was dropped during transmission | Your server started delivering the message but the connection was broken during transmission. This may be an unusual transient error – however, if it keeps happening you should investigate possible problems with your server’s network card, your Internet routers, processes hogging the resources of your server, and anything else which could result in a network connection being broken. |
| 4.4.6 | The maximum hop count was exceeded for the message | The maximum hop count was exceeded for your message. The most likely cause of this error status code is that your message is looping internally on your server, internally between two of your organisation’s servers, or, sometimes, looping between your server and the recipient’s server. |
| 4.4.7 | Your outgoing message timed out. | Your outgoing message timed out because of problems with the receiving server who objected to your message. Typically there is a problem with the message header (such as too many recipients, in most cases, or a protocol timeout between the two servers). |
| 4.4.9 | Routing error | This is a Microsoft Exchange Server specific error code. As per Micro
|