SMTP relay для исходящей почты: что такое smarthost

SMTP relay, или smarthost, - это почтовый сервер, который доставляет вашу исходящую почту за вас. Вместо того чтобы ваш сервер искал MX каждого получателя и подключался к нему на порт 25, он передаёт каждое исходящее письмо одному фиксированному хосту на порт 587 или 465, входит с именем пользователя и паролем и поручает этому хосту доставку с адресов, у которых уже есть репутация. Он нужен, когда ваша сеть блокирует исходящий порт 25, когда у IP вашего сервера нет пригодного обратного DNS или когда новый IP иначе провёл бы недели в папках «Спам». Почту вы по-прежнему принимаете напрямую, ящики по-прежнему храните у себя и подписываете письма по-прежнему своим DKIM-ключом. Relay - это лишь последний шаг пути.

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

Что relay меняет, а что нет#

Без relay отправителем для всего мира является ваш сервер. Получатель видит подключение с вашего IP, проверяет его по блок-листам и обратному DNS и судит о письме по репутации вашего сервера.

С relay получатель видит подключение с IP relay. Проверки по блок-листам, обратный DNS и репутация на уровне соединения теперь относятся к relay. Всё внутри письма - ваш адрес From:, ваша DKIM-подпись, ваше содержимое - остаётся вашим, и репутация домена по-прежнему закреплена за вашим доменом.

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

Когда он нужен#

• Исходящий порт 25 заблокирован. Безусловно самая частая причина. Ваш сервер не может подключиться ни к чьему порту 25, но может подключиться к relay на 587 или 465. Почему существует такая блокировка и как её подтвердить, объясняется в статье порт 25 и блокировка исходящей почты.
• Вы не можете настроить обратный DNS. Крупные получатели ожидают, что у отправляющего IP есть PTR-запись, совпадающая с прямым DNS. Если провайдер не может прописать её для вашего адреса, у IP relay она уже есть. Подробности - в статье обратный DNS и PTR для почтовых серверов.
• Ваш IP новый, общий или подпорченный. У свежего IP нет репутации; у переиспользованного может оказаться чужая. Relay отправляет с IP, у которых есть история.
• Вы отправляете много почты из приложений - сбросы паролей, чеки, уведомления. Специализированные транзакционные сервисы обрабатывают возвраты, списки подавления и журналы по каждому письму лучше, чем универсальный почтовый сервер.
• Вы хотите следить за доставкой в одном месте. Панели relay показывают доставку, возвраты и жалобы по каждому письму, чего собственная очередь не делает.

Когда он не нужен: сервер в сети с открытым исходящим 25, правильным PTR, чистым IP с некоторой историей и небольшим объёмом личной переписки. Многие, кто держит почту сам, годами отправляют напрямую.

Как выбрать relay#

Relay бывают трёх основных видов.

Для собственного почтового сервера обычно правильный выбор - транзакционный сервис. Они принимают почту с любым From: на доменах, которые вы у них подтвердили, предлагают собственные домены конверта и DKIM с вашим доменом, а их бесплатные или младшие тарифы с запасом покрывают исходящий объём небольшой организации. Актуальные цены проверяйте сами - они меняются, и это как раз те цифры, которые неверны в любой статье старше нескольких месяцев.

Что проверить перед регистрацией:

1. Подтверждение домена и DKIM с вашим доменом - чтобы DMARC мог выровняться по DKIM.
2. Собственный домен return path или MAIL FROM - чтобы выравнивался и SPF.
3. Обработку возвратов и жалоб - подавление адресов с жёсткими возвратами и feedback loop от получателей.
4. Отправку на 587 и 465, а в идеале и на 2525, для сетей, которые блокируют стандартные порты.
5. Правила насчёт содержимого. Большинство транзакционных сервисов запрещают купленные базы, а некоторые запрещают маркетинговые рассылки на транзакционных тарифах. Прочитайте правила допустимого использования: за их нарушение аккаунты блокируют.

Аутентификация на relay#

Соединение вашего сервера с relay - это обычная SMTP-отправка:

1. Ваш сервер подключается к хосту relay на порт 587 и выполняет EHLO, затем STARTTLS, чтобы перевести соединение на шифрование, - или подключается на 465 и сразу начинает TLS.
2. По зашифрованному соединению он аутентифицируется через AUTH PLAIN или AUTH LOGIN, используя имя пользователя и пароль, выданные relay. Транзакционные сервисы обычно называют их SMTP-учётными данными и держат отдельно от входа в ваш аккаунт; некоторые используют буквальное имя пользователя вроде apikey и API-ключ в качестве пароля.
3. Он отправляет письмо командами MAIL FROM, RCPT TO и DATA точно так же, как любому другому серверу.

