SMTP log - Troubleshooting guide

WHAT IS SMTP

SMTP stands for The Simple Mail Transfer Protocol (SMTP), an Internet standard communication protocol for electronic mail transmission. So, when you have an issue with sending or receiving e-mail, you should check this LOG type to see how communication between your and the other side went.

LOGGING LEVEL

To see the most precise information in the log, choose the extended level logging for SMTP. It is under System->Services->General (next to the SMTP Service) in the remote admin console. SMTP communication will be logged; try to recreate the situation. Review the log from the remote admin console under Status->Logs. Select the log type as SMTP and the date when communication occurred.

Select the time of the e-mail sent or received; it helps locate the communication since the log can be extensive.

The most critical series of error messages is the 5xx one, especially the ones from 550 to 559. In particular, you will probably get a lot of 50x SMTP error codes – a problem concerning the recipient’s email address.

HOW TO READ IN THE LOG

Let's use the communication below as a demonstration. ("IP" represents the IP address used in this article for demonstration purposes.)

When communication between two SMTP servers starts, we see information about servers "getting to know each other" and "talking" about the same conditions to use during the communication.

As we get to the line where we see STARTTLS, this means that this communication is happening on a secured TLS port. 

Ready to start TLS means both servers agreed to proceed with communication on a secure TLS port.

The sending server/client greets the receiving server with EHLO, and the response from the receiving server is "pleased to meet you", along with the capabilities of the receiving server. The capability to note here is AUTH. This lets the sending server/client know the types of logins that can be used.

Next, we see  <<< AUTH LOGIN (this is the type of login the sending server/client chose to authenticate with).

The servers send and receive authentication information and confirmations.

>>> 334 VXNlcm5hbWU6
 <<< d3d3
>>> 334 UGFzc3dvcmQ6
<<< UGFzc3cwcmQ=

and then "authentication credentials invalid" and "closing connection". Exactly what you look for when you are in the process of troubleshooting.

So this means the transfer of the message was not successful, and the reason is the credentials were not valid.

IP [00007F9279E56700] 12:36:58 <<< STARTTLS
IP [00007F9279E56700] 12:36:58 >>> 220 2.0.0 Ready to start TLS
IP [00007F9279E56700] 12:36:58 <<< EHLO [IP]
IP [00007F9279E56700] 12:36:58 >>> 250-mail.domain.com Hello [IP] [IP], pleased to meet you.
250-ENHANCEDSTATUSCODES
250-SIZE 104857600
250-EXPN
250-ETRN
250-ATRN
250-CHECKPOINT
250-8BITMIME
250-DSN
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
250-VRFY
IP [00007F9279E56700] 12:36:58 <<< AUTH LOGIN
IP [00007F9279E56700] 12:36:58 >>> 334 VXNlcm5hbWU6
IP [00007F9279E56700] 12:36:58 <<< d3d3
IP [00007F9279E56700] 12:36:58 >>> 334 UGFzc3dvcmQ6
IP [00007F9279E56700] 12:36:58 <<< UGFzc3cwcmQ=
IP [00007F9279E56700] 12:37:01 Authentication [SMTP] - Result=0, User=www, Method=0
IP [00007F9279E56700] 12:37:01 >>> 535 5.7.8 Authentication credentials invalid
IP [00007F9279E56700] 12:37:01 <<< QUIT
IP  [00007F9279E56700] 12:37:01 >>> 221 2.0.0 mail.domain.com closing connection
IP [00007F9279E56700] 12:37:01 *** <> <> 0 0 00:00:00 INCOMPLETE-SESSION 
IP [00007F9279E56700] 12:37:01 Disconnected

Invalid credentials are a common scenario; below, you will find other examples. 

EXAMPLE OF SCENARIOS

1. You cannot send e-mails to a certain domain

a) the recipient's server doesn’t trust yours (certificate etc.)

This scenario might arise when you are using SSL communication without a valid SSL certificate. The certificates are in the remote console under system->certificates (a free Lets Encrypt certificate can be added as needed), or servers have different TLS versions and are incompatible.

Piece of Example communication where the message was not sent from you, which you may find in this case:

SSL: Handshake with client failed <IP address>
 <> <> 0 0 00:00:00 INCOMPLETE-SESSION

Disconnected

To troubleshoot it (refers to the highlighted part in a code block), please check if you have a valid certificate in IceWarp, and if you have the right port under System->Services->double click on service SMTP and check SSL port (465); in the other case, when servers have different TLS versions, you have to have matching versions; fortunately, this case is not so frequent. 

b) you are not able to send an e-mail from webmail

This case is only for when you cannot send an e-mail from the webmail. So when you are dealing with some reports of users being unable to send e-mails and they are using webmail, check the SMTP log, and if you see text like down below in the code block, proceed to troubleshoot like described.

Piece of Example communication where the message was not sent from you, which you may find in this case:

<user@domain.com>... Sender ok
 <<< DATA
