Настройка почтового сервера: этапы развертывания и защиты

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

Ниже разберём настройку почтового узла на базе Postfix и Dovecot: от разделения ролей между компонентами до записей MX, PTR, SPF, DKIM и DMARC. Примеры рассчитаны на сервер с публичным IP и зарегистрированным доменом. Конкретные пути к файлам и названия служб могут отличаться в зависимости от дистрибутива.

Архитектура почтового узла: связка Postfix и Dovecot

Postfix работает как MTA, агент передачи почты. Он принимает SMTP-соединения, обрабатывает очередь и передаёт сообщения другим почтовым серверам или компонентам локальной доставки. Dovecot обычно предоставляет пользователям доступ к ящикам по IMAP или POP3, а также может участвовать в локальной доставке и проверке паролей для SMTP-аутентификации.

Эта пара популярна, но не обязательна как единая связка. Postfix можно настроить с другим механизмом SASL и другой системой локальной доставки. Dovecot, в свою очередь, может работать с почтовым транспортом, отличным от Postfix. При выборе архитектуры важнее определить границы ответственности и способ взаимодействия компонентов.

В типичной конфигурации задействованы:

• Postfix для SMTP-транспорта, очередей и правил приёма или ретрансляции.
• Dovecot для IMAP-доступа, управления почтовыми ящиками и, при соответствующей настройке, локальной доставки по LMTP.
• OpenSSL и TLS-сертификат для шифрования соединений.
• OpenDKIM или другой совместимый механизм подписывания для DKIM.
• DNS-хостинг для публикации записей домена. BIND нужен только в том случае, если администратор действительно размещает DNS-зону самостоятельно.

Почтовый путь полезно представлять как несколько отдельных операций. Входящее сообщение приходит на SMTP-порт Postfix, после проверки принимается в очередь, а затем передаётся локальному агенту доставки. Пользователь получает его через IMAP или POP3. Для отправки из почтовой программы клиент проходит аутентификацию на выделенном сервисе отправки, после чего Postfix передаёт сообщение дальше.

Такое разделение помогает искать неисправность по участку. Если пользователь не может войти в ящик, проверяют Dovecot, TLS и данные учётной записи. Если письмо не принимается извне, смотрят DNS, доступность SMTP и ограничения Postfix. Если исходящее сообщение поставлено в очередь, важны журналы MTA, доступность следующего узла и ответы удалённого сервера.

Конфигурация MTA и MDA: от SMTP-транспорта до SASL-авторизации

Основные параметры Postfix обычно находятся в /etc/postfix/main.cf. В конфигурации задают имя узла, обслуживаемые домены, локальные интерфейсы и ограничения ретрансляции. Например, myhostname указывает полное доменное имя сервера, mydomain задаёт домен, а mydestination перечисляет домены, почту для которых Postfix доставляет локально. Эти значения должны соответствовать реальной схеме: ошибка в mydestination может привести к неверной локальной доставке или к отказу принимать нужные адреса.

Часто используемые параметры:

• myhostname задаёт FQDN сервера, например mail.example.com.
• mydomain указывает домен организации.
• myorigin определяет домен, который добавляется к сообщениям локальных пользователей.
• inet_interfaces задаёт сетевые интерфейсы, на которых Postfix принимает соединения.
• mydestination перечисляет домены локальной доставки.
• home_mailbox может указывать каталог Maildir/, если выбрана доставка в домашние каталоги пользователей.
• smtpd_relay_restrictions задаёт правила, по которым сервер решает, кому разрешена ретрансляция.

Ключевой принцип здесь прост: принимать почту для своих доменов и разрешать пользователям отправлять письма наружу можно разными правилами и на разных сервисах. Параметр reject_unauth_destination запрещает несанкционированную ретрансляцию для неподходящих получателей. Он не означает, что всякое входящее письмо на порт 25 должно быть отклонено без SMTP-аутентификации. Межсерверная доставка обычно происходит без входа по паролю, если сообщение адресовано домену, который обслуживает данный узел.

Dovecot настраивают в /etc/dovecot/dovecot.conf и подключаемых файлах из /etc/dovecot/conf.d/. Среди важных параметров protocols, mail_location, auth_mechanisms и настройки TLS. Если для хранения выбрана структура Maildir, путь в mail_location должен совпадать с тем, куда фактически доставляет почту локальный агент. Если доставку выполняет Dovecot по LMTP, соответствующий сервис и сокет должны быть согласованы с конфигурацией Postfix.

Для SMTP-аутентификации Postfix может обращаться к Dovecot по SASL. В такой схеме на стороне Postfix указывают тип SASL и путь к сокету, а Dovecot создаёт этот сокет с правами, позволяющими Postfix подключаться к нему. Но это лишь один из вариантов: возможны другие SASL-провайдеры. Отсутствие Dovecot само по себе не создаёт открытый ретранслятор. Риск определяется правилами доступа и тем, разрешает ли сервер пересылать почту для посторонних получателей без авторизации.

Пользовательскую отправку обычно выносят на порт 587 с STARTTLS или на порт 465 с TLS с самого начала соединения. На этих сервисах требуют аутентификацию и отдельно настраивают ограничения. Порт 25, как правило, оставляют для обмена между почтовыми серверами и приёма сообщений для обслуживаемых доменов. Правила для этих трёх сценариев не стоит механически сводить к одной настройке.

После изменений полезно выполнить postfix check, проверить активные параметры командой postconf -n и изучить журналы службы. Для Dovecot аналогичную роль выполняет doveconf -n. Перезапускать службы следует после проверки синтаксиса и с учётом особенностей дистрибутива. Проверку SMTP-аутентификации лучше проводить тестовой учётной записью, не передавая пароль в публичные логи и не оставляя его в истории команд.

DNS-инфраструктура: MX, PTR и критические записи для домена

DNS связывает домен с почтовым узлом и публикует сведения, по которым принимающие серверы проверяют отправителя. Для базовой схемы понадобятся MX и A или AAAA, а также записи SPF, DKIM и DMARC. PTR настраивается отдельно у владельца IP-адреса, обычно у хостинг-провайдера.

В MX указывают имя узла, для которого существует соответствующая A- или AAAA-запись. Обычно MX не направляют на IP-адрес напрямую. Если почта отправляется по IPv6, серверу нужны рабочая IPv6-связность и подходящая DNS-конфигурация; одного IPv4 в SPF для такого источника недостаточно.

PTR, или обратная DNS-запись, находится под управлением владельца диапазона IP. Её нельзя опубликовать только через панель доменного регистратора, если тот не управляет обратной зоной адреса. Желательно, чтобы PTR указывал на имя почтового узла, а прямое разрешение этого имени вело обратно к используемому IP. Проверьте также, какое имя Postfix сообщает в EHLO: согласованная конфигурация облегчает диагностику и помогает избежать подозрительных несоответствий.

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

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

Аутентификация отправителя: внедрение SPF, DKIM и DMARC

SPF, DKIM и DMARC решают разные задачи. SPF сопоставляет IP отправителя со списком разрешённых источников для домена в SMTP-конверте. DKIM проверяет криптографическую подпись, связанную с доменом. DMARC проверяет выравнивание домена из заголовка From с доменом, прошедшим SPF или DKIM, и сообщает получателю предпочтительную политику для сообщений, которые не прошли проверку.

SPF публикуют в TXT-записи домена. В политику включают все легитимные источники отправки: собственный сервер, сервис рассылок и другие системы, если они отправляют почту от имени домена. Пример для одного IPv4-узла:

v=spf1 ip4:203.0.113.10 -all

Это только иллюстрация, а не готовая запись для любого домена. Если отправка идёт с других адресов, их нужно учесть. Для домена должна быть одна SPF-запись; несколько отдельных записей с началом v=spf1 могут привести к ошибке обработки. Механизм ~all обозначает softfail, а -all задаёт более строгий результат для источников, не перечисленных в политике. Выбор зависит от полноты инвентаризации отправителей и политики организации.

DKIM подписывает сообщение закрытым ключом, а получатель проверяет подпись по открытому ключу, опубликованному в DNS. Имя записи включает селектор, например selector._domainkey.example.com. Селектор позволяет менять ключи и обслуживать несколько конфигураций. Закрытый ключ следует хранить с ограниченными правами доступа, а публичную часть публиковать в TXT-записи без обрезки и случайных пробелов.

OpenDKIM можно подключить к Postfix как milter. Тогда Postfix передаёт сообщение сервису подписи, а тот добавляет заголовок DKIM-Signature. Нужно проверить, что milter доступен, использует правильный ключ и подписывает именно нужные домены. Если у организации несколько систем отправки, каждая из них должна подписывать письма либо быть учтена в общей схеме аутентификации.

DMARC публикуют в TXT-записи _dmarc.example.com. На этапе наблюдения часто начинают с p=none: эта политика позволяет получать отчёты и изучать источники отправки, но сама по себе не требует от получателя помещать сообщения в карантин или отклонять их. После проверки всех легитимных потоков можно рассмотреть более строгую политику quarantine или reject. Переход стоит делать постепенно, чтобы не затронуть забытые сервисы, системы уведомлений и сторонние платформы.

DMARC может пройти, если выровнен домен успешной SPF-проверки или домен успешной DKIM-подписи. Не требуется, чтобы одновременно прошли обе проверки, хотя корректно настроенные SPF и DKIM дают дополнительную устойчивость. Поэтому результаты pass, fail и none нужно читать в контексте заголовка From, SMTP-конверта, выбранной DMARC-политики и отчёта конкретного получателя. Универсального правила, по которому любой none блокирует доставку, нет.

Проверять записи удобно через dig TXT example.com, dig TXT selector._domainkey.example.com и dig TXT _dmarc.example.com. Затем отправьте тестовое сообщение на адрес, который предоставляет почтовый диагностический сервис, или на собственный ящик у принимающего провайдера. В заголовках письма ищут результаты Authentication-Results: там видны отдельные итоги SPF, DKIM и DMARC. Успешное разрешение TXT в DNS ещё не подтверждает, что сообщение подписано нужным ключом или прошло выравнивание DMARC.

Диагностика доставки: почему возникают ошибки 550 5.7.26

Код 550 5.7.26 встречается в ответах Gmail при проблемах с аутентификацией отправителя. Первые части расширенного кода статуса указывают на постоянный отказ и категорию политики, однако приведённое сообщение нельзя расшифровывать как дословную универсальную формулировку RFC 3463. Текст ответа и условия отказа зависят от принимающей системы. Код служит поводом проверить аутентификацию и сведения в полном ответе сервера, но сам по себе не доказывает, что одновременно провалились SPF, DKIM и DMARC.

В первую очередь стоит выяснить, откуда фактически ушло письмо. Маршрут может проходить через отдельный relay или сервис рассылок, а не через адрес, указанный в записи SPF. Если есть IPv4 и IPv6, нужно проверить оба варианта. Среди частых причин проблем:

1. SPF не включает IP или сервис, который действительно отправил письмо.

2. DKIM-подпись отсутствует, повреждена или не проходит проверку открытым ключом.

3. DKIM проходит, но домен подписи не выровнен с доменом в заголовке From.

4. SPF проходит для домена конверта, но он не выровнен с From, а DKIM не даёт успешной выровненной проверки.

5. Указанный в сообщении отправитель не совпадает с настроенными доменами или адресами почтового маршрута.

6. Postfix отправляет по IPv6, хотя запись SPF разрешает только IPv4.

7. Запись DNS опубликована недавно, содержит синтаксическую ошибку или была изменена не в той зоне.

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

Команды dig TXT example.com, dig TXT selector._domainkey.example.com и dig TXT _dmarc.example.com помогают проверить публикацию записей. Для обратной зоны используют dig -x 203.0.113.10. В журнале Postfix ищут сведения о соединении и ответе удалённого узла; путь к журналу зависит от системы. На тестовое письмо полезно посмотреть заголовки Authentication-Results, добавленные получателем, а не ориентироваться только на собственное сообщение в логах отправителя.

