Как написать свой почтовый сервер

Настраиваем домашний почтовый сервер и уходим с «бесплатной» почты

С каждым годом рекламы в интернете становится все больше, а подают ее с каждым разом все навязчивее. Дошло уже до почты: реклама в интерфейсе почтового ящика выглядит как первое непрочитанное письмо, которое машинально хочется открыть. Я не против рекламы, особенно когда она в тему и не сбивает с толку. Но маскировать её под непрочитанное письмо ‒ это перебор. Чувствуется, что следующим шагом рекламу начнут вставлять прямо в тело письма.

Мы уже привыкли, что наша активность в интернете анализируется для подсовывания релевантной рекламы. Но там нет персональных данных в чистом виде: есть пользователь-1 с такими-то привычками, есть пользователь-2 с другими привычками, пользователь-3, 4, 5 и т.д.

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

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

Но отказаться не так то просто:

• Можно завести ящик на другом почтовом сервисе, но там тоже не будет никаких гарантий отсутствия обработки писем.

• Можно арендовать виртуальный сервер в интернете и настроить его как почтовый сервер, но без физического доступа ваши письма никогда не станут только вашими.

• Можно сделать почту на каком-нибудь зашифрованном protonmail’e, но по этой же причине он стал так популярен у мошенников, что был заблокирован в этой стране.

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

Домашний сервер

Очевидно, что для почтового сервера нам нужен комп или его аналог, который будет доступен извне 24/7. Можно было бы посмотреть в сторону чего-нибудь компактного и маломощного типа Raspberry Pi, но т.к. мне нужен задел на будущее для других домашних систем, то я отдал предпочтение полноценному компу. На комп устанавливается гипервизор VMWare ESXi, а на нем уже живут виртуальные машины с необходимыми функциями и в том числе почтовый сервер. Такой подход дает дополнительную гибкость при проведении экспериментов и распределении ресурсов, а в случае чего виртуальные машины можно легко перенести на другое железо. Если нет особых требований к скорости работы, то для компа можно взять обычный HDD, т.к. от разделов подкачки виртуальных машин б/ушный SSD может быстро деградировать. Либо делать виртуальные машины без swap. Либо ставить два диска: основной диск виртуальной машины живет на SSD, а раздел подкачки на HDD. Компьютер я выбрал HP ProDesk 600 G2 SFF с процессором i5-6500: компактный корпус, достаточно низкое энергопотребление и ESXi на него устанавливается как родной. Все это хозяйство в режиме простоя потребляет 25 Вт, под нагрузкой 40-45 Вт. В частных объявлениях такой комп вполне реально найти за вменяемые деньги.

ESXi устанавливается со всеми настройками по умолчанию, затем сетевому интерфейсу присваивается статический IP. Более подробно и с картинками см. здесь.

Связь, электричество, бэкапы

Дома, в отличие от датацентра возможны перебои электричества, поэтому нужен ИБП с батареей на несколько часов работы сервера и роутера. От этого же электричества зависит работа оборудования внутридомового провайдера, поэтому ИБП для домашнего сервера не решает проблему отключения провайдерского оборудования и интернета вместе с электричеством. Получается, что на домашний роутер должно быть заведено два провайдера: основной (например, по витой паре или оптике) и резервный (через LTE модем). В разных роутерах процесс настройки выглядит по разному, но суть не меняется. Для резервного интернет-канала я взял LTE модем Huawei E3372-320. Свисток хорош тем, что есть в свободной продаже в разлоченном виде и он оснащен разъемами для внешних антенн, что в некоторых ситуациях может сильно улучшить качество связи.

Однако, с двумя провайдерами у вас будет два разных серых IP адреса, а почтовому серверу нужно нормальное доменное имя и по хорошему белый IP. Выход из ситуации у меня такой: арендуется виртуальный сервер (VPS) за границей, на нем настраивается VPN-сервер, а на почтовом сервере настраивается туннель до VPS. Кроме того, туннель можно поднять прямо с домашнего роутера (если он умеет) и таким образом ликвидируется сразу два зайца: мы получаем статический белый IP не зависящий от локальных провайдеров, а после тюнинга маршрутизации на роутере ‒ централизованный обход блокировок Роскомпозора для всех устройств домашней сети. Схема получается примерно такая:

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

Условные обозначения

В статье будут содержаться примеры конфигурации, в которых вам потребуется заменить некоторые значения на свои:

• Hostname (имя компьютера) почтового сервера ‒ mail

• Домен ‒ example.com

• IP адрес VPS сервера ‒ 1.2.3.4

• Локальная домашняя сеть 192.168.1.0 с маской /24 (255.255.255.0) и шлюзом 192.168.1.1

• IP адрес почтового сервера в локальной сети ‒ 192.168.1.3

• Внутри VPN тунеля IP адрес VPN сервера 192.168.77.1, IP адрес VPN клиента 192.168.77.3

Арендуем VPS, настраиваем VPN сервер

Есть куча разных VPS провайдеров, я выбрал vps2day.com, потому что они не просят персональные данные при регистрации, платить можно криптой, можно выбрать страну, где разместить сервер. Для целей VPN будет достаточно VPS в базовой конфигурации, который обойдется в 5 €/месяц. Сперва я зарегистрировал почтовый ящик на protonmail’e, а затем на него оформил аккаунт в vps2day, закинул крипту и арендовал VPS. В качестве ОС я выбрал Debian 10, через несколько минут после оформления аренды на почту приходит отбойник с IP адресом сервера и учетными данными для SSH подключения.

Логинимся, обновляемся:

apt update && apt upgrade

В качестве решения для VPN я выбрал Wireguard, но для установки на Debian 10 надо добавить его репозиторий в apt:

echo 'deb http://deb.debian.org/debian buster-backports main contrib non-free' > /etc/apt/sources.list.d/buster-backports.list
apt update
apt install wireguard

Создаем каталог для файлов конфигурации (если его вдруг нет), назначаем права доступа туда, переходим в него и генерируем закрытый и открытый ключи:

mkdir /etc/wireguard
chmod 700 /etc/wireguard
cd /etc/wireguard
wg genkey | tee privatekey | wg pubkey > publickey

На выходе получим два файла: privatekey с закрытым ключом и publickey с открытым ключом. Создаем файл конфигурации /etc/wireguard/wg0.conf вида:

[Interface]
PrivateKey = сюда вставляем значение ключа из файла privatekey
Address = 192.168.77.1/24
ListenPort = 51820
MTU = 1380

Чуть позже мы дополним этот файл, а пока едем дальше.

Регистрация домена, настройка DNS

При регистрации домена в зоне .RU нужно предоставлять паспортные данные, а делать этого не очень хочется… В международной зоне список необходимых для регистрации данных скромнее. Для регистрации можно указать все тот же ящик с protonmail’a. В качестве примера представим, что мы зарегистрировали домен example.com.

В редакторе DNS зоны нужно добавить «А» запись с именем mail и с указанием на внешний IP нашего почтового сервера, коим будет являться арендованный VPS:

Запись «MX» с приоритетом 10 и указанием на mail.example.com:

Запись «TXT» с SPF v=spf1 ip4:1.2.3.4 mx ~all :

Запись «TXT» DMARC v=DMARC1; p=reject; adkim=s; aspf=s; pct=100; :

Создание виртуальной машины

На ESXi создаем виртуальную машину (ВМ). Диск почтового сервера будем шифровать, поэтому нужно учесть один нюанс. По умолчанию гипервизор создает swap файл, равный размеру оперативной памяти виртуальной машины в каталоге ВМ. Таким образом есть вероятность, что ключ шифрования диска, хранимый в памяти ВМ во время работы окажется в swap файле на гипервизоре, что совсем не здорово. Чтобы этого не случилось, в настройках виртуальной машины нужно зарезервировать всю отведенную под ВМ оперативную память, тогда swap файл будет нулевой длины.

Установка системы и начальная конфигурация

В гостевой ОС вполне можно отказаться от раздела подкачки, особенно если назначить ВМ достаточное количество оперативки, а datastore гипервизора находится на SSD. Я взял Debian 10, процесс установки полностью стандартный за исключением разметки диска. Имя сервера задаем mail, домен example.com. Система ставится в минимальной конфигурации. В разметке дисков я сделал первый раздел под /boot и второй раздел с шифрованием:

После установки системы я делаю несколько базовых вещей. Удаляю созданного при установке пользователя командой deluser <username> --remove-home.

Задаю статический адрес, если это не было сделано во время установки. Для этого правим файл /etc/network/interfaces. Обратите внимание, что сетевой адаптер вашего сервера может называться по другому, в моем примере ens192. Секция файла с настройкой сетевого адаптера должна получиться такой:

allow-hotplug ens192
iface ens192 inet static
    address 192.168.1.3/24
    gateway 192.168.1.1

Для применения изменений выполняем команду (не забываем здесь заменить название сетевого интерфейса на свое):

ifdown ens192 && ifup ens192

Чтобы не углубляться в настройку домашних роутеров, VPN туннель мы будем делать сразу с почтового сервера до VPS и завернем туда весь трафик. Поэтому имеет смысл поменять DNS сервера на публичные. Для этого правим файл /etc/resolv.conf, конечный вид которого примет вид:

nameserver 1.1.1.1
nameserver 1.0.0.1

IPv6 я тоже отключаю, для этого в конец файла /etc/sysctl.conf добавляю строку:

net.ipv6.conf.all.disable_ipv6 = 1

Чтобы параметр применился выполняем команду:

sysctl -p

