Формат записи SPF нашей компании следующий:
"v = spf1 include: _spf.google.com ~ все a mx ip4: X.X.0.0 / 23 include: spf.example.com? all "
Итак, у нас есть «~ all» в середине нашей записи SPF. На сайт openspf.com, вот что говорят о механизме «всего»:
Этот механизм всегда совпадает. Обычно он идет в конце записи SPF.
Таким образом, они не говорят, что «все» ДОЛЖНЫ идти в конце записи SPF, но что это ОБЫЧНО идет в конце.
В нашей компании в последнее время мы наблюдаем несколько программных сбоев в сообщениях электронной почты, отправленных с серверов, перечисленных в нашей записи SPF, но наша запись SPF проходит все инструменты проверки, которые я нашел до сих пор.
Мне интересно, может ли это "~ all" сразу после включения для Google Apps (_spf.google.com) останавливать синтаксический анализ и не распознавать оставшиеся части записи SPF? Будет ли передача или мягкий отказ зависеть от того, кто ее анализирует, и их конкретной реализации того, как они обрабатывают записи SPF? Есть ли причина иметь механизм «все», который не находится в конце записи SPF?
И да, я знаю, что мы можем просто изменить нашу запись SPF. Этот вопрос больше касается разъяснения того, как все это работает, а не обязательно разрешения нашей конкретной ситуации.
RFC 7208 § 5.1 прямо об этом: после all появляется, все после него ДОЛЖНО игнорироваться.
Механизмы ведь «все» никогда не будут проверены. Механизмы, перечисленные после "всех", ДОЛЖНЫ игнорироваться. Любой модификатор "перенаправления" (Раздел 6.1) ДОЛЖЕН игнорироваться, если в записи есть механизм «все», независимо от относительного порядка терминов.
RFC устарел, RFC 4408, сказал примерно то же самое; новая версия RFC просто поясняет намерение.
Механизмы ведь «все» никогда не будут проверены. Любой модификатор "перенаправления" (Раздел 6.1) не действует при наличии механизма «все».
Таким образом, соответствующие реализации SPF будут полностью игнорировать все, что происходит после первого ~all. Однако это не означает, что каждая реализация соответствует спецификации. В частности, это, вероятно, считалось заслуживающим уточнения именно так как одна или несколько реализаций не соответствовали.
Совершенно непонятно, почему инструмент онлайн-проверки не обнаружит эту неверную конфигурацию, но если вы собираетесь что-либо после первого all для использования, вы должны исправить запись, так как правильные реализации проигнорируют ее.
"v = spf1 include: _spf.google.com ~ all a mx ip4: X.X.0.0 / 23 include: spf.example.com? all"
говорит по порядку:
"электронное письмо, передающее запись SPF
_spf.google.comдействительно для нашего домена ""softfail для всех остальных отправителей для нашего домена"
"электронные письма, поступающие из наших записей A, действительны для нашего домена"
"электронные письма, поступающие из наших записей MX, действительны для нашего домена"
"электронное письмо из диапазона IP-адресов
x.x.0.0/23действительно для нашего домена ""электронное письмо, передающее запись SPF
spf.example.comдействительно для нашего домена ""электронная почта от всех других отправителей для нашего домена не может быть проверена тем или иным способом"
Согласно синтаксису записи:
Механизмы оцениваются по порядку. Если ни один механизм или модификатор не совпадают, результатом по умолчанию является «Нейтральный».
Так что для вашего, как только он попадает в «softfail для всех остальных», это действительно об этом ... он должен игнорировать остальные указанные вами механизмы.
Ваша запись SPF должна быть максимально лаконичной. Я очень сомневаюсь, что у вас есть целая сеть / 23, которая должна отправлять электронную почту для вашего домена, а также все ваши записи A. Может и так ... но, скорее всего, нет.
Хорошая чистая запись SPF должна выглядеть примерно так:
"v = spf1 include: _spf.google.com include: spf.example.com mx -all"
По сути, это означает, что _spf.google.com, spf.example.com и ваши записи MX являются единственными действительными отправителями для вашего домена ... все остальное следует рассматривать как недопустимое.
А правильно реализовано Устройство проверки SPF закоротит механизм match, и функция check_host () вернет значение квалификатора в качестве результата. У меня нет «реальных» данных, которые я мог бы предоставить вам относительно того, соблюдают ли большинство почтовых серверов RFC или нет.
Источник: RFC7208 (см. стр.17)