Коллеги, в этой статье мы бы хотели поделиться с вами стратегией развития TEGU Enterprise на ближайшую перспективу.

Разработка помощника планирования (выполнено 100%)

Помощник по планированию — это функция, предназначенная для упрощения планирования встреч. Вы можете не только увидеть доступность каждого участника собственной компании (такая функция к примеру есть в MS Outlook), но также мгновенно согласовать встречу с внешними сотрудниками. Планировщик также может помочь в поиске и бронировании различных ресурсов (переговорных комнат, систем бронирования парковок, систем ВКС).

Разработка собственного почтового межсерверного протокола 2TMTP (выполнено 100%)

Электронная почта при своем возникновении была мало приспособлена для передачи информации потому, что в сущности она копировала классическую бумажную почту.
Это касается и принципов адресации, и составления сообщения. Типичным примером является подпись, в которой мы выражаем свое уважением и далее перечисляем все свои контакты в произвольном стиле. Существовал даже специальный этикет электронной почты, рекомендующий правила обращения, составления, цитирования и прощания. Сегодня такой стиль де-факто не применяется и приводит к замусориванию и трудностям поиска.

К передаче файлов электронная почта была не приспособлена вовсе. В результате появились сложные механизмы кодирования и инкапсуляции бинарных файлов, что увеличило размер, затруднило структуру, создало предпосылки для вирусов и т.п. При всех сложностях максимальный размер передаваемого файла так и остался неприемлемым.

Еще хуже обстоят дела с календарями и адресными книгами. Для этих сервисов вообще нет собственного протокола, было решено использовать популярный на тот момент HTTP (ставший DAV-ом).
Отсюда ограничения функциональности и размера, которые решительно не позволяют применять его в корпоративной среде.Давайте тезисно перечислим основные проблемы стандартных протоколов:

• Низкая производительность
• Низкая безопасность
• Ограничение размера сообщения
• Ограничение размеров календарей и адресных книг
• Недостаточная функциональность
• Отсутствие протокола управления профилем
• Отсутствие протокола управления пользовательским приложением
• Отсутствие возможности аутентификации для доверенных ресурсов
• Сложный и неудобный механизм уведомлений о доставке
• Устаревший (непригодный) формат MIME
• Отсутствие механизма отзыва сообщения
• Большое количество используемых сетевых привелегированных портов
• Атомарный формат передачи сообщений
• Отсутствие в стандарте статусов и контактов пользователя

Таким образом, становится очевидным, что без нового протокола развитие почтового сервиса невозможно.

Какие функции должны быть реализованы в современной почте:

• MDM (Mobile Device Management) via Bring Your Own Device
• Управление правилами и настройками профиля на серверной стороне
• Клиент-серверное взаимодействие календаря и адресных книг
• Выборка всех файлов, фотографий, видео, медиа, ссылок в выбранной переписке
• Поддержка данных неограниченного объема
• Автонастройка клиента
• Автоудаление клиента и данных
• Доступ ко всем сервисам по одному сетевому порту
• Серверная персонализация
• Удобное (как в ТГ) уведомление о доставке, прочтении и изменении сообщений
• Отзыв письма
• Пакетное взаимодействие между серверами
• Пересылка файлов неограниченного объема
• Специальное поле для стандартной подписи (как в ТГ)
• Специальное поле для статуса пользователя
• Новая структура письма (JSON)
• Мгновенная доставка почты (пушинг)
• Получение всей коллекции данных за одну транзакцию
• Развитое тегирование данных на стороне сервера
• Редактирование отправленного письма (версионность)
• Встроенный мессенджер

А что же со старым добрым IMAP/SMTP.
Естественно, что они остаются — их невозможно заменить как минимум на данном этапе развития.
Однако, если два хоста взяимно объявляют поддержку 2TMTP, то они переходят на новый протокол, забывая про старый.

Разработка собственных почтовых клиентов нового поколения