Проверить, отключился ли IPv6 довольно легко. Для этого нужно просмотреть вывод нижеследующей команды на наличие ipv6 адресов:

ip a

Устанавливаем ssh и wget:

apt install ssh wget

Включаю логин по паролю для root по SSH, для этого в файле /etc/ssh/sshd_config добавляем строку PermitRootLogin yes. Применяем изменения:

service ssh restart

Коннектимся к серверу по ssh и едем дальше.

Настройка VPN подключения

Устанавливаем wireguard на почтовом сервере так же как это делали на VPS несколькими шагами выше:

echo 'deb http://deb.debian.org/debian buster-backports main contrib non-free' > /etc/apt/sources.list.d/buster-backports.list
apt update
apt install wireguard
mkdir /etc/wireguard
chmod 700 /etc/wireguard
cd /etc/wireguard
wg genkey | tee privatekey | wg pubkey > publickey

Создаем файл конфигурации /etc/wireguard/wg0.conf следующего содержания:

[Interface]
PrivateKey = значение ключа из файла privatekey
Address = 192.168.77.3/32
MTU = 1380

[Peer]
PublicKey = значение ключа из файла publickey с VPS сервера
AllowedIPs = 0.0.0.0/0
Endpoint = 1.2.3.4:51820
PersistentKeepalive = 20

Теперь идем по SSH на VPS сервер и в файл конфигурации /etc/wireguard/wg0.conf добавляем:

# mail server
[Peer]
PublicKey = значение ключа из файла publickey с почтового сервера
AllowedIPs = 192.168.77.3/32

На VPS сервере в файл /etc/sysctl.conf добавляем строку net.ipv4.ip_forward = 1, чтобы разрешить форвардинг трафика, а чтобы применить эту настройку без перезагрузки, даем команду sysctl -w net.ipv4.ip_forward = 1.

На VPS создаем небольшой скрипт фаерволла, который будет срабатывать при каждом включении сетевого адаптера. Создаем файл /etc/network/if-up.d/firewall, содержимое файла спрятал под спойлер.

/etc/network/if-up.d/firewall

#! /bin/sh

EXT_IP="1.2.3.4"

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT

# Разрешаем пинги в разумных пределах
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT --match limit --limit 5/second
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT --match limit --limit 5/second

# Разрешаем SSH
iptables -A INPUT -d $EXT_IP -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -d 192.168.77.1 -p tcp --dport 22 -j ACCEPT

# Established connections
iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

# DNS
iptables -A INPUT -i eth0 -p udp -d $EXT_IP --sport 53 -j ACCEPT

# Wireguard
iptables -A INPUT -i eth0 -d $EXT_IP -p udp --dport 51820 -j ACCEPT
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -A FORWARD -o wg0 -j ACCEPT
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Выход в интернет для почтового сервера через VPS
iptables -t nat -A POSTROUTING -s 192.168.77.3 -j SNAT --to-source $EXT_IP

# Проброс портов к почтовому серверу через туннель
iptables -t nat -A PREROUTING -d $EXT_IP -p tcp --dport 80 -j DNAT --to-destination 192.168.77.3
iptables -t nat -A PREROUTING -d $EXT_IP -p tcp --dport 443 -j DNAT --to-destination 192.168.77.3
iptables -t nat -A PREROUTING -d $EXT_IP -p tcp --dport 25 -j DNAT --to-destination 192.168.77.3
iptables -t nat -A PREROUTING -d $EXT_IP -p tcp --dport 587 -j DNAT --to-destination 192.168.77.3
iptables -t nat -A PREROUTING -d $EXT_IP -p tcp --dport 143 -j DNAT --to-destination 192.168.77.3
iptables -t nat -A PREROUTING -d $EXT_IP -p tcp --dport 993 -j DNAT --to-destination 192.168.77.3

Не забываем сделать файл исполняемым командой chmod +x /etc/network/if-up.d/firewall

На VPS сервере запускаем wireguard:

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0

Возвращаемся на почтовый сервер и запускаем wireguard там:

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0

Состояние подключения можно посмотреть командой wg show. Если хоть какие-то данные в обоих направления пошли, значит все ОК и можно двигаться дальше:

Настройка почтового сервера

В интернете есть пара отличных гайдов по развертыванию почтового сервера на Debian: e-mail caramel и ispmail. Основная сложность настройки заключается в том, что нужно правильным образом сконфигурировать довольно много файлов и нигде не накосячить. Нужно настроить Apache, PostgreSQL, Postfix, Dovecot, rspamd, sieve, сгенерировать SSL сертификаты и DKIM, выставить права. Со знанием дела весь процесс занимает несколько часов, а у новичков может легко занять пару дней и не факт что все получится с первого раза.

По гайду «e-mail caramel» на выходе получается почтовый сервер с IMAP протоколом для клиентов с обязательным шифрованием STARTTLS и Nextcloud’ом в качестве webmail. Сервер убирает из писем мета-теги User-Agent и Received. Учет почтовых пользователей ведется в БД.

Чтобы не заниматься курением конфигов, а результат был предсказуем ‒ я сделал скрипт, который автоматизирует 90% всего процесса из вышеупомянутого гайда с некоторыми отличиями:

• Я не хочу ставить на почтовый сервер ресурсоемкий Nextcloud, вместо него я буду использовать Rainloop

• Подрежем еще несколько мета-тегов: X-Mailer, X-Originating-IP, X-PHP-Originating-Script, Mime-Version. При этом в оригинальном гайде фильтрация конфигурируется в master.cf, а у меня в main.cf

Скрипт устанавливает необходимые пакеты, конфигурирует apache, БД, конфигурирует почтовые службы и на выходе получается практически готовый к употреблению почтовый сервер. При этом я пока не стал включать в скрипт генерирование SSL и DKIM, сделаем это руками чуть ниже.

Скрипт пока не тестировался на корректность работы при многократном запуске. Если почтовый сервер у вас развернут как виртуальная машина, то перед выполнением лучше сделать снапшот ВМ.

Скачиваем и распаковываем скрипт:

wget https://github.com/alexmdv/mailserver-autosetup/archive/main.zip
unzip main.zip
chmod +x -R ./mailserver-autosetup-main
cd ./mailserver-autosetup-main

Всего в каталоге 3 файла:

• mailserver-setup.sh — основной скрипт конфигурирования сервера

• mailuser-addnew.sh — скрипт создания почтового юзера

• mailuser-setpass.sh — скрипт смены пароля для существующего почтового юзера

Запускаем mailserver-setup.sh. Скрипт попросит ввести следующие данные: имя хоста почтового сервера (в этом гайде это просто mail), имя домена, который был ранее зарегистрирован (например, example.com), IP адрес почтового сервера в локальной сети. Имя хоста + домен как раз образуют полное имя mail.example.com. По завершению работы скрипта почтовые сервисы остаются в выключенном состоянии, т.к. перед запуском надо сгенерировать SSL сертификаты и DKIM. Так же по завершению будет отображен админский пароль от БД. Этот пароль нужно вставить в скрипты mailuser-addnew.sh и mailuser-setpass.sh вместо слова PASSWORD, см в файлах вторую строку:

#!/bin/bash
pgadmpass="PASSWORD"

Генерирование сертификатов, завершение настройки

Генерируем SSL сертификат командой. Не забываем заменить example.com на свой домен:

certbot certonly --apache --agree-tos --email admin@example.com --no-eff-email --domain mail.example.com

Генерируем DKIM. В команде ниже вместе example.com ‒ ваш домен, а вместо 20210121 можно взять текущую дату (ггггммдд):

rspamadm dkim_keygen -b 2048 -d example.com -s 20210121 -k /var/lib/rspamd/dkim/example.com.20210121.key

Результатом выполнения команды будет такой текст:

20210121._domainkey IN TXT ( "v=DKIM1; k=rsa; "
	"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAumOhUcY3anZV4tGF1+VsYDD9bTZ0rqiFCm8FPdDHVB0U+ZPfZ2Cxf+x+jIFYXfO/jWEoAw2uYFz3Mt1ImvRQzU9oMx0t/0HtMKS4m3AhOBM5SkkhvoAaJkoIt3gTQ4KQyiBsZemihAw6V/gsex8K6M76m4WkbT92+tg192EGXBUDo0k7kk1rDOld0G9X2P0IxkVfqKqfwg+fI+0Im"
	"AOFC1gBCIm18XPEGZA2oOoNbkWO95bD8Rj20yv8639bMA27+B08v4/aPXQb9HZLEwpsz8Qa/WgEZFGJzd6kUaYWHTfMmbgBXnET5N+tjXGvkjtnLbx25ru/PZTeckGjE/komQIDAQAB"
) ;

В файл /etc/rspamd/dkim_selectors.map нужно добавить дату, чтобы получилось примерно так:

example.com 20210121

Идем в редактор DNS зоны у регистратора, добавляем запись «TXT» с именем 20210121._domainkey и значением v=DKIM1; k=rsa; p=... Дата в имени у вас будет своя, параметры перечисляются без двойных кавычек. Примерно так:

Тут есть нюанс. По умолчанию длина ТХТ записи может быть до 255 символов, а т.к. мы сгенерировали 2048 битный DKIM ключ, то его длина выходит за это ограничение и если вы внимательно посмотрите на результат генерации ключа, параметр p разбит на два, каждый из которых в своих двойных кавычках. Если регистратор поддерживает ТХТ записи большей длины, то две части можно просто схлопнуть, убрав кавычки. У GoDaddy, например, максимальная длина TXT записи 1024 символа. А если регистратор не поддерживает больше 255 символов, то ключ записывается в две ТХТ записи. Или можно сгенерировать более короткий ключ на 1024 бита.

