In this tutorial topic, we’ll be discussing how to go through the logs on your SmarterMail server, which we’ll specifically be covering the SMTP and Delivery logs.
At times you may want to verify if an e-mail you sent really did get sent out, or maybe you thought you should’ve received an e-mail from a specific individual that you have yet to receive in your inbox. With the logs in SmarterMail you should be able to determine the fate of that e-mail, which we’ll outline in our steps below:
Searching the logs via SmarterMail
-
Login to the Smartermail administrator user for your server. You can view our guide on logging in or recovering your password if needed.
-
Once logged in click on the Globe icon for ‘Manage’ (should default to this option upon immediate login).
-
Choose ‘Troubleshooting’ from the list of available options under manage.
-
You will then be taken to a page with different logging options. At the top of the page in the navigation choose ‘View Logs’, as also shown in the screenshot below:
-
You will then be presented with your search criteria fields including:
-
Start: The start date to start searching through the logs. To shorten the results to find the actual message you’re looking for be sure to select the date that the message was attempting delivery.
-
End: The end date to stop searching through the logs. To shorten the results to find the actual message you’re looking for be sure to select the date that the message was attempting delivery.
-
Type: The type of error log to search through. If sending is the problem and you are sending via SMTP authentication, then check the SMTP logs. If delivery is an issue (incoming email) or sending an e-mail directly through webmail (By-passes SMTP authentication), then check the DELIVERY logs.
-
Search: This field input is the search string that you’re looking through the logs for. For example, this could be the e-mail address being sent TO or FROM for the individual email you’re searching the logs for.
-
Match Type: This option will allow you to see results ONLY matching the log line that is found for the search, or it will show any related e-mail traffic that it finds for the search string._
-
-
Once you’ve selected the search criteria click the ‘Search’ button and wait a few seconds to display the results. If this is a busy e-mail server and the logs are rather large this could take some time.
What is difference between SMTP and DELIVERY log?
To explain the difference we created a test case (be sure to check out the conclusion below if needed):
-
We sent two separate e-mails (both from the same ‘[email protected]’ address to the same ‘@gmail.com’ address.
-
One of the above-mentioned e-mails was sent directly via SmarterMail interface via the logged on user.
-
The other above-mentioned e-mail was sent from an e-mail application (MacMail, Outlook, iPhone, etc.) using SMTP authentication (username & password).
Looking through the logs for this e-mail in the SMTP Log displays only ONE of these e-mails, since the SMTP log only reports logs related to SMTP. Since the first e-mail sent was sent directly through the SmarterMail interface we bypass the need for SMTP authentication (already logged in) and the e-mail would only show up in the delivery log for when it is processed.
However, as you can see in the DELIVERY Log example below BOTH of these e-mails are displayed… and yes as you can see from the delivery log both e-mails were successfully delivered, as shown with the ‘(Delivered)’ status.
Conclusion: The Delivery log is the log to go to for all processing of e-mails, including incoming and outgoing e-mail. The SMTP log is strictly for pre-processing (SMTP Authentication) so that the server can ensure that the message is okay to start the delivery process.
If sending via an e-mail client (such as Outlook, Thunderbird, iPhone, MacMail, etc.) and you’re using the wrong username or password for example… then this will be logged in the SMTP log and the e-mail will not make it to the DELIVERY log since there will be no attempt in delivery (email did not make it that far in the process).
Analyzing the search results
In the first section, we explained how to perform a search. In the second section, we explained the difference between what is logged in the SMTP log versus what is logged in the DELIVERY log.
Let’s now show a few common results found in each to explain their importance:
SMTP Log
We’ll start with the SMTP log first. See below for each important entry in the logs that you’ll commonly see.
First off let’s start with the beginning of every log line:
[2018.05.07] 22:54:21 [123.123.123.123][63985015]
The above shows that this particular line in the log is happening at 10:54 PM on May 5th, 2018 & that the connection is coming from the IP Address 123.123.123.123. The very last part of the text ‘[63985015]’ is the SMTP message ID, so that you know which lines of the logs go with each individual e-mail messages.
Now let’s show the rest:
Line 1: rsp: 220 mail.servermanagementco.com
Line 2: connected at 5/7/2018 10:54:21 PM
Line 3: cmd: EHLO [192.168.0.8]
Line 4: rsp: 250-mail.servermanagementco.com Hello [123.123.123.123]250-SIZE 31457280250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
Line 5: cmd: AUTH CRAM-MD5
Line 6: rsp: 334 PDQwNTYwMTI1My42MzY2MTMzMDQ2MTY1OTAzMTRAbWFpbC5zZXJ2ZXJtYW5hZ2VtZW50Y28uY29tPg==
Line 7: Authenticating as [email protected]
Line 8: rsp: 235 Authentication successful
Line 9: Authenticated as [email protected]
Line 10: cmd: QUIT
Line 11: rsp: 221 Service closing transmission channel
Line 12: disconnected at 5/7/2018 10:54:21 PM
-
Line 1 - On this line, the server is responding with a status code of ‘220’, which means the connection was accepted. The server hostname (of our server for our test case) is ‘mail.servermanagementco.com’ in this case.
-
Line 2 - Confirming that the connection is connected and logs the time of connection.
-
Line 3 - EHLO command initiates to identify server initiating connection.
-
Line 4 - Server responding to sender host (123.123.123.123) with a “Hello” greeting.
-
Line 5 & 6 - Specifying the type of authentication encryption. In this case, CRAM-MD5 hashing was used. Sends encryption.
-
Line 7 - 9 - States user that is attempting to authenticate (tutorials@servermanagementco.com) and that the authentication was successful (correct username & password).
-
10 - 12 - The authentication process is now complete (successful) and the e-mail is now spooled in the e-mail queue and will attempt to be delivered once it’s received its turn in the e-mail spool.
The above was a successful SMTP authentication connection from an e-mail client. Now… for testing purposes I’ll change the password to something incorrect to see the results in the log.
Posted below is the equivalent of lines 7 - 12 mentioned above when the SMTP authentication failed:
[2018.05.07] 23:25:43 [216.15.151.93][12653114] Authenticating as [email protected]
[2018.05.07] 23:25:43 [216.15.151.93][12653114] rsp: 334 UGFzc3dvcmQ6
[2018.05.07] 23:25:43 [216.15.151.93][12653114] rsp: 535 Authentication failed
[2018.05.07] 23:25:43 [216.15.151.93][12653114] disconnected at 5/7/2018 11:25:43 PM
So, as shown above, we entered the wrong password and the authentication indeed failed. The connection immediately disconnected and the e-mail was not processed any further and will continue to be the result until the password authentication is successful, which will require the password to be updated in the e-mail client (or if in your website’s code, then the password in your code must be updated).
Delivery Log
The Delivery log, as mentioned above, contains logs for when incoming or outgoing e-mail is being processed (attempting delivery). There can be numerous causes for e-mail getting blocked such as incoming or outgoing spam filters, RBLs (Real Time Blacklist), & more.
See below for each important entry in the logs that you’ll commonly see.
First off let’s start with the beginning of every log line:
[2018.05.07] 22:57:34 [61003]
The above shows that this particular line in the log is happening at 10:57 PM on May 5th, 2018 & that the connection is coming from the IP Address 123.123.123.123. The very last part of the text ‘[61003]’ is the Delivery message ID, so that you know which lines of the logs go with each individual e-mail messages.
Line 1: Delivery started for [email protected] at 10:57:34 PM
Line 2: Sending remote mail for [email protected]
Line 3: Sending remote mail to: [email protected]
Line 4: Initiating connection to 74.125.69.26
Line 5: Connection to 74.125.69.26:25 from 216.15.151.93:52003 succeeded (Id: 1)
Line 6: RSP: 220 mx.google.com ESMTP m203-v6si8908464itm.99 - gsmtp
Line 7: CMD: EHLO mail.servermanagementco.com
Line 8: RSP: 250-mx.google.com at your service, [216.15.151.93]
Line 9: CMD: MAIL FROM:<[email protected]> SIZE=943
Line 10: RSP: 250 2.1.0 OK m203-v6si8908464itm.99 - gsmtp
Line 11: CMD: RCPT TO:<[email protected]>
Line 12: RSP: 250 2.1.5 OK m203-v6si8908464itm.99 - gsmtp
Line 13: CMD: DATA
Line 14: RSP: 354 Go ahead m203-v6si8908464itm.99 - gsmtp
Line 15: RSP: 250 2.0.0 OK 1525751864 m203-v6si8908464itm.99 - gsmtp
Line 16: CMD: QUIT
Line 17: RSP: 221 2.0.0 closing connection m203-v6si8908464itm.99 - gsmtp
Line 18: Delivery for [email protected] to [email protected] has completed (Delivered)
Line 19: Removing Spool message: Killed: False, Failed: False, Finished: True
Line 20: Delivery finished for [email protected] at 10:57:43 PM [id:-1979091561003]
-
Lines 1 - 3 - The delivery process starts and issues the TO and FROM address.
-
Lines 4 - 8 - The server (sending the email) initiates the connection to the destination address (in this case Google ). Google then came back saying ‘at your service’, or in other words ‘ready to attempt delivery’.
-
Lines 9 - 12 - The server told the destination server what address is sending and what address is receiving and google came back verifying this was OK.
-
Lines 13 - 15 - The data (the entire message header, body, etc.) is transferred to the destination server to attempt delivery
-
Lines 16 - 18 - The process is ending and is stating that the delivery has been successful and shows the status ‘(Delivered)’.
-
Lines 19 - 20 - The delivery is now complete and the log is reporting the end of logging for this message.
So, the above example shows a successful message being delivered from our server to an @gmail.com hosted server. There may be cases where this can bounce and there may be additional information logged.
If the recipient server provides the reason for the block, bounce, etc. then that will be reported in the logs or in the bounce back (or both).
If you ARE the recipient server and the server is blocking an e-mail from another host, then the server should state the reason as well in this log… such as the total spam score being to high and being filtered / deleted / bounced, or if there is a content filter setup that is preventing the e-mail delivery due to a keyword, email address match, etc. causing the filter to activate.
The cause could also be due to the sending server IP Address being on a blacklist. If you grab the sending server IP Address from the delivery log you can do a blacklist check against that IP Address. A good tool to use is MXToolBox for blacklist checks, which checks most common public blacklist (doesn’t check all blacklist including private blacklist used by companies like Google, Yahoo, Hotmail, etc.).