Mandic Wiki

 

Seguimos uma norma do Comitê Gestor da Internet no Brasil no combate ao spam. Caso queira maiores detalhes, favor acessar: http://antispam.br/admin/spf/

 

 

O SPF (Sender Police Framework) é um protocolo aberto desenvolvido com o objetivo de permitir que administradores de domínios possam informar publicamente quais servidores de e-mail são legítimos para seus domínios e quais não são.

 

 

O SPF é uma política que ajuda a corrigir uma brecha existente no sistema de e-mails, a qual permite que mensagens de correio eletrônico sejam impersonificadas, isto é, que sejam enviadas como se partissem de um endereço que não é o verdadeiro remetente. Enquanto nem toda mensagem de spam é forjada (impersonificada), virtualmente todas as mensagens forjadas são spam. Dessa forma, à medida que é adotado por uma quantidade cada vez maior de servidores na Internet, o SPF contribui para a diminuição da quantidade de spam e mensagens falsas que circulam na rede.

 

 

Basicamente, o SPF é constituído por um registro DNS do tipo texto, o qual contém os dados públicos sobre os remetentes confiáveis do domínio. Um servidor de e-mails da rede compatível com o protocolo SPF, ao receber uma mensagem, verifica se o domínio do remetente possui o registro DNS SPF. As ações a serem tomadas conforme o resultado dessa verificação são especificadas no protocolo e, em alguns casos, podem variar de servidor para servidor. O caso comum, quando o domínio possui o registro SPF, é o seguinte: se o registro indica o servidor do remetente como um servidor confiável para o domínio, a mensagem é aceita; se o servidor remetente não aparece entre os servidores autorizados, a mensagem é rejeitada, normalmente havendo um retorno a respeito para o remetente.

 

 