Последнее что нужно сделать ‒ поправить файл /etc/postfix/master.cf. Необходимо раскомментировать строку:

#submission inet n       -       -       -       -       smtpd

И 4 вложенных параметра, начинающихся на «-o». Двойной пробел перед ними нужно сохранить. Последний параметр, возможно нужно будет просто дописать. На всякий случай в архиве со скриптом приложен готовый к употреблению файл master.cf. Должно получиться так:

submission inet n       -       -       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o cleanup_service_name=header_cleanup

Перезагружаем сервер.

Теперь заведем первый почтовый ящик. Для этого нужно воспользоваться скриптом mailuser-addnew.sh. Нужно будет ввести короткое имя (слово до @example.com), доменное имя (сам example.com) и пароль два раза. После этого можно попробовать настроить любой почтовый клиент используя созданную учетную запись.

В качестве примера пусть будет oleg@example.com. Для настройки почтового клиента набор параметров будет таким: почтовый адрес oleg@example.com, имя пользователя для IMAP и для SMTP так же oleg@example.com, сервер входящей почты IMAP mail.example.com, исходящей почты тоже mail.example.com, способ подключения везде STARTTLS.

Для проверки корректности настройки DKIM и SPF, можно воспользоваться ресурсом https://dkimvalidator.com, отправив туда тестовое письмо и посмотрев отчет. Все проверки должны быть в статусе pass (пройдено).

Устанавливаем Rainloop webmail

Все необходимые php модули для Rainloop уже были установлены скриптом. Скачиваем актуальную версию проекта, распаковываем, задаем права, включаем vhost на веб-сервере:

wget http://www.rainloop.net/repository/webmail/rainloop-community-latest.zip
unzip rainloop-community-latest.zip -d /var/www/webmail
cd /var/www/webmail
chmod 644 .
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chown -R www-data:www-data .
a2ensite webmail
service apache2 reload

Логинимся в админку rainloop по адресу https://mail.example.com/?admin с логином admin и паролем 12345. Пароль естественно надо будет сменить, это делается в разделе Security.

Далее добавляем наш почтовый сервер. Идем в раздел Domains, отключаем все прочие почтовые сервера и жмем по кнопке Add Domain:

Вводим параметры нашего домена и жмем Add:

Дополнительно в закладке Login можно так же указать домен:

Теперь можно пробовать заходить в webmail https://mail.example.com используя короткое имя пользователя (без @example.com):

Интерфейс выглядит лаконично, работает быстро, есть возможность настроить внешний вид под себя.

В качестве небольшого тюнинга безопасности Apache добавим пару строк в файл /etc/apache2/apache2.conf. Это скроет данные о версии веб-сервера:

ServerSignature Off
ServerTokens Prod

Для применения изменений перезагрузим Apache командой service apache2 reload.

phpPgAdmin

В БД mail_server есть три основные таблицы: alias, sharedmail_boxes, users. Все пользователи с хешами паролей хранятся в users. С помощью таблицы alias можно сделать псевдонимы к уже существующим почтовым ящикам, а с помощью таблицы shared_mailboxes можно сделать доступ к определенным ящикам для нескольких людей. Вход в phpPgAdmin по адресу http://локальный-ip-адрес-сервера/phppgadmin с логином postgres и паролем, который был сгенерирован скриптом.

Если нет нужды ковырять таблицы, то можно отключить сайт с phpPgAdmin вообще:

a2dissite lanhost
service apache2 reload

Бэкапы

Так как почтовый сервер я делал для себя и очень ограниченного круга людей, то много пространства серверу не нужно, емкость всего диска 20 Гб. Схема резервного копирования такая: один раз бэкапится виртуальная машина почтового сервера целиком, чтобы случае чего не настраивать сервер заново. А во вне делается бэкап почтового каталога. Естественно все бэкапы шифруем. Для копий каталога отлично подойдет VPS, у которого целых 25 Гб пространства, бэкапить буду с помощью restic. Но прежде надо настроить ssh подключение до VPS по сертификату.

На почтовом сервере генерируем RSA ключ, на все вопросы мастера просто жмем Enter:

ssh-keygen -t rsa -b 4096

Копируем открытый ключ на VPS:

cat ~/.ssh/id_rsa.pub | ssh root@192.168.77.1 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Устанавливаем Restic

apt install restic

Создаем репозиторий (копии будут храниться на VPS в каталоге /mnt/mserv-bkp):

restic -r sftp:192.168.77.1:/mnt/mserv-bkp init

Выполнение команды может занять несколько минут, в конце попросят придумать пароль для шифрования репозитория. Чтобы автоматизировать процесс создания резервных копий, создадим файл с переменными /root/.restic следующего содержания:

export RESTIC_REPOSITORY="sftp:192.168.77.1:/mnt/mserv-bkp"
export RESTIC_PASSWORD="Пароль придуманный на прошлом шаге"

Подхватываем файлик:

source /root/.restic

Попробуем выполнить резервное копирование почтового каталога:

restic backup /var/vmail

Проверяем, что в репозитории что-то появилось:

restic snapshots

Если есть наш только что созданный снапшот, то двигаемся дальше. Создаем файл /etc/root/restic с содержимым:

#!/bin/bash

source /root/.restic
restic backup /var/vmail

Делаем его исполняемым:

chmod +x /root/restic

И добавляем в /etc/crontab на запуск раз в сутки:

0 1 * * * root /root/restic

Заключение

Теперь настройку почтового сервера можно считать полностью завершенной.

Как видно, владение своим почтовым сервером стоит некоторых денег. Цена складывается из оплаты регистрации домена, аренды VPS, оплаты второго провайдера дома и в конце концов электричества. В моем случае получается в районе 950 ₽ в месяц за всё. С другой стороны резервный интернет канал и VPN будут полезны для всей домашней сети, но об этом мы поговорим в следующий раз.

Спасибо, что дочитали. Комментарии, вопросы, замечания и пожелания приветствуются!

Оригинал статьи в моем блоге.

Почтовый сервер, как следует из названия, — это устройство, которое отвечает за корректную доставку электронных писем от отправителя получателю. Так, например, когда вы отправляете почту через Gmail, вероятнее всего вы используете почтовый сервер Google. 

Почтовый клиент — это программа, которая используется непосредственно для работы с почтой: чтения, отправки и хранения. Примеры таких клиентов — Microsoft Outlook, Thunderbird и так далее. 

Протоколы для приёма и отправки почты

SMTP

Сервер исходящей почты использует протокол SMTP — simple mail transfer protocol — дословно переводится как «простой протокол передачи почты». Главная задача протокола — быть ретранслятором между отправителем и получателем. Она заключается в выполнении каждой из двух ключевых функций: проверять конфигурацию и разрешать отправку устройству-отправителю, отправлять сообщение и получать код ответа. 

SMTP-сервер использует 25 и 465 порты для отправки почты с шифрованием и без шифрования соответственно. 

POP3

POP3 (Post Office Protocol) — протокол для получения электронной почты. Он позволяет установить соединение с сервером и загрузить письмо на локальное устройство, чтобы отобразить его в почтовом клиенте. При этом на удалённом сервере информация не сохраняется (однако существует опция создания дублей).

Этот протокол использует 110 и 995 порты (без шифрования и SSL/TLS). 

IMAP

IMAP (Internet Message Access Protocol) — протокол с теми же задачами и функциями, что и POP3. Ключевое отличие в том, что IMAP позволяет работать с почтой непосредственно на сервере, без дублирования почты на локальное устройство. 

Используются порты 143 и 993 (без шифрования и SSL/TLS).

Зачем нужен собственный почтовый сервер? 

Чаще всего ответ на этот вопрос: «если настроить свой сервер, можно использовать свой домен в адресе электронной почты». Это верный, однако не совсем точный ответ. 

Настроить почту на своём домене вы сможете и без создания собственного сервера. Такую услугу, например, предоставляют VK Group, Яндекс.Почта и Google. Вам нужно только купить домен и привязать его к серверам компании в личном кабинете. 

Основное преимущество такого подхода — уже настроенный SMTP-сервер. То есть вам не придётся заниматься настройками переадресации, антиспам-фильтрами и прочими сложными настройками. Достаточно лишь грамотно указать NS-записи, а это не так сложно, как создать свой почтовый сервер. Кроме того, стоимость обслуживания и настройки гораздо ниже по сравнению с конфигурацией собственного сервера.

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

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

Создание почтового сервера

В этой статье мы рассмотрим способы создания собственного почтового сервера. Для наших целей отлично подойдут облачные серверы Timeweb — мы выберем себе устройство с ОС Ubuntu версии 20.04. 

Настроенная нами почта будет поддерживать шифрование, мы обеспечим защиту от спама, а также настроим панель администрирования писем в веб-среде.

Подготовка сервера

Первый шаг — переход в режим суперпользователя root:

sudo su

Перед установкой необходимого программного обеспечения обновим пакеты на сервере:

apt update && apt upgrade

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

hostname

Если в ответе вы видите что-то отличное от желаемого имени сервера, используйте команду hostnamectl:

hostnamectl set-hostname mail.hostname.ru,

где mail.hostname.ru — имя хоста.  

Далее для корректной работы всех планировщиков и непосредственно почты настраиваем временную зону — устанавливаем пакет для синхронизации времени chrony:

apt install chrony
timedatectl set-timezone Europe/Moscow

Если ваша временная зона отличается от МСК, выберите подходящую, воспользовавшись командой timedatectl list-timezones.

