Чужой опыт экономит время и увеличивает шансы для удачи

Postfix - Postscreen, первый уровень обороны

Большинство писем является спамом, а большинство спама рассылается зомби-ботами. Зомби-боты - это зараженные компьютеры, хозяева которых могут и не знать о том, что они - источники спама. Разработчик Postfix Wietse Venema предсказывает, что в дальнейшем проблема зомби-ботов будет нарастать и ситуация будет только ухудшаться. Идея защиты состоит в том, что такие компьютеры, как правило, не соблюдают все стандарты SMTP-протокола, и кроме того, могут проявлять неестественную настойчивость, подключаясь после отказа снова и снова. Вычисляя их по характерному поведению Postscreen удерживает их на эмуляции SMTP-сессии, не давая соединится напрямик с SMTP-сервером.

ВАЖНО! Эта страница является частью списка заметок о настройке почтовой системы (Postfix+Dovecot и пр.).
Родительская страница - обязательна к просмотру: Установка и настройка почтового сервера

Подробнее о конфигурации к которой относятся примеры в этой статье - см. ссылку выше.
Тем же - коротко об основных терминах (MTA, MDA, MUA и т.п.).

Эта заметка имеет характер исследования. Все упомянутые в заметке эксперименты проводились на ОС Debian. Пожалуйста не используйте слепое копирование примеров. Автор не гарантирует, что применение изложенной здесь информации не приведет к потере данных.

Это скорее конспект-шпаргалка, чем достоверный справочник. Кроме ответов здесь могут присутствовать вопросы.

Содержание


В этой заметке - вольный перевод некоторых частей официальной документации + отсебятина.

Введение

Зомби-блокировщик Postscreen - это первый уровень защиты. Он находится перед smtpd и, тестируя и анализируя поведение SMTP-клиента, решает, кого допустить к прямому соединению, а кого - нет.
ВАЖНО! Postscreen не может сосуществовать на одном порту с MUA! Необходимо перенести MUA на другой порт (например 587) или другой интерфейс.
Postscreen доступен в Postfix с версии 2.8 и выше, а некоторые функции (например "cache sharing") - с версии 2.9.

Зомби-спам-боты создают самую серьезную нагрузку на почтовые сервера. Особенно усердны боты, которые не принимают отказ, а продолжают бесконечные подключения, вынуждая почтовый сервер каждый раз отвлекать свои ресурсы на постоянные соединения с ними. Для того чтобы разгрузить smtpd, используется postscreen. Postscreen проводит ряд тестов SMTP-клиента, и если он выявляет признаки "зомби", то удерживает его на эмуляции SMTP-сессии, не давая подключиться к основному демону - smtpd.
При этом Postscreen поддерживает временный белый список для клиентов, к которым эти тесты не применяются.
Postscreen никогда не проверяет контент, поскольку он не является достаточно надежным источником данных для анализа. Postscreen ищет в первую очередь нарушения, которые допускает зомби-клиент в стандартах SMTP-протокола.


Postscren проводит ряд тестов в том порядке, в котором они описаны ниже.

Быстрые тесты

Быстрые тесты перед всеми остальными призваны в первую очередь определить клиентов, которые не нуждаются в тестировании.

Постоянные черные/белые списки

Параметр postscreen_access_list (значение по умолчанию = permit_mynetworks) указывает список постоянно разрешенных IP клиентов. Обычно в нем сначала указывают разрешение для допустимых сетей, а после - CIDR-таблицу белых/черных списков.

Формат CIDR интересен тем, что не требует никаких манипуляций или перечитывания, после добавления строк.

Пример

/etc/postfix/main.cf

postscreen_access_list = permit_mynetworks,
    cidr:/etc/postfix/postscreen_access.cidr

Соответственно

/etc/postfix/postscreen_access.cidr

# Rules are evaluated in the order as specified.
# Blacklist 192.168.* except 192.168.0.1.
192.168.0.1          permit
192.168.0.0/16       reject

Очередность строк в CIDR-файле важна при обработке, т.к. поиск идет до первого совпадения.

После того, как адрес SMTP-клиента совпадет со строкой для которой указано значение "permit", произойдет логгирование адреса клиента и порта: WHITELISTED [address]:port .

События белого списка не контролируются в настройках - происходит немедленная передача клиентского соединения процессу Postfix SMTP (smtpd).

После того, как адрес SMTP-клиента совпадет со строкой для которой указано значение "reject", произойдет логгирование адреса клиента и порта: BLACKLISTED [address]:port .

