Políticas de Segurança e Confiabilidade
- Detalhes
- Última atualização em Terça, 18 Fevereiro 2020 15:48
Abaixo é possível verificar as políticas de segurança e confiabilidade:
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.