Запускаем chrony:

systemctl enable chrony

Теперь нужно открыть порты, необходимые для работы почтового сервера, с помощью утилиты iptables. Нам нужен следующий набор портов: 

1. 25, 465 — SMTP
2. 110, 995 — POP3
3. 143, 993 — IMAP
4. 80, 443 — HTTP 

В списке выше первыми идут порты для стандартных соединений, а вторыми — для защищённых. Воспользуемся утилитой iptables:

iptables -I INPUT 1 -p tcp --match multiport --dports 25,110,143,465,587,993,995,80,443 -j ACCEPT

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

netfilter-persistent save

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

Установка и настройка Postfix

Postfix — агент передачи почты (mail transfer agent) с открытым исходным кодом. Он имеет модульную архитектуру, которая не требует работы из-под суперпользователя root. Установим приложение postfix и postfix-mysql для работы с базой данных:

apt install postfix postfix-mysql

В диалоговом окне в процессе установки выбираем Internet Site. Это предполагает, что у вас есть доступ к редактированию DNS-записей и вы можете указать FQDN — полное имя домена. В следующем окне оставляем имя сервера и переходим далее. 

После установки создаём новую учётную запись в системе, из-под этого пользователя будем работать с почтой. С помощью утилиты groupadd создаём группу vmail:

addgroup -gid 1080 vmail

Далее создадим пользователя vmail и назначим ему домашнюю директорию /home/mail:

 adduser --home /home/mail -gid 1080 -uid 1080 vmail

… где 1080 — guid группы и uid пользователя. Если он занят, вы можете заменить его на любой другой. 

Проверим, что права на директорию /home/mail принадлежат пользователю vmail и группе vmail:

ll /home

Конфигурация почтового сервера

После создания пользователя можно приступить к настройке postfix. Для этого открываем файл /etc/postfix/main.cf в любом текстовом редакторе:

nano /etc/postfix/main.cf

… и редактируем строки:

mydestination = localhost.$mydomain, localhost, localhost.localdomain # Для каких доменов принимаем почту
Inet_protocols = ipv4 # протокол работы postfix
smtpd_tls_cert_file = /etc/ssl/mail/public.pem # путь до публичного сертификата.
smtpd_tls_key_file = /etc/ssl/mail/private.key # путь до приватного сертификата.

Далее в этот же файл дописываем дополнительные опции, которые необходимы для корректной работы Postfix:

virtual_mailbox_base = /home/mail # где будем хранить почту
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf # путь к псевдонимам 
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf # формат хранения доменов 
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf # формат хранения почтовых ящиков
virtual_minimum_uid = 1080 # минимальный идентификатор виртуального пользователя
virtual_uid_maps = static:1080 # идентификатор основного пользователя, от которого создаются сообщения
virtual_gid_maps = static:1080 # идентификатор группы, от пользователей которой создаются сообщения
virtual_transport = dovecot # регистрируем доставщик сообщений
smtpd_sasl_auth_enable = yes # разрешаем безопасную аутентификацию
smtpd_sasl_exceptions_networks = $mynetworks # не используем шифрование в сетях $mynetworks
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot # тип аутентификации
smtpd_sasl_path = private/auth # где лежат временные файлы 
smtp_use_tls = yes # шифровать соединение при подключении к другому SMTP-серверу
smtpd_use_tls = yes # поддерживаем подключение TLS
smtpd_tls_auth_only = yes # и используем только TLS
smtpd_helo_required = yes # начинаем сессию с HELO (или EHLO)



  


                       
  

Теперь создадим файлы, которые указывали в этой конфигурации. Сперва укажем, где Postfix должен брать псевдонимы. Открываем файл /etc/postfix/mysql_virtual_alias_maps.cf:

nano mysql_virtual_alias_maps.cf

… и записываем в него следующие строки:

user = postfix
password = postfixPa$$w0rd
hosts = localhost
dbname = postfix
query = SELECT goto FROM alias WHERE address='%s' AND active = '1'

Здесь dbname, user и password — база данных, имя пользователя и пароль для подключения к MySQL (настроим позже), query — шаблон запроса.

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

nano /etc/postfix/mysql_virtual_domains_maps.cf

Записываем:

user = postfix
password = postfixPa$$w0rd
hosts = localhost
dbname = postfix
query = SELECT domain FROM domain WHERE domain='%u'

Следом — файл с почтовыми ящиками:

nano /etc/postfix/mysql_virtual_mailbox_maps.cf

Записываем:

user = postfix
password = postfixPa$$w0rd
hosts = localhost
dbname = postfix
query = SELECT CONCAT(domain,'/',maildir) FROM mailbox WHERE username='%s' AND active = '1'

На этом этапе мы можем перейти к настройке файла master.cf:

nano /etc/postfix/master.cf

И записываем туда следующие настройки:

submission   inet  n  -  n  -  -  smtpd
  -o smtpd_tls_security_level=may
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=/var/spool/postfix/private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_local_domain=$myhostname
smtps   inet  n  -  n  -  -  smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject



  


                       
  



dovecot   unix  -  n  n  -  -  pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}

Генерация сертификатов безопасности

Для корректной работы почты нужно сгенерировать сертификаты безопасности с помощью утилиты openssl. В первую очередь создаём директорию, в которой будем хранить сертификаты (указывали в файле main.cf):

mkdir -p /etc/ssl/mail
openssl req -new -x509 -days 1000 -nodes -out /etc/ssl/mail/public.pem -keyout /etc/ssl/mail/private.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=mail.devnullhost.ru"

Запускаем и перезагружаем postfix:

systemctl enable postfix && systemctl restart postfix

Установка и настройка Dovecot 

Dovecot — IMAP и POP3 сервер с открытым исходным кодом. Установим его и модули для работы с БД:

apt install dovecot-imapd dovecot-pop3d dovecot-mysql

Настраиваем способ хранения сообщений:

nano /etc/dovecot/conf.d/10-mail.conf

Записываем в файл каталог для хранения почты. Будем использовать иерархию домен → пользователь:

mail_location = maildir:/home/mail/%d/%u/

В этом же файле настраиваем метод аутентификации:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
    group = vmail
  }
}
service stats {
    unix_listener stats-reader {
        user = vmail
        group = vmail
        mode = 0660
    }
    unix_listener stats-writer {
        user = vmail
        group = vmail
        mode = 0660
    }
}

Настраиваем аутентификацию в Dovecot:

nano /etc/dovecot/conf.d/10-auth.conf

Заменяем строку !include auth-system.conf.ext на !include auth-sql.conf.ext, указывая, что использовать нужно sql-авторизацию.

Редактируем настройки шифрования:

nano /etc/dovecot/conf.d/10-ssl.conf

В файле указываем:

ssl = required
ssl_cert = </etc/ssl/mail/public.pem
ssl_key = </etc/ssl/mail/private.key

При первом подключении пользователей создаём каталоги в домашней директории:

nano /etc/dovecot/conf.d/15-lda.conf

Добавляем строку:

lda_mailbox_autocreate = yes

Настраиваем подключение к базе данных:

nano /etc/dovecot/dovecot-sql.conf.ext

И добавим в него:

driver = mysql
connect = host=localhost dbname=postfix user=postfix password=postfixPa$$w0rd
default_pass_scheme = MD5-CRYPT
password_query = SELECT password FROM mailbox WHERE username = '%u'
user_query = SELECT maildir, 1080 AS uid, 1080 AS gid FROM mailbox WHERE username = '%u'
user_query = SELECT CONCAT('/home/mail/',LCASE(`domain`),'/',LCASE(`maildir`)), 1080 AS uid, 1080 AS gid FROM mailbox WHERE username = '%u'

Настраиваем интерфейс Dovecot:

nano /etc/dovecot/dovecot.conf

Указываем:

listen = *

Запускаем и перезагружаем Dovecot:

systemctl enable dovecot && systemctl restart dovecot

Установка и настройка PostfixAdmin

Для корректной работы PostfixAdmin нужен настроенный веб-сервер, PHP и база данных mariadb (стеки LAMP или LEMP). В этом руководстве пропустим конфигурацию веб-сервера и приступим непосредственно к установке PostfixAdmin.

Устанавливаем необходимые расширения php:

apt install php-mysql php-mbstring php-imap

Скачиваем PostfixAdmin в корневой каталог веб-сервера с помощью утилиты wget:

wget https://sourceforge.net/projects/postfixadmin/files/latest/download -O postfixadmin.tar.gz

Создаём каталог postfixadmin и помещаем туда содержимое архива:

mkdir /var/www/html/postfixadmin && tar -C /var/www/html/postfixadmin -xvf postfixadmin.tar.gz --strip-components 1

И создаём каталог для хранения кэша шаблонов:

mkdir /var/www/html/postfixadmin/templates_c

Ставим на весь каталог права веб-сервера:

chown -R www-data:www-data /var/www/html/postfixadmin

База данных

Создаём базу данных и пользователя:

mysql -u root

> CREATE DATABASE postfix DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
> GRANT ALL ON postfix.* TO 'postfix'@'localhost' IDENTIFIED BY 'postfixPa$$w0rd';
> exit;

В локальном файле конфигурации postfix добавим конфигурацию базы данных: 

nano /var/www/html/postfixadmin/config.local.php

Содержимое файла:

<?php
$CONF['configured'] = true;
$CONF['default_language'] = 'ru';
$CONF['database_password'] = 'postfixPa$$w0rd';
$CONF['emailcheck_resolve_domain']='NO';

