Proxmox Mail Gateway: защита корпоративной почты от спама

Где находится шлюз и чего он не заменяет

• Входящие: интернет → PMG на TCP25 → фильтрация → внутренний почтовый сервер.
• Исходящие: доверенный почтовый сервер → PMG на внутренний TCP26 → проверка/подпись по политике → интернет или согласованный smart host.
• Почтовые клиенты: работают со своим сервером и его аутентифицированной submission-службой; PMG 26 не является заменой пользовательскому SMTP AUTH.
• Администратор: управляет шлюзом по отдельному защищённому маршруту.

PMG не хранит корпоративные ящики как полноценный mailbox-сервер, не предоставляет пользователям обычную IMAP-почту и не заменяет права в Exchange, Postfix/Dovecot, Zimbra, CommuniGate Pro, Mailcow или другом выбранном решении. Объём интеграции с каждым продуктом определяется его SMTP-коннекторами и политикой доступа.

Это практическое продолжение темы антиспам-защиты корпоративной почты.

IP-план и матрица портов для примера

Внешний IP и example.net документационные. Для production нужны рабочий публичный адрес либо согласованный SMTP-релей, доступность TCP25, корректные DNS/PTR и политика провайдера. В облаке исходящий 25 может быть ограничен, а PTR настраивается владельцем адреса — выясните это до переноса MX.

Не открывайте внутренний 26 в интернет. При включённом IPv6 проверьте отдельный адрес, маршрут и firewall: публикация AAAA без работающего IPv6 может создавать выборочные задержки доставки.

До установки: что собрать у владельца почты

1. Почтовые домены, aliases, группы, пересылки, catch-all и правила обработки несуществующих получателей.
2. Все исходящие источники: основной MTA, CRM/1С, сканеры, сайт, системы рассылок и SaaS. Определите, какие из них идут через шлюз, а какие отдельно.
3. Текущие MX/A/AAAA/PTR, SPF, DKIM, DMARC, сертификаты и TTL.
4. Маршруты коннекторов, лимиты размера письма, тайм-ауты, ограничения провайдера и резервные пути.
5. Владельца карантина, срок реакции на ложное срабатывание, порядок выпуска и хранения писем.
6. Резервную копию, окно изменения DNS, контроль очередей и план возврата.

Нельзя сначала переключить MX, а затем выяснять адрес внутреннего сервера. Для пилота выделите тестовый домен/получателя либо согласованный маршрут без перехвата всей рабочей почты.

Шаг 1. Установите PMG и проверьте основу

Скачайте ISO с официальной страницы Proxmox, сверьте контрольную сумму выбранного файла. Например, для локального переименованного ISO на Windows:

Get-FileHash -LiteralPath 'C:\Install\proxmox-mailgateway.iso' -Algorithm SHA256

В установщике выберите только подготовленный системный диск новой ВМ/сервера, задайте генерируемый пароль администратора, FQDN, статический IP, шлюз и DNS. Выбор диска установщиком может уничтожить прежние данные: эту процедуру не выполняют поверх рабочего mailbox-сервера.

Для небольшого пилота можно рассмотреть 2 vCPU,8ГБ RAM и отдельный диск под систему/очереди с запасом. Это плановая отправная точка, не гарантия числа ящиков: нагрузку определяют количество и размер писем, вложения, одновременная обработка и карантин.

pmgversion -v
hostname -f
ip -br address
timedatectl status
df -h
systemctl status postfix pmg-smtp-filter pmgproxy pmgdaemon --no-pager
ss -ltnp

Проверьте фактическую версию, время, имена и listeners. Репозитории должны соответствовать ветке и подписке. Используйте штатный раздел Repositories и официальные источники; не отключайте проверку подписи пакетов ради ошибки enterprise-доступа. Справка по версии — pmgversion.

Шаг 2. Защитите управление и сертификаты

Веб-интерфейс штатно использует HTTPS8006. Разрешите его и SSH только с management/VPN, настройте персональные административные записи, роли и доступную двухфакторную аутентификацию. Пароль root/администратора хранится отдельно от учётных данных почтовых пользователей.

