Обновление списка актуальных CA сертификатов, для исправления ошибки в postfix, связанной с проверкой издателей сертификатов других почтовых серверов.
https://serveradmin.ru/oshibka-v-postfix-certificate-verification-failed/

#ошибка #postfix #mailserver

Мой вариант защиты от популярного последнее время спама, где в поле отправитель указан ваш почтовый ящик. Спамеры таким образом намекают на то, что они взломали ваш почтовый ящик и знают про вас все.
https://serveradmin.ru/zapret-pisem-s-poddelnyim-polem-from-ili-spam-ot-sebya-k-sebe-v-postfix/

#статья #postfix #mailserver

Давно не писал статей с прикладными задачами, все больше обзоры да руководства. Сегодня расскажу о том, как на практике перенести почтовый сервер postfix на другое железо или виртуальную машину. Поделюсь своим подходом к решению подобной задачи с минимальным простоем.
https://serveradmin.ru/perenos-pochtovogo-servera-postfix/

#статья #postfix #mailserver

Появилась необходимость настроить отправку почты с одного почтового сервера postfix через другой. Причем на сервере было несколько доменов, для каждого нужен был свой внешний почтовый сервер для пересылки почты. Настройка простая, пишу для справки. Нужно было для тестирования proxmox mail gateway.
https://serveradmin.ru/postfix-nastrojka-relayhost-otdelnyj-dlya-kazhdogo-domena/

#статья #postfix #mailserver

Хочу поделиться парочкой полезных советов по настройке почтового сервера. Я расскажу, как автоматически изменять тему всех отправляемых сообщений через postfix, а так же подменять адрес отправителя. На днях в комментариях к одной статье про отправку почты, читатель показал простое и интересное решение, которое я решил проверить, дополнить и оформить в виде отдельной статьи.
https://serveradmin.ru/kak-izmenit-temu-pisma-i-adres-otpravitelya-cherez-postfix/

#статья #postfix #mailserver

Решил в праздники, пока все отдыхают, перенести почтовый сервер с устаревшей системой, на свежую Centos 8. У меня есть на эту тему подробная и популярная статья - https://serveradmin.ru/nastroyka-postfix-dovecot-centos-7/

Настраивать на Centos 7, когда уже вышла 8-я версия, не хочется. К тому же почтовые сервера обычно настраиваются один раз и на много лет. Конкретно этот сервер отработал уже 10 лет. Удалось решить все вопросы и в целом подготовить перенос, кроме одного небольшого, но очень важного нюанса.

В Centos 8 не перенесли пакет dovecot-pigeonhole, который отвечает за managesieve - механизм создания правил сортировки писем. Он удобен и популярен, повсеместно используется. Без него неудобно, тем более, когда ты переносишь сервер, где он работал. У некоторых людей десятки правил сортировки.

По данному вопросу есть запросы к разработчикам:
https://bugzilla.redhat.com/show_bug.cgi?id=1766985
https://bugs.centos.org/view.php?id=16502

В первом запросе есть информация, что пакет появится в ближайшем обновлении: "pigeonhole is planned to be included in next RHEL8 update". По факту пока его нет. Будем ждать, перенос отложил. Если вы планируете установку или перенос почтового сервера, где используется sieve, использовать Centos 8 не получится.

В целом, получается типичная история с выходом нового релиза. Работать с ним трудно, так как то тут, то там натыкаешься на проблемы с изменившимися или отсутствующими пакетами. Например, из базового репозитория убрали пакет php-imap, который раньше там был. Получилось найти его в репозитории Remi. А вот dovecot-pigeonhole нет нигде. В итоге тратишь лишнее время на настройку.

Конечно, лучше подождать какое-то время, а пока использовать Centos 7, но лично мне хочется уже перейти на Centos 8, чтобы строить системы полностью на нем. Так удобнее в обслуживании. Плюс, не хочется поддерживать статьи с разными версиями системы. Это хлопотно. Лучше, когда все одной версии.

