dxdt.ru: занимательный интернет-журнал

Электронная почта, email – одна из немногих интернет-технологий уровня приложений, которая всё ещё сохраняет черты “старого интернета”, где общедоступные протоколы позволяли строить распределённые системы обмена сообщениями. Да, нельзя не заметить, что централизация нынче настигла и email, но заметка о другом – хотелось бы рассмотреть пару конкретных способов защиты от нежелательных сообщений, которые используются на почтовых серверах, но при этом настолько избыточны, что мешают доставлять вполне себе легитимные письма.

Способ первый – это требование наличия адресных записей в апексе почтовой зоны. Речь вот о чём: представьте, что доставляющий релей принёс письмо из домена example.com, а принимающий почтовый сервер требует, чтобы для этого example.com была указана A-запись (либо AAAA – не важно). То есть, принимающий сервер смотрит в DNS, обнаруживает, что в example.com нет A-записи и отбрасывает письмо. (Просто закрыть SMTP-сессию в самом начале этот сценарий не позволяет: нужно дождаться, когда клиент скажет, из какого домена, – якобы! – он принёс письмо.) Очевидно, данный способ предполагает, что “настоящие” доменные зоны не могут работать без адресных записей, а если такой записи нет, то и письмо – “подспуфлено”. Но это далеко не всегда так. Почтовый домен – это почтовый домен. Необязательно держать под тем же именем веб-сайт, предположим. Конечно, способ обоснован: пусть спецификация такого и не предписывает, но ведь можно потребовать, чтобы в почтовом домен был опубликован какой-то способ доставки почты, однако просто требовать наличия адресных записей – это слишком строго. Да, при отсутствии MX-записей почта может доставляться по A-записям. Это верно, но это не означает, что наличие Α-записи обязательно, если есть MX-записи. А вот легитимные письма, приходящие из чисто почтового и корректно настроенного домена, оказываются отброшены. Это плохо.

Данная проверка при фильтрации разумна только в том случае, если для почтового домена-отправителя не удалось найти MX-ы. Но обратите внимание, что, вообще говоря, наличие MX-записей, технически, не является обязательным при отправке сообщений: логика фильтрации тут строится на том, что если для почтового домена, из которого, якобы, пришло письмо, не опубликовано методов доставки сообщений, то и письмо-то какое-то липовое. Но наличие DNS-записей не гарантирует, что письма будут приняты. Есть и специальные адреса в стиле no-reply, и прочий /dev/null. Как говорится, ладно, допустим – однако отсутствие-то A-записи при наличии MX уж точно не может служить основанием для отбрасывания письма.

Вообще, изобретательная защита от нежелательных сообщений – мера вполне оправданная. Главное, не переусердствовать. Особенно, в эпоху развитого DKIM и SPF. Эти две упомянутых технологии вполне себе позволяют предоставить достаточные доказательства того, что письмо отправлено с привязкой именно к тому домену, который указан в качестве “источника”. “Источника” тут в кавычках потому, что схема доставки сообщений электронной почты вообще не подразумевает доменов-источников – источником всегда является ближайший к получателю почтовый релей, который, что называется, “приносит письмо по SMTP”. В этом сила email. И этот же момент приводит к перегибам, с которыми приходится встречаться на практике. Всё дело в разнообразных дополнительных проверках, применяемых SMTP-сервером получателя к SMTP-клиенту, который принёс письмо.

Поэтому переходим к описанию второго способа фильтрации повышенной строгости. Здесь сервер-получатель требует, чтобы все имена MX-ов, указанных для почтового домена отправителя, резолвились (DNS) в маршрутизируемые IP-адреса. Это вот совсем специальный случай, но и он встречается на практике. Что он означает? Вот что: в процессе получения письма сервер получатель отыскивает MX-записи домена-источника в DNS, резолвит их, и если одну из записей не удалось разрезолвить, то не принимает письмо. Тут ключевые слова, обозначающие избыточный уровень фильтрации: “одну из записей”. Представьте, что в зоне домена-отправителя указано три различных имени MX-а. И одно из этих имён, при попытке резолвинга, приводит к ошибке – например, нет такого имени в DNS. Но остались же ещё два! Это полностью допустимая ситуация. У нас же речь о приёме электронной почты. При этом почтовый релей, если бы он доставлял почту в исходный домен, так или иначе должен попробовать использовать другие MX-ы – это прямо предписывается спецификацией, в которой есть даже поле для установки приоритета. И вот с другими MX всё обязательно сработает. Но вот проверять доступность MX-ов в домене-источнике при получении письма – сервер не должен. Но, конечно, технически может и проверить. Главный вопрос тут – как потенциальная недоступность MX в домене-источнике вообще может влиять на приём сообщений? Никак не может, и не должна. Но получается, что влияет.