• Установите доверенный сертификат для управления и проверьте правильное имя/цепочку/срок.
• Учитывайте, что SMTP и API/GUI используют разные назначения сертификатов и настройки. Замена одного не подтверждает замену другого.
• Для ACME согласуйте способ проверки домена и продление; DNS API-токен ограничьте нужной зоной.
• Не публикуйте весь административный 8006 только ради пользовательского карантина. Отдельно спроектируйте его URL, аутентификацию и доступ.

Настройку выполняют через GUI/API/штатные инструменты PMG. Не считайте любой DMARC fail автоматическим SMTP reject: проверьте фактические правила и действия своей конфигурации. Сгенерированные main.cf и master.cf Postfix нельзя считать независимой постоянной конфигурацией: изменения могут быть перезаписаны. Для необходимых нестандартных шаблонов используйте поддерживаемый механизм и сопровождение.

Шаг 3. Настройте входящий маршрут в Mail Proxy

В Configuration → Mail Proxy последовательно проверьте:

1. Relay Domains: домены, для которых PMG принимает входящую почту, например corp.example.net. Это не разрешение отправлять от любого доверенного отправителя куда угодно.
2. Relaying / Default Relay: внутренний MTA10.10.50.10 и его SMTP-порт 25. Если указаны transports для отдельных доменов, учтите их при выборе маршрута.
3. Transports: особые маршруты доменов и поддоменов, если они реально нужны. Не добавляйте неизвестные wildcard-правила.
4. Ports: внешний 25 и внутренний 26 согласно принятой схеме. Отдельно проверьте, что firewall/NAT не поменял их смысл.

В качестве внутреннего relay укажите адрес, который действительно ведёт к mailbox-серверу, а не обратно к MX самого PMG. Иначе появится петля: шлюз передаёт письмо серверу, тот возвращает его шлюзу.

pmgsh get /version
pmgsh get /config/mail
pmgsh help /config/mail -v
postconf myhostname mynetworks relay_domains transport_maps relayhost

Это команды чтения для сопоставления GUI и эффективной конфигурации. Не публикуйте полный вывод с закрытыми параметрами. Доступные пути и параметры своей версии уточняют через pmgsh; не используйте старый set-пример, не проверив его смысл.

Шаг 4. Доверенные узлы и исходящий маршрут

В Mail Proxy → Networks добавляют только необходимые внутренние источники. Для нашего MTA это конкретный 10.10.50.10/32, а не весь 10.10.0.0/16. Настройте его исходящий connector/smart host на 10.10.80.10:26 и проверьте отсутствие обходного маршрута.

Критическая особенность: штатная конфигурация PMG может доверять хостам собственной подсети по умолчанию. Поэтому шлюз в общей сети пользователей или большом облачном сегменте — плохая граница доверия. Проверьте фактический postconf mynetworks и сетевую изоляцию, а не только добавленную строку /32.

• Не добавляйте 0.0.0.0/0 в trusted networks и не открывайте 26 из интернета.
• Обычный ноутбук, сайт и принтер не получают relay автоматически; их отправка должна проходить через аутентифицированный MTA или иной согласованный канал.
• Убедитесь, что внешний SMTP-трафик не приходит к PMG после SNAT с доверенного внутреннего адреса. Иначе источник может выглядеть локальным.
• Для Exchange, Postfix и других серверов отдельно проверяют порт и параметры connector; не меняют 25/26 местами без пересмотра всей схемы.
• При внешнем smart host зафиксируйте его требования, аутентификацию, TLS и роль PTR/IP конечного отправителя.

Официальное Getting started объясняет различие портов. PMG 26— это вход доверенного сервера для исходящего потока, а не безопасная публичная submission-служба для любого пользователя с паролем.

Шаг 5. DNS и защита от обхода шлюза

Для входящей почты MX домена указывает на FQDN шлюза, а его A/AAAA — на рабочие адреса. Для исходящей важны фактический публичный IP, PTR и согласованное имя SMTP. DNS меняют только после проверки нового маршрута.

dig +short MX corp.example.net
dig +short A mx1.corp.example.net
dig +short AAAA mx1.corp.example.net
dig +short -x 203.0.113.25

Примерные DNS-отношения:

corp.example.net.      MX 10 mx1.corp.example.net.
mx1.corp.example.net.  A 203.0.113.25