Хорошо, что у Centos не так часто выходят релизы, как в Debian или Ubuntu. За это больше его люблю. Меньше хлопот с новыми версиями, больше стабильности, меньше зоопарка.

#статья #postfix #mailserver #centos

Наконец-то написал и выверил большую статью про настройку почтового сервера на базе Centos 8 и postfix + dovecot. Прошлая версия для Centos 7 собрала рекордное количество комментариев - 500+. Тема актуальная и сложная. Хороших руководств почти нет. Надеюсь у меня получилось разложить все по полочкам и эта статья окажется такой же полезной.
https://serveradmin.ru/nastroyka-postfix-dovecot-centos-8/

#статья #centos #postfix #mailserver

Небольшая статья про настройку fail2ban для защиты классического почтового сервера на базе postfix и dovecot. Баню всех по ip, кто авторизуется с неверными учетными данными.
https://serveradmin.ru/fail2ban-postfix-dovecot/

#статья #mailserver #postfix

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

Но и его постигла современная зараза. Вот одно из нововведений:

Ведем журнал с уважением. Версия Postfix 3.6 объявляет deprecated терминологию, подразумевающую, что белое лучше черного. Вместо этого вводятся понятия allowlist и denylist и другие вариации этих слов. Эти изменения затрагивают документацию, настройки postscreen и логирование.

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

http://www.postfix.org/announcements/postfix-3.6.0.html

Осуждаем такие изменения?

#postfix #mailserver

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

#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала

Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow

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

Задача переноса Postfix очень простая и состоит из двух этапов:
1️⃣ Перенос mysql базы с ящиками и некоторыми настройками доменов и алиасов.
2️⃣ Перенос непосредственно почты, которая в формате хранения maildir представляет из себя обычные файлы. По отдельному файлу на каждое письмо. Копируется обычным rsync.

Важно, что вы можете спокойно перенести почтовый сервер очень старой версии на полностью новую систему и новую версию Postfix. Я вообще не помню, чтобы у Postfix менялся формат конфига или базы mysql. Можно поставить самую свежую версию Postfix и вручную перенести с любого старого Linux сервера. И каких-то особых сложностей не возникнет. Не надо ломать голову, как безболезненно переехать. Сейчас у многих возникли потребности в смене ОС и подобная легкость переезда очень на руку.

Из основных плюсов Postfix, кроме тех, что я уже перечислил, отмечу ещё некоторые:
✅ Очень информативные логи. Прямо классический пример качественных логов. По ним всегда ясно, где и что произошло. Никакое письмо не потеряется. Всегда будет понятно, почему оно не доставлено и куда в итоге пропало.
✅ Не припоминаю каких-то серьезных критических уязвимостей.
✅ Нетребовательный к ресурсам. На практике у меня были сервера с архивами почты на 3-4 Тб для 50-150 пользователей. У некоторых ящики были по 50-100 Гб. Доступ к ящикам через Dovecot. Всё это без проблем работает на обычных HDD в RAID1 или RAID10. Даже на таких ящиках без каких-то внешних поисковых сервисов вполне сносно работает поиск по всему ящику.
✅ Простой бэкап и перенос данных.
✅ Куча инструкций по интеграции с внешними сервисами: антиспам, антивирус, dkim и т.д.
✅ Возможность гибкой настройки транспорта и редактирования писем. Например, менять тему на лету, отправлять копию писем на несколько ящиков, подменять отправителя и т.д. Я реализовывал авто удаление писем с определённо темой через заданное количество дней.

Тематические ссылки с моего сайта:
◽ Перенос почтового сервера postfix
◽ Защита почтового сервера postfix
◽ Установка и настройка postfix
◽ Очистка и обслуживание почтовой базы postfix

А вы какие почтовые сервера предпочитаете?

#mailserver #postfix