Domínio pode ou não autorizar que outros IP’s de fora desta relação enviem e-mails em seu nome. O administrador configura esta relação na entrada TXT da zona de DNS seguindo as regras da RFC 4408 (https://www.ietf.org/rfc/rfc4408.txt).

 

 

A entrada SPF, pode ter 4 atributos diferentes que alteram o modo como o servidor de destino tratará mensagens enviadas de servidores que não estejam presentes na mesma.

 

 

Tipos de Atributos:

 

 

+ 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.

 

 

~ 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.

 

 

? 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.

 

 

SPF Mandic

 

 

Abaixo está a regra de SPF que deve ser criada na zona de DNS de seu domínio:

 

 

TXT   v=spf1 include:spf.idc2.mandic.com.br -all

 

 

 

 

Seguimos uma norma do Comitê Gestor da Internet no Brasil no combate ao spam. Caso queira maiores detalhes, favor acessar: https://antispam.br/admin/dkim/

 

 

DKIM é uma especificação do IETF que define um mecanismo para autenticação de e-mail baseado em criptografia de chaves públicas. Através do uso do DKIM, uma organização assina digitalmente as mensagens que envia, permitindo ao receptor confirmar a autenticidade da mensagem. Para verificar a assinatura digital, a chave pública é obtida por meio de consulta ao DNS do domínio do assinante.

 

 

Ao contrário do SPF, que verifica somente o envelope, o DKIM verifica o cabeçalho da mensagem. Esta técnica acarreta um custo computacional adicional por mensagem, tanto para o MTA remetente quanto para o receptor.

 

 

Resumindo, o DKIM é uma forma de autenticação por e-mail que adiciona assinaturas de criptografia digital para as mensagens de correio eletrônico.

 

 

Isso garante que o e-mail vem de uma fonte confiável e que ele não foi alterado ou forjado no período de trânsito entre os servidores de envio e de recebimento.

 

 

Quando você envia uma mensagem eletrônica, um par de chaves privadas/públicas será gerada.

 

 

A chave privada é usada para assinar o e-mail, enquanto a pública é divulgada para o DNS de seu domínio usando registros TXT.

 

 

Nesse caso, o registro é usado pelos servidores do destinatário para validar os e-mails.

 

 

Como implementar em seu domínio na Mandic?

 

 

Por padrão, o domínio na estrutura de e-mail em seu painel vem com o recurso DKIM desabilitado sendo necessário solicitar ao suporte à ativação.

 

 

 

 

Caso queira maiores detalhes, favor acessar: https://dmarc.org/ e/ou https://tools.ietf.org/html/rfc7489

 

 

DMARC é uma especificação do IETF que define um padrão que permite que remetentes e destinatários de e-mail cooperem no compartilhamento de informações sobre o e-mail que eles enviam uns aos outros. Essas informações ajudam os remetentes a melhorar a infraestrutura de autenticação de e-mail para que todos os seus e-mails possam ser autenticados.

 

 

O DMARC, baseia-se no SPF e no DKIM, que são dois mecanismos de proteção e segurança amplamente difundidos e agrega uma função especial de relatórios, que permite monitorar o comportamento dos e-mails.

 

 

Ele também dá ao legítimo proprietário de um domínio na Internet uma forma de solicitar que as mensagens ilegítimas – Spam falsificado, phishing – sejam colocadas diretamente na pasta de spam imediatamente.

 

 

A política do DMARC permite que um remetente indique que suas mensagens são protegidas por SPF e/ou DKIM, e diz ao receptor o que fazer se nenhum desses métodos de autenticação funcionar – mandar para o lixo ou rejeitar a mensagem, por exemplo.

 

 

Criação da Entrada DMARC

 

 

DMARC usa entradas TXT do DNS de seu domínio.

 

 

Abaixo segue exemplos de entradas TXT configuradas em um domínio:

 

 

"v=DMARC1; p=none; rua=mailto:  O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. "

 

 

Neste exemplo de entrada TXT para DMARC, se o provedor receber uma mensagem do domínio, nenhuma ação será tomada. Porém, todas as mensagens irão aparecer no relatório diário enviado para o e-mail cadastrado “ O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. ”.

 

 

"v=DMARC1; p=quarentine; rua=mailto:  O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. "

 

 

Neste exemplo de DMARC, se o provedor receber uma mensagem do domínio, as mensagens serão direcionadas para quarentena.

 

 

"v=DMARC1; p=reject; rua=mailto:  O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. , mailto: O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. "

 

 

Neste exemplo de DMARC, se o provedor receber uma mensagem do domínio, as mensagens serão 100% rejeitadas. Após, serão informados em seu relatório diário nos dois e-mails cadastrados: “ O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. ” e “ O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. ”

 

 

Abaixo estão as tags de configuração:

 

 

Tags obrigatórias

 

 

v: é a tag de versão que identifica o registro recuperado como DMARC record. Seu valor deve ser DMARC1 e precisa estar listado primeiro no DMARC record.

 

 

p: é a tag que indica a política solicitada que você deseja que os provedores de mailbox apliquem quando seu e-mail falhar nas verificações de autenticação e alinhamento do DMARC. A política é aplicada a um domínio principal (exemplo.com) e a todos os seus subdomínios (m.exemplo.com, b.exemplo.com, etc.), a menos que a tag sp seja usada (veja abaixo) com um valor de política diferente.

 

 

Saiba mais sobre os diferentes valores de política aqui. Os diferentes valores de política são:

 

Nenhum

Quarentena

Rejeitar

 

Tags opcionais, porém recomendadas

 

 

rua=mailto: O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. : tag para que os provedores de mailbox saibam para onde você deseja que os relatórios agregados sejam enviados. Os relatórios agregados fornecem visibilidade sobre a integridade do seu programa de e-mail, identificando possíveis problemas de autenticação ou atividades maliciosas. Esses relatórios contêm informações de nível superior e são enviados diariamente pelos provedores de mailbox participantes.

 

 

fo: tag para que os provedores de mailbox saibam que você deseja amostras de mensagens de e-mails que falharam no SPF e/ou DKIM. Existem quatro opções de valor disponíveis:

 

 

0: gera um relatório de falha do DMARC se nenhum mecanismo de autenticação subjacente (SPF e DKIM) produzir um resultado "aprovado" alinhado. (padrão)

 

 

1: gera um relatório de falha do DMARC se algum mecanismo de autenticação subjacente (SPF e DKIM) produzir algo diferente do resultado "aprovado" alinhado. (recomendado)

 

 

d: gera um relatório de falha do DKIM se a mensagem tiver uma assinatura que tenha falhado na avaliação, independentemente do alinhamento.

 

 

s: gera um relatório de falha do SPF se a mensagem falhar na avaliação do SPF, independentemente do alinhamento.

 

 

Tags opcionais

 

 

sp: tag que indica uma política solicitada a todos os subdomínios nos quais o e-mail está falhando nas verificações de autenticação e alinhamento do DMARC. É mais eficaz quando um proprietário de domínio deseja especificar políticas diferentes para o domínio principal e todos os subdomínios. As opções de política são as mesmas para a tag "p" listada acima. Se essa tag não for usada nos subdomínios, o conjunto de políticas que usa a tag p será aplicado ao domínio principal e a todos os seus subdomínios.

 

 

adkim: indica alinhamento rigoroso ou relaxado do identificador DKIM. O padrão é relaxado.

 

 

aspf: indica alinhamento rigoroso ou relaxado do identificador SPF. O padrão é relaxado.

 

 

pct: a porcentagem de mensagens às quais a política DMARC deve ser aplicada. Essa tag implementa e testa gradualmente o impacto da política.

 

 

Os valores são números inteiros que variam de 1 - 100. O valor padrão é 100.

 

 

ruf=mailto: O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. : tag para que os provedores de mailbox saibam para onde você deseja que seus relatórios de perícia (em nível de mensagem) sejam enviados. Os relatórios de perícia são mais detalhados e devem ser entregues pelos provedores de mailbox quase imediatamente após a detecção de uma falha de autenticação DMARC. No entanto, devido a possíveis problemas de privacidade e desempenho, a maioria dos provedores de mailbox não os envia.

 

 

rf: formato para relatórios de falha de mensagem. O padrão é Formato de Relatório de Falha de Autenticação, ou “afrf”. Afrf é o único valor aceito neste momento.

 

 

ri: o número de segundos decorridos entre o envio de relatórios agregados ao remetente. O valor padrão é 86400 segundos, o que equivale a um dia. Os provedores de mailbox participantes que acomodem o envio de mais de um relatório agregado por dia fornecerão relatórios mais frequentes com base no melhor esforço.