Notícia publicada por brain em junho 30, 2004 09:04 AM
| TrackBack
O SPF (ou Sender Policy Framework) é uma extensão do SMTP que facilita a identificação de spam com endereço de origem forjado. A descrição técnica é simples: cada domínio interessado em combater e-mails forjados acrescenta uma linha de texto padronizada à configuração do seu próprio DNS. Esta linha segue o padrão definido pelo SPF, e descreve quais os endereços dos servidores de e-mail autorizados a gerar mensagens daquele domínio.
Assim, o administrador do domínio provedorX.com pode definir em seu DNS que mensagens com o sufixo "@provedorX.com" só podem ser originadas dos servidores mailer1.provedorX.com e backup.reserva.com. Em consequência, quem tiver suporte ao SPF e receber mail com o sufixo "@provedorX.com" que tenha sido originado em outro servidor que não seja um dos dois definidos acima precisará apenas fazer uma rápida consulta de DNS para saber que deverá tratá-lo como mail forjado.
A Wikipedia dá maiores detalhes sobre o padrão, inclusive mencionando que já é suportado por softwares como o SpamAssassin 2.70 e patches ou plugins para Postfix, Sendmail, Exim, and Qmail. O padrão já foi abraçado por domínios de grande volume, como AOL, Earthlink, Microsoft, Google, editora O'Reilly e outros.
Para saber mais sobre os aspectos técnicos do SPF e como funciona sua configuração nos endereços de origem (que é bastante simples e pode até mesmo envolver apenas uma linha na configuração do DNS), consulte este artigo do Linux Journal escrito pelo próprio autor do padrão.
Por mais que eu me concentre nesta noticia, eu nao consigo entende-la. As vezes é preciso uma tecla SAP para entender algumas noticias postadas. :P
Implementamos o SPF aqui na provedora em que trabalho, para alguns domínios. Foi simples configurar o DNS, porém pra se preparar o MTA é necessário um pouco mais de experiência, caso se queira chegar no resultado desejado sem perda de perfomance. No caso do Postfix, por exemplo, recomenda-se utilizar a versão em desenvolvimento (snapshot), que suporta políticas plugáveis. Tivemos que fazer diversas alterações nos softwares em questão, para que atendesse aos nossos requisitos.
O problema na minha opinião é que a checagem de SPF ainda é "cara" demais, pra relativamente pouco benefício. Dos e-mails que recebemos, vemos que em apenas poucos o domínio do remetente possui uma entrada SPF preenchida.
Portanto, para o SPF se tornar mais interessante, é necessário que seja adotado em massa no Brasil. Entretanto, além de representar um custo de configuração e manutenção a mais, é difícil esperar que esse tipo de mudança seja feita naqueles "domínios velhos", em que o administrador configurou o e-mail há alguns anos e se esqueceu (talvez até seja um open relay). Essa discussão é velha, e prefiro agir a discutir questões batidas.
Aos administradores que me leêm, caso precisem de ajuda, posso tentar ajudar com questões pontuais para a configuração do seu DNS e do MTA.
Seria tão bom termos no Brasil uma "zona" (de DNS) livre de spam...
".. uma zona livre de spam." Não que o SPF seja feito pra combater SPAM, mas ele dá uma excelente contribuição.
Olá,
só uma questão:
Se todo o controle é feito através de 'headers' (entendi direito?) que vão junto com o e-mail,
não seria fácil, para o spanner, simulá-los?
Não, Eduardo. A vantagem do SPF é que ele complementa os headers com informações do envelope smtp e com um campo a mais no servidor DNS do domínio de origem.
Entendi como é, se o cara manda o email de @fulano.com.br ele pergunta ao mx do dominio quem pode mandar aquele email, e compara o dns com o dns do spammer, que pode fazer spoof do header da mensagem , mas nao do dns do verdadeiro servidor. :P , simples e pratico isso viu, mas nao creio que isso ai junto com um ip spoofing é facil de burlar. Mas de qq forma é valido e espero estar errado :P
Alguem sabe onde eu posso conseguir um how to sobre como conf esse spf?
A idéia até que é legal. Mas nem todo email originado em um servidor diferente é forjado.
Eu posso ter dois endereços de email em dois dominios diferentes (xxx@bol.com.br e xxx@terra.com.br) e usar o mesmo servidor smtp para enviar mensagens legítimas com qualquer um dos dois emails como remetente.
Por exemplo: Estou enviando um email de xxx@bol.com.br usando o server smtp.terra.com.br.
Giovani: pela proposta, cabe ao administrador de cada um dos domínios dizer quais os servidores autorizados a enviar e-mail dele. Se você for o administrador de um deles e autorizar o smtp do outro a mandar mensagens legítimas, tudo vai funcionar como sempre funcionou. Caso contrário, as suas mensagens vão ser tratadas como tendo sido enviadas por um servidor não homologado para o domínio.
continuando a observação do Giovani: no nosso caso, fazemos uso de aliases de e-mail (com nosso domínio) para os usuários remotos (fora de SP), que utilizam vários provedores locais diferentes - incluindo alguns grandes como UOL e Terra. Se autorizamos os servidores desses caras a enviar e-mails, é o que Augusto disse: tudo fica como antes; por outro lado, essa nossa solução barata de criar identidade institucional (adoção de aliases) ficaria inviabilizada se não autorizássemos. Assim, creio ter mostrado uma situação real em que o SPF não ajuda (infelizmente)... a menos que eu não tenha entendido...
Acho que neste caso a solução ideal (e correta, do ponto de vista da preservação da integridade) seria simplesmente habilitar o acesso destes seus usuários remotos ao servidor SMTP da sua empresa (habilitando autenticação, claro) e configurar os clientes deles de acordo.
Eu discordo de você quando diz que esta é uma situação que o SPF não ajuda. Entendo por que você quer "fingir" que as mensagens vem do seu domínio, mas é exatamente esta a situação que o SPF busca combater. Assim, ele de fato torna as coisas menos fáceis para você - mas impedir o e-mail com domínio inconsistente é o objetivo da coisa.
Abraços
Augusto
Comentários desativados: Esta discussão é antiga e foi arquivada, não é mais possível enviar comentários adicionais.