Обзор: контроль пересылки(relay)/доступа


Введение

Сервер Postfix SMTP принимает почту из сети и подвержен воздействию со стороны спамеров и вирусов. Данный документ описывает встроенные и внешние методы Postfix, которые указывают, какую SMTP почту он должен принимать. Также вы узнаете, каких ошибок следует избегать и как тестировать свою конфигурацию.

Темы, охваченные в документе:

Управление пересылкой (relay), блокировка спам-а(junk mail), политики для отдельных пользователей (per-user policies)

В далеком прошлом Интернет представлял из себя дружественную среду. Почтовые сервера без ограничений пересылали почту от кого угодно кому угодно. Сегодня спамеры создают проблемы для серверов, которые пересылают почту от произвольных клиентов (т.н. open relay сервера), так как в последствии эти сервера могут быть добавлены в антиспамерские черные списки (anti-spammer blacklists). Вы можете ознакомиться, например, с информацией на этом сайте: http://www.mail-abuse.org/.

По умолчанию, Postfix использует умеренно строгий подход к пересылке почты. Postfix пересылает почту только от клиентов из дружественных сетей (trusted networks) или для доменов, пересылка почты которым разрешена явно. Для ознакомления с поведением Postfix по умолчанию читайте описание параметра smtpd_recipient_restrictions в документе postconf(5) , а также документацию, на которую ссылается указанное описание.

Большинство возможностей по управлению доступом к SMTP серверу Postfix направлены на борьбу со спамом.

К сожалению, все средства борьбы со спамом могут ошибаться, отвергая легитимные письма. Это может быть серьезной проблемой для сервера, обрабатывающего почту для большого количества пользователей. Для одних пользователей неприемлемо получение хоть одного письма спама, в то время как для других одно ошибочно отвергнутое легитимное сообщение может обернуться трагедией. Так как нет определенной политики, которая бы удовлитворяла пожеланиям всех без исключения пользователей, Postfix поддерживает разные ограничения по доступу к SMTP серверу для разных пользователей. Эта возможность описана в документе RESTRICTION_CLASS_README.

Ограничения, которые воздействуют на всю SMTP почту

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

Списки ограничений для отдельных этапов SMTP соединения

Postfix позволяет задавать списки ограничений для каждого этапа SMTP диалога. Отдельные ограничения описаны на странице документации postconf(5) .

Примеры простых списков ограничений:

/etc/postfix/main.cf:
    # Разрешить соединения только от дружественных (trusted) сетей.
    smtpd_client_restrictions = permit_mynetworks, reject

    # Не общаться с почтовыми системами, которые не знают имени своего хоста.
    smtpd_helo_restrictions = reject_unknown_hostname

    # Не принимать почту от доменов, которые не существуют.
    smtpd_sender_restrictions = reject_unknown_sender_domain

    # "Белые" списки. Локальные клиенты могут указывать любого получателя. Другие клиенты не могут.
    smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

    # Блокировать клиентов, которые начинают общаться рано.
    smtpd_data_restrictions = reject_unauth_pipelining

    # Проверять квоты на объем почты, обращаясь к внешним сервисам. 
    smtpd_end_of_data_restrictions = check_policy_service unix:private/policy

Каждый список ограничений обрабатывается слева направо до тех пор, пока какое-либо ограничение не выдаст результат PERMIT (разрешить), REJECT (отклонить) или DEFER (отложить для последующей повторной попытки). Достижение конца списка эквивалентно получению результата PERMIT. Указывая ограничение PERMIT перед ограничением REJECT, вы можете делать исключение для определенных клиентов или пользователей (т.н. белые списки, whitelisting). Пример ниже разрешает отправлять почту локальным клиентам, но другим клиентам отсылка почты для произвольных получателей запрещена.

    # "Белые" списки. Локальные клиенты могут указывать любого получателя. Другие клиенты не могут.
    smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Ниже показана таблица, объясняющая назначение всех списков ограничений доступа к SMTP. Синтаксис написания списков одинаков, они отличаются лишь временем применения и эффектом, который порождают результаты REJECT или DEFER.

Название списка ограничений Статус Эффект результата REJECT или DEFER
smtpd_client_restrictions Опционален Отклонять все команды клиента
smtpd_helo_restrictions Опционален Отклонять на основании информации HELO/EHLO
smtpd_sender_restrictions Опционален Отклонять на основании информации MAIL FROM
smtpd_recipient_restrictions Необходим Отклонять на основании информации RCPT TO
smtpd_data_restrictions Опционален Отклонять команду DATA
smtpd_end_of_data_restrictions Опционален Отклонять после получения команды END-OF-DATA
smtpd_etrn_restrictions Опционален Отклонять команду ETRN