Если SPF и DKIM проходят, а DMARC не проходит, проверьте выравнивание доменов. При строгом режиме сравнения домены должны совпадать точнее; при обычном допускаются некоторые варианты организационного домена. Если DMARC установлен в p=none, это означает сбор данных и не задаёт обязательного отказа. Если сообщение отклоняется, изучите фактический ответ принимающего сервера, включая его объяснение и идентификатор проверки.

Аутентификация влияет на оценку отправителя, но не гарантирует доставку во входящие. На результат также влияют репутация IP и домена, качество списка адресатов, жалобы на спам, частота отправки, содержание письма и история домена. Для нового IP полезно планировать постепенное увеличение объёма, а для рассылок поддерживать понятный способ отписки и удалять недействительные адреса. Эти меры не заменяют DNS-настройку, но помогают не сводить доставляемость к одному набору записей.

Безопасность узла: фильтрация трафика и защита от перехвата

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

Для этого проверяют:

• значение mynetworks: там должны быть только доверенные сети, а не любой адрес в интернете;
• ограничения smtpd_relay_restrictions, включая reject_unauth_destination;
• правила на портах 587 и 465, где для пользовательской отправки требуется SMTP-аутентификация;
• доступность нужных портов в сетевом экране и отсутствие лишних открытых сервисов;
• права на закрытые ключи DKIM, TLS и доступ к сокетам аутентификации.

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

TLS следует настраивать с учётом направления соединения. Параметр smtpd_tls_security_level относится к входящему SMTP-соединению с Postfix. Значение may допускает STARTTLS, не требуя его от каждого подключающегося почтового сервера. Для пользовательской отправки требования к шифрованию задают в конфигурации сервисов 587 и 465 отдельно. Исходящие соединения Postfix настраиваются параметрами клиентской стороны, в частности smtp_tls_security_level; это не тот же самый параметр, что smtpd_tls_security_level.

Полезны и дополнительные меры:

• Fail2ban может ограничивать адреса с повторяющимися неудачными попытками входа, если правильно настроены фильтры и пороги.
• Postscreen способен проверять SMTP-клиентов до передачи соединения основному серверу. Его стоит внедрять с пониманием того, какие проверки включены и как они повлияют на легитимные источники.
• Ограничения на HELO, отправителя и получателя помогают отсекать часть некорректных запросов, но слишком жёсткие правила могут мешать доставке от исправных серверов.
• Обновления Postfix, Dovecot и операционной системы закрывают известные уязвимости; журналы помогают замечать перебор паролей и ошибки конфигурации.
• Резервное копирование почтовых ящиков и конфигурации должно учитывать права доступа и возможность восстановления, а не только факт создания архивов.

Для пользовательских соединений используйте корректный сертификат и требуйте шифрование там, где это допускают клиенты. Межсерверный SMTP устроен иначе: удалённый MTA может не поддерживать TLS или не согласиться на него, поэтому политика для входящих соединений требует отдельного решения. Важно не смешивать настройку шифрования для SMTP-сервера, SMTP-клиента и IMAP.

Финальные проверки перед запуском

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

• dig MX example.com показывает ожидаемый почтовый узел.
• A- и, если используется, AAAA-записи разрешаются в адреса сервера.
• dig -x <IP> возвращает настроенное имя PTR.
• SPF, DKIM и DMARC опубликованы в правильной DNS-зоне.
• Входящее тестовое письмо принимается для обслуживаемого домена и появляется в нужном ящике.
• Пользователь может получить почту по IMAP с TLS.
• Отправка через порт 587 или 465 работает с авторизацией.
• Неавторизованный клиент не может пересылать через сервер письмо постороннему домену.
• По заголовкам тестового письма можно понять результаты SPF, DKIM и DMARC.
• Очередь Postfix не накапливает сообщения с повторяющимися ошибками доставки.

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

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

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