Параметр postscreen_blacklist_action указывает следующее событие. См. Провал тестирования до приветствия 220.

Временный белый список

Postscreen вносит IP-адрес SMTP-клиента, прошедшего все тесты, во временный белый список. Параметр postscreen_cache_map указывает его расположение. Временный белый список не используется для клиентских адресов присутствующих в постоянном белом списке.

Обычно это postscreen_cache_map = btree:$data_directory/postscreen_cache . По умолчанию $data_directory = /var/lib/postfix

ПРИМЕЧАНИЕ: Для того, чтобы использовать общий кэш для нескольких Postscreen экземпляров под мастер-демоном, надо использовать:

postscreen_cache_map = proxy:btree:$data_directory/postscreen_cache , отключив очистку кэша (postscreen_cache_cleanup_interval = 0 ), во всех Postscreen экземплярах, за исключением одного, ответственного за эту очистку.

Общий кэш доступен в Postfix версии 2.9 и выше; ранее proxymap не поддерживал очистку кэша.
В качестве альтернативы можно использовать для общего кэша memcache_table.

Когда адрес SMTP-клиента появляется во временном белом списке, происходит логгирование адреса клиента и порта: PASS OLD [address]:port .
Это событие не контролируется в настройках, - происходит немедленная передача клиентского соединения процессу Postfix SMTP (smtpd). Клиент избавляется от дальнейших тестов до тех пор, пока его время пребывания во временном белом списке не истечет, что контролируется параметром postscreen_*_ttl parameters и без упоминаний продлевается когда допустимо.

MX-политика для тестов

Когда удаленный SMTP-клиент не найден в постоянном списке доступа или во временном белом списке, Postscreen проводит ряд тестов в отношение белого списка перед добавлением во временный список и предоставлением доступа к Postfix SMTP.

Когда Postscreen настроен для мониторинга всех основных и резервных MX, он может отказать клиентам белого списка, которые подключаются только к резервному MX (старый трюк спамеров - использовать резервный MX с более слабой анти-спам политикой) .

ПРИМЕЧАНИЕ: Следующие решения предназначены для малых сайтов. Большие сайты должны иметь общий кэш у основных и резервных MTA, чтобы использовать единую точку отказа.

  • Во-первых, нужно настроить хост для прослушивания основного и резервного адреса MX. Настройте соответствующим образом сетевые интерфейсы локальной операционной системы.
    Во-вторых, нужно настроить Postfix на прослушивание нового IP-адреса (этот шаг необходим, после настройки inet_interfaces в "main.cf").
  • Затем настройте Postscreen, на отказ в обслуживании временного белого списка для резервных MX, например так:
  • /etc/postfix/main.cf :

    postscreen_whitelist_interfaces = !IP.IP.IP.IP static:all

    Расшифровка: разрешить клиентам проверяться во временном белом списке для всех серверов, за исключением IP.IP.IP.IP , который является резервным MX.

Когда клиент, не присутствующий в белом списке коннектится к резервному MX, происходит логгирование адреса клиента и порта:

CONNECT from [address]:port to [IP.IP.IP.IP]:25

WHITELIST VETO [address]:port

Расшифровка: клиент [address]:port подключался к резервному MX IP.IP.IP.IP , до того как был проверен через белый список. Клиент не будет внесен во временный белый список, даже если он пройдет все последующие тесты{этот перевод требует перепроверки}.


Тестирование перед приветствием 220 SMTP

Этот тест запускается сразу при подключении клиента и ощущается в виде небольшой задержки во время выдачи первого приветствия 220. Клиенты занесенные в белый список (постоянный или временный) не подвергаются этому тестированию, а сразу подключаются напрямую к smtpd (т.е. эту задержку они не ощутят).

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

Тест "ожидание приветствия"

SMTP-протокол представляет собой классический пример протокола, в котором сервер начинает раньше клиента (после инициации соединения последним). Postscreen обнаруживает зомби, которые в спешке начинают посылать команды, не дожидаясь окончания приветствия. Этот тест включен по умолчанию.

Параметр postscreen_greet_banner указывает текст приветствия: "220-текст ..." (по умолчанию = $smtpd_banner). Это первая часть приветствия, которая происходит перед запуском postscreen_greet_wait таймера. По окончании таймера будет выдана вторая строка - заключительная часть приветствия: "220 текст ..." (без дефиса), где текст ... = $smtpd_banner (во второй, заключительной строке приветствия текст не настраивается).

