Postfix

Введение

Postfix реализует поддержку протокола Sendmail 8 Milter, и позволяет проверять SMTP-события (CONNECT, DISCONNECT), SMTP-команды (HELO, MAIL FROM, и т.д.), а также почтовый контент (headers, body), — до попадания письма в очередь. Присутствует в двух ипостасях — для smtpd и для не smtp почты.

Причина добавления поддержки Milter в том, что существует большое количество приложений, реализующих не только блокирование нежелательной почты, но и проверку подлинности («OpenDKIM», «DomainKeys Identified Mail (DKIM)», «SenderID+SPF» и «DomainKeys») или проверку цифровой подписи («OpenDKIM», «DomainKeys Identified Mail (DKIM)», «DomainKeys»). Создавать еще одно Postfix-приложение — было бы неэффективно.

Протокол Milter развивается с течением времени, и различные версии Postfix реализуют различные наборы функций. См. и в конце этого документа, чтобы увидеть различия между Postfix и Sendmail реализациями.

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

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

Это средство заменяет действия SMTP сервера
REJECT на DEFER (попытаться позже). Это позволяет оставлять сообщения в очереди, которые
в противном случае были бы возвращены отправителю.
Укажите » = yes» в файле main.cf, чтобы предотвратить
постоянное отклонение почты SMTP сервером Postfix. С этой целью Postfix заменит
все коды ответов 5xx на 4xx.; Эта возможность
позволяет заменить действия SMTP сервира REJRCT на замечания (warnings). Вместо отклонения
команды клиента Postfix регистрирует, что он собирался отвергнуть. Укажите
«» в списке ограничений доступа к SMTP
перед тем ограничением, которое вы хотите протестировать без реального отклонения почты.
XCLIENT: Благодаря этой возможности (Postfix 2.1 и последующие версии) авторизованные
SMTP клиенты могут имитировать другие системы, таким образом вы можете проводить ралистичные
тесты правил доступа к SMTP серверу Postfix. Примеры использования XCLIENT для тестирования правил
доступа содержатся в документе
XCLIENT_README .

Используем Relayhost

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

Файл изменяется так, чтобы он указывал relayhost:

# vim /etc/postfix/main.cf 
relayhost = mail.providermx.com

## in case of IP address ##
##  disables DNS lookups ##
relayhost = 
# service postfix restart

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

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

— Постоянные черные/белые списки
— Временный белый список
— MX-политика для тестов

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

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

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

Пример

postscreen_access_list = permit_mynetworks,
    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», произойдет логгирование адреса клиента и порта: .

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

После того, как адрес SMTP-клиента совпадет со строкой для которой указано значение «reject», произойдет логгирование адреса клиента и порта: .

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

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

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

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

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

, отключив очистку кэша (), во всех Postscreen экземплярах, за исключением одного, ответственного за эту очистку.

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

Когда адрес SMTP-клиента появляется во временном белом списке, происходит логгирование адреса клиента и порта: . Это событие не контролируется в настройках, — происходит немедленная передача клиентского соединения процессу 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, например так:

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

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

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

CONNECT from :port to :25

WHITELIST VETO :port

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

Выбор сервера отправки в зависимости от адреса получателя

Итак, в sender_bcc_map всю локальную почту я оставляю локально, просто указывая адрес отправителя (каждый сайт шлет почту от своего ящика) и локального пользователя, к которому она будет складываться. Если у вас много сайтов, то для каждого сайта будет свой локальный пользователь. Чаще всего это так, потому что разные сайты лучше всего запускать под разными пользователями, от которых работает веб сервер. Файл с записями для sender_bcc_map выглядит так:

[email protected] user1
[email protected] user2

Если у вас использует разные ящики для отправки, то можете настроить правило для всего домена сразу:

*@site1.ru user1
*@site2.ru user2

Дальше вам нужно выяснить, как выглядит полностью адрес домена для локальной доставки почты. Это имя задается в параметре mydomain в конфиге postfix main.cf. Допустим, там указано имя сервера — websrv.site.ru. Это не принципиально, в нашем случае там можно написать все, что угодно, но лучше использовать полное доменное имя (fqdn) самого веб сервера, которое указано в DNS записи типа А.

Теперь создаем файл transport_map, в котором пишем следующее:

