Почтовиков «на мыло»: переходим на личный почтовый сервер

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

Это, разумеется, не первая публикация на Хабре на эту тему. Тем не менее, я хочу поднять ее снова и поделиться личным опытом: рассказать, как я настраивала собственную почту, показать этот процесс от начала и до конца. Одна из моих целей — максимальная прозрачность, чтобы любой человек, следуя шаг за шагом, смог повторить всё описанное здесь и получить рабочий результат.

Перед тем как мы начнём, стоит ответить на вопрос: «А зачем вообще нужна своя почта?» Ведь у нас уже есть крупные почтовые сервисы вроде Gmail, Yandex, Mail.ru — они бесплатные, привычные, надёжные. Более того, в 2025 году почта многим вообще кажется анахронизмом. Кто ей пользуется? Кто читает письма?

И вот тут становится интересно. Если честно, у меня не так уж много аргументов, чтобы вас убедить. Когда‑то e‑mail был основным каналом связи, и люди ждали прихода нового письма. Сегодня же почти всё общение переместилось в мессенджеры — Telegram, WhatsApp, соцсети. Электронную почту массово захлестнул спам и маркетинговые рассылки. Казалось бы — всё, пора прощаться. Но… нет.

Электронная почта всё ещё остаётся базовым, универсальным и технически зрелым способом связи. Она понятна, совместима с чем угодно, и работает даже там, где ничего больше не работает. А главное — она не зависит от одного сервиса, компании или приложения.

Есть ещё более глубокий мотив — желание контролировать своё цифровое пространство. С развитием технологий каждый из нас в сети становится «не просто юзером», а цифровым профилем конкретного человека. И возникает естественное стремление иметь что‑то своё. Например, вместо того чтобы использовать Gmail, вы можете настроить свою собственную почту — и тогда никто не будет читать ваши письма, кроме вас. Никто не решит за вас, какие письма доставлять, а какие — фильтровать. Да, есть провайдер, есть маршруты, но вы становитесь самостоятельным участником цифрового мира.

Третья причина — самопрезентация. В адресе vasya@pupkin.space уже звучит индивидуальность. Это не просто красивая обёртка, а сигнал: «Я знаю, как всё это устроено». Отличный способ выделиться, особенно если вы специалист в сфере IT.

И наконец — любопытство. Мне лично было чертовски интересно. Разобраться, настроить, увидеть, как летит первое письмо — от меня самой, на мой домен. Это настоящее инженерное удовольствие.

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

Приступим!

Подготовка

Что нужно, чтобы сделать свою электронную почту?

Для начала посмотрим, как вообще устроена обычная электронная почта. Вот, например, адрес: vasya_pupkin@mail.ru. Вначале идёт никнейм (выбранное имя), затем символ @, а после — домен mail.ru.

mail.ru — это домен, за которым стоит чужой почтовый сервер. Нам же хочется уйти от зависимости от чужих сервисов (Mail.ru, Gmail, Yandex и др.) и настроить всё под себя. Для этого нужно зарегистрировать собственный домен в глобальной системе доменных имён.

В интернете есть множество сервисов, где можно арендовать домен и закрепить его за собой. Я не буду рекомендовать конкретную платформу — это была бы реклама. Выбор остаётся за вами. Аренда домена платная, но совсем недорогая. Цена чашки кофе за год обслуживания — это небольшая плата за вашу цифровую свободу.

Допустим, вы зарегистрировали домен. Теперь у вас есть, скажем, pupkin.space, и в перспективе ваша электронная почта будет выглядеть, например, так: vasya@pupkin.space.

Второе, что необходимо — арендовать VPS с белым (публичным) статическим IP-адресом. Теоретически, почтовый сервер можно было бы развернуть и на домашнем компьютере, но в большинстве случаев у пользователей провайдеры используют NAT. Это значит, что ваша машина не имеет постоянного внешнего IP-адреса — он может меняться, или быть вовсе недоступен извне. А для работы почтового сервера критически важно, чтобы его IP-адрес оставался стабильным и был доступен из интернета. Существуют способы обойти эти ограничения (например, с помощью туннелей или специальных прокси-сервисов), но в рамках этой статьи мы рассматриваем конфигурацию именно для полноценного статического IP-адреса. Возможно, в будущем я доработаю статью для домашнего сервера, но конкретно сейчас нам нужен VPS с белым статическим IP!

Кому-то такая необходимость может показаться неудобной, но на самом деле VPS — это довольно практичное решение. Это удалённый сервер, который работает круглосуточно, не тратит ваше электричество и освобождает вас от забот о стабильности соединения. И, что особенно приятно — на нём можно запускать не только почтовый сервер. Например, я со временем разместила там свой сайт-визитку — и до сих пор получаю удовольствие от того, что у меня все под контролем 🙂

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

Дело в том, что для почтового SMTP-сервера критически важен открытый 25-й порт. Многие бюджетные хостеры по умолчанию его блокируют — и, что хуже, могут не разблокировать даже по заявке. Поэтому обязательно заранее проверьте, предоставляет ли выбранный вами провайдер возможность работы с портом 25. Без него почта с вашего сервера просто не сможет быть отправлена.

После того как вы арендовали домен и VPS, у вас на руках должно быть две основные вещи:

• Доменное имя — например, pupkin.space, только ваше и в той зоне, которую вы выбрали (.com, .org, .ru и т.д.).

• Виртуальный сервер — машина с установленной Linux-системой (например, Ubuntu 20.04) и статическим белым IP-адресом. В этой статье мы будем использовать для примера IP 123.123.123.123.

Далее следует полная инструкция с пояснениями по настройке DNS и SMTP серверов. В ней pupkin.space нужно заменить на ваш домен, а IP-адрес 123.123.123.123 — на ваш белый IP от хостера.

Bind9 (DNS-сервер)

Перед тем как приступить к настройке, разберёмся, зачем вообще нужен DNS‑сервер и как он связан с доменом.

В интернете существует иерархия доменных имён. На самом верху — корневой домен (обозначается как .), от него идут домены верхнего уровня (TLD): .com, .net, .ru и т. д. Ниже располагаются домены второго уровня, например google.com. или mail.ru., затем — третьего уровня и так далее.

Каждый уровень иерархии обслуживается DNS‑серверами — это распределённая система, в которую входят:

• авторитетные (primary/secondary) DNS‑серверы, которые хранят полную информацию о конкретной зоне

• кэширующие (резолверы) — они запоминают ответы, чтобы ускорить последующие запросы

Когда, например, вы отправляете письмо на адрес в чужом домене, например, с mail.ru на gmail.com, ваша система должна определить IP‑адрес почтового сервера получателя. Для этого она формирует DNS‑запрос, который проходит через всю цепочку DNS‑серверов — от локального резолвера и выше по иерархии, пока не найдёт нужную зону, где указано, какой сервер отвечает за приём почты для этого домена.

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

Наша задача — встроиться в эту систему. Мы уже арендовали домен, теперь хотим, чтобы его обслуживал наш собственный DNS‑сервер, а не DNS‑сервер регистратора.

Для этого мы:

1. Настроим DNS-сервер (Bind9)

2. Опишем DNS-зону для нашего домена

3. Пропишем в ней, где находится наш почтовый сервер и какой у него IP-адрес

4. Передадим DNS-серверу управление нашим доменом

Приступим!

1. Установка DNS-сервера

Устанавливаем Bind9 на VPS:

sudo apt update sudo apt install bind9 bind9utils bind9-doc

2. Конфигурация сервера

Редактируем основной конфигурационный файл:

sudo nano /etc/bind/named.conf.local

Добавляем:

zone "pupkin.space" { type master; file "/etc/bind/zones/db.pupkin.space"; };

Помимо основного, стоит добавить несколько записей в файл опций:

sudo nano /etc/bind/named.conf.options

Пример содержимого:

options { directory "/var/cache/bind";  dnssec-validation auto;  allow-query { any; };  listen-on port 53 { any; }; listen-on-v6 { any; };  allow-recursion { none;}; recursion no; };

Это хорошие минимальные и безопасные настройки.

3. Файл зоны

