Почтовый сервер linux docker

Отправка почты из Docker-контейнера (докеризация postfix и sasl)

Когда я расположил приложение в Docker-контейнере и попробовал отправить email на почтовый сервер в другом Docker-контейнере, столкнулся с непредвиденной проблемой. Почтовый сервер postfix по умолчанию отправляет почту на произвольный домен получателя только от локального клиента. Все остальные домены нужно прописывать в параметре relay_domains, и если параметр mynetwors настроен правильно, то почта будет отправляться на перечисленные в параметре relay_domains домены с клиента из mynetwors.

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

Первым решением, которым я попробовал воспользоваться — это установить postfix вне контейнера Docker и оправлять на него прямо на порт 25 сообщения с клиента из контейнера Docker. Конечно, меня ожидало разочарование, т.к. localhhost внутри контейнера не имеет ничего общего с localhost вне контейнера.

Следовательно пришлось бы обращаться к postfix не через localhost. Да и изначально цель была такая, чтобы все нужное установить в контейнерах, и не зависеть от окружения на сервере. То есть postfix желательно было установить в контейнере.

Дополнительным плюсом установки postfix внутри контейнера является его полная закрытость от внешнего мира, если только явно не опубликовать его порт в docker-compose, что естественно легче контролировать, чем экзотические параметры в конфигурационных файлах самого postfix.

Для того чтобы можно было обращаться к postfix серверу, который работает внутри контейнера, нужно настроить авторизацию. Самым популярным решением является авторизация sasl. Я ее и решил настроить с использованием sasldb2. Как оказалось не так уж много подробных инструкций об установке sasl для postfix с использованием sasldb2. Некоторые инструкции содержали устаревшую информацию и не содержали нужных сведений. В результате, с первого раза авторизация упорно отказывалась работать. Как оказалось, две основные причины были: использование postfix сервером файловой системе в «песочнице» /var/spool/postfix/, о которой ничего не знает sasl, а также необходимость раздачи прав на файл базы данных /etc/sasldb2, который создает пользователь sasl — пользователю postfix.

Результирующий файл Dockerfile достаточно прост, хотя при поиске решения пришлось повозиться, в основном с правами пользователей, о чем я расскажу немного подробнее.

ln /etc/sasldb2 /var/spool/postfix/etc/sasldb2 По умолчанию postfix работет с файловой системой в «песочнице» /var/spool/postfix/. Там он будет искать файл с логинами /etc/sasldb2. Поэтому, задаем ссылку на файл /etc/sasldb2 из песочницы на реальный файл. Ссылка должны быть только жесткой (без параметра -s).

adduser postfix sasl вполне понятное и очень важно действие позволяет работать postfix с файлом /var/spool/postfix/etc/sasldb2.

Правило postconf -e «smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination» как раз и позволяет отправлять почту на произвольный домен всем прошедшим авторизацию sasl клиентам.

Конфигурация авторизации sasl в файле ./smtpd.conf:

Параметр postconf -e «mydestination = localhost» говорит о том, что почту для этого домена не отправлять дальше а принимать на этом хосте. Как показывает опыт, почтовые сервера, которые должны принимать почту, очень часто настроены неверно, теряют почту. Иногда это критично т.к. может вредить бизнесу, если почтовое сообщение содержит заявку клиента на приобретение товара или услуги. Поэтому данная конфигурация настроена на отправку копии локальному получателю postconf -e «always_bcc = www-arc@localhost» . Это получатель создается с идентификатором текущего пользователя useradd -u $UID www-arc .

Текущий пользователь определяется в конфигурации docker-compose:

При билде текущий пользователь передается из окружения env UID=$UID docker-compose build .

Для подключения из другого контейнера docker к этому сервису, необходимо в качестве хоста указать postfix (название сервиса из docker-compose.yml), а имя с учетом домена (postfix@example.com) и пароль. Во всех случаях имя postfix не является обязательным инастраивается в конфигурации.

Настройка почты на стороне приложения и на строне почтового сервиса это еще даже не половина того что необходимо сделать. Все что нужно сделать еще кроме этого в настройках домена часто лежит вне контроля разработчика или девопса, а у некоего специалиста с правами редактироваить учетную запись домена. С которым приходится общаться по испорченному телефону. Пока будет проходить неторопливый диалог в стиле «эй, ребята, смотрите там у себя, это ваш бэк» — ваш ip-адрес попадет в черные списки разных почтовых сервисов, откуда исключить их будет ой как непросто. Поэтому есть смысл сразу воспользоваться услугами платных почтовых сервисов, например, docs.aws.amazon.com/ses/latest/DeveloperGuide/postfix.html. Интегрироваться с ними можно через API, но с моей точки зрения более надежно сделать это через postfix (он собственно для этого и предназначен), задав параметр relayhost = [email-smtp.us-west-2.amazonaws.com]:587 . Более подробно интеграцию см. на сайте AWS (ссылка выше). Они как бы с одной стороны гарантируют непопадание вашего ip в черные списки а Вашей почты в спам, но зато сами могут объявить Вас спаммером в любой момент и заблокировать Вашу почту. Тоак что идельных решений не бывает.

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

