“~all” посреди SPF записывают, сигнализируют о конце записи, когда это анализируется?
Формат записи SPF нашей компании следующие:
"v=spf1 include:_spf.google.com ~all mx ip4:X.X.0.0/23 include:spf.example.com? все"
Таким образом, у нас есть "~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: XX0.0 / 23 include: spf.example.com? All"
говорит по порядку:
"электронная почта, передающая запись SPF
_spf.google.com, действительна для нашего домена""softfail для всех других отправителей для нашего домена"
". Электронная почта, полученная из наших записей A, действительна для электронная почта нашего домена «
», полученная из наших записей MX, действительна для нашего домена. Электронная почта «
» из диапазона IP-адресов
xx0.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 приведет к короткому замыканию при совпадении механизма , и функция check_host () вернет в качестве результата значение квалификатора. У меня нет «реальных» данных, которые я мог бы предоставить вам относительно того, соответствуют ли большинство почтовых серверов RFC или нет.
Источник: RFC7208 (см. Стр. 17)