Следующим шагом идет создание DNS-зоны.

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

Создаём директорию зон, если её нет:

sudo mkdir /etc/bind/zones

Создаём файл зоны:

sudo nano /etc/bind/zones/db.pupkin.space

Пример содержимого:

$TTL 604800 ; @INSOAdev.pupkin.space. admin.pupkin.space. (       3; Serial   604800; Refresh   86400; Retry  2419200; Expire   604800); Negative Cache TTL ; INNSdev INNSns2 INTXT"v=spf1 ip4:123.123.123.123 -all" INMX 5dev  dev     IN  A       123.123.123.123 ns2     IN  A       123.123.123.123 wwwINCNAMEdev

Пояснение к записям:

• $TTL (Time to Live) — время жизни записей в кэше других DNS-серверов. Показывает, как долго кэширующие серверы могут хранить данные зоны без повторного запроса. Значение применяется ко всем записям в файле. В данном случае записи будут храниться 7 дней (604800 секунд).

• SOA (Start of Authority) — обязательная и единственная запись, с которой начинается каждая зона. Указывает:

  • основной DNS-сервер зоны — dev.pupkin.space.

  • email администратора зоны — admin.pupkin.space. (точка вместо @)

  • а также включает следующие параметры:

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

    • Refresh, Retry, Expire, Negative Cache TTL — интервалы, которые определяют поведение secondary-серверов и кэширование ошибок.

• NS (Name Server) — указывает, какие DNS-серверы обслуживают зону:

  • dev — наш основной (primary) сервер

  • ns2 — резервный (secondary) сервер (если нет альтернатив, то это тоже наш сервер)

• TXT — универсальный тип записи. Здесь мы используем его для SPF (Sender Policy Framework) — механизма защиты от подделки отправителя. В записи "v=spf1 ip4:123.123.123.123 -all" говорится: письма от имени домена pupkin.space могут отправляться только с IP-адреса 123.123.123.123. Всё остальное — спам.

• MX (Mail Exchanger) — указывает, какой хост обрабатывает почту для домена. Мы пишем dev, что значит: именно этот сервер будет принимать входящую почту.

• A (Address) — связывает доменное имя с IP-адресом. Например, dev.pupkin.space. указывает на 123.123.123.123.

• CNAME (Canonical Name) — задаёт псевдоним: www.pupkin.space. будет перенаправлен на dev.pupkin.space.. Это удобно, чтобы не дублировать A-записи.

Примечание: в файле зоны имя dev мы можем указывать без полного доменного имени (dev.pupkin.space.), потому что внутри файла зоны все неполные имена интерпретируются относительно текущей зоны (pupkin.space.). То есть запись MX 5 dev автоматически понимается как MX 5 dev.pupkin.space. и тд.

DNS-зону, как правило, обслуживают два сервера: основной (primary) и резервный (secondary). Primary-сервер отвечает за зону и содержит основной файл зоны, а secondary-сервер поддерживает его копию и обрабатывает запросы, если основной недоступен.

Идеально иметь два отдельных сервера, но у нас только один. Есть несколько вариантов, как выйти из этой ситуации:

2. Попросить знакомого предоставить свой DNS-сервер в качестве secondary.

3. Указать оба — и primary, и secondary — на один и тот же сервер. Это не лучший вариант с точки зрения отказоустойчивости, но он работает и не требует второго сервера.

4. Использовать один сервер свой, а в качестве второго — сервер регистратора. Этот вариант я не рекомендую: регистраторы неохотно работают с внешними серверами, что может привести к дополнительным трудностям.

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

4. Проверка зоны и применение конфигурации:

После редактирования нужно убедиться, что файл зоны написан корректно:

sudo named-checkzone pupkin.space /etc/bind/zones/db.pupkin.space sudo named-checkconf

Если всё в порядке — перезапускаем сервер:

sudo systemctl restart bind9

Проверка статуса:

sudo systemctl status bind9

(выйти из просмотра — :q)

Если все хорошо, Bind9 покажет статус Active: active (running), если же сервер упадет, то надо еще раз проверить, нет ли ошибок конфигурации, после чего идти в логи:

sudo journalctl -u named.service -n 50

или

sudo journalctl -u named.service -f

(выйти из просмотра — Ctrl+C)

В качестве последнего штриха убедимся, что Bind9 слушает 53 порт и доступен извне.

sudo ss -lnptu | grep :53

Вывод должен быть примерно следующим (только больше):

udp   UNCONN  0      0       0.0.0.0:53       0.0.0.0:*    users:(("named",pid,fd)) tcp   LISTEN  0      10      0.0.0.0:53       0.0.0.0:*    users:(("named",pid,fd))

Проверим также настройки UFW (фаервол):

sudo ufw status verbose

Если вы не видите среди них разрешения на 53 порт, то его нужно добавить:

sudo ufw allow 53/udp sudo ufw reload

У вас может быть другой фаервол, если это так, подбирайте настройки соответственно.

5. Делегирование зоны у регистратора

Сейчас наш домен обслуживается DNS‑серверами регистратора. После того как мы настроили свой DNS‑сервер, мы должны делегировать зону ему. Для этого мы идем туда, где регистрировали домен, находим в личном кабинете меню с управлением DNS‑серверами и прописываем вместо первого из них наш свеженастроенный dev.pupkin.space, а вместо второго ns2.pupkin.space. Для первого и второго также прописываем IP 123.123.123.123 — такая опция должна быть в интерфейсе. Если ее нет, то обратитесь в поддержку и попросите прописать glue‑record. Это специальная запись, которая нужна, потому что dev.pupkin.space — это поддомен в той же зоне pupkin.space, которую он должен обслуживать, и без явного указания IP его невозможно разрешить (возникает замкнутый круг). С ns2 ситуация аналогична.

6. Проверка делегирования и работы DNS-сервера

Теперь нужно убедиться, что делегирование прошло успешно и наш DNS-сервер обслуживает домен. Для этого можно воспользоваться онлайн-сервисами:

• dnschecker.org

• Google Dig Tool

Второй вариант — использовать локальную утилиту dig. 

Ее можно установить следующим образом:

sudo apt install dnsutils

При помощи нее осуществляем проверки:

Проверка NS-записей:

dig pupkin.space NS +short

Ожидаемый результат:

dev.pupkin.space. ns2.pupkin.space.

Здесь мы видим оба наших DNS-сервера.

Проверка MX-записей

dig pupkin.space MX +noall +answer

Ожидаемый результат:

pupkin.space.INMX5 dev.pupkin.space.

Это означает, что почта для домена будет приходить на dev.pupkin.space..

Проверка SPF-записи

dig pupkin.space TXT +short

Ожидаемый результат:

"v=spf1 ip4:123.123.123.123 -all"

Если вы добавляли SPF-запись — она должна отобразиться здесь.

Проверка полной трассировки DNS-запроса

dig pupkin.space any +trace

Показывает полную цепочку разрешения — от корневых серверов до нашего DNS-сервера. Если трассировка не срабатывает локально, попробуйте сделать трассировку запроса через онлайн-сервисы.

Если вы по dig-командам или онлайн-сервисам получили соответствующие записи — это хорошо, значит зона отдалась 🙂

7. PTR-запись

В завершение стоит настроить PTR‑запись, также называемую reverse DNS (rDNS). Эта запись не обязательна для работы DNS‑сервера, но критически важна для почтового сервера — без неё почта с вашего IP‑адреса может массово блокироваться другими серверами.

Если A‑запись сопоставляет доменное имя с IP‑адресом, то PTR‑запись наоборот сопоставляет IP‑адрес с доменом. Благодаря этому получатель письма может проверить, что IP‑адрес, с которого пришло письмо, действительно соответствует доменному имени отправителя. Если такая проверка не проходит на стороне получателя, то ваше письмо может быть помечено как спам или отклонено.

PTR‑запись нельзя создать самостоятельно — её можно добавить только через провайдера VPS. Обычно это делается через поддержку: вы пишете письмо, указываете ваш IP‑адрес и доменное имя, которое хотите назначить, и просите настроить PTR‑запись. У разных хостеров процедура может отличаться, но обычно это делается в течение нескольких дней.

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

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

