Postfix - описание настроек, в контексте рассматриваемой конфигурации

В заметке - частичный вольный перевод официальной документации Postfix + отсебятина. Разобраны некоторые механизмы работы, приведен список инструментов командной строки, рассмотрены параметры настроек конфигурационных файлов (выборочно) и пр. Все примеры в первую очередь применялись для Debian, хотя это не должно создать проблем для тех, у кого другая ОС.
Затронуты только самые ключевые моменты, - минимум необходимый для "вхождения в тему".
В заметке есть и вопросы, которые пока остаются без ответа. Кроме того возможны неточности - это скорее конспект-шпаргалка, чем достоверный справочник.

Эта страница является частью списка заметок о настройке почтовой системы:
Установка и настройка почтового сервера

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

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

Содержание

• Postfix - общие моменты
• Процессы
• Файлы конфигурации
• Параметры глобально и избирательно
• Очередь
• PostfixAdmin
• Сервисы, демоны, серверы
• Очередность событий Postfix
• Упрощенная схема
• Некоторые элементы схемы
• receive_override_options = ...
• Манипуляции с адресом до и после очереди
• Очередность обработки
• До очереди
• Rewrite addresses to standard form
• Canonical address mapping
• Address masquerading
• Automatic BCC
• Virtual alias address mapping
• Проверка получателя через verify (пробное письмо)
• После очереди
• Resolve address to destination
• Mail transport switch
• Relocated users table
• Generic mapping (SMTP/LMTP)
• Local alias database
• Local per-user .forward files
• Local catch-all address
• Фильтрация контента
• SASL
• Submission - отключение на 25 порту извне предложения аутентификации после EHLO
• Postfix, Sendmail, Heirloom Mailx (nail) и PHP
• Heirloom Mailx (nail)
• PHP - отправка письма
• Postfix - эмуляция Sendmail
• Многоуровневая защита в Postfix
• OpenDKIM - цифровые подписи, и SPF
• DKIM
• Yahoo DomainKeys
• DKIM ADSP
• DKIM ATPS
• SPF
• Проверка DKIM и SPF через Gmail
• Сторонние сервисы онлайн-тестирования
• Postgrey vs Postscreen
• Postgrey
• Postscreen
• ClamAV
• Amavis/Amavis-new
• Spamassassin
• Список специальных переменных для SQL-запросов
• Список инструментов командной строки
• Источники

Postfix - общие моменты

Процессы

Postfix использует master-демон, который управляет множеством других вспомогательных (работающих с ограниченными правами), загружаемых динамически - только когда в них есть необходимость, и выгружаемых из памяти в случае ненадобности. Все они могут быть настроены в файле конфигурации /etc/postfix/master.cf . Некоторые частично описаны (см. ссылку ниже).

Файлы конфигурации

Postfix определяет общие настройки в файле /etc/postfix/main.cf , и настройки конкретных сервисов (демонов) в файле /etc/postfix/master.cf . Например можно установить отсылку BCC-копий (скрытых) всех отправляемых сообщений в общих настройках, а потом в файле /etc/postfix/master.cf уточнить поведение конкретного сервиса, добавив под строкой сервиса соответствующую опцию: "    -o receive_override_options=no_address_mappings", тем самым отключив манипуляции с адресом (в т.ч. авто-BCC) для этого сервиса.
Можно исследовать каталог "/usr/share/postfix/" - там находятся примеры конфигурационных файлов. Например файл "main.cf.dist" содержит достаточно подробное описание многих важных параметров.

Параметры глобально и избирательно

Большинство параметров могут иметь две области применения (в т.ч. одновременно): глобальную - в файле "main.cf" и избирательную - в опциях сервисов, в файле "master.cf". Т.е. одна и та же опция может быть задействована в разном контексте с разным результатом. И, при дублирующем одновременном использовании, избирательное значение переопределяет глобальное для выбранного сервиса.
Например можно указать глобально для "smtpd" использование TLS = "may" (возможно, - по выбору клиента)

/etc/postfix/main.cf

smtpd_tls_security_level = may

Но в "mastr.cf", только для сервиса "submission" (smtpd на порту 587), изменить условие использования TLS - сделать его обязательным! И это переопределит глобальную настройку - но только для выбранного сервиса

/etc/postfix/master.cf :

ВАЖНО! Указание опций "   -o ***" для любых сервисов в "master.cf" всегда должно начинаться с двух пробелов и не должно содержать пробелы вокруг "=".

Очередь

Postfix имеет четыре типа очереди: maildrop, incoming, active и deferred.
maildrop принимает письма отправленные локально и передает в incoming после некоторой обработки.
incoming хранит поступающие сообщения, которые еще не успел обработать менеджер очереди qmgr.
active (активная) - очередь ограниченного размера (в целях защиты от перегрузки), которая принята в обработку qmgr.
deferred (отложенная) - очередь сообщений, которые тоже приняты к обработке, но временно отложены из за переполнения активной очереди.

PostfixAdmin

Важно понимать, что положение PostfixAdmin в этой почтовой системе - декларативное. Он ничего не делает за пределами своей базы и ни на что напрямую не влияет (за исключением возможности выполнять скрипты в нескольких случаях: после событий добавления ящика, удаления ящика, редактирования ящика, домена; но у этих скриптов ограниченные возможности, т.к. запускаются они от пользователя "www-data").

Т.е. PostfixAdmin производит изменения только в своих SQL-таблицах. И только когда Postfix или Dovecot сами обращаются к ним, - происходит реальное взаимодействие. Чаще всего, это проверка пользователя и пароля, а так-же получение связанной дополнительной информации. Поэтому для того, чтобы PosfixAdmin на что-либо влиял, нужно будет специально настроить Dovecot и Postfix на считывание информации из его базы.

Таким образом, любые параметры, изменяемые PostfixAdmin, должны быть задействованы во внешних SQL-запросах Dovecot и Postfix - иначе они не имеют никакого смысла и будут хранится пустым грузом. Например если Dovecot, в своих запросах к базе PostfixAdmin, не проверяет флаг активности ящика, то несмотря ни на какие изменения в PostfixAdmin, Dovecot будет считать любой ящик - активным. И т.п.

Есть два входа: для интерфейса суперадмина - domain.tld/postfixadmin, и для пользователей (например, чтобы отредактировать свои автоответчики) - domain.tld/postfixadmin/users. Впрочем второе может быть небезопасно для системы в целом.

Сервисы, демоны, серверы

Некоторые сервисы/демоны:

• smtpd - сервер, к которому коннектятся другие сервера (порт 25), для того, чтобы отдать ему его почту
• smtp - сервис (клиент), который коннектится к другим серверам, чтобы отдать им их почту
• submission - сервис переопределяющий порт (с 25 на 587), к которому должен подключаться MUA для отправки почты
• qmgr - менеджер очереди сообщений, маэстро, который правит весь бал
• flush - "секретарь" менеджера очереди сообщений, "по блату" (ETRN) переставляющий нужные сообщения в начало очереди
• anvil - "наковальня", - отодвигает "назойливых", контролирует количество сессий и частоту запросов
• cleanup - упаковщик, педант, чистюля: дополняет заголовки, исправляет/дополняет/подчищает адреса и т.п.
• bounce (defer, trace) - отслеживает доставку сообщений, журналирует каждую; после окончания - удаляет запись журнала
• verify - проверка отправителя/получателя (в т.ч. у себя) на этапе SMTP-сессии, путем отправки фейкового письма (с отменой доставки)
• rewrite/trivial-rewrite - перезаписывает адреса (через cleanup), может использовать списки (таблицу) и регулярные выражения
• pickup - посредник; подхватывает готовый файл из очереди maildrop, читает его, проверяет, и передает считанные данные cleanup
• virtual, local - встроенные LDA (дублируют часть функций Dovecot)
• showq - предоставляет отчет о состоянии очереди
• spawn - указывает Postfix слушать назначенный в опциях сокет, при обращении к которому выполнять внешнюю команду (из тех же опций)
• policyd-spf - запрашивает TXT-запись в DNS, и проверяет в SPF допуск для подключающегося MTA
• postscreen - "пограничник" - блокиратор зомби-компьютеров, эмулирующий SMTP-сессию и проводящий рад тестов SMTP-клиента

Зомби - зараженные компьютеры, хозяева которых могут не знать о том, что они источники спама.

Очередность событий Postfix

Упрощенная схема

Отправка почты наружу, прием почты снаружи, отправка почты в пределах домена, - во всех ситуациях, в которых почтовый сервер выступает в роли принимающего и/или отправляющего - почта проходит цепочку обработок от входа до доставки, согласно нижеприведенной схемы (релей в этой серии заметок не рассматривается).

элемент

- тип очереди

элемент

- активный сервис, используемый в рассматриваемой конфигурации

элемент

- сервис, не используемый в рассматриваемой конфигурации

Некоторые элементы схемы

trivial-rewrite

Работает в трех типах запросов.

До очереди incoming:

rewrite - перезапись адреса в связанном контексте

• local - добавление к неполным адресам доменного имени, указанного в "$myorigin" или "$mydomain"
• remote - добавление к неполным адресам доменного имени, указанного в "$remote_header_rewrite_domain"

verify * - проверка адреса отправителя через пробное пустое письмо (с отменой)

* В свежих примерах настройки "master.cf" в официальной документации, - verify присутствует как отдельный демон.

После очереди active:

resolve - анализ адреса отправителя^{{может "получателя"? ошибка в доках?}}, чтобы определить

