When did your company start working on developing a mail server?
Work on the server has been going on for about 4 years. We didn't come to writing it right away. The fact is that before that our company was engaged in system integration based on Linux solutions. Naturally, in our work, we primarily relied on OSS (Open Source) solutions. We have been engaged in integration for more than 20 years and, of course, we are well aware of all the pros and cons of existing solutions. Something was definitely pleasing, something had to be fought.
Therefore, the first thing we did was a plugin for the Exim mail server. However, the community refused to accept our code into the upstream because it did not fit into the roadmap. Then the idea came to write the server ourselves. Starting work, we clearly saw the goal in front of us, but we were not sure that we could implement it. Therefore, the first version of the server was written in Python. Actually, hence the name of the server: Python - Python, Tegu - lizard. In general, relatives. Having worked out all the main ideas in Python, we rewrote the entire server again in the compiled language GoLang. But we got used to the working name and left it as TEGU. The first load tests and the first implementations showed that the ideas were correct. We like what happened.
How long did such a development take?
The work itself from prototype to today took 4 years. Probably, it could have been stretched out, but enthusiasm spurs, so they often worked at night, and 20 hours a day because it "doesn't let go" :)
What equipment is suitable for your server, and what will be the most effective?
We compile the code for two architectures X86-64 and AArch64 (ARM64) (this also includes domestic Baikal processors). There is a desire to compile for Elbrus, we do not have our own server on Elbrus yet, but it will be in the future.
Your server runs under the Linux OS. Does this server support all Russian Linux developments and which of the Russian Linux is the most optimal for your server?
One of the features of the server is that it does not depend on the operating system's package base. The server is monolithic and uses nothing but the GLIBC system library. Hence the only compatibility requirement - GLIBC version not lower than 2.28. Thus, we are compatible with all Linuxes, including, of course, all domestic ones.
When was your server registered in the “Unified Register of Russian Programs for Electronic Computers and Databases”?
We were in no hurry with the register, understanding the responsibility of working with government customers. The first implementations were carried out among commercial companies. Therefore, the first edition appeared in the register in March 2021.
How many users is the free (FreeWare) version of your product designed for?
The free version of TEGU Free has no restrictions on any parameters. More precisely, we do not limit these parameters in any way, but it is built according to the "classical" architecture. That is, the computational code and data are stored on one computational node. At the same time, the data is stored in the Maildir format, which is standard for mail servers. It is the file storage system that imposes the restriction. With a large number of threads (and requests to the storage system), conflicts arise when accessing files. If the file is locked at the time of access, the result of the access is unknown. Since transactionality cannot be ensured at the file level, such an architecture easily loses consistency (is destroyed) at high loads. This empirically calculated threshold occurs at approximately 1000-2000 users. We do not recommend using Maildir at such loads. Actually, that is why in TEGU Enterprise we completely abandoned file storage in favor of the Postgres DBMS.
Has your high-load server been tested for the maximum number of users? All versions of the server undergo testing on a load stand. This is fundamental in the development of a high-load application (HLA). We must be sure that the changes we have made do not lead to a loss of performance. Therefore, the load stand is always working. As a rule, we emulate a load of 400 thousand users on the stand. The figures we receive indicate that the load can be increased further, but more equipment is simply needed for this. In real commercial implementations, everything is somewhat more modest. At the moment, the largest system on TEGU includes 26 thousand users.
Please, a few words about the CloudNative approach you use…
CloudNative is not a panacea. You need to understand well what goals we want to achieve. Let me explain with an example. Classic servers are cut into MTA (transport agent) and MDA (delivery agent). Often, different agents are written by different vendors. Example: Postfix and Dovecot (ruthlessly cloned by our developers). Why? No one knows the answer now.
The reason is that the mail format that is familiar to us today was not so recently. There were SMTP-incompatible systems from Lotus, Novell, etc. That is why then it was necessary to install several transport agents and one delivery (storage) agent. Now it is decisively an atavism that interferes. But to do it in a new way, you need to rewrite everything.
But to separate the system along the line of executable code and storage system, to separate the code of the server itself from the web client - this is a positive solution that allows you to competently implement transactionality, fault tolerance and redundancy, and balance loads.
How is data recovery ensured in case of failures?
It should be said that the TEGU computing node does not store any information locally. Configuration, temporary queues, message database, etc., all this is stored in the DBMS. A failure on the side of the computing node is not critical. We did not write the storage system at all, as mentioned above, we use one of the best DBMS - Postgres. Therefore, clustering, redundancy, backup and recovery are carried out by means of the DBMS. Many thanks to our colleagues for this. And in particular to our domestic colleagues from Postgres Pro.
How do you assess the information security of your mail server?
Let it sound immodest, but high. Practice has already proven this. But there is no focus here, the reason is in the architecture.
- The use of monolithic code excludes the possibility of code replacement.
- Non-use of a multi-level architecture reduces the attack surface by orders of magnitude.
- The use of an asynchronous request processing model does not allow you to influence with DDOS.
- Another factor is the meticulous adherence to RFC. Those who start using TEGU always pay attention to this. Actually, it is the most stringent RFC requirement that allows the server to fight application-level attacks.
How does your partner Positive Technology help you ensure the protection of Tegu?
Here, rather, the merit of the DLP system. We only provide the interface, compatibility for this.
What does your server gain from the fact that it does not use a multi-layered architecture?
The fact that we wrote everything necessary ourselves. Yes, the server is managed using a GUI web interface. But you don't need to look for Apache or Nginx components in it. They are not there, we wrote it ourselves. And so in everything.
You have confirmed the compatibility of Tegu with «1C:Document Management 8». Do you plan to continue working with the company «1C» and confirm compatibility with other products of this company?
Yes, this work is underway. And partners from the 1C Distribution channel help us. They check, implement, shoot videos.
Your mail server is compatible with the R7-OFFICE office suite. Are there any plans to improve compatibility with other Russian office suites?
We try to be friends with everyone, because everyone will benefit from this, but first of all our users.
What needs to be done to migrate from an old mail server to Tegu?
Here you should distinguish situations. There are two options:
- Old mail server on its own equipment and under the client's own management (well, let's say MS Exchange);
- Migration from a cloud server (MS Office 365, Yandex etc).
But in the case of using TEGU, everything is simple. It is necessary to follow the methodology we have proposed and fill in only four fields in the migration dialog. It will be performed smoothly and without problems.
How did you manage to provide the ability to serve users from different organizations in isolation within one instance of the server? The explanation for this is again the chosen architecture. Using a DBMS to cut data along any axis is very easy. But compare this with file storage - it is really difficult and potentially unsafe there.
You provide support for server equipment of domestic production. Which Russian servers have you already installed Tegu on?
What is a domestic server - a legal question :) The requirements are constantly changing, so I will answer this way - as I wrote above, x86_64 and AArch64 (ARM64) architectures are supported. All Baikal processors are supported by us. Porting to Elbrus is still in the future.