Обзор: контроль пересылки(relay)/доступаОбзор: контроль пересылки(relay)/доступаСервер Postfix SMTP принимает почту из сети и подвержен воздействию со стороны спамеров и вирусов. Данный документ описывает встроенные и внешние методы Postfix, которые указывают, какую SMTP почту он должен принимать. Также вы узнаете, каких ошибок следует избегать и как тестировать свою конфигурацию.
Темы, охваченные в документе:
В далеком прошлом Интернет представлял из себя дружественную среду. Почтовые сервера без ограничений пересылали почту от кого угодно кому угодно. Сегодня спамеры создают проблемы для серверов, которые пересылают почту от произвольных клиентов (т.н. open relay сервера), так как в последствии эти сервера могут быть добавлены в антиспамерские черные списки (anti-spammer blacklists). Вы можете ознакомиться, например, с информацией на этом сайте: http://www.mail-abuse.org/.
По умолчанию, Postfix использует умеренно строгий подход к пересылке почты. Postfix пересылает почту только от клиентов из дружественных сетей (trusted networks) или для доменов, пересылка почты которым разрешена явно. Для ознакомления с поведением Postfix по умолчанию читайте описание параметра smtpd_recipient_restrictions в документе postconf(5) , а также документацию, на которую ссылается указанное описание.
Большинство возможностей по управлению доступом к SMTP серверу Postfix направлены на борьбу со спамом.
С ориентацией на протокол. Некоторые средства управления доступом к серверу SMTP блокируют почту от клиентов, которые нестрого придерживаются протокола SMTP. Таким образом, блокируются плохо реализованные и/или плохо настроенные спамерские программы, равно как и почтовые черви, которые пользуются собственной нестандартной реализацией SMTP клиента. Средства контроля, ориентированные на протокол, теряют эффективность со временем, так как спамеры и авторы вирусов учатся читать документы RFC.
Ориентированные на черные списки. Некоторые средства управления доступом к SMTP серверу опрашивают черные списки (blacklists), в которых хранится информация о "плохих" сайтах таких, как открытые релэи (open mail relays), открытые WEB-прокси сервера, скомпрометированные домашние компьютеры, которые удаленно управляемы криминалитетом. Эффективность черных списков зависит от их полноты и актуальности (современости) информации (up to date).
Ориентация на повышение требований. Некоторые средства управления доступом к SMTP серверу позволяют поднять планку требований для клиента, либо заставляя клиента выполнять больше работы (greylisting, серые списки), либо проводя дополнительные проверки (SPF[Sender Policy Framework] и проверку адресов отправителя/получателя). Серые списки и политики SPF реализованы вне Postfix и являются темой документа SMTPD_POLICY_README. Проверка адресов отправителя/получателя описана в документе ADDRESS_VERIFICATION_README.
К сожалению, все средства борьбы со спамом могут ошибаться, отвергая легитимные письма. Это может быть серьезной проблемой для сервера, обрабатывающего почту для большого количества пользователей. Для одних пользователей неприемлемо получение хоть одного письма спама, в то время как для других одно ошибочно отвергнутое легитимное сообщение может обернуться трагедией. Так как нет определенной политики, которая бы удовлитворяла пожеланиям всех без исключения пользователей, Postfix поддерживает разные ограничения по доступу к SMTP серверу для разных пользователей. Эта возможность описана в документе RESTRICTION_CLASS_README.
Помимо ограничений, которые могут быть настроены для отдельных клиентов или пользователей, в Postfix реализованы несколько ограничений, которые воздействуют на всю SMTP почту.
Встроенные ограничения по содержимому header_checks(проверки заголовка) и body_checks(проверки содержимого письма), которые описаны в документе BUILTIN_FILTER_README. Эти проверки производятся во время приема почты, до помещения письма в очередь входящих сообщений (incoming queue).
Внешняя (посредством сторонних программ) проверка содержимого до помещения в очередь, которая описана в документе SMTPD_PROXY_README . Эта проверка выполняется во время приема почты, до помещения письма в очередь входящих сообщений (incoming queue).
Требование к клиентам отсылать команду HELO или EHLO перед использованием команды MAIL FROM или ETRN. Это может вызвать проблемы при работе с "доморощенными" почтовыми клиентами. По этой причине ограничение отключено по умолчанию ("smtpd_helo_required = no").
Запрет некорректного синтаксиса в командах MAIL FROM или RCPT TO. Это может вызвать проблемы при работе с "доморощенными" или древними почтовыми клиентами. По этой причине требование отключено по умолчанию ("strict_rfc821_envelopes = no").
Запрет использования синтаксиса адресов RFC 822 (пример: "MAIL FROM: the dude <dude@example.com>").
Запрет использования адресов, которые не заключены в угловые скобки <> (пример: "MAIL FROM: dude@example.com").
Отклонение писем с несуществующим адресом отправителя. Эта форма фильтрации "на входе" может помочь в борьбе с "червями" и спамерами, но может вызвать проблемы при работе с "доморощенными" почтовыми клиентами, которые отсылают письма с несуществующим адресом отправителя. По этой причине данной ограничение отключено по умолчанию ("smtpd_reject_unlisted_sender = no").
Отклонение писем с несуществующим адресом получателя. Эта форма фильтрации "на входе" помогает содержать почтовую очередь свободной от сообщений MAILER-DAEMON, которые не могут быть доставлены. Это ограничение включено по умолчанию ("smtpd_reject_unlisted_recipient = yes").
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
Ранние версии 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.
Преимущества отложенной обработки списков ограничений и смешанных списков:
Некоторые SMTP клиенты не ожидают негативных ответов на ранних этапах SMTP сессии. Когда плохие новости откладываются до ответа на RCPT TO, клиент уходит, что и требуется, а не висит до разрыва соединения по таймауту, или, хуже того, входит в бесконечный цикл соединение-отказ-соединение.
Postfix может регистрировать больше полезной информации. Например, когда Postfix отклоняет имя или адрес клиента и ждет команды RCPT TO, он получает информацию о адресе отправителя и получателя. Это полезнее, чем регистрация имени хоста и IP адреса клиента вкупе с полным незнанием того, чья почта была заблокирована.
Смешивание необходимо для реализации комплексных политик "белых списков". Например, чтобы отклонить локальные адреса отправителей в сообщениях от нелокальных клиентов, вам необходимо воспользоваться информацией о клиенте и адресе отправителя в одном и том же списке управления доступом. Без данной возможности многие подобные ограничения для отдельных пользователей невозможно описать.
Теперь читатель может спросить, зачем нужны списки ограничений 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, где оно не вызовет проблем.
В Postfix имеются несколько возможностей, которые помогают тестировать правила доступа к SMTP:
Это средство заменяет действия SMTP сервера REJECT на DEFER (попытаться позже). Это позволяет оставлять сообщения в очереди, которые в противном случае были бы возвращены отправителю. Укажите "soft_bounce = yes" в файле main.cf, чтобы предотвратить постоянное отклонение почты SMTP сервером Postfix. С этой целью Postfix заменит все коды ответов 5xx на 4xx.
Эта возможность позволяет заменить действия SMTP сервира REJRCT на замечания (warnings). Вместо отклонения команды клиента Postfix регистрирует, что он собирался отвергнуть. Укажите "warn_if_reject" в списке ограничений доступа к SMTP перед тем ограничением, которое вы хотите протестировать без реального отклонения почты.
Благодаря этой возможности (Postfix 2.1 и последующие версии) авторизованные SMTP клиенты могут имитировать другие системы, таким образом вы можете проводить ралистичные тесты правил доступа к SMTP серверу Postfix. Примеры использования XCLIENT для тестирования правил доступа содержатся в документе XCLIENT_README .