За что люблю почтовый сервер Postfix, так это за его гибкость в настройках. Если хорошенько поискать, всегда можно найти решение той или иной задачи с этим почтовым сервером. Я неизменно всегда устанавливаю почтовый сервер на базе Postfix. Если выбираете почтовый сервер, который будете собирать из компонентов и настраивать самостоятельно, то рекомендую в качестве основы взять Postfix.

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

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

Начал искать решение и очень быстро нашёл - postfwd. Очень гибкое решение с возможностью писать свои правила для отправки. В Debian пакет есть в стандартном репозитории. Указанная задача решается очень просто:
1. Устанавливаем postfwd:
# apt install postfwd
2. Включаем автозапуск в /etc/default/postfwd, рисуем простой конфиг с единственным правилом в /etc/postfix/postfwd.cf:
id=R01; action=rcpt(sender/50/3600/REJECT sorry, max 50 emails per hour for sender $$sender exceeded)
При желании можно добавить предупреждение при совершённых 30-ти отправках в час:
id=R02; action=rate(sender/30/3600/WARN limit of 30 email per hour exceeded [$$ratecount hits])
Показал для примера, как выглядят правила. Большое количество примеров приведены в документации. По аналогии не трудно для себя писать правила. Возможности очень широкие.
3. Добавляем интеграцию в postfix через его механизм restrictions:
smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040
permit_mynetworks
permit_sasl_authenticated
...........................................
4. Запускаем postfwd, перечитываем конфиг postfix.

Сайт - https://postfwd.org
Исходники - https://github.com/postfwd/postfwd

Cсылки на мои материалы по postfix:
- Настройка postfix + dovecot + mysql база + postfixadmin + roundcube + dkim
- Настройка SSL/TLS сертификатов Let's Encrypt в postfix и dovecot
- Защита почтового сервера postfix + dovecot с помощью fail2ban
- Перенос почтового сервера postfix
- Очистка и обслуживание почтовой базы postfix
- Мониторинг postfix в zabbix         

#postfix #mailserver

Я неоднократно получал вопрос от тех, кто настраивал почтовый сервер по моей статье, о том, как закрыть почтовые алиасы от спама. Поясню, о чём идёт речь.

Допустим, у вас есть почтовый алиас all@firma.ru, куда входят все сотрудники компании. Их может быть очень много. Подобные алиасы удобно использовать для рассылок внутри компании. Обычно делаю общий алиас для всей компании и для каждого отдела. Остальное уже по потребностям.

Подобные адреса очень удобно использовать спамерам. Отправил одно письмо на all@firma.ru и его получили все сотрудники. Логично было бы ограничить возможность отправки на эти адреса. Я в своё время сам разбирал эту задачу и придумал решение. Нигде его не записал, поэтому каждый раз приходилось вспоминать, как я делал. Так что решил хотя бы заметкой оформить.

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

.....................................
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
check_recipient_access hash:/etc/postfix/maillist_access
..................................
Это строки из конфигурационного файла postfix main.cf. Текстовый файл maillist_access выглядит примерно так:
all@firma.ru REJECT
Одна строка, один адрес.

Суть тут в чём. Мы в ограничениях получателя указываем, что люди из mynetworks и sasl_authenticated не имеют никаких ограничений на отправку. Это все люди из белых списков локальных сетей (не рекомендую их использовать, только в крайних случаях) и прошедшие аутентификацию, то есть наши сотрудники и пользователи почтового сервера. А все остальные попадают на проверку check_recipient_access, где в файле указано действие для получателя all@firma.ru — давать REJECT. Вот и всё.

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

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

#postfix #mailserver

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

Назову несколько причин, почему отдаю предпочтение именно локальному Postfix.

1️⃣ У Postfix хорошее логирование. Всегда точно можно узнать, что, когда, кому было отправлено и какой статус получила эта отправка. Было ли письмо реально принято удалённой стороной или отклонено. Это особенно актуально для сайтов, где нет собственного логирования отправки, либо оно не очень информативное.

