Почтовый сервер

Минимизация рисков

По мере роста организации, увеличения числа сотрудников и изменений в законодательстве требования к почтовому сервису будут возрастать. При использовании общедоступных сервисов или хостинг-услуг рано или поздно возникнут технологические ограничения, создающие риски для безопасности и управляемости корпоративной переписки.

Для их предотвращения следует придерживаться нескольких базовых правил:

1. Необходимо обладать всеми юридическими правами на доменную зону (домен), к которой относятся используемые адреса электронной почты, а также иметь полный, актуальный и контролируемый доступ к её управлению.
2. Административный доступ к почтовой системе должен быть разделён и ограничен кругом доверенных лиц и/или предоставляться на контролируемой и временной основе.
3. Физический доступ к серверному оборудованию должен быть ограничен и строго регламентирован.
4. MX-записи, PTR-записи обратной зоны, а также TXT-записи SPF, DKIM и DMARC, включая подпись зоны DNS, должны регулярно проверяться и поддерживаться в актуальном состоянии.
5. Использование многофакторной аутентификации (MFA) должно быть обязательным для всех пользователей без исключения.

Общедоступные почтовые сервисы

Использование адресов электронной почты в доменах общедоступных сервисов (@gmail.com, @icloud.com, @mail.ru, @yandex.ru и аналогичных) для служебной переписки противоречит корпоративным стандартам и создаёт существенные риски. Ключевым из них является возможная утрата доступа к почтовому ящику и, как следствие, компрометация деловой переписки. Применение таких сервисов в служебных целях в ряде случаев может рассматриваться как нарушение внутренних регламентов.

Почтовый ящик в общедоступном сервисе может быть удалён по решению владельца домена. Это может произойти, например, по экономическим причинам или в случае изменений в законодательстве, когда оператор домена не готов будет нести ответственность за пользователей. Известные примеры таких ситуаций произошли в 2022–2024 годах с доменами @ngs.ru, @e1.ru, @74.ru, @chita.ru и @nn.ru.

Некоторые сервисы могут стать недоступны по решению регуляторов из-за нарушений других пользователей — примером является @protonmail.com.

Технологические ограничения по реализации многофакторной аутентификации могут также привести к потере доступа — примеры: @gmail.com, @outlook.com, @icloud.com.

Корпоративный домен

Использование выделенного домена позволяет не только выбирать почтовый сервис или задействовать собственные серверы, но и обеспечивать отказоустойчивость за счёт использования нескольких сервисов с разными приоритетами (при помощи MX-записей в DNS).

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

Использование IDN-доменов (например, компания.рф) для почтовых сервисов не допускается, так как они могут вызывать проблемы с доставкой писем, совместимостью почтовых клиентов и фильтрацией спама.

При выборе зоны для регистрации домена (.ru, .com, .moscow, .spb.ru) рекомендуется:

1. Убедиться в наличии юридических прав на регистрацию домена в выбранной вами зоне, а также в способности доказать эти права. Для некоторых зон регистрация доступна только гражданам или постоянным резидентам (.us, .ca, .eu, .fr, .ee, .az), других требуется наличие представителя в стране (.ae, .de, .tr, .mx, .jp, .sa, .id).
2. Убедиться в наличии юридических прав на конкретное доменное имя (бренд), чтобы избежать споров со стороны третьих лиц.
3. Проверить возможность выполнения технических требований регистратора (например, поддержку DNS-зоны на серверах внутри страны для .by и .kz).
4. Избегать регистрации доменов в зонах массового расширения (2012-2020). Эти домены принадлежат коммерческим компаниям, не имеют проверенной истории, стоимость их продления может резко меняться, а сами зоны со временем могут быть ликвидированы.
5. Учитывать географическую и поисковую локальность доменных зон (.ru, .by, .moscow, .tatar) и избегать регистрации доменов третьего уровня (.com.ru, .spb.ru, .tomsk.ru) там, где возможна регистрация домена второго уровня; исключением являются зоны с иерархической моделью, где регистрация второго уровня не предусмотрена (например, в Японии — .co.jp).

Коммерческий сервис и облако

При наличии формализованных соглашений об уровне сервиса (SLA), соглашений о конфиденциальности (NDA) и согласованности с внутренними службами допустимо использовать коммерческие почтовые платформы для корпоративного домена — например, Яндекс 360, VK WorkSpace (@mail.ru) или почтовые сервисы хостинг-провайдеров (Reg.ru, TimeWeb, masterhost и т.д.).

По разным оценкам на начало 2026 года, около 70–85 % компаний в мире используют облачные почтовые сервисы. При этом среди средних и крупных организаций доля таких решений не превышает 13–15 %, а в России эти показатели ещё ниже.

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

Операторы почтовых сервисов вынуждены вводить ограничения на исходящую почту — от 100 писем за раз и до 500–2000 в сутки. В противном случае существует значительный риск включения диапазонов адресации провайдера в стоп-листы (RBL), что приведёт к деградации сервиса для всех пользователей. При этом потребности в таких объёмах рассылки вовсе не означают СПАМ — это может быть уведомление контрагентов об изменении банковских реквизитов, обновлении цен на продукцию или ежегодная рассылка актов сверки в рамках инвентаризации перед годовым отчётом, которую организации обязаны проводить.

Облачный сервис и услуги хостинга, как правило, не предусматривают полноценного сервиса общих папок и не поддерживают модель коллективного доступа к почтовым ящикам и структурам хранения.

Кроме того, сервисы с единой политикой обработки почтового трафика для всех доменов существенно ограничены в администрировании и не предусматривают:

• инструментов управления автоматическими блокировками и репутационными фильтрами, включая возможности выборочных исключений для отдельных IP-адресов, серверов и доменов;
• управления размером и типом вложений;
• управления заголовками писем;
• доступа к очередям сообщений и параметрам временной доставки;
• доступа к глобальному журналу событий, необходимому для контроля входящих SMTP-подключений.

Microsoft Exchange

Exchange On-Premises — это современный термин для локальной версии Microsoft Exchange Server — монолитной экосистемы, которая помимо стандартного функционала электронной почты и адресной книги забирает на себя всё, что касается календаря, планирования встреч, ведения задач и заметок.

Это один из самых технологически сложных продуктов в мире. Его администрирование требует значительного практического опыта и широкого набора компетенций: понимания архитектуры Exchange в целом, гибридного развёртывания, взаимодействия с Active Directory, механизмов аутентификации, управления группами и почтовыми потоками.

Безопасность

С точки зрения безопасности владение Microsoft Exchange означает концентрацию максимального объёма критических данных и сервисов.

В январе 2021 года по меньшей мере десять хак-групп атаковали серверы Microsoft Exchange Server через ошибки ProxyLogon по всему миру. По разным оценкам, количество скомпрометированых почтовых серверов превысило сотню тысяч. Первый патч от Microsoft был выпушен лишь 2 марта того же года.

По отраслевой практике, восстановление сложных корпоративных почтовых платформ (включая Microsoft Exchange) после серьёзных киберинцидентов может занимать от 2–3 недель до нескольких месяцев. В ряде случаев компании выбирают отказ от восстановления и переход на другие решения, используя облачные сервисы как временную меру на период миграции.

Лицензирование

Exchange On-Premises — коммерческий продукт, распространяемый по модели подписки Exchange Server Subscription Edition (SE) с ежегодной оплатой:

• Standard (до ~250 пользователей): сервер — $630, пользователь — $79;
• Enterprise (свыше ~250 пользователей): сервер — $3620, пользователь — $79.

Цены указаны исключительно в ознакомительных целях и основаны на данных, размещённых на сайте DSA ICT Services & Software B.V..

Решение на базе открытого ПО

Postfix, Dovecot и Roundcube образуют основу автономной и масштабируемой почтовой платформы, не обременённой лицензионными ограничениями и поддерживающей всё необходимые современные технологии, включая:

• поддержку неограниченного числа доменов с полной изоляцией;
• алиасы, списки рассылки и гибкую маршрутизацию;
• локальные учётные записи и/или централизованную аутентификацию с использованием Microsoft Active Directory;
• двухфакторную проверку подлинности (TOTP/SMS);
• общие почтовые папки для совместной работы;
• веб-интерфейс — современный, интуитивно понятный, адаптивный (ПК, планшеты, мобильные телефоны).

В зависимости от требуемого количества одновременных пользователей архитектура решения может различаться. Это обусловлено различными подходами к масштабированию ключевых компонентов платформы — Postfix, Dovecot и веб-интерфейса почты.

Postfix и Dovecot изначально спроектированы с учётом горизонтального и вертикального масштабирования и поддерживают распределение нагрузки.

Веб-платформа Roundcube проверена временем, однако при нагрузке от одной до трёх тысяч одновременных пользователей требует выделенной инфраструктуры и изоляции. При необходимости она может быть заменена на решения, такие как SnappyMail, SOGo или Zimbra.