Почему администраторы в основном используют +aAlong +mxв записях SPF? Вот пример:
@ 10800 IN TXT "v=spf1 +a +mx -all"
Разве не достаточно использовать только +mxпараметр, например:
@ 10800 IN TXT "v=spf1 +mx -all"
Я думал, что задача записи MX — отправлять электронную почту, а не записи A. Может ли кто-нибудь объяснить сценарий, почему кто-то +aтогда будет использовать?
решение1
Честно говоря, потому что они скопировали конфигурацию из какого-то руководства или примера конфигурации, не зная основных принципов SPF. Иногда желательно, чтобы, например, и веб-сервер в aи входящийпочтовые обмены mxтакже используются для отправки почты, но не всегда.
Лучше отдать предпочтение механизмам с меньшим количеством дополнительных DNS-запросов: ip4/ ip6снова aи aснова mx(RFC 7208, 10.1.1) И даже если для более легкого администрирования (10.1.2), aмеханизм выбирается, это не всегда a mxили a, но например a:relay.example.com.
решение2
Задача хозяев, указанных в MXзаписях, состоит в том, чтобыполучатьэлектронная почта, не обязательнодоставлятьэлектронная почта.
Вполне допустимо (и довольно распространено, особенно для крупных операций) иметь асимметричную настройку, когда хосты, обрабатывающие входящую и исходящую почту, не одинаковы.
То есть нет гарантии, что либо mx(aka +mx), либо a(aka +a) в SPF имеет отношение к указанию того, какие хосты, как ожидается, будутдоставлятьemail.
Например, если у вас нет собственных почтовых серверов, возможно, что-то вроде этого v=spf1 include:spf.majoremailserviceprovider.example -allбудет более уместным.
Если напрямую ответить на вопрос о том, почему эта a mxкомбинация, в частности, представляется чрезмерно представленной в записях SPF, то я предполагаю, что эта ситуация сводится к тому, что слишком много администраторов добавляют записи SPF, не понимая концепции SPF достаточно хорошо, чтобы решить, что включить в свою политику, а вместо этого просто копируют и вставляют несколько произвольно сконструированных примеров.
решение3
Я согласен с другими ответами, что +a +mxэто, вероятно, антиидиома, культивирующая карго.
Что касается того, когда следует использовать +a, документ RFC отвечает на этот вопрос враздел 10.1.2:
Публикация записей SPF для отдельных хостов также является наилучшей практикой. Имя хоста обычно является идентификатором, используемым в команде 5321.HELO/.EHLO. В случае сообщений с пустым 5321.MailFrom, он используется как домен для проверок SPF 5321.MailFrom, в дополнение к использованию в проверках SPF на основе 5321.HELO/.EHLO. Стандартная запись SPF для отдельного хоста, участвующего в обработке почты, выглядит следующим образом:
relay.example.com. IN TXT "v=spf1 a -all"
Например, я публикую такую запись для своего почтового сервера mail.mydomain.org, для удобства верификаторов, которые сначала проверяют идентификацию HELO. (Конечно, я также публикую обычную v=spf1 mx -allзапись на самом почтовом домене mydomain.org.)
решение4
Преимущество может заключаться в длине, хотя вряд ли это является реальной мотивацией.
Учтите, что запись TXT может раздуться до размеров, когда один пакет UDP будет слишком мал. Поэтому запрос отправляется снова в TCP, а ответ — несколько пакетов TCP и соответствующее время установки рукопожатия.
При аккуратном использовании запросов A и MX можно получить два ответа UDP размером около 1500 байт для записи SPF, один для A и один для MX, а также оставшиеся около 1400 байт для всех записей TXT.
Это предполагает, что у вас достаточно авторизованных "вещей" в вашей записи SPF, чтобы превысить 3000 байт. Включения также могут обойти ограничения по длине, но я не уверен, будет ли каждый из них отдельным запросом UDP или одним сеансом запроса TCP.