Необходимость в собственных клиентских приложениях достаточно низкая на данном этапе т.к. TEGU с реализацией IMAP/SMTP совместим со всеми существующими стандартными почтовыми приложениями.

Однако с появлением функциональности, описанной в протоколе 2TMTP, функций стандартных почтовых программ будет недостаточно. Понимая это, мы планируем разработку собственных клиентов для протокола 2TMTP. В ближайшее время будут опубликованы:

• Web-клиент
• Почтовый клиент TIMON для Linux (декстопное приложение)
• Почтовый клиент TIMON для Android (мобильное приложение)

Характерным в данном случае является тот факт, что почтовый веб-интрефейс не является классической IMAP/SMTP надстройкой над почтовым сервером (такой метод не позволяет реализовать все функции в полной мере), а неотъемлем частью сервера, использующей внутренний API для доступа к объектам. Такой способ значительно более функционален, повышает надежность и безопасность системы, а также является в разы более экономичным к аппаратным ресурсам.

Почтовый клиент TIMON использует собственный протокол 2TMTP, за счет которого реализуется не только классическая для почтовых серверов функциональность, но и значительно превосходит ее.

Реализация WebDAV хранилища файлов

Оборудовать сервер WebDAV хранилищем файлов с возможностью создавать как системные так и пользовательские папки, которые можно расшаривать в широком диапазоне времени и прав.

Портирование TEGU на аппаратную архитектуру LoongArch64 (выполнено 50%)

Китайская компания Loongson Technology разработала с нуля новую процессорную архитектуру LoongArch64, что позволяет использовать эти процессоры на объектах критической информационной инфраструктуры. Кроме того, процессоры уже запущены в массовое производство, в связи с чем их можно рассматривать как реальную альтернативу западным аналогам в нашей стране и за рубежом.

Завершение работ по реализации полной мультитеннатности (выполнено 90%)

Мультитенантность описывает программную архитектуру, в которой одна физическая установка может обеспечивать несколько логических установок. Каждая логическая установка обслуживает выделенную базу пользователей, называемую «клиентом».

Мы планомерно движемся в данном направлении и в настоящий момент осталось «разрезать» на теннантов только системный лог.

Управление доступом на основе ролей

Role Based Access Control (RBAC) — развитие политики управления доступом. Формирование ролей призвано разграничить уровни доступа администраторов почтовых систем.

Стратегия развития редакций TEGU

Обратите внимание, что активная разработка продуктов TEGU (Freeware) и TEGU Professional завершена. Это связано с тем, что мы считаем архитектуру на базе хранилища maildir безнадежно устаревшей. Поэтому мы сохраняем поддержку данных продуктов, однако разработку нового функционала в этих редакциях останавливаем.

Напротив, TEGU Enterprise ожидают серьезные изменения. Мы уже сообщали, что в ближайших версиях TEGU Enterprise больше не будет поддерживать хранилище Maildir. Этот атавизм мы пока еще поддерживаем для совместимости с теми, кто по каким то причинам все еще продолжает использовать устаревший тип хранилища, однако в документации процедура установки хранилище Maildir больше не описывается. Тем самым мы хотим пресечь установку этого типа хранилища в новых инсталляциях.

Выпуск собственного почтового клиента TMON ознаменует новую мажорную версию TEGU Enterprise 2. Условия получения данной версии сейчас согласовываются.

Для тех пользователей, кто пожелает остаться на версии 1, мы планируем выпустить TEGU v1 LTS (релиз длительной поддержки) со сроком 3 года. Функционально версия 1 развиваться не будет, но поддержка законодательства, консультирование и исправление ошибок будут обеспечены. Пользователи, для которых новая функциональность не является критичной, а издержки перехода необходимо минимизировать, могут остаться на версии 1 в течение срока поддержки.

Как улучшить TEGU

Мы не занимаемся доработками программы под конкретные проекты, но если ваше предложение будет интересно широкой аудитории, мы реализуем предложенную вами функцию — напишите нам: support@mbk-lab.ru