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

Введение

Данная статья будет написана по мотивам другого материала — отправка почты через консоль с авторизацией. В целом, там представлено законченное решение, но в некоторых случаях требуется дополнительная настройка.

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

Замена адреса отправителя может быть полезна в разных ситуациях. Я ее буду использовать конкретно для решения проблемы с отправкой писем через почтовые сервера Яндекса. Для успешной отправки письма, Яндекс требует, чтобы адрес отправителя в письме совпадал с адресом для авторизации на сервере. Если это не будет сделано, то вы получите ошибку во время отправки — Sender address rejected: not owned by auth user.

Происходит это потому, что отправка системных сообщений идет от локального пользователя root. Имя отправителя в письме будет примерно такое — [email protected]. В данном случае prox-centos7.loc это локальное имя сервера. Я его заменю на учетную запись яндекса.

Настройка аутентификации на Postfix

Аутентификация на postfix будет выполняться методом dovecot. Для этого устанавливаем его. Заодно, устанавливаем и postfix (на случай, если его нет еще в системе). В зависимости от используемой операционной системы используем разные команды.

а) если используем Ubuntu / Debian:

apt-get update

apt-get install postfix dovecot-imapd dovecot-pop3d

б) если используем CentOS / Red Hat:

yum install postfix dovecot

После установки пакетов, разрешаем автозапуск dovecot и postfix:

systemctl enable postfix dovecot

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

vi /etc/postfix/main.cf

Добавляем строки (или меняем значения):

smtpd_sasl_type = dovecot
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_relay_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_unauth_destination

* где:

smtpd_sasl_type — тип плагина, который используется для SASL-аутентификации. Командой postconf -a мы можем получить список механизмов аутентификации, которые поддерживаются почтовой системой.
smtpd_sasl_auth_enable — разрешает или запрещает аутентификацию по механизму SASL.
smtpd_sasl_path — путь до файла для обмена аутентификационной информацией. Используется для взаимодействия нескольких систем — в нашем примере Postfix + Dovecot.
smtpd_relay_restrictions — правила разрешения и запрета использования MTA при пересылке. В нашем случае:
- permit_mynetworks — разрешить отправку с компьютеров, чьи IP-адреса соответствуют настройке mynetworks.
- permit_sasl_authenticated — разрешить отправку писем тем, кто прошел авторизацию.
- reject_unauth_destination — запретить всем, кто не прошел проверку подлинности.

Проверяем корректность настройки:

postconf > /dev/null

Если команда не вернула ошибок, перезапускаем Postfix:

systemctl restart postfix

Переходим к настройке dovecot — открываем файл:

vi /etc/dovecot/conf.d/10-master.conf

… и приводим опцию service auth к следующему виду:

service auth {
…
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
…
}

* если соответствующей секции unix_listener нет, то ее нужно создать

Обратите внимание, что для обмена аутентификационными данными мы применяем файл /var/spool/postfix/private/auth, который в конфигурационном файле postfix был указан, как private/auth

Отключаем требование ssl для аутентификации (на текущем этапе нам это не нужно):

vi /etc/dovecot/conf.d/10-ssl.conf

Проверяем, чтобы значение ssl не было required:

ssl = yes

* нас устроит оба варианта — yes или no.

Настройки аутентификации приводим к следующему виду:

vi /etc/dovecot/conf.d/10-auth.conf

auth_mechanisms = plain login

* данные механизмы позволяют передачу данных в открытом виде.

В этом же файле проверяем, что снят комментарий со следующей строки:

!include auth-system.conf.ext

Проверяем корректность настройки dovecot:

doveconf > /dev/null

Если команда ничего не вернула, перезапускаем сервис:

systemctl restart dovecot

В качестве логина и пароля можно использовать любую системную учетную запись. Создадим ее для теста:

useradd smtptest

passwd smtptest

Мы настроили простую аутентификацию на сервере SMTP. Для проверки можно воспользоваться любым почтовым клиентом. Пример настройки thunderbird:

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

Мы завершили настройку аутнтификации на postfix при отправке письма. Добавим проверку данных через LDAP.

Отправка не отфильтрованной почты в расширенном фильтре

