При перезаписи адресов в заголовке сообщения вам необходимо подумать о том, как применять фильтры. В частности, следует решить, когда вы будете просить Postfix перезаписывать адреса (например, посредством virtual_alias_maps) – до или после фильтрации. Если вы примете решение перезаписывать адреса перед фильтрацией, то появится риск использования внутренних адресов для возвратов и предупреждений. Например, предупреждение, вызванное сообщением адресату moe_helden@example.com, может быть возвращено с адресом mh123@mailbox.example.com.
Поэтому с нашей точки зрения следует перезаписывать адреса (используя virtual_alias_maps или canonical_maps) после возвращения сообщений обратно в очередь Postfix для финальной доставки. Это позволит внешнему приложению (например, антивирусной программе) видеть исходные адреса и формировать соответствующие предупреждения до того, как Postfix их заменит. Существуют два способа отмены преобразования адресов (расширения виртуального псевдонима, канонического преобразования, трансляции адреса и т. д.) перед фильтрацией. Первый заключается в установке специального параметра в файле main.cf: receive_override_options = no_address_mappings Вы также можете отключить перезапись адресов в файле master.cf только для принимающего сообщения из сети демона (обычно это smtpd): smtp inetnn smtpd o content_filter=foo:[127.0.0.1]:54321 o receive_override_options=no_address_mappings ...
Стандарты RFC говорят о том, что почтовый сервер должен решить, принять или отвергнуть сообщение, не позднее, чем на этапе команды DATA в диалоге SMTP. К сожалению, такое требование оставляет почтовому серверу мало времени на анализ содержимого сообщения, т. к. в почтовых клиентах реализован достаточно короткий таймаут с тем, чтобы не «зависнуть» в общении с неисправным почтовым сервером.
Например, таймаут для SMTP клиента Postfix определяется параметром smtp_data_done_timeout, который весьма толерантен и по умолчанию установлен в 600 секунд. Если почтовый сервер завершает просмотр содержимого до истечения клиентского таймаута, все работает отлично, т. к. у сервера есть время на уведомление клиента о своем решении в отношении приема сообщения. Однако если сервер работает слишком медленно, то клиент заканчивает соединение и повторяет попытку позже, при этом шансы на успех при следующей попытке невелики. Имеющийся в Postfix механизм content_filter позволяет избежать таких проблем благодаря специальной организации исследования содержимого:
1. Почтовый клиент отправляет содержимое на этапе DATA. 2. Сервер Postfix принимает сообщение и ставит его в очередь. Клиент предполагает, что передача была успешной. 3. Диспетчер очередей анализирует почту и составляет расписание доставки согласно записям content_filter. 4. Postfix передает сообщение внешнему приложению. 5. Внешнее приложение берет на себя доставку сообщения. Оно может выполнить для сообщения одно из следующих действий:
Описанные в предыдущих главах встроенные фильтры предназначены для решения простых проблем; более сложную фильтрацию поручают внешним программам. Postfix может запускать приложения проверки содержимого до или после постановки сообщений в очередь. Если почта фильтруется до постановки в очередь, то Postfix может оставить уведомление отправителей на усмотрение клиента. Если же почта фильтруется после постановки в очередь, ответственность за уведомления несет Postfix В этой главе в общих чертах описан процесс передачи полномочий. Вы увидите, как настроить архитектуру демонов Postfix для отправки сообщений внешним механизмам фильтрации и как позволить сообщениям вернуться в систему Postfix после успешной фильтрации для окончательной доставки.
Внешние фильтры содержимого вступают в дело, когда со сцены уходят встроенные фильтры заголовков и тела сообщения; внешние приложения не только исследуют и отвергают сообщения, но и могут изменять их содержимое. Приведем несколько стандартных задач для фильтров: • Добавление «отказа от ответственности» (disclaimer) • Проверка на наличие вирусов и червей • Выявление спама • Архивирование почты
