Postfix reject_unknown_reverse_client_hostname: substitua default unknown_client_reject_code (450) por 550. Por que / quando não devo?

Na batalha diária contra o SPAM, houve várias vezes em que fui tentado a impor fortemente os requisitos de DNS de clientes que se conectam a partir da Internet selvagem.

Em detalhes, eu teria adicionado a configuração reject_unknown_reverse_client_hostname na minha seção smtpd_client_restrictions , como em:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining

De qualquer forma, observei que, ao atingir essa restrição, o comportamento do Postfix é bastante "suave", pois o valor padrão unknown_client_reject_codeé 450. Portanto, o cliente é convidado a continuar tentando novamente.

Ao investigar uma resposta de 550, encontrei a seguinte declaração na documentação oficial do Postfix :

insira a descrição da imagem aqui

Estou absolutamente não um especialista sobre toda a RFC 5321 , mas como alguém idade suficiente para saber RFC 821 , eu realmente não vejo por que, uma resposta em vez de um 450 550, poderia impactar o meu exemplo Postfix no nível máximo SMTP ( violando a conformidade com a RFC), especialmente considerando que, no caso de erros temporários, o Postfix fica com 450, independentemente da configuração explícita.

Então, alguém pode me ajudar a entender qual é o problema dessa substituição?

PS: enquanto isso, terminei com uma restrição "relaxada":

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname

postfix smtp spam

— Damiano Verzulli
fonte

Vou começar com duas respostas práticas

A primeira e mais óbvia resposta é que, no caso de um erro temporário de DNS, um retorno temporário permitirá que o servidor de email do remetente tente novamente até que o erro de DNS seja corrigido. Nesse caso, um salto permanente impedirá que as correspondências presas reais cheguem até você.
A segunda resposta é que uma grande quantidade de spam é enviada através de caixas de botnet que não possuem nenhuma forma de programas funcionais reais para enviar o correio. Eles pulverizarão o lixo eletrônico apenas uma vez e não tentarão reenviar nenhuma mensagem se a mensagem receber um erro temporário ou permanente. Portanto, usando um erro temporário, você está bloqueando uma grande porcentagem de spam definitivamente, mas ainda está permitindo que o ham tente novamente. (A propósito, é por isso que a lista cinza ainda funciona e ainda captura muitos spams.)

Além desses, há também uma resposta que tem mais a ver com a teoria e a RFC

A RFC diz na seção 4.2.1. aquele:

Uma regra prática para determinar se uma resposta se encaixa na categoria 4yz ou 5yz (veja abaixo) é que as respostas são 4yz se puderem ser bem-sucedidas se repetidas sem nenhuma alteração no formulário de comando ou nas propriedades do remetente ou do destinatário (ou seja, , o comando é repetido de forma idêntica e o destinatário não coloca uma nova implementação).

No caso de uma falha de pesquisa inversa, seria possível que a mensagem fosse aceitável sem nenhuma alteração na própria mensagem, desde que o erro de DNS fosse corrigido. Portanto, isso deve ser um erro temporário.

Nos casos em que a mensagem não é spam, o sysadmin do servidor de envio pode perceber a mensagem de erro e corrigir o problema de DNS, para que a mensagem possa ser entregue sem que o usuário precise intervir e reenviar a mensagem. E, a menos que o usuário que está enviando o email também seja responsável pelo servidor de e-mail e / ou suas entradas DNS, mesmo que receba um retorno permanente diretamente, ele não poderá fazer nada com ele - ao contrário, por exemplo, de um erro de ortografia endereço.

Obviamente, você ainda tem sempre o direito de rejeitar qualquer email por qualquer motivo.

— Jenny D
fonte

Pensei em problemas temporários de DNS, mas ... parece que eles não deveriam ser um problema como ... " O servidor SMTP sempre responde com 450 quando o mapeamento falha devido a uma condição de erro temporário ". Isso deve incluir problemas temporários de pesquisa de DNS. Não é? Quanto ao segundo ponto (BotNet, lista cinza, etc.), parece razoável: quando os clientes não implementam um mecanismo de enfileiramento adequado, uma resposta 4XX produz os mesmos efeitos de um 5XX. De qualquer forma, ainda sinto falta do porquê disso ter impactos no nível da RFC.

— Damiano Verzulli 6/06/2015

@DamianoVerzulli É aplicável quando o mapeamento falha com um erro, não quando o DNS está configurado incorretamente para retornar o nome errado e, posteriormente, é corrigido. De qualquer forma, expandi um pouco os problemas referentes à RFC.

— Jenny D

Obrigado por apontar para a seção RFC adequada. Estou focando nisto: "as respostas são 4yz se puderem ser bem-sucedidas se repetidas SEM QUALQUER MUDANÇA no formulário de comando ou nas PROPRIEDADES do remetente ou destinatário". Meu primeiro palpite é que o nome de host DNS do cliente, bem como seu mapeamento DNS reverso, são propriedades do remetente. Não é? Caso contrário, não consigo ver o que poderia ser uma propriedade do remetente. (BTW: por favor, não leve meus comentários para o lado pessoal. Estou realmente interessado nesta discussão e aprecio muito seus pontos! Obrigado por comentar!).

— Damiano Verzulli 6/06/2015

@DamianoVerzulli O nome do host DNS não é uma propriedade do servidor de envio de mensagens e não pode ser alterado na configuração do servidor de correio. É controlado pelo servidor DNS autoritativo, que geralmente não é o mesmo servidor, muito menos parte do servidor de email. Às vezes, nem é controlado dentro da mesma organização. (Não estou levando para o lado pessoal - trata-se de uma discussão de fatos, sem argumentos ad hominem, não há nada para levar para o lado pessoal! Concordo que é muito interessante e não acho claro, há um caso a ser feita para o outro lado também).

— Jenny D