Включить таймер-задержку например, на 15 сек. можно так

/etc/postfix/main.cf :

postscreen_greet_wait = 15s

Чтобы избежать проблем с плохо настроенными MTA или на время тестирования можно исключить клиента из списка тестирования postscreen_access_list или указать пустой баннер

/etc/postfix/main.cf :

# Exclude broken clients by whitelisting. Clients in mynetworks
# should always be whitelisted.
postscreen_access_list = permit_mynetworks, 
    cidr:/etc/postfix/postscreen_access.cidr

/etc/postfix/postscreen_access.cidr :

192.168.254.0/24 permit

/etc/postfix/main.cf :

# Disable the teaser banner (try whitelisting first if you can).
postscreen_greet_banner =

Если тест должен быть активен для всех - пустой баннер указывать нельзя! Его можно закомментировать (тогда будет принято значение по умолчанию), либо указать например так

/etc/postfix/main.cf :

postscreen_greet_banner = $myhostname ESMTP

Когда SMTP-клиент отправляет команду до истечения postscreen_greet_wait, происходит логгирование следующего вида: PREGREET count after time from [address]:port text... .

Расшифровка: клиент [address]:port отправил count байт не дождавшись окончания приветствия. Это случилось через time секунд после старта postscreen_greet_wait. В text содержится - что клиент отправил (первые 100 байт с учетом непечатаемых символов конца строки и т.п.).

Параметр postscreen_greet_action указывает следующее событие. См. Провал тестирования до приветствия 220.

Белый/черный список DNS

DNSBL - это серверы, содержащие списки хостов, хранимые с использованием системы архитектуры DNS. Ранее такие списки назывались RBL, но сейчас это название является защищенной торговой маркой.

Параметр postscreen_dnsbl_sites (по умолчанию: empty) указывает список "DNS blocklist" серверов, с опциями фильтрации и факторов веса (положительный вес для черных списков и негативный для белых). Эти запросы могут быть выполнены параллельно с PTR. По умолчанию этот тест отключен.

ВАЖНО! Когда Postscreen отбрасывает почту в SMTP-ответе указывается имя DNSBL. Используйте postscreen_dnsbl_reply_map предложение срыть "password" в имени DNSBL{информация требует проверки и уточнения}.

Когда истекает время, указанное в postscreen_greet_wait, и суммарный показатель DNSBL больше или равен указанному в параметре postscreen_dnsbl_threshold, происходит логгирование: DNSBL rank count for [address]:port .

Расшифровка: SMTP-клиент [address]:port имеет суммарный DNSBL показатель count.

Параметр postscreen_dnsbl_action указывает событие которое должно происходить в случае, если суммарный показатель DNSBL больше или равен указанному в параметре postscreen_dnsbl_threshold. См. Провал тестирования до приветствия 220.

Провал тестирования до приветствия 220

Когда адрес клиента найден в постоянном черном списке, или когда клиент не прошел тесты "ожидание приветствия" или DNSBL, происходят события указанные в соответствующих параметрах: postscreen_blacklist_action, postscreen_greet_action, postscreen_dnsbl_action.

Эти события могут быть такими:

  • ignore - игнорировать проваленный тест и перейти к следующим тестам. Повторить этот тест при следующем коннекте клиента. Это событие указывается, если нужно только накопить статистику, - без блокирования почты.
  • enforce - Перейти к следующим тестам, но потом все равно отказать в доставке почты с ответом SMTP 550, и логгировать информацию: "helo"/"sender"/"recipient". Повторять этот тест при следующем коннекте клиента (только для тех кто не прошел в предыдущий раз).
  • drop - Оборвать соединение с ответом SMTP 521. Повторять этот тест при следующем коннекте клиента.

Тестирование после приветствия 220 SMTP

На этой фазе происходит глубокое тестирование соответствия SMTP-протокола. Для этого подключается встроенный в Postscreen SMTP-движок.
ВАЖНО! По умолчанию эти тесты отключены, т.к. они более интенсивны, чем предыдущие и они накладывают некоторые ограничения, о которых будет упомянуто ниже.

  • Когда живой клиент проходит глубокое тестирование, Postscreen добавляет его во временный белый список, но не допускает его сразу к прямому соединению с Postfix SMTP. Вместо этого он дает ему "мягкий отказ" (4XX), логгируя информацию о нем: "helo"/"sender"/"recipient", после чего ожидает что он на некоторое время отключится.
    Прямой доступ к Postfix SMTP дается такому клиенту только при следующем подключении. Для компенсации влияния этого ограничения, Postscreen хранит допуск для клиентов прошедших глубокое тестирование, относительно длительное время.
  • Встроенный SMTP-движок Postscreen не реализует предложения "AUTH", "XCLIENT", и "XFORWARD". Поддержка "AUTH" возможно будет включена в будущих версиях. В то же время, если необходимо совместить на 25 порту MTA и указанные выше предложения (например для MUA), то придется отказаться от глубокого тестирования "после приветствия 220 SMTP".

MUA-клиенты необходимо перенаправить на submission (порт 587), чтобы они никогда не имели дело с Postscreen-тестами.

Тестирование "одна команда за один раз"

По умолчанию SMTP является полудуплексным протоколом: отправитель и получатель могут отправить только одну команду и один ответ за один раз. В отличие от Postfix SMTP (smtpd), Postscreen не объявляет о конвейерной поддержке RFC 2920 в ESMTP (после подачи команды "EHLO" в списке поддерживаемых расширений отсутствует "PIPELINING"). Таким образом клиентам не разрешается отправлять несколько команд.
Глубокое тестирование в Postscreen по умолчанию отключено.

При указании настройки postscreen_pipelining_enable = yes, Postscreen обнаруживает зомби, которые посылают несколько команд за один раз, вместо того, чтобы послать одну команду и ждать ответа.

Этот тест без предупреждения включается всегда, когда Postscreen задействует SMTP-движок. Это необходимо для того, чтобы сделать логгирование более информативным. Когда клиент посылает несколько команд происходит следующее логгирование: COMMAND PIPELINING from [address]:port after command: text .

Расшифровка: SMTP-клиент [address]:port послал несколько команд SMTP, вместо того чтобы послать одну команду и ждать, пока сервер ответит. Это произошло после того, как сервер послал command. Содержание text отражает те самые поспешные команды клиента (это не логгируется с Postfix 2.8).

Параметр postscreen_pipelining_action указывает следующее событие. См. Провал тестирования после приветствия 220.

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

Некоторые спам-боты отправляют почту через открытые прокси. Симптомом этого является использование таких команд как "CONNECT" и др. не-SMTP команд. Postscreen имеет параметр postscreen_forbidden_commands, который эквивалентен параметру Postfix SMTP: smtpd_forbidden_commands . С помощью этого параметра можно блокировать таких клиентов. По умолчанию эта функция отключена.

С помощью postscreen_non_smtp_command_enable = yes, Postscreen обнаруживает зомби, которые посылают команды, указанные в postscreen_forbidden_commands. С помощью этого параметра можно обнаруживать команды, содержащие заголовки (чего на этапе работы Postscreen быть не должно). Последнее является признаком того, что клиент посылает сообщение, несмотря на все отказы Postscreen (Postscreen в принципе, либо посылает отказы, либо дает прямое соединения с Postfix SMTP, - до приема сообщения дело не доходит никогда).

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

Когда клиент посылает не-SMTP команды, происходит следующее логгирование: NON-SMTP COMMAND from [address]:port after command: text .

Расшифровка: SMTP-клиент [address]:port отправил команду, указанную в параметре postscreen_forbidden_commands, либо содержащую заголовки (символ ":" и текст после пробела). Часть after command логгируется только с версии Postfix 2.10.

Параметр postscreen_non_smtp_command_action указывает следующее событие. См. Провал тестирования после приветствия 220.

Тестирование соблюдения стандарта символов конца строки

SMTP - "строчно-ориентированный" протокол (line-oriented). Лимитирована длина строки, и ее окончание: "<CR><LF>". Строки, которые заканчиваются только "<LF>" не допустимы в SMTP. По умолчанию это тестирование отключено.

Если указана настройка параметра postscreen_bare_newline_enable = yes , Postscreen ищет клиентов, которые отправляют строки с некорректными окончаниями.

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

Когда клиент посылает строки, заканчивающиеся только символом перевода строки "<LF>" (без символа возврата картетки "<CR>"), происходит следующее логгирование: BARE NEWLINE from [address]:port after command .

Расшифровка: SMTP-клиент [address]:port отправил строку заканчивающуюся только символом новой строки, и не содержащую символа возврата каретки. Часть after command логгируется только с версии Postfix 2.10.

Параметр postscreen_bare_newline_action указывает следующее событие. См. Провал тестирования после приветствия 220.

Провал тестирования после приветствия 220