• Если старый MX ведёт прямо на mailbox-сервер, часть почты может обходить фильтр.
• Резервный MX с более слабой защитой также может стать обходным входом.
• Закройте межсерверный SMTP 25 внутреннего MTA от внешних источников, оставив PMG и реально необходимые системы. Не путайте это с пользовательскими 587/465.
• Внутренние отправители, доставляющие письмо напрямую, тоже могут обходить gateway. Определите, какой поток обязан проверяться.
• При IPv6 примените ту же политику: одного IPv4 NAT недостаточно.

Не обещайте, что смена MX завершится мгновенно: кеши и очереди удалённых отправителей сохраняют прежние сведения. В период переноса наблюдайте оба согласованных пути и не создавайте петлю.

Шаг 6. Проверьте STARTTLS отдельно от доставки

Настройте SMTP TLS и сертификат согласно схеме. Для проверки соединения с правильным именем можно использовать:

openssl s_client -starttls smtp \
  -connect mx1.corp.example.net:25 \
  -servername mx1.corp.example.net \
  -verify_hostname mx1.corp.example.net \
  -verify_return_error </dev/null

Ожидается корректная цепочка и имя без ошибок проверки. Для корпоративного CA требуется штатное доверие. Не превращайте тест в «успешный», отключая валидацию.

Обычный opportunistic STARTTLS не равен обязательному TLS со всеми партнёрами. Для выбранного направления можно задавать согласованную TLS-политику, но её включение требует проверки совместимости. Шифрование SMTP-соединения не делает вложение безопасным и не заменяет SPF/DKIM/DMARC.

SPF, DKIM и DMARC: три разных проверки

SPF может осложняться пересылками, DKIM — модификацией подписанных данных. DMARC не распознаёт весь фишинг: похожий домен и поддельное отображаемое имя могут пройти техническую проверку своего домена. Смотрите полные заголовки и результаты проверки на стороне фактического получателя.

Не публикуйте SPF с единственным IP, пока не собрали все легальные источники. Пример ниже подходит только если отправитель действительно один — этот шлюз:

corp.example.net. TXT "v=spf1 ip4:203.0.113.25 -all"

Если используются SaaS, рассылки и другие адреса, запись будет другой. Не создавайте несколько отдельных SPF-записей одного домена вместо корректной единой политики. Ужесточайте DMARC после анализа источников и alignment, контролируя отчёты и легальную доставку.

Шаг 7. Настройте DKIM-подпись исходящей почты

В Mail Proxy → DKIM Signing выберите selector, создайте ключ штатным способом и получите готовую DNS TXT-запись через View DNS Record. Опубликуйте именно её у владельца DNS; приватный ключ не переносится в TXT.

1. Определите домены подписи и источник signing domain: envelope либо header по выбранной политике.
2. Не подписывайте все посторонние домены только потому, что письмо пришло на доверенный порт.
3. Проверьте TXT для selector._domainkey.corp.example.net снаружи.
4. После включения отправьте согласованный тест через правильный исходящий маршрут и проверьте DKIM/DMARC у получателя.
5. Зафиксируйте ротацию, старые selectors и резервную копию приватного ключа с ограниченным доступом.

Для уведомлений и карантинных отчётов самого PMG envelope может быть пустым; signing-domain и From этих писем требуют отдельной проверки. Подпись обычного исходящего письма не доказывает подпись системного отчёта.

dig +short TXT selector._domainkey.corp.example.net
dig +short TXT _dmarc.corp.example.net
pmgconfig help

selector заменяют фактическим именем. Не вставляйте в статью или заявку приватные ключи. Штатные параметры и применение конфигурации описаны в pmgconfig.

Шаг 8. Проверяйте получателя до приёма письма

Если backend умеет достоверно отклонять несуществующие адреса на SMTP RCPT, можно настроить Receiver Verification. Сначала проверьте реальные ящики, aliases, группы, пересылки, временную недоступность и catch-all. Сервер, который принимает любой адрес, не даёт достоверной проверки получателя.

При проверке 450 и 550 имеют разный смысл: временный отказ предлагает повторить позже, постоянный сообщает о недоставке. Не переключайте всё на жёсткий отказ до проверки маршрута и поведения MTA.

Отклонение неизвестного адресата до принятия сообщения помогает уменьшить обработку мусора и риск последующих нежелательных bounce. Но неверно настроенная проверка может остановить легальную почту. LDAP/список пользователей и SMTP-проверка — не одно и то же; используйте выбранный механизм осознанно.