В этом примере scan является экземпляром клиента Postfix с несколько другими параметрами конфигурации. Можно создать сервис в Postfix настроив его в файле :

# =============================================================
# 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=

* Пробелы перед строками с опциями — обязательны.

В этом примере настроена возможность работы 10 контент-фильтров одновременно. Вместо ограничения в 10 процессов, используйте число, допустимое для Вашей машины. Программа может потреблять много системных ресурсов, поэтому указывайте разумную величину.
-o smtp_send_xforward_command=yes Попытка определить первоначальное имя клиента и IP-адрес, и сохранить его после фильтрации
-o disable_mime_output_conversion=yes Предотвращает нарушение цифровых подписей и ключей, которое может произойти потому, что некоторые фильтры контента не объявляют 8BITMIME-поддержку, даже если они могут обрабатывать 8-битные сообщения
-o smtp_generic_maps= Предотвращает перезапись локального адреса через generic. Такая перезапись должна произойти только, когда почта отправляется наружу.

Простое удаление старых писем из ящика

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

/usr/bin/find /data/mail/virtual/[email protected]/Maildir/*/ -type f -mtime +30 -exec rm {} \;

/usr/bin/find	Путь до утилиты find. Проверьте его актуальность в своем дистрибутиве.
/data/mail/virtual/[email protected]/Maildir/*/	Путь до конкретного ящика. Конструкция /*/ позволяет сразу проверить обе папки new и cur.
-type f	Говорим find, что ищем только файлы.
-mtime +30	Указываем срок более 30 дней с последнего изменения файла. То есть все файлы старше 30-ти дней.
-exec rm {} \;	Выполняем удаление.

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

/usr/bin/find /data/mail/virtual/[email protected]/Maildir/*/ -type f -mtime +30 >> /root/dellist.txt

После этого смотрите файл /root/dellist.txt и проверяйте, что собираетесь удалить. После того, как проверили, не обязательно заново выполнять поиск по базе и лишний раз нагружать диски. Можно удалить все указанные в dellist.txt письма следующим скриптом.

#!/bin/bash

cat /root/dellist.txt | while read i ; do 
rm -f "$i" 
done

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

Установка на 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 с помощью fail2ban

Изначально fail2ban идет с комплектом готовых настроек и фильтров для защиты большинства популярных сервисов. К ним относится и postfix. Но когда я посмотрел в готовый набор с regexp для postfix, я слегка растерялся Он просто огромен. И самое главное, что в таком виде он не заработал на моем лог файле.

Мне стало лень ковыряться в этих правилах. Для защиты postfix от перебора паролей почтовых ящиков, достаточно банить ip адреса из следующих строк лога.

Jun 17 03:14:07 mail postfix/smtpd: warning: unknown: SASL LOGIN authentication failed: UGFzc3dvcmQ6

Для этого достаточно относительно простого regexp.

^%(__prefix_line)swarning: +\: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: *={0,2})?\s*$

Его придумал не я. Честно подсмотрел на просторах интернета. Примеров масса и у нас, и в англоязычном гугле. Далее создаем конфигурационный файл с фильтром из этого regexp — /etc/fail2ban/filter.d/postfix-sasl.conf.

before = common.conf

_daemon = postfix/smtpd
failregex = ^%(__prefix_line)swarning: +\: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: *={0,2})?\s*$
ignoreregex =

Можно сразу же проверить работу этого фильтра с помощью fail2ban-regex. Эта утилита никого не банит, а просто выводит информацию о работе фильтра.

# fail2ban-regex /var/log/maillog /etc/fail2ban/filter.d/postfix-sasl.conf

Команда успешно отработала и вывела результат.

24327 раз данный фильтр распознал строки, попадающие под работу фильтра. Изначально я напрягся, когда прикинул, что именно такое количество ip адресов поедет в бан с помощью iptables. Это еще не критично большое количество, но все равно достаточно много. По одному добавлять такое количество адресов не стоит. Нужно использовать списки, например, .

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

enabled	= true
filter	= postfix-sasl
port	= smtp,465,submission,imap,imaps,pop3,pop3s
action	= iptables
logpath	= /var/log/maillog
bantime	= 60m
maxretry = 3
findtime = 60m