Когда клиент проваливает тест "одна команда за один раз", когда обнаруживается не-SMTP команда, или когда провален тест на правильность окончания строк, возникают события, указанные в соответствующих параметрах: postscreen_pipelining_action, postscreen_non_smtp_command_action или postscreen_bare_newline_action.

Эти события могут быть такими:

  • ignore - игнорировать проваленный тест и перейти к следующим тестам. НЕ ПОВТОРЯТЬ этот тест, пока другие тесты не закончены{уточнить}. Это событие указывается, если нужно только накопить статистику, - без блокирования почты.
  • enforce - Перейти к следующим тестам. Отказать в доставке почты с ответом SMTP 550, и логгировать информацию: "helo"/"sender"/"recipient". Повторять этот тест при следующем коннекте клиента.
  • drop - Оборвать соединение с ответом SMTP 521. Повторять этот тест при следующем коннекте клиента. это событие совместимо с Postfix SMTP параметром smtpd_forbidden_commands.

Прочие ошибки

Когда SMTP-клиент неожиданно разрывает соединение, это логгируется так:
HANGUP after time from [address]:port in test name .
Расшифровка: SMTP-клиент [address]:port разорвал соединение через time секунд после начала теста test name.
Это не ведет к негативным последствиям. Клиент, который разорвал соединение, без использования команды "QUIT", все еще может пройти все Postscreen-тесты.

Следующие ошибки поступают от SMTP-движка. Этот движок никогда не принимает письма, поэтому он имеет ограничения для каждого сеанса на количество команд и продолжительность сессии.

COMMAND TIME LIMIT from [address]:port after command .
Расшифровка: SMTP-клиент [address]:port достиг лимита времени, указанного в параметре postscreen_command_time_limit. Сессия была немедленно прекращена. Часть after command логгируется только с версии Postfix 2.10.

COMMAND COUNT LIMIT from [address]:port after command .
Расшифровка: SMTP-клиент [address]:port достиг лимита на количество команд, указанного в параметре postscreen_command_count_limit. Сессия была немедленно прекращена. Часть after command логгируется только с версии Postfix 2.10.

COMMAND LENGTH LIMIT from [address]:port after command .
Расшифровка: SMTP-клиент [address]:port достиг лимита длины команд, указанного в параметре line_length_limit. Сессия была немедленно прекращена. Часть after command логгируется только с версии Postfix 2.10.

Когда SMTP-клиент производит слишком много подключений за определенное количество времени, или когда порт Postscreen занят (перегружен), происходит отказ соединения со статусом "421" и следующим логгированием:

NOQUEUE: reject: CONNECT from [address]:port: too many connections

NOQUEUE: reject: CONNECT from [address]:port: all server ports busy

Параметры postscreen_client_connection_count_limit и postscreen_pre_queue_limit контролируют эти лимиты.


Когда все тесты пройдены успешно

Когда новый SMTP-клиент успешно проходит все тесты (т.е. он не внесен в какой-либо белый список), Postscreen логгирует это так: PASS NEW [address]:port , где [address]:port - IP-адрес клиента и порт. Затем Postscreen создает запись во временном белом списке, избавляя IP-адрес от дальнейших тестирований, на время пока время допустимого присутствия этой записи в белом списке не истечет, что регулируется параметрами postscreen_*_ttl parameters.

Если глубокое тестирование протокола не задействовано, Posctscreen немедленно передает соединение Postfix SMTP. Клиент не будет ощущать присутствие Postscreen (за исключением задержки, указанной в postscreen_greet_wait).

Если глубокое тестирование протокола включено, Postscreen не отдаст соединение для прямого коннекта с Postfix SMTP в середине своей сессии (т.е. здесь может быть либо "мягкий отказ", либо "полный отказ", либо пропуск теста по причине присутствия клиента в постоянном/временном белом списке). Вместо этого Postscreen задерживает доставку почты, выдавая предупреждение с 4XX статусом, логгирует информацию "helo"/"sender"/"recipient", и ожидает отключения клиента. В следующем подключении клиент будет допущен к прямому соединению с Postfix SMTP. Postscreen компенсирует последствия такого неудобного поведения длительным сроком допуска для клиентов прошедших глубокое тестирование. Это регулируется параметром postscreen_cache_retention_time = 7d (по умолчанию - 7 дней){информация требует проверки и уточнения}.


Подключение Postscreen в файлах конфигурации

Включение Postscreen без блокирования почты