Способ 1: с помощью команды dig

dig -x 123.123.123.123 +short

Ожидаемый результат:

dev.pupkin.space.

Способ 2: с помощью команды host

host 123.123.123.123

Ожидаемый результат:

123.123.123.123.in-addr.arpa domain name pointer dev.pupkin.space.

Если вывод показывает нужный домен — всё работает. Если ничего не возвращается или указан домен провайдера — значит PTR-запись ещё не прописана.

На этом настройка DNS-сервера завершена. Теперь наш собственный DNS-сервер отвечает за домен и указывает, где находится почтовый сервер для приёма и отправки писем. Следующим шагом мы развернём уже непосредственно сам почтовый SMTP-сервер с помощью Postfix.

Postfix (SMTP-сервер)

SMTP‑сервер — это почтовый сервер, который использует протокол SMTP (Simple Mail Transfer Protocol) для отправки и получения электронной почты между почтовыми клиентами и другими серверами. Он отвечает за корректную доставку сообщений, маршрутизацию почты и взаимодействие с другими почтовыми системами в интернете.

В нашей почтовой архитектуре SMTP‑сервер будет обслуживать только локальных пользователей операционной системы Linux, то есть принимает почту исключительно для учётных записей, созданных непосредственно на сервере. У каждого такого пользователя есть собственный почтовый ящик — это либо файл /var/mail/vasya, либо, как в нашем случае, директория ~/Maildir/, если используется формат Maildir. Мы будем использовать именно его: каждое входящее письмо будет храниться в отдельном файле, что удобнее для чтения, фильтрации и резервного копирования.

Когда SMTP‑сервер принимает почту для конкретного пользователя, он помещает сообщение во внутреннюю очередь, выполняет базовую фильтрацию и доставляет его в соответствующий почтовый ящик. Адрес пользователя строится по схеме vasya@pupkin.space, где vasya — имя локальной учётной записи, а pupkin.space — домен, которым управляет наш сервер. Таким образом, почта обслуживается только для своих локальных пользователей внутри заданного домена.

О «своих» и «чужих»

Для нашего SMTP-сервера:

• «Своими» считаются локальные пользователи системы

• «Чужими» — все внешние адресаты и отправители из других доменов

SMTP-сервер может доставлять письма по принципу:

• «свои» → «свои»

• «чужие» → «свои»

• «свои» → «чужие»

но никогда!!! «чужие» → «чужие».

Разрешение пересылки «чужим от чужих» превращает сервер в открытый релей (open relay), за что он моментально попадает в черные списки, и восстановить его репутацию будет уже невозможно. Настройки, которые мы разберём ниже, надёжно защищают от этого, но настраивать Postfix следует очень внимательно.

1. Установка Postfix

Устанавливаем Postfix на VPS:

sudo apt update sudo apt install postfix

Во время установки система задаст несколько вопросов. Выберите тип конфигурации "Internet Site", а в качестве системного почтового домена укажите ваш домен pupkin.space.. Если в меню у вас не будет получаться выбрать Ok, попробуйте стрелочки влево-вправо.

2. Конфигурация Postfix

Редактируем основной конфигурационный файл:

sudo nano /etc/postfix/main.cf

Пример содержимого:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version  выйти из просмотра # Debian specific:  Specifying a file name will cause the first # line of that file to be used as the name.  The Debian default # is /etc/mailname. #myorigin = /etc/mailname  smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no  # appending .domain is the MUA's job. append_dot_mydomain = no  # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h  readme_directory = no  # See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on # fresh installs. compatibility_level = 2  # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_security_level=none  smtp_tls_CApath=/etc/ssl/certs smtp_tls_security_level=none smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtp_generic_maps = hash:/etc/postfix/generic  smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination  myhostname = dev.pupkin.space mydomain = pupkin.space myorigin = $mydomain alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases  mydestination = $myhostname, $mydomain, localhost  relayhost =  relay_domains =  mynetworks = host   mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = all

Комментарии к важным настройкам

• myhostname, mydomain, myorigin — задают имя хоста и домен, с которыми будет работать сервер.

• mydestination — список доменов, для которых этот сервер принимает входящую почту. Например, для пользователя vasya будут приниматься письма, отправленные на:

  • vasya@pupkin.space

  • vasya@dev.pupkin.space

  • vasya@localhost

• mynetworks = host — важнейшая настройка, определяющая, откуда можно отправлять письма. В данном случае разрешена отправка только с самого сервера. Это безопасно на первом этапе, когда мы будем использовать локальные утилиты вроде mutt для отправки.

• smtpd_relay_restrictions — строго определяет, кто имеет право на пересылку.

  • permit_mynetworks — разрешает отправку с локальной машины

  • permit_sasl_authenticated — авторизованные пользователи (например, при работе с IMAP/SMTP-клиентами в будущем)

  • reject_unauth_destination — всё остальное запрещается. Это основной щит от превращения сервера в open relay

Прежде чем отправлять письма, нужно также проверить работоспособность 25-го порта — это основной порт, по которому проходят SMTP-соединения.

Сначала проверим, слушает ли Postfix нужный порт:

sudo ss -tnlp | grep :25

Ожидаемый вывод — строка, где видно, что процесс master (Postfix) слушает порт 0.0.0.0:25 или [::]:25. Это означает, что сервер готов принимать подключения на всех сетевых интерфейсах.

Теперь проверим доступ к порту извне (с вашей локальной машины вне VPS):

telnet dev.pupkin.space 25

(из telnet выход QUIT)

или

nc -vz dev.pupkin.space 25

Если соединение устанавливается — отлично, порт открыт, всё работает.

Если же команда «висит» или завершается ошибкой вроде Connection timed out или Connection refused, есть два варианта: либо мешает фаервол, либо ваш хостинг-провайдер блокирует порт.

• В первом случае можно попробовать временно отключить или перенастроить UFW (или другой фаервол).

• Во втором случае — придётся писать в поддержку и подавать заявку на разблокировку 25 порта.

Некоторые провайдеры не разблокируют его вовсе — поэтому при выборе VPS об этом лучше уточнять заранее (!). К счастью, большинство адекватных хостеров этот порт открывают без проблем, особенно по запросу.

Далее проверим настройки UFW (если он используется):

sudo ufw status verbose

Если Status: active, и вы не видите разрешения на порт 25, надо добавить:

sudo ufw allow 25/tcp sudo ufw reload

Поделюсь опытом, у меня после настройки SMTP-сервера почта не ходила именно из-за UFW. Только после  добавления правилаsudo ufw allow 25/tcp я смогла отправлять и принимать почту.

3. Применение конфигурации

После внесения изменений:

sudo postfix check sudo systemctl restart postfix

Проверка статуса:

sudo systemctl status postfix

(выйти из просмотра — :q)

Если все хорошо, Postfix покажет статус Active: active, иначе идем в логи:

sudo tail -n 50 /var/log/mail.log

или

sudo tail -f /var/log/mail.log

(выйти из просмотра — Ctrl+C)

4. Создание пользователя

Наша работа по конфигурации почтового сервера подошла к следующему этапу — созданию пользователя. Если до этого момента мы настраивали только системные конфиги от имени root (как и положено в цивилизованном мире), то теперь пора перейти к реальному взаимодействию с почтовой системой, а для этого нам нужен пользователь, например, vasya.

Создаём пользователя в Linux:

sudo adduser vasya

Особое внимание стоит уделить паролю. Очень часто пользователи ставят что‑то вроде Vpupkin87, и кажется, что всё в порядке. Но если вы сидите на VPS с публичным статическим IP, такой пароль могут подобрать за несколько часов. Я, например, по наивности сделала слабый пароль и уже на второй день получила троян‑майнер, а вместе с ним — гневное письмо от хостера с требованием немедленно прекратить слать миллионы запросов, иначе мой сервер будет уничтожен.

Вывод: придумывайте пароль не короче 12–15 символов, состоящий из строчных и заглавных латинских букв, цифр и спецсимволов — и обязательно вперемешку!

Пример: UwFP7=5iC5TA.

Это не паранойя — это здравый смысл!

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

5. Маппинг email-адресов

Если вы хотите, чтобы письма от root или vasya@localhost выглядели как vasya@pupkin.space, создайте файл /etc/postfix/generic:

root@pupkin.space         vasya@pupkin.space vasya@localhost           vasya@pupkin.space

Затем:

sudo postmap /etc/postfix/generic sudo postfix check sudo systemctl restart postfix sudo systemctl status postfix

6. Переход на Maildir

По умолчанию Postfix использует формат mbox, при котором все письма одного пользователя хранятся в одном большом файле /var/mail/vasya. Это неудобно. Лучше использовать формат Maildir, где каждое письмо — отдельный файл в директории ~/Maildir.

Чтобы переключиться:

В /etc/postfix/main.cf в любое место необходимо добавить строку:

home_mailbox = Maildir/

После этого перезапустите Postfix:

sudo postfix check sudo systemctl restart postfix sudo systemctl status postfix

Установите maildrop, чтобы создать директорию Maildir:

sudo apt install maildrop

Создайте структуру Maildir для нужного пользователя (например, vasya):

sudo -u vasya bash maildirmake ~/Maildir maildirmake ~/Maildir/.Sent maildirmake ~/Maildir/.Drafts chmod -R 700 ~/Maildir exit

Теперь, когда вы отправите себе письмо, оно появится в ~/Maildir/new/.

На этом этапе базовая настройка SMTP‑сервера завершена. Остался последний штрих — подключение локального почтового клиента (mutt), чтобы можно было отправлять и читать письма прямо на сервере.

Mutt E-mail Client

Mutt — это лёгкий консольный почтовый клиент, идеально подходящий для серверов без графического интерфейса. Он не требует много ресурсов, работает в терминале и прекрасно справляется с базовыми задачами: чтение, отправка и организация почты.

Почему именно Mutt:

• Подходит для системной почты и повседневной работы на сервере

• Прост в установке и конфигурации

• Позволяет лучше понять внутреннюю механику email

• Поддерживает работу с Maildir и mbox, внешними MTA (Postfix, Sendmail и др.)

• Гибко настраивается через .muttrc

1. Установка mutt

Устанавливаем mutt под рутом:

sudo apt install mutt

2. Конфигурация mutt

Создаем файл конфигурации .muttrc для пользователя vasya: 

sudo nano /home/vasya/.muttrc

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

# Disable sorting set sort=mailbox-order  # Set the desired default "from" address for both header From and envelope-from set from="vasya@pupkin.space" set envelope_from=yes set use_domain=no  # Maildir set mbox_type=Maildir set folder="/home/vasya/Maildir" set spoolfile="/home/vasya/Maildir" set record="+.Sent" set postponed="+.Drafts"  # Recognize these as own addresses for displaying +/T/C marks on messages, as # well as for the reverse_name setting alternates "vasya@pupkin.space"  # When replying to or forwarding a message sent to a recognized own address # (see above), reuse the same full name and address that the message was # addressed to as the new "from" address set reverse_name=yes  # Maybe use ~/tmp instead of /tmp - useful when /tmp is on tmpfs, to not lose # edits on power failure set tmpdir="/home/vasya/tmp"  # Decode and/or decrypt messages when searching (much slower and prompts for # passphrase on first encrypted message encountered) set thorough_search="yes"  # Use this when "ispell" is actually the "aspell" wrapper (press "i" to invoke) set ispell="ispell --mode=email"  # By default, Mutt adds the original sender's address to Subject on forwards, # which we usually don't want set forward_format="Fwd: %s"  # Don't display these headers by default (press "h" to display full headers) ignore Delivered-To X-Delivery-ID X-Priority X-MSMail-Priority X-MimeOLE X-Spam-Checker-Version X-Spam-Level X-Spam-Status Precedence X-No-Archive List- DomainKey-Signature In-Reply-To User-Agent DKIM-Signature X-Google-Sender-Auth  # Highlight the obfuscated e-mail addresses in our RPM %changelogs, etc. color body brightcyan default "<[-a-z_0-9.+]+[- ]at[- ][-a-z_0-9.]+>"  # If you're using a local SpamAssassin bayes database, you might want to bind a # key, such as Shift-S on the index, to invoke sa-learn and mark messages as # deleted. #macro index S "| sa-learn --spam --no-sync --single\n<delete-message>" "spam learn"  # ...append /usr/share/doc/mutt-1.4*/gpg.rc to here #source ~/.mutt/gpg  bind pager <up> previous-line bind pager <down> next-line bind index F flag-message bind pager F flag-message bind index x sync-mailbox 