• transport - агент доставки
• nexthop - хост отправки и, опционально, метод доставки
• recipient - адрес получателя, допущенный nexthop
• flags - адрес класса, требует ли адрес трансляции, имеет ли адрес проблемы, и не является ли запрос не удачным

---

cleanup

Демон реализует заключительный этап обработки новой почты. Он добавляет "From:" и другие заголовки сообщения, организует перезапись адресов к стандартному виду: "user@fully.qualified.domain" (используя для этого trivial-rewrite), и извлекает адреса получателей из заголовков сообщений (опционально). Демон также вставляет результат в виде одного файла в очередь incoming и уведомляет менеджера очереди qmgr о прибытии новой почты. Сервис может быть сконфигурирован для преобразования адресов на основе канонического и виртуального преобразования (маппинга) с использованием запроса данных из специальных таблиц.
Подробнее см. ниже.

---

cleanup

->

incoming

До очереди происходят следующие события обработки (в указанном порядке сверху-вниз):

• Приведение адресов к стандартному виду
• Канонические преобразования
• Маскарадинг
• Формирование автоматических скрытых копий (BCC)
• Преобразование виртуальных алиасов
• Подключение Milter
• Проверка получателя через verify (пробное письмо)

Подробнее см. ниже.

receive_override_options = ...

Для начала пару слов об этом параметре. Его использование со значением "no_address_mappings" ломает весь механизм событий до очереди. По сути из вышеприведенного списка остается работать только первый и последний пункт. При этом, пробное письмо, созданное verify (см. о нем подробнее ниже), не смотря ни на что, пройдет все этапы преобразования, т.к. для пробного письма отмена через "no_address_mappings" не действует! А "настоящее" письмо, которое пойдет следом за пробным - все эти преобразования пропустит (т.к. оно подчиняется "no_address_mappings"). Т.е. может сложится ложная картина - пробное письмо, например для несуществующего адреса пройдет алиас-преобразования и "отрапортует" о том, что всё в порядке (если из этого несуществующего ящика создан алиас для существующего), а настоящее письмо минует алиас-преобразования (из-за "no_address_mappings") и столкнется с тем, что адрес не существует.

Поэтому в случае, если использование "no_address_mappings" неизбежно, лучше убрать все преобразования адреса и перенести их на этап "после очереди". Например использовать lmtp_generic_maps (хотя в этом случае любые ящики-алиасы должны обязательно присутствовать среди активных, даже если они никогда не будут принимать почту). Подробнее об этом параметре см. ниже.

Канонические преобразования, маскарадинг, BCC, Алиасы

Milter

Проверка получателя

---

			/
active	->	qmgr	->
			\

После очереди происходят (могут происходить) следующие события обработки:

• Определение адреса доставки
• Подключение таблицы переключения транспорта
• Подключение таблицы перемещенных пользовательских адресов
• Для доставки через SMTP/LMTP:
• Подмена адресов локальных отправителей для почты наружу (хотя на деле - не только)
• Для доставки через local (встроенную Postfix-LDA):
• Подключение базы локальных алиасов
• Обработка персональных .forward-файлов пользователей
• Обработка почты несуществующих пользователей

Подробнее см. ниже.

---

Манипуляции с адресом до и после очереди

В этом разделе детальнее разобрано то, что коротко перечислено выше. Параметр receive_override_options достаточно подробно был описан выше, поэтому здесь он не подробно упоминается.

Очередность обработки

Postfix не имеет встроенных языков, способных к сложным манипуляциям, но может перезаписывать адреса по таблицам - в очередности, в которой перечислено далее в списке. События происходят на разных этапах (до очереди, после очереди...) в указанном порядке сверху-вниз.

До очереди:

• Rewrite addresses to standard form - перезапись адресов к стандартному виду
• Canonical address mapping - каноническое отображение адреса
• Address masquerading - маскарадинг адресов
• Automatic BCC - автоматические скрытые копии
• Virtual alias address mapping - маппинг виртуального алиаса адреса
• Проверка получателя - через verify пробное письмо

После очереди:

• Resolve address to destination - определение адреса доставки
• Mail transport switch - таблица переключения транспорта
• Relocated users table - таблица перемещенных пользовательских адресов
• Для доставки через SMTP/LMTP:
• Generic mapping (SMTP/LMTP) - подмена адресов локальных отправителей для почты наружу (хотя на деле - не только)
• Для доставки через local (встроенную Postfix-LDA):
• Local alias database - база локальных алиасов
• Local per-user .forward files - персональные .forward-файлы пользователей
• Local catch-all address - почта для несуществующих пользователей

Ссылки в списках частично дублируют раздел "Содержание" и указывают на подразделы на этой же странице ниже.

До очереди

Rewrite addresses to standard form

Прежде, чем демон cleanup запустит обработку адреса через любую таблицу преобразования, будет произведено приведение адреса к стандарту "user@fully.qualified.domain", с использованием демона trivial-rewrite.

Будут произведены следующие преобразования:

• @hosta,@hostb:user@site => user@site
  Эта запись означает: доставить user@site через hosta и hostb. Не рекомендуется использовать.
  ВАЖНО: Postfix версии 2.2 и выше, перезаписывает заголовки сообщений от удаленных клиентов SMTP, только если клиент удовлетворяет указанным в local_header_rewrite_clients параметрам, или если в параметре remote_header_rewrite_domain определено непустое значение.
• site!user => user@site
  Эта функция управляется параметром swap_bangpath (по умолчанию: yes). Цель состоит в том, чтобы адреса в стиле UUCP переписать в доменном стиле. Это полезно только тогда, когда вы получаете почту через UUCP.
  ВАЖНО: Postfix версии 2.2 и выше, перезаписывает заголовки сообщений от удаленных клиентов SMTP, только если клиент удовлетворяет указанным в local_header_rewrite_clients параметрам, или если в параметре remote_header_rewrite_domain определено непустое значение.
• user%domain => user@domain
  Эта функция управляется параметром allow_percent_hack (по умолчанию: yes). Как правило, используется для конструкций, используемых на крупных сайтах, вида: "user%domain@otherdomain".
  ВАЖНО: Postfix версии 2.2 и выше, перезаписывает заголовки сообщений от удаленных клиентов SMTP, только если клиент удовлетворяет указанным в local_header_rewrite_clients параметрам, или если в параметре remote_header_rewrite_domain определено непустое значение.
• user => user@$myorigin
  Эта функция управляется параметром append_at_myorigin (по умолчанию: yes). Категорически не рекомендуется отключать эту функцию, т.к. много компонентов Postfix рассчитаны на то, что все адреса имеют вид "user@domain".
  ВАЖНО! Postfix версии 2.2 и выше, перезаписывает заголовки сообщений от удаленных клиентов SMTP, только если клиент удовлетворяет указанным в local_header_rewrite_clients параметрам; иначе будет добавлено значение параметра remote_header_rewrite_domain если оно указано.
  Если Ваша машина не является основной машиной для $myorigin и Вы хотите, чтобы некоторым пользователям доставка осуществлялась локально без подключения к главной машине, - сделайте запись в таблице виртуальных алиасов, которая перенаправит "user@$myorigin" на "user@$myhostname".
• user@host => user@host.$mydomain
  Эта функция управляется параметром append_dot_mydomain (по умолчанию: yes). Цель состоит в том, чтобы пройти совместимую обработку различных форм одного и того же имени узла.
  ВАЖНО: Postfix версии 2.2 и выше, перезаписывает заголовки сообщений от удаленных клиентов SMTP, только если клиент удовлетворяет указанным в local_header_rewrite_clients параметрам; иначе будет добавлено значение параметра remote_header_rewrite_domain если оно указано.
  В некоторых случаях такая перезапись не нужна, - поэтому она сделана отключаемой.
• user@site. => user@site (без точки в конце).
  Одна точка в конце просто удаляется. Но если адрес заканчивается на несколько точек, - он будет отброшен как неверный.
  ВАЖНО: Postfix версии 2.2 и выше, перезаписывает заголовки сообщений от удаленных клиентов SMTP, только если клиент удовлетворяет указанным в local_header_rewrite_clients параметрам, или если в параметре remote_header_rewrite_domain определено непустое значение.

Canonical address mapping

Прежде, чем демон cleanup передаст входящую почту в incoming, он использует таблицу канонического преобразования, чтобы переписать все адреса в окружении сообщения, и в заголовках сообщения, локальных или удаленных. Маппинг канонических адресов удобен для приведения указанных имен к виду "Firstname.Lastname", или для замены недействительных доменов на допустимые. В дополнение к каноническому маппингу, использующемуся для обоих адресов: отправителя и получателя, можно указать отдельные канонические таблицы, только для адреса отправителя или только для адреса получателя. Например

/etc/postfix/main.cf :

canonical_maps = hash:/etc/postfix/canonical
sender_canonical_maps = hash:/etc/postfix/sender_canonical
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical

Канонические преобразования sender_canonical_maps и recipient_canonical_maps происходят до общих canonical_maps.

Пример таблицы замены

/etc/postfix/canonical :

vasya        Vasily.Pupkin

ВАЖНО! Нельзя забывать, что "sender" и "recipient" зависят от направления почты - входящая/исходящая. Т.е. "web@domain.tld" может быть "sender" в случае отправки почты от его имени, и тогда для него сработает правило sender_canonical_maps, но в случае приема почты в его адрес, он уже будет "recipient", и тогда правило sender_canonical_maps его не коснется.