В только что описанной схеме фильтрации может ещё проверяться состав IP-адресов, полученных в результате резолвинга имён из MX-записей. И если адреса – это какой-нибудь localhost или 0.0.0.0, то письмо, опять же, отбрасывается.

Кстати, с IP-адресами связан, наверное, самый тривиальный, но при этом действенный и допустимый, способ фильтрации – проверить обратную зону: то есть, принимающий сервер видит IP-адрес источника (почта доставляется по TCP), а поэтому может разрезолвить обратную зону (имя хоста по IP-адресу). И вот дальше начинается “серая зона” (игра слов: “серая” может быть “серой” в смысле специальных списков отправителей – это точно знакомо администраторам почтовиков). Сервер может вообще не принимать сообщения от узлов, которые не имеют записи в обратной зоне, а может даже не принимать и от тех, которые представились не так, как записано в обратной зоне (протокол SMTP подразумевает указание сетевого имени подключающегося клиента). Можно всё же принимать сообщения от подобных узлов и складывать их в “Спам”, можно просить прийти через некоторое время ещё раз. Вариантов много. Обратите внимание, что все они основаны на сопоставлении некоторых имён и адресов, записанных как в SMTP-обмене, так и в DNS, и в IP. Почта предоставляет целую пачку способов сравнить разные имена и адреса, сделав выводы о том, является ли данная “корреспонденция” нежелательной. Во многих случаях ранжировать по степени “нежелательности” можно SMTP-сессию, даже не дожидаясь самого письма.

DKIM – позволяет привязать письмо к доменной зоне криптографически, при помощи цифровой подписи. Это весьма строго. Да, для выполнения проверки серверу придётся не только дочитать пришедшее письмо, но ещё и разобрать подписи, найдя ключ в DNS. Это, конечно, оправдывает “скептическое” использование DKIM при приёме сообщений: понятно, что с вычислительной точки зрения – проще прервать SMTP-сессию в самом начале, даже не дожидаясь заголовков с DKIM и самого письма, которое необходимо для вычисления подписи. Есть ещё SPF – этот механизм срабатывает несколько раньше, так как позволяет привязать к доменной зоне непосредственно IP-адрес узла, который приносит сообщения, относящиеся к этой зоне. И DKIM, и SPF, и обратная зона – подразумевают работу с DNS. Поэтому, что касается рисков обработки DKIM, то упасть “почтовик”, как ни странно, может и без чтения письма, и даже до начала полноценной SMTP-сессии – из-за сбоя резолвера (например, при валидации DNSSEC).

Да, существуют продвинутые интерактивные способы защиты от нежелательных сообщений, когда в ответ на принятое письмо отправляется автоматически сгенерированное сообщение с инструкциями о том, как корреспонденту подтвердить свои “добрые намерения”. Легитимный пользователь почтового адреса, – получатель, – при этом исходного письма не увидит до тех пор, пока корреспондент не выполнит требуемый минимум по подтверждению (в нормальных системах достаточно просто ответить на запрос робота пустым письмом). Но это совсем другая история, если сравнивать со строгой фильтрацией по наличию MX и адресных записей в зоне: ошибка тут вылезет при попытке доставки ответного сообщения корреспонденту – если в его домене нет доступных MX-ов. Предсказывать же такую ошибку в ходе приёма, да ещё и отбрасывать сообщения по результату – так себе способ фильтрации.

Заметьте, что упомянутые выше SPF и DKIM уже дают довольно строгое “подтверждение домена”. Оно уж точно строже, чем состав списка MX-ов и, тем более, наличие A-записей.

Адрес записки: https://dxdt.ru/2025/08/03/16070/