После редактирования достаточно сохранить и выйти.

Не забудьте под vasya создать директорию /tmp, иначе вы не сможете в mutt открывать письма.

sudo mkdir /home/vasya/tmp sudo chown vasya:vasya /home/vasya/tmp sudo chmod 700 /home/vasya/tmp

3. Использование mutt

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

mutt

Навигация и действия отображаются в верхнем меню. Почта будет храниться в ~/Maildir, а отправленные — в ~/Maildir/.Sent.

4. Тестирование

Финальным шагом будет полноценное тестирование работы вашей почты — как входящей, так и исходящей. Если у вас есть друг, готовый помочь — отлично. Если нет, используйте личные почтовые ящики, например, Gmail, Mail.ru или Yandex. Чем больше комбинаций вы проверите, тем выше вероятность, что конфигурация действительно работает корректно.

От vasya:

1. Заходим в mutt.

2. Нажимаем m (новое письмо), указываем получателя и тему.

3. Печатаем текст, затем ^X (если используете nano) и y, видим Mail Sent.

4. Идем в директорию ~/Maildir/.Sent/cur и убеждаемся, что там появилось наше письмо.

5. Убеждаемся, что письмо появилось у получателя на внешней почте.

Если что-то не сработало, идем в логи и ищем, по какой причине письмо не удалось доставить.

sudo tail -n 100 /var/log/mail.log

Для vasya:

1. Заходим на какую-нибудь имеющуюся почту на Mail.ru, Gmail или Yandex.

2. Отправляем письмо на vasya@pupkin.space.

3. Заходим в mutt и видим письмо, можем его прочитать.

4. Проверяем, что это письмо появилось в ~/Maildir/new.

Если письмо не пришло -> идем в логи.

Если оба направления работают — поздравляю, у вас функционирующий SMTP‑сервер, который способен как принимать, так и отправлять почту!!! Ура‑ура!!!

Заключение

В ходе этой инструкции мы развернули DNS‑сервер, полноценный SMTP‑сервер на собственном домене, создали локального пользователя, подключили почтовый клиент и протестировали приём и отправку писем. По сути, мы получили простую, но полностью рабочую альтернативу почтовым сервисам вроде Gmail, Yandex или Mail.ru — только теперь вся система под нашим полным контролем.

Этот результат — уже само по себе достижение. Даже в минимальной конфигурации почтовый сервер:

• функционирует в реальном домене

• обрабатывает письма локальных пользователей

• удовлетворяет базовым требованиям безопасности (в частности, не является open relay)

• прост в эксплуатации и открыт к дальнейшему развитию

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

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

Что в перспективе можно улучшить:

1. DKIM/DMARC. Для повышения доверия к вашей почте и защиты от подделки отправителей стоит настроить цифровую подпись DKIM и политику DMARC через конфигурацию DNS‑записей.

2. TLS. SMTP‑сервер на данном этапе не использует шифрование при передаче писем. Рекомендуется подключить поддержку TLS через Let's Encrypt и certbot, чтобы обеспечить безопасность вашей почтовой переписки.

3. IMAP-сервер. Сейчас вы читаете почту через mutt прямо на сервере. Чтобы подключать внешние почтовые клиенты и приложения, потребуется IMAP‑сервер (например, Dovecot), обеспечивающий синхронизацию писем.

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

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

Надеюсь, статья была вам полезна. Спасибо, что дочитали до конца!

Удачи вам в самостоятельной работе с почтовой инфраструктурой и дальнейшем изучении сетевых технологий!

До новых встреч!

Подготовлено в соавторстве с ByteRider