Какое влияние на квалификаторы SPF-записи есть, если они включены в другую запись SPF, если родительская запись более строгая, чем дочерняя?

Question

Я хочу поставить строгий квалификатор FAIL на все источники электронной почты, которые явно не указаны в записи SPF моего домена.

Это может просто быть достигнуто следующей записью (-all означает, что все другие источники, не должны быть приняты)

mydomain.com. IN TXT "v=spf1 ip4:my-ip-address/32 -all" 

Теперь моя проблема заключается в том, что я в дополнении хочу белого список моего поставщика услуг электронной почты (mailgun.com), а также Google Apps, поэтому я создал следующую запись:

mydomain.com. IN TXT "v=spf1 include:mailgun.org include:_spf.google.com ip4:my-ip-address/32 -all" 

Теперь запись SPF из mailgun.com (в случае Google применяется такая же ситуация) решает:

mailgun.org.  3600 IN TXT "v=spf1 ip4:173.193.210.32/27 ip4:50.23.218.192/27 ip4:174.37.226.64/27 ip4:208.43.239.136/30 ip4:50.23.215.176/30 ip4:184.173.105.0/24 ip4:184.173.153.0/24 ip4:209.61.151.0/24 ip4:166.78.68.0/22 ip4:198.61.254.0/23 ip4:192.237.158.0/23 " "~all" 

Теперь, что интересно, заключается в том, что они положили квалификационный знак мягкого отказа "~all" на их запись spf.

Википедия описывает включает директиву следующим образом:

Если включен (неправильно) политика проходит тест этого механизма матчей. Обычно это используется для включения политик более одного ISP.

интерпретировать это в том, что неизвестный отправитель квалифицировано как SOFT FAIL по включенным записям, и, следовательно, проходит, как SOFT FAIL, так как они включены в корневой записи. Даже если корневая запись помещает FAIL во все неиспользуемые источники.

Так, чтобы незавершенные записи эффективно отображали квалификатор FAIL корневой записи бесполезным. Таким образом, самая строгая запись деинфинирует общий классификатор неизвестных источников.

Правильно ли в этом допущении? Если нет, то как в приведенном примере неизвестный отправитель квалифицирован?

Answer 1

поведение описано в seciton 5.2 RFC, где он говорит

Whether this mechanism matches, does not match, or throws an 
    exception depends on the result of the recursive evaluation of 
    check_host(): 

    +---------------------------------+---------------------------------+ 
    | A recursive check_host() result | Causes the "include" mechanism | 
    | of:        | to:        | 
    +---------------------------------+---------------------------------+ 
    | Pass       | match       | 
    |         |         | 
    | Fail       | not match      | 
    |         |         | 
    | SoftFail      | not match      | 
    |         |         | 
    | Neutral       | not match      | 
    |         |         | 
    | TempError      | throw TempError     | 
    |         |         | 
    | PermError      | throw PermError     | 
    |         |         | 
    | None       | throw PermError     | 
    +---------------------------------+---------------------------------+ 

Механизм в этом contects относится к «включают в себя» функциональности.

Как показано в таблице, softfail вызывает несоответствие.

Он также говорит:

In hindsight, the name "include" was poorly chosen. Only the 
    evaluated result of the referenced SPF record is used, rather than 
    acting as if the referenced SPF record was literally included in the 
    first. 

Что я интерпретировать таким образом, что только результат включенной записи имеет отношение, которое, в КАС мягкий провал, а не-матч (такой же, как если у записи есть FAIL).

Вот также результат теста с ру Spf библиотеки выполняется на этом website

Input accepted, querying now... 


Mail sent from this IP address: 1.2.3.4 
Mail from (Sender): scknpbi@cacxjxv.com 
Mail checked using this SPF policy: v=spf1 ip4:4.5.6.7/32 include:mailgun.org -all 
Results - FAIL Message may be rejected 


Mail sent from: 1.2.3.4 
Mail Server HELO/EHLO identity: blanivzsrxvbla@saucjw.com 

HELO/EHLO Results - none