websrv.site.ru local

Мы явно указываем, что всю почту для домена websrv.site.ru отправлять локально. Не забываем построить индексированный файл:

# postmap /etc/postfix/transport_map

Отправляемся в конфиг main.cf и добавляем туда параметр:

transport_maps = hash:/etc/postfix/transport_map

Перезапускаем postfix и проверяем работу. При отправке почтового сообщения от имени пользователя [email protected] там должно быть примерно следующее:

websrv postfix/smtpd: CC8F0602E205: client=localhost
websrv postfix/cleanup: CC8F0602E205: message-id=<[email protected]>
websrv postfix/qmgr: CC8F0602E205: from=<[email protected]>, size=874, nrcpt=2 (queue active)
websrv postfix/smtpd: disconnect from localhost ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
websrv postfix/local: CC8F0602E205: to=<[email protected]>, relay=local, delay=0.07, delays=0.06/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to mailbox)
websrv postfix/smtp: CC8F0602E205: to=<[email protected]>, relay=smtp.yandex.ru:465, delay=0.93, delays=0.06/0.01/0.23/0.63, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on myt6-9bdf92ffd111.qloud-c.yandex.net as 1608951012-xOUj8gBhbE-oCJSqvIX)
websrv postfix/qmgr: CC8F0602E205: removed

[email protected]	адрес, с которого сайт ведет отправку почты
[email protected]	итоговый локальный адрес, куда идет пересылка почты
[email protected]	внешний почтовый адрес, куда идет отправление через внешний smtp
smtp.yandex.ru	адрес внешнего smtp сервера

Получили в итоге то, что хотели. Внешняя почта отправляется через внешний smtp адрес, указанный в relayhost, а копии сообщений падают в локальный ящик, который находится в файле /var/mail/user1. Конкретно мне это нужно было для отладки, чтобы понять, что именно отправляет сайт.

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

sender_bcc_maps:

*@site1.ru [email protected] 
*@site2.ru [email protected]

transport_map:

backupmail.ru relay::25

В данном случае backupmail.ru это отдельный почтовый домен и почтовый сервер для него для сбора всей вашей почты. Это не обязательно может быть собственноручно настроенный почтовый сервер. Можете использовать ящик в какой-то готовой службе почты. Но имейте ввиду, если это будет какой-то бесплатный сервис, то он вас быстро заблокирует, если будете слать слишком много почты на этот ящик.

Полезные команды Postfix

До того, как мы начнём, давайте взглянем на некоторые команды, связанные с Postfix.

1. postfix reload или service postfix restart?

Для перезагрузки Postfix с обновлёнными конфигурационными файлами могут быть использованы две команды.

postfix reload: Эта команда проверит конфигурационные файлы и, соответственно, обновит Postfix. Поскольку данная команда не приводит к отключению Postfix, она крайне рекомендована в условиях реальной работы.
service postfix restart: Эта команда, для начала, остановит Postfix, а затем запустит его снова. Эта команда запустит свежий экземпляр Postfix.

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

2. postconf

postconf — это очень полезная команда Postfix. Далее несколько примеров использования postconf.

Для показа значений всех параметров Postfix:

# postconf

Чтобы увидеть значения специфичных параметров, можно использовать grep для фильтра вывода:

# postconf | grep myorigin
append_at_myorigin = yes
myorigin = example.tst

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

# postconf -e 'myorigin = example.tst'

Обратите внимание, что любые параметры Postfix, изменённые командой postconf, сохраняться до перезагрузки. То же самое может быть достигнуто модификацией конфигурационного файла /etc/postfix/main.cf.

Блокирование конкретных адресов или доменов

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

# vim /etc/postfix/access 
[email protected]   550             address blocked
wxyz.com        550             domain blocked
# postmap access 
# vim /etc/postfix/main.cf 
smtpd_recipient_restrictions = hash:/etc/postfix/access, permit_mynetworks, permit_sasl_authenticated,reject_unauth_destination
# service postfix restart

Примечание: можно использовать один и тот же файл для блокирования отправителя и получателя, вместо того, чтобы использовать отдельные файлы (описан выше) и . Лично я предпочитаю иметь отдельно два файла для того, чтобы было удобно выполнять поиск и устранять проблемы.