Тестирование

Создадим ящики "test@domain.tld" и "other@domain.tld".
Сделаем "test@domain.tld" алиасом для "other@domain.tld" с использованием canonical_maps.

• При получении почты с внешнего адреса на подопытный "test@domain.tld", письмо доставляется в ящик "other@domain.tld". В письме изменяется только "Delivered-To: <other@domain.tld>" и встречается упоминание в верхнем "Received: ..." - "... for <other@domain.tld>; ...".
  В остальных "Received: ..." фигурирует "... for <test@domain.tld>; ...", как и в "To: ... <test@domain.tld>"
• При отправке почты от "test@domain.tld" (в т.ч. через sendmail) на внешний адрес, изучение заголовков у получателя показывает, что все "test@domain.tld" заменены на "other@domain.tld". Единственное место, где может остаться упоминание о "test@domain.tld" - это "From: <other@domain.tld> (test)".
  Важно также то, что цифровая подпись (DKIM, см. ниже) валидна - по-видимому наложение подписи происходит после обработки canonical_maps.

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

Address masquerading

Маскарадинг предназначен для того, чтобы скрыть хосты внутри домена за их почтовым шлюзом, сделав вид, что письмо шлет сам шлюз, а не отдельные машины. Маскарадинг осуществляется cleanup, и по умолчанию отключен. Чтобы включить его, нужно отредактировать параметр masquerade_domains в main.cf файл и указать одно или несколько доменных имен, разделенных пробелами или запятыми.
Допускаются такие параметры в

/etc/postfix/main.cf :

• masquerade_domains = домены, которые будут заменены.
  Например, если указать: masquerade_domains = foo.example.com example.com , то замены будут такими:
  "any.thing.foo.example.com" => "foo.example.com"
  "any.thing.else.example.com" => "example.com"
  Можно использовать отрицание: masquerade_domains != foo.example.com example.com
  тогда не измененными останутся "any.thing.foo.example.com" и "foo.example.com", но изменится
  "any.thing.else.example.com" => "example.com".
• masquerade_exceptions = адреса, которые будут исключены из маскарадинга. Например: "root".
• masquerade_classes = envelope_sender, header_sender, header_recipient -> что маскарадить (только отправителя, отправителя в заголовках, получателя).

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

Маскарадинг может быть отключен принудительно - глобально или избирательно,- см. выше.

Automatic BCC

На этом этапе происходит формирование автоматически скрытых копий (BCC). Доступно три параметра:

• always_bcc - отправка копий всех отсылаемых сообщений (включая приходящие извне для почты в домене) - на один указанный адрес
• sender_bcc_maps - сопоставление адреса отправителя (для письма в любом направлении - изнутри и снаружи) с таблицей. Если адрес отправителя найден в таблице - на адрес, который в таблице с ним связан, будет отправлена копия. Если связанный адрес не найден - копия отправлена не будет.
• recipient_bcc_maps - сопоставление адреса получателя (для письма в любом направлении - изнутри и снаружи) с таблицей. Если адрес получателя найден в таблице - на адрес, который в таблице с ним связан, будет отправлена копия. Если связанный адрес не найден - копия отправлена не будет.

Multi-BCC не поддерживаются.

ВАЖНО! К сожалению, тесты показали, что избирательные авто-BCC (в "master.cf", напр.: "   -o sender_bcc_maps=...") - не поддерживаются!

Автоматические BCC могут быть отключены принудительно - глобально или избирательно,- см. выше.
См. так же заметку Копии всех отправленных.

Virtual alias address mapping

Перед выходом почты из cleanup, перед помещением ее в очередь incoming происходит перезапись алиасов адресов получателей для всех локальных, всех виртуальных и всех удаленных мест назначения. Это касается только получателей, и не затрагивает "заголовки содержания" и адрес отправителя

ВАЖНО! Тесты показли, что virual_alias_address_mapping изменяет только "Delivered-To:", т.е. для исходящей наружу почты это не применяется.

Алиасы доменов удобны когда, например, используются зеркала одного домена (***.net, ***.com, и т.п.). Алиасы ящиков могут быть, использованы, например, когда необходимо получать почту несуществующих пользователей на один ящик, и т.п.

Виртуальные алиасы можно использовать и для преобразования имен вида "Firstname.Lastname" в UNIX-имя, но по-видимому для этого удобнее будет Local alias.

Подключается маппинг алиасов примерно так

/etc/postfix/main.cf :

virtual_alias_maps = mysql:/etc/postfix/virtual_alias_domain_maps.cf,mysql:/etc/postfix/virtual_alias_mailbox_maps.cf

Логика PostfixAdmin в отношение алиасов такова, что возможность указать для домена-1 алиас (другой домен-2) доступна при просмотре списка ящиков этого домена-1, а при редактировании ящика наоборот - есть возможность превратить этот ящик в алиас для другого ящика. Немного запутанно и сбивает с толку по-началу, но это именно так и только так.

Кроме того, PostfixAdmin по умолчанию заполняет поле алиаса ящика копией основного значения. Видимо это сделано для того, чтобы не возвращать пустую строку в соответствующем запросе.

При построении SQL-запросов для виртуальных алиасов нужно учитывать вышесказанное, а так же следующее:

• Отключение (не удаление) ящика через интерфейс PostfixAdmin меняет значение (active="0") как в таблице ящиков, так и в таблице алиасов.

• Если запросов несколько (как в примере выше), то отсутствие строк в ответе первого запроса не прекратит дальнейший поиск - будет обработан следующий запрос (указанный далее через запятую для "virtual_alias_maps").

• Если запросов несколько (как в примере выше), то пустая строка в ответе первого запроса тоже не остановит дальнейший поиск - будет обработан следующий запрос (указанный далее через запятую для "virtual_alias_maps"). Пустая строка просто проигнорируется не повлияв на адрес.

• Если запросов несколько (как в примере выше), то НЕ пустая строка в ответе первого запроса, вернувшая значение отличающееся от искомого - не остановит дальнейший поиск, и будет обработан следующий запрос (указанный далее через запятую для "virtual_alias_maps").

• Если запросов несколько (как в примере выше), то НЕ пустая строка в ответе первого запроса, вернувшая значение совпадающее с искомым - остановит дальнейший поиск, и следующий запрос (указанный далее через запятую для "virtual_alias_maps") обработан не будет!

• Преобразований адреса может быть несколько - по цепочке. Например, если почта адресована "user1@domain.tld", который является алиасом для "user2@domain.tld", который в свою очередь является алиасом для "user3@domain.tld", то почта придет на "user3@domain.tld".

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

• Учитывая вышеперечисленное, - если запросов несколько (как в примере выше), то первым должен по-видимому идти запрос таблицы алиаса доменов, (который должен быть построен так, чтобы не возвращать совпадающих с искомым значений), т.к. в PostfixAdmin невозможно указать дублирующее основное значение алиаса для домена, зато можно для ящика.
  Впрочем логикой алиасов можно манипулировать. Если есть необходимость, чтобы сначала отработали алиасы ящиков несуществующего домена, а только потом - сработал алиас на существующий домен, то первым должен идти запрос на алиас ящиков (построенный так, чтобы не возвращать совпадающего значения, даже если оно присутствует). Если все же алиас домена сделать первым, то имя ящика "покинет" пространство имен несуществующего домена, и запросы алиасов ящиков несуществующего домена в нем уже не отработают.

• Следует обязательно учитывать опцию "receive_override_options", т.к. она может нарушить всю логику алиасов. Подробнее см. выше.

КСТАТИ! В маппинге авто-BCC Postfix ведет себя по-другому. Если первый запрос вернул хоть какое-нибудь значение, то следующий запрос обработан не будет.

С учетом всех замечаний выше, запросы можно было бы построить например так

/etc/postfix/virtual_alias_domain_maps.cf :

user = _ИМЯ_ПОЛЬЗОВАТЕЛЯ_
password = _ПАРОЛЬ_К БАЗЕ_
hosts = 127.0.0.1
dbname = _ИМЯ_SQL_БАЗЫ_
query = SELECT CONCAT('%u', '@', target_domain) FROM alias_domain WHERE alias_domain = '%d' AND active = 1

/etc/postfix/virtual_alias_mailbox_maps.cf :

user = _ИМЯ_ПОЛЬЗОВАТЕЛЯ_
password = _ПАРОЛЬ_К БАЗЕ_
hosts = 127.0.0.1
dbname = _ИМЯ_SQL_БАЗЫ_
query = SELECT goto FROM alias WHERE address='%s' AND active = '1'

В приведенных выше примерах не имеет значения - заполнено ли поле алиаса ящика значением дублирующим основной адрес, если алиаса нет (только если запрос алиасов доменов идет первым).

Эти же запросы можно вместо "virtual_alias_maps", использовать на других этапах обработки - например, в lmtp_generic_maps (хотя в этом случае любые ящики-алиасы должны обязательно присутствовать среди активных, даже если они никогда не будут принимать почту).

Проверка получателя через verify (пробное письмо)