Никогда не аутентифицируйтесь по незашифрованному соединению - пароль идёт по сети в base64, а это кодирование, а не шифрование. Настройте сервер так, чтобы он требовал TLS при соединении с relay, а не просто пытался его использовать.

В Stalwart relay настраивается в параметрах исходящей почты в веб-админке. Свежие версии описывают его как маршрут типа Relay с адресом, портом, признаком неявного TLS (true для 465, false для 587 со STARTTLS), а также именем пользователя и секретом для аутентификации; стратегия исходящей доставки затем выбирает этот маршрут для внешних получателей, а локальная почта доставляется локально. Другие серверы выражают то же самое по-своему. Для сравнения - Postfix:

relayhost = [smtp.relay.example]:587smtp_sasl_auth_enable = yessmtp_sasl_password_maps = hash:/etc/postfix/sasl_passwdsmtp_sasl_security_options = noanonymoussmtp_tls_security_level = encrypt

Квадратные скобки вокруг имени хоста говорят Postfix не искать для него MX-записи, а подключаться к этому хосту напрямую. Та же идея действует везде: relay - фиксированный адресат, а не поиск по MX.

SPF, DKIM и выравнивание через relay#

Именно здесь с relay всё и ломается. DMARC проходит, когда SPF или DKIM проходит для домена в видимом заголовке `From:`. Relay меняет IP, с которого идёт отправка, и может поменять отправителя в конверте, так что каждую проверку нужно продумать. Теория - в статье SPF, DKIM и DMARC простыми словами.

DKIM - самая надёжная из них. Ваш почтовый сервер подписывает каждое письмо вашим собственным ключом (d=example.com) до передачи relay. Relay не должен изменять подписанные заголовки или тело письма, и добросовестные relay этого не делают. Подпись приходит нетронутой, проверяется по вашему открытому ключу и выравнивается с вашим From:. Многие relay добавляют ещё и собственную подпись со своим доменом; это безвредно - достаточно одной выровненной проходящей подписи. Если ваш сервер не подписывает письма, пусть relay подписывает их вашим доменом, используя DKIM-записи, которые он даст вам для публикации.

SPF зависит от отправителя в конверте. Два случая:

• Relay сохраняет ваш адрес в конверте (MAIL FROM:<anna@example.com>). Получатели проверяют SPF для example.com относительно IP relay. Вам нужно добавить relay в свою SPF-запись, обычно со значением include:, указанным в документации relay, - например include:amazonses.com, include:mailgun.org или include:sendgrid.net.
• Relay подменяет отправителя в конверте на собственный домен для возвратов, чтобы самому их обрабатывать. Тогда SPF проверяется для домена relay, проходит и не выравнивается с вашим. Это нормально, если выравнивается DKIM. Лучше всего настроить собственный домен MAIL FROM или return path, например bounces.example.com, опубликованный так, как велит relay, - тогда выравнивается и SPF.

example.com.  IN  TXT  "v=spf1 mx include:mailgun.org -all"

Держите одну SPF-запись на имя и укладывайтесь в десять DNS-запросов; каждый include: тратит как минимум один. Если до добавления relay у вас стоял -all, сначала добавьте include и отправьте тестовое письмо, иначе всё отправленное через relay в промежутке будет проваливать SPF.

Возвраты, лимиты и очередь#

Чего стоит ждать на практике, когда почта пойдёт через relay.

• Возвраты приходят отправителю из конверта. Если relay его подменяет, возвраты получает relay и обычно автоматически подавляет эти адреса - следующее письмо на подавленный адрес relay отбрасывает, и до получателя оно не доходит. Загляните в его список подавления, когда кто-то говорит, что не получает ваших писем.
• Лимиты отправки. Новые аккаунты relay часто начинают с суточного лимита или в песочнице, которая доставляет почту только на подтверждённые адреса. Сервер, превысивший лимит, получает от relay отсрочки 4xx; ваша очередь держит почту и повторяет попытки. Просите повысить лимит до запланированной рассылки, а не во время неё.
• Размер письма. У relay есть максимальный размер письма, часто в диапазоне от 10 MB до 50 MB с учётом накладных расходов на кодирование. Base64 делает вложения примерно на треть больше самих файлов.
• Ваша очередь - по-прежнему первая очередь. Если relay недоступен или отклоняет вход, почта ждёт в очереди вашего сервера. Растущая очередь с ошибками аутентификации означает неверные или просроченные учётные данные; с таймаутами - порт relay заблокирован или relay лежит.

Отправка через relay только части почты#

Relay не обязан брать на себя всё. Типичные варианты разделения:

• Внешняя почта через relay, локальная доставляется локально. Схема по умолчанию: письма между учётными записями на ваших собственных доменах вообще не покидают сервер.
• Через relay только определённые направления. Например, большинству доменов доставлять напрямую, а почту одному крупному провайдеру, который притормаживает ваш IP, отправлять через relay. Исходящая маршрутизация Stalwart выбирает маршрут для каждого получателя с помощью выражений, так что такое разделение возможно, хотя простое правило «вся внешняя почта через relay» легче понимать.
• Приложения через relay, люди напрямую. Если ваш сервер отправляет напрямую, а приложение массово рассылает чеки, направьте приложение прямо в транзакционный сервис, а почтовый сервер оставьте для людей. Об этой стороне - в статье транзакционная почта из вашего приложения.

Проверка relay#

# Can the server reach the relay at all?$ nc -vz -w 5 smtp.relay.example 587# A full authenticated test from the command line$ swaks --server smtp.relay.example:587 --tls \    --auth LOGIN --auth-user 'relay-user' --auth-password 'relay-secret' \    --from anna@example.com --to you@gmail.com

Затем отправьте настоящее письмо через свой почтовый сервер на внешний ящик, к которому у вас есть доступ, и прочитайте Authentication-Results. Нужно увидеть dkim=pass с header.d=example.com (или header.i=@example.com), dmarc=pass и header.from=example.com. spf=pass - бонус, если вы настроили собственный return path. Заголовки Received: покажут серверы relay последним шагом перед получателем - так и должно быть.

Когда проверка не проходит, ошибка обычно указывает, какой уровень неисправен:

• `535 5.7.8` authentication failed - неверные учётные данные или учётные данные от другого региона или аккаунта. Транзакционные сервисы часто выдают SMTP-учётные данные по регионам; имя хоста и учётные данные должны соответствовать друг другу.
• `530` must issue STARTTLS first - сервер попытался войти на 587, не перейдя на шифрование. Включите STARTTLS для relay или переключитесь на 465 с неявным TLS.
• Ошибки TLS-рукопожатия на 465 - сервер говорит STARTTLS с портом неявного TLS. Поменяйте режим TLS.
• `554` sender address not verified или «domain not verified» - relay принимает только те домены в From:, которые вы у него подтвердили. Завершите подтверждение домена в панели relay.
• `dkim=fail` после relay - что-то по пути изменило письмо. Проверьте, не настроен ли relay на переписывание ссылок или добавление подписей внизу письма: некоторые сервисы делают и то и другое ради отслеживания кликов.

Relay на RE:NODE Mail Server#

Линейка Mail Server работает на Stalwart, и relay настраивается в его веб-админке. Если какая-то сеть по пути не пропускает ваш исходящий порт 25, вы задаёте там relay, и Stalwart передаёт ему внешнюю почту на 587 или 465, по-прежнему подписывая её DKIM-ключами, сгенерированными для вашего домена. Входящая почта - отдельная история: поддержка по запросу пробрасывает порт 25 на ваш сервер, один почтовый сервер на адрес. Можно ли прописать PTR-запись для адреса вашего сервера, лучше спросить поддержку, а не предполагать, - и если ответ вас не устроит, relay как раз тот инструмент, с которым для исходящей почты это перестаёт иметь значение. Остальная настройка описана в статье настройка почтового сервера Stalwart.

FAQ#

Relay - это то же самое, что open relay?

Нет. Open relay принимает почту от кого угодно для любого адресата и служит инструментом спамеров; серверы, на которых его находят, быстро попадают в блок-листы. Smarthost пересылает почту только для клиентов, которые аутентифицируются выданными им учётными данными.

Увидят ли получатели имя relay?

Только в технических заголовках Received:. Адрес From:, отображаемое имя и DKIM-подпись - ваши, и почтовые клиенты показывают ваш домен. Некоторые relay добавляют в Gmail небольшую пометку «via», если DKIM подписан не вашим доменом, - подпись вашим доменом её убирает.

Решает ли relay проблему попадания в спам?

Он решает проблемы на уровне IP: IP в блок-листах или новые IP и отсутствие обратного DNS. Плохое содержимое, нежеланную почту или домен с плохой репутацией он не исправит. Об остальном - в статье почему письма попадают в спам.

Какой порт использовать для связи с relay - 587 или 465?

Любой. 465 использует TLS с самого начала; 587 переходит на шифрование через STARTTLS. Используйте тот, что указан в документации relay, и выставьте в сервере соответствующий режим TLS. Если заблокированы оба, многие relay принимают ещё и 2525.

Можно ли использовать мой аккаунт Gmail как relay?

Для одного адреса - в каком-то смысле: он перепишет или ограничит From: этим аккаунтом, и у него низкие суточные лимиты. Для пересылки всей почты домена с вашего сервера он не подходит. Используйте транзакционный сервис.