Существует простой и эффективный метод борьбы со спамом — Greylisting. Его переводят на русский как серый список. Расскажу вам простыми словами, как он работает, а также поделюсь своим опытом его использования.
Принцип работы Greylisting очень прост. Когда на сервер поступает письмо от нового адресата, с которым он ещё не взаимодействовал, письмо отклоняется с временным кодом ошибки 4ХХ, обычно 450. Согласно rfc5321, отправитель, получив такую ошибку, должен выполнить повторную отправку через некоторое время. В rfc оно указано как не менее 30 минут, если я правильно понял (the retry interval SHOULD be at least 30 minutes). На практике обычно это время меньше. В postfix по умолчанию оно равно 3 минутам.
Вот тут и кроется главная проблема. Не все серверы делают повторную отправку через 3 минуты. Это всё может настраиваться индивидуально, а rfc не указывает конкретные значения. В итоге может так получиться, что пользователь в течении 10-20 минут не сможет получить письмо от нового контрагента, что очень раздражает. Случается такое не часто, но бывает.
Способ реально простой и рабочий. Отсекает спам эффективно, так как спамеры обычно не обрабатывают коды ошибок и не держат у себя очередь, так как это накладно. Рассылка идёт по сотням тысяч адресов с каких-то взломанных машин или временных почтовых серверов. Надо за короткий промежуток времени разослать как можно больше почты, пока тебя не забанили. Поэтому обработкой ошибок обычно не занимаются.
Так что Greylisting очень дешёвый и эффективный способ борьбы со спамом, который не требует особых настроек. Достаточно где-то хранить список всех серверов, с которых вы уже получали почту и принимать от них её сразу. А всем остальным на первый раз выдавать 450 ошибку. Если они повторно делают отправку к вам, то принимается письмо, а сервер добавляется в этот список.
Во многих готовых почтовый сборках этот механизм включён по умолчанию. Например в Iredmail или Mail-in-a-Box. Я лично всегда его отключают, потому что даже задержка письма на 5-10 минут хотя бы раз в месяц вынудит пользователя сообщить поддержке, что с доставкой какие-то проблемы. И надо будет разбираться, объяснять в чём тут дело. Популярна ситуация, когда пользователь разговаривает с кем-то по телефону и тут же обменивается почтой. И письмо не приходит сразу. Для разговора в режиме реального времени задержка в 3 минуты значительна и раздражает. Приходится ждать, обновлять ящик, отправлять ещё раз и т.д.
Если для вас это не критично, то рекомендую обратить внимание на Greylisting. Он один способен отсечь большую часть спама. И не нужно будет разбираться с другими системами, особенно бальными, где надо поначалу тратить время на калибровку системы. Конкретных реализаций подхода Greylisting много. Под каждый почтовый сервер написаны свои. В каких-то сборках это собственным решением реализовано. На Postfix легко гуглится настройка.
#mailserver
Принцип работы Greylisting очень прост. Когда на сервер поступает письмо от нового адресата, с которым он ещё не взаимодействовал, письмо отклоняется с временным кодом ошибки 4ХХ, обычно 450. Согласно rfc5321, отправитель, получив такую ошибку, должен выполнить повторную отправку через некоторое время. В rfc оно указано как не менее 30 минут, если я правильно понял (the retry interval SHOULD be at least 30 minutes). На практике обычно это время меньше. В postfix по умолчанию оно равно 3 минутам.
Вот тут и кроется главная проблема. Не все серверы делают повторную отправку через 3 минуты. Это всё может настраиваться индивидуально, а rfc не указывает конкретные значения. В итоге может так получиться, что пользователь в течении 10-20 минут не сможет получить письмо от нового контрагента, что очень раздражает. Случается такое не часто, но бывает.
Способ реально простой и рабочий. Отсекает спам эффективно, так как спамеры обычно не обрабатывают коды ошибок и не держат у себя очередь, так как это накладно. Рассылка идёт по сотням тысяч адресов с каких-то взломанных машин или временных почтовых серверов. Надо за короткий промежуток времени разослать как можно больше почты, пока тебя не забанили. Поэтому обработкой ошибок обычно не занимаются.
Так что Greylisting очень дешёвый и эффективный способ борьбы со спамом, который не требует особых настроек. Достаточно где-то хранить список всех серверов, с которых вы уже получали почту и принимать от них её сразу. А всем остальным на первый раз выдавать 450 ошибку. Если они повторно делают отправку к вам, то принимается письмо, а сервер добавляется в этот список.
Во многих готовых почтовый сборках этот механизм включён по умолчанию. Например в Iredmail или Mail-in-a-Box. Я лично всегда его отключают, потому что даже задержка письма на 5-10 минут хотя бы раз в месяц вынудит пользователя сообщить поддержке, что с доставкой какие-то проблемы. И надо будет разбираться, объяснять в чём тут дело. Популярна ситуация, когда пользователь разговаривает с кем-то по телефону и тут же обменивается почтой. И письмо не приходит сразу. Для разговора в режиме реального времени задержка в 3 минуты значительна и раздражает. Приходится ждать, обновлять ящик, отправлять ещё раз и т.д.
Если для вас это не критично, то рекомендую обратить внимание на Greylisting. Он один способен отсечь большую часть спама. И не нужно будет разбираться с другими системами, особенно бальными, где надо поначалу тратить время на калибровку системы. Конкретных реализаций подхода Greylisting много. Под каждый почтовый сервер написаны свои. В каких-то сборках это собственным решением реализовано. На Postfix легко гуглится настройка.
#mailserver
Вчера изучал тему веб панелей для почтовых серверов. Сам постоянно использую Roundсube, но хотелось поискать что-то более функциональное. Про SOGo знаю, мне она не нравится. С удивление обнаружил, что проект SquirrelMail всё ещё жив. Не так давно было обновление для поддержки php 8. Этот веб интерфейс я настраивал на первых своих почтовых серверах ещё под Freebsd 6.2, как сейчас помню эту версию.
На глаза попался проект Cypht, который сразу заинтересовал. Это web клиент для imap и rss. Отличительная особенность его в том, что в нём можно подключать много ящиков одновременно, и он умеет выводить письма из них в едином списке. Причём в этом списке можно сразу же отвечать от имени той учётной записи, на которую пришло письмо.
У меня самого очень много почтовых ящиков. Вопрос с чтением почты я решаю пересылкой из этих ящиков на один. В целом, нормально всё работает, но если вдруг какая-то пересылка отвалится, я об этом не узнаю. Так что функционал объединения кучи ящиков в единый веб интерфейс меня заинтересовал.
Я установил и попробовал эту веб панель. Сразу скажу, что интерфейс так себе. Не особо понравился. Но заявленный функционал реализован. Подключил три ящика и 2 rss ленты. Как я и сказал в начале, Cypht поддерживает rss, так что является по сути ещё и читалкой этих лент. При этом он умеет в единый список объединять события как из почты, так и из rss лент.
Проект не сказать, что сильно активный, но тем не менее, обновления выходят уже много лет. В github много issues. То есть люди пользуются и считают его полезным. Я провозился с ним пол дня. Вряд ли сам буду использовать. Помимо почты и rss там ещё можно вести календари, подключать контакты из того же gmail.
Интерфейс мобилен (написан на php, для работы нужна mysql база), так что можно со смартфона смотреть. Эта веб панель наверно будет более актуальна для тех, кто не только читает из кучи ящиков, но ещё и отвечает от них же. Там этот функционал реализован удобно. Либо сразу отвечаешь из общей ленты под конкретным аккаунтом, либо создаёшь новое письмо и выбираешь учётку, от которой оно будет отправлено, как в microsoft outlook.
Хотел поинтересоваться, какая веб панель для работы с почтой вам нравится больше всего?
⇨ Сайт / Исходники / Docker (неофициальный)
#mailserver
На глаза попался проект Cypht, который сразу заинтересовал. Это web клиент для imap и rss. Отличительная особенность его в том, что в нём можно подключать много ящиков одновременно, и он умеет выводить письма из них в едином списке. Причём в этом списке можно сразу же отвечать от имени той учётной записи, на которую пришло письмо.
У меня самого очень много почтовых ящиков. Вопрос с чтением почты я решаю пересылкой из этих ящиков на один. В целом, нормально всё работает, но если вдруг какая-то пересылка отвалится, я об этом не узнаю. Так что функционал объединения кучи ящиков в единый веб интерфейс меня заинтересовал.
Я установил и попробовал эту веб панель. Сразу скажу, что интерфейс так себе. Не особо понравился. Но заявленный функционал реализован. Подключил три ящика и 2 rss ленты. Как я и сказал в начале, Cypht поддерживает rss, так что является по сути ещё и читалкой этих лент. При этом он умеет в единый список объединять события как из почты, так и из rss лент.
Проект не сказать, что сильно активный, но тем не менее, обновления выходят уже много лет. В github много issues. То есть люди пользуются и считают его полезным. Я провозился с ним пол дня. Вряд ли сам буду использовать. Помимо почты и rss там ещё можно вести календари, подключать контакты из того же gmail.
Интерфейс мобилен (написан на php, для работы нужна mysql база), так что можно со смартфона смотреть. Эта веб панель наверно будет более актуальна для тех, кто не только читает из кучи ящиков, но ещё и отвечает от них же. Там этот функционал реализован удобно. Либо сразу отвечаешь из общей ленты под конкретным аккаунтом, либо создаёшь новое письмо и выбираешь учётку, от которой оно будет отправлено, как в microsoft outlook.
Хотел поинтересоваться, какая веб панель для работы с почтой вам нравится больше всего?
⇨ Сайт / Исходники / Docker (неофициальный)
#mailserver
Я неоднократно получал как вопросы, так и запросы на настройку аватарок в почтовых клиентах. Подобные вещи реализованы в популярных почтовых сервисах, типа yandex или gmail. К сожалению, сделать так же у себя не получится.
В почтовых протоколах smtp и imap нет понятия аватар. Соответственно почтовые системы по умолчанию никакие аватары принимать и понимать не могут. Изображения к контактам интерпретируют почтовые клиенты на основе своей базы контактов. Каждый сервис ведёт свою базу контактов и аватарок к ним. Реализация закрыта, так что мы наверняка не может судить откуда они берут картинки. Также нет и доступа к общей базе данных контактов.
Реализовать такое на своём почтовом сервере не представляется возможным, если, конечно, вы не захотите написать свой почтовый клиент и реализовать там эту возможность, как это сделали почтовые гиганты.
#mailserver
В почтовых протоколах smtp и imap нет понятия аватар. Соответственно почтовые системы по умолчанию никакие аватары принимать и понимать не могут. Изображения к контактам интерпретируют почтовые клиенты на основе своей базы контактов. Каждый сервис ведёт свою базу контактов и аватарок к ним. Реализация закрыта, так что мы наверняка не может судить откуда они берут картинки. Также нет и доступа к общей базе данных контактов.
Реализовать такое на своём почтовом сервере не представляется возможным, если, конечно, вы не захотите написать свой почтовый клиент и реализовать там эту возможность, как это сделали почтовые гиганты.
#mailserver
Ребята, час ИКС всё ближе. Яндекс повторно сделал рассылку на тему того, что с 17 апреля почта для домена станет платной для всех аккаунтов, где больше 3-х почтовых ящиков. Надо срочно переезжать, кто не хочет платить. Откладывать нельзя, так как предвижу какие-то ограничения на скачивание почты из ящиков из-за того, что переезжающих будет много и скачать быстро свою почту не получится.
Мне много людей писали в личку, задавали вопросы по поводу переноса, предлагали нанять меня на эту задачу. Всем отказал, так как я полностью трудоустроен и со стороны очень редко беру какие-то заказы. Могу только часовую платную консультацию провести и что-то порекомендовать, рассказать, как лучше и куда переехать в вашем случае.
📌 Могу порекомендовать следующие варианты, от простого к сложному.
1️⃣ Аналогичный сервис от mailru — biz.mail.ru. Пару-тройку месяцев назад я заходил туда и явно видел информацию о том, что есть бесплатный тариф. Сейчас вообще не вижу никакой информации о тарифах и тем более о том, что есть бесплатная версия. Тем не менее видел в отзывах информацию, что почта всё ещё бесплатна. Подтвердите или опровергните те, кто наверняка знают и пользуются этой почтой бесплатно.
2️⃣ Купить любой виртуальный хостинг у крупного хостера. С виртуальным хостингом почти всегда в комплекте идёт возможность создавать и пользоваться почтовыми ящиками. Это самый дешёвый вариант для небольших ящиков, так как оплата на таких тарифах обычно идёт за занимаемое место, а не количество ящиков. Если вы настроите почтовый сервер у себя локально, а этот сервис будете использовать только для пересылки, то вам хватит самого дешёвого тарифа за 100-150 р.
3️⃣ Купить VPS или дедик и развернуть там почтовый сервер из конструктора. Сейчас очень много готовых решений, где вручную нужно будет только DNS записи настроить, а всё остальное будет развёрнуто автоматически. Вот моя публикация с подборкой таких решений. В ней не хватает Mail-in-a-Box, которую обозревал позже. Мне очень интересен сервер Tegu, который хочу развернуть и попробовать. Надеюсь, получится на этой неделе. Напишу статью после тестов.
4️⃣ Настроить свой собственный сервер, например, на базе postfix. Моя свежая и подробная статья. Если внимательно повторите написанное, то всё получится. Получил много подтверждений того, что в статье нет ошибок и по ней получается настроить работающий полнофункциональный почтовый сервер с базовой защитой от спама и веб интерфейсом.
5️⃣ Если вам нужен сервер только для отправки почты с сайта или для рассылок, по советую специализированные решения для этого: Postal и Cuttlefish.
6️⃣ Для админов Windows отдельно порекомендую простой, надёжный и бесплатный сервер hMailServer.
Напомню, что перенести почту можно с помощью программ imapsync и imapcopy. Либо самый простой вариант — в любом imap клиенте подключить 2 почтовых ящика и перенести письма из одного в другой. Рекомендую для этого Thunderbird.
Расскажите, куда сами переехали или будете переезжать. Может я забыл какой-то простой и удобный вариант?
#mailserver
Мне много людей писали в личку, задавали вопросы по поводу переноса, предлагали нанять меня на эту задачу. Всем отказал, так как я полностью трудоустроен и со стороны очень редко беру какие-то заказы. Могу только часовую платную консультацию провести и что-то порекомендовать, рассказать, как лучше и куда переехать в вашем случае.
📌 Могу порекомендовать следующие варианты, от простого к сложному.
1️⃣ Аналогичный сервис от mailru — biz.mail.ru. Пару-тройку месяцев назад я заходил туда и явно видел информацию о том, что есть бесплатный тариф. Сейчас вообще не вижу никакой информации о тарифах и тем более о том, что есть бесплатная версия. Тем не менее видел в отзывах информацию, что почта всё ещё бесплатна. Подтвердите или опровергните те, кто наверняка знают и пользуются этой почтой бесплатно.
2️⃣ Купить любой виртуальный хостинг у крупного хостера. С виртуальным хостингом почти всегда в комплекте идёт возможность создавать и пользоваться почтовыми ящиками. Это самый дешёвый вариант для небольших ящиков, так как оплата на таких тарифах обычно идёт за занимаемое место, а не количество ящиков. Если вы настроите почтовый сервер у себя локально, а этот сервис будете использовать только для пересылки, то вам хватит самого дешёвого тарифа за 100-150 р.
3️⃣ Купить VPS или дедик и развернуть там почтовый сервер из конструктора. Сейчас очень много готовых решений, где вручную нужно будет только DNS записи настроить, а всё остальное будет развёрнуто автоматически. Вот моя публикация с подборкой таких решений. В ней не хватает Mail-in-a-Box, которую обозревал позже. Мне очень интересен сервер Tegu, который хочу развернуть и попробовать. Надеюсь, получится на этой неделе. Напишу статью после тестов.
4️⃣ Настроить свой собственный сервер, например, на базе postfix. Моя свежая и подробная статья. Если внимательно повторите написанное, то всё получится. Получил много подтверждений того, что в статье нет ошибок и по ней получается настроить работающий полнофункциональный почтовый сервер с базовой защитой от спама и веб интерфейсом.
5️⃣ Если вам нужен сервер только для отправки почты с сайта или для рассылок, по советую специализированные решения для этого: Postal и Cuttlefish.
6️⃣ Для админов Windows отдельно порекомендую простой, надёжный и бесплатный сервер hMailServer.
Напомню, что перенести почту можно с помощью программ imapsync и imapcopy. Либо самый простой вариант — в любом imap клиенте подключить 2 почтовых ящика и перенести письма из одного в другой. Рекомендую для этого Thunderbird.
Расскажите, куда сами переехали или будете переезжать. Может я забыл какой-то простой и удобный вариант?
#mailserver
Продолжу тему переезда и переноса почтовых ящиков. А также их бэкапа из облачных сервисов. Ранее я рассматривал инструменты для переноса писем с одного imap ящика в другой. Сейчас расскажу про imap-backup, с помощью которого можно сохранить локально архив почты из любого imap ящика.
Если вам не нужно переносить прямо все ящики, либо всю почту из ящиков, можно перенести только то, что, к примеру, не старше 3-х лет, а всё остальное скачать и положить в архив локально. Потом можно без проблем открыть архив и посмотреть там почту.
Imap-backup умеет скачивать почту по imap и сохранять её локально в формате mbox. Это по сути один большой текстовый файл, где письма идут один за другим. Программа написана на ruby, так что проще всего её поставить через gem. На Debian это выглядит следующим образом:
Теперь можно запустить программу и выполнить первоначальную настройку через консоль:
Либо сразу нарисовать конфиг в формате json и положить его в ~/.imap-backup/config.json. Вот рабочий пример для Яндекса, проверил лично:
Для доступа по imap в ящике нужно создать пароль для приложения. В самих настройках ящика есть инструкция для этого.
Программа выкачивает почту в отдельно созданный каталог для ящика. Каждая папка imap — отдельный файл mbox. Далее эту почту можно подключить к Thunderbird. Для этого надо установить расширение ImportExportTools NG из официального магазина. После установки в разделе Инструменты в самом конце будет раздел ImportExportTools, через который можно выполнить импорт папки mbox.
Я всё проверил лично. Работает хорошо, проблем не возникло. Можно таким образом настроить регулярный бэкап почты из любого почтового ящика, или группы ящиков. Например, того же Gmail. С ним программа тоже работает. Imap-backup — хороший инструмент для массового бэкапа почтовых ящиков облачных сервисов.
#mailserver
Если вам не нужно переносить прямо все ящики, либо всю почту из ящиков, можно перенести только то, что, к примеру, не старше 3-х лет, а всё остальное скачать и положить в архив локально. Потом можно без проблем открыть архив и посмотреть там почту.
Imap-backup умеет скачивать почту по imap и сохранять её локально в формате mbox. Это по сути один большой текстовый файл, где письма идут один за другим. Программа написана на ruby, так что проще всего её поставить через gem. На Debian это выглядит следующим образом:
# apt install rubygems# gem install imap-backupТеперь можно запустить программу и выполнить первоначальную настройку через консоль:
# imap-backup setupЛибо сразу нарисовать конфиг в формате json и положить его в ~/.imap-backup/config.json. Вот рабочий пример для Яндекса, проверил лично:
{ "version": "2.0", "accounts": [ { "username": "zabbix@serveradmin.ru", "password": "topsecretpassword", "local_path": "/root/.imap-backup/zabbix_serveradmin.ru", "folders": [ ], "server": "imap.yandex.ru" } ]}Для доступа по imap в ящике нужно создать пароль для приложения. В самих настройках ящика есть инструкция для этого.
Программа выкачивает почту в отдельно созданный каталог для ящика. Каждая папка imap — отдельный файл mbox. Далее эту почту можно подключить к Thunderbird. Для этого надо установить расширение ImportExportTools NG из официального магазина. После установки в разделе Инструменты в самом конце будет раздел ImportExportTools, через который можно выполнить импорт папки mbox.
Я всё проверил лично. Работает хорошо, проблем не возникло. Можно таким образом настроить регулярный бэкап почты из любого почтового ящика, или группы ящиков. Например, того же Gmail. С ним программа тоже работает. Imap-backup — хороший инструмент для массового бэкапа почтовых ящиков облачных сервисов.
#mailserver
У меня наконец-то дошли руки установить и настроить почтовый сервер Tegu (бесплатную версию). Так что теперь могу поделиться своими впечатлениями и первым опытом работы. Я планирую написать по нему подробную статью, когда немного накопится опыт использования. Когда она выйдет неизвестно, поэтому решил сразу заметку сделать.
✅ Плюсы:
1️⃣ Простая и быстрая установка. Весь сервер это один скомпилированный бинарник, написанный на Go и один конфигурационный файл к нему. Никаких зависимостей от системных библиотек. Весь код реализован самостоятельно. Работает практически на любом линуксе. Скачиваем бинарник, рисуем конфиг, systemd юнит и всё, установка завершена. Обновление — это просто замена бинарника новой версией.
2️⃣ Сервер включает в себя службы smtp, imap и панель управления через веб интерфейс. Это очень удобно по сравнению с традиционными связками, когда надо отдельно ставить smtp, отдельно imap и отдельно какое-то управление. Установка и запуск базового сервера занимает буквально 10 минут, если вы делаете это не первый раз. И уже можно подключаться любым почтовым клиентом. Встроенного веб клиента нет.
3️⃣ В сервере реализована поддержка протокола milter, так что многие привычные службы, которые мы подключали через milter к postfix теоретически можно подключить и здесь. Как на деле это реализовано, надо смотреть и разбираться.
4️⃣ В сервер встроен функционал белых/чёрных спискв IP/email отправителей, технология Greylist, проверка по спискам DNSBL, проверка наличия SPF записи и блокировка в случае отсутствия таковых записей, глобальные правила сортировки и фильтрации, dkim. Также реализована защита от перебора паролей, типа fail2ban.
5️⃣ Сервер поддерживает хранение своего состояния в базе sqlite, а пользователей в json файле (пароли зашифрованы). По мне так это очень удобно для небольших серверов. Нет необходимости поднятия полноценной базы данных. Хранить там всё равно особо нечего и sqlite в этом плане отличное решение.
6️⃣ Для каждого домена можно указывать своё хранилище почты. Удобно для управления многодоменными серверами.
7️⃣ Есть возможность хранить почту в формате Maildir. Это позволяет легко бэкапить или переносить почту между серверами. К примеру, чтобы перенести почту с сервера postfix, достаточно просто скопировать почту из ящиков.
🔴 Минусы:
1️⃣ Малоинформативный лог. По умолчанию пишется в journald, настроек для него практически нет. Я много времени потратил на то, чтобы запустить защищённые соединения. Указал путь к сертификатам let's encrypt, но служба на портах 465 и 993 не запускалась. В логах пусто, ошибок нет. Уже в процессе разбирательства по чисто своей догадке я предположил, что возможно у сервера нет доступа к сертификатам. Tegu запускается от системного пользователя mail. И у него действительно нет доступа к стандартной директории /etc/letsencrypt/live. Когда исправил это, почтовый сервер запустился на указанных портах и шифрованные подключения заработали.
2️⃣ В документации указано, что сервер работает только с доверенными сертификатами, самоподписанные не поддерживаются: "Использование самоподписанных сертификатов вызовет ошибку".
3️⃣ Документация немного сумбурная. Не всё в ней отражено, что-то дублируется в разных статьях (например, установка и ещё одна установка и эксплуатация, где описана настройка кучи веб клиентов, которые к серверу не имеют отношения). Например, у меня не стартовала служба smtp на 25 порту. Оказалось, что надо было создать через веб интерфейс очередь smtp. Для меня это было неочевидно.
💡Впечатление от сервера и его концепции положительные. Мне кажется, разработчики заняли очень удачную нишу. Аналогов просто нет, где можно взять и быстро поднять почтовый сервер с базовым функционалом. Все бесплатные решения — это связки и обвес вокруг postfix + dovecot + БД + dkim + какой-то интерфейс управления. Несмотря на то, что сервер видел в первый раз, я его настроил за пару часов чтения доков. Взял VM: 1 CPU, 1GB памяти 💪🏻.
#mailserver #tegu #отечественное
✅ Плюсы:
1️⃣ Простая и быстрая установка. Весь сервер это один скомпилированный бинарник, написанный на Go и один конфигурационный файл к нему. Никаких зависимостей от системных библиотек. Весь код реализован самостоятельно. Работает практически на любом линуксе. Скачиваем бинарник, рисуем конфиг, systemd юнит и всё, установка завершена. Обновление — это просто замена бинарника новой версией.
2️⃣ Сервер включает в себя службы smtp, imap и панель управления через веб интерфейс. Это очень удобно по сравнению с традиционными связками, когда надо отдельно ставить smtp, отдельно imap и отдельно какое-то управление. Установка и запуск базового сервера занимает буквально 10 минут, если вы делаете это не первый раз. И уже можно подключаться любым почтовым клиентом. Встроенного веб клиента нет.
3️⃣ В сервере реализована поддержка протокола milter, так что многие привычные службы, которые мы подключали через milter к postfix теоретически можно подключить и здесь. Как на деле это реализовано, надо смотреть и разбираться.
4️⃣ В сервер встроен функционал белых/чёрных спискв IP/email отправителей, технология Greylist, проверка по спискам DNSBL, проверка наличия SPF записи и блокировка в случае отсутствия таковых записей, глобальные правила сортировки и фильтрации, dkim. Также реализована защита от перебора паролей, типа fail2ban.
5️⃣ Сервер поддерживает хранение своего состояния в базе sqlite, а пользователей в json файле (пароли зашифрованы). По мне так это очень удобно для небольших серверов. Нет необходимости поднятия полноценной базы данных. Хранить там всё равно особо нечего и sqlite в этом плане отличное решение.
6️⃣ Для каждого домена можно указывать своё хранилище почты. Удобно для управления многодоменными серверами.
7️⃣ Есть возможность хранить почту в формате Maildir. Это позволяет легко бэкапить или переносить почту между серверами. К примеру, чтобы перенести почту с сервера postfix, достаточно просто скопировать почту из ящиков.
🔴 Минусы:
1️⃣ Малоинформативный лог. По умолчанию пишется в journald, настроек для него практически нет. Я много времени потратил на то, чтобы запустить защищённые соединения. Указал путь к сертификатам let's encrypt, но служба на портах 465 и 993 не запускалась. В логах пусто, ошибок нет. Уже в процессе разбирательства по чисто своей догадке я предположил, что возможно у сервера нет доступа к сертификатам. Tegu запускается от системного пользователя mail. И у него действительно нет доступа к стандартной директории /etc/letsencrypt/live. Когда исправил это, почтовый сервер запустился на указанных портах и шифрованные подключения заработали.
2️⃣ В документации указано, что сервер работает только с доверенными сертификатами, самоподписанные не поддерживаются: "Использование самоподписанных сертификатов вызовет ошибку".
3️⃣ Документация немного сумбурная. Не всё в ней отражено, что-то дублируется в разных статьях (например, установка и ещё одна установка и эксплуатация, где описана настройка кучи веб клиентов, которые к серверу не имеют отношения). Например, у меня не стартовала служба smtp на 25 порту. Оказалось, что надо было создать через веб интерфейс очередь smtp. Для меня это было неочевидно.
💡Впечатление от сервера и его концепции положительные. Мне кажется, разработчики заняли очень удачную нишу. Аналогов просто нет, где можно взять и быстро поднять почтовый сервер с базовым функционалом. Все бесплатные решения — это связки и обвес вокруг postfix + dovecot + БД + dkim + какой-то интерфейс управления. Несмотря на то, что сервер видел в первый раз, я его настроил за пару часов чтения доков. Взял VM: 1 CPU, 1GB памяти 💪🏻.
#mailserver #tegu #отечественное
Для тех, кто впервые настраивает веб сервер, бывает странно видеть названия imap папок вида:
◽ .&BB4EQgQ,BEAEMAQyBDsENQQ9BD0ESwQ1-
◽ .&BBoEPgRABDcEOAQ9BDA-
◽ .&BCcENQRABD0EPgQyBDgEOgQ4-
Создаётся впечатление, что с сервером какие-то проблемы.
На самом деле это не проблема. Почему-то исторически сложилось, что названия imap директорий хранятся в кодировке UTF-7. Для англоязычных названий проблем нет, а вот кириллические понять невозможно.
Вы можете воспользоваться любым преобразователем кодировок либо в виде веб сервиса, либо прямо в консоли с помощью
#mailserver
◽ .&BB4EQgQ,BEAEMAQyBDsENQQ9BD0ESwQ1-
◽ .&BBoEPgRABDcEOAQ9BDA-
◽ .&BCcENQRABD0EPgQyBDgEOgQ4-
Создаётся впечатление, что с сервером какие-то проблемы.
На самом деле это не проблема. Почему-то исторически сложилось, что названия imap директорий хранятся в кодировке UTF-7. Для англоязычных названий проблем нет, а вот кириллические понять невозможно.
Вы можете воспользоваться любым преобразователем кодировок либо в виде веб сервиса, либо прямо в консоли с помощью
iconv -f UTF7 -t UTF8. Ещё проще скопировать на почтовый сервер готовый скрипт. И пользоваться им, когда понадобится. Текст можете проверить, там ничего особенного. # git clone https://github.com/Yar4e/lsmaildir# cd lsmaildir# chmod u+x lsmaildir# ./lsmaildir /opt/tegu/mail/zeroxzed.ru/vladimir/.maildir.Отправленные .&BB4EQgQ,BEAEMAQyBDsENQQ9BD0ESwQ1-.Архив .&BBAEQARFBDgEMg-.Корзина .&BBoEPgRABDcEOAQ9BDA-.Черновики .&BCcENQRABD0EPgQyBDgEOgQ4-.Спам .&BCEEPwQwBDw-cur curnew newtmp tmp#mailserver
Расскажу историю про то, как я перенёс почту в отдельно взятой компании с Яндекса. Сразу скажу, что это не описание оптимального варианта, или какая-то рекомендация, как поступать вам. Тут ситуация специфическая. Я просто дам информацию, которая кому-то может оказаться полезной.
В компании есть Windows Server, где установлен Kerio Mailserver. Исторически так сложилось, что через него почта почти никогда не отправлялась напрямую из-за проблем с доставкой, так как компания часто переезжала с места на место в различных промзонах, где нет стабильного интернета и электричества. Иногда это был мобильный интернет.
Последние несколько лет почта работала через Яндекс по следующей схеме. Для всех сотрудников были созданы почтовые ящики. Локальный Kerio Mailserver подключался к этим ящикам и забирал почту к себе по pop3. Сами пользователи подключались к локальному серверу и забирали почту через него. Отправка осуществлялась у пользователей напрямую через Яндекс, хотя с другим почтовым оператором вся отправка централизованно настраивалась тоже через локальный сервер с помощью сервера ретрансляции. Но Яндекс такую работу не поддерживает. Там для каждого пользователя должна быть своя учётная запись.
Схема на самом деле удобная и гибкая. Изначально так настроил не я. Когда впервые увидел, подумал, что как-то сложно всё это настраивать в нескольких местах. С учётом того, что я умею настраивать почтовые сервера и имею большой опыт по их обслуживаю, не оценил решение. Но после парочки переездов и смены почтового оператора понял, что на самом деле это удобно. В ящиках много почты. У кого-то по 50 гигов. Люди привыкли работать в локальных программах, а не через веб интерфейс. У некоторых может быть подключено по 5-7 ящиков. Без локальной программы работать с таким количеством ящиков неудобно.
Встала задача переехать с Яндекса. У компании сайты живут на Masterhost. К услуге виртуального хостинга полагается неограниченное количество почтовых ящиков. Ограничение одно — 7 гигабайт места под почту включены в тарифный план. В итоге я просто создал все ящики в Masterhost (там удобная админка для этого), переключил MX записи на этого провайдера. А в локальном почтовом сервере настроил сбор почты по pop3 вместо Яндекса с Masterhost, и отправку через него же.
Вот и весь переезд. Не нужно ни пользователей трогать, ни почту переносить. Это уже не первый подобный переезд. До Яндекса тоже была платная услуга почты от другого хостера. Для небольших компаний, где есть возможность установить сервер на своё железо, хороший вариант. Не нужно беспокоиться о доставке почты и борьбы со спамом. Это на себя берёт хостер в данном случае за символические 250 р. в месяц — стоимость услуги виртуального хостинга, где живёт сайт.
Подобную схему можно реализовать и с помощью Linux сервера, но будет посложнее. В Kerio Mailserver все настройки делаются мышкой через консоль управления. Это штатный функционал. В Linux придётся настраивать отдельные программы, типа Fetchmail для сбора почты и настройки relay для отправки почты через сторонний сервер.
Подведу итог. Плюсы такой схемы следующие:
➕ вся почта хранится локально, быстрый доступ к объёмным ящикам
➕ удобный бэкап всей почты
➕ нет привязки к ip адресу офиса, легко изменить оператора почты или переехать самим офисом
➕ не нужно самому следить за рейтингом ip адреса и проходимостью почты
➕ антиспам средствами хостера
➕ если у вас проблемы с интернетом, почта накапливается у хостера и не пропадает
Минусы:
➖ более сложная настройка пользователей, их надо создавать два раза — у хостера и локально, настраивать сбор почты
➖ за услугу придётся платить некоторую сумму
➖ нужен свой сервер
#mailserver
В компании есть Windows Server, где установлен Kerio Mailserver. Исторически так сложилось, что через него почта почти никогда не отправлялась напрямую из-за проблем с доставкой, так как компания часто переезжала с места на место в различных промзонах, где нет стабильного интернета и электричества. Иногда это был мобильный интернет.
Последние несколько лет почта работала через Яндекс по следующей схеме. Для всех сотрудников были созданы почтовые ящики. Локальный Kerio Mailserver подключался к этим ящикам и забирал почту к себе по pop3. Сами пользователи подключались к локальному серверу и забирали почту через него. Отправка осуществлялась у пользователей напрямую через Яндекс, хотя с другим почтовым оператором вся отправка централизованно настраивалась тоже через локальный сервер с помощью сервера ретрансляции. Но Яндекс такую работу не поддерживает. Там для каждого пользователя должна быть своя учётная запись.
Схема на самом деле удобная и гибкая. Изначально так настроил не я. Когда впервые увидел, подумал, что как-то сложно всё это настраивать в нескольких местах. С учётом того, что я умею настраивать почтовые сервера и имею большой опыт по их обслуживаю, не оценил решение. Но после парочки переездов и смены почтового оператора понял, что на самом деле это удобно. В ящиках много почты. У кого-то по 50 гигов. Люди привыкли работать в локальных программах, а не через веб интерфейс. У некоторых может быть подключено по 5-7 ящиков. Без локальной программы работать с таким количеством ящиков неудобно.
Встала задача переехать с Яндекса. У компании сайты живут на Masterhost. К услуге виртуального хостинга полагается неограниченное количество почтовых ящиков. Ограничение одно — 7 гигабайт места под почту включены в тарифный план. В итоге я просто создал все ящики в Masterhost (там удобная админка для этого), переключил MX записи на этого провайдера. А в локальном почтовом сервере настроил сбор почты по pop3 вместо Яндекса с Masterhost, и отправку через него же.
Вот и весь переезд. Не нужно ни пользователей трогать, ни почту переносить. Это уже не первый подобный переезд. До Яндекса тоже была платная услуга почты от другого хостера. Для небольших компаний, где есть возможность установить сервер на своё железо, хороший вариант. Не нужно беспокоиться о доставке почты и борьбы со спамом. Это на себя берёт хостер в данном случае за символические 250 р. в месяц — стоимость услуги виртуального хостинга, где живёт сайт.
Подобную схему можно реализовать и с помощью Linux сервера, но будет посложнее. В Kerio Mailserver все настройки делаются мышкой через консоль управления. Это штатный функционал. В Linux придётся настраивать отдельные программы, типа Fetchmail для сбора почты и настройки relay для отправки почты через сторонний сервер.
Подведу итог. Плюсы такой схемы следующие:
➕ вся почта хранится локально, быстрый доступ к объёмным ящикам
➕ удобный бэкап всей почты
➕ нет привязки к ip адресу офиса, легко изменить оператора почты или переехать самим офисом
➕ не нужно самому следить за рейтингом ip адреса и проходимостью почты
➕ антиспам средствами хостера
➕ если у вас проблемы с интернетом, почта накапливается у хостера и не пропадает
Минусы:
➖ более сложная настройка пользователей, их надо создавать два раза — у хостера и локально, настраивать сбор почты
➖ за услугу придётся платить некоторую сумму
➖ нужен свой сервер
#mailserver
Мне посоветовали посмотреть на почтовый сервер Axigen Mail Server, про который я вообще ни разу не слышал. С интересом изучил его, но быстро разочаровался. Это коммерческий продукт с очень ограниченной бесплатной версией: 5 доменов, 5 пользователей, 5 групп. С такими ограничениями этот сервер подходит только для личного использования.
Тем не менее, сервер мне понравился. Разворачивается он очень просто и быстро. Для запуска есть всё, что только можно: deb и rpm пакеты, docker образ, образ VM для VMWare и VirtualBox, Helm чарт для k8s, установщик для Windows.
Я выбрал Docker для запуска. В лучших традициях монолита всё, что нужно для работы, упаковано в один образ. Это просто праздник. Вместо дюжины контейнеров тут только один. Запускаем:
Функционал типичный для личного органайзера:
▪ почта
▪ календарь
▪ адресная книга
▪ планировщик дел
▪ заметки
Отдельно хочу отметить веб интерфейс. Он удобный, шустрый, приятный для глаза. Лично мне хотелось бы примерно таким видеть веб интерфейс для работы с почтой.
Решил сделать заметку про этот почтовый сервер, потому что понравился веб интерфейс. Может кому-то тоже приглянется, и он выберет себе этот инструмент для личного использования в качестве персональной почты и всех остальных сервисов. Удобно, когда всё это интегрировано в единую систему. Из письма сразу же можно сделать заметку или задачу. У меня заметки, календарь, почта, задачи — разные сервисы. И это неудобно. А тут всё в одном месте.
⇨ Сайт / Demo
#mailserver #заметки
Тем не менее, сервер мне понравился. Разворачивается он очень просто и быстро. Для запуска есть всё, что только можно: deb и rpm пакеты, docker образ, образ VM для VMWare и VirtualBox, Helm чарт для k8s, установщик для Windows.
Я выбрал Docker для запуска. В лучших традициях монолита всё, что нужно для работы, упаковано в один образ. Это просто праздник. Вместо дюжины контейнеров тут только один. Запускаем:
# docker run --name=axigen -dt -v ~/axigen_var:/axigen/var \-p 443:443 -p 9443:9443 \-p 993:993 -p 995:995 \-p 25:25 -p 465:465 \-p 9000:9000 -p 7000:7000 axigen/axigenФункционал типичный для личного органайзера:
▪ почта
▪ календарь
▪ адресная книга
▪ планировщик дел
▪ заметки
Отдельно хочу отметить веб интерфейс. Он удобный, шустрый, приятный для глаза. Лично мне хотелось бы примерно таким видеть веб интерфейс для работы с почтой.
Решил сделать заметку про этот почтовый сервер, потому что понравился веб интерфейс. Может кому-то тоже приглянется, и он выберет себе этот инструмент для личного использования в качестве персональной почты и всех остальных сервисов. Удобно, когда всё это интегрировано в единую систему. Из письма сразу же можно сделать заметку или задачу. У меня заметки, календарь, почта, задачи — разные сервисы. И это неудобно. А тут всё в одном месте.
⇨ Сайт / Demo
#mailserver #заметки
Дам маленький совет по настройке почтового сервера. Мне задали вопрос в комментариях к статье, который напомнил об одной небольшой ошибке. Хочу вас предостеречь от неё.
Как-то раз в одной компании настраивал локальный почтовый сервер. Развернул привычную связку на базе postfix + dovecot и сделал веб интерфейс roundcube. Настроил всё это на одном сервере. Для простоты настройки, сделал доменное имя сервера mail.example.com и для настройки почтовых клиентов, и для веб интерфейса. Сотрудники пользовались и тем, и другим, в зависимости от личных предпочтений. Доступ был из локальной сети.
Со временем появилась необходимость убрать веб интерфейс с почтового сервера на отдельный веб сервер. Парк сервисов и серверов увеличился, захотелось всё упорядочить. В общем случае я рекомендую веб интерфейс настраивать отдельно, не на самом почтовом сервере.
В итоге возникла проблема с тем, что все привыкли к адресу веб интерфейса mail.example.com, который резолвится в IP адрес почтового сервера, а веб сервер имеет другой IP. Пришлось сделать отдельное доменное имя для веб интерфейса - webmail.example.com, а на почтовом сервере оставить nginx с проксированием запросов к mail.example.com на новый веб сервер.
В целом, это некритичная мелочь, но всё равно неудобство. Лучше для почтового сервера выделить отдельное доменное имя и больше его нигде не использовать. Одна виртуалка, один сервис, одно доменное имя. Когда настраиваешь, думаешь, зачем заморачиваться с разными именами. Разные настройки, разные сертификаты получать и т.д. Удобно же, когда всё с одним именем. А на самом деле неудобно. Потом больше времени потеряешь, чтобы разделить сервисы.
#mailserver
Как-то раз в одной компании настраивал локальный почтовый сервер. Развернул привычную связку на базе postfix + dovecot и сделал веб интерфейс roundcube. Настроил всё это на одном сервере. Для простоты настройки, сделал доменное имя сервера mail.example.com и для настройки почтовых клиентов, и для веб интерфейса. Сотрудники пользовались и тем, и другим, в зависимости от личных предпочтений. Доступ был из локальной сети.
Со временем появилась необходимость убрать веб интерфейс с почтового сервера на отдельный веб сервер. Парк сервисов и серверов увеличился, захотелось всё упорядочить. В общем случае я рекомендую веб интерфейс настраивать отдельно, не на самом почтовом сервере.
В итоге возникла проблема с тем, что все привыкли к адресу веб интерфейса mail.example.com, который резолвится в IP адрес почтового сервера, а веб сервер имеет другой IP. Пришлось сделать отдельное доменное имя для веб интерфейса - webmail.example.com, а на почтовом сервере оставить nginx с проксированием запросов к mail.example.com на новый веб сервер.
В целом, это некритичная мелочь, но всё равно неудобство. Лучше для почтового сервера выделить отдельное доменное имя и больше его нигде не использовать. Одна виртуалка, один сервис, одно доменное имя. Когда настраиваешь, думаешь, зачем заморачиваться с разными именами. Разные настройки, разные сертификаты получать и т.д. Удобно же, когда всё с одним именем. А на самом деле неудобно. Потом больше времени потеряешь, чтобы разделить сервисы.
#mailserver
Я неоднократно получал вопрос от тех, кто настраивал почтовый сервер по моей статье, о том, как закрыть почтовые алиасы от спама. Поясню, о чём идёт речь.
Допустим, у вас есть почтовый алиас all@firma.ru, куда входят все сотрудники компании. Их может быть очень много. Подобные алиасы удобно использовать для рассылок внутри компании. Обычно делаю общий алиас для всей компании и для каждого отдела. Остальное уже по потребностям.
Подобные адреса очень удобно использовать спамерам. Отправил одно письмо на all@firma.ru и его получили все сотрудники. Логично было бы ограничить возможность отправки на эти адреса. Я в своё время сам разбирал эту задачу и придумал решение. Нигде его не записал, поэтому каждый раз приходилось вспоминать, как я делал. Так что решил хотя бы заметкой оформить.
Чем мне нравится postfix, так это своей гибкостью и механизмом restrictions, на основе которых можно много всего придумать. Я задачу решил так. Взял параметр smtpd_recipient_restrictions и добавил туда дополнительную проверку:
Это строки из конфигурационного файла postfix main.cf. Текстовый файл maillist_access выглядит примерно так:
Одна строка, один адрес.
Суть тут в чём. Мы в ограничениях получателя указываем, что люди из mynetworks и sasl_authenticated не имеют никаких ограничений на отправку. Это все люди из белых списков локальных сетей (не рекомендую их использовать, только в крайних случаях) и прошедшие аутентификацию, то есть наши сотрудники и пользователи почтового сервера. А все остальные попадают на проверку check_recipient_access, где в файле указано действие для получателя all@firma.ru — давать REJECT. Вот и всё.
Основное неудобство в том, что файл maillist_access придётся заполнять вручную. Если это критично, то можно и автоматизировать каким-то образом. Например, настроить проверку из базы mysql, а там завести какую-то отдельную таблицу для таких алиасов, в которую по какому-то признаку скрипт будет перетаскивать записи из общей таблицы алиасов. Например, по наличию какого-то слова в описании. У меня не было задачи с автоматизацией, поэтому не занимался вопросом. Массовых алиасов не так много, можно и вручную один раз составить список.
Возможно есть какое-то другое решение этой задачи, может быть проще и удобнее. Я настроил так и везде использовал.
#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
Server Admin
Настройка почтового сервера на Debian: postfix + dovecot + web...
Подробная пошаговая установка и настройка почтового сервера на Debian (postfix + dovecot): от подготовки DNS записей до запуска служб.
Я всегда на одиночных веб серверах использую для отправки почты локальный 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
На одном из почтовых серверов попросили увеличить лимит на размер вложений. Сказали, что 10 Мб им не хватает. Немного удивился, потому что по умолчанию ставлю лимит на размер письма 20 Мб. Считаю это универсальным размером. Разрешение пересылки больших файлов без квот на почтовые ящики очень быстро приводит к разрастанию почтовой базы. Особенно, когда кто-то начинает макеты, презентации и прочие большие файлы по почте ежедневно гонять.
Сходил, проверил. Ограничение действительно стояло 20 Мб. Смысл тут в том, что итоговый размер письма может быть существенно больше, чем объём вложения. Всё дело в кодировании вложений для пересылки в письме. Они передаются как часть письма в виде печатных символов стандартной кодовой таблицы ASCII.
Для кодирования вложений в электронной почте обычно используют методы base64 и quoted-printable, описанные в стандарте MIME. Их там больше представлено, но насколько я знаю, в современной почте используют именно эти два. При кодировании по методу base64, а чаще всего используется именно он, получается в среднем увеличение размера вложения в 1,3 раза. Но бывает и значительно больше. Это зависит от особенностей исходного файла и метода кодирования. При использовании quoted-printable увеличение размера может доходить до 3-х раз.
Посмотреть информацию о вложении и методе кодирования можно, сохранив письмо и открыв любым текстовым редактором. Там будут примерно такие заголовки:
Это кодированный pdf файл, который в исходном тексте письма представлен в виде ASCII символов.
Так что когда ставите ограничение на размер письма, имейте ввиду, что этот размер может существенно отличаться от итогового размера вложения, которое сможет пролезть в этот лимит.
#mailserver
Сходил, проверил. Ограничение действительно стояло 20 Мб. Смысл тут в том, что итоговый размер письма может быть существенно больше, чем объём вложения. Всё дело в кодировании вложений для пересылки в письме. Они передаются как часть письма в виде печатных символов стандартной кодовой таблицы ASCII.
Для кодирования вложений в электронной почте обычно используют методы base64 и quoted-printable, описанные в стандарте MIME. Их там больше представлено, но насколько я знаю, в современной почте используют именно эти два. При кодировании по методу base64, а чаще всего используется именно он, получается в среднем увеличение размера вложения в 1,3 раза. Но бывает и значительно больше. Это зависит от особенностей исходного файла и метода кодирования. При использовании quoted-printable увеличение размера может доходить до 3-х раз.
Посмотреть информацию о вложении и методе кодирования можно, сохранив письмо и открыв любым текстовым редактором. Там будут примерно такие заголовки:
Mime-Version: 1.0Content-Type: application/pdf; name="file_credit50198.pdf"Content-Transfer-Encoding: Base64Content-Disposition: attachment; filename="file_credit50198.pdf"Это кодированный pdf файл, который в исходном тексте письма представлен в виде ASCII символов.
Так что когда ставите ограничение на размер письма, имейте ввиду, что этот размер может существенно отличаться от итогового размера вложения, которое сможет пролезть в этот лимит.
#mailserver
Тема мониторинга imap сервера Dovecot всегда обходила меня стороной. Я даже и не знал, что там есть встроенный модуль, который умеет отдавать кучу своих метрик. Не видел особой надобности. Я всегда настраивал fail2ban на перебор учёток Dovecot и мониторинг доступности TCP портов службы. В общем случае мне этого достаточно.
На днях читал новость про обновления в очередной новой версии Dovecot и увидел там изменения в модуле статистики. Заинтересовался и решил изучить его. Оказалось, там всё не так просто, как думалось на первый взгляд. Ожидал там увидеть что-то типа того, что есть в статистике Nginx или Php-fpm. А на самом деле в Dovecot очень много всевозможных метрик и их представлений: в линейных, логарифмических, средних, перцинтильных видах. Плюс фильтры, наборы метрик и т.д. Постараюсь кратко саму суть рассказать. А позже, скорее всего, сделаю небольшой шаблон для Zabbix и настрою мониторинг.
Включаем мониторинг и добавляем некоторый набор метрик, который описывает документация, как пример. Добавляем в конфиг Dovecot:
Перезапускаем Dovecot. Метрики можно увидеть по HTTP на порту сервера 9900 (не забудьте настроить ограничение на firewall) или в консоли:
Описание увиденных полей смотрите в документации, в разделе listing-statistic. Все метрики, что не count, выводятся в микросекундах. Я долго не мог понять, что это за огромные числа и зачем они нужны, пока не нашёл описание в документации.
В данном примере мы вывели статистику по успешным и неуспешным аутентификациям, по всем imap и smtp (не понял, что это за smtp метрики, у меня они по нулям) командам, и по успешным доставкам почты в ящики. Полный список событий, которые можно выводить, смотрите в разделе Events. А возможности фильтрации в Event Filtering. В принципе, тут будет вся информация по поводу метрик и их вывода.
Я посмотрел все возможные метрики и прикинул, что реально полезных, за которыми стоит следить, не так много. Перечислю их:
1️⃣ Uptime сервера. Выводится по умолчанию, отдельно настраивать эту метрику не надо. Соответственно, можно делать триггер на перезапуск сервера.
2️⃣ Количество успешных и неудачных аутентификаций. Причём интересны не абсолютные значения, а изменение в минуту. Сделать триггер на превышение среднего значения, например, в 1,5-2 раза. Если у вас резко выросли аутентификации, то, возможно, кто-то наплодил ящиков и заходит в них. А если много неудачных попыток, то, возможно, fail2ban сломался и начался подбор паролей.
3️⃣ Число успешных доставок почты. Если резво выросло число доставленных писем на каком-то большой интервале, то это повод обратить внимание. Интервал надо брать побольше, чем минута, иначе на какие-то легитимные рассылки будет реакция. Взять, думаю, надо интервал 30-60 минут и сравнивать изменения на нём. Можно и накопительную метрику сделать за сутки, чтобы быстро оценить количество входящей почты.
Вот, в принципе, и всё. Остальные метрики это уже тонкая настройка отдельных служб или слежение за производительностью. Dovecot умеет считать выполнение в микросекундах каждой своей команды и выводить min, max, avg, median, персинтили. Можно очень гибко следить за производительностью в разрезе отдельной imap команды, если для вас это важно.
#dovecot #mailserver #мониторинг
На днях читал новость про обновления в очередной новой версии Dovecot и увидел там изменения в модуле статистики. Заинтересовался и решил изучить его. Оказалось, там всё не так просто, как думалось на первый взгляд. Ожидал там увидеть что-то типа того, что есть в статистике Nginx или Php-fpm. А на самом деле в Dovecot очень много всевозможных метрик и их представлений: в линейных, логарифмических, средних, перцинтильных видах. Плюс фильтры, наборы метрик и т.д. Постараюсь кратко саму суть рассказать. А позже, скорее всего, сделаю небольшой шаблон для Zabbix и настрою мониторинг.
Включаем мониторинг и добавляем некоторый набор метрик, который описывает документация, как пример. Добавляем в конфиг Dovecot:
service stats { inet_listener http { port = 9900 }}metric auth_success { filter = event=auth_request_finished AND success=yes}metric auth_failures { filter = event=auth_request_finished AND NOT success=yes}metric imap_command { filter = event=imap_command_finished group_by = cmd_name tagged_reply_state}metric smtp_command { filter = event=smtp_server_command_finished group_by = cmd_name status_code duration:exponential:1:5:10}metric mail_delivery { filter = event=mail_delivery_finished group_by = duration:exponential:1:5:10}Перезапускаем Dovecot. Метрики можно увидеть по HTTP на порту сервера 9900 (не забудьте настроить ограничение на firewall) или в консоли:
# doveadm -f table stats dumpОписание увиденных полей смотрите в документации, в разделе listing-statistic. Все метрики, что не count, выводятся в микросекундах. Я долго не мог понять, что это за огромные числа и зачем они нужны, пока не нашёл описание в документации.
В данном примере мы вывели статистику по успешным и неуспешным аутентификациям, по всем imap и smtp (не понял, что это за smtp метрики, у меня они по нулям) командам, и по успешным доставкам почты в ящики. Полный список событий, которые можно выводить, смотрите в разделе Events. А возможности фильтрации в Event Filtering. В принципе, тут будет вся информация по поводу метрик и их вывода.
Я посмотрел все возможные метрики и прикинул, что реально полезных, за которыми стоит следить, не так много. Перечислю их:
1️⃣ Uptime сервера. Выводится по умолчанию, отдельно настраивать эту метрику не надо. Соответственно, можно делать триггер на перезапуск сервера.
2️⃣ Количество успешных и неудачных аутентификаций. Причём интересны не абсолютные значения, а изменение в минуту. Сделать триггер на превышение среднего значения, например, в 1,5-2 раза. Если у вас резко выросли аутентификации, то, возможно, кто-то наплодил ящиков и заходит в них. А если много неудачных попыток, то, возможно, fail2ban сломался и начался подбор паролей.
3️⃣ Число успешных доставок почты. Если резво выросло число доставленных писем на каком-то большой интервале, то это повод обратить внимание. Интервал надо брать побольше, чем минута, иначе на какие-то легитимные рассылки будет реакция. Взять, думаю, надо интервал 30-60 минут и сравнивать изменения на нём. Можно и накопительную метрику сделать за сутки, чтобы быстро оценить количество входящей почты.
Вот, в принципе, и всё. Остальные метрики это уже тонкая настройка отдельных служб или слежение за производительностью. Dovecot умеет считать выполнение в микросекундах каждой своей команды и выводить min, max, avg, median, персинтили. Можно очень гибко следить за производительностью в разрезе отдельной imap команды, если для вас это важно.
#dovecot #mailserver #мониторинг
Я написал очень подробный обзор нового почтового сервера от ГК Астра — RuPost:
⇨ Установка и настройка почтового сервера RuPost
Описал основные возможности, сделал пошаговую инструкцию по базовой настройке, подключился различными клиентами. Статья позволит получить общее представление, что это за система, из чего состоит и как с ней работать. В статье много пояснений и картинок для этого.
Кратко скажу следующее:
▪ RuPost построен на базе open source решений: haproxy, postfix, dovecot, sogo и др.
▪ Установка в несколько действий в консоли (установка deb пакета), управление в браузере через самописную админку.
▪ Поддерживается только ОС Astra 1.7.
▪ Интеграция и одновременная работа с несколькими службами каталогов – ALD Pro, Active Directory, FreeIPA.
▪ Почта хранится в формате maildir.
▪ Есть возможность организовать HA cluster.
▪ Настройка системы выполняется на основе шаблонов конфигураций, которые можно готовить заранее, сохранять, выгружать. Есть несколько готовых шаблонов от разработчиков. Формат шаблонов YAML.
▪ RuPost поддерживает общие адресные книги и календари.
▪ Есть механизм миграции с сервера Microsoft Exchange, есть плагин для MS Outlook для работы с календарями и адресными книгами в RuPost. Есть механизм работы одновременно с Exchange, чтобы выполнить поэтапный переход от одного сервера к другому.
Если всё аккуратно настроить, то получается удобный почтовый сервер с автоматической настройкой пользователей. Я проверял на примере Active Directory. Интеграция настраивается легко и быстро. Потом доменный пользователь без проблем запускает клиента, получает все настройки автоматически и работает с почтой через встроенную аутентификацию.
❗️Сразу скажу, что цен в открытом доступе нет и мне их не сообщили. Только по запросу. Так что обсуждать их не представляется возможным. Лицензирование по конечным пользователям. Сколько пользователей, столько надо лицензий. Сами сервера и подключения к ним не лицензируются.
#mailserver #отечественное
⇨ Установка и настройка почтового сервера RuPost
Описал основные возможности, сделал пошаговую инструкцию по базовой настройке, подключился различными клиентами. Статья позволит получить общее представление, что это за система, из чего состоит и как с ней работать. В статье много пояснений и картинок для этого.
Кратко скажу следующее:
▪ RuPost построен на базе open source решений: haproxy, postfix, dovecot, sogo и др.
▪ Установка в несколько действий в консоли (установка deb пакета), управление в браузере через самописную админку.
▪ Поддерживается только ОС Astra 1.7.
▪ Интеграция и одновременная работа с несколькими службами каталогов – ALD Pro, Active Directory, FreeIPA.
▪ Почта хранится в формате maildir.
▪ Есть возможность организовать HA cluster.
▪ Настройка системы выполняется на основе шаблонов конфигураций, которые можно готовить заранее, сохранять, выгружать. Есть несколько готовых шаблонов от разработчиков. Формат шаблонов YAML.
▪ RuPost поддерживает общие адресные книги и календари.
▪ Есть механизм миграции с сервера Microsoft Exchange, есть плагин для MS Outlook для работы с календарями и адресными книгами в RuPost. Есть механизм работы одновременно с Exchange, чтобы выполнить поэтапный переход от одного сервера к другому.
Если всё аккуратно настроить, то получается удобный почтовый сервер с автоматической настройкой пользователей. Я проверял на примере Active Directory. Интеграция настраивается легко и быстро. Потом доменный пользователь без проблем запускает клиента, получает все настройки автоматически и работает с почтой через встроенную аутентификацию.
❗️Сразу скажу, что цен в открытом доступе нет и мне их не сообщили. Только по запросу. Так что обсуждать их не представляется возможным. Лицензирование по конечным пользователям. Сколько пользователей, столько надо лицензий. Сами сервера и подключения к ним не лицензируются.
#mailserver #отечественное
Server Admin
Установка и настройка почтового сервера RuPost
Пошаговое руководство по установке и настройке почтового сервера RuPost, в том числе подключение клиентов, календарей, адресных книг.
Вчера вечером проскочила интересная новость на opennet. Я их обычно не комментирую, если они напрямую не касаются меня. В данном случае это не так. Компания Nextcloud GmbH объявила о присоединении почтового клиента Roundcube. Я этот веб клиент использую по умолчанию для всех настроенных почтовых серверов последние лет 10. Может даже больше. До этого пользовался Squirrelmail. Roundcube один из самых популярных, если не самый популярный, автономный веб клиент для почтовых серверов.
Новость на Opennet:
⇨ https://www.opennet.ru/opennews/art.shtml?num=60197
Оригинал:
⇨ https://nextcloud.com/blog/open-source-email-pioneer-roundcube-comes-aboard-nextcloud/
Что по факту будет, пока не понятно. Заявляют, что веб клиент так и будет обособленным, развитие продолжится, команда останется и даже увеличится, слияния кодовых баз не будет. Тогда не понятно, зачем покупали. Надеюсь, что продукт получит новый виток развития, а не заглохнет, как конкурент собственной разработки Nextcloud Mail.
Я ещё почему обратил внимание и подсветил эту новость. В opennet показали недавние проблемы с безопасностью у Roundcube. Там регулярно находят критические уязвимости. Я очень не люблю оставлять веб почту в открытый доступ. Это всегда риск её компрометации. А если начинаешь ограничивать доступ, то сильно падает удобство использования.
Если в условном postfix и dovecot критические уязвимости я вообще не припоминаю, и их можно спокойно оставлять в открытом доступе, то с веб клиентами это не так. C Roundcube всё время приходится следить за обновлениями и своевременно обновлять. Если есть возможность, я закрываю доступ к веб почте либо vpn, либо basic_auth. Пользователям это не нравится. Иногда руководство в приказном порядке настаивает на открытом прямом доступе, принимая риски.
В общем, если у вас веб почта в открытом доступе, уделяйте ей пристальное внимание и по возможности изолируйте от остальных сервисов. Это прям реальная дыра в инфраструктуру. Почтовые сервера чаще всего компрометируют через веб клиенты.
#mailserver
Новость на Opennet:
⇨ https://www.opennet.ru/opennews/art.shtml?num=60197
Оригинал:
⇨ https://nextcloud.com/blog/open-source-email-pioneer-roundcube-comes-aboard-nextcloud/
Что по факту будет, пока не понятно. Заявляют, что веб клиент так и будет обособленным, развитие продолжится, команда останется и даже увеличится, слияния кодовых баз не будет. Тогда не понятно, зачем покупали. Надеюсь, что продукт получит новый виток развития, а не заглохнет, как конкурент собственной разработки Nextcloud Mail.
Я ещё почему обратил внимание и подсветил эту новость. В opennet показали недавние проблемы с безопасностью у Roundcube. Там регулярно находят критические уязвимости. Я очень не люблю оставлять веб почту в открытый доступ. Это всегда риск её компрометации. А если начинаешь ограничивать доступ, то сильно падает удобство использования.
Если в условном postfix и dovecot критические уязвимости я вообще не припоминаю, и их можно спокойно оставлять в открытом доступе, то с веб клиентами это не так. C Roundcube всё время приходится следить за обновлениями и своевременно обновлять. Если есть возможность, я закрываю доступ к веб почте либо vpn, либо basic_auth. Пользователям это не нравится. Иногда руководство в приказном порядке настаивает на открытом прямом доступе, принимая риски.
В общем, если у вас веб почта в открытом доступе, уделяйте ей пристальное внимание и по возможности изолируйте от остальных сервисов. Это прям реальная дыра в инфраструктуру. Почтовые сервера чаще всего компрометируют через веб клиенты.
#mailserver
Для тех, кто сам настраивает и обслуживает почтовые сервера, хочу предложить удобный инструмент для диагностики - Swaks (Swiss Army Knife for SMTP). В нём нет чего-то особенного, что вы не смогли бы выполнить с помощью прямых запросов через telnet. Но со swaks удобнее, быстрее и проще, и при этом вы видите полный лог общения с почтовым сервером, как если бы вы с ним общались по telnet.
Утилита есть в стандартных репозиториях популярных систем, так что с установкой никаких проблем:
Можете сразу же проверить свой сервер на возможность отправки сообщений без аутентификации:
Корректно настроенный сервер должен вернуть ошибку, причём её код будет зависеть от конкретных настроек почтового сервера. А вот реальная отправка письма с аутентификацией. Пароль будет запрошен в консоли:
С помощью похожего запроса можно удобно проверить поддерживаемые методы аутентификации. Например, CRAM-MD5:
Сервер ответил, что подобный механизм аутентификации не поддерживает.
Если не хочется каждый раз указывать данные аутентификации, их можно добавить в файл
Чтобы программа приняла этот файл, у него должен быть доступ только для пользователя, от которого вы запускаете программу.
В качестве тела письма можно использовать текстовый файл. Это удобно, если нужно проверить работу антивируса или антиспама. К примеру, берём файл EICAR-Test-File, на который все антивирусы дают реакцию, как на вирус, и отправляем его содержимое письмом:
Gmail не принял письмо: "552 5.7.0 This message was blocked because its content presents a potential security issue."
Тело письма можно и сразу в консоли передать через ключ
В общем, инструмент простой, универсальный, интуитивно понятный. Автор поддерживает и регулярно обновляет. Можно использовать и в каких-то велосипедах на bash. Swaks умеет работать через различные прокси, использовать tls сертификаты с выбором шифров и некоторых настроек.
⇨ Исходники
#mailserver
Утилита есть в стандартных репозиториях популярных систем, так что с установкой никаких проблем:
# apt install swaksМожете сразу же проверить свой сервер на возможность отправки сообщений без аутентификации:
# swaks --to user@example.com --server mail.example.netКорректно настроенный сервер должен вернуть ошибку, причём её код будет зависеть от конкретных настроек почтового сервера. А вот реальная отправка письма с аутентификацией. Пароль будет запрошен в консоли:
# swaks --to zeroxzed@gmail.com --from vladimir@zeroxzed.ru --auth PLAIN --auth-user vladimir@zeroxzed.ru --server mail.zeroxzed.ruС помощью похожего запроса можно удобно проверить поддерживаемые методы аутентификации. Например, CRAM-MD5:
# swaks --to zeroxzed@gmail.com --from vladimir@zeroxzed.ru --auth CRAM-MD5 --auth-user vladimir@zeroxzed.ru --server mail.zeroxzed.ru=== Trying mail.zeroxzed.ru:25...=== Connected to mail.zeroxzed.ru.<- 220 mail.zeroxzed.ru ESMTP -> EHLO debian11.homelab.local<- 250-mail.zeroxzed.ru<- 250-8BITMIME<- 250-SIZE 31457280<- 250-AUTH PLAIN LOGIN<- 250-STARTTLS<- 250 PIPELINING*** Auth not attempted, requested type not available -> QUIT<- 221 GoodbyeСервер ответил, что подобный механизм аутентификации не поддерживает.
Если не хочется каждый раз указывать данные аутентификации, их можно добавить в файл
.netrc. Это тот же файл, что поддерживает и curl. Формат его такой:machine mail.server.ru login root@server.ru password password123Чтобы программа приняла этот файл, у него должен быть доступ только для пользователя, от которого вы запускаете программу.
В качестве тела письма можно использовать текстовый файл. Это удобно, если нужно проверить работу антивируса или антиспама. К примеру, берём файл EICAR-Test-File, на который все антивирусы дают реакцию, как на вирус, и отправляем его содержимое письмом:
# wget http://eicar.eu/eicar.com.txt# swaks --to zeroxzed@gmail.com --from vladimir@zeroxzed.ru --auth PLAIN --auth-user vladimir@zeroxzed.ru --server mail.zeroxzed.ru --attach - --suppress-data <eicar.com.txtGmail не принял письмо: "552 5.7.0 This message was blocked because its content presents a potential security issue."
Тело письма можно и сразу в консоли передать через ключ
--body 'foo', тему через --header 'Subject: foo'. Можно и случайные заголовки добавлять примерно так: --header-X-Test "test email". В общем, инструмент простой, универсальный, интуитивно понятный. Автор поддерживает и регулярно обновляет. Можно использовать и в каких-то велосипедах на bash. Swaks умеет работать через различные прокси, использовать tls сертификаты с выбором шифров и некоторых настроек.
⇨ Исходники
#mailserver
Я привык вместе с почтовыми серверами настраивать веб интерфейс на базе RoundCube. Простой и удобный интерфейс, написанный на php. Основной его минус - он почти не развивался последние лет 10. Недавно его под своё крыло взяла Nextcloud GmbH и пообещала добавить разработчиков, чтобы оживить панельку и вдохнуть в неё новую жизнь. Времени прошло немного, так что каких-то изменений пока нет. Выкатили один релиз с исправлением известных ошибок.
Много раз видел рекомендации на SnappyMail, это форк RainLoop, который больше не развивается. Решил посмотреть на SnappyMail и подключил к одному из почтовых серверов. Напишу то, на что обратил внимание сам по сравнению с RoundCube:
🔹SnappyMail имеет очень простой и быстрый веб интерфейс. Я, честно говоря, прям кайфую, когда вижу лёгкие и быстрые интерфейсы. Сейчас это редкость. Не сказать, что RoundCube тяжёлый, но SnappyMail легче и отзывчивее.
🔹Если вам не нужна общая адресная книга, то для работы SnappyMail не нужна СУБД. Она все настройки хранит в файлах. Написана тоже на php, так что для установки достаточно просто исходники положить в директорию веб сервера. Все дальнейшие настройки через веб интерфейс. Не нужно руками править конфиги. В RoundCube придётся по конфигам полазить, чтобы настроить.
🔹Как и RoundCube, SnappyMail поддерживает работу фильтров sieve. Из коробки стандартная тема поддерживает мобильные устройства.
🔹В SnappyMail по умолчанию любой пользователь может настраивать несколько почтовых ящиков, подключенных к его аккаунту.
🔹Для SnappyMail, как и RoundCube, есть много дополнительных плагинов. Но в отличие от круглого куба, в Snappy вся установка и настройка выполняется через веб интерфейс администратора. Не надо руками качать плагины и править конфиги. Это очень удобно. Набор плагинов тоже понравился.
🔹У SnappyMail есть готовые фильтры для Fail2ban, которые пресекают перебор учёток через веб интерфейс.
В общем и целом, ничего особенного у SnappyMail я не увидел, но по совокупности небольших улучшений он выглядит более простым и удобным в установке и настройке. Плюс, мне внешний вид темы по умолчанию понравился больше в SnappyMail. Он более минималистичный и компактный.
Единственное, что не понравилось - не увидел в SnappyMail плагин, который позволяет пользователю самостоятельно поставить отбойник, когда он уходит в отпуск. В RoundCube я в обязательном порядке его ставлю, пользователи активно используют. Можно это реализовывать с помощью фильтров, но отдельный плагин только под это дело удобнее.
❗️Если кто-то будет прямо сейчас пробовать, имейте ввиду, что в последних двух релизах есть баг, связанный с начальной настройкой, который уже исправили, но ещё не выпустили новый релиз с исправлением. Ставьте версию 2.35.0. Там ошибок нет.
#mailserver
Много раз видел рекомендации на SnappyMail, это форк RainLoop, который больше не развивается. Решил посмотреть на SnappyMail и подключил к одному из почтовых серверов. Напишу то, на что обратил внимание сам по сравнению с RoundCube:
🔹SnappyMail имеет очень простой и быстрый веб интерфейс. Я, честно говоря, прям кайфую, когда вижу лёгкие и быстрые интерфейсы. Сейчас это редкость. Не сказать, что RoundCube тяжёлый, но SnappyMail легче и отзывчивее.
🔹Если вам не нужна общая адресная книга, то для работы SnappyMail не нужна СУБД. Она все настройки хранит в файлах. Написана тоже на php, так что для установки достаточно просто исходники положить в директорию веб сервера. Все дальнейшие настройки через веб интерфейс. Не нужно руками править конфиги. В RoundCube придётся по конфигам полазить, чтобы настроить.
🔹Как и RoundCube, SnappyMail поддерживает работу фильтров sieve. Из коробки стандартная тема поддерживает мобильные устройства.
🔹В SnappyMail по умолчанию любой пользователь может настраивать несколько почтовых ящиков, подключенных к его аккаунту.
🔹Для SnappyMail, как и RoundCube, есть много дополнительных плагинов. Но в отличие от круглого куба, в Snappy вся установка и настройка выполняется через веб интерфейс администратора. Не надо руками качать плагины и править конфиги. Это очень удобно. Набор плагинов тоже понравился.
🔹У SnappyMail есть готовые фильтры для Fail2ban, которые пресекают перебор учёток через веб интерфейс.
В общем и целом, ничего особенного у SnappyMail я не увидел, но по совокупности небольших улучшений он выглядит более простым и удобным в установке и настройке. Плюс, мне внешний вид темы по умолчанию понравился больше в SnappyMail. Он более минималистичный и компактный.
Единственное, что не понравилось - не увидел в SnappyMail плагин, который позволяет пользователю самостоятельно поставить отбойник, когда он уходит в отпуск. В RoundCube я в обязательном порядке его ставлю, пользователи активно используют. Можно это реализовывать с помощью фильтров, но отдельный плагин только под это дело удобнее.
❗️Если кто-то будет прямо сейчас пробовать, имейте ввиду, что в последних двух релизах есть баг, связанный с начальной настройкой, который уже исправили, но ещё не выпустили новый релиз с исправлением. Ставьте версию 2.35.0. Там ошибок нет.
#mailserver
Давно не было заметок на тему почтовых серверов. Год назад тема была очень живая, когда Яндекс объявил, что бесплатная почта для доменов перестаёт быть бесплатной. Судя по всему он на этом неплохо заработал. Часть знакомых мне людей в итоге оплатила услугу и продолжает с тех пор пользоваться уже за деньги.
Сегодня хотел не об этом. Попался на глаза очередной готовый почтовый сервер на базе известных open source компонентов, упакованных в Docker - docker-mailserver. На первый взгляд всё это очень сильно похоже на Mail-in-a-Box или Mailcow, которые уже давно известны и на слуху. У них даже количество звёзд на гитхабе примерно одинаковое.
Основные компоненты и особенности этой сборки:
◽ Postfix + Dovecot + Amavis
◽ Rspamd и SpamAssassin
◽ Clamav + Fail2ban
◽ OpenDKIM и OpenDMARC
◽ Postscreen + Postgrey
🔥SASLauthd с поддержкой LDAP
◽ Не используются базы данных, только конфигурационные файлы.
Стек очень стандартный и лично у меня к нему претензий никаких. Если собираю почтовик сам, то использую примерно эти же компоненты. Так что если вы любитель Docker и вам непременно нужен почтовый сервер в контейнерах, то это как минимум стандартный вариант без экзотики. Можно брать и пользоваться. Даже если что-то заглючит, можно залезть и поправить, потому что по каждому из этих компонентов есть масса инструкций и руководств.
У продукта неплохая документация: описание структуры, какие DNS записи нужны, как настроить окружение, пример рабочего docker-compose для запуска и т.д. В общем, я почитал, впечатление хорошее. Подробная документация обычно признак зрелого продукта. В этом плане он выглядит более привлекательно, чем Mail-in-a-Box.
С другой стороны, docker-mailserver ориентирован на максимальную простоту и снижение требований по ресурсам. По сути это минимальное ядро для реализации современного почтового сервера. Для запуска достаточно 1 vCore и 512MB RAM. Рекомендуется: 1 vCore 2GB RAM. У этой сборки нет ни интерфейса для администрирования, ни веб интерфейса для почты. Пользователи создаются консольными командами или берутся из LDAP.
Подводя итог скажу, что docker-mailserver в первую очередь для тех, кто уже умеет работать с почтовыми серверами, знает из чего они состоят и как с ними обращаться. Он пригодится, к примеру, как почтовый шлюз для приёма и отправки почты из расположенных рядом контейнеров. Благодаря минимальным системным требованиям и простоте установки, он будет уместен в этой роли.
Это не продукт по типу запустил установщик, зашёл в веб интерфейс и начал пользоваться. Если вам нужен подобный веб сервер, то можете выбрать что-то из моей подборки:
⇨ Подборка бесплатных почтовых серверов
Надо бы её обновить. Уже есть чем дополнить. Того же Mail-in-a-Box там нет, или Modoboa. Думаю, организую в ближайшее время.
Отдельное внимание обращаю на бесплатную версию Tegu. Я давно себе поднял для технических нужд и пользуюсь. Очень простой в настройке почтовый сервер. Состоит из одного бинарника на Go и конфига. Уже имеет встроенный веб интерфейс для управления. То есть просто рисуете конфиг, запускаете бинарник и у вас готовый почтовый сервер, где реализованы все основные возможности стандартного почтового сервера. Для тех, кто не хочет заморачиваться по этой теме, а нужен просто работающий сервер - идеальный вариант. У меня есть заметка, где я Tegu упаковал в deb пакет сразу вместе со службами для systemd.
Если кого-то интересует, что предпочитаю я сам, то отвечу, что это самостоятельная сборка необходимых компонентов. Как это примерно делается, описано в моей статье. Я умею это делать и мне так привычнее, удобнее. Вам не обязательно поступать так же. Можно взять готовое решение, просто его кто-то собрал за вас.
#mailserver
Сегодня хотел не об этом. Попался на глаза очередной готовый почтовый сервер на базе известных open source компонентов, упакованных в Docker - docker-mailserver. На первый взгляд всё это очень сильно похоже на Mail-in-a-Box или Mailcow, которые уже давно известны и на слуху. У них даже количество звёзд на гитхабе примерно одинаковое.
Основные компоненты и особенности этой сборки:
◽ Postfix + Dovecot + Amavis
◽ Rspamd и SpamAssassin
◽ Clamav + Fail2ban
◽ OpenDKIM и OpenDMARC
◽ Postscreen + Postgrey
🔥SASLauthd с поддержкой LDAP
◽ Не используются базы данных, только конфигурационные файлы.
Стек очень стандартный и лично у меня к нему претензий никаких. Если собираю почтовик сам, то использую примерно эти же компоненты. Так что если вы любитель Docker и вам непременно нужен почтовый сервер в контейнерах, то это как минимум стандартный вариант без экзотики. Можно брать и пользоваться. Даже если что-то заглючит, можно залезть и поправить, потому что по каждому из этих компонентов есть масса инструкций и руководств.
У продукта неплохая документация: описание структуры, какие DNS записи нужны, как настроить окружение, пример рабочего docker-compose для запуска и т.д. В общем, я почитал, впечатление хорошее. Подробная документация обычно признак зрелого продукта. В этом плане он выглядит более привлекательно, чем Mail-in-a-Box.
С другой стороны, docker-mailserver ориентирован на максимальную простоту и снижение требований по ресурсам. По сути это минимальное ядро для реализации современного почтового сервера. Для запуска достаточно 1 vCore и 512MB RAM. Рекомендуется: 1 vCore 2GB RAM. У этой сборки нет ни интерфейса для администрирования, ни веб интерфейса для почты. Пользователи создаются консольными командами или берутся из LDAP.
Подводя итог скажу, что docker-mailserver в первую очередь для тех, кто уже умеет работать с почтовыми серверами, знает из чего они состоят и как с ними обращаться. Он пригодится, к примеру, как почтовый шлюз для приёма и отправки почты из расположенных рядом контейнеров. Благодаря минимальным системным требованиям и простоте установки, он будет уместен в этой роли.
Это не продукт по типу запустил установщик, зашёл в веб интерфейс и начал пользоваться. Если вам нужен подобный веб сервер, то можете выбрать что-то из моей подборки:
⇨ Подборка бесплатных почтовых серверов
Надо бы её обновить. Уже есть чем дополнить. Того же Mail-in-a-Box там нет, или Modoboa. Думаю, организую в ближайшее время.
Отдельное внимание обращаю на бесплатную версию Tegu. Я давно себе поднял для технических нужд и пользуюсь. Очень простой в настройке почтовый сервер. Состоит из одного бинарника на Go и конфига. Уже имеет встроенный веб интерфейс для управления. То есть просто рисуете конфиг, запускаете бинарник и у вас готовый почтовый сервер, где реализованы все основные возможности стандартного почтового сервера. Для тех, кто не хочет заморачиваться по этой теме, а нужен просто работающий сервер - идеальный вариант. У меня есть заметка, где я Tegu упаковал в deb пакет сразу вместе со службами для systemd.
Если кого-то интересует, что предпочитаю я сам, то отвечу, что это самостоятельная сборка необходимых компонентов. Как это примерно делается, описано в моей статье. Я умею это делать и мне так привычнее, удобнее. Вам не обязательно поступать так же. Можно взять готовое решение, просто его кто-то собрал за вас.
#mailserver
GitHub
GitHub - docker-mailserver/docker-mailserver: Production-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus…
Production-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.) running inside a container. - docker-mailserver/docker-mailserver
В продолжение темы с уведомлениями в Apprise. Есть продукт на его основе, который умеет конвертировать email сообщения в уведомления apprise. Называется Mailrise. По своей сути это SMTP gateway для apprise.
Он поднимается как обычный SMTP сервер. Принимает сообщения и переадресует их в зависимости от настроек в необходимые каналы уведомлений. И речь тут может идти не только об уведомлениях в мессенджеры, смс, пуши и т.д. Например, mailrise может отправить email в формате JSON через HTTP POST запрос. Может в Syslog сделать запись с заголовком и текстом письма, может переслать на другой SMTP сервер. Продукт универсальный.
Насколько я понимаю, основное применение - отправка уведомлений с тех устройств и систем, которые кроме email ничего не умеют отправлять. Какие-нибудь свитчи, принтеры, может ещё что-то.
Покажу на примере, как это работает. Для начала установим Mailrise. Сделать это можно либо через pip, либо запустить в Docker. Я беру второй вариант, поэтому сразу подготовим конфигурационный файл, который мы передадим в контейнер.
Я буду принимать почту и отправлять уведомление в Telegram и Syslog. Для этого готовлю такой конфиг
Запускаю контейнер с указанным конфигом:
Почтовый сервер готов принимать почту на порту 8025. Отправляю тестовое сообщение. Проще всего это сделать через PowerShell:
В данном случае адреса telegram@mailrise.xyz и rsyslog@mailrise.xyz вымышленные. Имеет значение только название перед @. Оно должно соответствовать названиям конфигов в
В Linux через консоль с указанием релея отправки проще всего использовать ssmtp. Для этого её надо установить и нарисовать простой конфиг:
В конфиг
Отправляем почту через mailrise:
Оповещение прилетит в Telegram и Rsyslog. В последнем будет примерно такая запись в логе:
Соответственно, можно указать отдельный facility и настроить в rsyslog.conf приём этих уведомлений в отдельный файл.
Подобным образом можно настраивать любой тип уведомлений, которые поддерживает Apprise. По мне так очень простое и функциональное решение. Понятно, что оно не везде нужно. Лишнюю прослойку без нужды не стоит использовать. Но в целом сделано неплохо.
Если нужна аутентификация, то добавить её можно следующими настройками в конфиге:
⇨ Исходники / Видеообзор
#mailserver
Он поднимается как обычный SMTP сервер. Принимает сообщения и переадресует их в зависимости от настроек в необходимые каналы уведомлений. И речь тут может идти не только об уведомлениях в мессенджеры, смс, пуши и т.д. Например, mailrise может отправить email в формате JSON через HTTP POST запрос. Может в Syslog сделать запись с заголовком и текстом письма, может переслать на другой SMTP сервер. Продукт универсальный.
Насколько я понимаю, основное применение - отправка уведомлений с тех устройств и систем, которые кроме email ничего не умеют отправлять. Какие-нибудь свитчи, принтеры, может ещё что-то.
Покажу на примере, как это работает. Для начала установим Mailrise. Сделать это можно либо через pip, либо запустить в Docker. Я беру второй вариант, поэтому сразу подготовим конфигурационный файл, который мы передадим в контейнер.
Я буду принимать почту и отправлять уведомление в Telegram и Syslog. Для этого готовлю такой конфиг
mailrise.conf в формате yaml :configs: telegram: urls: - tgram://1393668911:AAHtETAKqxUH8ZpyC28R-wxKfvH8WR6-vdNw/211805263 rsyslog: urls: - rsyslog://172.30.245.222Запускаю контейнер с указанным конфигом:
# docker run -d -p 8025:8025 --restart always \-v ~/mailrise/mailrise.conf:/etc/mailrise.conf \--name mailrise \yoryan/mailriseПочтовый сервер готов принимать почту на порту 8025. Отправляю тестовое сообщение. Проще всего это сделать через PowerShell:
> send-mailmessage -from "admin@local" -to "Telegram <telegram@mailrise.xyz>","Rsyslog <rsyslog@mailrise.xyz>" -subject "Message from Mailrise" -body "Test Message" -smtpserver 172.30.245.222 -port 8025В данном случае адреса telegram@mailrise.xyz и rsyslog@mailrise.xyz вымышленные. Имеет значение только название перед @. Оно должно соответствовать названиям конфигов в
mailrise.conf. То есть если отправить почту только на telegram@mailrise.xyz, то оповещение придёт только в Telegram. То есть вот так:> send-mailmessage -from "admin@local" -to "Telegram <telegram@mailrise.xyz>" -subject "Message from Mailrise" -body "Test Message" -smtpserver 172.30.245.222 -port 8025В Linux через консоль с указанием релея отправки проще всего использовать ssmtp. Для этого её надо установить и нарисовать простой конфиг:
# apt install ssmtpВ конфиг
/etc/ssmtp/ssmtp.conf пишем:root=admin@localmailhub=172.30.245.222:8025hostname=debian12.homelab.localОтправляем почту через mailrise:
# echo "Test Message" | mail -s "Message from Mailrise" telegram@mailrise.xyz rsyslog@mailrise.xyzОповещение прилетит в Telegram и Rsyslog. В последнем будет примерно такая запись в логе:
2024-04-25T14:55:20.717270+03:00 172.17.0.2 - 1 - Message from Mailrise (admin@local): Test MessageСоответственно, можно указать отдельный facility и настроить в rsyslog.conf приём этих уведомлений в отдельный файл.
Подобным образом можно настраивать любой тип уведомлений, которые поддерживает Apprise. По мне так очень простое и функциональное решение. Понятно, что оно не везде нужно. Лишнюю прослойку без нужды не стоит использовать. Но в целом сделано неплохо.
Если нужна аутентификация, то добавить её можно следующими настройками в конфиге:
smtp: auth: basic: user01: password01⇨ Исходники / Видеообзор
#mailserver