Когда Postfix-MTA принимает письмо для получателя в своем домене, он еще на этапе SMTP-сессии создает через verify пробное письмо сам себе с целью проверить - есть ли такой получатель (если проверяется внешний адресат, например получатель не в своем домене - проба происходит на внешний сервер). При этом, само это пробное письмо так и не отправляется - происходит отмена отправки после ответа на команду "RCPT TO"^{{информация нуждается в проверке и подтверждении}}. При проверке, например, внешнего сервера, первая проба может занимать относительно продолжительное время, но после этого результат кешируется и в дальнейшем всё происходит быстрее. Если проверка затягивается то отправляется код 450, после которого отправляющий MTA должен будет повторить попытку позже. "Терпение" самого Postfix-MTA регулируется параметрами address_verify_poll_count (сколько раз повторять попытку проверки, обычн. умолч.=3 раза, умолч. при перегрузке = 1 раз) и address_verify_poll_delay (пауза между попытками проверки, умолч.=3сек). Проверка производится от имени отправителя "double-bounce@$myorigin". Но этот адрес можно изменить или сделать пустым (на случай попадания стандартного в спам-лист) указав пустым соответствующий параметр

/etc/postfix/main.cf :

address_verify_sender =

Нужно учитывать, что не все серверы принимают пустой MAIL FROM.

На время отладки кеширование verify можно (и стоит) отключить

/etc/postfix/main.cf :

address_verify_map =

Но вернемся к получателю в своем домене.

Пробное письмо проходит все стадии манипуляций с адресом перед попаданием в очередь. Это значит, что если "user@domain.tld" является алиасом для "dest@domain.tld", то пробное письмо будет направлено к "dest@domain.tld".

Кроме того конечным "ответчиком" для verify будет Dovecot. Поэтому параметр lmtp_generic_maps тоже участвует в преобразованиях адреса для пробного письма. Это значит, что если в таблице lmtp_generic_maps адресу "dest@domain.tld" сопоставлен адрес "dest_lmtp@domain.tld", то пробное письмо будет направлено к "dest_lmtp@domain.tld".

ВАЖНО! Если в настройках присутствует receive_override_options = no_address_mappings, то пробное письмо его проигнорирует и пройдет через все преобразования, а вот настоящее письмо подчиняясь этому параметру, не подвергнется преобразованиям "до-очереди". Т.е. при включенном receive_override_options = no_address_mappings, одинаково преобразовывать адрес можно будет только после очереди (напр. через lmtp_generic_maps).

Для того чтобы все работало, в "master.cf" должен присутствовать настроенный демон verify и соответствующие restrictions (smtpd_recipient_restrictions = reject_unverified_recipient ) в глобальных или избирательных (для smtpd-сервера в "master.cf") настройках.

Поскольку при отправке почты (наружу или в свой домен), smtpd-сервер Postfix-MTA принимающий подключение, тоже может производить такую проверку, то поведение Postfix-MTA в этой ситуации так же зависит от соответствующей настройки restrictions: smtpd_recipient_restrictions = reject_unverified_recipient , глобально (в "main.cf") или избирательно (в "master.cf") для соотв. сервисов.

Если smtpd_recipient_restrictions=reject_unverified_recipient указана глобально в "main.cf", но отменена избирательно для, например submission (т.е. "smtpd_recipient_restrictions" присутствует, но с другими параметрами), то письмо от MUA через submission будет принято и помещено в очередь на отправку (т.е. сессия с MUA будт завершена удачно). Но сессия, в которой Postfix будет выступать уже в роли клиента, пытаясь отправить принятое от MUA письмо, скорее всего завершится с ошибкой и оно так и не уйдет. И поскольку verify срабатывает в самом конце всех преобразований (хотя и до помещения письма в очередь), то любые авто-BCC все-же будут отправлены - на этапе сессии с MUA.

См. так же заметку Пересылка почты - примеры работы системы в разных ситуациях,
и раздел в ней Отправка писем - общие сведения в контексте рассматриваемой конфигурации.

Рекомендую сменить код ответа для не найденного через verify получателя на 550 (по умолчанию 450), чтобы внешние MTA не пытались сутками отправить Вам отклоненные ранее письма.

/etc/postfix/main.cf :

unverified_recipient_reject_code = 550

В заключение.

Здесь остается несколько вопросов, которые я пока не понял :)

• Почему каждый раз, при попытке приема почты для несуществующего получателя, не отсылаются авто-BCC (если они присутствуют)? Ведь то, что получатель не существует, обнаруживается только в самом конце - verify-проверкой, и уже после этапа авто-BCC. Может быть авто-BCC формируются после verify? Но проверено, что авто-BCC подхватывает "до-алиасный" адрес, а на проверку в verify попадает "после-алиасный"...
• Почему receive_override_options = no_address_mappings не отключает (это проверено) verify?

После очереди

Resolve address to destination

Менеджер очереди qmgr выбирает новую почту из очереди входящих или старую почту из очереди отложенных, запрашивает trivial-rewrite, чтобы перезаписать адреса, а так же демона resolve, чтобы определить как письмо должно быть доставлено.

Начиная с версии 2.0, Postfix выделяет четыре основных класса адреса. Каждый класс имеет свой ​​собственный список доменных имен, и каждый класс имеет свой ​​собственный метод доставки по умолчанию, как показано в таблице ниже.

Список доменов назначения	Метод доставки по умолчанию	Доступно
$mydestination, $inet_interfaces, $proxy_interfaces	$local_transport	Postfix 1.0
$virtual_mailbox_domains	$virtual_transport	Postfix 2.0
$relay_domains	$relay_transport	Postfix 2.0
none	$default_transport	Postfix 1.0

Mail transport switch

Как только демон trivial-rewrite определил метод доставки по умолчанию, он ищет дополнительные таблицы транспорта, для информации, которая переопределит место назначения сообщения и/или способ доставки. Типичное использование таблицы транспорта - для отправки почты в системе, которая не подключена к Интернет, или использование специального клиента SMTP для направлений, к которым есть особые требования.

Таблицы транспорта по умолчанию отключены. Чтобы включить их, необходимо задействовать параметр transport_maps в файле "main.cf", и указать одну или несколько таблиц поиска, разделенных пробелами или запятыми.

Например

/etc/postfix/main.cf :

transport_maps = hash:/etc/postfix/transport

Пример таблицы транспорта

/etc/postfix/transport :

example.tld			smtp:bar.example:2025
my.example.tld			:
.sudomain1.example.tld		error:mail for *.sudomain1.example.tld is not deliverable
.example.tld			:[gateway.example.tld]

Первая строка - указывает использовать для корневого домена smtp-клиент подключающийся на порт 2025 хоста bar.example

Вторая строка - субдомен my.example.tld использует транспорт по умолчанию.

Третья строка - все субдомены для субдомена sudomain1.example.tld вернут ошибку.

Четвертая строка - все субдомены (кроме указанных выше) должны доставляться транспортом по умолчанию на хост gateway.example.tld

В приведенном выше примере, квадратные скобки "[...]" подавляют MX поиск. Это предотвращает петли маршрутизации почты, когда машина является первичной MX для хоста example.tld.

Relocated users table

(таблица перемещенных пользовательских адресов)

Далее, демон trivial-rewrite пропустит каждого получателя через базу relocated. Эта таблицы, содержащие информацию о том, как связаться с пользователями, которые больше не имеет учетной записи, или что делать с почтой для всей области, которая больше не существует. При отправке почты на адрес, который указан в таблице, сообщение возвращается отправителю с объяснительной информацией.

Поиск в базе relocated происходит после представления таблиц транспорта, в ожидании замены одного адреса получателя на другой^{{??? - The relocated database is searched after transport table lookups, in anticipation of transport tables that can replace one recipient address by a different one.}}.

Поиск перемещенных пользователей по умолчанию отключен. Чтобы включить его, необходимо отредактировать параметр relocated_maps в файле "main.cf", и указать одну или несколько таблиц, разделенных пробелами или запятыми.

Пример

/etc/postfix/main.cf :

relocated_maps = hash:/etc/postfix/relocated

/etc/postfix/relocated :

username@example.com      otheruser@elsewhere.tld

Начиная с версии Postfix 2, почта для перемещенных пользователей будет отклонена SMTP сервером с сообщением "user has moved to otheruser@elsewhere.tld". Старые версии Postfix будет получать почту, после чего вернут ее отправителю с таким же сообщением.

Generic mapping (SMTP/LMTP)

Подмена адресов локальных отправителей для почты наружу

Параметр smtp_generic_maps производит подмену адресов отправителей только для почты, уходящей за пределы домена (через SMTP-клиент). Можно указывать конкретные адреса, а можно только домены.

ВАЖНО! Могут возникнуть проблемы при совместном использовании smtp_generic_maps и DKIM - подробнее см. ниже.

* С версии 2.3 можно аналогично для LMTP использовать lmtp_generic_maps.

Например создадим алиас

/etc/generic_aliases :

root	server@domain.tld

В консоли:

# postmap /etc/generic_aliases

Теперь внесем изменения в конфигурацию

/etc/postfix/main.cf :

smtp_generic_maps = hash:/etc/generic_aliases

Перечитывание конфигов

# service postfix reload

Отправим из консоли почту для "output@otherdomain.tld", находясь под "root"

# echo "Test generic mapping" | sendmail  output@otherdomain.tld

Пара замечаний по примеру:

• Поскольку обработка идет только для SMTP-клиента, то замена адреса будет произведена только для исходящей (наружу) почты
• При попытке подмены адреса получателя, происходит следующее - сервер пытается доставить на изначальный домен письмо с новым получателем. Поэтому если там его нет, то доставка не произойдет.
• Не забываем про очередность - подмена адресов этим способом происходит после формирования BCC (а также после канонического преобразования и т.п.). Например, sender_bcc_maps - скрытая копия локального отправителя "root", будет сопоставлена изначальному (не измененному) отправителю, хотя адресату за пределы домена письмо придет с измененным отправителем. Кроме того, скрытая копия так-же может быть будет пропущена через преобразование адресов - если она отправляется наружу.
• В приведенном выше примере письмо удаленному получателю поступит почти без следов "root". Отправитель будет заменен везде, за исключением одного упоминания From: site@domain.tld (root) .

