Em primeiro lugar, apenas para esclarecer sobre include
, s5.2 do RFC 4408 diz :
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.
Quanto a saber se o MX
RR em um registro include
d se refere ao seu MX
ou MX
do domínio include
d, concedo com alegria que A página de protocolo do OpenSPF é incrivelmente inútil sobre o assunto, porque o exemplo usa o mesmo domínio para o registro de origem e incluído . Mas o RFC é (muito ligeiramente) mais claro, quando escreve (novamente no s5.2):
The "include" mechanism triggers a recursive evaluation of check_host(). The domain-spec is expanded as per Section 8. Then check_host() is evaluated with the resulting string as the <domain>. The <ip> and <sender> arguments remain the same as in the current evaluation of check_host().
Eu destaquei o bit que interpreto como significando que mx
e registros semelhantes são avaliados no contexto do domínio include
d. Mas como nada é tão bom quanto o Real Data, defini os seguintes subdomínios em um dos domínios da minha família ( waide.me.uk
e obrigado pelo empréstimo temporário!):
foo IN TXT "v=spf1 include:bar.waide.me.uk -all"
foo IN A 10.5.5.5
bar IN TXT "v=spf1 mx -all"
bar IN MX 5 baz.bar
baz.bar IN A 78.46.204.154
Quando eu uso o testador de Beveridge (que openspf.org recomenda), ele diz que o e-mail de [email protected]
que chega de 78.46.204.154
é um passe de SPF. Note que nenhuma referência é feita para esse endereço em qualquer lugar em foo.waide.me.uk
. Há uma referência MX
no registro bar.waide.me.uk
do included
, mas foo.waide.me.uk
não tem MX . Se o MX
no registro include
d não fosse avaliado no contexto do domínio include
d ( bar.waide.me.uk
), ele não poderia resolver nada.
E apenas para completar, quando eu removo o registro SPF de include
de foo.waide.me.uk
, então, como seria de esperar agora, Beveridge relata uma falha.