Безболезненное подключение Postscreen без блокирования почты:

  1. По-видимому локальные клиенты, и системы с нестандартными SMTP реализациями, должны быть исключены из Postscreen тестирования. По умолчанию исключены все клиенты mynetworks. Можно исключить других клиентов, например, сторонние реализации инструментов мониторинга:

    /etc/postfix/main.cf :

    # Exclude broken clients by whitelisting. Clients in mynetworks
    # should always be whitelisted.
    postscreen_access_list = permit_mynetworks, 
        cidr:/etc/postfix/postscreen_access.cidr

    /etc/postfix/postscreen_access.cidr :

    192.168.254.0/24 permit
  2. Необходимо закомментировать строку "smtp inet ... smtpd" в файле "master.cf", включая все параметры "-o parameter=value", следующие следом за ней.

    /etc/postfix/master.cf :

    #smtp      inet  n       -       n       -       -       smtpd
    #    -o parameter=value ...
  3. Необходимо добавить строку "smtpd pass ... smtpd" в файле "master.cf" и перенести под нее все опции "-o parameter=value" закоментированные на предыдущем шаге.

    /etc/postfix/master.cf :

    smtpd     pass  -       -       n       -       -       smtpd
        -o parameter=value ...
  4. Необходимо добавить строку "smtp inet ... postscreen" в файл "master.cf".

    /etc/postfix/master.cf :

    smtp      inet  n       -       n       -       1       postscreen
  5. Необходимо добавить строку "tlsproxy unix ... tlsproxy" в файл "master.cf". Этот сервис добавит поддержку "STARTTLS" в Postscreen.

    /etc/postfix/master.cf :

    tlsproxy  unix  -       -       n       -       0       tlsproxy
  6. Необходимо добавить строку "dnsblog unix ... dnsblog" в файл "master.cf". Этот сервис добавит поддержку DNSBL и логгирование результатов в Postscreen.

    /etc/postfix/master.cf :

    dnsblog   unix  -       -       n       -       0       dnsblog
  7. Для включения DNSBL, необходимо указать списки сайтов "DNS-blocklist", разделенные пробелом. Разные сайты могут иметь разный вес. Например

    /etc/postfix/main.cf :

    postscreen_dnsbl_threshold = 2
    postscreen_dnsbl_sites = zen.spamhaus.org*2 
        bl.spamcop.net*1 b.barracudacentral.org*1

    ВАЖНО! Если Ваши DNSBL запросы содержат секретную часть в доменном имени, необходимо будет включить эту информацию в Postscreen SMTP-запросы. Например

    /etc/postfix/main.cf :

    postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply

    /etc/postfix/dnsbl_reply :

    # Secret DNSBL name        Name in postscreen(8) replies
    secret.zen.spamhaus.org    zen.spamhaus.org

    Формат texthash: аналогичен hash:, за исключением того, что не требует запуска postmap перед использованием файла, и не реагирует на изменения в нем после того, как файл был хотя бы один раз прочитан. Это доступно с версии Postfix 2.8.

  8. Необходимо перезагрузить конфигурацию service postfix reload .

Замечания:

  • Некоторые параметры конфигурации Postscreen, реализуют стресс-зависимое поведение. Это утверждение касается только только тех параметров, у которых значение по умолчанию является стресс-зависимым (т.е. вывод postconf -d parametername показывает parametername = ${stress? something}${stress: something} ). Прочие параметры всегда действуют так, как если значение "stress" является пустой строкой.
  • См. также подробности логгирования выше.
  • Для Postfix версии 2.6 и более ранних, необходим полный перезапуск (postfix stop ; postfix start ). Это необходимо потому, что тип "pass" Postfix master сервиса работает не достаточно надежно на всех системах.

Использование TLS в Postscreen

Поддержка TLS в Postscreen доступна для удаленных SMTP-клиентов, отсутствующих в белых списках, в т.ч. для клиентов, которым необходимо возобновить свой статус во временных белых списках. Когда удаленный клиент запрашивает TLS-подключение, Postscreen незаметно устраняется, чтобы обеспечить соединение с процессом tlsproxy. После этого tlsproxy шифрует и дешифрует сообщения между Postscreen и удаленным клиентом. Один процесс tlsproxy может работать с несколькими SMTP-сессиями. Количество процессов tlsproxy может постепенно увеличиваться с увеличением нагрузки на сервер, но их всегда будет меньше, чем число Postscreen TLS-сессий.