2️⃣ Вы без проблем можете направлять всю отправленную почту в отдельные ящики для аналитики, контроля или бэкапа. Всё делается средствами самого Postfix. Для разных сайтов и доменов можно настроить свои правила.

3️⃣ С помощью Postfix можно гибко управлять отправкой. Какую-то почту можно отправлять самостоятельно, какую-то направлять на отправку через внешний smtp сервер. Для каждого сайта, почтового домена или отдельного ящика можно настроить свои маршруты отправки.

4️⃣ Благодаря подробному логированию для Postfix легко настроить мониторинг, подсчёт статистики. Это позволит сразу заметить, если ваш сайт взломают и начнут рассылать через него спам, что случается не редко, если сайт не обслуживают и своевременно не обновляют. Много раз с этим сталкивался. Можно легко вычислить бота, который начнёт спамить в личку пользователям сайта. Им тут же полетят уведомления на почту. Статистика почты часто позволяет обнаружить проблемы быстрее всего. Советую использовать эту возможность.

5️⃣ Вы можете на ходу менять содержимое письма без участия непосредственно сайта, только средствами Postfix. Например, менять адрес отправителя или тему письма. Это снимет лишнюю задачу с разработчиков.

Ссылки на мои статьи по данной теме:
▪ Мониторинг postfix в zabbix
▪ Настройка маршрута отправки в зависимости от домена
▪ Как изменить тему письма и адрес отправителя через postfix
▪ Выбор сервера для отправки в зависимости от получателя

#postfix #mailserver #webserver

В Linux есть любопытный бинарник /bin/true, про который я узнал случайно. Стал искать подробности и наткнулся на интересную информацию про него. Сначала про него расскажу, а потом как я на него наткнулся.

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

Изначально true был обычным shell скриптом в unix вот такого содержания:

 #   Copyright (c) 1984 AT&T
 #    All Rights Reserved
 
 #   THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T
 #   The copyright notice above does not evidence any
 #   actual or intended publication of such source code.
 
 #ident    "@(#)cmd/true.sh    50.1"

По сути это пустой скрипт, который, если его запустить, ничего не делает, но завершается с нулевым кодом выхода. И вот этот скрипт компания AT&T запатентовала. Для того, чтобы его можно было использовать в Linux, пришлось написать то же самое на C и скомпилировать. Поэтому в Linux не скрипт, а бинарник, который делает то же самое, что и задумывалось изначально.

Аналогичной утилитой, только возвращающей код ошибки является /bin/false:

# /bin/false
# echo $?
1
Код выхода у неё ошибочный, то есть 1.

Узнал про /bin/true я случайно, когда в Debian смотрел systemd unit от postfix /lib/systemd/system/postfix.service. Открываю, а там такое:

[Unit]
Description=Postfix Mail Transport Agent
Conflicts=sendmail.service exim4.service
ConditionPathExists=/etc/postfix/main.cf

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true

[Install]
WantedBy=multi-user.target

Вообще не понятно, к чему всё это и почему при этом служба работает корректно. Как она запускается? Оказалось, что для управления работой postfix используются шаблоны systemd. И рядом лежит файл postfix@.service, где уже описаны все параметры запуска конкретного экземпляра почтового сервера. При этом в /etc/systemd/system/multi-user.target.wants есть символьная ссылка только на postfix.service, поэтому сразу не очевидно, что там зависимые юниты есть.

В итоге, сначала запускается основной unit, в котором прописана команда /bin/true, успешно отрабатывает, а потом то, что описано шаблоном.

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

Потом уже почитал ещё немного, увидел режим multiple Postfix instances в рамках одного хоста. Не буду на этом останавливаться подробно, но смысл в том, что можно запускать несколько экземпляров postfix, которые будут использовать разные файлы конфигураций и рабочие директории. Сам никогда подобное не настраивал и не вижу особо смысла в современных реалиях.

#postfix #systemd