Заходим на страницу установщика postfixadmin в браузере — /postfixadmin/public/setup.php. Здесь нам будет предложено сгенерировать хэш для авторизации.

Вводим пароль и нажимаем на кнопку. Под формой увидим сообщение, в котором содержится хэш, его мы должны вставить в файл /var/www/html/postfixadmin/config.local.php:

nano /var/www/html/postfixadmin/config.local.php

Обновляем страницу /postfixadmin/public/setup.php и входим на страницу с паролем, который вводили для генерации хэша. Если сервер настроен верно, в результате мы увидим страницу с проверками конфигурации. 

В самом низу расположена форма, в ней создаём админа. После успешного создания переходим на страницу /postfixadmin/public/login.php и авторизуемся в аккаунт, который только что создали.

В итоге вы будете перенаправлены на стартовый экран панели администрирования. 

Создаём почтовый ящик в PostfixAdmin

В браузере переходим по адресу /postfixadmin/public/. В верхнем меню выбираем «Список доменов → Новый домен». 

Далее в разделе «Обзор → создать ящик» вводим данные для тестового почтового ящика. 

Теперь вы можете проверить подключение с помощью почтовых клиентов. Параметры для подключения:

1. Сервер — имя вашего сервера
2. IMAP — 143 STARTTLS
3. POP3 — 110 STARTTLS
4. SMTP — 25 STARTTLS
5. Логин и пароль — данные, которые вы указали при создании ящика

Заключение

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

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

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

Предисловие

В Интернетах много разных очень крутых сервисов, которые позволяют сделать свой почтовый сервис с собственными адресами. Однако, захотелось приключений и появилась тяга к созданию чего-нибудь своего. Зачем что-то делать просто, если можно причудливо?

Предпосылки, что и зачем описал тут: статья

Постановка задачи

Захотелось сделать собственный почтовый сервис, чтобы письма отправлял/получал, рассылки делал и интегрировался с другими сервисами (чтобы клубная платформа Vas3k могла отправлять письма). Плюс имел бы веб-интерфейс для администрирования.

Описание проекта

В GitHub создал проект, с помощью которого можно создать собственный почтовый сервис за 10 минут, используя Docker. Посмотреть все исходники можно тут: MyDockerMailserver

Что же оно умеет:

• Поддержка POP3, IMAP, SMTP с авторизацией. А еще могут быть ящики, которые только отправляют письма, но не умеют получать.

• TLS enforced: использование SSL-сертификатов. Как самоподписанных (self-signed, так и кастомных).

• Веб-интерфейс для доступа в почту (Roundcube).

• Возможность задания правил фильтрации почты через веб-интерфейс (RSPADM).

• Защита от спама и вирусов в почтовых сообщениях Спам-фильтр сам тренируется при переносе сообщений в спам! А еще есть Real Time Black Hole Lists (RBL) для блокировки известных спамеров.

• Поддержка универсальных почтовых адресов (Aliasing).

• Поддержка квот на почтовые ящики пользователей. С уведомлениями о превышении.

• Поддержка DKIM подписи.

• Веб-интерфейс для администрирования всего этого добра.

• Поддержка отправки почты через RELAY HOST.

• и т. д.

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

Итак, если вы хотите создать свой почтовый сервис, но не обладаете достаточными знаниями в администрировании различных систем, то дальнейшая информация будет крайне полезна.

Необходимые средства для развертывания почтового сервиса:

• Сервер с Ubuntu и установленным Docker. Например, можно развернуть в Yandex.cloud, AWS, Azure, Digital Ocean.

• Доменное имя. (далее, для примера, будет использоваться несуществующее доменное имя domain.my).

• Wildcard SSL-сертификат для домена, либо выделенные сертификаты для sub-домена.

В статье предполагается, что почтовый сервис будет доступен по адресу https://mail.domain.my. При этом, на основном адресе будет развернут основной веб-сайт.

Автор использует обратный прокси jwilder/nginx-proxy для маршрутизации запросов туды-сюды по тому или иному адресу.

ШАГ 0

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

Чтобы обойти это недоразумение есть разные способы (наверное). Простой способ — это использовать Relay сервис по отправке сообщений. Автор остановился на сервисе SendInBlue, который на момент написания этих строк по бесплатному тарифу предлагает отправку 300 сообщений в день.

https://www.sendinblue.com

Настройка SendInBlue не должно быть какой-то проблемой. Важно это сделать для вашего домена. В итоге, на странице https://account.sendinblue.com/advanced/api будут доступным необходимые данные для настройки RelayHost.

Вот тута, в целом, написано неплохо: как настраивать SendInBlue.

ШАГ 1

Подключаемся на сервер через SSH любым удобным доступным способом.

На сервере нужен какой-нибудь редактор текстовых файликов. Т.к. автор не смог выйти из VIM, то он использует Nano.

ШАГ 2

• На сервере переходим в необходимую директорию

mkdir mailserver
cd mailserver

• Клонируем репозитарий в директорию (которую создали, но предыдущий шаг — необязателен).

git clone https://github.com/TopTuK/docker-mailserver.git

• Переходим в директорию, куда клонирован репозитарий

ШАГ 3

• Копируем файл .env.dist в .env и открываем его

cp .env.dist .env
nano .env

• Редактируем файл .env

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

MYSQL_DATABASE=mailserver # Название mysql базы. Оставляем как есть
MYSQL_USER=mailserver # Имя пользователя. Оставляем как есть
MYSQL_PASSWORD=changeme # Пароль от базы. Меняем на свой
MYSQL_ROOT_PASSWORD=changeme # Пароль от базы. Меняем на свой
MAILNAME=mail.domain.my # Меняем на свой домен, где доступен mailserver
POSTMASTER=postmaster@domain.my # Меням постмастера
RELAYHOST= # указываем relayhost. Если используется sendinblue, то '[smtp-relay.sendinblue.com]:587'
RELAY_PASSWD_KEY= # В случае sendinblue, то будет что-то вида 'user@domain.my:QQQYYYZZZ'
RELAY_OPTIONS=noanonymous # Для работы Relayhost
HEADER_SIZE_LIMIT=4096000 # Для работы Relayhost
FILTER_MIME=false
FILTER_VIRUS=true
ENABLE_IMAP=true
ENABLE_POP3=true
ENABLE_FTS=true
CONTROLLER_PASSWORD=changeme # Меняем на свой для доступа в RSPADM
WAITSTART_TIMEOUT=2m
RECIPIENT_DELIMITER=-
FTS_ARGS="partial=3 full=20 verbose=0 lowmemory=256"
FTS_VSZ_LIMIT=256M

ШАГ 4

Настраиваем использование своих SSL сертификатов

• Переходим в директорию certs: cd certs

• Создаем файлы сертификатов. Например, путем копирования их содержимого

Примечание: я сделал путем копирования содержимого файлов сертификатов, т.е. через Ctrl-C -> Ctrl-V. Название файлов с сертификатами может быть произвольным.

rm domain.*
touch mail.domain.my.crt
touch mail.domain.my.key
# Копируем содержимое сертификатов в созданные файлики. Например, через nano
cd ..

ШАГ 5

Конфигурируем файлы docker-compose.*

• Открываем на редактирование файл docker-compose.yml

• Редактируем docker-compose.yml

# Либо комментируем, либо удаляем
# ssl:
  # image: jeboehm/mailserver-ssl:latest
  # build: ./ssl
  # env_file: .env
  # volumes:
  # - data-tls:/media/tls:rw

• Добавляем свои сертификаты (для сервисов mda и mta)

...
# - data-tls:/media/tls:ro
# Uncomment lines below and change left part for using your own certificates
- ./certs/mail.domain.my.crt:/media/tls/mailserver.crt:ro
- ./certs/mail.domain.my.key:/media/tls/mailserver.key:ro
...

• Добавляем возможность интеграции с обратным прокси (jwilder/nginx-proxy)

...
# For use with jwilder/nginx-proxy. Uncomment this if you are using jwilder/nginx-proxy
environment:
  - VIRTUAL_HOST=mail.domain.my
...

• Удаляем или комментируем «лишний» volume, т.к. используем «свои» сертификаты

...
volumes:
  data-db:
  data-dkim:
  ...
  # Comment line below if you are using your own certificates
  # data-tls:
  data-filter:
  ...
...

ШАГ 6

На данном шаге требуется сделать последние шаги перед запуском почтового сервиса. Сконфигурировать production параметры. Редактируем параметры docker-compose.production.yml

• Комментируем раздел для сервиса web, т.к. используем обратный прокси

...
# Remove this block if you are using jwilder/nginx-proxy reverse proxy
# web:
  # ports:
    # - "0.0.0.0:81:80"
...

• Объединяем все почтовые сервисы в единую сеть

...
# Uncomment next block if you use jwilder/nginx-proxy reverse proxy
networks:
  default:
  # Set your network name
    name: mynetwork
...

ШАГ 7

Конфигурирование сделано. Настало время запустить почтовый сервис и убедиться, что все работает.

• Запускаем сервисы и дожидаемся выполнения каждой команды без ошибок.

./bin/production.sh pull
./bin/production.sh build
./bin/production.sh up -d

• Проверяем, что сервисы запущены и инициализированы. Выполняем команду docker ps. В результате, что-то должно быть похоже на:

ШАГ 8

На этом шаге требуется создать первого пользователя администратора

Выполняем команду ниже, а потом отвечаем на простые вопросы, следуя инструкции.

./bin/production.sh run --rm web setup.sh

ШАГ 9: Оно работает!

В результате выполнения всех шагов выше все сервисы должны заработать в PROD.