Поддержка tlsproxy для Postscreen использует те же параметры, что и для smtpd. Рекомендуется указывать связанные параметры конфигурации глобально в "main.cf". Если необходимо указать переопределяющий параметр "-o smtpd_mumble=value" в "master.cf" для процесса smtpd, связанного с Postscreen, то такие же переопределяющие параметры необходимо указать для процессов postscreen и tlsproxy в "master.cf".

Особенности блокирования почты в Postscreen

Для совместимости с smtpd, postscreen реализует элемент безопасности soft_bounce. Это заставляет Postfix отклонять почту с кодом ответа, интерпретируемом как: "попробуйте еще ​​раз".

  • Чтобы включить soft_bounce глобально для всего Postfix, необходимо указать soft_bounce = yes в "main.cf".

  • Чтобы включить soft_bounce только для postscreen, необходимо добавить строку "   -o soft_bounce=yes" в "master.cf" под postscreen (пробелы вокруг "=" недопустимы, а перед "-o" - обязательны).

Для вступления изменений в силу необходимо выполнить service postfix reload .
После тестирования, не забудьте удалить soft_bounce, иначе отправители будут получать уведомление о том, что почта не доставлена, лишь спустя несколько дней.

Для правильного блокирования почты в Postscreen, необходимо отредактировать "main.cf":

  • После указания "postscreen_dnsbl_action = enforce", будут отброшены ("reject") клиенты, которые были найдены в "DNS blocklists", с логгированием информации о них: "helo"/"sender"/"recipient". С хорошим DNSBL это резко уменьшит нагрузку на Postfix SMTP.

  • После указания "postscreen_greet_action = enforce", будут отброшены ("reject") клиенты, которые посылают команды не дождавшись приветствия, с логгированием информации о них: "helo"/"sender"/"recipient". Это, например отсекло более половины всех подключений зомби к серверу разработчика Postfix Wietse. Это дополнительная защита от тех зомби, что еще не занесены в черный список.

  • Можно так же включить глубокое тестирование протокола, но оно более тяжелое чем DNSBL или тестирование "перед приветствием".

    Когда живой клиент проходит глубокое тестирование протокола, Postscreen добавляет клиента во временный белый список, но он не может передать соединение Postfix SMTP в середине Postscreen-сессии. Postscreen отвергает прием почты от такого клиента со статусом ответа "4XX" и логгированием информации о нем: "helo"/"sender"/"recipient", ожидая его отключения и последующего повторного подключения.

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

    Неожиданной выгодой от глубокого тестирования протокола является то, что клиенты, которые были определены как "живые", не возвращаются после мягкого отказа, что означает, что они не были "живыми". Разработчик Postfix Wietse сам использует глубокое тестирование на своем сервере.

  • Существует так же поддержка постоянных белых и черных списков. См. описание использования параметра postscreen_access_list выше.

Отключение Postscreen

Чтобы правильно отключить Postscreen и обрабатывать почту напрямую Postfix SMTP:

  1. Необходимо закомментировать строку "smtp inet ... postscreen" в файле "master.cf", и все опции "-o parameter=value" после нее

    /etc/postfix/master.cf :

    #smtp      inet  n       -       n       -       1       postscreen
    #    -o parameter=value ...
  2. Необходимо закомментировать строку "dnsblog unix ... dnsblog" в файле "master.cf"

    /etc/postfix/master.cf :

    #dnsblog   unix  -       -       n       -       0       dnsblog
  3. Необходимо закомментировать строку "smtpd pass ... smtpd" в файле "master.cf", и все опции "-o parameter=value" после нее

    /etc/postfix/master.cf :

    #smtpd     pass  -       -       n       -       -       smtpd
    #    -o parameter=value ...
  4. Необходимо закомментировать строку "tlsproxy unix ... tlsproxy" в файле "master.cf", и все опции "-o parameter=value" после нее

    /etc/postfix/master.cf :

    #tlsproxy  unix  -       -       n       -       0       tlsproxy
    #    -o parameter=value ...
  5. Необходимо РАСкомментировать строку "smtp inet ... smtpd" в файле "master.cf", и все опции "-o parameter=value" после нее

    /etc/postfix/master.cf :

    smtp       inet  n       -       n       -       -       smtpd
        -o parameter=value ...
  6. Перезагрузить конфигурацию: service postfix reload .


Тестирование - письмо от GMail и из telnet, и пр.

Этот раздел был добавлен мной позже, поскольку тестирование дало интересные результаты.

Тестирование из telnet дало предполагаемый результат (в /var/log/mail.log ). Всё произошло точно по документации.

