Postfix reject_unknown_reverse_client_hostname: substitua o padrão unknown_client_reject_code (450) para 550. Por que / quando eu não deveria?

Question

Na batalha diária contra o SPAM, houve várias ocasiões em que me senti tentado a impor strongmente os requisitos de DNS dos clientes que se conectavam da Internet selvagem.

Em detalhes, eu teria adicionado a configuração reject_unknown_reverse_client_hostname no meu smtpd_client_restrictions seção, 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 "soft", já que o valor padrão para o unknown_client_reject_code é 450. Por isso, o cliente é convidado a continuar tentando.

Durante uma investigação para uma resposta 550, conheci a seguinte declaração, na documentação oficial do Postfix :

Nãosouabsolutamenteumespecialistaemtodaa RFC 5321 , mas como alguém idade suficiente para saber RFC 821 , eu realmente não vejo por que, uma resposta 550 em vez de 450, poderia afetar minha Instância de postfix no nível de SMTP máximo (quebra de conformidade com RFC), especialmente considerando que, em caso de erros temporários, o Postfix permanecerá com um 450, independentemente da configuração explícita.

Então, alguém pode me ajudar a entender qual é o problema com esse substituto?

P.S .: entretanto, acabei 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 

    

Answer 1

Vou começar com duas respostas práticas

1. A primeira e mais óbvia resposta é que, em um caso em que há um erro de DNS temporário, uma rejeição temporária permitirá que o servidor de email do remetente tente novamente até que o erro de DNS seja corrigido. Nesse caso, uma rejeição permanente bloqueará o recebimento de e-mails reais de você.

2. A segunda resposta é que uma grande quantidade de spam é enviada através de caixas de botnet que não possuem nenhum tipo de programa funcional real para enviar o email. Eles vão pulverizar seu lixo apenas uma vez e não tentarão reenviar qualquer mensagem se a mensagem receber um erro temporário ou permanente. Então, usando um erro temporário, você está bloqueando uma grande porcentagem do spam de uma vez por todas, mas ainda está permitindo que ele tente de novo. (A propósito, é por isso que o greylisting ainda funciona e ainda captura um lote de spam.)

Além desses, há também uma resposta que vale mais para a teoria e para o RFC

O RFC diz na seção 4.2.1. isso:

A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated without any change in command form or in properties of the sender or receiver (that is, the command is repeated identically and the receiver does not put up a new implementation).

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

Em um caso em que a mensagem é not spam, o sysadmin do servidor de envio de correio pode perceber a mensagem de erro e corrigir o problema do DNS, para que a mensagem possa ser entregue sem que o usuário precise intervir reenvie a mensagem. E a menos que o usuário que envia o e-mail também seja responsável pelo servidor de e-mail e / ou por suas entradas de DNS, mesmo que recebam uma rejeição permanente diretamente, eles não poderão fazer nada com ela - ao contrário de o caso de um endereço incorreto.

É claro que você ainda está sempre em seu direito de rejeitar qualquer email por qualquer motivo.