• Админка (при обращении к mail.domain.my -> потом авторизация администратора).

• Веб-интерфейс почтового клиента (mail.domain.my/webmail)

• Настройка спам-фильтра (mail.domain.my/rspadm). Пароль для доступа указывали в параметре CONTROLLER_PASSWORD.

Заключение

Вот так, с помощью нехитрых приобщений можно превратить буханку черного (или белого) хлеба в троллейбус построить свой почтовый сервер буквально за 5-10 минуты имея манипулятор типа мышь и клавиатуру.

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

Хотябы 1 раз в жизни админ сталкивается с настройкой своего почтового сервера. Настраивать всё по старинке, довольно долгое занятие и требует тщательного внимания. Сегодня поднимем всё необходимое в докер контейнере что избавит нас от лишних телодвижений.

Необходимые требования

Чтобы всё получилось нам понадобится:

• Сервер с Root доступом. Рекомендую вот этот
• На хостинге должна быть предусмотрена возможность менять PTR запись для своего домена
• Доменное имя. Можно бесплатный домен или поддомен
• Установленный Docker + Docker-Compose
• 30 — 60 минут времени

Предыстория

Какое то время назад мы с другом затеяли поднять игровой сервер Lineage 2. Разумеется что серверу был необходим форум. А для регистрации пользователей свой SMTP сервер. Ведь все письма отсылаются по протоколу SMTP. А получаются при помощи IMAP/POP. Тут то я и озадачился вопросом как поднять свой почтовый сервер. Я как раз тогда изучал Docker и наткнулся на интересный проект mailu, который позволял поднять свой почтовый сервер с нуля, буквально за пол часа.

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

• Open Source. Причём именно в том смысле в котором его принято видеть полностью бесплатен.
• Прост в эксплуатации.
• Есть веб-интерфейс для приёма и отправки почты.
• Работает с SSL сам получит необходимые сертификаты, либо есть возможность задать свои.
• Сгенерирует все необходимые DNS записи SPF, DMARC, DKIM. Которые потом просто добавить в виде DNS записей для своего домена.

Особенности почтового сервера

Установка почтового сервера предусматривает что Вы будете добавлять PTR запись, что в свою очередь приведёт к деанону ip адреса сервера из за специфики работы почтовых протоколов. Настоятельно рекомендуется ставить почтовый сервер на отдельной впске или сервере.

Предварительная настройка (PTR, DNS, ETC)

Первым делом нам понадобиться поменять PTR запись для домена, на котором мы планируем держать mailu. Это делается в интерфейсе вашего хостинга. В каждом хостинге это делается по разному, покажу как это сделано у меня.

В настройках сервера вписываем желаемый домен, для которого будет установлена PTR запись.

PTR запись может обновляться долгое время, зависит от хостинга и DNS. Проверить что она установилась корректно можно двумя способами

Первый способ nslookup

nslookup -type=PTR ip-адрес-вашего-сервера

Второй способ dig

dig -x ip-адрес-вашего-сервера

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

Желательно установить hostname для Вашего сервера. Впишите свой домен

sudo hostnamectl set-hostname mymailu.cf

Дополнительно добавим наш домен в /etc/hostname

sudo nano /etc/hostname

Как и в предыдущих статьях про докер контейнеры мы будем придерживаться правила — хранить все контейнеры в одном месте. Создаём необходимые директории для mailu

sudo mkdir -p /app/mail/mailu

Сделаем нашего пользователя (не root !) владельцем этой директории

sudo chown -R $USER:$USER /app/mail/mailu

На этом предварительная настройка завершена

Конфигурация mailu

Нам необходимо получить рабочий конфиг docker-compose.yml под свой сервер, поэтому отправляемся на страницу конфигурации mailu, выбираем что мы будем использовать compose и начинаем постепенно вводить свои данные.

Далее необходимо вписать данные для своего сервера, я приведу пример как это сделано у меня

Step 2 — Initial configuration

Mailu storage path:
/app/mail/mailu

Main mail domain and server display name
mymailu.cf

Postmaster local part
admin

Choose how you wish to handle security
выбираем letsencrypt

Authentication rate limit per IP for failed login attempts or non-existing accounts
по умолчанию

Opt-out of statistics
Включаем, если не хотим отсылать телеметрию

Website name
mail.mymailu.cf

Linked Website URL
https://mail.mymailu.cf

Enable the admin UI (and path to the admin UI)
Включаем и оставляем по умолчанию.

Step 3 — Pick some features

Enable Web email client (and path to the Web email client)
если хотим отдельный веб интерфейс для почты выбираем roundcube. Путь /webmail можно оставить по умолчанию.

Enable the antivirus service
по желанию можно включить антивирус, но он будет есть нехило ресурсов, если у Вас мощный сервер можно включить. Я предпочитаю его не включать.

Enable the webdav service
по желанию можно включить, для того чтобы была возможность использовать календари. У себя включаю.

Enable fetchmail
по желанию, включаю.

Step 4 — expose Mailu to the world

IPv4 listen address
вписываем ip адрес сервера.

Subnet of the docker network.
по умолчанию.

Enable IPv6
Я предпочитаю не включать.

Enable an internal DNS resolver (unbound)
Включаем.

Public hostnames
mail.mymailu.cf

Database preferences

Дабы слишком не усложнять этот и без того большой пост — выбираем sqlite

Наконец нажимаем Setup Mailu

Установка mailu

В результате конфигурации mailu нас перебрасывает на специальную страницу с нашими уникальными конфигами.

Отправляемся в директорию

cd /app/mail/mailu

И скачиваем наши уникальные сгенерированные конфиги

wget https://setup.mailu.io/1.9/file/ваш-уникальный-id/docker-compose.yml
wget https://setup.mailu.io/1.9/file/ваш-уникальный-id/mailu.env

Следующий шаг предполагает ревью кода из конфигов. Кстати тут можно заменить SECRET_KEY в фаиле mailu.env на состоящую из 16 рандомно последовательных символов. Для лучшей безопасности.

Третий шаг запуск контейнера

Находясь в папке с mailu стартуем наш стек контейнеров

sudo docker-compose -p mailu up -d

Начнется продолжительное скачивание и распаковка образов. А после этого будут подняты все необходимые для работы mailu контейнеры.

Иногда полезно сразу взглянуть на логи. Например выявить нет ли каких то проблем с letsencrypt.

sudo docker-compose logs -f front

Финализируем установку, задав пароль для учётки администратора

sudo docker-compose -p mailu exec admin flask mailu admin admin mymailu.cf PASSWORD

В ответ нам напишут что наш пользователь admin создан

Теперь можно переходить в веб панель у меня она располагается по адресу https://mail.mymailu.cf который я задавал на этапе конфигурации.

Авторизуемся вводя электронную почту admin@mymailu.cf и заданный пароль и нажимаем Войти Admin

Настройка mailu

Вся дальнейшая настройка mailu по большей части сводится к тому чтобы правильно прописать необходимые DNS записи. Но сначала я предпочитаю поменять язык на английский, чтобы было более универсально. Это делается сверху-справа наведя курсор на иконку языка.

Переходим в раздел Mail domains. Тут в разделе Actions нажимаем на кнопку гамбургер (3 полоски).

Тут необходимо сгенерировать необходимые днс записи. Для этого нажимаем на кнопку Generate keys. Нам будет выдано предупреждение с кнопкой Confirm, нажимаем её.

Мы увидим как добавились такие записи как публичный ключ DKIM, а также запись DMARC и другие. В любой момент мы можем перегенерировать эти записи нажав на кнопку Regenerate keys.

Следующим шагом будет установка всех этих данных в DNS.

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

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

sudo apt install dnsutils

Как я уже говорил ранее я почти для всех доменов использую cloudflare, поэтому буду показывать на его примере. Идём в настройки DNS домена и начинаем постепенно вводить свои данные. У меня домен mymailu.cf

MX запись

• Type: MX
• Name: @
• Mail server: mail.mymailu.cf
• TTL: Auto
• Priority: 10

Проверить MX запись можно в терминале командой

dig mymailu.cf MX

SPF запись

• Type: TXT
• Name: @
• TTL: Auto
• Content: v=spf1 mx a:mail.mymailu.cf ~all

Содержимое поля content берём из графы DNS SPF entries в mailu то что содержится в кавычках.

DKIM запись

• Type: TXT
• Name: dkim._domainkey
• TTL: Auto
• Priority: v=DKIM1; k=rsa; p=…

Содержимое поля content берём из графы DNS DKIM entry в mailu то что содержится в кавычках. А поле Name должно быть dkim._domainkey.

Проверить DKIM запись можно командой

dig dkim._domainkey.mymailu.cf TXT

DMARC запись

• Type: TXT
• Name: _dmarc.mymailu.cf
• TTL: Auto
• Priority: v=DMARC1; p=reject;…

Содержимое поля content берём из графы DNS DMARC entry в mailu то что содержится в кавычках. А поле Name должно быть _dmarc.mymailu.cf.

Проверить DMARC запись можно командой

dig _dmarc.mymailu.cf TXT

В результате заполнения DNS в cloudflare я получил такую картину

Добавляем пользователей / почтовые ящики

Для того чтобы добавить почтовый ящик отправляемся в пункт Mail domains и оттуда кликаем по иконке письма

Нажимаем Add User

Задаём:

• Адрес почты
• Пароль
• Отображаемое имя
• Комментарий
• Состояние ВКЛ / ВЫКЛ
• Квоту в гигабайтах
• Возможность использования IMAP
• Возможность использования POP3

и нажимаем Save

Нам сообщат что почта успешно добавлена