Отложенная обработка списков управления доступом к SMTP

Ранние версии Postfix выполняли действия, предусмотренные списками ограничений доступа к SMTP, настолько рано, насколько это возможно. Список ограничения клиентов (client restriction list) проверялся перед тем, как Postfix отсылал приветствие "220 $myhostname..." SMTP клиенту. Список smtpd_helo_restrictions обрабатывался перед тем, как Postfix отвечал на команду HELO (EHLO). Список smtpd_sender_restrictions обрабатывался перед ответом на команду MAIL FROM. И так далее. Эта практика оказалась весьма сложной в применении.

Текущие версии Postfix откладывают обработку списков ограничения для клиентов, отправителей и HELO до получения команды RCPT TO или ETRN. Это поведение контролируется параметром smtpd_delay_reject. Списки ограничений обрабатываются в правильном порядке (client, helo, etrn) или (client, helo, sender, recipient, data, end-of-data). Когда список ограничений (например, client) выдает результат REJECT или DEFER, обработка последующих списков (пример: helo, sender, и т.д.) не выполняется.

В то время как был добавлен параметр smtpd_delay_reject, в Postfix также была введена поддержка смешанных списков ограничений, которые комбинируют информацию о клиенте, отправителе, получателе и информацию команд helo, etrn.

Преимущества отложенной обработки списков ограничений и смешанных списков:

Опасное использование smtpd_recipient_restrictions

Теперь читатель может спросить, зачем нужны списки ограничений client, helo или sender, если их обработка откладывается до команды RCPT TO или ETRN. Некоторые люди рекомендуют помещать ВСЕ ограничения в список smtpd_recipient_restrictions. К сожалению, это может привести к слишком доверчивому поведению SMTP сервера Postfix. Как это возможно?

Цель списка smtpd_recipient_restrictions - это управление тем, как Postfix отвечает на команду RCPT TO. Если список ограничения выдает результат REJECT или DEFER, то адрес получателя отклоняется, что и требуется. Если результат - PERMIT, то адрес получателя принимается. И здесь следует ждать сюрпризов.

Вот пример, который иллюстрирует вышеуказанную ситуацию:

1 /etc/postfix/main.cf:
2     smtpd_recipient_restrictions = 
3         permit_mynetworks
4         check_helo_access hash:/etc/postfix/helo_access
5         reject_unknown_hostname
6         reject_unauth_destination
7 
8 /etc/postfix/helo_access:
9     localhost.localdomain PERMIT

В 5-ой строке отклоняется почта от всех клиентов, которые не указывают правильное имя хоста в команде HELO. В строках 4-ой и 9-ой сделано исключение для некоторого клиента, который представляется, как "HELO localhost.localdomain".

Проблема этой конфигурации в том, что список smtpd_recipient_restrictions выдает результат PERMIT для ЛЮБОГО хоста, который анонсирует себя, как "localhost.localdomain". В результате, Postfix становится открытым релэем (open relay) для всех таких машин.

Чтобы избежать подобных недоразумений со списком smtpd_recipient_restrictions, вам следует помещать ограничения, не связанные с адресом получателя (non-recipient restrictions), ПОСЛЕ ограничения reject_unauth_destination, а не до него. В примере выше ограничение для HELO должно быть размещено ПОСЛЕ reject_unauth_destination, или, еще лучше, поместить ограничение HELO в список smtpd_helo_restrictions, где оно не вызовет проблем.

Тестирование правил доступа к SMTP

В Postfix имеются несколько возможностей, которые помогают тестировать правила доступа к SMTP:

soft_bounce

Это средство заменяет действия SMTP сервера REJECT на DEFER (попытаться позже). Это позволяет оставлять сообщения в очереди, которые в противном случае были бы возвращены отправителю. Укажите "soft_bounce = yes" в файле main.cf, чтобы предотвратить постоянное отклонение почты SMTP сервером Postfix. С этой целью Postfix заменит все коды ответов 5xx на 4xx.

warn_if_reject

Эта возможность позволяет заменить действия SMTP сервира REJRCT на замечания (warnings). Вместо отклонения команды клиента Postfix регистрирует, что он собирался отвергнуть. Укажите "warn_if_reject" в списке ограничений доступа к SMTP перед тем ограничением, которое вы хотите протестировать без реального отклонения почты.

XCLIENT

Благодаря этой возможности (Postfix 2.1 и последующие версии) авторизованные SMTP клиенты могут имитировать другие системы, таким образом вы можете проводить ралистичные тесты правил доступа к SMTP серверу Postfix. Примеры использования XCLIENT для тестирования правил доступа содержатся в документе XCLIENT_README .

Hosted by uCoz