Meus artigos: Restrições no MTA - Compliance e Policy Enforcement
De Ramoni
Artigo não terminado.
Conteúdo |
Introdução
- Existem muitas restrições possíveis de se aplicar durante a conexão de recebimento de email. Estas medidas têm a vantagem de economizar recursos para o processamento do email já que ele nem entra na fila caso seja bloqueado por estas medidas.
- Outro fator importante sobre estas medidas é que não existem falsos positivos. Não é uma análise usando algoritmos que podem falhar. São exigências que o cliente cumpre ou não. Quando você compra uma passagem aérea pela Internet e não recebe o email de confirmação porque o servidor origem não possuia reverso, isto não é falso positivo, ele foi bloqueado por uma medida que você optou por usar.
- Não vou falar de nenhum MTA específico porque acredito que todo MTA deva fornecer estas funcionalidades.
- Vou dividir as medidas em dois tipos:
- Compliance
- Policy Enforcement
Compliance
- As regras de compliance consistem que exigir conformidade por parte do cliente.
- O protocolo SMTP em sua RFC especifica normas de como uma transação de email deve funcionar e para isto existem algumas exigências. Qualquer um colocando um servidor de email na Internet precisa cumprir estas regras, e exigí-las, deveria ser o padrão.
- O email hoje na Internet está um caos, e minha opinião sobre como chegamos a isso está em outro artigo.
- A importância de usar estas medidas é que algumas delas são difíceis dos spammers obedecerem.
Checagem de IP reverso
- Esta medida consiste em exigir que o IP do cliente possa ser resolvido em nome, ou seja, que o administrador do DNS do bloco IP do cliente tenha configurado um registro PTR para este host. Um nível além, é que este nome retornado resolva de volta para o IP do cliente.
- Esta restrição não é explicitamente exigida na RFC, mas é boa prática que todo servidor tenha seu IP como exclusivo, com registro PTR e apontando de volta para o IP do servidor.
Validação de HELO/EHLO
- Apesar de estar explícito na RFC a exigência aqui cobrada, muitos, mas MUITOS sistemas de email não estão em conformidade com ela.
- Trecho da RFC:
The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
- O problema normalmente acontece porque se coloca um nome interno para a máquina, como por exemplo mailpubrjo01.domínio e a máquina passa a se identificar com este hostname quando envia emails. Para resolver, ou se cria no DNS este nome apontando para o IP de saída do servidor, ou se configura para ele usar outra string válida.
Validação de remetente
- Consiste em não receber emails que não podem ser respondidos.
- A RFC exige que o domínio do remetente para ser válido (receber emails de volta), precisa ter um registro MX ou um registro A no DNS.