Добавляем Catch-All filter

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

В mailu из коробки нет механизма catch-all. Однако можно воспользоваться хаком и тогда всё заработает. Для включения отправляемся в пункт Mail domains и оттуда кликаем по иконке символа собаки @.

В появившемся окне пишем в поле Alias символ %.
Обязательно нажимаем галку Use SQL LIKE Syntax(без нее не будет работать).

Затем выбираем в качестве Destination специально созданную почту для catch-all. У меня это test@mymailu.cf заполняем по желанию описание

После добавления если отправить например почту на ящик fweh3423423iuhfew@mymailu.cf то он будет попадать в test@mymailu.cf а если например отправить на admin@mymaily.cf которая существует, то почта попадёт именно туда.

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

Проверяем работу mailu

Настало время проверить корректность настройки mailu. Открываем сайт mail-tester.com. Этот сайт позволит нам делать 3 проверки в день так что используйте эти попытки экономно.

Попав на сайт нам сразу же будет предоставлена почта, на которую мы должны отправить тестовое письмо. Копируем эту почту и переходим в веб интерфейсе mailu в раздел Webmail.

Создаём новое сообщение и вставляем адрес почты, полученный с меилтестера. И нажимаем отправить.

Наконец проверяем результат

Дополнительно я отправил писмо на свой gmail ящик и оно сразу зашло в инбокс

Кстати, если планируете отсылать письма по gmail’ам не лишним будет добавить свой домен на специальную страницу https://postmaster.google.com

Mission Completed!

Полезные ссылки

Офф Сайт

Офф Github

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Общее устройство и принципы работы почтового сервера

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

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

Их ровно три:

• Message transfer agent (MTA) — агент передачи сообщений. Данный компонент, собственно, и является почтовым сервером в узком понимании этого термина, он работает по протоколу SMTP и его основная задача прием и передача почтовых сообщений, как для внешних получателей, так и для внутренних. Взаимодействует как с внешними серверами, так и с почтовыми клиентами. И это единственный компонент почтового сервера, который имеет связь с внешним миром. Основная задача MTA — это отправка почты внешним получателям и получение почты для внутренних.
• Message delivery agent (MDA) — агент доставки сообщений. Он обеспечивает доставку полученных от MTA сообщений к месту прочтения клиентским приложением. Проще говоря, именно с помощью MDA почтовый клиент может получить доступ к собственной почте. Работает по протоколам POP3 и IMAP, также отдельные решения могут использовать проприетарные протоколы, такие как MAPI Exchange. MDA не взаимодействует с внешними системами и не принимает участие в отправке почты, его задача — доставка уже полученных сообщений клиенту почтовой системы.
• Хранилище почтовых ящиков — третий компонент почтового сервера, отвечающий за хранение полученных и отправленных сообщений. Различные системы могут использовать разные форматы хранения, в Linux системах наиболее распространены mbox и Maildir, но на этом варианты хранилищ не исчерпываются.

С почтовым сервером взаимодействует клиент электронной почты — Mail User Agent (MUA) — он может быть как в виде отдельного приложения, так и в виде популярного ныне веб-интерфейса. В любом случае это только разновидности почтового клиента, принцип их работы одинаков.

Когда пользователь хочет получить свою почту, он обращается к агенту доставки сообщений (MDA), сегодня MDA несут важную дополнительную функцию — ведение базы пользователей и их аутентификацию. Проверив, что пользователь тот, за кого себя выдает MDA предоставляет ему доступ к собственному ящику в хранилище при помощи выбранного пользователем протокола. Во всех современных решениях используется протокол IMAP, который позволяет гибко управлять собственным почтовым ящиком и не требует обязательного скачивания сообщений клиентом.

Если же мы хотим отправить почту, то почтовый клиент связывается с MTA, либо с дополнительным компонентом — Message submission agent (MSA) — агентом отправки почты, он использует отдельный порт — 587 и его задача получение сообщений от почтового клиента и передача их MTA для отправки по назначению. Вне зависимости от наличия MSA клиент всегда может отправить почту непосредственно через MTA.

Мы не стали добавлять MSA на основную схему, чтобы не плодить дополнительных сущностей, но о его существовании надо знать, чтобы не удивляться наличию дополнительного порта на почтовом сервере. Его появление во многом обусловлено ограниченностью протокола SMTP, тогда как для взаимодействия с клиентами нужны были дополнительные функции, поэтому MSA работает через протокол ESMTP (Extended SMTP) и поддерживает, например, такие возможности, как аутентификацию пользователей. Чаще всего функции MTA и MSA выполняет один и тот же пакет.

Теперь, читая, скажем, про связку Postfix + Dovecot + Roundcube вы будете четко понимать, что речь идет про MTA (Postfix), MDA (Dovecot) и веб-клиента MUA (Roundcube), представлять назначение каждого компонента и не путаться во взаимодействии с ними.

Обязательные DNS-записи: MX и PTR

Итак, мы хотим отправить почту. Пользователь открывает MUA, быстро создает сообщение и нажимает кнопку Отправить. Дело сделано, но мало кто задумывается о том, что происходит после, все мы привыкли что уже через считанные секунды наше сообщение будет в почтовом ящике получателя.

На самом деле сообщению предстоит достаточно длительный путь, сопровождаемый активной работой компонентов как сервера отправителя, так и сервера получателя. Но пойдем по порядку.

Первым в дело вступает MTA, он анализирует поле адреса назначения в заголовках письма, допустим мы видим там:

To: Maria Smirnova <MSmirnova@example.org>
From: Ivanov Ivan <IIvaniov@example.com>

Если домен получателя отличается от обслуживаемого MTA домена, то он должен каким-то образом узнать, кому именно отправлять почту. Для этого он использует систему DNS, запросив специальную запись — MX. MX — Mail Exchanger — особая DNS-запись, указывающая на адрес почтового шлюза домена, таких записей может быть несколько, они отличаются приоритетом, чем больше число — тем ниже приоритет.

MX-запись никак не связана с отправкой почты, но именно она указывает на узел, который уполномочен принимать почту в данном домене. Данная запись должна содержать именно имя узла, а не IP-адрес, после чего сервер-отправитель сделает еще один запрос, чтобы по имени хоста получить его IP-адрес. Данные записи прописываются администратором домена и в базовом варианте будут выглядеть так:

@ IN MX 10 srv-mx-01
srv-mx-01 IN A 203.0.113.25

Первая запись — это MX-запись для домена, которая говорит кому отправлять почту. Вторая запись сопоставляет имя srv-mx-01.example.com и действительный IP-адрес узла.

Часто администраторы предпочитают использовать псевдонимы — CNAME — для указания на отдельные почтовые узлы. Это удобно, но в любом случае MX-запись должна содержать реальное имя узла, а не псевдоним, поэтому правильно будет так:

@ IN MX 10 srv-mx-01
smtp IN CNAME srv-mx-01
imap IN CNAME srv-mx-01
srv-mx-01 IN A 203.0.113.25

Принимать почту в домене могут несколько серверов, или один, но на разных каналах. Допустим у нас есть основной канал и есть резервный, тогда набор записей будет выглядеть так:

@ IN MX 10 srv-mx-01
@ IN MX 20 srv-mx-02
srv-mx-01 IN A 203.0.113.25
srv-mx-02 IN A 198.51.100.25

Если сервер-отправитель не сможет отравить почту первому MX-серверу в списке, то он переключится на второй. Обратите внимание на разный приоритет серверов: 10 и 20, таким образом пока доступен сервер с приоритетом 10 почта никогда не будет направляться серверу с приоритетом 20.

А если мы укажем несколько серверов с одинаковым приоритетом? Почта будет направляться на все из них по принципу Round-robin, т.е., чередуясь по кругу, такое решение можно использовать для балансировки нагрузки.

C MX-записями разобрались, переходим к PTR. PTR — Pointer — соответствие адреса имени, позволяет на основании IP-адреса получить имя хоста этого узла. Какое это имеет отношение к отправке и получению почты? Да никакого, наличие или отсутствие PTR-записи никак не влияет на процесс отправки или получения почты. Но зачем же тогда она нужна?

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

Для кого следует прописывать обратную запись? Для имени узла, фактически отправляющего почту, вне зависимости от того, какие домены он обслуживает. Так один почтовый сервер может обслуживать множество доменов, но PTR-запись мы должны прописать для фактического имени хоста. В классическом виде PTR-запись будет выглядеть так:

25.113.0.203 IN PTR srv-mx-01.example.com.

Обращаем внимание на то, что в PTR всегда указывается полное доменное имя FQDN и обязательно с точкой на конце. Но это знание более академическое, так как обратной зоной будет управлять ваш провайдер и прямого доступа туда у вас не будет.

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

25.113.0.203 IN PTR srv-mx-01.example.com.
25.100.51.198 IN PTR srv-mx-02.example.com.

Почему? Да потому что сервера srv-mx-02 у нас физически не существует, мы придумали его как второе имя для основного сервера srv-mx-01 и в заголовках писем в качестве отправителя будет присутствовать именно это имя. Кроме того, как мы уже говорили, MX-сервера не имеют никакого отношения к процессу отправки почты.

Поэтому правильно будет сделать PTR-записи так:

25.113.0.203 IN PTR srv-mx-01.example.com.
25.100.51.198 IN PTR srv-mx-01.example.com.

И еще раз предупредим, все записи выше даны сугубо в академических целях, в реальности вам нужно будет только сообщить провайдеру (или провайдерам) для какого узла им нужно сделать PTR-запись.

SPF — Sender Policy Framework