Этим способом можно, например, организовать подмену адреса отправителя для пользователя "www-data" для писем отправляемых сайтом через PHP. См. о PHP ниже.

Пара замечаний по lmtp_generic_maps:

• Поскольку обрабатывается почта проходящая только через LMTP, то замена адреса будет произведена как для входящей (снаружи) почты, так и для почты отправляемой в пределах родного домена (друг другу), но не затронет почту, отправляемую изнутри наружу.
• Этот параметр производит замену адреса как отправителя, так и получателя (баг или фича?) снаружи внутрь, и изнутри - внутрь.
• От отправителя он не оставляет почти никаких следов (кроме хоста MTA и может быть упоминания в "X-Sender:").
• С получателем сложнее. Он изменяется в "Delivered-To:" и "To:" (и доставляется на измененный адрес), но остается и след первоначального адреса - упоминание в каждом "Received:" после "for"
• Обработка адреса происходит после создания BCC. Поэтому, если скрытая копия пройдет через LMTP (внутрь сервера), то ее адрес тоже может быть подвергнут обработке.

Local alias database

Для почты, которая должна быть доставлена локально, local-LDA пропускает получателей через базу алиасов. Маппинг не затронет заголовки сообщения. Типичное использование - листы рассылки или использование аласов для рассылки почты реальным людям. Таблица может быть использована для подстановки имен вида "Firstname.Lastname".

Локальные алиасы включены по умолчанию!
Это может быть что-то вроде

/etc/postfix/main.cf :

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

Вторая строка (alias_database) указывает, что алиасы должны быть обработаны с помощью "newaliases" или "sendmail -bi" (а не "postmap"). Это означает, что в качестве разделителя используется двоеточие

/etc/aliases :

postmaster:	root

После изменений обязательно в консоли:

# newaliases

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

Local per-user .forward files

При использовании local-LDA, пользователи могут контролировать свои собственные методы доставки почты, указывая их в файле ".forward" в своем домашнем каталоге. Синтаксис этих файлов является таким же, как "Local alias" (см. выше), за исключением того, что левая часть строки не указывается (а только новый адрес).

Local catch-all address

(почта для несуществующих пользователей)

Когда local-LDA считает, что получатель сообщения не существует, сообщение, как правило, возвращаются отправителю ("неизвестный пользователь"). Иногда желательно пересылать почту для несуществующих получателей на другую машину. Для этой цели вы можете указать альтернативное место назначения, используя параметр luser_relay.

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

Если Вы используете функцию luser_relay для того, чтобы получать не-UNIX почту, то Вы должны указать

/etc/postfix/main.cf :

local_recipient_maps =

Если не указать пустое значение, то SMTP-сервер отбросит почту не-UNIX пользователя: "User unknown in local recipient table".

В luser_relay может быть указан один адрес. Он будет расширен "$name"^{{информация нуждается в уточнении и дополнении}}.

Примеры.

• $user@other.host , здесь например: "username+foo" будет отправлено "username@other.host"

• $local@other.host , здесь например: "username+foo" будет отправлено "username+foo@other.host"

• sysadmin+$user , здесь например: "username+foo" будет отправлено "sysadmin+username"

• sysadmin+$local , здесь например: "username+foo" будет отправлено "sysadmin+username+foo"

Фильтрация контента

Postfix поддерживает три метода проверки содержимого, начиная от легкой проверки одной строки за раз, до попадания почты очередь, и заканчивая тяжелой, с использованием связанных механизмов, которые производят сложный анализ содержания уже после попадания почты очередь. Каждый подход служит для разных целей.

легкая проверка перед очередью
Этот метод проверяет почту перед его сохранением в очереди, и использует встроенный средства проверки заголовка сообщения и тела сообщения. Хотя главная цель фильтрации состоит в том, чтобы остановить поток почты, зараженной троянами и вирусами, это также полезно для блокирования потока отброшенной (reject) нежелательной почты и перехвата почты с маркерами уведомлений от систем обнаружения вирусов. Этот встроенный в Postfix способ не предназначен для использования в нем регулярных выражений, и не предназначен для реализации функций обнаружения спама и вирусов. Для этого лучше использовать один из методов проверки содержимого описанных ниже в этом же разделе (см. также официальную документацию по "Built-in Content Inspection" и "Postfix Backscatter").

тяжеловесная проверка после очереди
Этот метод проверяет почту после того как она сохраняется в очереди, и использует стандартные протоколы, такие как SMTP или "pipe to command and wait for exit status" (команда через pipe с ожиданием статуса выхода). Этот способ позволяет использовать контент-фильтры произвольной сложности, не вызывая тайм-ауты во время приема почты, и без использования ресурсов памяти на максимальную загрузку.
См. также заметку Postfix - фильтрация после очереди.

средняя проверка перед очередью
Доступны следующие два метода проверки почты перед сохранением в очереди.

• Первый способ использует протокол SMTP (в режиме прозрачного прокси-фильтра). Такой подход доступен с Postfix версии 2.1 и выше.
• Второй способ использует Sendmail 8 Milter протокол. Такой подход доступен с Postfix версии 2.3 и выше. См. подробнее в заметке Postfix - Milter, фильтрация до очереди

Хотя эти способы кажутся привлекательными, у них есть некоторые серьезные ограничения. Во-первых, программы проверки содержимого должны успевать отрабатывать в течение ограниченного периода времени. Если какая-нибудь проверка затянется надолго, то результатом будет большой тайм-аут для входящих. Во-вторых, программы проверки содержимого должны выполняться в ограниченном объеме памяти, т.к. если проверка содержимого отнимет слишком много памяти, то приложения упадут в момент пиковой нагрузки. Проверка перед очередью лимитирует максимальную нагрузку, поэтому для нее существуют ограничения на использование слишком сложных контент-фильтров.

Для особо сложных задач лучше использовать дополнительные внешние средства и программы (антивирусы и сервисы проверки на спам).

SASL

SASL расшифровывается как "Simple Authentication and Security Layer". SASL - это список требований к механизмам аутентификации и протоколам, для их совместимости с SASL, как описано в RFC 4422. IMAP, POP3 и SMTP протоколы имеют поддержку SASL.

Многие люди путают SASL с одной конкретной реализацией SASL: библиотекой Cyrus SASL. Dovecot имеет свою собственную реализацию SASL, которая может рассматриваться отдельно от Dovecot и "конкурировать" с Cyrus SASL.

Postfix версии 2.3 и выше поддерживает два типа SASL: "dovecot" и "cyrus".

Соответственно в настройке Postfix нужно указывать smtpd_sasl_type = dovecot. Это только тип SASL, т.е. стандарт инициированный Dovecot.

ВАЖНО! При использовании в Postfix только LMTP, упоминаний о Dovecot в конфигурационных файлах в Postfix больше нигде не должно встречаться (за исключением имен сокетов и собственно упомянутого выше типа SASL).

Submission - отключение на 25 порту извне предложения аутентификации после EHLO

После настройки submission по инструкции из официальной документации и перенаправления "своих" SMTP-клиентов на 587 порт, подключившись на 25 порт и отправив "EHLO", видим тем не менее большой список, в т.ч. и возможность авторизации.

Чтобы не оставлять даже надежду для брутфорс и отсечь лишний трафик, этот список нужно "почистить".

Для этого нужно удалить глобальные настройки из файла "main.cf" и перенести их в "master.cf" в соответствующий сервис - submission.

Удаляем следующие строки из файла

/etc/postfix/main.cf :

#smtpd_sasl_type = unix
#smtpd_sasl_type = dovecot
#smtpd_sasl_path = private/auth
#smtpd_sasl_auth_enable = yes

Добавляем следующие строки в файл

/etc/postfix/master.cf :

...
submission  inet n       -       -       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_sasl_security_options=noanonymous
...

* Пробелы вокруг "=" не допускаются! Пробелы вначале строк с опциями - обязательны.

После этого авторизация извне на 25 порт исчезнет из списка допустимых команд, который появляется после EHLO. Соответственно, чтобы отправлять почту через SMTP - нужно будет перенастроить MUA-клиентов на 587 порт.

Postfix, Sendmail, Heirloom Mailx (nail) и PHP

Heirloom Mailx (nail)

На мой взгляд эту программу можно спокойно удалить - она совершенно не нужна:

# apt-get --purge remove heirloom-mailx

Если до удаления отправка письма из консоли через "mail" была успешной:

# echo `hostname` | mail -v -s `hostname` root
Mail Delivery Status Report will be mailed to <root>.

То теперь, после удаления, попытка отправить письмо из консоли через "mail" должна выдать ошибку:

# echo `hostname` | mail -v -s `hostname` root
bash: /usr/bin/mail: No such file or directory

PHP - отправка письма

Если в файле /etc/php5/apache2/php.ini , параметр sendmail_path отсутствует (закомментирован), то скорее всего это означает "sendmail -t -i" по умолчанию. Можно изменить это значение и заставить PHP отправлять почту, используя любую указанную программу. Но, поскольку Postfix эмулирует Sendmail (см. следующий подраздел ниже), то в этом нет необходимости.

Можно создать тестовый php-скрипт и, отправив письмо на свой адрес, проверить его заголовки. См. тестовый скрипт для проверки отправки письма из PHP в разделе Проверка отправки почты из PHP, в заметке Пересылка почты - примеры работы системы в разных ситуациях.

В полученном письме наибольший интерес представляют заголовки "User-Agent:", "X-Mailer:", "X-PHP-Originating-Script:". Кроме того, письмо отправляемое, из PHP-скрипта скорее всего будет иметь отправителя "www-data@domain.tld". Вывод напрашивается очевидный - по-видимому всё лишнее стоит оттуда убрать. *

Имя скрипта можно удалить из писем вместе с "X-PHP-Originating-Script:" настройкой PHP (потребуется рестарт Apache)

/etc/php5/apache2/php.ini

mail.add_x_header = Off

А подменять отправителя (если это нужно) можно используя например алиасы.

* Есть подозрение, что эти специфические заголовки можно использовать для контроля за PHP (например разрешить отправку только определенным скриптам), уменьшив тем самым возможности рассылки спама, в случае взлома сайта. Хотя не все так однозначно - например, письмо отправленное из вышеупомянутого тестового скрипта, добавляет заголовок "X-PHP-Originating-Script:", но не имеет заголовка "X-Mailer:". А письмо отправленное, например, при помощи Codeigniter - наоборот.

Кроме того, можно по-видимому проверять получателя отправляемых писем одновременно с проверкой отправителя в Postfix, объединенным SQL-запросом (разрешив, например отправку только зарегистрировавшимся пользователям сайта). Или организовать "отстойник" для всех писем, отправляемых "www-data" в каком-нибудь ящике, с последующей пакетной отправкой после ручного контроля.

Тема интересная и, возможно, имеет право на более глубокое исследование...

Postfix - эмуляция Sendmail

Postfix хорош тем, что заменив Sendmail, ведет себя почти так же как Sendmail. Например в вышеупомянутом случае с PHP отправка по умолчанию должна происходить через командную строку "sendmail -t -i". Postfix берет на себя выполнение этой команды, не смущаясь тем, что в ней присутствует "sendmail", тогда как на самом деле сам Sendmail в системе отсутствует (то, что находится здесь: "/usr/sbin/sendmail" - это не Sendmail, а часть установки Postfix, обеспечивающая эту мимикрию).

Можно протестировать локальную отправку. Сначала создать файл

# nano ~/testmail :

From: <fromtest@test.tld>
To: <root>
Subject: Test message
Test mail via Postfix-sendmail

* "<root>" - можно заменить на любого валидного системного получателя.

И отправить его (первая строка ниже) через Postfix-sendmail, тут же наблюдая ответ (вторая строка ниже), благодаря опции -v

# cat ~/testmail | /usr/sbin/sendmail -t -bm -v
Mail Delivery Status Report will be mailed to <root>.

Удаляем ненужный файл:

# rm ~/testmail

Открыв полученное письмо и изучив исходное содержимое, можно увидеть - через кого оно было отправлено и через кого доставлено в ящик.

Просмотр очереди:

# sendmail -bp

Очистка очереди:

# postsuper -d ALL

Почта системных юзеров, после того, как Postfix становится вместо Sendmail, может отправляться в виртуальный ящик, если он есть для этого юзера, или в "/var/spool/mail/" ("/var/mail/"), если такого ящика нет (в случае если указан альтернативный транспорт для локальных юзеров). При этом в любом случае весь используемый транспорт должен быть настроен, т.к. решение о том, как и куда доставлять почту принимается после обработки менеджером очереди qmgr. И если виртуальный и локальный транспорт не будет настроен, то письмо удалится из очереди и не будет доставлено.

См. выше о транспорте.

Многоуровневая защита в Postfix

Postfix организует несколько уровней защиты:

1. Блокировку посредством Postscreen зомби-спам-ботов, которые генерируют 90% всего спама. Реализован как единый процесс, чтобы сделать эту защиту как можно менее ресурсоемкой.
2. Реализацию более сложного SMTP-контроля, во взаимодействии с Postfix SMTP-серверами, policy-демонами, и Milter-приложениями.
3. Легкую проверку контента через Postfix header_checks и body_checks. На этом этапе может происходить блокирование неприемлемых вложений, таких как вирусы, трояны, с легко распознаваемыми сигнатурами.
4. Тяжеловесную проверку контента с помощью внешних фильтров. Например, с использованием: Amavisd-new, SpamAssassin и Milter-приложений.

Подробнее - см. следующие разделы ниже.

OpenDKIM - цифровые подписи, и SPF

При использовании описанных в этом разделе технологий в DNS должны будут появиться три TXT-записи:

• SPF - список серверов, которым разрешена отправка почты
• DKIM - открытый ключ цифровой подписи
• DKIM ADSP - политика использования DKIM в домене

Раздел содержит описательную информацию, из которой для краткости и ясности удалены подробности. Детальнее установка разобрана в указанных в подразделах ссылках.

DKIM

Использование цифровых подписей в исходящей почте увеличивает ее шансы не попасть в спам, а проверка у входящей почты - дает шанс оценить "солидность" отправителя, - увеличивает вероятность определить: является или не является письмо спамом.

DomainKeys Identified Mail (DKIM) - это технология которая позволяет добавлять цифровую подпись к каждому исходящему письму, которую получатель может проверить, используя ключ опубликованный в соответствующей TXT-записи DNS. Подпись привязывается к доменному имени отправителя и не только подтверждает его, но и гарантирует (в теории), что письмо не подвергалось изменениям.

Вместо ранее привычного dkim-milter его разработчики рекомендуют использовать OpenDKIM.

Настройка его не слишком сложна - нужно установить сам пакет, сконфигурировать его, добавить пару параметров в "main.cf" Postfix, создать закрытый и открытый ключ, после чего опубликовать открытый ключ прямо в DNS.

Подключается DKIM для исходящей почты на этапе "до очереди" через параметры настройки Milter.
См. заметку Postfix - Milter, фильтрация до очереди.

Параметры конфигурации Postfix для DKIM могут выглядеть например так

/etc/postfix/main.cf :

...
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
...

Первая строка здесь говорит о том, чтобы все же принимать даже ту почту, которая не подписана.
Последние две строки указывают на каком порту localhost сервер OpenDKIM ожидает для проверки всю почту (внимание! - как входящую, так и исходящую; входящую - для проверки подписи, исходящую - для наложения подписи).

ВАЖНО! Надо учитывать, что DKIM накладывается до очереди. Поэтому, в случае, если письмо подвергается преобразованиям, например подмене адреса после очереди через smtp_generic_maps, то у получателя будем иметь "dkim=fail".
А вот использование, например canonical_maps для исходящей почты по-видимому происходит до наложения подписи и поэтому, даже после подмены адреса, у получателя она будет "dkim=pass ..." (см. выше тесты с подменой адресов через canonical_maps).

Подробнее о настройке OpenDKIM см. заметку Полный пример установки всех пакетов и настройки конфигурационных файлов.

ВАЖНО! При перечислении нескольких фильтров в smtpd_milters или non_smtpd_milters, накладывание подписи по-видимому должно быть указано последним.

Yahoo DomainKeys

Можно запутаться, но несмотря на схожесть названия - это еще одна технология верификации писем. Технология более старая, по сути - предшественник DKIM. Ее использование по-видимому уже не имеет ни смысла, ни преимуществ.

DKIM ADSP

Еще одна TXT-запись в DNS определяет политику использования DKIM в домене.

• unknown - отправка не подписанных сообщений разрешена (значение по умолчанию)
• all - отправка не подписанных сообщений запрещена
• discardable - все не подписанные сообщения должны быть заблокированы на стороне получателя

Выглядеть эта запись может например так: _adsp._domainkey IN TXT "dkim=all" .

DKIM ATPS

Экспериментальная (пока?) технология, позволяющая подключать третью сторону, делегируя ей право подписывать почту. Пока в стадии обсуждения.

SPF

SPF - это еще одна TXT-запись в DNS, в которой, в простейшем варианте должен быть указан IP сервера которому разрешено отправлять почту. Выглядеть эта запись может например так:

v=spf1 a mx ip4:IP.IP.IP.IP ~all
где IP.IP.IP.IP - IP разрешенного сервера. А последний элемент ~all говорит о том, что не стоит слишком строго учитывать это соответствие (т.е. почта может прийти и от других серверов). Это сделано на случай, если по пути следования почты будет присутствовать какой-нибудь шлюз. В этом случае, если IP MTA совпало с указанным, то это плюс, если не совпало - ничего страшного. :) Для жесткой привязки нужно указывать -all.

Всё описанное выше в этом подразделе касалось того, как пройти проверку на внешних MTA для своей исходящей почты.

Кроме этого, можно настроить проверку SPF для чужой почты извне. Эта проверка может происходить с помощью разных механизмов (и пакетов). Из тех что бросаются в глаза среди доступных в репозитариях Debian, интересны как минимум два: spfmilter и postfix-policyd-spf-python. Из названия следует, что первый работает через Milter, а второй является Python-скриптом.

Остановимся на втором:
# apt-get install postfix-policyd-spf-python .

Настроим policyd-spf через spawn, так, что Postfix будет прослушивать нужный сокет и запускать внешнюю команду, когда будет происходить обращение к нему (это способность spawn)

