[MASOCH-L] Adoção de SPF

[Danton Nunes]

On Tue, 18 Jan 2011, Anísio J. Moreira Neto wrote:

> A implantação do SPF funciona através da inserção de um registro de DNS 
> do tipo TXT no domínio, no qual é registrado quais MTAs são autorizados 
> a enviar e-mail do domínio, por exemplo: Crio o registro TXT com o 
> seguinte valor: "v=spf1 189.x.9.2 ~all" no domínio exemplo.eti.br, sendo 
> assim estou informando que apenas o IP 189.x.9.2 é o MTA do domínio 
> exemplo.eti.br.

a lista do registro TXT é uma ACL (lista de controle de acesso). o último 
elemento é a política 'default' da lista. ~all significa 'softfail', então 
você está indicando que o 189.x.9.2 é um transmissor válido para o domínio 
mas que qualquer outro IP pode transmitir email desse domínio embora não 
de forma oficial. cabe ao receptor aplicar, se quiser, políticas distintas 
para o 'pass' e o 'softfail', por exemplo, por o segundo em uma graylist.

> A utilização do SPF acontece quando um MTA recebe um e-mail, e o mesmo 
> busca no DNS o registro TXT do domínio do remetente do e-mail, para 
> confrontar o conteúdo do registro com o MTA que está enviando o e-mail. 
> Também concordo em apenas classificar o e-mail como spam quando o MTA 
> remetente não consta no registro TXT.

na verdade, confrontar com o endereço IP do MTA remetente. Aí é um ponto 
em que o SPF "cheira mal", pois ele usa um recurso de outra camada da 
pilha de protocolos, que supostamente deveria ser ortogonal. É daí que 
surge a necessidade de gambiaras como reescrita de envelopes para poder 
retransmitir uma mensagem sem que seja rejeitada por causa do SPF.

há alternativas que são ortogonais, o DKIM, por exemplo.

> Leandro, não entendi o reescrever o endereço do remetente, no meu 
> entendimento o remetente não muda, no caso de um provedor de serviços, o 
> mesmo deveria apontar do TXT dos domínios de seus clientes para seu MTA.

suponha o seguinte cenário: tenho dois MX com prioridades diferentes, o 
principal é onde estão as caixas postais e um secundário 'queue-only' que 
funciona em caso do principal estar indisponível ou pifado.

o servidor principal sai do ar por algumas horas. mensagens se acumulam no 
secundário - e é para isso que ele existe. quando o servidor principal 
volta à luta, as mensagens acumuladas no secundário começam a ser 
despachadas para o principal.

o que acontece com o SPF agora? vai dar pau, porque o endereço IP do 
servidor secundário não é o mesmo do MTA remetente. Então é necessário 
reescrever o endereço do remetente no envelope para que a mensagem não 
seja recusada.

> Henrique, não entendi qual seria o trabalho de um MTA no envio de um 
> e-mail com SPF, no meu conceito o MTA que envia não modifica o cabeçalho 
> do e-mail, basto o domínio ter o TXT registrado no DNS.

o que recebe, se quiser verificar o SPF, terá algum trabalho, mas mínimo.

> Por que o domínio oracle.com nem sequer possui registro TXT? Por que não 
> utiliza o domínio para envio de e-mail? Ora, faça igual a IBM, que 
> possui um registro TXT sem nenhum MTA cadastrado. Desta forma evita que 
> sejam enviados e-mails falsos utilizando o nome da empresa.

vá perguntar para os manés da Oracle! ;-)