Чтобы ограничить количество систем, которые могут отправлять неаутентифицированную исходящую почту через MTA Zimbra, установите для атрибута этого сервера zimbraMtaMyNetworksкороткий список разрешенных IP-адресов или сетей CIDR. Оставьте в списке адреса локальной петли, сохраните все существующие доверенные хосты, которые все еще нуждаются в ретрансляции, и удалите широкие диапазоны, которым вы больше не собираетесь доверять. Затем перезагрузите Postfix и протестируйте как одобренный, так и неодобренный источник.
Этот параметр управляет доверенными SMTP-клиентами, которые могут пересылать сообщения без аутентификации SMTP. Он не блокирует все исходящие сообщения от аутентифицированного пользователя Zimbra и не устанавливает почтовый сервер следующего перехода. Если ваша цель — требовать аутентификацию для перемещаемых почтовых клиентов или ограничить доступ к определенным учетным записям пользователей, используйте вместо этого соответствующие параметры аутентификации или политики почты.
Что контролирует список разрешенных IP-адресов?
MTA в Zimbra использует Postfix. В Postfix клиент, чей исходный адрес совпадает, mynetworksсчитается доверенным для ретрансляции. Zimbra предоставляет этот список через zimbraMtaMyNetworks. Указанный хост может отправлять почту для внешних адресатов без аутентификации, поэтому каждая запись является значимым решением о доверии.
Не путайте список разрешенных серверов с zimbraMtaRelayHost. Список разрешенных серверов определяет, какие SMTP-клиенты могут пересылать сообщения через этот MTA. Хост ретрансляции — это вышестоящий сервер, на который MTA пересылает нелокальные сообщения, например, когда сетевой провайдер требует наличия смарт-хоста. Изменение одного не меняет работу другого.
На страницах Технического центра Zimbra описан этот атрибут и соответствующие команды, но некоторые материалы помечены как находящиеся в разработке или архивные документы. Перед внесением изменений проверьте поведение в соответствии с установленной версией Zimbra и дизайном развертывания. В приведенных ниже примерах в качестве zimbraучетной записи службы используются инструменты командной строки Zimbra, что соответствует рекомендациям Zimbra по MTA.
Перед изменением настроек
- Определите хост MTA, который принимает SMTP-запросы от систем, которые вы планируете разрешить. В среде с несколькими MTA определите, какие MTA обрабатывают эти соединения, и спланируйте изменение на каждом соответствующем сервере.
- Найдите фиксированный исходный IP-адрес, который фактически видит MTA. Если приложение находится за NAT, используйте его публичный исходящий адрес, а не частный адрес локальной сети. Если IP-адрес часто меняется, список разрешенных адресов, содержащих только IP-адреса, потребует постоянного обслуживания.
- Запишите текущий атрибут Zimbra и эффективное значение Postfix. Не заменяйте существующий список только новым адресом, пока не проверите, какие службы зависят от текущих записей.
- Установите период технического обслуживания или период внесения изменений, подходящий для вашей почтовой службы, и сохраните копию с точной первоначальной стоимостью.
Используйте CIDR для одного хоста, например /32, для IPv4-адреса. Например, 198.51.100.25/32представляет собой один IPv4-хост; этот адрес, указанный только в документации, является примером и не должен копироваться как реальный адрес сервера. Более широкий диапазон, например, /24доверяет каждому адресу в этой подсети. Не добавляйте общедоступные сети или большие диапазоны адресов провайдеров только для того, чтобы тест прошел успешно.
Как настроить список разрешенных устройств для ретранслятора Zimbra
1. Проверьте заданные и фактически сгенерированные значения.
Войдите на хост MTA и переключитесь на учетную запись службы Zimbra. Замените mta.example.comна точное имя сервера, возвращенное zmhostnameкомандой вашей установки.
su - zimbra
zmhostname
zmprov gs mta.example.com zimbraMtaMyNetworks
postconf mynetworks
Первый запрос считывает значение, хранящееся для объекта сервера Zimbra; postconfон показывает действующую настройку Postfix. Сохраните оба результата. Если атрибут LDAP не задан, Postfix может использовать значение по умолчанию, поэтому не следует предполагать, что пустой запрос означает отсутствие доверенных сетей. Перед продолжением проверьте действующее значение и поведение конфигурации вашей версии.
2. Составьте наименьший полный список.
Создайте список, содержащий адрес локальной точки (loopback) плюс каждый источник, которому действительно требуется неаутентифицированная ретрансляция. Для сервера, который должен принимать ретрансляцию только с локального хоста и одного фиксированного хоста приложения, структура списка будет следующей:
127.0.0.0/8 198.51.100.25/32
Замените пример реальным адресом, видимым для MTA. Включайте необходимые локальные интерфейсы сервера или дополнительные доверенные службы только после подтверждения их необходимости. Избегайте использования широкой офисной подсети, если следует доверять только одному серверу; по возможности сократите ее до записи хоста.
3. Установите значение для соответствующего MTA.
Используйте zmprov msэту команду для установки атрибута на уровне сервера. Эта команда заменяет значение, поэтому включите все записи, которые вы хотите сохранить, включая запись на локальную точку:
zmprov ms mta.example.com zimbraMtaMyNetworks '127.0.0.0/8 198.51.100.25/32'
Для нескольких IP-адресов поместите полный список разрешенных IP-адресов в кавычки, разделяя их пробелами. Не запускайте пример команды без изменений. Если ваша конфигурация основана на глобальном значении, переопределениях на уровне сервера, IPv6, нескольких MTA или поведении, специфичном для версии, проверьте, как работает наследование и сгенерированная конфигурация Postfix в этой конфигурации, прежде чем устанавливать атрибут.
4. Перезагрузите Postfix и подтвердите активные настройки.
После изменения конфигурации Zimbra перезагрузите Postfix под учетной записью службы Zimbra, а затем снова запросите фактическое значение:
postfix reload
postconf mynetworks
zmprov gs mta.example.com zimbraMtaMyNetworks
Вывод должен соответствовать указанному вами списку разрешенных адресов, включая локальную сеть. Если Postfix сообщает о некорректном формате сети или значения отличаются, остановитесь и устраните эту проблему с конфигурацией, прежде чем тестировать поток почты. Записи CIDR должны использовать правильную границу сети; для одного хоста используйте адрес хоста с параметром `<IP-адрес>` /32, а не сетевую маску, включающую соседние хосты.
Как проверить, работает ли ограничение?
Проведите тестирование на контролируемой, авторизованной системе, используя тот же сетевой путь и SMTP-сервер, что и в реальном приложении. Отправьте сообщение в почтовый ящик, который вы контролируете, за пределами доменов Zimbra. Убедитесь, что утвержденный хост может отправить сообщение и что журналы MTA показывают успешное принятие или доставку. Активность MTA Zimbra обычно регистрируется в журнале /var/log/zimbra.log; проверьте соответствующую метку времени и исходный IP-адрес, а не полагайтесь только на сообщение об успешном завершении от почтового клиента.
Затем проведите проверку с хоста, который не находится в списке разрешенных и не аутентифицирован. Ожидаемый результат — отказ в ретрансляции при попытке отправки сообщения нелокальному получателю. Проверьте журнал MTA на наличие отклоненного соединения и адреса источника, зафиксированного Postfix. Неаутентифицированному клиенту может быть разрешено отправлять сообщения локальным получателям Zimbra; это обычный прием почты и не доказывает, что он может ретранслировать исходящую почту.
Также проверьте все легитимные приложения, которые были в старом списке. Неудачная отправка приложения обычно означает, что в список разрешенных был добавлен неверный адрес источника, удалена старая доверенная зависимость или приложению требуется аутентификация SMTP. Если клиенты перемещаются между сетями или их исходящий IP-адрес нестабилен, аутентификация SMTP через TLS, как правило, проще в управлении, чем многократная смена списка разрешенных IP-адресов.
Как откатить изменения или устранить неполадки
Если одобренные приложения перестают отправлять данные, восстановите точное сохраненное значение, а не добавляйте предполагаемую подсеть. Примените его с помощью команды `npm install` zmprov ms, перезагрузите Postfix и подтвердите фактическое значение с помощью postconf mynetworksкоманды `npm install`. Проверьте, не изменяет ли балансировщик нагрузки, NAT-шлюз, хост контейнера или исходящий прокси-сервер исходный адрес до того, как он достигнет MTA.
Ответ Relay access deniedтакже может означать, что клиент не аутентифицирован, и его исходный IP-адрес отсутствует в списке доверенных адресов. Для обычных пользователей электронной почты настройте отправку SMTP-трафика с аутентификацией, а не добавляйте все пользовательские сети в список zimbraMtaMyNetworks. Широкие списки разрешенных адресов создают большую поверхность неаутентифицированной пересылки и могут сделать сервер уязвимым для злоупотреблений, если доверенная сеть содержит неуправляемые устройства.
Если значение MTA отображается корректно, но поведение не меняется, убедитесь, что вы отредактировали сервер, принявший соединение, что перезагрузка прошла успешно и что никакие другие экземпляры Postfix или сетевые устройства не обрабатывают SMTP. Не редактируйте файлы Postfix, сгенерированные Zimbra, напрямую в качестве постоянного решения; управление конфигурацией может сгенерировать их заново. Обратитесь к документации по администрированию Zimbra или каналу поддержки для получения информации о процедурах, специфичных для вашей версии, если значение LDAP и конфигурация среды выполнения не совпадают.
Как выглядит успешный результат
postconf mynetworksОтображает только адреса локальной петли и предполагаемые доверенные исходные адреса или сети.
- Одобренное, но не прошедшее аутентификацию приложение может отправлять сообщения во внешний тестовый почтовый ящик.
- Неаутентифицированный, не одобренный хост получает отказ в ретрансляции для внешнего получателя.
- Аутентифицированные пользователи и локальная входящая почта продолжают работать в обычном режиме.
- Зарегистрированное значение отката и список зависимых служб сохраняются для будущих изменений.
Этот метод сужает круг неаутентифицированных ретрансляторов по исходному IP-адресу. Он не заменяет аутентификацию SMTP, TLS, контроль скорости, безопасность учетных записей или мониторинг, и не может различать отдельные приложения, использующие один публичный NAT-адрес. Используйте его как единый целевой механизм контроля и пересматривайте список разрешенных каналов при каждом изменении исходящего трафика или ролей MTA.
Источники