Тестовое письмо от GMail принесло неожиданный сюрприз. Каждая следующая попытка (со стороны GMail) отправить письмо после мягкого отказа (450) происходила с нового IP. И для каждого IP опять запускались тесты, и опять происходил мягкий отказ и следующее подключение происходило опять с нового IP.

Это печально, и вывод по-видимому один - глубокое тестирование стоит включать не сразу, а только после того как будет накоплена достаточная статистика "PASS OLD" временного белого списка (из которого, кстати, можно дополнить постоянный).


Примечание:
Просмотр значения любого активного параметра (напр.: "postscreen_greet_wait") postconf | grep postscreen_greet_wait .


Можно просмотреть информацию об IP в кэше btree postmap -q IP.IP.IP.IP btree:/var/lib/postfix/postscreen_cache . Здесь открывается широкий простор для исследований и творческих поисков. :)


Можно просмотреть информацию об IP в черном/белом списке

# postmap -q IP.IP.IP.IP cidr:/etc/postfix/postscreen_access.cidr
permit

Вторая строка "permit" - это ответ (может быть и "reject" или вообще ничего). И по-видимому здесь так же открывается простор для исследований и творчества. :)

Найти в логе строки с IP прошедшими все тесты cat /var/log/mail.log | grep "PASS NEW"

Найти в логе строки с IP прошедшими все тесты и подключавшимися после этого еще cat /var/log/mail.log | grep "PASS OLD"



Источники

Источники информации и ссылки перечислены на отдельной странице, указанной внизу главной страницы темы:
Установка и настройка почтового сервера

Рекламные ссылки:
Комментариев: 6 RSS

Здравствуйте. А есть простой способ переместить письма из Sent одного пользователя в Sent Другого?

Здравствуйте. Не знаю можно ли считать это простым способом, но единственный 100% способ, это с использованием incron. По крайней мере для этих версий программ.

См. здесь, (речь о копиях, но перенос от копии отличается только уничтожением исходного письма):

http://dummyluck.com/page/bcc_sent_copy_postfix_dovecot_2

Dummy Luck

2015-01-07 в 18:57:20

---

Спасибо за Ваш ответ. Постараюсь сформулировать вопрос поточнее. В нашей почтовой системе только зарегистрированные пользователи. Входящие письма форвардятся на USER1, фильтруются sieve и раскладываются в соответствующие папки USER1. Исходящие USER1 фильтруются по тем же правилам sieve-filter. Если ответить на любое письмо из папки USER1 от имени USER2, то естественно копия письма окажется в Sent USER2. Вижу только два варианта решения проблемы. №1 - (лучшее решение) Заставить postfix копии отправленных писем от любого пользователя размещать в Sent USER1. Не знаю как. №2 incrontab следит за состоянием Sent ВСЕХ юзеров, перехватывает письмо вида (1418129126.M882072P14164.crm,S=1366,W=1407:2,S) и форвардит его USER1, ( тоже не знаю как, пока не получилось), где оно фильтруется Sieve и попадет в нужную папку USER1 согласно правилам. Подскажите действующий способ на Ваше усмотрение. Буду признателен.

2 Игорь.

Не знаю правильно ли я Вас понял, но...

Если Вас устраивает сохранение _копий_ всех отправленных, то имеет смысл использовать параметр "sender_bcc_maps" Postfix.

Копии всех отправленных будут отправляться на USER1 к примеру, а там с помощью Sieve раскладываться по нужным папкам.

Что касается Incron, то его надо использовать для _всех_ (любых) исходящих писем (incron следит за соответствующей папкой каждого пользователя) вместе с инструментом командной строки sieve-filter и потом помечать письмо, как обработанное. См. ссылку в первом ответе - там разобрана как раз эта проблема достаточно подробно.

Dummy Luck4

2015-01-08 в 16:45:46

--

Спасибо, сработало. Использовал sender_bcc_maps + incron совместно с sieve-filter. Еще раз спасибо за Ваши рекомендации.

2 Игорь

Рад был помочь.

Добавление/удаление отслеживания с помощью incron можно синхронизировать с добавлением/удалением пользователей (автоматизировать процесс, чтобы не работать с incron вручную). Но при работе через админ. почтовый web-интерфейс надо будет решить проблему владельца создаваемых файлов. Это можно сделать с помощью того-же incron.

Вопросы по теме статьи (просьба - без личностей), - присутствует премодерация:
   - регистрироваться НЕ обязательно! -

Комментарий будет опубликован только после проверки

Вы можете войти под своим логином или зарегистрироваться на сайте.

(обязательно)