SPF — это специальный тип DNS-записи в формате TXT, позволяющий владельцу домена указать те узлы, которые имеют право отправлять почту от имени домена. Эта запись не является обязательной, но ее наличие резко снижает вероятность попадания вашей корреспонденции в спам.

Чаще всего содержимое SPF сводится к стандартному:

@ IN TXT "v=spf1 +a +mx ~all"

Запись состоит из списка тегов и значений, теги в SPF-записи называются механизмами и могут иметь следующие значения:

• v — версия SPF, это обязательный механизм, сейчас доступно единственное значение v=spf1
• a — определяет узлы на основе доменного имени (A-записи), формат a:example.com, если домен не указан, то применяется текущий домен
• mx — определяет узлы на основе MX-записей домена, если домен не указан, то применяется текущий домен
• ip4/ip6 — определяет узлы на основе IPv4 или IPv6 адреса
• all — все остальные узлы
• include — включает в состав SPF-записи указанного домена, например, include:_spf.yandex.net
• redirect — использовать для домена SPF-записи указанного домена.

Для уточнения действий к механизмам применяются квалификаторы (префиксы):

• + — Аутентификация пройдена. Узлу разрешена отправка почты от имени домена.
• — — Аутентификация не пройдена. Узлу запрещена отправка почты от имени домена.
• ~ — Аутентификация с неполным отказом. Скорее всего, узлу запрещена отправка почты от имени домена.
• ? — Нейтральный квалификатор, обозначает что для узла нет явных указаний, обычно используется как ?all

Таким образом стандартная запись читается как: разрешено отправлять почту узлам перечисленным в A и MX записях домена, остальным, скорее всего запрещено. При аутентификации с неполным отказом письма от прочих узлов обычно не отвергаются получателем, а помечаются как подозрительные. Квалификатор «+» подразумевается по умолчанию и его можно не указывать. Если нам нужно указать несколько узлов, то используем несколько механизмов. Например:

@ IN TXT "v=spf1 a a:mail.example.org mx -all"

Здесь мы указали, что отправлять почту можно с узлов указанных в A и MX записях текущего домена, а также с узла mail.example.org.

Если у вас есть домены с которых никогда не должна отправляться почта, то не будет лишним указать для них следующую SPF-запись:

@ IN TXT "v=spf1 -all"

Теперь немного об include и redirect, может показаться, что они делают одно и тоже, но есть тонкости. Механизм redirect просто перенаправляет вас к записям указанного в нем домена. Это удобно, если сервер обслуживает сразу несколько доменов, это позволяет иметь одну единственную запись, которую будут использовать все остальные. Также это применяется при использовании своего домена совместно c публичными почтовыми системами:

@ IN TXT "v=spf1 redirect=_spf.yandex.net"

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

Если же вместе с публичными сервисами вы используете собственные сервера, то вам нужно использовать механизм include, который подгрузит записи указанного домена к вашим собственным.

@ IN TXT "v=spf1 ip4:203.0.113.25 include=_spf.yandex.net ~all"

Данная запись говорит о том, что отправлять почту имеет право узел с адресом 203.0.113.25, а также все остальные, которые перечислены в записях указанного домена.

DKIM — DomainKeys Identified Mail

Если говорить коротко, то DKIM — это технология электронно-цифровой подписи, которая позволят получателю убедиться, что письмо действительно принадлежит отправителю. Для этого на каждом почтовом сервере, которые отправляют почту в нашем домене мы генерируем ключевую пару RSA. Закрытый ключ мы добавляем в конфигурацию почтового сервера и теперь он будет подписывать все исходящие письма.

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

Для того, чтобы проверить подлинность подписи мы публикуем открытый ключ и используем для этого систему DNS, сформировав специальную запись типа TXT:

m1._domainkey TXT "v=DKIM1; k=rsa; p=<публичный ключ>"

Где m1 — селектор, он выбирается произвольно и должен быть уникальным для каждого почтового сервера, также селектор указывается в конфигурации почтового сервера при настройке подписи DKIM. Он нужен для того, чтобы получатель мог получить открытый ключ именно того сервера, который отправил данное письмо.

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

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

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC — это техническая спецификация, обеспечивающая единые механизмы проверки почты по SPF и DKIM, а также формирование и отправку отчетов. На первый взгляд выглядит сложно и непонятно, но на самом деле позволяет отправителю не только дать прямые указания что делать с почтой, но и получать обратную связь от получателей, что очень важно если вы только тестируете отправку почты.

В простейшем случае DMARC запись выглядит так:

_dmarc TXT "v=DMARC1; p=none; rua=mailto:report@example.com"

Запись состоит из тегов:

• v — версия DMARC, обязательный тег, в настоящее время единственное значение v=DMARC1
• p — правило для домена, указывает какое действие следует предпринять если письмо не прошло проверку, может иметь значения: none — ничего не делать, quarantine — поместить письмо в карантин, reject — отклонить письмо.
• sp — правило для субдоменов, принимает такие же значения, как и p.
• aspf и adkim — позволяют указать строгость проверки, по умолчанию используется мягкая проверка, при которой результат будет провален только при провале и SPF и DKIM, с помощью данных опций и значения s (strict) мы можем ужесточить проверку, и она будет провалена при провале только одной из указанных опций.
• pct — процент писем, подлежащих фильтрации DMARC, удобно для постепенного внедрения проверки, например, мы можем для начала указать 10% и потом по отчетам анализировать правильность настройки почтовой для отправляемых нами писем.
• rua и ruf — адреса для направления ежедневных отчетов о применении политик DMARC, при этом ruf используется для отчета только о письмах, не прошедших проверку.
• fo — определяет о каких не пройденных проверках сообщать владельцу домена, по умолчанию значение 0 — сообщать только если не пройдены проверки SPF и DKIM, 1 — если не пройдена хотя бы одна проверка, s или d — если не пройдена SPF или DKIM.

В самом простом варианте мы говорим получателям ничего не делать с не прошедшими проверку письмами и слать нам отчеты на указанный адрес.

Более сложная политика может выглядеть так:

_dmarc TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:report@example.com; ruf=mailto:admin@example.com; fo=1; pct=25"

Данная запись предписывает не прошедшие проверку письма основного домена отправлять в карантин, поддоменов — отклонять, сообщать если не пройдена даже одна из проверок и фильтровать 25% входящей почты. Отчеты присылать на указанные адреса, в нашем случае они разные. Общий отчет направляется в один почтовый ящик, отчет о не прошедших проверку письмах в другой.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

В этой статье мы рассмотрим установку почтового сервера iRedMail. Для этого нам потребуется VDS или выделенный сервер с ОС Linux. Подключаемся к своему серверу по SSH и приступаем к установке. 

Первым делом обновляем репозитории и пакеты:

apt-get update
apt-get upgrade -y

Для работы iRedMail необходим веб-сервер, поэтому следующим шагом устанавливаем его (в нашем случае это будет nginx):

apt-get install -y vim nginx

Далее получаем архив стабильной версии iRedMail (посмотрел на сайте разработчика):

wget https://github.com/iredmail/iRedMail/archive/1.1.tar.gz

Распаковываем его:

tar zxf 1.1.tar.gz.1

Переходим в директорию и запускаем скрипт:

cd iRedMail-1.1/
bash iRedMail.sh

“Welcome and thanks for your use” => Yes.
“Default mail storage path” => /var/vmail.
“Preferred web server” => Nginx.
“Choose preferred backend used to store mail accounts” => OpenLDAP.

Затем в блоке “LDAP suffix (root dn)” указываем домен. Причем сделать это нужно, записав каждую часть до точки, с префиксом “dc=”:

dc=mailtest,dc=tmweb,dc=ru

Я использовал тестовый домен mailtest.tmweb.ru (на этом шаге и далее вы вводите свой домен и пароли).

Задаем пароль для MySQL:

“Password for MySQL administrator: root” => 1A74oTnF

Указываем почтовый домен:

“You first mail domain name” => mail.299825-oiptwvds.tmweb.ru

Задаем пароль администратора:

“Password for the mail domain administrator” => m35Me6jy

Выбираем дополнительные компоненты:

“Optinal components” => Roundcubemail, netdata, iRedAdmin

Затем отобразятся несколько вопросов, соглашаемся:

“Continue» => y
“Would you like to use firewall rules provided by iRedMail?” => y
“Restart firewall now?” => y

И перезапускаем сервер:

shutdown -r now

Готово! Почтовый сервер работает и доступен по ссылкам:

• Roundcube (https://mailtest.tmweb.ru/mail/) — почтовый клиент.
• Netdata (https://mailtest.tmweb.ru/netdata/) — сбор и визуализация метрик в реальном времени.
• Web admin panel, iRedAdmin (https://mailtest.tmweb.ru/iredadmin/) — админка, в которой можно добавлять дополнительные домены и почтовые ящики.

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

Username: postmaster@mail.mailtest.tmweb.ru
Password: m35Me6jy

В дальнейшем, при необходимости, вы можете изменить пароль администратора через базу данных.

Существует большое количество программного обеспечения, позволяющего настроить работу почты по заявленным в начале требованиям: iRedMail, IndiMail, Rumble, Axigen, CommuniGate Pro и так далее. В зависимости от опыта на запуск уйдет от силы полчаса. 

Для компании среднего размера подойдут iRedMail, Axigen и Rumble. Если же у вас несколько удаленных офисов, стоит рассмотреть Axigen, IndiMail и CommuniGate Pro. В последний, к слову, включена функция VoIP, которая позволяет настроить IP-телефонию.