>>> 503 5.5.1 Incorrect command sequence
*** <user@domain.com> <> 0 0 00:00:00 INCOMPLETE-SESSION
[00007FCCD1584700] 09:28:47 Disconnected

To troubleshoot it (refers to the highlighted part in a code block), please check for default folders in WebClient under the affected user. Click on his avatar under webmail->settings->general->default folders and make sure folders are mapped correctly.

2. You did not receive an e-mail that was sent to you

a) the sender is blacklisted on your server

This scenario is easy to troubleshoot, but sometimes you will not think of it like, "oh, I do not remember adding this address to a blacklist" sometimes address might end up in blacklist/greylist/intrusion prevention automatically without your action. For example, the sender's IP reputation is bad, so he will probably end up on your blacklist (if you have the option enabled - "use IP reputation" under Mail->security->DNS).

Piece of Example communication where the message was not delivered to you, which you may find in this case:

 <<< RCPT To:<user@domain.com>
 >>> 250 2.1.5 <user@domain.com>... Recipient ok
*** <user@domain.com> <user@domain.com> 1 131596 00:00:00 OK 202301160743383607
 Message for <user@domain.com> not delivered. Reasons:[Live=N,Blacklist], Action:DELETE
SYSTEM [00007FCA969E9700]  MDA *** <user@domain.com> <user@domain.com> 1 131596

To troubleshoot it (refers to the highlighted part in a code block), this example of communication is clear. See, there is a "Reasons:[Live=N, Blacklist]" this means the sender is blacklisted on your server. So in the remote console, under Status->Spam queues->BlackList tab->delete his entry. 

The line Reasons:[Live=N, Blacklist]" BlackList information is only one that matters because the information Live=N means that antispam checked this message and gave it the green light.

b) intrusion prevention

The sender ends up in intrusion prevention because he didn't meet the condition you have on your server. You can check them in the remote console under Mail->security->intrusion prevention.

Also could be because of a bad IP reputation.

Piece of Example communication where the message was not delivered to you, which you may find in this case :

Client session >>> 2024681 bytes (overall data transfer speed=126477535 B/s)

Connected, local IP=<UIP xx.xx>

>>> 421 4.7.1 Intrusion prevention active for [IP address] [L]

Intrusion Prevention - closing all connections from <IP >

*** <> <> 0 0 00:00:00 INCOMPLETE-SESSION

To troubleshoot it (refers to the highlighted part in a code block), this one intrusion prevention active [L] - that L is the reason, and you can see what it means if you are in the admin remote console under Mail->security->intrusion prevention and press F1, where it is described, or here.

In the remote console, under Status->Spam queues->Intrusion Prevention tab -> check if the sender’s IP is not there, if it’s there and you are sure it is safe, delete the IP from the list and if you are sure the sender is not dangerous then add him to bypass ("B" in the screenshot above.)

c) could be a rule/Content filter

Rules - for incoming messages

Content filters - for both incoming and outgoing messages

These are managed in the Remote Admin Console under Mail->Rules (also, the user can have a rule which he/she created, for example, under his/her webmail/Desktop client), but content filters are only in the admin tool.

Piece of Example communication where the message was not delivered to you, which you may find in this case:

<user@domain.com> <user@domain.cz> 1 131617 00:00:00 OK 202301171144533836
Message for <user@domain.cz> not delivered. 
 MDA *** <user@domain.com> <user@domain.cz>CONTENT-FILTER 202301171144533836

To troubleshoot it (refers to the highlighted part in a code block), in the remote console under Mail->Rules, there are tabs named Content Filters and Rules. The log refers to these locations. Review the rules/filters to determine the logic that might have blocked the message. In the rules/filter settings is a "Title" box. If you provide a unique name for each rule/filter in the Title box, that name will appear in the log for easier identification. If the rule/filter blocks a message, the sender should receive a bounce-back e-mail about the unsuccessful delivery

d) sender didn't have a proper authorization

This only refers to local communication means from your domain or domains in the same server. 

So when your local user cannot send to another local user, check SMTP log, and if you'll see the message access not allowed-> Check troubleshooting,

Piece of Example communication where the message was not delivered to you, which you may find in this case:

<user@domain.com>... Sender ok
<<< RCPT TO:<user@domain.eu> ORCPT=rfc822;root
>>> 550 5.7.1 <user@domain.com> Access to <user@domain.eu> not allowed
<<< RSET
>>> 250 2.0.0 Reset state
<<< QUIT
>>> 221 2.0.0 EXICEWARP01 closing connection
<> <> 0 0 00:00:00 INCOMPLETE-SESSION

To troubleshoot it (refers to the highlighted part in a code block), it usually means that the sender is not using specified standards for communication in your server. The email client is not using SMTP authentication, or SMTP authentication is forced on port 587, and the user is trying to use port 25. Check his client (webmail or desktop client and SMTP settings) and see if the ports match your conditions. In another case, please contact our support.