Арендованная почта у крупных сервисов удобна ровно до первого лимита: вложение больше разрешённого, ящик сверх тарифа, письмо из бэкапа на несколько гигабайт. Собственный сервер возвращает контроль над всеми этими гайками: сколько ящиков, какие вложения, где физически лежат письма и кто имеет к ним доступ. Плата за свободу известна: настройка за вечер и ответственность за репутацию адреса. В статье собирается рабочая связка Postfix и Dovecot на чистой Ubuntu Server 24.04: приём писем из интернета, отправка клиентами с аутентификацией, шифрованный IMAP и виртуальные пользователи, не занимающие ни одной системной учётной записи.
Когда собственная почта оправдана и что приготовить до установки
Честный расклад выглядит так. Один личный ящик проще арендовать у готового сервиса, своя инфраструктура тут не окупится. Другое дело домен с десятком адресов, небольшая организация или проект, где важны свои лимиты и полная принадлежность переписки: сервер за цену недорогого VPS закрывает эти сценарии и заодно снимает вопрос о том, где хранятся письма. До установки выполняют четыре подготовительных шага, и каждый экономит часы отладки:
- Домен с доступом к панели DNS, где будут созданы записи A и MX для почтового узла;
- Виртуальный сервер с открытым портом 25 в обе стороны, что проверяется у хостера до оплаты;
- Обратная запись PTR на адрес сервера, заказываемая в панели хостера, без неё крупные провайдеры бракуют письма;
- Полное доменное имя узла почты, смотрящее в DNS на адрес сервера, и синхронизация времени штатной службой системы.
Пункт про порт 25 не для красоты. Хостеры массово закрывают его новичкам из за спамерского прошлого сегмента, и узнавать об этом после оплаты неприятно. Вопрос в поддержку формулируется одной строкой: разрешён ли исходящий порт 25 на этом тарифе. Обратная запись ставится там же: имя из PTR обязано резолвиться обратно в адрес сервера, и это первое, что проверяет приёмная сторона любого крупного провайдера ещё до чтения письма.
Приём писем из интернета и базовый конфиг Postfix для домена
Транспортная часть ставится из штатного репозитория: Ubuntu 24.04 отдаёт Postfix ветки 3.8 и Dovecot ветки 2.3, для первого сервера этого достаточно. Установка умещается в одну строку:
sudo apt update
sudo apt install postfix dovecot-core dovecot-imapd dovecot-lmtpdДиалог установщика предложит тип окружения, для сценария с ручной правкой берут вариант Internet Site и указывают домен, его потом всё равно перепишут в конфиге. Пакет dovecot-lmtpd в списке не случайный: именно он даёт протокол передачи писем между транспортной и почтовой половинами связки. Межсетевой экран открывает ровно три порта: 25 для интернета, 587 для клиентов отправки, 993 для IMAP, остальное остаётся закрытым.
Основные параметры складываются в /etc/postfix/main.cf:
myhostname = mx.example.com
mydestination = localhost
virtual_mailbox_domains = hash:/etc/postfix/virtual_domains
virtual_mailbox_maps = hash:/etc/postfix/virtual_users
virtual_uid_maps = static:150
virtual_gid_maps = static:8
virtual_transport = lmtp:unix:private/dovecot-lmtp
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_tls_cert_file = /etc/letsencrypt/live/mx.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx.example.com/privkey.pem
smtpd_tls_security_level = mayТри строки здесь решают больше, чем кажется. mydestination ограничен localhost: настоящие домены обслуживаются виртуальными картами, и пересечение двух списков в классической ошибке уводит письма в локальную доставку мимо ящиков. Сертификаты выпускаются заранее клиентом Let's Encrypt на полное имя узла, уровень may разрешает TLS при любом рукопожатии, а принуждение к шифрованию включается отдельно на порту для клиентов. Параметры SASL указывают на сокет Dovecot: проверкой паролей занимается не Postfix, а сосед, и это снимает половину типовых конфликтов между двумя службами.
Быстрая самопроверка после правки файла делается командой postconf -n: она печатает только отличия от умолчаний, и по этому списку удобно сверять, что действительно прочитано из конфигурации, а что осталось в голове администратора. Разделение труда в связке стоит проговорить отдельно: Postfix ведёт маршруты и очереди, Dovecot хранение и пароли, и попытки научить одну службу делать работу другой заканчиваются лишней сущностью с неожиданным поведением.
Виртуальные ящики и домены в картах хэшей без системных пользователей
Виртуальная схема держится на двух текстовых картах и одном служебном пользователе. Пользователь vmail создаётся без оболочки и без прав, его идентификатор 150 и группа mail дальше указываются в картах:
sudo useradd -r -u 150 -g mail -d /var/vmail -s /usr/sbin/nologin vmail
sudo mkdir -p /var/vmail
sudo chown vmail:mail /var/vmail
sudo chmod 750 /var/vmailФайл /etc/postfix/virtual_domains перечисляет обслуживаемые домены, файл virtual_users сопоставляет адреса и пути хранения:
example.com OKАдрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. example.com/info/
Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. example.com/boss/Оба файла превращаются в хэши командой postmap, и повторять её нужно после каждой правки: транспорт читает только готовые хэши, и забытая пересборка держит пальму первенства среди ошибок первого дня. Работает схема так: письмо приходит на порт 25, транспорт сверяет домен с картой доменов, адрес с картой пользователей и передаёт письмо в сокет LMTP, где Dovecot раскладывает его по каталогу /var/vmail. Системные учётные записи не создаются вовсе, пароли ящиков живут в отдельной базе Dovecot, и новый адрес заводится одной строкой в карте. Формат хранения Maildir выбран не из моды: письмо ложится отдельным файлом в подпапку new, почтовый клиент при чтении переносит его в cur, и повреждение одного файла не рушит весь ящик, в отличие от монолитных форматов прошлого.
Для парков из десятков доменов текстовые карты сменяются таблицами в MariaDB или каталоге LDAP, но переход этот про масштаб, а не про возможности: хэши спокойно обслуживают сотни ящиков и делают сопровождение прозрачным.
Отправка клиентами через порт 587 с аутентификацией SASL от Dovecot
Порт 25 и порт 587 решают разные задачи, и смешивать их не стоит. Двадцать пятый слушает серверы интернета без всяких логинов, доверие там строится на DNS и репутации адреса. Пятьсот восемьдесят седьмой создан для людей и программ владельца домена: без логина с паролем туда не попасть, без шифрования тем более. За это отвечает секция submission в /etc/postfix/master.cf:
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_relay_restrictions=permit_sasl_authenticated,rejectСтрока ограничений читается как закон: разрешено только тому, кто прошёл аутентификацию, остальным отказ без разбора. Именно она убивает классический кошмар открытого релея, когда сервер по недосмотру рассылает спам от имени владельца. Проверка логина уходит в сокет Dovecot, соединение задаётся параметрами из main.cf, и после перезапуска служб порт готов принимать клиентов с паролем от виртуального ящика. В почтовых программах это выглядит скромно: сервер входящих на имя узла по порту 993, сервер исходящих там же по порту 587, галочка шифрования и логин с паролем ящика. Порт 465 в современных настройках не используют, он остался из старой эпохи, и стандартным портом отправки давно считается именно 587.
Dovecot с доставкой LMTP и шифрованным IMAP на порту 993
Dovecot в связке делает три работы: хранит письма, отдаёт их клиентам по IMAP и проверяет пароли для транспортной половины. Точки конфигурации умещаются в четыре файла. В 10-mail.conf описывается хранение:
mail_location = maildir:/var/vmail/%d/%n/Maildir
mail_privileged_group = mail
first_valid_uid = 150Формат пути читается как конструктор: %d подставляет домен, %n имя ящика, каждый адрес получает собственный каталог. В 10-auth.conf включаются механизмы plain и login, а строка disable_plaintext_auth = yes запрещает передачу пароля без шифрования. Сокеты описываются в 10-master.conf, и это самый ответственный блок:
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode = 0600
user = postfix
group = postfix
}
}
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0666
user = postfix
}
}Оба сокета живут внутри каталога Postfix, потому что транспорт в Ubuntu работает в изолированном окружении и видит только собственный spool. Наконец 10-ssl.conf включает обязательное шифрование строкой ssl = required и указывает на те же сертификаты Let's Encrypt, что и транспортная половина. После правок обе службы перезапускаются, и связка готова к первым проверкам.
Проверки openssl s_client и первое письмо во внешний мир
Прежде чем подключать людей, сервер проверяют руками. Соединение с IMAP выглядит так:
openssl s_client -connect localhost:993 -quietОтвет со списком возможностей и приглашением LOGIN означает живой порт с рабочим сертификатом. Для порта отправки проверка выглядит чуть иначе, с переключением в TLS после приветствия:
openssl s_client -connect localhost:587 -starttls smtp -quietВторой этап, отправка контрольного письма, выполняется утилитой sendmail с указанием отправителя и получателя. Дальше журнал /var/log/mail.log читается как книга: строка со статусом sent закрывает вопрос исходящей доставки, письмо, найденное в каталоге Maildir адресата, закрывает вопрос приёма, а ответ от внешнего сервиса на свежий ящик замыкает контур целиком. Терпеливое правило первой недели: тесты делаются снаружи и изнутри, с паузой на DNS. Записи домена разъезжаются по миру до суток, и половина якобы сломанных серверов первых дней на деле просто ещё не видны со стороны. Быстрая проверка со стороны делается утилитой dig: MX запись домена обязана указывать на имя узла, а обратное имя обязано совпадать с прямым.
Очередь транспортной половины заслуживает отдельного взгляда: команда mailq показывает письма в ожидании с причинами, пустой вывод означает, что всё ушло. Отложенные попытки повторяются автоматически с растущими интервалами, поэтому временный отказ получателя не теряет письмо, и это поведение экономит нервы при коротких сбоях на другой стороне.
Права на каталоги почты и грабли первой недели эксплуатации
Почти все сбои свежего сервера сводятся к правам, и короткая лестница проверок держится в голове целиком. Каталог /var/vmail принадлежит пользователю vmail с группой mail, права 750. Процессы Dovecot стартуют с максимальными правами и сбрасывают их до vmail, строка first_valid_uid разрешает именно этот переход. Сокеты в spool Postfix принадлежат пользователю postfix, иначе транспорт не достучится до соседа, и в журнале появится отказ с говорящим словом permission. Идентификаторы в картах, 150 и 8, обязаны совпадать с реальными из системы, расхождение роняет доставку молча.
Отдельный пункт заботы на будущее: каталог /var/vmail это и есть вся почта сервера, и его архивирование по расписанию отделяет аварию диска от катастрофы. Копируется он обычным tar в спокойное окно, база паролей Dovecot лежит рядом и входит в тот же архив.
Две привычки стоит завести с первого дня. Первая - продумать продление сертификатов: certbot умеет перезапускать службы после обновления, и одна строчка в настройке избавляет от ежеквартального ритуала с ручной копировкой файлов. Вторая - прикрыть перебор паролей: fail2ban с готовыми правилами для почтовых портов гасит волны подбора, которые начинают стучаться в 25-й и 143-й порты уже через час после появления сервера в DNS.
Три наблюдения из практики закрывают большинство обращений первой недели. Отказ доставки с упоминанием сокета почти всегда означает права сокета или забытый postmap после правки карт. Ругань на сертификат, как правило, опечатка в пути или не выпущенный сертификат на полное имя узла. Тихое оседание исходящих в спаме у крупных провайдеров при технически исправной работе означает отсутствие обратной записи или трёх DNS строк про отправителя, и лечится это настройкой репутации, а не конфигурации.
Дальше у собранного сервера два пути. Технический контур работает, письма ходят, ящики заводятся строкой в карте, и домену с парой десятков адресов этого хватает годами. Следующий уровень зрелости, записи SPF, DKIM и DMARC плюс антиспам, отделяет просто работающую почту от почты, которую уважают чужие серверы, и думать о нём стоит заранее, пока репутация адреса ещё чистая.
Скромный финал пути - резервная копия: карты виртуальных доменов и каталог Maildir архивируются штатным tar по расписанию, и восстановление на свежем сервере укладывается в час. Собранная своими руками почта тем и хороша, что в ней нет ни одного файла, происхождение которого неизвестно.