/etc/postfix/master.cf :

...
# python-postfix-policyd-spf
policyd-spf  unix  -       n       n       -       0       spawn
  user=nobody argv=/usr/bin/python /usr/bin/policyd-spf
...

* Пробелы вокруг "=" не допускаются! Пробелы вначале строк с опциями - обязательны.
"/usr/bin/policyd-spf" - это тот самый Python-скрипт (можно открыть его и просмотреть, например, информацию о разработчике).

После этого надо указать подключение самой проверки через настроенный ранее сервис

/etc/postfix/main.cf :

Я здесь немного опередил события, указав нужный _restrictions (голубым цветом) вместе с check_policy_service для Postgrey (см. ниже), поскольку здесь важна очередность проверок.
Во-первых параметры check_policy_service лучше указывать после всех остальных "smtpd_recipient_restrictions". Во-вторых важно, чтобы они были указаны после reject_unauth_destination, иначе система превратиться в открытый релей. В-третьих Postgrey-policy нужно подключать до "policy-spf", т.к. нет смысла производить эти проверки в обратном порядке.

Использование сокета "unix:private/policyd-spf" обусловлено именем сервиса (policyd-spf) в "master.cf".

С версии Postfix 2.9 можно (в "main.cf") использовать комбинацию prefix_time_limit для сервисов описанных в "master.cf", где prefix - имя такого сервиса.

Перезагрузим конфиги Postfix:
# service postfix reload .

Теперь разберем некоторые настройки. Для этого стоит просмотреть папку /usr/share/doc/postfix-policyd-spf-python, и в частности файл: /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.

Настройки указанные после установки (ниже рекомендации по изменению)
/etc/postfix-policyd-spf-python/policyd-spf.conf :

Приведенные настройки устанавливаются по умолчанию.

Но лучше некоторые из них изменить:

debugLevel - уровень подробности лога. Если указать "0", то будут записаны только ошибки.

defaultSeedOnly - если указать "0" (по-видимому так и стоит сделать), то работать будет в тестовом режиме: только логи и запись информации в заголовки писем, но никакого влияния на доставку писем.

HELO_reject - "False" по-видимому здесь будет более верным значением, чем значение по умолчанию, т.к. отвергать почту после "HELO" при не прохождении SPF-соответствия между "HELO" и "MAIL FROM" - не совсем разумное решение.

Mail_From_reject - "False" по-видимому здесь также будет более верным значением, по тем же причинам. В любом случае результат SPF-проверки будет добавлен в заголовки письма.

PermError_reject - Реакция, в случае если результатом SPF-проверки будет "PermError". Значение по умолчанию ("False") - по-видимому наиболее разумное решение.

TempError_Defer - Реакция, в случае если результатом SPF-проверки будет "TempError". Значение по умолчанию ("False") - по-видимому наиболее разумное решение.

skip_addresses - список сетей, для которых пропускать письма в любом случае, независимо от результатов проверки. ВАЖНО! пробелы в значениях параметров недопустимы.

Подробнее см. в ссылках - Источники.
Также см. заметку Полный пример установки всех пакетов и настройки конфигурационных файлов.

Проверка DKIM и SPF через Gmail

После отправки письма на внешний ящик (например на GMail) заголовки там должны выглядеть примерно так:

pass - главное слово в этих строках :)

sender@domain.tld - адрес отправителя

IP.IP.IP.IP - IP сервера отправителя

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

Сторонние сервисы онлайн-тестирования

Кроме письма на GMail, можно использовать специальные тестирующие сервисы, коих в Интернет достаточно много. Среди них есть такие, что предлагают выслать письмо на рандомно сгенерированный адрес, и в ответ высылают отчет.
Подробнее см. в ссылках - Источники.

ВАЖНО! Возможно, нужно будет дождаться пока обновится DNS. Это может занять от нескольких часов до нескольких суток.

Также см. заметку Полный пример установки всех пакетов и настройки конфигурационных файлов.

Postgrey vs Postscreen

На самом деле это совсем не конкуренты, хотя кое в чем они и действуют похоже (Postgrey - сторонний продукт, Postscreen - часть Postfix). У обоих так или иначе используется идея о том, что если при приеме внешнего письма первый раз давать отказ, а принимать его только после следующих попыток, то по поведению удаленного клиента можно судить о его "нормальности". Отказ должен быть не жестким, как "550", а сообщать о проблемах приема (как "450"), чтобы вызвать повторные попытки доставки через некоторое время. Некоторые администраторы утверждают, что эта технология позволяет отсечь 90% спама.

Но если "Postgrey" заточен под это, и позволяет достаточно гибко настраивать описанную выше технологию, то у "Posrscreen" - это лишь побочный эффект одного из тестов, не являющийся его основной целью. Зато "Postscreen" использует другие интересные фишки. Например, позволяет провести тестирование (анализ поведения) SMTP-клиента еще до начала прямого подключения к Postfix-smtpd и даже до начала приветствия, и делает это по-возможности быстро. Кроме того, "Postscreen" представляет из себя некий щит, удерживающий не желающих отключаться зомби-ботов на эмуляции подключения, не давая им реального доступа к smtpd. Некоторые администраторы в качестве аргумента в пользу Postscreen упоминают также качество кода, присущее Postfix.

Оба продукта используют постоянные и временные списки, в которые клиент попадает только после некоторых проверок, испытаний. И конечно - можно использовать их одновременно - и "Postgrey",и "Postscreen".

Зомби - зараженные компьютеры, хозяева которых могут не знать о том, что они источники спама. И, кстати, идея о том, чтобы удерживать зомби-ботов на эмуляции подключения, не давая им прямого доступа к основным ресурсам... - что-то в ней есть философски-практическое, применимое не только в IT... :)

Postgrey

Это проверенная временем технология, суть которой в том, что для "новичков" (неизвестных ранее) допуск дается только после проверки их настойчивости - не с первого раза. Сначала происходит мягкий отказ (с кодом напр.: "450"), после чего ожидаются повторные попытки. Расчет идет на то, что серверы спамеров экономят ресурсы и не тратят время на стандартную процедуру повторных попыток, которая по умолчанию используется большинством нормальных MTA. Далее работает уже белый список, в котором информация без обновления хранится около месяца (это настраивается) и отказов уже не происходит - проверенная однажды почта, в дальнейшем принимается сразу.

Установка тривиальна:
# apt-get install postgrey

Postgrey сохраняет записи-триплеты вида: "IP_клиента"/"Отправитель"/"Получатель". в базах, которые по умолчанию находятся здесь: /var/lib/postgrey .

Присутствие Postgrey в конфигурации Postfix сводится примерно к следующему

/etc/postfix/main.cf :

Отсюда очевидно следует, что сервис висит на localhost, порт 10023.
Параметр check_policy_service лучше указывать после всех остальных "smtpd_recipient_restrictions". Важно, чтобы он был указан после reject_unauth_destination, иначе система превратиться в открытый релей. Очевидно также, что Postgrey-policy нужно подключать до "policy-spf" (см. выше), т.к. нет смысла производить эти проверки в обратном порядке.

Кроме того, могут быть заданы белые списки - в двух файлах:

• /etc/postgrey/whitelist_clients - белый список клиентов (сессии). После установки весь забит доверенными (с точки зрения разработчиков) серверами. :)

• /etc/postgrey/whitelist_recipients - белый список получателей

Формат строк в белых списках я здесь описывать не буду, - можно использовать подобие с теми что есть, либо обратиться к официальной документации. Настройки самого Postgrey хранятся в файле /etc/default/postgrey . Можно увеличить в нем, например, задержку писем от "новичков" до 30 минут (по умолчанию - 300 сек), уменьшить время неприкосновенности уже "допущенных" до 10 дней ( по умолчанию - 35 дней, и любая активность рестартит этот срок), и после 20 принятых писем автоматом переносить клиента в белый список (по умолчанию - 5):

/etc/default/postgrey

...
POSTGREY_OPTS="--inet=10023 --delay=1800 --max-age=10 --auto-whitelist-clients=20"
...

Кроме всего прочего, Postgrey может формировать статистику с помощью утилиты командной строки postgreyreport.
Пример использования (можно задействовать в Cron и отсылку на email):
# cat /var/log/mail.log | postgreyreport --nosingle_line --check_sender=mx,a --show_tries --separate_by_subnet=":-----------------------\n"

Очевидно, на корректность отчетов может повлиять ротация логов.

Рестарт Postgrey:
# service postgrey restart .

Интересно также, что Postgrey добавляет в письма свой заголовок: X-Greylist: delayed 435 seconds by postgrey ... .

И первоначальный отказ "новичкам" также содержит упоминание о нем: Recipient address rejected: Greylisted, see ... .

Postscreen

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

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

При этом Postscreen поддерживает временный белый список для клиентов, к которым эти тесты не применяются.

Работе Postscreen посвящена отдельная заметка: Postfix - Postscreen, первый уровень обороны.

Кроме того, см. подробности настройки в заметке Полный пример установки всех пакетов и настройки конфигурационных файлов.

ClamAV

ВАЖНО! Вся информация ниже в этом разделе содержит повышенный процент отсебятины, и требует перепроверки.

Антивирус ClamAV может быть подключен к Postfix разными способами. У системы, которая хорошо защищена и не слишком нагружена (имеет достаточный резерв ресурсов), ClamAV может быть подключен до очереди, и успевать проверять письма до завершения SMTP-сессии. Это позволит давать немедленный отказ клиентам, даже не принимая сообщение в очередь.