Шаг 9. Постройте фильтры как понятную политику

В Mail Filter используются объекты Who/What/When и действия. У каждого правила зафиксируйте направление Incoming/Outgoing, смысл сопоставления, приоритет и ожидаемое действие. Логику PMG нельзя механически переносить с firewall.

Например, score5 можно рассматривать как зону пилотной пометки,10— как кандидат на карантин. Это условные проектные значения, не рекомендация без замеров и не заявленные defaults PMG. Калибруйте по реальным письмам и фиксируйте причину каждого исключения.

Начинайте с малой группы и прозрачных правил. Не меняйте одновременно DNSBL, SMTP checks, SpamAssassin scores и все действия карантина: иначе трудно понять причину потери письма.

SMTP Welcomelist и пользовательские исключения — не одно и то же

В PMG есть несколько уровней welcome/block lists. SMTP Welcomelist может обходить SMTP-проверки, включая greylisting, SPF и DNSBL, а не просто уменьшать score. Поэтому правило «доверяем всему домену партнёра» может открыть больше, чем ожидалось.

• Записывайте точную причину: какой легальный поток ломается и на какой проверке.
• Ограничивайте исключение источником, адресатом и сроком там, где это поддерживается выбранным механизмом.
• Не доверяйте одному отображаемому From: его можно подделать.
• Проверяйте, какие последующие контент/антивирусные правила продолжают применяться.
• Пересматривайте временные исключения после исправления исходной проблемы.

Greylisting может давать задержку первой доставки, а DNSBL — зависеть от выбранного резолвера, условий списка и его доступности. При массовых задержках сначала смотрите DNS и SMTP-ответы, а не отключайте всю защиту сразу.

Шаг 10. Сделайте карантин управляемым процессом

Карантин бесполезен, если письмо лежит там неделями без ответственного. Определите, кто получает отчёт, кто вправе выпускать разные категории, как быстро разбирают обращения и где фиксируют причину ложного срабатывания.

1. Настройте время и адреса отчётов, корректный From и URL карантина.
2. Проверьте персональный доступ: пользователь не должен видеть чужие письма и вложения.
3. Проверьте срок действия ссылок/токенов и выбранный способ входа; ссылки на карантин могут быть чувствительными.
4. Разведите spam quarantine и опасные объекты: право обычного пользователя выпускать спам не означает разрешение запускать вредоносное вложение.
5. Проверьте фактическую доставку выпущенного письма и журнал действия.

Не открывайте подозрительные вложения на административном ПК ради «проверки, вирус ли это». Для анализа используйте принятый изолированный процесс. Нажатие Release не доказывает попадание письма в Inbox: backend и клиент могут применить свои правила.

Tracking Center, Queue-ID и Message-ID: как искать письмо

Начните с времени, отправителя, получателя и направления. Message-ID задаётся в письме и не является безусловным доказательством уникальности. Queue-ID относится к конкретной обработке MTA; при пересылке между узлами он может меняться.

systemctl status postfix pmg-smtp-filter --no-pager
journalctl -u postfix -u pmg-smtp-filter --since '-30 min' --no-pager
postqueue -p
postconf myhostname relayhost transport_maps

Фактический журнал зависит от настроек syslog/journald. Используйте Tracking Center и логи нужных служб, сопоставляя этапы. Команды не показывают «универсальный статус доставки до пользователя».

• PMG принял: сообщение принято шлюзом, но может ждать фильтрации/маршрута.
• Deferred: временная проблема, надо прочитать причину и время повторов.
• Следующий MTA ответил 250: передача следующему узлу состоялась; это не доказательство доставки в Inbox.
• Карантин: сработало конкретное правило; нужны категория и право дальнейшего действия.
• Пользователь не видит: проверяются backend, папки спама, правила клиента и мобильная синхронизация.

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

Приёмка: доставлено, отфильтровано и не стало открытым relay

