Я наконец-то закончил обновление статьи про локальный почтовый сервер на базе Postfix и Dovecot:

⇨ Настройка Postfix + Dovecot + Postfixadmin + Roundcube + DKIM на Debian

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

Старую версию статьи под Debian 12 сохранил в виде статической страницы и упаковал в архив. Ссылка в начале новой статьи. Если кто-то по ней настраивал или что-то нужно будет подсмотреть, можете скачать. Я не стал плодить похожие статьи с разными версиями ПО, так как это неудобно, приводит к дублированию информации на сайте и путанице. Удобнее, когда есть одна актуальная статья, на которую можно ссылаться.

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

Можно было бы сразу итоговый вариант настроек дать и всё разом запустить, но это было бы не так понятно. В целом, подобный сервер можно запустить в пару кликов на базе какого-нибудь Mailcow, Mailu, или их аналогов. Почти все сборки бесплатных серверов (и не только бесплатных) сделаны на базе этих же компонентов. Но если вы собираетесь потом эксплуатировать и администрировать этот сервер, то без знания его устройства это будет сложно сделать.

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

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

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

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

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

Решил обновить весь цикл статей про почтовый сервер. Начал с самой актуальной - настройка Fail2Ban для защиты от перебора учёток и прочих паразитных соединений:

⇨ Защита почтового сервера Postfix + Dovecot с помощью Fail2Ban

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

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

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

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

Помню как-то даже шутку придумал:

«Если я усну и проснусь через сто лет и меня спросят, что сейчас настраивают системные администраторы Linux, я отвечу: блокировку SSH с помощью Fail2Ban».

Это придумано в контексте того, что сам я лично для SSH никогда не ставлю Fail2Ban. В этом просто нет большого смысла.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#fail2ban #mailserver #postfix #dovecot

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

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

На поверхности лежат основные минусы этого подхода:

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

➖ Могут быть неочевидны вопросы бэкапа и централизованного управления большой инфраструктурой. Последнее, кстати, актуально. Мне как-то довелось управлять большим количеством ящиков в Google Workspace. Они тогда вроде G-Suite назывались. Не было, к примеру, простой возможности всем добавить какое-то правило сортировки почты. Надо было либо инструкцию пользователям писать, либо в каждый ящик заходить. И таких моментов там много было.

➖ Чаще всего нет инструментов для анализа каких-то непонятных ситуаций. Пользователь может намудрить с правилами и письмо куда-то пропадает. Он жалуется, что почта не ходит. Поди разберись, в чём причина. Либо просто письмо не приходит, или он его сразу удалил. Ты тут можешь только развести руками.

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

❗️Это всё технические моменты. Но есть не менее важные и некоторые другие. Я не раз слышал такое мнение от руководителей и обеспеченных людей. Они не хотят светить свою переписку как личную, так и всей компании, в публичном сервисе, где она наверняка в обязательном порядке анализируется ИИ и подшивается к чему-то.

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

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

☝️Так что вопрос это не такой простой, как может показаться на первый взгляд. И лежит не только в технической плоскости. Активная деловая переписка содержит много различной информации, причём уже в готовом виде. Это не СУБД по модели SaaS, где ещё ковыряться в данных надо. Возможно не стоит её вот так опрометчиво отдавать кому-то. Запустил свой сервер где угодно, настроил Thunderbird пользователям в офисе. И твоя переписка теперь только у тебя. Не такая уж большая переплата за это.

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

#mailserver