Если до антивируса будет доходить только те письма, которые уже прошли Postscreen и Postgrey, то можно рассчитывать на резерв ресурсов, достаточный для того, чтобы ClamAV успевал отработать.

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

В репозитариях Debian присутствует адаптер для ClamAV, написанный на Python. Кроме того ClamAV поддерживает интерфейс командной строки.

Установка ClamAV как Milter-приложения

Установим ClamAV и настроим его подключение через Milter-протокол:
# apt-get install clamav-milter .
Oстальное подтянется по зависимостям, включая clamav, clamav-base, clamav-daemon, Sendmail milter plugin, и clamav-freshclam - инструмент обновления баз.

Документация и примеры должны быть здесь:
/usr/share/doc/clamav/
/usr/share/doc/clamav-base/
/usr/share/doc/clamav-daemon/
/usr/share/doc/clamav-freshclam/
/usr/share/doc/clamav-milter/

Первоначальная простая установка может быть осуществлена например так:
# dpkg-reconfigure clamav-milter .

Ответить на вопросы можно, например так:

1. Handle the configuration file automaticaly? - Yes
2. User tu run clamav-milter as: - clamav
3. Groups for clamav-milter (space-separated): - (пустая строка)
4. Communications interface with Sendmail - inet:10026@127.0.0.1
5. Group owner of clamav-milter local (UNIX) socket: - clamav
6. Creation mode for clamav-milter local (UNIX) socket: - 600
7. Remove stale socket after unclean shutdown - Yes
8. Wait timeout for data coming from clamd - 120
9. Should clamav-milter stay in foreground (not forking)? - No
10. Chroot to directory - (пустая строка)
11. Pid file - (не меняем) /var/run/clamav/clamav-milter.pid
12. Temporary directory path - (пустая строка). При отсутствии значения, используется $TEMPDIR или $TEMP
13. Clamav socket to connect to for scanning: - unix:/var/run/clamav/clamd.ctl
14. Host excludes for scanning: - (пустая строка). Если оставить пустым, то вся без исключения почта будет сканироваться.
15. Mail address whitelist: - (пустая строка)
16. Action to perform on infected messages: - (что делать если найдено зараженное письмо) - Reject (550)
17. Action to perform on error conditions: - (если ошибка: таймаут, ошибка сканера, нарушение структуры данных и т.п.) - Reject
18. Specific rejection reason for infected messages: - (сообщение для ответа на зараженное письмо) - Virus detected: "%v".
19. Add headers to processed messages? - Add
20. Log-file for clamav-milter: - /var/log/clamav/clamav-milter.log
21. Disable log file locking? - Yes
22. Maximum size of the log file (MB) - 10
23. Log time with each message? - Yes
24. Use system logger? - No
25. Type of the syslog messages - LOG_LOCAL6
26. Enable verbose logging? - (подробное логгирование) - No
27. Information to log on infected messages - Full
28. Information to log if no threat is found - Off
29. Size limit for scanned messages (MB) - 25

В "Add headers to processed messages? - Add", указанный ответ "Add" - позволяет не искажать DKIM.

Это всего лишь один из вариантов ответов на вопросы, - после такой настройки будет использоваться хост 127.0.0.1 и порт 10026. Если бы вместо inet:10026@127.0.0.1 использовался UNIX-сокет, то по-видимому пришлось бы указать еще следующее

/etc/default/clamav-milter

...
SOCKET_RWGROUP=postfix
...

Последний штрих. Нужно проверить чтобы строки в следующих двух файлах конфигурации указывали на один файл

/etc/clamav/clamav-milter.conf

...
ClamdSocket unix:/var/run/clamav/clamd.ctl
...

/etc/clamav/clamd.conf

...
LocalSocket /var/run/clamav/clamd.ctl
...

По-видимому имеет смысл внести кое-какие изменения в настройки по умолчанию, созданные после установки в других файлах конфигурации.
LogFileMaxSize 10M - Максимальный размер лога обновления баз 10 MB, т.к. "0" после установки - это без ограничения.
Checks 4 - количество проверок обновлений базы, в день. Слишком часто наверное - бессмысленно.

/etc/clamav/freshclam.conf :

...
LogFileMaxSize 10M
Checks 4
...

По аналогичным причинам изменим размер максимального лога для clamd

/etc/clamav/clamd.conf :

...
LogFileMaxSize 10M
...

Подключение clamav-milter в Postfix

/etc/postfix/main.cf :

Перезагрузка

# /etc/init.d/clamav-milter restart
или так:
# service clamav-milter restart

Кроме того нужно перечитать конфиги Postfix
# service postfix reload

Проверка работы

# sockstat -l :

...
clamav   clamav-milter    ...     tcp4   127.0.0.1:10026     *:*      LISTEN
...

Кроме того, нужно проверить логи здесь: /var/log/clamav/ .

• clamav-milter.log - не должен содержать ошибок конфигурации и предупреждений. В нем будет также записываться подробная информация о письмах, в которых обнаружены вирусы
• clamav.log - логиирует рестарты и обновление баз (одной строкой), и содержит краткую информацию об обнаруженных вирусах
• freshclam.log - подробно логгируется обновление баз

Здесь должны быть свежие антивирусные базы: /var/lib/clamav/ .

Проверка в письмах

В чистых письмах должны появиться примерно такие заголовки:

X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter ... at ...

ВАЖНО! Не должны быть нарушены "DKIM - pass" и "SPF - pass".

Для того чтобы проверить свой антивирус, можно послать себе письмо, которое будет распознано как зараженное. Для это существует т.н. "тестовый вирус" EICAR-Test-File. Нужно вставить эту выделенную жирным часть текста в поисковик :) и найти тестовую строку на одном из сайтов (например в Википедии). После чего скопировать прямо в содержание письма, указанную там тестовую строку, и послать себе из внешнего почтовика (можно из GMail). Через непродолжительное время (скорее всего несколько секунд) должно вернуться сообщение о том, что письмо не доставлено. В нем должно присутствовать указанное чуть выше в настройках сообщение (Virus detected: "%v". ) и код ответа (550).

Вообще, с помощью теста EICAR-Test-File удобно налаживать работу антивирусной системы.

Подробности также см. в заметке Полный пример установки всех пакетов и настройки конфигурационных файлов.

Amavis/Amavis-new

Интерфейс-посредник между Postfix и антивирусами, фильтрами, Spamassassin и пр. Кроме того может осуществлять диспетчерские функции: накладывать и проверять подписи (DKIM), осуществлять проверку письма со множеством получателей один раз, перенаправлять почту в зависимости от содержания, получателей или даже размера. Архивировать почту в файлы, использовать SQL и пр.

Spamassassin

Spamassassin - мощная система оценки почты на предмет вероятности того, что она может быть спамом. Использует систему баллов (очков), анализируя ряд параметров. Подключать Spamassassin можно даже на этапе обработки Milter-приложений, а окончательно решение о судьбе письма, по результатам оценки, может принимать например Dovecot, с использованием "Sieve".

Spamassassin использует множество компонентов и методов, включая самообучение и внешние сервисы. Может быть настроен как отдельное приложение, как часть Postfix или другой программы, связанной с Postfix (например Amavis), либо как клиент "spamc" (их может быть несколько), взаимодействующий с демоном "spamd".

Список специальных переменных для SQL-запросов

Для параметра query:

%% - Заменяется на "%"

%s - исходный ключ, передаваемый в запрос

%u - если исходный ключ - адрес, то это левая часть адреса (пользователь)

%d - если исходный ключ - адрес, то это правая часть адреса (домен)

%[S/U/D] - Прописные эквиваленты вышеупомянутых расширений ведут себя в параметре запроса тождественно их строчным дубликатам. С параметром result_format, они разворачивают исходный ключ, а не значение результата.

%[1-9] - Паттерны %1, %2... %9 заменяются соответствующим старшим значащим компонентом домена исходного ключа. Например, если исходный ключ user@mail.example.tld, то %1 = tld, %2 = example, и %3 = mail. Если исходный ключ неполон или не имеет достаточного количества доменных компонентов, чтобы удовлетворить все указанные паттерны, то запрос будет подавлен и не вернет результатов.

Список инструментов командной строки

• postfix - управляет работой почтовой системы. Интерфейс для запуска, остановки и перезапуска почтовой системы, а также для некоторых других административных операций. Запускается с правами root.
• postalias - поддержка баз алиасов. Выполняет работу для команды newaliases
• postcat - просмотрщик содержимого файлов очереди. Будет заменена на полноценный редактор.
• postconf - показывает и обновляет список параметров "main.cf". Поведение зависит от ОС
• postdrop - утилита, запускаемая для Postfix-sendmail, при обработке почты для maildrop
• postkick - делает доступным внутренние каналы Postfix для скриптов.
• postlock - предоставляет Postfix-совместимую блокировку ящиков - для скриптов.
• postlog - предоставляет Postfix-совместимое логгирование - для скриптов.
• postmap - поддержка таблиц (списков) поиска: канонических, виртуальных и пр. Родственник UNIX-программы makemap.
• postmulti - дублирует "postfix start" и т.п. команды для разных экземпляров Postfix, а также поддерживает создание, удаление и т.п. экземпляров Postfix.
• postqueue - команда привилегированного запуска "Postfix sendmail" и "mailq" при операциях с очередью.
• postsuper - поддерживает очереди во время перезапуска Postfix

Источники

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