O site para validação é o http://www.kitterman.com/spf/validate.html. Digite o seu domínio e clique em “Get SPF record”, o resultado será exibido por meio de um arquivo em python (http://www.kitterman.com/getspf2.py).
Exemplo de um cliente da RT7 com dois spf’s (do gmail e do aknamail) configurados corretamente (só pode ter 1 registro e ele tem que ser em TXT, pois o tipo SPF já não se usa mais):
1. Introdução
SPF é uma tecnologia para combater a falsificação de endereços de retorno dos emails (return-path). O mecanismo permite:
- ao administrador de um domínio: definir e publicar uma política SPF, onde são designados os endereços das máquinas autorizadas a enviar mensagens em nome deste domínio; e
- ao administrador de um serviço de e-mail: estabelecer critérios de aceitação de mensagens em função da checagem das políticas SPF publicadas para cada domínio.
O processo de publicação de uma política SPF é independente da implantação de checagem de SPF por parte do MTA, estes podem ou não ser feitos em conjunto.
2. Publicando a política SPF
Ao publicar uma política de SPF, o administrador de um domínio está autorizando determinados MTAs a enviar e-mails em nome deste domínio. O objetivo é evitar que terceiros enviem mensagem indevidamente em nome de seu domínio, e que mensagens de erro (bounces) causadas por spam com envelope falso sejam enviadas para o seu servidor.
Estas políticas são publicadas através de registros TXT do DNS, em formato ASCII. Um exemplo desse registro é:
Exemplo:
example.com. IN TXT "v=spf1 a mx ip4:192.0.2.32/27 -all"
Neste caso a política estabelece que pode enviar mensagens em nome do domínio example.com uma máquina que satisfaça um dos seguintes critérios:
- seu endereço IP deve ser um RR tipo A do domínio example.com (a);
- seja designada como MX do domínio example.com (mx); ou
- pertença ao bloco de endereços IP 192.0.2.32/27 (ip4).
A cláusula “-all” diz que devem ser recusados (“-“, prefixo Fail) e-mails partindo de qualquer outro endereço IP (all).
Todas as opções de prefixos são:
- “+” Pass
- “-” Fail
- “~” SoftFail
- “?” Neutral
O prefixo é opcional, e se omitido o valor utilizado é o “+” (Pass).
A cláusula “all” deve ser sempre a cláusula mais à direita. Ela define qual resposta será retornada em uma consulta SPF, caso nenhuma das outras cláusulas se aplique.
O administrador de um MTA que consulte a política SPF do domímio do remetente de um e-mail, como definido no envelope, poderá rejeitar ou marcar como suspeita uma mensagem que não satisfaça à política SPF daquele domímio.
A especificação completa de como expressar uma política SPF pode ser encontrada no site de referência do SPF (http://www.openspf.org/) e na RFC 4408: “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1” (http://tools.ietf.org/html/rfc4408).
3. Configurando o MTA
A maioria dos MTAs atuais possui suporte a SPF, seja através de filtros externos (Milters), patches ou suporte nativo. Nesta seção trataremos de considerações gerais sobre a configuração de um MTA para checar registros SPF.
É necessário estabelecer quais serão as ações tomadas dependendo da resposta obtida à consulta SPF. O Internet-Draft “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL” define algumas possíveis interpretações para os resultados obtidos:
- não há registro SPF publicado: neste caso, não é possível determinar se o endereço IP está ou não autorizado a enviar e-mails em nome do domímio sendo consultado.
- neutral (“?“): o dono do domínio não tem como ou não quer definir se um determinado endereço IP está ou não autorizado a enviar mensagens em nome do domínio. Este resultado deve ser tratado exatamente como se não existisse um registro SPF, não devendo ser avaliado de forma mais rigorosa devido a isto;
- pass (“+“): significa que o IP está autorizado a enviar mensagens em nome do domínio, sendo que o domínio consultado pode, então, ser considerado responsável pelo envio da mensagem;
- fail (“-“): significa explicitamente que o IP não está autorizado a enviar mensagens em nome do domínio consultado. Este resultado pode ser utilizado para rejeitar a mensagem ou para marcá-la para ser avaliada mais rigorosamente;
- softfail (“~“): deve ser tratado como um resultado intermediário entre os níveis fail e neutral. Neste caso, o domínio consultado informa que acha que o IP não está autorizado, mas que não pode fazer uma afirmação taxativa. A mensagem não deve ser rejeitada apenas com base neste resultado, mas é recomendável submetê-la a outros testes. Softfail também tem sido usado para indicar uma situação transitória, em que o SPF está sendo adotado por um domínio.
Em geral, os MTAs que consultam registros SPF podem processar um conjunto de regras pré-definidas pelo administrador antes de processar o registro recebido por DNS. Isso permite implementar listas brancas, discutidas na seção sobre listas de bloqueio.
4. SPF e esquemas de retransmissão de e-mails
Mensagens legítimas, mas que tenham passado por um relay ou tenham sido redirecionadas, podem ser recusadas por MTAs que checam SPF. Para evitar que estas mensagens sejam rejeitadas, devem ser adotadas algumas estratégias, como SRS (Sender Rewriting Scheme) e autorizações especiais.
4.1. SRS – Sender Rewriting Scheme
Para evitar que MTAs que checam SPF rejeitem mails redirecionados, é necessário que o relay reescreva o endereço do remetente no envelope e encapsule o endereço original.
O SRS reescreve o endereço do remetente no envelope, de modo que:
- o IP do transmissor é autorizado (pass) a enviar mensagens em nome do domínio à direita do “@“;
- o endereço à esquerda do “@” permite determinar qual é o remetente real;
- o endereço à esquerda do “@” contém uma assinatura e um timestamp, que permitem reconhecer sua validade em mensagens de erro retornadas.
Por exemplo, considere o remetente “[email protected]“, cuja mensagem é retransmitida por “example.org“, o envelope poderá ser reescrito da seguinte forma:
Exemplo:
[email protected]
onde,
- “HHH” é um hash criptográfico para validar os dados do envelope sendo gerado, de forma a impedir que spammers utilizem o relay.
- “TT” é um timestamp.
Além de evitar o abuso por parte de spammers, estas informações, também permitem que o relay receba uma mensagem de erro, consiga validá-la e enviá-la para o endereço correto de origem.
Nem todos os MTAs têm suporte a esquemas de reescrita do endereço de remetente. Os que têm, quase sempre se baseiam na libsrs2 (http://www.libsrs2.org/).
De modo geral, somente servidores especializados em relays de mensagens é que precisam do SRS para poder operar em conjunto com SPF. Para outros tipos de MTAs, que estejam sob seu controle, há uma solução mais simples, apresentada a seguir.
4.2. Relays confiáveis
É bastante comum uma rede possuir dois (ou mais) servidores de correio eletrônico destinados à recepção de mensagens: um principal, responsável por entregar as mensagens para as caixas postais dos destinatários e outros secundários que não fazem entrega de mensagens diretamente aos destinatários. Caso o servidor principal fique impossibilitado de receber mensagens, os secundários as recebem e as enfileiram, para retransmití-las ao principal quando este estiver restabelecido.
Embora SRS pudesse ser utilizado em um servidor secundário, uma técnica muito mais simples consiste em:
- configurar o servidor secundário para também checar SPF, e tomar as mesmas ações que o servidor principal;
- incluir o endereço IP do servidor secundário em uma lista branca de endereços IP previamente aprovados. Os MTAs que checam SPF normalmente possuem uma regra local para isso;ouconfigurar o servidor secundário para que se autentique no servidor principal antes de iniciar as transações de envio das mensagens em sua fila.
4.3. Redirecionamento
O redirecionamento de mensagens através de esquemas como o uso do .forward ou de aliases redirecionando mensagens de um domínio para outro, também acarretam dificuldades quando o domínio tem um registro SPF.
Nesses casos é necessário reenviar o e-mail, reescrevendo o remetente no envelope, para evitar rejeição por parte de MTAs que chequem SPF.
5. Listas negras e SPF
Caso seja feito o uso de listas negras, é interessante verificar se o endereço IP do remetente se encontra em uma lista negra somente depois de verificar o registro SPF. Caso o resultado do SPF for Pass, o IP não deve ser bloqueado.
Esta recomendação é importante porque listas negras possuem uma taxa relativamente alta de falsos positivos, como discutido na seção sobre listas de bloqueio.
Nem todos os MTAs, entretanto, permitem que se faça a consulta à lista negra depois de verificar o SPF. É possível usar as políticas padrão do SPF para implementar consultas a listas negras, embora sejam configurações não triviais. No site de referência do SPF (http://www.openspf.org/) há vários exemplos.
Fonte: Antispam.
