Я всегда на одиночных веб серверах использую для отправки почты локальный Postfix. И хотя я не раз рассказывал про различные сервисы для отправки почты или специализированные серверы, которые можно развернуть у себя только для рассылок с сайта, сам я неизменно использую Postfix, потому что хорошо его знаю.
Назову несколько причин, почему отдаю предпочтение именно локальному Postfix.
1️⃣ У Postfix хорошее логирование. Всегда точно можно узнать, что, когда, кому было отправлено и какой статус получила эта отправка. Было ли письмо реально принято удалённой стороной или отклонено. Это особенно актуально для сайтов, где нет собственного логирования отправки, либо оно не очень информативное.
2️⃣ Вы без проблем можете направлять всю отправленную почту в отдельные ящики для аналитики, контроля или бэкапа. Всё делается средствами самого Postfix. Для разных сайтов и доменов можно настроить свои правила.
3️⃣ С помощью Postfix можно гибко управлять отправкой. Какую-то почту можно отправлять самостоятельно, какую-то направлять на отправку через внешний smtp сервер. Для каждого сайта, почтового домена или отдельного ящика можно настроить свои маршруты отправки.
4️⃣ Благодаря подробному логированию для Postfix легко настроить мониторинг, подсчёт статистики. Это позволит сразу заметить, если ваш сайт взломают и начнут рассылать через него спам, что случается не редко, если сайт не обслуживают и своевременно не обновляют. Много раз с этим сталкивался. Можно легко вычислить бота, который начнёт спамить в личку пользователям сайта. Им тут же полетят уведомления на почту. Статистика почты часто позволяет обнаружить проблемы быстрее всего. Советую использовать эту возможность.
5️⃣ Вы можете на ходу менять содержимое письма без участия непосредственно сайта, только средствами Postfix. Например, менять адрес отправителя или тему письма. Это снимет лишнюю задачу с разработчиков.
Ссылки на мои статьи по данной теме:
▪ Мониторинг postfix в zabbix
▪ Настройка маршрута отправки в зависимости от домена
▪ Как изменить тему письма и адрес отправителя через postfix
▪ Выбор сервера для отправки в зависимости от получателя
#postfix #mailserver #webserver
Назову несколько причин, почему отдаю предпочтение именно локальному Postfix.
1️⃣ У Postfix хорошее логирование. Всегда точно можно узнать, что, когда, кому было отправлено и какой статус получила эта отправка. Было ли письмо реально принято удалённой стороной или отклонено. Это особенно актуально для сайтов, где нет собственного логирования отправки, либо оно не очень информативное.
2️⃣ Вы без проблем можете направлять всю отправленную почту в отдельные ящики для аналитики, контроля или бэкапа. Всё делается средствами самого Postfix. Для разных сайтов и доменов можно настроить свои правила.
3️⃣ С помощью Postfix можно гибко управлять отправкой. Какую-то почту можно отправлять самостоятельно, какую-то направлять на отправку через внешний smtp сервер. Для каждого сайта, почтового домена или отдельного ящика можно настроить свои маршруты отправки.
4️⃣ Благодаря подробному логированию для Postfix легко настроить мониторинг, подсчёт статистики. Это позволит сразу заметить, если ваш сайт взломают и начнут рассылать через него спам, что случается не редко, если сайт не обслуживают и своевременно не обновляют. Много раз с этим сталкивался. Можно легко вычислить бота, который начнёт спамить в личку пользователям сайта. Им тут же полетят уведомления на почту. Статистика почты часто позволяет обнаружить проблемы быстрее всего. Советую использовать эту возможность.
5️⃣ Вы можете на ходу менять содержимое письма без участия непосредственно сайта, только средствами Postfix. Например, менять адрес отправителя или тему письма. Это снимет лишнюю задачу с разработчиков.
Ссылки на мои статьи по данной теме:
▪ Мониторинг postfix в zabbix
▪ Настройка маршрута отправки в зависимости от домена
▪ Как изменить тему письма и адрес отправителя через postfix
▪ Выбор сервера для отправки в зависимости от получателя
#postfix #mailserver #webserver
👍87👎1
В Linux есть любопытный бинарник
Бинарник этот по своей сути программа-пустышка. Он делает одну простую вещь - завершается с нулевым кодом выхода. То есть означает успешно выполненную команду. Используют её обычно для каких-то целей в скриптах.
Изначально true был обычным shell скриптом в unix вот такого содержания:
По сути это пустой скрипт, который, если его запустить, ничего не делает, но завершается с нулевым кодом выхода. И вот этот скрипт компания AT&T запатентовала. Для того, чтобы его можно было использовать в Linux, пришлось написать то же самое на C и скомпилировать. Поэтому в Linux не скрипт, а бинарник, который делает то же самое, что и задумывалось изначально.
Аналогичной утилитой, только возвращающей код ошибки является
Код выхода у неё ошибочный, то есть 1.
Узнал про
Вообще не понятно, к чему всё это и почему при этом служба работает корректно. Как она запускается? Оказалось, что для управления работой postfix используются шаблоны systemd. И рядом лежит файл
В итоге, сначала запускается основной unit, в котором прописана команда /bin/true, успешно отрабатывает, а потом то, что описано шаблоном.
Если честно, я не совсем понял, зачем для postfix используют шаблон. Они обычно нужны для удобного управления пулом запущенных сервисов единой командой. Когда у вас через шаблон запущены процессы, их все остановить или запустить можно одной командой. Но postfix обычно работает одним экземпляром на сервере.
Потом уже почитал ещё немного, увидел режим multiple Postfix instances в рамках одного хоста. Не буду на этом останавливаться подробно, но смысл в том, что можно запускать несколько экземпляров postfix, которые будут использовать разные файлы конфигураций и рабочие директории. Сам никогда подобное не настраивал и не вижу особо смысла в современных реалиях.
#postfix #systemd
/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 AgentConflicts=sendmail.service exim4.serviceConditionPathExists=/etc/postfix/main.cf[Service]Type=oneshotRemainAfterExit=yesExecStart=/bin/trueExecReload=/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
👍75👎5
Почтовые сервера, как правило, добавляют в заголовки писем всю цепочку адресов, которые оно прошло. Это стандартное поведение. Например, клиент с IP адресом 192.168.115.5 отправил письмо через почтовый сервер 95.185.15.218. В заголовках письма Received: будет отражена вся эта цепочка.
Вот реальный пример заголовка отправленного письма с моего тестового сервера, к которому я подключаюсь для отправки:
Тут указан мой локальный адрес 10.8.2.2, на котором был запущен мой почтовый клиент и некоторые мои параметры соединения. Внешним получателям не обязательно знать вашу внутреннюю кухню. Можно эту информацию удалить. В Postfix это делается очень просто. За это я его и люблю и обычно именно его использую. Очень легко настроить то, что вам нужно.
Добавляем в основной конфиг сервера
Создаём этот файл
Создаём db файл и перечитываем конфигурацию:
Больше в
Другие полезные материалы по Postfix:
◽️Ограничение на отправку писем в единицу времени
◽️Перенос почтового сервера
▪️ Мониторинг postfix в zabbix
▪️ Настройка маршрута отправки в зависимости от домена
▪️ Как изменить тему письма и адрес отправителя через postfix
▪️ Выбор сервера для отправки в зависимости от получателя
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#postfix
Вот реальный пример заголовка отправленного письма с моего тестового сервера, к которому я подключаюсь для отправки:
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
2👍158👎5
Почтовый сервер postfix позволяет очень гибко управлять транспортом почты во всех направлениях. Меня не раз спрашивали, можно ли сделать так, чтобы на какой-то домен почта не отправлялась, но при этом клиент во время отправки не получал никакой ошибки. То есть он как-будто всё отправил, но письмо реально не ушло.
Я так сходу не придумал как это сделать стандартными средствами postfix без костылей. У него есть настройка smtpd_recipient_restrictions, где можно управлять разрешениями для получателей. Там можно явно указать, что для конкретного домена отправка запрещена. Но клиент при попытке отправить туда письмо, получит обратное письмо с ошибкой на тему того, что это запрещено.
Это не всегда удобно. Можно подумать, что это нужно для того, чтобы ввести в заблуждение пользователя почты, чтобы он не знал, что письмо реально не доставлено. Но на самом деле нет. Это чаще всего нужно не для этого. Например, может быть софт, который делает какие-то отправки по определённому набору доменов. И отправлять ему можно только туда. Если в его список рассылки по какой-то причине попадут другие домены, а вы настроите smtpd_recipient_restrictions, то его завалит обратными письмами с ошибками.
В общем, ситуации бывают разные. Расскажу, как всё это можно настроить встроенными инструментами postfix. Он будет отправлять письма только разрешённым доменам или наоборот, запретит отправку на какие-то домены, но при этом отправляющий будет думать, что всё ОК, обратного письма с ошибкой он не получит. При этом в логе postfix будет явно видно, что письмо не было отправлено.
Настраиваем параметр transport_maps, добавляя в
Создаём файл
Создаём индексированный файл и перечитываем конфигурацию:
Теперь при отправке письма на домен example.com клиент не получит никакой ошибки. Он будет считать, что письмо нормально отправлено. При этом в логе postfix это отразится вот так:
Отправки реально не было, так как
Для example.com обычная доставка, для всех остальных - discard. Поясню, как это работает. Данный параметр я знаю давно и активно использую. Пример файла
Первый домен websrv.site.ru используется как локальный. Вся почта для этого домена отправляется только локально в рамках данного сервера. Второй домен backupmail.ru используется для бэкапа всей корреспонденции. Ящики из этого домена настроены как сборщики копий через bcc_maps всей входящей и исходящей почты. Третья строчка указывает отправлять всю остальную почту через smtp сервер Яндекса.
Подробно я эту тему рассматривал в отдельной статье:
⇨ Postfix - выбор сервера для отправки в зависимости от получателя
Там как раз рассматривается параметр transport_maps, но не в контексте задачи скрытого запрета отправки писем. Для запрета мы просто указали соответствующий транспорт - discard, вместо relay. И письма в итоге не отправляются.
Если у кого-то есть вопросы по настройке 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 localbackupmail.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
👍102👎3
Я наконец-то закончил обновление статьи про локальный почтовый сервер на базе Postfix и Dovecot:
⇨ Настройка Postfix + Dovecot + Postfixadmin + Roundcube + DKIM на Debian
Она актуальна на сегодняшний день на базе Debian 13 и стандартных пакетов в её репозитории. Хотя для примера я некоторые компоненты скачивал из их репозиториев и устанавливал вручную, так как со временем в Debian версии начинают отставать от актуальных.
Старую версию статьи под Debian 12 сохранил в виде статической страницы и упаковал в архив. Ссылка в начале новой статьи. Если кто-то по ней настраивал или что-то нужно будет подсмотреть, можете скачать. Я не стал плодить похожие статьи с разными версиями ПО, так как это неудобно, приводит к дублированию информации на сайте и путанице. Удобнее, когда есть одна актуальная статья, на которую можно ссылаться.
Уместил в одну статью практически невмещаемое. Очень большой материал получился, по которому можно с нуля практически без базовых знаний о предметной области, настроить и запустить в работу почтовый сервер. Материал подаётся этапами с объяснениями на каждом, чтобы было понятнее.
Можно было бы сразу итоговый вариант настроек дать и всё разом запустить, но это было бы не так понятно. В целом, подобный сервер можно запустить в пару кликов на базе какого-нибудь Mailcow, Mailu, или их аналогов. Почти все сборки бесплатных серверов (и не только бесплатных) сделаны на базе этих же компонентов. Но если вы собираетесь потом эксплуатировать и администрировать этот сервер, то без знания его устройства это будет сложно сделать.
Так что если хотите изучить эту тему, то рекомендую действовать похожим образом, описанным в статье. Несмотря на то, что почту и локальные серверы для неё хоронят уже столько лет, актуальности она не потеряла и повсеместно используется. А как показал недавний опрос, локальных установок значительно больше, чем использование облачных сервисов. А подобных сборок так вообще треть. И этому есть вполне логичные объяснения. Я на днях ещё подниму эту тему.
Всем спасибо, кто пролайкал и прокомментировал мою прошлую заметку по этой теме. Любому автору приятно осознавать, что то, что он делает, кому-то нужно. Поэтому лично я всегда лайкаю и комментирую то, что вижу у других авторов. У многих нет финансовой мотивации что-то делать, потому что их сфера либо не монетизируется, либо они не умеют это делать, а сами работают в других местах. Но при этом всё равно что-то пишут, снимают, делают для других.
Например, сайт для меня в финансовом плане сейчас пассив. Но я вижу, что его каждый день до сих пор читает огромное количество людей. Они находят его полезным, хотя многие материалы сильно устарели, содержат ошибки. По мере сил и времени, стараюсь что-то обновлять и актуализировать. Эту статью писал в выходные, на буднях просто нет на это времени.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver #postfix #dovecot #статья
⇨ Настройка Postfix + Dovecot + Postfixadmin + Roundcube + DKIM на Debian
Она актуальна на сегодняшний день на базе Debian 13 и стандартных пакетов в её репозитории. Хотя для примера я некоторые компоненты скачивал из их репозиториев и устанавливал вручную, так как со временем в Debian версии начинают отставать от актуальных.
Старую версию статьи под Debian 12 сохранил в виде статической страницы и упаковал в архив. Ссылка в начале новой статьи. Если кто-то по ней настраивал или что-то нужно будет подсмотреть, можете скачать. Я не стал плодить похожие статьи с разными версиями ПО, так как это неудобно, приводит к дублированию информации на сайте и путанице. Удобнее, когда есть одна актуальная статья, на которую можно ссылаться.
Уместил в одну статью практически невмещаемое. Очень большой материал получился, по которому можно с нуля практически без базовых знаний о предметной области, настроить и запустить в работу почтовый сервер. Материал подаётся этапами с объяснениями на каждом, чтобы было понятнее.
Можно было бы сразу итоговый вариант настроек дать и всё разом запустить, но это было бы не так понятно. В целом, подобный сервер можно запустить в пару кликов на базе какого-нибудь Mailcow, Mailu, или их аналогов. Почти все сборки бесплатных серверов (и не только бесплатных) сделаны на базе этих же компонентов. Но если вы собираетесь потом эксплуатировать и администрировать этот сервер, то без знания его устройства это будет сложно сделать.
Так что если хотите изучить эту тему, то рекомендую действовать похожим образом, описанным в статье. Несмотря на то, что почту и локальные серверы для неё хоронят уже столько лет, актуальности она не потеряла и повсеместно используется. А как показал недавний опрос, локальных установок значительно больше, чем использование облачных сервисов. А подобных сборок так вообще треть. И этому есть вполне логичные объяснения. Я на днях ещё подниму эту тему.
Всем спасибо, кто пролайкал и прокомментировал мою прошлую заметку по этой теме. Любому автору приятно осознавать, что то, что он делает, кому-то нужно. Поэтому лично я всегда лайкаю и комментирую то, что вижу у других авторов. У многих нет финансовой мотивации что-то делать, потому что их сфера либо не монетизируется, либо они не умеют это делать, а сами работают в других местах. Но при этом всё равно что-то пишут, снимают, делают для других.
Например, сайт для меня в финансовом плане сейчас пассив. Но я вижу, что его каждый день до сих пор читает огромное количество людей. Они находят его полезным, хотя многие материалы сильно устарели, содержат ошибки. По мере сил и времени, стараюсь что-то обновлять и актуализировать. Эту статью писал в выходные, на буднях просто нет на это времени.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#mailserver #postfix #dovecot #статья
Please open Telegram to view this post
VIEW IN TELEGRAM
110👍398👎2
Решил обновить весь цикл статей про почтовый сервер. Начал с самой актуальной - настройка Fail2Ban для защиты от перебора учёток и прочих паразитных соединений:
⇨ Защита почтового сервера Postfix + Dovecot с помощью Fail2Ban
Инструкция получилась универсальная, потому что и для Postfix, и для Dovecot пришлось писать свой шаблон под формат текущих логов свежих версий. Так что материал будет актуален для любого сервиса с текстовыми логами.
В очередной раз хотел сходить по лёгкому пути и попросил ИИ написать шаблоны. ChatGPT не справился совершенно. Мучал его минут 15, пока не понял, что это бесполезно и проще разобраться самому. Он постоянно обещал теперь точно рабочую версию, но всё мимо. PerplexityPro тоже не помогла.
Я пока спокоен за своё будущее трудоустройство. Современные ИИшки никаким интеллектом не обладают и даже имея документацию и похожие примеры не могут родить новое уникальное решение, которое ещё нигде не подсмотрели. У них хорошо получается с bash, думал и с другими вещами так же будет, но нет.
Fail2Ban очень старое, простое и эффективное средство. За столько лет у него не появилось аналогов, кроме CrowdSec, но он сильно навороченнее и движется в сторону масштабного сервиса, а не простой утилиты для одиночного сервера. При этом Fail2Ban, несмотря на свою простоту и топорный подход анализа логов, работает нормально и эффективно там, где нет больших нагрузок. Я его повсеместно использую.
Помню как-то даже шутку придумал:
Это придумано в контексте того, что сам я лично для SSH никогда не ставлю Fail2Ban. В этом просто нет большого смысла.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#fail2ban #mailserver #postfix #dovecot
⇨ Защита почтового сервера Postfix + Dovecot с помощью Fail2Ban
Инструкция получилась универсальная, потому что и для Postfix, и для Dovecot пришлось писать свой шаблон под формат текущих логов свежих версий. Так что материал будет актуален для любого сервиса с текстовыми логами.
В очередной раз хотел сходить по лёгкому пути и попросил ИИ написать шаблоны. ChatGPT не справился совершенно. Мучал его минут 15, пока не понял, что это бесполезно и проще разобраться самому. Он постоянно обещал теперь точно рабочую версию, но всё мимо. PerplexityPro тоже не помогла.
Я пока спокоен за своё будущее трудоустройство. Современные ИИшки никаким интеллектом не обладают и даже имея документацию и похожие примеры не могут родить новое уникальное решение, которое ещё нигде не подсмотрели. У них хорошо получается с bash, думал и с другими вещами так же будет, но нет.
Fail2Ban очень старое, простое и эффективное средство. За столько лет у него не появилось аналогов, кроме CrowdSec, но он сильно навороченнее и движется в сторону масштабного сервиса, а не простой утилиты для одиночного сервера. При этом Fail2Ban, несмотря на свою простоту и топорный подход анализа логов, работает нормально и эффективно там, где нет больших нагрузок. Я его повсеместно использую.
Помню как-то даже шутку придумал:
«Если я усну и проснусь через сто лет и меня спросят, что сейчас настраивают системные администраторы Linux, я отвечу: блокировку SSH с помощью Fail2Ban».
Это придумано в контексте того, что сам я лично для SSH никогда не ставлю Fail2Ban. В этом просто нет большого смысла.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#fail2ban #mailserver #postfix #dovecot
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍115👎4
Пока работает полностью настроенный сервер с тестовым почтовым сервером, решил обновить все статьи, связанные с ним. Не знаю, насколько хватит терпения и времени, так как статью писать помуторнее, чем просто заметку. Для заметки достаточно быстро настроить, сделать пару скринов и своими словами потом описать проделанное. А для статьи надо полностью всю последовательность описать и заскринить, чтобы можно было повторить.
В этот раз занялся мониторингом:
⇨ Мониторинг Postfix в Zabbix
У меня очень давно опубликована и периодически обновлялась статья на эту тему. Там я сам из костылей и велосипедов собирал свой шаблон для почтового сервера и подробно всё расписывал, почему, зачем и как.
Времени поддерживать свои шаблоны в актуальном состоянии у меня нет, так что решил перейти на что-то более стабильное в плане поддержки. Взял шаблон из репозитория Zabbix с community-templates:
⇨ Template App Postfix by Zabbix Agent
Там в принципе есть всё, что нужно. Все многочисленные шаблоны и статьи для мониторинга Postfix похожи, потому что основа для метрик там почтовая очередь и лог-файл со статистикой. И все этот лог-файл разбирают с помощью pflogsumm. Это древнючий скрипт на Perl. Но так как Postfix бдит за обратной совместимостью и практически не меняет формат лог файла в части доставки писем, скрипты даже 20-ти летней давности работают до сих пор.
Представленный шаблон относительно свежий. Писался для версии 6.4. Я его без проблем адаптировал по свой почтовый сервер, который недавно обновлял. По сути только пути к бинарникам и лог-файлам нужно было поправить.
Описанный мониторинг будет актуален для всех решений на базе Postfix, где используется лог файл /var/log/mail.log и стандартная очередь в /var/spool/postfix. Пути, если что, можно будет поправить.
Альтернативное решение - Prometheus exporter for Postfix. У Grafana есть готовый дашборд для этого экспортера. А при желании какие-то метрики из него, или даже все, можно завести в Zabbix через встроенную предобработку метрик Prometheus.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#zabbix #postfix #mailserver
В этот раз занялся мониторингом:
⇨ Мониторинг Postfix в Zabbix
У меня очень давно опубликована и периодически обновлялась статья на эту тему. Там я сам из костылей и велосипедов собирал свой шаблон для почтового сервера и подробно всё расписывал, почему, зачем и как.
Времени поддерживать свои шаблоны в актуальном состоянии у меня нет, так что решил перейти на что-то более стабильное в плане поддержки. Взял шаблон из репозитория Zabbix с community-templates:
⇨ Template App Postfix by Zabbix Agent
Там в принципе есть всё, что нужно. Все многочисленные шаблоны и статьи для мониторинга Postfix похожи, потому что основа для метрик там почтовая очередь и лог-файл со статистикой. И все этот лог-файл разбирают с помощью pflogsumm. Это древнючий скрипт на Perl. Но так как Postfix бдит за обратной совместимостью и практически не меняет формат лог файла в части доставки писем, скрипты даже 20-ти летней давности работают до сих пор.
Представленный шаблон относительно свежий. Писался для версии 6.4. Я его без проблем адаптировал по свой почтовый сервер, который недавно обновлял. По сути только пути к бинарникам и лог-файлам нужно было поправить.
Описанный мониторинг будет актуален для всех решений на базе Postfix, где используется лог файл /var/log/mail.log и стандартная очередь в /var/spool/postfix. Пути, если что, можно будет поправить.
Альтернативное решение - Prometheus exporter for Postfix. У Grafana есть готовый дашборд для этого экспортера. А при желании какие-то метрики из него, или даже все, можно завести в Zabbix через встроенную предобработку метрик Prometheus.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#zabbix #postfix #mailserver
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍79👎2
Продолжу тему с мониторингом почтового сервера. Вспомнился ещё один очень простой вариант, когда у вас нет Zabbix или Prometheus, или вы не хотите по какой-то причине всё это настраивать. Можно настроить мониторинг основных метрик по доставке писем и анализа очереди буквально за 5 минут.
Есть очень старый, но до сих пор по какой-то причине поддерживаемый мониторинг - Monitorix. Я уже упоминал его когда-то давно. Это простейший мониторинг, написанный на Perl, для одиночного сервера. У него преднастроен набор некоторых метрик и графиков, так что вручную настраивать ничего не надо. Достаточно указать модули, которые вы хотите добавить в мониторинг.
Один из таких модулей поддерживает Postfix и анализ его логов с помощью всё того же pflogsumm. Я даже удивился, когда его попробовал и всё практически сразу заработало. Погонял письма на сервере, получил пару rejected, посадил письмо в очередь. Посмотрел на графики, там всё это отобразилось, хоть и не совсем наглядно. Мониторинг не даёт посмотреть графики на интервале меньше суток, а на моём тестовом сервере трафика почти нет. Графики и значения усредняются.
Вообще, Monitorix любопытный мониторинг. Может быть актуален для одноплатников или где-то ещё, где нужно сэкономить по максимуму ресурсы. Мало того, что его настаивать очень просто, так он ещё и ресурсов занимает минимум.
Показываю, как настроил Monitorix для почтового сервера Postfix. Устанавливаем:
В файле конфигурации
Меняю во всех строках имя лог файла
Указываю в качестве почтового сервера postfix:
Перезапускаю мониторинг:
Можно идти на http://IP:8080/monitorix/ и смотреть графики. Помимо почты будут собираться и другие метрики, которые активированы в разделе конфигурации
Такой вот необычный мониторинг из прошлого. У него можно настроить аутентификацию, уведомления и некоторые другие вещи. На сайте есть руководства. Например, можно мониторить LM-Sensors, размер директорий и кол-во файлов (я проверил, легко настраивается, нормально работает), статистику Netstat, активность процессов, открытые файлы, статистику конкретных TCP портов и многое другое.
Метрики Monitorix хранит в RRDtool, а для графиков автоматом рисует готовые png. Уже после написания заметки увидел, что можно включить не только суточные интервалы просмотра, но и часовые. Для этого в конфигурацию надо добавить:
И перезапустить сервис.
Выглядит всё это очень непривычно в 2025 году. Но в целом всё работает из коробки. Графики приятны для глаз. Собираются все базовые метрики: CPU, Mem, Network, I/O и т.д. Поставил, запустил и всё заработало.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#postfix #мониторинг
Есть очень старый, но до сих пор по какой-то причине поддерживаемый мониторинг - Monitorix. Я уже упоминал его когда-то давно. Это простейший мониторинг, написанный на Perl, для одиночного сервера. У него преднастроен набор некоторых метрик и графиков, так что вручную настраивать ничего не надо. Достаточно указать модули, которые вы хотите добавить в мониторинг.
Один из таких модулей поддерживает Postfix и анализ его логов с помощью всё того же pflogsumm. Я даже удивился, когда его попробовал и всё практически сразу заработало. Погонял письма на сервере, получил пару rejected, посадил письмо в очередь. Посмотрел на графики, там всё это отобразилось, хоть и не совсем наглядно. Мониторинг не даёт посмотреть графики на интервале меньше суток, а на моём тестовом сервере трафика почти нет. Графики и значения усредняются.
Вообще, Monitorix любопытный мониторинг. Может быть актуален для одноплатников или где-то ещё, где нужно сэкономить по максимуму ресурсы. Мало того, что его настаивать очень просто, так он ещё и ресурсов занимает минимум.
Показываю, как настроил Monitorix для почтового сервера Postfix. Устанавливаем:
# apt install monitorix pflogsummВ файле конфигурации
/etc/monitorix/monitorix.conf включаю отображение графиков почты:<graph_enable>..... mail = y....</graph_enable>Меняю во всех строках имя лог файла
/var/log/maillog на /var/log/mail.log.Указываю в качестве почтового сервера postfix:
<mail>... mta = postfix...</mail>Перезапускаю мониторинг:
# systemctl restart monitorix# systemctl enable monitorixМожно идти на http://IP:8080/monitorix/ и смотреть графики. Помимо почты будут собираться и другие метрики, которые активированы в разделе конфигурации
graph_enable. Всё, что не нужно, можно отключить.Такой вот необычный мониторинг из прошлого. У него можно настроить аутентификацию, уведомления и некоторые другие вещи. На сайте есть руководства. Например, можно мониторить LM-Sensors, размер директорий и кол-во файлов (я проверил, легко настраивается, нормально работает), статистику Netstat, активность процессов, открытые файлы, статистику конкретных TCP портов и многое другое.
Метрики Monitorix хранит в RRDtool, а для графиков автоматом рисует готовые png. Уже после написания заметки увидел, что можно включить не только суточные интервалы просмотра, но и часовые. Для этого в конфигурацию надо добавить:
enable_hourly_view = yИ перезапустить сервис.
Выглядит всё это очень непривычно в 2025 году. Но в целом всё работает из коробки. Графики приятны для глаз. Собираются все базовые метрики: CPU, Mem, Network, I/O и т.д. Поставил, запустил и всё заработало.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#postfix #мониторинг
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍80👎1
Написал очередную статью из цикла про настройку своего почтового сервера:
⇨ Roundcube Fetchmail plugin - сбор почты с других почтовых ящиков
Я в ней настраиваю плагин для веб клиента Roundcube, с помощью которого можно собирать в свой ящик почту с других внешних серверов. И настроить этот сбор может каждый пользователь самостоятельно в своём аккаунте. Работает всё это на базе известного и популярного решения Fetchmail.
В настоящий момент цикл моих статей про почтовый сервер выглядит следующим образом:
▪️Настройка сервера на базе ОС Debian
▪️Защита от перебора учётных данных с помощью Fail2Ban
▪️Мониторинг Postfix в Zabbix
▪️Автоматическая загрузка почтовых вложений в Nextcloud при отправке через RoundCube и Thunderbird
▪️Roundcube Fetchmail plugin - сбор почты с других почтовых ящиков
Это свежие статьи, обновлённые в течении последних двух месяцев. Есть более старый, но актуальный материал:
◽️Выбор сервера для отправки в зависимости от получателя
◽️Настройка маршрута отправки в зависимости от домена
◽️Ограничение на отправку писем в единицу времени
◽️Перенос почтового сервера
◽️Как изменить тему письма и адрес отправителя через Postfix
◽️Удаление из писем заголовков с локальными IP адресами
◽️Защита почтовых алиасов с множеством получателей от спама
◽️Очистка и обслуживание почтовой базы Postfix
❓Как думаете, какой ещё темы не хватает в контексте своего почтового сервера? По идее не хватает бэкапа, но я почтовую базу формата maildir бэкаплю обычным rsync, про который было много заметок и добавить нечего. Подумываю написать ещё про сбор и анализ логов. Больше ничего в голову не приходит. По идее, всё наиболее актуальное я описал.
Не хватает материала по аутентификации через LDAP, но лично я всегда для почтового сервера использую отдельную базу данных учётных записей. Почтовые сервера всегда открыты для всего интернета, клиенты настроены на различных устройствах пользователей. Учётные данные нередко утекают. Мне не нравится идея объединять их с другими сервисами. Конкретно для почты я считаю, лучше использовать отдельную базу данных с учётными записями, хотя это и не совсем удобно. Для больших масштабов, наверное, не подойдёт, но для малых и средних компаний вполне.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver #postfix #подборка
⇨ Roundcube Fetchmail plugin - сбор почты с других почтовых ящиков
Я в ней настраиваю плагин для веб клиента Roundcube, с помощью которого можно собирать в свой ящик почту с других внешних серверов. И настроить этот сбор может каждый пользователь самостоятельно в своём аккаунте. Работает всё это на базе известного и популярного решения Fetchmail.
В настоящий момент цикл моих статей про почтовый сервер выглядит следующим образом:
▪️Настройка сервера на базе ОС Debian
▪️Защита от перебора учётных данных с помощью Fail2Ban
▪️Мониторинг Postfix в Zabbix
▪️Автоматическая загрузка почтовых вложений в Nextcloud при отправке через RoundCube и Thunderbird
▪️Roundcube Fetchmail plugin - сбор почты с других почтовых ящиков
Это свежие статьи, обновлённые в течении последних двух месяцев. Есть более старый, но актуальный материал:
◽️Выбор сервера для отправки в зависимости от получателя
◽️Настройка маршрута отправки в зависимости от домена
◽️Ограничение на отправку писем в единицу времени
◽️Перенос почтового сервера
◽️Как изменить тему письма и адрес отправителя через Postfix
◽️Удаление из писем заголовков с локальными IP адресами
◽️Защита почтовых алиасов с множеством получателей от спама
◽️Очистка и обслуживание почтовой базы Postfix
❓Как думаете, какой ещё темы не хватает в контексте своего почтового сервера? По идее не хватает бэкапа, но я почтовую базу формата maildir бэкаплю обычным rsync, про который было много заметок и добавить нечего. Подумываю написать ещё про сбор и анализ логов. Больше ничего в голову не приходит. По идее, всё наиболее актуальное я описал.
Не хватает материала по аутентификации через LDAP, но лично я всегда для почтового сервера использую отдельную базу данных учётных записей. Почтовые сервера всегда открыты для всего интернета, клиенты настроены на различных устройствах пользователей. Учётные данные нередко утекают. Мне не нравится идея объединять их с другими сервисами. Конкретно для почты я считаю, лучше использовать отдельную базу данных с учётными записями, хотя это и не совсем удобно. Для больших масштабов, наверное, не подойдёт, но для малых и средних компаний вполне.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#mailserver #postfix #подборка
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍87👎2
Продолжу одновременно две темы, которые развиваю последнее время - почтовый сервер на базе Postfix и сбор логов в Loki. Покажу, как очень просто и быстро собирать логи Postfix в Loki с базовым анализом содержимого и простенькой визуализацией в дашборде.
Напомню, что у меня есть подробная статья про мониторинг Postfix с помощью Zabbix. Там в том числе выполняется и анализ логов, но локально, а в систему мониторинга уходит результат локальной обработки. Сами логи Postfix не хранятся.
Сегодня я рассмотрю другой вариант - непосредственно хранение логов на внешнем сервере Loki, который сам будет парсить данные и выполнять некоторую аналитику. Я выведу на дашборд метрики:
◽️Количество доставленных и отклонённых писем в виде соотношения и временной шкалы
◽️Статистика по доменам внешних получателей писем от нас
◽️Статистика по полученным письмам локальных доменов нашего сервера
◽️Статистика по отклонённым письмам в разрезе ошибок и доменов
Помимо этого Loki автоматически будет парсить поступающие логи, что позволит выполнять группировки по 24 распознанным полям: имя получателя, имя отправителя, домен отправителя, IP адрес, ID сообщения, статусы и т.д.
Данную заметку я пишу на примере реального почтового сервера, который я настроил по этой своей статье. Это важно, так как в разных версиях Postfix немного отличается формат логов. Я за основу взял готовый Dashboard из базы Grafana и подправил его под свою версию сервера и настроек Alloy, которые я возьму из этой заметки. А сам Loki установлен и настроен так же, как тут.
Первым делом устанавливаем Alloy на почтовый сервер с Postfix. Посмотреть установку можно в предыдущей заметке. Для сбора только почтовых логов достаточно такой конфигурации:
После этого логи сразу потекут в Loki. Их можно смотреть в разделе Drilldown ⇨ Logs. В качестве service_name в соответствии с настройками Ally будет указано имя сервера и приписка
Далее нам нужно импортировать дашборд. Я положил его в свой репозиторий grafana-loki, в раздел
Если у вас Loki и Postfix настроены по моим статьям и заметкам, на которые я дал ссылки, то всё должно получиться, потому что все настройки я взял с работающего сервера. Проверил в момент написания заметки. Как это всё выглядит, видно ниже на скриншотах.
Если что-то не работает на дашборде, значит либо лог немного отличается, там локальный парсер прямо в настройках виджетов, либо выборка по меткам не совпадает, если свои метки ставили. Всё это проверяется тут же, в дашборде, в настройках виджетов. Я так всё и правил в изначальном дашборде. У меня после импорта ничего не работало. Поправил и шаблоны парсинга, и метки под свои настройки, добавил ещё один виджет, разделив внешних и внутренних получателей. В итоге всё получилось.
Ниже публикую файлы, которые используются в заметке. Они же продублированы в репозитории.
Подобная настройка максимально простая и быстрая, настраивается буквально за 5 минут по готовым конфигам и шаблонам. Плюс, это всё в формате IaC.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#loki #logs #mailserver #postfix
Напомню, что у меня есть подробная статья про мониторинг Postfix с помощью Zabbix. Там в том числе выполняется и анализ логов, но локально, а в систему мониторинга уходит результат локальной обработки. Сами логи Postfix не хранятся.
Сегодня я рассмотрю другой вариант - непосредственно хранение логов на внешнем сервере Loki, который сам будет парсить данные и выполнять некоторую аналитику. Я выведу на дашборд метрики:
◽️Количество доставленных и отклонённых писем в виде соотношения и временной шкалы
◽️Статистика по доменам внешних получателей писем от нас
◽️Статистика по полученным письмам локальных доменов нашего сервера
◽️Статистика по отклонённым письмам в разрезе ошибок и доменов
Помимо этого Loki автоматически будет парсить поступающие логи, что позволит выполнять группировки по 24 распознанным полям: имя получателя, имя отправителя, домен отправителя, IP адрес, ID сообщения, статусы и т.д.
Данную заметку я пишу на примере реального почтового сервера, который я настроил по этой своей статье. Это важно, так как в разных версиях Postfix немного отличается формат логов. Я за основу взял готовый Dashboard из базы Grafana и подправил его под свою версию сервера и настроек Alloy, которые я возьму из этой заметки. А сам Loki установлен и настроен так же, как тут.
Первым делом устанавливаем Alloy на почтовый сервер с Postfix. Посмотреть установку можно в предыдущей заметке. Для сбора только почтовых логов достаточно такой конфигурации:
loki.write "default" {
endpoint {
url = "http://195.20.47.169:3100/loki/api/v1/push"
}
external_labels = {}
}
local.file_match "postfix" {
path_targets = [{
__address__ = "localhost",
__path__ = "/var/log/mail.log",
instance = constants.hostname,
job = string.format("%s-maillog", constants.hostname),
}]
}
loki.source.file "postfix" {
targets = local.file_match.postfix.targets
forward_to = [loki.write.default.receiver]
}После этого логи сразу потекут в Loki. Их можно смотреть в разделе Drilldown ⇨ Logs. В качестве service_name в соответствии с настройками Ally будет указано имя сервера и приписка
-maillog. В моём случай это будет mail.zeroxzed.ru-maillog. На картинках другое название, но это мне показалось более удачное.Далее нам нужно импортировать дашборд. Я положил его в свой репозиторий grafana-loki, в раздел
grafana/dashboards/, файл Postfix Delivery Status.json. Его нужно скачать и импортировать в Grafana. Во время импорта в качестве источника данных укажите свой Datasource с Loki. Если он не подцепится автоматически, то после импорта зайдите в настройки дашборда, раздел Variables, укажите его явно в переменной DS_LOKI.Если у вас Loki и Postfix настроены по моим статьям и заметкам, на которые я дал ссылки, то всё должно получиться, потому что все настройки я взял с работающего сервера. Проверил в момент написания заметки. Как это всё выглядит, видно ниже на скриншотах.
Если что-то не работает на дашборде, значит либо лог немного отличается, там локальный парсер прямо в настройках виджетов, либо выборка по меткам не совпадает, если свои метки ставили. Всё это проверяется тут же, в дашборде, в настройках виджетов. Я так всё и правил в изначальном дашборде. У меня после импорта ничего не работало. Поправил и шаблоны парсинга, и метки под свои настройки, добавил ещё один виджет, разделив внешних и внутренних получателей. В итоге всё получилось.
Ниже публикую файлы, которые используются в заметке. Они же продублированы в репозитории.
Подобная настройка максимально простая и быстрая, настраивается буквально за 5 минут по готовым конфигам и шаблонам. Плюс, это всё в формате IaC.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#loki #logs #mailserver #postfix
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍66👎1