Я неоднократно получал вопрос от тех, кто настраивал почтовый сервер по моей статье, о том, как закрыть почтовые алиасы от спама. Поясню, о чём идёт речь.
Допустим, у вас есть почтовый алиас 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.0
Content-Type: application/pdf; name="file_credit50198.pdf"
Content-Transfer-Encoding: Base64
Content-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.txt
Gmail не принял письмо: "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@local
mailhub=172.30.245.222:8025
hostname=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
Решил сделать шпаргалку для копипасты по отправке email с аутентификацией из консоли через внешний smtp сервер. Нередко приходится этим заниматься как напрямую в консоли, так и в каких-то скриптах.
🔹В Linux самый простой вариант через Curl. Но там есть один нюанс, который создаёт неудобство, если вы хотите быстро отправить письмо через консоль. Заголовки и тело письма задаются через отдельный текстовый файл. Чтобы всё это уместить в одну команду, приходится использовать примерно такую конструкцию:
🔹Если вы будете использовать подобную отправку регулярно, либо где-то в скрипте, то скорее всего захочется вести лог передачи, отслеживать статус отправки и т.д. В таком случае проще всего настроить локально postfix или ssmtp. Для них нужно будет подготовить простой конфиг. Пример для postfix:
Добавляем в конфиг
Создаём файл
Создаем db файл.
Теперь можно перезапустить postfix и проверить работу.
Лог отправки, в том числе ответ принимающего сервера, будет в системном логе
🔹Ниже пример отправки почты через ssmtp.
В конфиг
Отправляем почту:
Утилита mail отправит почту через ssmtp. Я чаще отдаю предпочтение postfix, потому что у него лог кажется более информативным и привычным.
🔹В Windows можно использовать для этих же целей PowerShell. Вот как выглядит там отправка:
У вас откроется традиционное окно Windows для аутентификации. Туда нужно будет ввести логин и пароль от ящика. Если открыть cmd, перейти в powershell и выполнить указанную команду, то окно с аутентификацией почему-то не выскакивает. А если открыть сразу консоль PowerShell, то всё в порядке. Похоже на какой-то баг. Ошибка быстро гуглится, как и решение. Если не хочется вводить данные для аутентификации вручную, то их можно можно сохранить в переменной, в случае, если используется скрипт.
#mailserver
🔹В Linux самый простой вариант через Curl. Но там есть один нюанс, который создаёт неудобство, если вы хотите быстро отправить письмо через консоль. Заголовки и тело письма задаются через отдельный текстовый файл. Чтобы всё это уместить в одну команду, приходится использовать примерно такую конструкцию:
# echo -e "Subject: Test Subject \nTest body message." > /tmp/body.txt && curl -v --url "smtp://mail.server.ru:25" --mail-from root@server.ru --mail-rcpt user@example.com --user 'root@server.ru:password123' --upload-file "/tmp/body.txt"
🔹Если вы будете использовать подобную отправку регулярно, либо где-то в скрипте, то скорее всего захочется вести лог передачи, отслеживать статус отправки и т.д. В таком случае проще всего настроить локально postfix или ssmtp. Для них нужно будет подготовить простой конфиг. Пример для postfix:
# apt install postfix mailutils
Добавляем в конфиг
/etc/postfix/main.cf
relayhost = mail.server.ru:25
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
Создаём файл
/etc/postfix/sasl_passwd
с данными для аутентификации в таком формате:mail.server.ru:25 root@server.ru:password123
Создаем db файл.
# postmap /etc/postfix/sasl_passwd
Теперь можно перезапустить postfix и проверить работу.
# systemctl restart postfix
# echo "Test body message." | mail -s "Test Subject" user@example.com
Лог отправки, в том числе ответ принимающего сервера, будет в системном логе
/var/log/syslog
или /var/log/mail.log
. Удобно для отладки или мониторинга.🔹Ниже пример отправки почты через ssmtp.
# apt install ssmtp
В конфиг
/etc/ssmtp/ssmtp.conf
пишем:mailhub=mail.server.ru:25
hostname=mail.server.ru
root=root@server.ru
AuthUser=root@server.ru
AuthPass=password123
UseSTARTTLS=YES
UseTLS=YES
Отправляем почту:
# echo "Test body message." | mail -s "Test Subject" user@example.com
Утилита mail отправит почту через ssmtp. Я чаще отдаю предпочтение postfix, потому что у него лог кажется более информативным и привычным.
🔹В Windows можно использовать для этих же целей PowerShell. Вот как выглядит там отправка:
> Send-MailMessage -From root@server.ru -To user@example.com -Subject "Test Subject" -Body "Test body message." -SmtpServer mail.server.ru -Port 25 -Credential (Get-Credential)
У вас откроется традиционное окно Windows для аутентификации. Туда нужно будет ввести логин и пароль от ящика. Если открыть cmd, перейти в powershell и выполнить указанную команду, то окно с аутентификацией почему-то не выскакивает. А если открыть сразу консоль PowerShell, то всё в порядке. Похоже на какой-то баг. Ошибка быстро гуглится, как и решение. Если не хочется вводить данные для аутентификации вручную, то их можно можно сохранить в переменной, в случае, если используется скрипт.
#mailserver
Dovecot - наиболее популярный imap сервер, который используется в почтовых серверах на базе open source ПО. Остальные значительно уступают ему в популярности, и я даже не уверен, что их кто-то ещё использует. К примеру, лет 15 назад я настраивал Courier-IMAP. Со временем перешёл на Dovecot, потому что он более популярен.
Так вот, если вы эксплуатируете этот imap сервер, то можно использовать его встроенные возможности для очистки почтовых ящиков или папок в них. В первую очередь это касается папок Trash и Junk (Spam). Для этого можно использовать простую команду:
Она удалит все письма в ящике user@example.com в папке Trash старше 4-х недель. Соответственно, так можно очищать любой ящик.
Условие может быть составным. Например, очистим все прочитанные сообщения в папке Spam старше 24 часов:
Можно делать глобальные чистки сразу для всех ящиков (❗️будьте аккуратны с подобными командами). Например, удалим всю почту старше трёх лет:
Синтаксис запросов doveadm описан в документации dovecot.
Благодаря тому, что Dovecot, как я уже сказал, используется почти во всех бесплатных сборках почтовых серверов, вы можете использовать эти возможности и там. Например, в iredmail, mailcow и т.д.
Когда я не знал про эти возможности Dovecot, использовал свои костыли на основе find. Так как письма в формате maildir - это по сути обычные текстовые файлы, вы можете делать с ними на уровне файлов всё, что угодно. Примеры своих скриптов я показал в статье Очистка и обслуживание почтовой базы postfix. Посмотрите, может найдёте там для себя что-то полезное. Я показываю в том числе, как выполнять очистку писем на основе их содержимого или заголовка (поля subject). К примеру, удалять все письма старше 30 дней с определённой темой. Статья писалась 7! лет назад. Сейчас я бы делал скорее всего всё это по-другому, так что не спешите критиковать. Просто примите к сведению то, что там написано, если для вас эта тема актуальна.
#mailserver #dovecot
Так вот, если вы эксплуатируете этот imap сервер, то можно использовать его встроенные возможности для очистки почтовых ящиков или папок в них. В первую очередь это касается папок Trash и Junk (Spam). Для этого можно использовать простую команду:
# doveadm expunge -u user@example.com mailbox Trash savedbefore 4w
Она удалит все письма в ящике user@example.com в папке Trash старше 4-х недель. Соответственно, так можно очищать любой ящик.
Условие может быть составным. Например, очистим все прочитанные сообщения в папке Spam старше 24 часов:
# doveadm expunge -u user@example.com mailbox 'Junk' SEEN not SINCE 24h
Можно делать глобальные чистки сразу для всех ящиков (❗️будьте аккуратны с подобными командами). Например, удалим всю почту старше трёх лет:
# doveadm expunge -A mailbox % before 156w
Синтаксис запросов doveadm описан в документации dovecot.
Благодаря тому, что Dovecot, как я уже сказал, используется почти во всех бесплатных сборках почтовых серверов, вы можете использовать эти возможности и там. Например, в iredmail, mailcow и т.д.
Когда я не знал про эти возможности Dovecot, использовал свои костыли на основе find. Так как письма в формате maildir - это по сути обычные текстовые файлы, вы можете делать с ними на уровне файлов всё, что угодно. Примеры своих скриптов я показал в статье Очистка и обслуживание почтовой базы postfix. Посмотрите, может найдёте там для себя что-то полезное. Я показываю в том числе, как выполнять очистку писем на основе их содержимого или заголовка (поля subject). К примеру, удалять все письма старше 30 дней с определённой темой. Статья писалась 7! лет назад. Сейчас я бы делал скорее всего всё это по-другому, так что не спешите критиковать. Просто примите к сведению то, что там написано, если для вас эта тема актуальна.
#mailserver #dovecot
Server Admin
Очистка и обслуживание почтовой базы postfix
Практические примеры по фильтрации почты в почтовых ящиках postfix, автоматической очистке корзин и папок со спамом в почтовых ящиках.
Актуализировал свою статью про настройку почтового сервера на базе Debian 12:
⇨ Настройка почтового сервера на Debian: postfix + dovecot + web интерфейс
Если вам нужен стандартный почтовый сервер с базовыми возможностями, то с помощью этой статьи вы практически в режиме copy-paste сможете его настроить.
❓Может возникнуть резонный вопрос. Стоит ли всем этим заниматься самостоятельно и настраивать с нуля? Есть много вариантов готовых почтовых серверов, которые настраиваются в несколько действий. Моё мнение такое. Если вам нужен сервер для небольших вспомогательных задач, то лучше взять что-то готовое и не заморачиваться. Это такие знания, которые некоторым вообще не пригодятся в их карьере. Сейчас услуги почтовых серверов в основном приобретаются как сервис. Если в вашем случае такой сервис можно купить, то купите. Так будет удобнее всем, и пользователям, и тем, кто это будет поддерживать.
Самостоятельно настраивать почтовый сервер имеет смысл, если вы хотите изучить его работу, и вам это пригодится в будущем. Если вам нужно будет администрировать нагруженный почтовый сервер, с которым будет работать множество пользователей, то вникать в нюансы его работы нужно будет в обязательном порядке. Даже если вы планируете купить коммерческое решение, потренируйтесь в настройке самостоятельно. Postfix в этом плане подходящий вариант, так как к нему шаг за шагом можно навешивать новую функциональность и смотреть, как всё это вместе работает.
Второй вариант - вам нужно что-то необычное. Например, изменять письма перед отправкой. Отправлять почту с почтового сервера, используя несколько других в качестве релея, управляя условиями выбора того или иного внешнего сервера. Вы хотите что-то делать с письмами на основе их содержимого, заголовков и других признаков. Например, автоматически удалять какие-то письма по истечении определённого времени. Вам нужен почтовый сервер для двух доменных зон - одна для внешней почты, другая только для внутренней переписки, без возможности отправки какими-то пользователями почты во вне. Вы хотите кому-то запретить отправлять больше 30-ти писем в час. В общем, тут вы ограничены только своей фантазией. На базе Postfix и обвязки можно реализовать разнообразные функциональности.
Полезные ссылки по этой теме:
◽️Подборка онлайн сервисов для диагностики почтовых серверов
◽️Imapsync для переноса почты между серверами
◽️Ограничение на отправку за определённый период времени
◽️Защита почтового сервера с помощью Fail2Ban
◽️Перенос почтового сервера Postfix
◽️Очистка почтовых ящиков средствами Dovecot
◽️Веб интерфейс SnappyMail
◽️Инструмент для диагностики почтовых серверов - Swaks
◽️Модуль статистики для мониторинга Dovecot
◽️Мониторинг postfix в zabbix
◽️Настройка маршрута отправки в зависимости от домена
◽️Как изменить тему письма и адрес отправителя через postfix
◽️Выбор сервера для отправки в зависимости от получателя
◽️Названия imap директорий ф кодировке UTF-7
◽️Бэкап почтовых ящиков с помощью imap-backup
◽️Greylisting для борьбы со спамом
Если ищите себе вариант готового бесплатного сервера, то у меня почти все популярные варианты были на канале:
▪️Mailcow
▪️Mail-in-a-Box
▪️hMailServer
▪️Tegu
▪️Iredmail
▪️Carbonio CE
▪️Poste.io
▪️docker-mailserver
▪️Modoboa
Краткое описание некоторых из них было в подборке.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver #подборка
⇨ Настройка почтового сервера на Debian: postfix + dovecot + web интерфейс
Если вам нужен стандартный почтовый сервер с базовыми возможностями, то с помощью этой статьи вы практически в режиме copy-paste сможете его настроить.
❓Может возникнуть резонный вопрос. Стоит ли всем этим заниматься самостоятельно и настраивать с нуля? Есть много вариантов готовых почтовых серверов, которые настраиваются в несколько действий. Моё мнение такое. Если вам нужен сервер для небольших вспомогательных задач, то лучше взять что-то готовое и не заморачиваться. Это такие знания, которые некоторым вообще не пригодятся в их карьере. Сейчас услуги почтовых серверов в основном приобретаются как сервис. Если в вашем случае такой сервис можно купить, то купите. Так будет удобнее всем, и пользователям, и тем, кто это будет поддерживать.
Самостоятельно настраивать почтовый сервер имеет смысл, если вы хотите изучить его работу, и вам это пригодится в будущем. Если вам нужно будет администрировать нагруженный почтовый сервер, с которым будет работать множество пользователей, то вникать в нюансы его работы нужно будет в обязательном порядке. Даже если вы планируете купить коммерческое решение, потренируйтесь в настройке самостоятельно. Postfix в этом плане подходящий вариант, так как к нему шаг за шагом можно навешивать новую функциональность и смотреть, как всё это вместе работает.
Второй вариант - вам нужно что-то необычное. Например, изменять письма перед отправкой. Отправлять почту с почтового сервера, используя несколько других в качестве релея, управляя условиями выбора того или иного внешнего сервера. Вы хотите что-то делать с письмами на основе их содержимого, заголовков и других признаков. Например, автоматически удалять какие-то письма по истечении определённого времени. Вам нужен почтовый сервер для двух доменных зон - одна для внешней почты, другая только для внутренней переписки, без возможности отправки какими-то пользователями почты во вне. Вы хотите кому-то запретить отправлять больше 30-ти писем в час. В общем, тут вы ограничены только своей фантазией. На базе Postfix и обвязки можно реализовать разнообразные функциональности.
Полезные ссылки по этой теме:
◽️Подборка онлайн сервисов для диагностики почтовых серверов
◽️Imapsync для переноса почты между серверами
◽️Ограничение на отправку за определённый период времени
◽️Защита почтового сервера с помощью Fail2Ban
◽️Перенос почтового сервера Postfix
◽️Очистка почтовых ящиков средствами Dovecot
◽️Веб интерфейс SnappyMail
◽️Инструмент для диагностики почтовых серверов - Swaks
◽️Модуль статистики для мониторинга Dovecot
◽️Мониторинг postfix в zabbix
◽️Настройка маршрута отправки в зависимости от домена
◽️Как изменить тему письма и адрес отправителя через postfix
◽️Выбор сервера для отправки в зависимости от получателя
◽️Названия imap директорий ф кодировке UTF-7
◽️Бэкап почтовых ящиков с помощью imap-backup
◽️Greylisting для борьбы со спамом
Если ищите себе вариант готового бесплатного сервера, то у меня почти все популярные варианты были на канале:
▪️Mailcow
▪️Mail-in-a-Box
▪️hMailServer
▪️Tegu
▪️Iredmail
▪️Carbonio CE
▪️Poste.io
▪️docker-mailserver
▪️Modoboa
Краткое описание некоторых из них было в подборке.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver #подборка
Server Admin
Настройка почтового сервера на Debian: postfix + dovecot + web...
Подробная пошаговая установка и настройка почтового сервера на Debian (postfix + dovecot): от подготовки DNS записей до запуска служб.
Давненько не было публикаций на тему почтовых серверов. Они сейчас как-будто в тень ушли. Ни выступлений по теме почты не вижу, ни обсуждений, настройки, каких-то значимых новостей, если не считать новости о новых уязвимостях Exim. Хотя это тот сервис, которым все по-прежнему пользуются и не собираются отказываться.
Всё чаще почту предпочитают отдавать на откуп готовым платным сервисам. Правда иногда смотрю на расценки по услугам, а это не так, чтобы дёшево. Хотя в настройке почтового сервера ничего особенного нет. Надо только один раз вникнуть в настройку, организовать корректные записи DNS и получить беспроблемные внешние IP адреса. А дальше почтовый сервер обычно большого внимания к себе не требует, после того как всё настроишь и отладишь.
Я к чему эту подводку написал. Недавно просто увидел у одного провайдера новую услугу по отправке почты. Не буду называть название, чтобы не начали писать, что это скрытая реклама и т.д. Вроде и не особо дорого, можно купить и не заморачиваться. Но тут есть один нюанс, как это обычно бывает с сервисами. Можно легко попасть на приличные бабки.
Работал с одним проектом, который получил вал отправленных писем на ровном месте. Это было что-то вроде социальной сети, где можно друг другу отправлять сообщения и уведомления приходят на почту. Время от времени появлялись боты, которые массово начинали спамить по личкам и это вызывало вал отправленных писем. У нас сервер свой был и проблем это особо не доставляло. Причём я первый и узнавал об этом через мониторинг отправленных писем. Это быстро фиксили и не было проблем.
А если за почту платить, то можно влететь на ровном месте. Почта очень хорошо отправляется, производительность даже рядового сервера позволяет отправлять десятки тысяч писем за минуту. Если ломанут проект и начнут через него спамить, то очень быстро отправят миллионы писем, если не выставлены никакие лимиты.
Я вообще изначально хотел написать про очень старый и известный сервис для рассылок, но оформлю его вечером отдельной публикацией, а то как-то сумбурно получилось обо всём понемногу. Смешал в одной публикации почтовый сервер как службу для пользователей и сервис для рассылок.
Если надумаете поднимать свой почтовый сервер, а это по идее сейчас актуально стало, так как бесплатных сервисов, типа тех, что были у Яндекса или Мейла, больше нет. Я вообще не знаю, где можно бесплатно поднять почту на своём домене. То вот вам пару наводок:
▪️Свой почтовый сервер на базе Postfix + Dovecot. Статья не сильно старая. Написана пару лет назад, но осенью я её обновлял в соответствии с изменениями. В комментариях люди пишут, что всё ещё актуальна. Так что с её помощью можно почти в режиме copy-paste всё сделать.
Если ищите себе вариант готового бесплатного сервера, то у меня почти все популярные варианты были на канале:
▪️Mailcow
▪️Mail-in-a-Box
▪️hMailServer
▪️Tegu
▪️Iredmail
▪️Carbonio CE
▪️Poste.io
▪️docker-mailserver
▪️Modoboa
Вроде тут всё более-менее популярное. Если знаете какой-то удобный и функциональный почтовый сервер, то поделитесь информацией.
Ещё интересно было бы узнать, кто пользуется своими почтовыми серверами, и какими именно, а кто покупает как сервис, и где. Это была бы полезная информация. Я сейчас мало вижу информации о почтовых серверах. Даже не знаю, что сейчас наиболее популярное. По теме импортозамещения должно быть много новых имён. Последние несколько лет появилось много российских почтовых серверов. Как минимум от трёх российских вендоров я получал предложения о сотрудничестве. Но у меня не особо развит этот формат, так что отказывал. Тестировать почтовый сервер довольно хлопотно, хотя про астру и их RuPost я в своё время писал статью.
#mailserver
Всё чаще почту предпочитают отдавать на откуп готовым платным сервисам. Правда иногда смотрю на расценки по услугам, а это не так, чтобы дёшево. Хотя в настройке почтового сервера ничего особенного нет. Надо только один раз вникнуть в настройку, организовать корректные записи DNS и получить беспроблемные внешние IP адреса. А дальше почтовый сервер обычно большого внимания к себе не требует, после того как всё настроишь и отладишь.
Я к чему эту подводку написал. Недавно просто увидел у одного провайдера новую услугу по отправке почты. Не буду называть название, чтобы не начали писать, что это скрытая реклама и т.д. Вроде и не особо дорого, можно купить и не заморачиваться. Но тут есть один нюанс, как это обычно бывает с сервисами. Можно легко попасть на приличные бабки.
Работал с одним проектом, который получил вал отправленных писем на ровном месте. Это было что-то вроде социальной сети, где можно друг другу отправлять сообщения и уведомления приходят на почту. Время от времени появлялись боты, которые массово начинали спамить по личкам и это вызывало вал отправленных писем. У нас сервер свой был и проблем это особо не доставляло. Причём я первый и узнавал об этом через мониторинг отправленных писем. Это быстро фиксили и не было проблем.
А если за почту платить, то можно влететь на ровном месте. Почта очень хорошо отправляется, производительность даже рядового сервера позволяет отправлять десятки тысяч писем за минуту. Если ломанут проект и начнут через него спамить, то очень быстро отправят миллионы писем, если не выставлены никакие лимиты.
Я вообще изначально хотел написать про очень старый и известный сервис для рассылок, но оформлю его вечером отдельной публикацией, а то как-то сумбурно получилось обо всём понемногу. Смешал в одной публикации почтовый сервер как службу для пользователей и сервис для рассылок.
Если надумаете поднимать свой почтовый сервер, а это по идее сейчас актуально стало, так как бесплатных сервисов, типа тех, что были у Яндекса или Мейла, больше нет. Я вообще не знаю, где можно бесплатно поднять почту на своём домене. То вот вам пару наводок:
▪️Свой почтовый сервер на базе Postfix + Dovecot. Статья не сильно старая. Написана пару лет назад, но осенью я её обновлял в соответствии с изменениями. В комментариях люди пишут, что всё ещё актуальна. Так что с её помощью можно почти в режиме copy-paste всё сделать.
Если ищите себе вариант готового бесплатного сервера, то у меня почти все популярные варианты были на канале:
▪️Mailcow
▪️Mail-in-a-Box
▪️hMailServer
▪️Tegu
▪️Iredmail
▪️Carbonio CE
▪️Poste.io
▪️docker-mailserver
▪️Modoboa
Вроде тут всё более-менее популярное. Если знаете какой-то удобный и функциональный почтовый сервер, то поделитесь информацией.
Ещё интересно было бы узнать, кто пользуется своими почтовыми серверами, и какими именно, а кто покупает как сервис, и где. Это была бы полезная информация. Я сейчас мало вижу информации о почтовых серверах. Даже не знаю, что сейчас наиболее популярное. По теме импортозамещения должно быть много новых имён. Последние несколько лет появилось много российских почтовых серверов. Как минимум от трёх российских вендоров я получал предложения о сотрудничестве. Но у меня не особо развит этот формат, так что отказывал. Тестировать почтовый сервер довольно хлопотно, хотя про астру и их RuPost я в своё время писал статью.
#mailserver
Server Admin
Настройка почтового сервера на Debian: postfix + dovecot + web...
Подробная пошаговая установка и настройка почтового сервера на Debian (postfix + dovecot): от подготовки DNS записей до запуска служб.
📩 Продолжая тему почтовых серверов. Есть очень старый и известный сервис для организации почтовых рассылок на базе своего почтового сервера – Mailman (GNU Mailing List Manager). Скорее всего вы его где-то встречали или даже пользовались. Это очень старый, известный продукт, который поддерживается и актуален до сих пор. Не так давно вышла новая 3-я версия.
Часто можно встретить этот продукт либо на поддомене какого-то известного бренда, либо в виде алиаса. Например, на Mailman работают рассылки Nginx: mailman.nginx.org. Ещё пример – рассылки Proxmox: lists.proxmox.com/cgi-bin/mailman/listinfo/. Примеров можно найти очень много. Mailman любят использовать различные open source проекты.
При этом Mailman относительно легко настроить, если у вас, к примеру, есть свой сервер на Postfix. Для управления непосредственно рассылками есть веб интерфейс, а в почтовом сервере достаточно будет создать отдельный домен для рассылок и указать, что транспортом по этому домену занимается Mailman. Продукт старый и известный, в сети много инструкций. Настроить будет не трудно и не долго. При условии, что у вас есть почтовый сервер и вы умеете с ним работать. Если нет, то лучше выбрать что-то другое.
📌 Mailman закрывает следующие потребности:
🟢 Публичная рассылка. Примеры я привёл в начале. Любой пользователь может подписаться или отписаться.
🔴 Закрытая рассылка. Подписывает людей администратор. Назначаются ответственные лица, которые могут рассылать сообщения. Типичная история для офиса.
🟡 Модерируемая рассылка. Подписаться или отправить сообщение в рассылку может любой пользователь. При этом все отправляемые сообщения проверяются и одобряются модератором или группой модераторов.
Одно из удобств Mailman – добавлять и удалять пользователей в рассылки можно через консоль. Это актуально для тех, кто любит писать какие-то свои велосипеды из скрипов. Например, если речь идёт об офисе, то с помощью Mailman можно организовать рассылки внутри компании. Сделать рассылки по отделам, по направлениям, общую для всей компании. Добавлять туда пользователей, назначать тех, кто может отправлять письма на общие рассылки и т.д. К созданию пользователя можно добавить скрипт по добавлению его в те или иные рассылки.
В завершении добавлю, что если у вас потребность в рассылках очень простая, а сами списки и управление осуществляются каким-то сторонним софтом, например, движком сайта или cmr, то можно использовать простой почтовый сервер, рассчитанный именно на отправку. Его и настраивать быстрее, проще, и обслуживать почти не надо. Примеры таких серверов:
- Cuttlefish
- Postal
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver
Часто можно встретить этот продукт либо на поддомене какого-то известного бренда, либо в виде алиаса. Например, на Mailman работают рассылки Nginx: mailman.nginx.org. Ещё пример – рассылки Proxmox: lists.proxmox.com/cgi-bin/mailman/listinfo/. Примеров можно найти очень много. Mailman любят использовать различные open source проекты.
При этом Mailman относительно легко настроить, если у вас, к примеру, есть свой сервер на Postfix. Для управления непосредственно рассылками есть веб интерфейс, а в почтовом сервере достаточно будет создать отдельный домен для рассылок и указать, что транспортом по этому домену занимается Mailman. Продукт старый и известный, в сети много инструкций. Настроить будет не трудно и не долго. При условии, что у вас есть почтовый сервер и вы умеете с ним работать. Если нет, то лучше выбрать что-то другое.
📌 Mailman закрывает следующие потребности:
🟢 Публичная рассылка. Примеры я привёл в начале. Любой пользователь может подписаться или отписаться.
🔴 Закрытая рассылка. Подписывает людей администратор. Назначаются ответственные лица, которые могут рассылать сообщения. Типичная история для офиса.
🟡 Модерируемая рассылка. Подписаться или отправить сообщение в рассылку может любой пользователь. При этом все отправляемые сообщения проверяются и одобряются модератором или группой модераторов.
Одно из удобств Mailman – добавлять и удалять пользователей в рассылки можно через консоль. Это актуально для тех, кто любит писать какие-то свои велосипеды из скрипов. Например, если речь идёт об офисе, то с помощью Mailman можно организовать рассылки внутри компании. Сделать рассылки по отделам, по направлениям, общую для всей компании. Добавлять туда пользователей, назначать тех, кто может отправлять письма на общие рассылки и т.д. К созданию пользователя можно добавить скрипт по добавлению его в те или иные рассылки.
В завершении добавлю, что если у вас потребность в рассылках очень простая, а сами списки и управление осуществляются каким-то сторонним софтом, например, движком сайта или cmr, то можно использовать простой почтовый сервер, рассчитанный именно на отправку. Его и настраивать быстрее, проще, и обслуживать почти не надо. Примеры таких серверов:
- Cuttlefish
- Postal
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver
На днях в чате в обсуждении почтовых серверов, как обычно, поднялся вопрос прикрепления к письмам больших файлов. У облачных провайдеров типа Яндекса или Мейла есть возможность большие файлы прикреплять к письмам в виде ссылки, а сами файлы загружаются и хранятся на их файловых сервисах. Когда пользователей пересаживаешь с этих сервисов, они очень грустят и просят такую же функциональность на своих серверах.
В комментариях читатель упомянул плагин для популярного веб интерфейса Roundcube, который позволяет так же просто и удобно прикреплять к письмам большие файлы в виде ссылок на собственное хранилище NextCloud. Раньше я не встречал подобной функциональности. Её реально не хватает на настроенных у себя почтовых серверах.
Решил сразу же проверить, как это работает. Развернул быстро Nextcloud, поднял Roundcube и установил на него плагин Nextcloud Attachments for Roundcube. Никаких особых проблем не возникло. Работает просто и удобно. У меня сходу всё получилось настроить. Правда я хорошо знаю всю эту кухню, но тем не менее. Все файлы, что выходят за разрешённый лимит сервера, предлагается загрузить в Nextcloud.
Roundcube и Nextcloud можно настроить в стороне от вашего сервера, никак его не трогая. Потестировать эту связку нет никаких проблем. Отдельным вопросом стоит сквозная аутентификация. Но даже если её вообще не настраивать, то при первом прикреплении пользователю выскочит предложение пройти аутентификацию в Nextcloud и разрешить Roundcube загружать туда файлы.
В репозитории автора есть описание доступных настроек и картинка с примером, как это работает. Если честно, я по картинке ничего не понял. Ниже мои скрины, которые отражают весь процесс добавления вложения: предложение аутентификации, ссылка на файл в теле письма, как это письмо со ссылкой выглядит у получателя, и как этот файл выглядит, когда перейдёшь по ссылке.
Вообще, это очень крутая функциональность. Если обмен идёт неприватными файлами, то можно быстро поднять Nextcloud, сделать там одну учётку для всех своих пользователей и пусть они под ней прикрепляют туда свои большие файлы и отправляют. Получатели будут видеть только каждый свой файл из письма.
Из минусов – нет перевода на русский язык. Но там текста всего несколько фраз. Можно и вручную в исходниках перевести.
⇨ 🌐 Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver #fileserver
В комментариях читатель упомянул плагин для популярного веб интерфейса Roundcube, который позволяет так же просто и удобно прикреплять к письмам большие файлы в виде ссылок на собственное хранилище NextCloud. Раньше я не встречал подобной функциональности. Её реально не хватает на настроенных у себя почтовых серверах.
Решил сразу же проверить, как это работает. Развернул быстро Nextcloud, поднял Roundcube и установил на него плагин Nextcloud Attachments for Roundcube. Никаких особых проблем не возникло. Работает просто и удобно. У меня сходу всё получилось настроить. Правда я хорошо знаю всю эту кухню, но тем не менее. Все файлы, что выходят за разрешённый лимит сервера, предлагается загрузить в Nextcloud.
Roundcube и Nextcloud можно настроить в стороне от вашего сервера, никак его не трогая. Потестировать эту связку нет никаких проблем. Отдельным вопросом стоит сквозная аутентификация. Но даже если её вообще не настраивать, то при первом прикреплении пользователю выскочит предложение пройти аутентификацию в Nextcloud и разрешить Roundcube загружать туда файлы.
В репозитории автора есть описание доступных настроек и картинка с примером, как это работает. Если честно, я по картинке ничего не понял. Ниже мои скрины, которые отражают весь процесс добавления вложения: предложение аутентификации, ссылка на файл в теле письма, как это письмо со ссылкой выглядит у получателя, и как этот файл выглядит, когда перейдёшь по ссылке.
Вообще, это очень крутая функциональность. Если обмен идёт неприватными файлами, то можно быстро поднять Nextcloud, сделать там одну учётку для всех своих пользователей и пусть они под ней прикрепляют туда свои большие файлы и отправляют. Получатели будут видеть только каждый свой файл из письма.
Из минусов – нет перевода на русский язык. Но там текста всего несколько фраз. Можно и вручную в исходниках перевести.
⇨ 🌐 Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver #fileserver
📩 Расскажу про комбинированную схему работы своего почтового сервера, которая может оказаться простой и надёжной, но при этом очень бюджетной. Я об этом ранее упоминал в отдельных заметках, но не делал акцента.
➖ Очевидные проблемы своего почтового сервера, которые нужно решать:
◽️Отказоустойчивость и доступность.
◽️Доверие к своему IP адресу, транспорт почты.
◽️Борьба со спамом.
➕ Плюсы своего почтового сервера:
🟢 Дёшево на длинном интервале.
🟢 Ящики могут быть очень большого объёма, платите только за свои диски.
🟢 Накручиваете любую функциональность и интеграции, никаких ограничений.
Я предлагаю убрать проблемы следующим образом. У многих провайдеров есть услуга в виде почты. Она может продаваться как отдельно, так и в составе каких-то других услуг, например, виртуального хостинга. Вот пример такой услуги. Показываю не в качестве рекламы, а просто как пример, как это может выглядеть со стороны хостера.
Вы покупаете подобную услугу и настраиваете свой почтовый сервер где угодно. У хостера будут готовые инструкции, где и что надо настроить в DNS, чтобы почта доставлялась к нему. Вы настраиваете и вся почта улетает к провайдеру.
Настройка у провайдера может разниться. Я сталкивался с разными вариантами. Можно создать один почтовый ящик, куда будет сыпаться вся почта, адресованная на ящики домена. Это наиболее простой и удобный вариант. Один раз настроил и больше к провайдеру не обращаешься. Возможно придётся создать каждый почтовый ящик, куда вы хотите принимать почту.
⇨ Далее вы берёте свой почтовый сервер, добавляете туда пользователей. В настройках сервера указываете, что почту для пользователя нужно брать с внешнего сервера. Указываете учётные данные для доступа в ящик, где лежит почта. Также указываете в своём сервере, что отправку нужно делать через внешний релей провайдера.
Настройки серверов могут разниться. Я по такой схеме работал с Kerio и Postfix. В Kerio вообще всё просто. Он может забирать разом всю почту из общего ящика провайдера, куда валится почта для всего домена и раскладывать его по локальным ящикам пользователей на основе адреса получателя. Либо можно для каждого конкретного ящика указать ящик у провайдера, откуда он будет забирать почту. Ну и в качестве сервера для отправки указывается почтовый сервер провайдера.
У Postfix принцип такой же, но больше ручной работы. Забирать почту у провайдера можно через Fetchmail. Настраивать можно конфигами в консоли, либо с помощью RoundCube или PostfixAdmin. У них есть интеграция с Fetchmail. Ну а отправка настраивается на сервере через параметр relayhost. Более того, если вы хотите для разных доменов использовать разные сервера для отправки, то используете параметр transport_maps, которому можно указать список доменов и соответствие внешних smtp серверов, через которые будет отправка.
❗️Обращаю внимание на последний момент с transport_maps. Меня не раз спрашивали, как в рамках одного почтового сервера и нескольких доменов делать отправку так, чтобы не было видно, что они связаны между собой. С помощью внешних почтовых серверов и Postfix это легко настраивается. Арендуете разные услуги внешнего сервера SMTP и настраиваете на своём почтовом сервере отправку через них, используя разный сервер для каждого домена.
📌 Итак, что мы получаем на выходе:
1️⃣ Почта с сервера провайдера забирается по протоколу POP3 с удалением после получения. За место нам платить не надо. Это существенно уменьшает стоимость.
2️⃣ Провайдер сам отправляет почту и организует доступность сервера. Даже если у нас что-то сломается или нам нужно будет заменить свой сервер, вся почта будет прилетать на сервер провайдера. А когда наш оживёт, заберёт почту. Нам не нужно решать вопросы доступности. Мы не теряем почту в случае своих аварий.
3️⃣ Локально мы можем сколько угодно хранить почту, не переживая за занимаемое место.
Существенный минус один – нужно в двух местах делать настройки: на своем сервере и провайдерском.
Схема 100% рабочая и эффективная. Я не раз использовал.
#mailserver
➖ Очевидные проблемы своего почтового сервера, которые нужно решать:
◽️Отказоустойчивость и доступность.
◽️Доверие к своему IP адресу, транспорт почты.
◽️Борьба со спамом.
➕ Плюсы своего почтового сервера:
🟢 Дёшево на длинном интервале.
🟢 Ящики могут быть очень большого объёма, платите только за свои диски.
🟢 Накручиваете любую функциональность и интеграции, никаких ограничений.
Я предлагаю убрать проблемы следующим образом. У многих провайдеров есть услуга в виде почты. Она может продаваться как отдельно, так и в составе каких-то других услуг, например, виртуального хостинга. Вот пример такой услуги. Показываю не в качестве рекламы, а просто как пример, как это может выглядеть со стороны хостера.
Вы покупаете подобную услугу и настраиваете свой почтовый сервер где угодно. У хостера будут готовые инструкции, где и что надо настроить в DNS, чтобы почта доставлялась к нему. Вы настраиваете и вся почта улетает к провайдеру.
Настройка у провайдера может разниться. Я сталкивался с разными вариантами. Можно создать один почтовый ящик, куда будет сыпаться вся почта, адресованная на ящики домена. Это наиболее простой и удобный вариант. Один раз настроил и больше к провайдеру не обращаешься. Возможно придётся создать каждый почтовый ящик, куда вы хотите принимать почту.
⇨ Далее вы берёте свой почтовый сервер, добавляете туда пользователей. В настройках сервера указываете, что почту для пользователя нужно брать с внешнего сервера. Указываете учётные данные для доступа в ящик, где лежит почта. Также указываете в своём сервере, что отправку нужно делать через внешний релей провайдера.
Настройки серверов могут разниться. Я по такой схеме работал с Kerio и Postfix. В Kerio вообще всё просто. Он может забирать разом всю почту из общего ящика провайдера, куда валится почта для всего домена и раскладывать его по локальным ящикам пользователей на основе адреса получателя. Либо можно для каждого конкретного ящика указать ящик у провайдера, откуда он будет забирать почту. Ну и в качестве сервера для отправки указывается почтовый сервер провайдера.
У Postfix принцип такой же, но больше ручной работы. Забирать почту у провайдера можно через Fetchmail. Настраивать можно конфигами в консоли, либо с помощью RoundCube или PostfixAdmin. У них есть интеграция с Fetchmail. Ну а отправка настраивается на сервере через параметр relayhost. Более того, если вы хотите для разных доменов использовать разные сервера для отправки, то используете параметр transport_maps, которому можно указать список доменов и соответствие внешних smtp серверов, через которые будет отправка.
❗️Обращаю внимание на последний момент с transport_maps. Меня не раз спрашивали, как в рамках одного почтового сервера и нескольких доменов делать отправку так, чтобы не было видно, что они связаны между собой. С помощью внешних почтовых серверов и Postfix это легко настраивается. Арендуете разные услуги внешнего сервера SMTP и настраиваете на своём почтовом сервере отправку через них, используя разный сервер для каждого домена.
📌 Итак, что мы получаем на выходе:
Существенный минус один – нужно в двух местах делать настройки: на своем сервере и провайдерском.
Схема 100% рабочая и эффективная. Я не раз использовал.
#mailserver
Please open Telegram to view this post
VIEW IN TELEGRAM
masterhost.ru
Просто почта - удобный интерфейс и защита от СПАМа | masterhost
Просто почта от masterhost. Возможность получить качественную почту с удобным интерфейсом и защитой от СПАМа и вирусов по приятной цене!
На днях в комментариях промелькнул бесплатный почтовый сервер Mox с открытым исходным кодом. Про него не слышал ранее, поэтому решил посмотреть, что это такое. Я его развернул и немного попользовался. Перейду сразу к конкретике, перечислив плюсы и минусы.
✅ Плюсы:
1️⃣ Простая и быстрая установка. Весь сервер – это один скомпилированный бинарник, написанный на Go. Во время первого запуска нужно указать почтовый ящик администратора на том домене, где он будет работать. Сервер автоматически создаст все конфигурационные файлы, dkim ключ, покажет все необходимые DNS записи, которые нужно добавить. Там речь пойдёт не только про MX, SPF, DKIM, DMARC. Также будут показаны необходимые записи для работы MTA-STS, автообнаружения конфигурации почтовыми клиентами и некоторые другие.
То есть просто запускаете сервер и по его инструкции добавляете DNS. Всё, больше ничего делать не надо.
2️⃣ Сервер включает в себя все современные протоколы и технологии, публичные списки репутации IP адресов (лучше отключить), некоторые алгоритмы для борьбы со спамом с обучением, а также Greylisting.
3️⃣ Сервер сам получает, обновляет и использует TLS сертификаты от Let's Encrypt. Ничего настраивать по этой теме не надо.
4️⃣ Сервер включает в себя очень простой веб интерфейс для админки и веб клиента. Скриншоты в конце статьи. Веб клиент, конечно, выглядит уныло. Но он хотя бы есть. Никто не мешает использовать любой другой - локальный Thunderbird или тот же RoundCube, настроенный отдельно или тут же на сервере.
5️⃣ Встроенный мониторинг в виде экспорта метрик в формате Prometheus с примерами готовых правил для триггеров.
🔴 Минусы:
1️⃣ Это проект одного человека. И хотя он очень продуктивен, проекту уже несколько лет, активная разработка продолжается, но тем не менее.
2️⃣ Никакую дополнительную функциональность к серверу не добавить. Что есть, тем и пользуешься. Никакого Sieve, Milter тут пока нет, хотя автор обещает реализовать если судить по roadmap.
3️⃣ Нет и не будет поддержки POP3. Мне кажется для таких небольших серверов его поддержка была бы актуальна для каких-то своих небольших или нестандартных задач.
Почта хранится в формате maildir. Это не плюс и не минус, а скорее стандарт для такого рода серверов. Можно просто зайти на сервер и посмотреть все письма в ящиках в текстовом формате.
В целом, решение мне понравилось своей простотой и скоростью настройки. Проще я вообще не видел. Чем-то похож на бесплатный Tegu, который тоже представляет из себя один бинарник на Go. У последнего нет поддержки ACME для автоматического получения сертификатов и работы с TLS. Нет такой удобной автонастройки, но по функциональности и возможностям настроек в админке он выигрывает. Тот же Milter поддерживает, Fail2ban.
Mox хорошо подойдёт для личного сервера, для разовых или простых задач, типа отправка почты с сайта, когда не хочется заморачиваться с настройкой, для небольшого коллектива. Поднял сервер, добавил пользователя и вперёд. Ставится он так:
В консоли увидите всю дальнейшую информацию по настройке DNS, а так же созданные учётные записи администратора и пользователя почты. Веб интерфейс отвечает только на localhost, поэтому для доступа туда надо сделать проброс портов по SSH со своей машины:
И далее идите по ссылкам localhost:8080/admin/ и localhost:8080/webmail/. Перед этим надо добавить службу в systemd:
Это полная инструкция по настройке. Достаточно добавить предложенные DNS записи и Thunderbird будет автоматически настраивать ящик по введённому логину и паролю.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver
✅ Плюсы:
1️⃣ Простая и быстрая установка. Весь сервер – это один скомпилированный бинарник, написанный на Go. Во время первого запуска нужно указать почтовый ящик администратора на том домене, где он будет работать. Сервер автоматически создаст все конфигурационные файлы, dkim ключ, покажет все необходимые DNS записи, которые нужно добавить. Там речь пойдёт не только про MX, SPF, DKIM, DMARC. Также будут показаны необходимые записи для работы MTA-STS, автообнаружения конфигурации почтовыми клиентами и некоторые другие.
То есть просто запускаете сервер и по его инструкции добавляете DNS. Всё, больше ничего делать не надо.
2️⃣ Сервер включает в себя все современные протоколы и технологии, публичные списки репутации IP адресов (лучше отключить), некоторые алгоритмы для борьбы со спамом с обучением, а также Greylisting.
3️⃣ Сервер сам получает, обновляет и использует TLS сертификаты от Let's Encrypt. Ничего настраивать по этой теме не надо.
4️⃣ Сервер включает в себя очень простой веб интерфейс для админки и веб клиента. Скриншоты в конце статьи. Веб клиент, конечно, выглядит уныло. Но он хотя бы есть. Никто не мешает использовать любой другой - локальный Thunderbird или тот же RoundCube, настроенный отдельно или тут же на сервере.
5️⃣ Встроенный мониторинг в виде экспорта метрик в формате Prometheus с примерами готовых правил для триггеров.
🔴 Минусы:
1️⃣ Это проект одного человека. И хотя он очень продуктивен, проекту уже несколько лет, активная разработка продолжается, но тем не менее.
2️⃣ Никакую дополнительную функциональность к серверу не добавить. Что есть, тем и пользуешься. Никакого Sieve, Milter тут пока нет, хотя автор обещает реализовать если судить по roadmap.
3️⃣ Нет и не будет поддержки POP3. Мне кажется для таких небольших серверов его поддержка была бы актуальна для каких-то своих небольших или нестандартных задач.
Почта хранится в формате maildir. Это не плюс и не минус, а скорее стандарт для такого рода серверов. Можно просто зайти на сервер и посмотреть все письма в ящиках в текстовом формате.
В целом, решение мне понравилось своей простотой и скоростью настройки. Проще я вообще не видел. Чем-то похож на бесплатный Tegu, который тоже представляет из себя один бинарник на Go. У последнего нет поддержки ACME для автоматического получения сертификатов и работы с TLS. Нет такой удобной автонастройки, но по функциональности и возможностям настроек в админке он выигрывает. Тот же Milter поддерживает, Fail2ban.
Mox хорошо подойдёт для личного сервера, для разовых или простых задач, типа отправка почты с сайта, когда не хочется заморачиваться с настройкой, для небольшого коллектива. Поднял сервер, добавил пользователя и вперёд. Ставится он так:
# useradd -m -d /home/mox mox
# cd /home/mox
# wget https://beta.gobuilds.org/github.com/mjl-/mox@v0.0.14/linux-amd64-go1.24.1/0Ip8URcp-Eig5CZORoGnm25XVWMo/mox-v0.0.14-go1.24.1
# mv mox-v0.0.14-go1.24.1 mox
# ./mox quickstart you@example.com
В консоли увидите всю дальнейшую информацию по настройке DNS, а так же созданные учётные записи администратора и пользователя почты. Веб интерфейс отвечает только на localhost, поэтому для доступа туда надо сделать проброс портов по SSH со своей машины:
# ssh -L 8080:localhost:80 root@212.193.58.29
И далее идите по ссылкам localhost:8080/admin/ и localhost:8080/webmail/. Перед этим надо добавить службу в systemd:
# chmod 644 mox.service
# systemctl enable $PWD/mox.service
# systemctl start mox.service
Это полная инструкция по настройке. Достаточно добавить предложенные DNS записи и Thunderbird будет автоматически настраивать ящик по введённому логину и паролю.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver
Решил проработать тему с бесплатными почтовыми серверами. Есть ещё 2, которые мне показались интересными. Один из них Mailu. Это практически стандартный почтовый сервер на базе популярных open source компонентов: postfix, dovecot, roundcube или snappymail, rspamd, clamav. Собран он в docker compose.
Админка самописная на python. В истории проекта рассказано, что хотелось как-то освежить и осовременнить стандартный стек почтового сервера. Для этого упаковали всё в контейнеры и заменили PostfixAdmin на новую админку. В принципе, разумный подход. Лично меня в качестве сугубо почтового сервера связка Postfix + Dovecot вполне устраивает. Настраивается просто, работает стабильно, возможности в рамках поддерживаемых протоколов максимальные. Для большей функциональности нужно придумывать свой протокол и почтовый клиент. Бесплатно такого нет. А на базе smtp и imap чего-то большего уже не реализовать.
Из особенностей именно Mailu - конструктор для построения конфигурации. Ответив на простые вопросы на тему имени домена, сервера, каких-то лимитов и т.д. вы получаете
За счёт того, что Mailu полностью упакован в контейнеры и заточен на работу в качестве микросервисного приложения, его можно использовать в Kubernetes. Для этого есть готовый Helm Chart.
По умолчанию Mailu использует SQLite. При желании можно перенести в PostgreSQL или MySQL. Почта хранится в формате maildir.
Я развернул и попробовал Mailu. Установка выглядит так:
1️⃣ Идём на setup.mailu.io и отвечаем на вопросы. В конце получаем готовый конфиг.
2️⃣Переходим в консоль сервера. Ставим Docker и загружаем конфигурацию:
3️⃣ Смотрим скачанные файлы, что-то можно подправить, заодно увидеть состав сервера. Там следующий набор контейнеров:
- redis
- nginx
- unbound
- admin (админка)
- dovecot
- postfix
- oletools
- rspamd
- fetchmail
- webmail (roundcube)
Запускаем:
4️⃣ После того, как весь стек запустится, создаём учётку администратора:
5. Можно идти по имени домена в веб интерфейс и выбирать, логиниться в админку или почтовый клиент. В админке есть русский язык. Выглядит она функционально и современно. Жаль, что она не оформлена отдельно. Я бы её вместо PostfixAdmin с удовольствием использовал.
TLS сертификаты будут получены и настроены автоматически. Для каждого пользователя есть свой личный кабинет, где он может посмотреть настройки для приложений, сменить пароль, включить автоответ, добавить учётку от внешнего сервера, с которого fetchmail будет забирать почту.
Сервер мне максимально понятен и близок по функциональности, потому что используется стек, который я хорошо знаю. Плюс сверху удобная админка. Из минусов лично для меня - Docker. Я почтовые сервера давно настраиваю и знаю, что если его раз настроил, то потом много лет не трогаешь. Он обновляется из пакетов стандартного системного репозитория. Ни масштабировать, ни куда-то переносить между разными окружениями, ни деплоить по 5 раз на дню его не придётся. Живёт он обычно в отдельной виртуалке.
Например, у меня сразу по какой-то причине не заработал веб интерфейс Roundcube. В логах контейнера ошибки:
Надо лезть в контейнер и разбираться, что там с ним не так. Без них было бы проще. А так я сходу даже не увидел, где и как используется этот порт. Судя по всему imap внутри другого контейнера не отвечает, но при этом он нормально опубликован во вне.
В целом сервер неплох. Рекомендую.
⇨ 🌐 Сайт / Исходники
#mailserver
Админка самописная на python. В истории проекта рассказано, что хотелось как-то освежить и осовременнить стандартный стек почтового сервера. Для этого упаковали всё в контейнеры и заменили PostfixAdmin на новую админку. В принципе, разумный подход. Лично меня в качестве сугубо почтового сервера связка Postfix + Dovecot вполне устраивает. Настраивается просто, работает стабильно, возможности в рамках поддерживаемых протоколов максимальные. Для большей функциональности нужно придумывать свой протокол и почтовый клиент. Бесплатно такого нет. А на базе smtp и imap чего-то большего уже не реализовать.
Из особенностей именно Mailu - конструктор для построения конфигурации. Ответив на простые вопросы на тему имени домена, сервера, каких-то лимитов и т.д. вы получаете
docker-compose.yml
и .env
. Можно их и вручную при желании сделать.За счёт того, что Mailu полностью упакован в контейнеры и заточен на работу в качестве микросервисного приложения, его можно использовать в Kubernetes. Для этого есть готовый Helm Chart.
По умолчанию Mailu использует SQLite. При желании можно перенести в PostgreSQL или MySQL. Почта хранится в формате maildir.
Я развернул и попробовал Mailu. Установка выглядит так:
1️⃣ Идём на setup.mailu.io и отвечаем на вопросы. В конце получаем готовый конфиг.
2️⃣Переходим в консоль сервера. Ставим Docker и загружаем конфигурацию:
# curl https://get.docker.com | bash -
# mkdir /mailu && cd /mailu
# wget https://setup.mailu.io/2024.06/file/890ef5ad-efc3-444d-834d-abd1424e8741/docker-compose.yml
# wget https://setup.mailu.io/2024.06/file/890ef5ad-efc3-444d-834d-abd1424e8741/mailu.env
3️⃣ Смотрим скачанные файлы, что-то можно подправить, заодно увидеть состав сервера. Там следующий набор контейнеров:
- redis
- nginx
- unbound
- admin (админка)
- dovecot
- postfix
- oletools
- rspamd
- fetchmail
- webmail (roundcube)
Запускаем:
# docker compose -p mailu up -d
4️⃣ После того, как весь стек запустится, создаём учётку администратора:
# docker compose -p mailu exec admin flask mailu admin adminuser mail.example.com PASSWORD
5. Можно идти по имени домена в веб интерфейс и выбирать, логиниться в админку или почтовый клиент. В админке есть русский язык. Выглядит она функционально и современно. Жаль, что она не оформлена отдельно. Я бы её вместо PostfixAdmin с удовольствием использовал.
TLS сертификаты будут получены и настроены автоматически. Для каждого пользователя есть свой личный кабинет, где он может посмотреть настройки для приложений, сменить пароль, включить автоответ, добавить учётку от внешнего сервера, с которого fetchmail будет забирать почту.
Сервер мне максимально понятен и близок по функциональности, потому что используется стек, который я хорошо знаю. Плюс сверху удобная админка. Из минусов лично для меня - Docker. Я почтовые сервера давно настраиваю и знаю, что если его раз настроил, то потом много лет не трогаешь. Он обновляется из пакетов стандартного системного репозитория. Ни масштабировать, ни куда-то переносить между разными окружениями, ни деплоить по 5 раз на дню его не придётся. Живёт он обычно в отдельной виртуалке.
Например, у меня сразу по какой-то причине не заработал веб интерфейс Roundcube. В логах контейнера ошибки:
FastCGI sent in stderr: "PHP message: PHP Warning: stream_socket_client(): Unable to connect to front:10143 (Connection refused)
Надо лезть в контейнер и разбираться, что там с ним не так. Без них было бы проще. А так я сходу даже не увидел, где и как используется этот порт. Судя по всему imap внутри другого контейнера не отвечает, но при этом он нормально опубликован во вне.
В целом сервер неплох. Рекомендую.
⇨ 🌐 Сайт / Исходники
#mailserver
У меня остался нерассмотренным из закладок один многообещающий почтовый сервер – Stalwart Mail Server. Посмотрел сайт, документацию, репозиторий на github. Показалось вначале, что это прям то, что надо. Прикинул, что бесплатная версия может заменить ушедшую Zimbra. Полноценно подготовил тестовый домен, сделал все DNS записи, развернул и стал тестировать. Изначально решил его не только для теста, но и на постоянку развернуть, если всё будет ОК.
Привлекли в первую очередь следующие возможности:
◽️Новый протокол JMAP.
◽️Огромный список бэкендов для хранения почты: RocksDB, FoundationDB, PostgreSQL, mySQL, SQLite, S3-Compatible, Azure, Redis, ElasticSearch. Такого просто нигде не видел.
◽️Полнотекстовый поиск на 17-ти языках. Нигде не видел полный список, но когда выбирал ru, ошибок не получал. Вроде как поддерживается.
◽️Аутентификация через OpenID, LDAP, OIDC, SQL, дополнительно 2FA-TOTP, отдельные пароли для аутентификации приложений.
◽️Всё остальное присутствует в полном объёме - все протоколы TLS, борьба со спамом, многодоменность, права доступа на основе групп, лимиты и ограничения, возможность гибко настраивать все этапы обмена сообщениями на уровне протокола и т.д.
По заявленным возможностям я и платных то серверов таких не найду, не то, что бесплатных. Внешне всё выглядит очень красиво.
Развернул я сервер по инструкции в Docker:
Сразу скажу, что не понравилось:
В выводе пусто. Логи так не посмотреть.
Дальше я начал очень долго возиться с тем, чтобы просто подцепиться к серверу через Thunderbird. Нигде в документации не указано, что для этого нужно. Методом проб и ошибок выяснил, что:
1. Проходить аутентификацию нужно только указав пользователя, а не полный почтовый ящик. Не очень понял, как это будет работать, если у пользователя будет несколько ящиков в разных доменах.
2. По умолчанию сервер запускается без TLS и вроде как работает. Thunderbird автоматом подбирает его настройки без шифрования. Но где-то в глубинах сервера в настройках smtp стоит параметр не разрешать аутентификацию без TLS. Включил TLS, запустил на самоподписанном сертификате, заработало.
3. Правильные настройки, с которыми я в итоге подключился: imap 143 STARTTLS, smtp 587 STARTTLS.
4. Логи сервера, которые можно посмотреть через веб панель администратора вообще никак не помогли решить проблему. Они неинформативны в части ошибок.
5. В веб интерфейсе администратора смешаны бесплатные и платные возможности.
6. Нигде нет простого способа посмотреть, от кого и к кому отправлено письмо, кроме как парсить общий лог.
7. У меня иногда не доставлялись письма от себя к себе. В логах пусто. Не стал разбираться с этой ошибкой.
В итоге я всё худо-бедно настроил, чтобы почта забегала, но потратил много времени. По функциональности и удобству админки ничего плохого не скажу. Реально много всего умеет, но некоторые полезные вещи за денюжку.
Отдельно скажу пару слов про JMAP. Протокол по описанию неплох. Письма и другие сущности обернули в json и отдают по HTTP через запросы к API. Модно и современно, но нужна поддержка клиентов. Особой популярности он пока не приобрёл. Из популярных клиентов поддерживает K-9 Mail, есть плагин для Roundcube.
Кому-то посоветовать сервер этот не могу. Только если вам нужны все его возможности. Он сильно не похож на всё, что я видел до этого. Настройки немного непривычны и нелогичны. Много нюансов. С сервером надо разбираться, сначала тестировать. Он не сказать, что сильно популярен, поэтому искать решение внезапных проблем будет негде. Если он наберёт популярность и некоторый пользовательский опыт, то будет неплохим решением.
⇨ 🌐 Сайт / Исходники
#mailserver
Привлекли в первую очередь следующие возможности:
◽️Новый протокол JMAP.
◽️Огромный список бэкендов для хранения почты: RocksDB, FoundationDB, PostgreSQL, mySQL, SQLite, S3-Compatible, Azure, Redis, ElasticSearch. Такого просто нигде не видел.
◽️Полнотекстовый поиск на 17-ти языках. Нигде не видел полный список, но когда выбирал ru, ошибок не получал. Вроде как поддерживается.
◽️Аутентификация через OpenID, LDAP, OIDC, SQL, дополнительно 2FA-TOTP, отдельные пароли для аутентификации приложений.
◽️Всё остальное присутствует в полном объёме - все протоколы TLS, борьба со спамом, многодоменность, права доступа на основе групп, лимиты и ограничения, возможность гибко настраивать все этапы обмена сообщениями на уровне протокола и т.д.
По заявленным возможностям я и платных то серверов таких не найду, не то, что бесплатных. Внешне всё выглядит очень красиво.
Развернул я сервер по инструкции в Docker:
# docker run -d -ti -p 443:443 -p 8080:8080 \
-p 25:25 -p 587:587 -p 465:465 \
-p 143:143 -p 993:993 -p 4190:4190 \
-p 110:110 -p 995:995 \
-v /var/lib/stalwart-mail:/opt/stalwart-mail \
--name stalwart-mail stalwartlabs/mail-server:latest
Сразу скажу, что не понравилось:
# docker logs stalwart-mail
В выводе пусто. Логи так не посмотреть.
Дальше я начал очень долго возиться с тем, чтобы просто подцепиться к серверу через Thunderbird. Нигде в документации не указано, что для этого нужно. Методом проб и ошибок выяснил, что:
1. Проходить аутентификацию нужно только указав пользователя, а не полный почтовый ящик. Не очень понял, как это будет работать, если у пользователя будет несколько ящиков в разных доменах.
2. По умолчанию сервер запускается без TLS и вроде как работает. Thunderbird автоматом подбирает его настройки без шифрования. Но где-то в глубинах сервера в настройках smtp стоит параметр не разрешать аутентификацию без TLS. Включил TLS, запустил на самоподписанном сертификате, заработало.
3. Правильные настройки, с которыми я в итоге подключился: imap 143 STARTTLS, smtp 587 STARTTLS.
4. Логи сервера, которые можно посмотреть через веб панель администратора вообще никак не помогли решить проблему. Они неинформативны в части ошибок.
5. В веб интерфейсе администратора смешаны бесплатные и платные возможности.
6. Нигде нет простого способа посмотреть, от кого и к кому отправлено письмо, кроме как парсить общий лог.
7. У меня иногда не доставлялись письма от себя к себе. В логах пусто. Не стал разбираться с этой ошибкой.
В итоге я всё худо-бедно настроил, чтобы почта забегала, но потратил много времени. По функциональности и удобству админки ничего плохого не скажу. Реально много всего умеет, но некоторые полезные вещи за денюжку.
Отдельно скажу пару слов про JMAP. Протокол по описанию неплох. Письма и другие сущности обернули в json и отдают по HTTP через запросы к API. Модно и современно, но нужна поддержка клиентов. Особой популярности он пока не приобрёл. Из популярных клиентов поддерживает K-9 Mail, есть плагин для Roundcube.
Кому-то посоветовать сервер этот не могу. Только если вам нужны все его возможности. Он сильно не похож на всё, что я видел до этого. Настройки немного непривычны и нелогичны. Много нюансов. С сервером надо разбираться, сначала тестировать. Он не сказать, что сильно популярен, поэтому искать решение внезапных проблем будет негде. Если он наберёт популярность и некоторый пользовательский опыт, то будет неплохим решением.
⇨ 🌐 Сайт / Исходники
#mailserver