Решил в праздники, пока все отдыхают, перенести почтовый сервер с устаревшей системой, на свежую 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