Почтовые сервера, как правило, добавляют в заголовки писем всю цепочку адресов, которые оно прошло. Это стандартное поведение. Например, клиент с IP адресом 192.168.115.5 отправил письмо через почтовый сервер 95.185.15.218. В заголовках письма Received: будет отражена вся эта цепочка.

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

Received: from [10.8.2.2] (unknown [176.119.158.81])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
  key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mail.rocky-linux.ru (MailServer) with ESMTPSA id 59C4811B337

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

Добавляем в основной конфиг сервера /etc/postfix/main.cf новый параметр:

header_checks = regexp:/etc/postfix/header_checks

Создаём этот файл /etc/postfix/header_checks и добавляем в моём случае такое содержимое:

/^Received:.*\[10\.8\.2\.[0-9]/   IGNORE

Создаём db файл и перечитываем конфигурацию:

# postmap header_checks
# postfix reload

Больше в Received: заголовках писем, отправленных через мой почтовый сервер не будет информации о клиентах из подсети 10.8.2.0/24.

Другие полезные материалы по Postfix:

◽️Ограничение на отправку писем в единицу времени
◽️Перенос почтового сервера
▪️ Мониторинг postfix в zabbix
▪️ Настройка маршрута отправки в зависимости от домена
▪️ Как изменить тему письма и адрес отправителя через postfix
▪️ Выбор сервера для отправки в зависимости от получателя

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#postfix

Почтовый сервер postfix позволяет очень гибко управлять транспортом почты во всех направлениях. Меня не раз спрашивали, можно ли сделать так, чтобы на какой-то домен почта не отправлялась, но при этом клиент во время отправки не получал никакой ошибки. То есть он как-будто всё отправил, но письмо реально не ушло.

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

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

В общем, ситуации бывают разные. Расскажу, как всё это можно настроить встроенными инструментами postfix. Он будет отправлять письма только разрешённым доменам или наоборот, запретит отправку на какие-то домены, но при этом отправляющий будет думать, что всё ОК, обратного письма с ошибкой он не получит. При этом в логе postfix будет явно видно, что письмо не было отправлено.

Настраиваем параметр transport_maps, добавляя в /etc/postfix/main.cf:

transport_maps = hash:/etc/postfix/transport_map

Создаём файл /etc/postfix/transport_map следующего содержания:

example.com   discard: Not allowed destination

Создаём индексированный файл и перечитываем конфигурацию:

# postmap /etc/postfix/transport_map
# postfix reload

Теперь при отправке письма на домен example.com клиент не получит никакой ошибки. Он будет считать, что письмо нормально отправлено. При этом в логе postfix это отразится вот так:

2025-05-06T11:41:29.689884+03:00 mailsrv postfix/discard[3974535]: 887AA11B319: to=<user@example.com>, relay=none, delay=0.18, delays=0.17/0.01/0/0, dsn=2.0.0, status=sent (Not allowed destination)

Отправки реально не было, так как relay=none. Можно сделать и обратную ситуацию. Отменить отправку на все домены, кроме example.com. Тогда файл transport_map будет выглядеть так:

example.com :
* discard: Not allowed destination

Для example.com обычная доставка, для всех остальных - discard. Поясню, как это работает. Данный параметр я знаю давно и активно использую. Пример файла transport_map из моей практики:

websrv.site.ru local
backupmail.ru relay:[backupmail.ru]:25
* relay:[smtp.yandex.ru]:465

Первый домен websrv.site.ru используется как локальный. Вся почта для этого домена отправляется только локально в рамках данного сервера. Второй домен backupmail.ru используется для бэкапа всей корреспонденции. Ящики из этого домена настроены как сборщики копий через bcc_maps всей входящей и исходящей почты. Третья строчка указывает отправлять всю остальную почту через smtp сервер Яндекса.

Подробно я эту тему рассматривал в отдельной статье:

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

Там как раз рассматривается параметр transport_maps, но не в контексте задачи скрытого запрета отправки писем. Для запрета мы просто указали соответствующий транспорт - discard, вместо relay. И письма в итоге не отправляются.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#postfix