Создание Milter приложений

Milter-приложения могут быть написаны на «C», «Java» и «Perl», но в этом документе рассматривается применение только «C». Для них нужен будет объект библиотеки, которая реализует «Sendmail 8 Milter» протокол. Postfix в настоящее время не обеспечивает такую библиотеку, но ее имеет Sendmail.

Первый вариант заключается в использовании предварительно скомпилированной библиотеки. Некоторые системы устанавливают Sendmail libmilter по умолчанию. В других системах, libmilter устанавливается в составе отдельного пакета (например «sendmaul-devel»).

$ gzcat opendkim-x.y.z.tar.gz | tar xf -
$ cd opendkim-x.y.z
$ ./configure ...options...
$ make

$ make install
$ gzcat dkim-milter-x.y.z.tar.gz | tar xf -
$ cd dkim-milter-x.y.z
$ make

Опции при сборке libmilter из исходников Sendmail:

$ gzcat sendmail-x.y.z.tar.gz | tar xf -
$ cd sendmail-x.y.z/libmilter
$ make

После сборки, следуйте установочным инструкциям для исходников Milter-приложения в настройке местоположения подключаемых файлов libmilter и объектов библиотеки. Обычно конфигурация настраивается в файле или симулируется:

APPENDDEF(`confINCDIRS', `-I/some/where/sendmail-x.y.z/include')
APPENDDEF(`confLIBDIRS', `-L/some/where/sendmail-x.y.z/obj.systemtype/libmilter')

После чего соберите Milter-приложение.

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

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

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

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

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

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

Можно просмотреть информацию об IP в кэше btree . Здесь открывается широкий простор для исследований и творческих поисков.

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

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

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

Найти в логе строки с IP прошедшими все тесты

Найти в логе строки с IP прошедшими все тесты и подключавшимися после этого еще

Установка на Ubuntu 14.04

1. Для установки программы Fail2ban выполните следующие команды:

sudo apt-get update 
sudo apt-get install fail2ban

2. Для того, чтобы установленное программное обеспечение работало должным образом, вам необходимо внести поправки в конфигурационный файл. По умолчанию таковым является /etc/fail2ban/jail.conf.

Однако разработчики крайне не рекомендуют редактировать его напрямую, чтобы избежать осложнений при работе с сервером. Поэтому создайте локальную копию данного файла командой:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Далее вам нужно будет выполнять редактирование только /etc/fail2ban/jail.local. Он будет подключен системой автоматически и имеет высший приоритет при исполнении.

3. Откройте файл jail.local для редактирования одной из команд: Если вам удобнее работать с редактором nano:

sudo nano /etc/fail2ban/jail.local

Если для вас предпочтительнее редактор vi:

sudo vi /etc/fail2ban/jail.local

Обратите внимание на секцию . Она содержит в себе основные правила, заданные по умолчанию для Fail2ban

Она содержит в себе основные правила, заданные по умолчанию для Fail2ban.

ignoreip — значения этого параметра говорят о том, какие IP-адреса блокироваться не будут вовсе. Если вы хотите, чтобы Fail2ban игнорировал при проверке несколько IP-адресов, их необходимо указать в значении ignoreip через пробел.

bantime — данный параметр означает время в секундах, в течение которого подозрительный IP будет заблокирован. Изначально его значение составляет 10 минут.

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

maxretry — допустимое число неуспешных попыток получения доступа к серверу. При превышении указанного значения IP попадает в бан.

Ниже будут представлены другие секции, при помощи которых можно настроить защиту различных сервисов, установленных на ваш виртуальный сервер, например, ssh, ftp и прочих. Подробная процедура их настройки будет рассмотрена в конце данной статьи в разделе «Настройка Fail2ban».

4. После редактирования jail.local обязательно сделайте перезапуск Fail2ban командами

sudo service fail2ban restart
tail /var/log/fail2ban.log

Настройка Postfix

Открываем конфигурационный файл Postfix:

vi /etc/postfix/main.cf

Правим строку или добавляем ее:

header_checks = regexp:/etc/postfix/header_checks

Открываем файл header_checks:

vi /etc/postfix/header_checks

Добавляем:

/^X-Spam-Status:.*FILTER_CONTROL.*/ BCC [email protected]

* в данном примере мы ищем вхождения метки FILTER_CONTROL в заголовках письма, и если она есть, отправляем копию письма на адрес [email protected].

Для работы действия BCC в header_checks, необходим Postfix версии 3 и выше. Проверить версию установленного MTA можно командой postconf -d | grep mail_version.

Проверяем настройку header_checks:

postmap -q «X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,FILTER_CONTROL» regexp:/etc/postfix/header_checks

Мы должны увидеть:

BCC [email protected]

Перезапускаем postfix:

systemctl restart postfix

Для проверки отправляем письмо с содержанием ключевой фразы — мы должны получить копию письма на другой ящик.

Фильтрация писем на основе темы письма

Рассмотрим более сложный вариант предыдущего скрипта. Там мы фильтровали письма на основе содержимого служебных заголовков. Но если мы захотим отфильтровать почту по теме письма, то сходу у нас ничего не получится. С темой письма возникают сложности из-за того, что она закодирована в base64, если в ней используются русский язык. Вот простой пример. У нас есть письмо с темой «Как дела?». Используем base64 декодер и смотрим, как будет выглядеть тема сообщения в исходнике письма.

Как дела? - 0JrQsNC6INC00LXQu9CwPw==

А вот, что вы увидите в заголовке письма со всеми служебными добавлениями:

Subject: =?UTF-8?B?0JrQsNC6INC00LXQu9CwPw==?=

Вам нужно будет отбросить сначала кодировку =?UTF-8?, потом не знаю, что означающие символы B?, затем в конце еще вот это ?=. Так вы получаете искомую фразу. Теперь представьте, что кто-то ответит на это письмо. Тема сообщения станет Re: Как дела?. В base64 эта фраза будет выглядеть совершенно по-иному:

Re: Как дела? UmU6INCa0LDQuiDQtNC10LvQsD8=

И вот как в реальном заголовке:

Subject: =?UTF-8?B?UmU6INCa0LDQuiDQtNC10LvQsD8=?=

Сложность добавляет еще то, что разные почтовые клиенты используют разную кодировку в теме письма. Мне встречались как UTF-8, так и WIN-1251. То есть для того, чтобы нормально раскодировать и читать тему сообщения, вам нужно сделать обработку на декодирование, на отбрасывание служебных символов. Еще в процессе тестирования я заметил, что если вы используете не весь текст темы, а только ее часть, то закодированная строка поиска может немного не совпадать с той, что будет в теме письма. Изменения могут возникнуть из-за заглавных/строчных букв, пробелов, запятых и т.д. В общем, я не осилил эту тему, так как надо очень плотно погрузиться в предмет и написать много различных проверок и условий. У меня просто не хватило терпения все сделать красиво, чтобы скрипт работал надежно.

Поступил я в итоге по-другому, более просто и топорно, зато надежно. Допустим, вам нужно, чтобы какая-то переписка не хранилась на сервере дольше определенного времени. Это может быть конфиденциальная информация. Например, вы сканируете документы с отправкой на почту и вам нужно, чтобы сканы там не хранились бесконечно долго. Настраиваете на МФУ шаблон темы сообщения, добавляя в начало такую строку — !del. Затем переводите его в base64, добавляя еще фразы с Re: и Fwd: на случай, если эти письма могут куда-то пересылаться или писаться ответы. Конечно, сканеру вряд ли кто-то будет отвечать, но, возможно, для вашей темы сообщения это будет актуально.

!del	IWRlbA==
Re: !del	UmU6ICFkZWw=
Fwd: !del	RndkOiAhZGVs

Дальше берете скрипт из предыдущего примера и меняете там строку поиска на новую:

grep -E -R -l -I "Subject:.*IWRlb.*|Subject:.*RndkOiAhZGVs.*|Subject:.*UmU6ICFkZWw.*" "$a" >> $copydir/$box/copy-$data_full.txt

Эта строка найдет во всех письмах, сформированных в список предыдущей командой, темы сообщения !del, Re: !del, Fwd: !del и скопирует пути и имена файлов в список. Потом вы можете на свое усмотрение работать с этим списком.

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

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

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

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

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

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

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

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

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

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

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

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

Еще несколько примеров работы с почтовой базой

Этот пример будет актуален, если вы используете почтовые ящики, куда копируется абсолютно вся переписка вашего сервера. Допустим, у вас есть ящик [email protected], куда сохраняется вся уходящая корреспонденция. Если на сервере идет активная переписка, то писем в ящике будет много и искать с помощью какого-то imap клиента будет неудобно, так как он может либо тормозить на большом списке писем, либо вообще отваливаться по таймауту и поиск или сортировка будут невозможны с его помощью. Тогда на помощь придут простые скрипты в консоли сервера. Найдем в этом ящике все письма, отправленные в период между первым и седьмым сентября 2017 года и скопируем их в отдельный ящик.

find /data/mail/virtual/[email protected]/Maildir/*/ -newerBt '2017-09-01 00:00' -and -not -newerBt '2017-09-07 00:00' -and -type f | cpio -pdmv /data/mail/virtual/[email protected]/Maildir/new

По сути тут просто использовались ключи к команде find. У нее их так много, что я для всех прикладных задач всегда храню готовые конструкции, чтобы заново не вспоминать все ключи и возможности.

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

# du --max-depth=1 | sort -n -r

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

# du -h --max-depth=1

Еще удобнее отправить сразу вывод в текстовый файл с датой в имени файла, чтобы потом было удобно сравнить с тем, что получилось после чистки почтовой базы.

# du -h --max-depth=1 >> "dirsize_`date +"%Y-%m-%d_%H:%M"`.txt"

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

Временные решения

# =============================================================
# service type  private unpriv  chroot  wakeup  maxproc command
#               (yes)   (yes)   (yes)   (never) (100)
# =============================================================
scan      unix  -       -       n       -       10      smtp
	-o smtp_send_xforward_command=yes
	-o disable_mime_output_conversion=yes
	-o smtp_generic_maps=

Некоторые Milter-приложения используют макрос «{if_addr}» для распознания почты как локальной. Этот макрос отсутствует в Postfix. В качестве временного решения стоит использовать вместо него макрос «{client_addr}».
Некоторые Milter-приложения пишут в лог нечто вроде:

sid-filter: WARNING: sendmail symbol ‘i’ not available

А затем могут вставлять в сообщение неприятный заголовок с параметром «unknown-msgid», наподобие следующего:

X-SenderID: Sendmail Sender-ID Filter vx.y.z host.example.com <unknown-msgid>

Проблема в том, что Milter-приложения ожидают здесь присутствия идентификатора (ID) очереди до того как MTA примет команду «MAIL FROM» (sender). Postfix же выбирает этот идентификатор, используемый как имя файла очереди, уже после того как он получит первую правильную команду «RCPT TO» (recipient).

Если у вас возникли проблемы с появлением такого неприятного заголовка, проверьте — не исправлено ли это в последней версии Milter-приложения. Например, в текущих версиях «DKIM-фильтр» и «DK-фильтр» уже присутствует код, который просматривает ID очереди Postfix на более позднем этапе протокола, а SID-фильтр c версии 1.0.0, не включает больше идентификатор очереди в заголовок сообщения.

Чтобы исправить неприятность с заголовком сообщения, Вам необходимо добавить код, который выбирает ID очереди в некоторый более поздний момент времени. В приведенном ниже примере, выборка добавляется после конца сообщения (end-of-message).

Найдите исходный файл фильтра (обычно его имя «xxx-filter»/»xxx-filter.c» или подобное).
Найдите функцию mlfi_eom() и добавьте под строками в верхней части, код выделенный жирным:

dfc = cc->cctx_msg;
assert(dfc != NULL);

/* Determine the job ID for logging. */
if (dfc->mctx_jobid == 0 || strcmp(dfc->mctx_jobid, JOBIDUNKNOWN) == 0) {
        char *jobid = smfi_getsymval(ctx, "i");
        if (jobid != 0)
                dfc->mctx_jobid = jobid;
}

ВАЖНО!:

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

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

Когда новый SMTP-клиент успешно проходит все тесты (т.е. он не внесен в какой-либо белый список), Postscreen логгирует это так: , где :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 компенсирует последствия такого неудобного поведения длительным сроком допуска для клиентов прошедших глубокое тестирование. Это регулируется параметром (по умолчанию — 7 дней){информация требует проверки и уточнения}.