Проект

Общее

Профиль

Wiki en »

TEGU server concept

Choose a language: RU | EN | ZH

Table of contents

TEGU is a fully Russian server software, which is a modern mail server running on customer's equipment (on-premise) under Linux OS, allowing to organize exchange with any mail servers using SMTP protocol and supporting mail clients using IMAP/SMTP protocol. The server implements address books using CardDAV protocol and calendars using CalDAV protocol. The server supports LDAPv3 and Milter integrations.

Tegu is of fully Russian origin, developed from scratch and does not have any borrowings. The server is registered in the Russian software registry and supports the entire line of domestic operating systems and hardware architectures.

Server features

Among the features of the server are the following:
  • TEGU is a highly loaded application designed to handle up to 400 thousand users;
  • TEGU is not a package, but a monolithic application representing one single file;
  • The server implements an asynchronous event processing algorithm, which is important for performance and resistance to attacks;
  • All of the above methods, formats and protocols are implemented independently in TEGU. The server does not use any external applications or libraries;
  • The asynchronous and monolithic nature of TEGU significantly reduces the attack surface, makes its operation stable, independent of the OS package base, and undemanding on hardware resources;
  • TEGU does not synchronize directory server data and cannot compromise it;
  • TEGU does not check for updates, does not send debugging data to the developer, and does not send any undescribed data.

Server editions

The TEGU server comes in three editions, which can be compared using the following table:

TEGU Free TEGU Pro TEGU Enterprise
Architecture Single-unit server with MailDir storage with local user base Single-unit server with MailDir storage with the ability to interoperate with directory servers Simestric high load fault-tolerant cluster with Postgres storage
Configuration Mail server Mail server
Integration with directory servers
 Mail server
Integration with directory servers
Address book server
Calendar server
Redundancy
Scalability (cluster)
License Freeware (free) Commercial license Commercial license
Feature Related Software Required:
PostgreSQL DBMS or
Postgres Pro

Server data architecture

Server topologies can be very different. To design a system, it is important to understand the basic entities of the server (how the storage of different types of data and the methods of accessing them are organized).

The TEGU server in its operation uses three stores for:
  1. Configuration storage.
  2. SMTP queue storage.
  3. Storage of data (mail messages, calendars, address books, etc.).
Stores can be local or network.
  • SQLite on a local disk or Postgres on a network resource can be used to store configuration and queues.
  • The server can use MailDir on a local disk or Postgres on a network share to store data.
To describe the storages, use:
  • Local repositories are specified by a directory description. For example: /opt/go-tegu/data .
  • Network repositories are specified by specifying the server, port, database name, and access account.
You can change any of these parameters at any time.
  • For example, if you change the “Configuration Database”, the server will switch to a new profile. Let's assume that one profile is proxy-based, and the second profile is proxy-free, but with an integrated antivirus server connected via Milter protocol. Switching between profiles will allow you to instantly change server parameters.
  • By combining parameters you can achieve more complex configurations. Suppose your nodes are located in different data centers. Each of the servers uses its own configuration database, its own SMTP queues, but they all use a single data store. It is clear that there can be many such configuration options.

The combination of storages can be any with observance of the following principles:

TEGU Free TEGU Pro TEGU Enterprise (1 node) TEGU Enterprise (cluster)
Configuration Database Local SQLite Local SQLite Local SQLite or Postgres DBMS Postgres DBMS
SMTP queue Local SQLite Local SQLite Local SQLite or Postgres DBMS Postgres DBMS
Data Store Local MailDir Local MailDir Local MailDir or DBMS Postgres Postgres DBMS

The number of server databases is unlimited.

Internet domains of the server

The server can serve any number of Internet domains.
It is important that each Internet domain must have its own storage (in any combination of types) pre-created.

User authentication mechanisms

The server can use two types of sources for user authentication:
  1. Local user base (stored in JSON format);
  2. Directory servers (LDAP v3, including Windows AD).

An unlimited number of user base sources in any combination of types can be used within a single Internet domain.
All user base sources are used as a single (unified) base to form a global address book (in terms of Internet domains).

TEGU Free TEGU Pro TEGU Enterprise (1 node) TEGU Enterprise (cluster)
User bases Local JSON Local JSON + LDAP v3 Local JSON + LDAP v3 LDAP v3

Server Roles

At the program level, the server is implemented as a single monolithic executable.
The server can fulfill the following roles (all or partial combinations of them):
  • Operating as an MTA (integration with an external MDA);
  • Acting as an MDA (integration with an external MTA);
  • Receiving mail via relay;
  • Sending mail via smart host;
  • Integration with antivirus application installed as a proxy or via Milter protocol;
  • Working together in a group with an external server (serving users of the same domain or directory server);
  • Work in “soft migration” mode from an external on-premise or cloud server;
  • Address book server using CardDAV protocol;
  • Calendars server using CalDAV protocol.

Using Milter

The server at the SMTP session stage supports the Milter protocol, which can be used for a variety of purposes.
The main purposes for using Milter are:
  • Integration with antivirus applications;
  • Integration with anti-spam applications;
  • Integration with ProcMail handler;
  • Integration with proprietary milter agents.

The server transfers control to the milter program at the stage of receiving and sending messages.
Milter cannot be used when delivering messages locally.

Redundancy and scalability

Redundancy and scalability are implemented in the TEGU Enterprise edition.
Redundancy and scalability is achieved by utilizing multiple compute nodes of the server running in parallel and independently.
The server is fully operational as long as at least one compute node is running.

The DBMS redundancy and scalability is achieved by means of the Postgres DBMS. A cluster of Master + Slave or Master + Master type can be realized.

The redundancy of the TEGU Free and TEGU Professional editions is not provided (but can be partially implemented by virtualization means). TEGU Free and TEGU Professional editions are not scalable.

Server backup

Backup depends on the combination of the server database types you use. Most often, the operating organization already has backup tools (used for other services) or has some preference for their selection. With TEGU, you can use any tool capable of copying file structures and/or Postgres DBMSs without exception.

Management Interface

The server is managed through a graphical web interface.
Server administration is described in detail in the following articles.

The interface is unified for both the administrator and the server users.
Using their own account, mail users can use the web interface to find out the client software configuration parameters, configure server-side processing rules, auto-reply rules, create and configure access to public folders, create and configure access to calendars, etc.

The server management interface does not contain colorful dialogs designed for wow-effect. The dialog with the administrator and user is designed for daily convenient work. For this reason, it is ascetic, thoughtful and concise. Each control element contains a description (a link to the documentation that can be opened on request).

Documentation

The documentation, which you are reading now, is a joint work, in which the team of developers and our users participate. Your questions and comments formed the basis of its structure and content. Every appeal to us, which reveals the shortcomings of the documentation, is immediately filled by us in these articles. We are waiting for thoughtful reading from our users, and secondly (but only secondly) for your questions and comments.

We wish you a pleasant work at TEGU!