Like any enterprise-class mail server, Carbonio CE carefully captures in a special log all actions occurring on the server, from sending emails and logging in to user accounts, ending with fatal error messages. A detailed log of server operation helps system administrators resolve various failures as quickly as possible, and also allows you to effectively investigate incidents related to the company’s information security. In this article, we will understand how logs are stored on the Carbonio CE server, how to read them correctly, and we will also understand how, thanks to the logs, you can track the path of specific emails in case of problems.
Where to find log files
All the main logs related to the operation of the mail server are stored in the /opt/zextras/log folder, and some of the logs can also be found in the /var/log folder.
The main log file is /var/log/carbonio.log, which collects information from several other log files at once. The remaining files located in /opt/zextras/log contain information about the operation of individual mail server nodes.
For example, audit.log contains information about successful and unsuccessful login attempts, clamd.log contains information about the operation of the antivirus, nginx.access.log logs connections to the Carbonio CE proxy server, and mailbox.log stores information about the operation mail storage.
As a rule, it is /opt/zextras/log/mailbox.log and /var/log/carbonio.log that are the main log files that administrators use when troubleshooting various errors and problems that occur on the server.
How to read log files
All Carbonio CE log files are human readable records in English. Depending on which log file you open, the entries in them can store different information.
For example, the entries in the carbonio.log log file after sending the message would look like this:
Here we see the timestamp, the name of the server on which the event occurs, the name of the service that generated the entry, and the message itself. Depending on which service and under what conditions created the entry in the log, they may look different.
And this is how the same event looks in the mailbox.log log file. The main difference here is that all messages have their own severity level. There are 5 levels in total:
FATAL – this level means the occurrence of an error that is incompatible with the further operation of the server. Among them, for example, loss of connection to the MySQL database.
ERROR – this level indicates the occurrence of errors that allow the server to continue working or concern a specific user. For example, an error occurs when the index data of one mailbox is damaged, or when an email cannot be deleted from the mailbox.
WARN – this level means potentially dangerous situations that can usually be corrected or even ignored, but it is still better for the administrator to be aware of them. The WARN level is usually marked with messages about failed login attempts.
INFO – this level of log records contain information about the performance of certain operations on the server. For example, they mark messages about the successful start of the server, the creation and deletion of accounts, and so on.
DEBUG – this entry level is disabled by default and is commonly used for server debugging and used by developers to troubleshoot various issues.
Record levels make it very convenient to find error messages that occur.
Another handy way to find the error is to run sudo cat /opt/zextras/log/mailbox.log | grep exception
As already mentioned, the audit.log file contains information about users logging into the web client, with information about successful logons being stored at the INFO logging level, and information about unsuccessful logons being stored at the WARN logging level. In the file itself, it looks like this:
As you can see, in addition to the login failure warning, additional information is displayed about why the login failed. In our case, an incorrectly entered password was the cause of the error.
Since Postfix writes all the logs to one file, the entries for different messages are constantly interleaved. And therefore, when a letter does not arrive for some reason, it can be difficult for the administrator to track the path that it took and what caused its delivery failure. To facilitate this task, the utility built into Carbonio CE allows zmmsgtracewhich allows you to concatenate records related to one particular message.
Initially, the zmmsgtrace binary is located in the /opt/zextras/libexec folder. In order not to write the full path each time it is used, you can make a symbolic link to it using the command
sudo ln -s /opt/zextras/libexec/zmmsgtrace /opt/zextras/bin/zmmsgtrace.
After that, go to the Carbonio CE command line and run the command with the required parameters.
zmmsgtrace without parameters will display all message logs stored in /var/log/
zmmsgtrace -s firstname.lastname@example.org displays all messages sent by the user email@example.com. In turn, the team
zmmsgtrace -r firstname.lastname@example.org displays all messages containing email@example.com is the recipient.
Also, this utility supports the output of logs for a certain period and regular expressions:
zmmsgtrace -time 20220214,20220218– will display data on all letters for the working week from February 14 to February 18, 2022.
zmmsgtrace -s '^z' -r '@example.ru$'– displays all messages sent by accounts whose name starts with z and the recipient’s account name contains the @example.ru domain.
In addition, zmmsgtrace supports searching for a message by ID using the parameter
-ias well as by the ip-address or name of the sender’s or recipient’s mail server using the parameters
If the output of this command is quite voluminous, you can use the function of saving information to a text file, for example, the command
zmmsgtrace -time 20220214,20220218 > /tmp/zimbralogs.txt saves data on all letters for the working week from February 14 to February 18, 2022 to the /tmp/zimbralogs.txt file.
For all questions related to Zextras Suite and the commercial version of Carbonio, you can contact Zextras Representative Ekaterina Triandafilidi by email firstname.lastname@example.org.