Overview

SMTP Conversations are the method used by Mail Servers to negotiate a connection while delivering email using the SMTP protocol. There is a back and forth exchange of information which helps determine the identity of the servers, the email participants, and the results of the email attempt. By analyzing these conversations, you can understand exactly what transpired.

Information

1. Analyzing SMTP Conversations
   1. Inbound SMTP Conversation
   2. Outbound SMTP Conversation
   3. Keeping Track of the SMTP Conversation within Logs
   4. Monitoring Server SMTP Delivery Statistics/Health
2. SMTP Commands, Response codes, and Status Codes
   1. SMTP Commands
   2. Response Codes
   3. Status Codes
3. Isolating SMTP Issues

Analyzing SMTP Conversations

The SMTP Conversation(or Session) is fundamentally the programmatic method used by SMTP Clients and SMTP Servers when the client attempts to send an email over the SMTP protocol. The client speaks to the server using a series of defined alphabetical characters and the server will respond with a number of numerical codes. 

Inbound SMTP Conversation

Below is an abstract diagram of an SMTP Conversation between an External O365 Mail Server and a Kerio Connect Server. Notice that the Sending Server (Client) is connecting to the SMTP Port (25) and a number of checks may occur on the Receiving Server (Server) end before responses are sent out, however, the SMTP Session is technically established, although the "conversation" has not yet begun.

Once the Receiving Server determines that it can communicate with the IP or Domain, it will send the "SMTP Greeting" to the Client signaling that it is ready for the Client to send "Commands". 