Пояснять тут особо нечего и так все понятно. Настройка блокировки будет проверять лог файл и записи в нем за последние 60 минут. Если будут 3 совпадения с regexp из фильтра postfix-sasl, ip адрес будет забанен на 60 минут. Таким образом, список забаненных ip адресов будет не очень большой, так как большая часть адресов будет повторяться.

Запускаем fail2ban и добавляем в автозагрузку.

# systemctl enable --now fail2ban

Проверяем лог файл /var/log/fail2ban.

Смотрим правила iptables.

# iptables -L -v -n

У вас должна появиться отдельная цепочка правил f2b-Postfix-sals с заблокированными ip адресами, которые добавил fail2ban. С защитой postfix с помощью fail2ban все. Переходим к Dovecot.

Присматриваемся к клиенту

Итак, SMTP сессия начинается с попытки подключения от клиента. Соответственно вы получаете его IP и можете сделать кое-какие выводы только на его основании. Например, вы можете включить проверку PTR записи для клиента, для это используйте опцию

reject_unknown_client_hostname

Она требует, чтобы IP, с которого совершается соединение, резолвился в имя через PTR, а это имя резолвилось в свою очередь обратно в искомый IP.

Есть и менее жёсткое ограничение, задаваемое опцией

reject_unknown_reverse_client_hostname

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

Есть ещё один трюк. Можно заставить свой сервер отвечать клиенту не сразу, а с небольшой задержкой. Это поможет отсечь много спама, поскольку спамерам ждать некогда. В то же время нормальный SMTP сервер никогда не порвёт соединение, не подождав хотя бы нескольких секунд. Ждать можно на любом этапе общения, но эффективней это делать сразу после получения запроса на соединение от клиента (то есть просто немного затянуть с ответом), поскольку когда вы уже начнёте общение, то задержки вряд ли заставят клиента отключиться.

Для включения таймаута служит опция

sleep seconds

Не указывайте время ожидания больше 25 секунд. По умолчанию тот же Postfix после 30-ой секунды ожидания считает, что сервер недоступен, так что разумным ограничением на используемое время задержки можно считать 20 секунд или около того.

Резюме

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

Вы должны сами решить, какие ограничения вы готовы поставить на свой сервер, а какие — нет. Многие скептически относятся ко многим представленным выше проверкам. Однако все они используются на реальных SMTP серверах в интернете, поэтому даже если вы включите вообще всё — вы будете далеко не одиноки. Поэтому если вы заметили сервер, который настроен неверно, не поленитесь отправить его администратору письмо на эту тему, возможно вы поможете ему избежать гнева со стороны пользователей, чья корреспонденция не дошла (если его уже не выгнали взашей с работы к моменту написания вами письма). И никогда не забывайте, что ломанные хосты можно добавить в вайтлист, дабы принимать от них почту без проверок.

С ног на голову, или посмотрим с другой стороны баррикад

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

Для администраторов почтовых серверов:

Всегда делайте MX записи ссылающимися на записи A.
Запись A для почтового сервера всегда должна иметь зеркальную PTR запись.
Хост из HELO заголовка должен иметь A или MX запись.
Всегда создавайте SPF записи (да-да, это-то как раз не обязательно, но просто правило хорошего тона).
Для всех писем, рассылаемых из обслуживаемого домена, ящик для обратного адреса должен существовать и принимать почту.

Для тех, кто рассылает почту (из программ, с сайтов и т.д.):

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

Никогда не посылайте почту с неподконтрольного вам домена, не проверив правила SPF для него

Например gmail.com в текущий момент позволяет посылать письма от его имени любому серверу, а вот yandex.ru и mail.ru сообщают через SPF о том, что посылка от их имени со сторонних серверов должна вызывать на себя пристальное внимание, что истолковывается умными спамфильтрами как увеличение уровня оценки спама для данного письма.

Никогда не посылайте почту через неправильно настроенные SMTP серверы. Проверить сервер на вшивость по списку выше — дело 5 минут, вам поможет утилита или .

Отправитель — а стоит ли ему доверять?

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

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

reject_non_fqdn_sender
reject_unknown_sender_domain

Первая — проверка адреса на написание, вторая — проверка существования домена.

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

Технически это реализуется очень просто: наш сервер открывает встречную SMTP сессию, пытаясь послать письмо по адресу отправителя. Если удаётся успешно пройти этап посылки RCPT TO с этим адресом, т.е. если принимающий сервер вдруг не заявляет, что указанного ящика на нём нет, то считается, что присланный нам обратный адрес существует. Данные (то есть письмо) при проверке естественно никакие не передаются, сессия прерывается после RCPT TO.

За такую проверку обратного адреса отвечает опция

reject_unverified_sender

Из сказанного выше следует, что для любого адреса, с которого вы рассылаете почту из своего домена, должен существовать ящик на вашем сервере. Иначе ваши письма не пройдут проверку обратного адреса на стороне получателя и соответственно не будут доставлены по назначению. Это актуально для всяких рассылок и прочей вроде как односторонней коммуникации, не требующей ответа. Всегда создавайте ящики для всех адресов, с которых вы рассылаете почту. Если вы не хотите получать ответы на какой-то адрес, то просто посылайте письма на него в /dev/null, но принимать эти письма вы обязаны.

Полезные команды 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.

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

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

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

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

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

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

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

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

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

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

Проверяем приветствие

Итак, кто-то захотел передать вашему серверу письмо. Передача начинается с приветствия — заголовка HELO. В HELO должно быть указано полное доменное имя (FQDN) отправителя, соответственно если это не так — можете смело сразу же отказывать в принятии. В Postfix для этого служат две опции:

reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname

Первая запрещает приём писем от хостов, передающих приветствие с некорректным синтаксисом, вторая — от хостов, передающих не FQDN в HELO запросе.

Однако не FQDN передают только самые глупые спамеры (и продукты MS, но им, как известно, законы не писаны), в конце концов представиться gmail.com не составляет труда. Поэтому надо ещё немного присмотреться к HELO. Для этого служат опция

reject_unknown_helo_hostname

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

Принцип работы

Контент-фильтр получает не отфильтрованную почту от Postfix, и может выполнить одно из следующих действий:

Вернуть почту Postfix, возможно, после изменения содержания и/или назначения
Отменить или поместить почту на карантин
Отсечь (reject) почту, путем отправки соответствующего кода состояния в Postfix. Postfix отправит почту обратно отправителю

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

Замена адреса отправителя в postfix

Начнем с подмены отправителя, чтобы можно было сразу тестировать отправку. Для этого добавляем в конфиг postfix /etc/postfix/main.cf следующий параметр.

Там же у меня есть такие параметры:

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

[email protected]	Локальный пользователь сервера.
[email protected]	Пользователь сервера yandex. В данном случае домен serveradmin.ru привязан к почте яндекса.

Перезапускаем postfix и проверяем отправку.

В логе отправитель локальный, но тем не менее, яндекс успешно отправил письмо, ошибки не было.

Ограничения для упрощенной фильтрации

Проблема контент-фильтров, таких как представленный ваше, в том, что они не являются достаточно надежными. Причина в том, что здесь не используется четко оговоренный протокол. Поэтому в случае прерывания скрипта из за каких-нибудь проблем с памятью, не будет произведен правильный выход, — такой как например описан в файле . Вместо того, чтобы попасть в отложенную очередь (deferred queue) почта будет контролироваться bounce. Такое же неустойчивое состояние может наступить, когда сам контент-фильтр столкнется с проблемами нехватки ресурсов.

Использование упрощенного контент-фильтра не подходит для случаев, когда задействованы паттерны фильтрации через header_checks или body_checks. Эти паттерны будут задействованы после окончания цикла фильтрации с помощью команд Posfix Sendmail… Метод расширенной фильтрации контента (см. ниже) позволяет отключить header_checks и body_checks.

Заключение

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

Если вас интересует настройка полноценного почтового сервера postfix, то у меня есть очень подробная статья на эту тему.

Буду рад полезным замечаниям и дополнениям. Ваши комментарии иногда делают меня умнее

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

Познакомитесь с Terraform.
Изучите систему управления конфигурацией Ansible.
Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .