Разбираем, как Proxmox Mail Gateway встраивается в сетевую инфраструктуру, фильтрует спам и вирусы — и почему бесплатная версия вполне годится для реального использования.
Proxmox Mail Gateway — это почтовый прокси-сервер с открытым исходным кодом, который фильтрует входящую и исходящую почту до того, как она попадает на основной почтовый сервер. Он разворачивается как отдельная система между интернетом и внутренней инфраструктурой, принимая на себя первый удар: спам, вирусы, фишинг. Для организаций, которые держат почту на собственных серверах, это один из наиболее практичных способов выстроить защиту без переплаты за коммерческие решения.
Proxmox Mail Gateway работает как MTA-прокси: принимает SMTP-соединения снаружи, обрабатывает письма и передаёт их дальше — на Postfix, Exchange, Zimbra или любой другой сервер. Это не замена почтовому серверу, а фронтенд перед ним. На уровне DNS запись MX должна указывать на Proxmox Mail Gateway, а не на внутренний сервер.
Сетевая схема обычно строится по одной из двух моделей. В первой Proxmox Mail Gateway стоит в DMZ: публичный IP у него, внутренний почтовый сервер — за NAT или файрволом. Во второй оба сервера находятся внутри периметра, и фильтрация происходит до того, как письмо касается внутренних хостов. Вторая модель проще в реализации, но чуть уязвимее — внешний трафик всё равно заходит глубже в сеть.
Кластеризация в Proxmox Mail Gateway работает через встроенный механизм: несколько узлов объединяются в кластер, используют общую базу данных PostgreSQL и синхронизируют правила. Это важно, если нужна отказоустойчивость или балансировка нагрузки. Один узел при этом назначается мастером, остальные — репликами, хотя фильтрацию могут выполнять все.
Proxmox Mail Gateway слушает 25-й порт для приёма внешней почты — это стандарт SMTP, без которого входящая почта просто не дойдёт. Исходящая фильтрация, если она настроена, идёт через relay: внутренние серверы отправляют письма через Proxmox Mail Gateway, который проверяет их перед отправкой в интернет. Порт 587 (submission) в типичной схеме остаётся на основном почтовом сервере.
Веб-интерфейс управления доступен на порту 8006 по HTTPS — тот же порт, что у Proxmox VE, если вы знакомы с этой платформой. Это удобно в смысле унификации, но требует внимания при планировании сетевых правил: 8006 не должен быть открыт наружу без дополнительной защиты. На практике его закрывают для внешнего доступа и открывают только для администраторских подсетей.
Для карантина и пользовательских уведомлений Proxmox Mail Gateway использует собственный интерфейс на порту 8006 и может рассылать дайджесты — письма, в которых пользователь видит задержанные сообщения. Доставка этих дайджестов идёт через встроенный SMTP-клиент, и его нужно правильно настроить: иначе уведомления о спаме сами попадут в спам.
Обработка каждого письма в Proxmox Mail Gateway происходит последовательно через несколько слоёв. Первый — проверки на уровне SMTP-сессии: rDNS, HELO-валидация, greylisting. Письма от подозрительных отправителей могут быть отклонены ещё до того, как содержимое вообще будет получено. Это снижает нагрузку на следующие слои.
Дальше в работу вступает SpamAssassin и ClamAV — оба встроены в дистрибутив и не требуют отдельной установки. SpamAssassin проверяет заголовки, тело, репутацию домена и IP; ClamAV сканирует вложения. Pyzor и Razor (опциональные плагины SpamAssassin) подключают облачные базы хэшей известного спама — это полезно, но требует исходящего доступа к интернету с сервера фильтрации.
Правила в Proxmox Mail Gateway делятся на несколько уровней: глобальные, доменные и пользовательские. Пользователь может самостоятельно добавлять адреса в белый список через интерфейс карантина — это снижает нагрузку на администраторов. Любопытно, что правила применяются в строгом порядке приоритетов: пользовательское правило не может отменить глобальную блокировку домена, если администратор это не разрешил.
Proxmox Mail Gateway совместим с любым SMTP-сервером, который принимает relay-соединения. На практике чаще всего его ставят перед Postfix или Microsoft Exchange. В случае с Exchange важно правильно настроить receive connector, чтобы сервер принимал письма только от IP-адреса Proxmox Mail Gateway — иначе защита теряет смысл.
Для Active Directory и LDAP есть встроенная интеграция: Proxmox Mail Gateway может проверять, существует ли получатель в каталоге, до приёма письма. Это называется recipient validation и позволяет отклонять письма на несуществующие адреса на этапе SMTP-диалога, не создавая bounce-сообщений. Настройка требует доступа к LDAP-порту (389 или 636 для LDAPS) с сервера фильтрации.
API Proxmox Mail Gateway позволяет управлять настройками программно — создавать правила, получать статистику, управлять карантином. API использует тот же токен-based механизм авторизации, что и Proxmox VE. Это полезно при автоматизации: например, при создании нового почтового домена можно скриптом добавить соответствующую конфигурацию в Proxmox Mail Gateway.
Плюсы:
Минусы:
Перед запуском стоит убедиться, что внутренний почтовый сервер настроен принимать письма только с IP-адреса Proxmox Mail Gateway. Это ключевой момент: если Exchange или Postfix принимают соединения со всех адресов, фильтрация легко обходится прямым подключением. Также имеет смысл сразу настроить TLS для SMTP-соединений между Proxmox Mail Gateway и внутренним сервером — трафик внутри периметра тоже стоит шифровать.
Вы также захотите заранее продумать политику greylisting применительно к вашим партнёрам и критичным отправителям. Временная задержка письма из-за greylisting может быть болезненной, если речь идёт о транзакционных уведомлениях или письмах от сервисов, которые не повторяют доставку. Для таких отправителей имеет смысл сразу составить whitelist по IP или домену.
| Сценарий | Что важно |
|---|---|
| Входящая почта из интернета | MX указывает на Proxmox Mail Gateway, порт 25 открыт |
| Фильтрация исходящей почты | Внутренние серверы шлют через relay на Proxmox Mail Gateway |
| Интеграция с Exchange | Receive connector ограничен IP-адресом Proxmox Mail Gateway |
| Проверка существования получателя | LDAP/AD-интеграция, recipient validation на этапе SMTP |
| Управление карантином | Пользователи работают через веб-интерфейс, дайджесты по расписанию |
| Кластеризация | Несколько узлов, общая PostgreSQL, один мастер |
| Обновления без подписки | Публичный репозиторий, возможна задержка патчей |
Да, бесплатная версия полностью работоспособна. Ограничение касается только источника обновлений: без подписки используется публичный репозиторий, обновления в котором могут появляться позже, чем в корпоративном. Для большинства небольших организаций это приемлемый компромисс.
Каждый домен настраивается отдельно в разделе Mail Proxy: указывается целевой сервер доставки, правила фильтрации, настройки TLS. Правила можно создавать на уровне домена, не затрагивая другие. Если домены обслуживаются разными серверами — каждый маршрутизируется независимо.
Внешние SMTP-серверы будут повторять попытки доставки согласно собственным политикам — обычно в течение нескольких дней. Письма не теряются, но задерживаются. Для критичной