With the Greeting offered, the SMTP Client sends its first command, “EHLO” (Sometimes “HELO” on mail servers that don't support Enhanced SMTP(ESMTP)) and awaits a response. In this example of a healthy conversation, the Connect server sends a “250” or “Success - Previous command was completed.”

Notice that in this example, the STARTTLS command is sent after the conversation begins, signaling a desire for a secured connection. Once the TLS connection is established, the Client will send another “EHLO” within the new, secured connection, as the change to TLS resets the conversation.

This continues through the various components of the email content (Sender, Recipient, and Email Body) until finally all of the data that the Client wanted to send has been received and the Email is “Accepted for Delivery.” This is where the SMTP Client ends the Session by sending its “QUIT” command and the two servers are no longer connected. The Kerio Connect server then uses the collected details to inject the message into the queue and based on the results produces a “Status Code,” in this case “2.0.0” or “Email delivered to Inbox.” 

Comparing the Abstract to the Logs

It can be easier to review the contents of the conversation using the above abstract diagram of the back and forth, however, most often you will simply be reviewing this within the server logs, as seen below. This log is a direct match for the diagram above(the external server’s side of the conversation is highlighted in green):

It is important to remember that the exact commands sent by the sending SMTP client can vary based on the type of Mail Server being used. The example conversation above is between a Kerio Connect Server and an O365 Account. While the commands sent will vary, the general back and forth “Conversation” is generally consistent across most providers. 

Another important thing to consider within the terminology used in the example above is that the sending SMTP Server is considered the “client.” The email was likely not directly drafted within the Email Server, but rather by a user within their chosen email client. This Email client uses the configured SMTP settings to connect with their own SMTP Server that is actually having the conversation above. Despite this, the outbound leg is most often described as the “Client.”

Outbound SMTP Conversation

In contrast to the above, below is a log entry showing the opposite scenario, with the same Kerio Connect server sending an email via webmail to the same O365 Account(the external server’s side of the conversation is again highlighted in green):

Notice that the initial queue processing takes place upfront as the Kerio Connect server is preparing the email for delivery first, and then it begins to establish the connection. Once the greeting is received, the Connect Server sends its EHLO, and then we can see an implied STARTTLS command was received, as we see the Connect Server changing to TLS. The remainder of the SMTP Conversation should appear very familiar, although in reverse.

Keeping Track of the SMTP Conversation within Logs

One common source of confusion when analyzing the SMTP Conversation logs is within high-volume environments where a large number of SMTP conversations are occurring at once. It is recommended that in these instances, you trace down the Thread ID of the conversation based on the initial SMTP Session begin or SMTP Greeting log entry.

All of the related log entries for the SMTP Conversation will share this same ID, which can be filtered on using Log Highlighting or within an external IDE. Here you can see the ThreadID appearing within [Square Brackets] just after the Timestamp:

Monitoring Server SMTP Delivery Statistics/Health

Server statistics are needed when it is required to get a report on the number of inbound/outbound emails, the number of failed and bounced emails, delivery status notifications and so on without using the email logs. Such statistics help get a quick overview of the health and usage numbers of the server.

In the Kerio Connect administration interface, this can be checked from Status > Statistics > To Advanced Mode. For more information, refer to Viewing statistics in Kerio Connect.

Failure and bounce statistics can be particularly helpful in identifying if there could be a problem with the SMTP server.

Permanent delivery failures result in the emails getting 'bounced'. This could be because of one of the following reasons:

• A user sends an email to a wrong or non-existent email address.
• The recipient server is unreachable.
• Failures defined as permanent with error codes 5xx as noted in About SMTP Error Messages.

Temporary delivery failures result in emails being 'delayed'. This can happen when:

• The remote server rejects an email temporarily due to 'graylisting' by their spam filter.
• DNS resolution to the recipient server is temporarily unavailable.

SMTP Commands, Status codes, and Response Codes

As seen above, the most important pieces of an SMTP conversation are handled through the use of alphanumeric commands and codes sent between the two SMTP Servers. In addition, a similar set of codes are used to differentiate the results of the conversation once a message is queued. Below are detailed the most common of these.

SMTP Commands

These are the alphabetic commands that are sent from the SMTP Client during the conversation. While not an exhaustive list of all potential Commands, these are the ones most commonly used. For a more complete listing, you can review the associated rfc5321.

SMTP Response Codes

These are the numerical codes that an SMTP Server can provide in response to the above commands. The first digit of the 3-digit code acts as a quick reference for the general meaning of the commands:

Code 2XX: Success codes with special meaning.

Code 3XX: Commands that are accepted but require additional information to complete.

Code 4XX: Temporary Error and means that sender should send request again.

Code 5XX: Denotes Permanent Error like transaction failure, mailbox being unavailable, etc.

Note that many of these are command-specific, so will normally only appear when the associated command is sent (Detailed within the SMTP Commands section above). Further, this list contains the most common codes used by various Mail Servers, however, other servers may provide unexpected or irregular codes during the SMTP conversation. 

SMTP Status Codes

These are the codes used to determine the overall “Result” of the attempted SMTP conversation. Status codes consist of three numerical fields delimited by periods. 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.

These can be generally grouped by the first digit of the Status Code, as seen below:

• 2.X.X - Success - Report of a positive delivery action.
• 4.X.X - Persistent Transient Failure - Message is valid, but the persistence of some temporary conditions has caused abandonment or delay.
• 5.X.X - Permanent Failure - Not likely to be resolved by resending the message in current form.

Below are the most common status codes that you will encounter, however, you can review rfc3463 for a more exhaustive list.

• 2.0.0 - Email has been delivered to the Inbox.
• 2.1.5 - Email has been delivered and moved to another folder due to a filtering rule.
• 4.1.1 - Email address does not exist.
• 4.4.1 - No answer from host or connection lost.
• 4.4.4 - Temporary Server Error.
• 4.4.7 - Message expired
• 5.1.7 - Sender's email address was incorrect or has bad syntax.
• 5.7.1 - Authentication Required.

Isolating SMTP Issues

The most common and obvious issues with SMTP are with delivery when sending or receiving messages. When reviewing these issues, the main focus should be on isolating exactly where in the conversation the issues appear. 

Once identified, this can make the process of troubleshooting the issue much easier, as issues that appear within certain phases of the conversation tend to have similar root causes. You can reference the guidance within Troubleshooting SMTP-Related Issues to help during this isolation.

For issues specifically involving O365 or Exchange servers, consider using Microsoft's Remote Connectivity Analyzer which provides a number of Tools and Tests that can help isolate issues with their services.

Failing before the Greeting is Sent

• • Common issues at this point in the SMTP conversation are often related to the Network or Firewall on either end of the attempted connection. They can, however, also be caused by issues with the Email Client authorizing with the SMTP Server, preventing the conversation from ever beginning.
  • For example, the appropriate ports (25) are not open to connections from outside their LAN, the IP of one of the servers has been Blacklisted by the other end preventing the connection, or the connection is blocked due to a lack of reverse DNS entry.

Failing during the Conversation

• • Most often this is the result of an invalid or unauthorized email address being used in the sender/recipient portion of the conversation, in situations where an invalid or unimplemented command has been sent, or when the receiving server identifies the sender IP/Domain within a blacklist/greylist.
  • You can analyze the specific commands and response codes using the details above to better isolate the cause, however, these often will express themselves as one of the servers closing the connection prematurely.

After the Message is Queued for Delivery

• • These issues are often more difficult to analyze if the issue is occurring on an external server, as the visibility into the issue will be severely diminished. That said, generally speaking in those scenarios, the cause of the issue is not a result of failure on the sending Mail Server.
    • Note that the direction of the SMTP conversation can play a part in why emails are stuck in the queue.
    • For example: When sending emails out of Kerio Connect, emails may become queued due to a failure during the conversation, but received emails will get stuck in the queue only after the SMTP conversation has been completed and they were accepted for delivery.
  • When seeing these issues within your Kerio Connect server, this is often easier to review as you will have direct access to the Mail Queue containing the undelivered emails and can similarly review the inbound mail logs to determine the Status Code detailing the cause for the failure.
    • For example, issues with the Antivirus being unable to scan the emails or a particular user account has exceeded their defined mail quota.
    • In any scenario involving mail stuck within your own mail server, you can access the Message Queue(Status > Message Queue) to quickly determine the reason for the failed delivery.