1. Обычная входящая: согласованный внешний отправитель → реальный тестовый ящик; проверены Tracking Center и получение у адресата.
2. Обычная исходящая: MTA →PMG 26→внешний контролируемый адрес; проверены направление, SPF/DKIM/DMARC и получатель.
3. Несуществующий адресат: ожидаемый SMTP-отказ без нарушения aliases/групп.
4. Внешний sender →внешний recipient: недоверенный узел не получает право транзитной ретрансляции. Проверяют из действительно внешней сети, не с доверенного MTA.
5. Пользовательский ПК →PMG 26: не получает незапланированное право relay.
6. Безопасный spam-тест: согласованный GTUBE-поток вызывает ожидаемое правило, журнал и карантин.
7. Ложное срабатывание: тестовое легальное письмо выпускается уполномоченным человеком и действительно приходит.
8. Отказ backend/DNS: очередь и уведомления ведут себя предсказуемо; после восстановления письмо обрабатывается.
9. Обход: старый MX, прямой 25 на backend, резервный MX и IPv6 не открывают незащищённый путь.

GTUBE — безвредный тестовый маркер SpamAssassin, а не настоящий спам-образец или вредоносный файл; инструкции есть у Apache. Проводите тест только на согласованных адресах: маркер намеренно может попасть в карантин. Эта статья не отправляет тестовые письма и не заявляет результаты реального внедрения.

Ответ 250 на RCPT сам по себе ещё не доказывает открытый relay или конечную доставку: решение может приниматься позже. Проверка должна учитывать полный согласованный SMTP-сценарий и журналы без отправки посторонним адресатам.

Копии, обновления и восстановление

До изменения политики создайте штатный backup конфигурации и базы правил, сохраните его вне узла с ограниченным доступом. Пример:

pmgbackup backup
pmgbackup list
pmgbackup help

Проверьте фактический состав: backup конфигурации не равен копии всех писем очереди, карантина и почтовых ящиков. Копия PMG не резервирует Exchange/Postfix mailbox-хранилище. Ключи, статистика, cluster membership и перенос на другой узел имеют свои правила. Возможности описаны в pmgbackup.

• Перед обновлением сохраните версии, правила, адреса и DNS/маршруты.
• Репетируйте restore в изоляции: восстановленный узел не должен случайно отправлять или принимать рабочую почту.
• Наблюдайте место, очередь, карантин, обновления правил/сигнатур, TLS-сроки и DNS.
• Проверяйте обновление служб и перезапуски по документации; активная служба не подтверждает актуальность сигнатур.

В конфигурации применяйте GUI/API. Если по согласованной причине менялись поддерживаемые шаблоны, штатный pmgconfig sync --restart 1 может перегенерировать файлы и перезапустить службы; это планируют в окне.

План возврата: DNS, коннекторы и очередь меняются отдельно

При проблеме сначала определите слой: DNS, соединение, relay, фильтр, backend или карантин. Возврат старого MX не отменяет сообщения, которые уже принял PMG. Они остаются его ответственностью до обработки по согласованному плану.

1. Зафиксируйте очередь и состояние сообщений, временно остановите дальнейшее расширение пилота.
2. Восстановите только изменённые маршруты/правила из согласованного состояния, не удаляя принятые письма.
3. Проверьте старый и новый путь на петли, дубли и обход.
4. Повторите входящий и исходящий тест, а также карантинные/отложенные сообщения.
5. Не снижайте защиту backend на неопределённый срок под видом временного обхода.

Два MX или кластер не создают HA автоматически. Нужны проверенные DNS-приоритеты, одинаковая политика, маршруты, доверие и порядок обработки при отказе; очередь каждого MTA не становится общей лишь из-за второго узла.

Практические ограничения защиты

• Качественное деловое письмо тоже может попасть в карантин; нужен управляемый выпуск и настройка.
• Письмо с похожего легально зарегистрированного домена может пройти SPF/DKIM/DMARC.
• Зашифрованные архивы, новые угрозы, ссылки и действия пользователя требуют дополнительных мер.
• Если злоумышленник вошёл в настоящий ящик, одной проверки внешнего SMTP-источника недостаточно.
• Шлюз не заменяет MFA почты, защиту endpoint, обучение, DLP и резервные копии.
• Нельзя обещать 100%защиты от фишинга или отсутствие ложных срабатываний.

Ценность PMG — контролируемые маршруты, фильтрация, карантин и расследование. Итог измеряют на вашей почте: доля нежелательных сообщений, легальные задержки, ложные срабатывания и время разбора.

Паспорт шлюза и протокол приёмки

Настройка почтовой защиты и сопровождение

Частые вопросы