Для обзора я воспользовался ключевой фразой в поиске Google «docker sasl postfix». Поэтому, если кто-нибудь посоветует еще какие-то репозитарии, я из включу в этот список.

Автор воспользовался не плагином postfix auxprop_plugin: sasldb , а стандартным средством sasl pwcheck_method: saslauthd . Это еще один дополнительный процесс который запускается в контейнере, и который не очень удобно конфигурировать, т.к. по умолчанию он выключен. Поэтому автор применяет в своей конфигурации такие вот конструкции:

Аналогично предыдущему используется pwcheck_method: saslauthd

Автор использовал sasldb2 с плагином postfix, но отключил механизм «песочницы»: smtp inet n — n — — smtpd , и для запуска процессов использовал supervisor, таким образом включив в контейнер несколько процессов.

4) github.com/catatnight/docker-postfix
Подобно предыдущему, автор откючил «песочницу»: postconf -F ‘*/*/chroot = n’ и использовал supervisor.

Использует плоский файл с паролями: echo «[$SMTP_SERVER]:587 $SMTP_USERNAME:$SMTP_PASSWORD» >> /etc/postfix/sasl_passwd

Отключает песочницу sed -i ‘s/^smtp\(\s*\)inet\(.*\)/docker_smtp\1inet\tn\ty\tn\t-\t-\tsmtpd -v/g’ «$MASTER»

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

Буду благодарен за дополнение этого списка репозитариев, и обещаю оперативно дополнять этот список по Вашим комментариям.

Источник

/4te.me

Тут опишу как поднять почтовый сервер на базе Postfix-а для рассылки почты. Также расскажу про DKIM, SPF, DMARC. Поднимать буду в docker-контейнере, потому что это просто и быстро.

Общая схема будет выглядеть так:

PTR-запись

Основное что нужно прописать, чтобы почта не попадала в спам-листы — это обратная запись PTR. Она должна указывать на сервер с которого будут отправляться письма. То есть, если мы отправляем письма с сервера mydomain.ru с IP-адресом 11.22.33.44, то PTR должна быть:

PTR-записи прописывается тем, кому приндалежит этот IP-адрес. Если это какой-то облачный провайдер, то в админке обычно есть редактор PTR-записей. В DigitalOcean создается автоматически по имени инстанса — имя должно быть FQDN:

SPF-запись

Это TXT-запись в DNS зоне домена в которой указываются адреса серверов с которых происходит отпарвка почты у данного домена. Когда почтовый сервер приемника получает письмо с адресом отправителя example@mydomain.ru он идет в DNS и проверяет SPF запись у домена example.com. Пример такой записи:

В данном примере:

• v=spf1 — версия SPF
• a — разрешить прием писем с адреса указанного в A записи example.com
• mx — разрешить прием писем с адреса указанного в MX записи example.com
• ip4:1.1.1.0/24 ip4:2.2.2.2 — разрешить прием писем из сети 1.1.1.0/24; разрешить прием писем с адреса 2.2.2.2
• ip6:2a03:b0c0:0:1010::424:8001/64 — то же самое что ip4, но для IPv6
• -all — отбросить письмо, пришедшее не от указанных адресов. Можно вместо -all указать

all, что значит — письмо не отбрасывать, но проверить остальными способами.

Все поля опциональные, не обязательно указывать все. Здесь есть более подробное описание синтаксиса SPF-записи: http://www.openspf.org/SPF_Record_Syntax

Механизм подписи всех писем цифровой подписьмю и проверки валидности подписи приемником. В общем виде работает так:

1. Генерируем пару приватный/публичный ключ
2. Кладем публичный ключ в TXT запись домена
3. Приватный ключ отдаем почтовому серверу postfix (ниже описано как настроить), и настраиваем чтобы он подписывал все письма этим ключом
4. Когда почтовый сервер получает письмо, он проверяет что подписано оно ключом из TXT записи домена

Настроим. Создаем пару ключей:

Добавляем TXT запись

Здесь: — v=DKIM1 — версия DKIM, всегда DKIM1 — myselector — селектор в самом домене. Может быть произвольным. Нужен чтобы на один домен можно было повесить несколько ключей. Запоминаем его — он понадобится при настройке Postfix — k=rsa — тип ключа; обычно — rsa — t=s — указывает на то, что письма не отправляются с субдоменов этого домена — p= — публичная часть ключа, которую генерировали выше

DMARC

DMARC — это тоже TXT запись в которой указывается политика для принимающего сервера, что делать с письмами не прошедшими проверку SPF и DKIM. Вот пример DMARC записи:

• v=DMARC1 — версия DMARC. Всегда DMARC1
• p=none — что делать с письмами не прошедшими проверку. Может быть none — ничего не делать, только слать отчет, quarantine — добавлять письмо в спам, reject — отклонять письмо.
• fo=0 — политика отправки отчетов; 0 — отправлять отчет только если письмо не прошло и DKIM и SPF; 1 — если не прошло или DKIM или SPF; s — не прошло SPF; d — не прошло DKIM
• rua=mailto:dmarc_reports@mydomain.ru — адрес на который будут слаться отчеты от почтовых серверов в случае обнаружения, не прошедших проверку, писем

Установка Postfix в docker-контейнере

Запустим контейнер с Postfix-ом и открытым 25 портом в который будет ходить наше приложение для отправки почты. Предлагаю воспользоваться уже собранным образом вот из этого репозитория — https://github.com/MarvAmBass/docker-versatile-postfix

Создадим на хост машине папки для DKIM, почтовой очерди и логов. Потом эти папки подмонтируем в контейнер:

DKIM приватный ключ (публичный в TXT записи), который генерировали выше положим сюда (имя обязательно такое):

По умолчанию в этом образе включен TLS, я его отключил в переменной POSTFIX_RAW_CONFIG_SMTPD_USE_TLS, потому что ходить в этот Postfix будут соседние контейнеры на этом же хосте. При необходимости можно опубликовать 25 порт контейнера на интерфейс локальной сети (но не в интернет!), чтобы приложение с соседних хостов могло посылать почту.

Теперь можно отправлять почту с хост машины, или прилинковывать к этому контейнеру соседние, чтобы они тоже получали доступ в 25 порт.

Проверить работоспособность можно маленькой утилиткой mail-checker http://github.com/fote/mail-checker. Она отправляет тестовое письмо на указанный адрес через только что поднятый MTA:

Или по старинке через nc / telnet:

Если все было настроено правильно, то письмо не должно попасть в спам, а если заглянуть в свойства, там будет примерно следующее:

Источник

Почтовый сервер mailcow через docker за 30 минут

Почтовый сервер mailcow через docker за 30 минут

Недавно наткнулся на довольно интересный комбаин из postfix-sogo-gui-панели для управления почтовыми сервисом. Называется он mailcow. В этой статье решил кратко описать как это все работает. Итак, приступим. Представим что нам надо настроить почтовый домен em.linux2be.com

Требования:

Пакеты

Доступные порты:

Эти порты можно поменять ниже в mailcow.conf, если они у вас уже заняты, например другими докер контейнерами.

Приступаем к установке

Запускаем генератор конфига.

Мы сгенерировали конфиг на основе которого будет собираться наша связка из докер-контейнеров

Посмотреть его можно в файле

Теперь приступим к сборке

Часть персистентных данных хранится в докерах volumes

Есле сервер на виртулке, и есть впс сервер, можно все спроксировать на него через nginx. Конфиг nginx тут.
Кладем его в /etc/nginx/conf.d/http_em.linux2be.com.conf

Для почтовых сервисов делаем такой конфиг.

Добавляем эту часть конфига вниз файла /etc/nginx/nginx.conf

Создаем каталог каталог /etc/nginx/stream.d

И создаем конфиг /etc/nginx/stream.d/mail_proxy.conf

Данные для входа

Логин – admin

Пароль – moohoo

Меняем его после входа

ЗАмена серфиката postfix на свой

Чтобы не ругалось на сертификат – меняем его в конфиге postfix data/conf/postfix/main.cf на свой.

Далее добавляем почтовые домены

Создаем почтовые ящики

Далее добавлем dkim. Выбираем длину ключа 2048

Добавляем сгенерированный ящик в relay host – не обязательно

Добавляем пароль для rspamd – не обязательно

Заходим в сгерерированнй почтовые ящики через

Теперь остается настроить нашу почту чтобы она не попадала в спам. Настройка dns записей. Почтовый домен будет em.linux2be.com

Добавляем записи A

Где сервере ip – ip вашего сервера или прокси

Dkim текстовые записи c именем селектора – dkim

Dmarc текстовые записи

Adsp текстовые записи(deprecated in 2013)

Настраиваем запись mx для почтового домена em.linux2be.com

Добавим A запись (если нет)

Добавим mx запись (если нет)

Добавим spf записи

Есть мастер генерации spf записей – можете воспользоваться им.

Создаем spf запись

Проверка mx записи

Проверка _dmarc записи

Регистрируем свой сервер в почтовом сервисе google

Добавляем txt запись предоставленную google и нажимаем далее.

Чекаем сервер здесь

7 thoughts on “ Почтовый сервер mailcow через docker за 30 минут ”

Спасибо! Очень помогла статья твоя.

Настрока прошла как по маслу. Спасибо за труды.

Спасибо! но подскажите:
– откуда IP адрес 10.47.0.15 (сервера или докера)?
– Где создаем каталог каталог stream.d ?

Дополнил мануал, чтобы было понятнее. И вот небольшие пояснения.

– 10.47.0.15 – это ip виртуалки, на котором мы создаем(запускаем наш почтовый сервер), если у вас виртуалка с внешним ip v4/v6 адресом, то эти шаги делать не надо;
– stream.d – этот каталог я создаю в папке /etc/nginx

Кто-нибудь в курсе как заставить Outlook 2013 взаимодействовать с MailCow? В инете нарыл только что нужно поменять /opt/ mailcow-dockerized/data/web/inc/vars.inc.php
‘userEASforOutlook’ => ‘no’ на ‘userEASforOutlook’ => ‘yes’
Но что-то это не помогло.

А что значит взаимодействовать ?

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник