Desde que você devolva o e-mail recusando-se a recebê-lo, um spammer não poderá usar você para incomodar alguém inocente com muitos retornos.
Você pode retornar um erro no comando RCPT TO , que é o que geralmente acontece no caso de um endereço inexistente, ou pode retornar sucesso no comando RCPT TO , mas retornar um erro no final de DATA .
Em ambos os casos, o resultado final será o mesmo. Seu servidor de e-mail não assumiu nenhuma responsabilidade pelo e-mail, e o servidor de envio de e-mails agora é responsável por devolvê-lo. Em caso de spam, significa que o spammer terá que gerar retornos. (E se é isso que eles queriam fazer, eles poderiam ter feito isso sem sequer tentar entregar a correspondência para você em primeiro lugar.)
Não vejo problema nessa abordagem.
No entanto, vejo um problema em aceitar o e-mail. Ou seja Se o seu servidor de e-mail responder com sucesso até a transação, incluindo o final de DATA , então, a responsabilidade do servidor de e-mail é entregar o e-mail. Isso é um problema, porque você não tem uma saída adequada.
- A remoção silenciosa do e-mail é um problema, porque, se algum e-mail legítimo for enviado, o remetente nunca poderá saber que ele não foi entregue.
- O envio de devoluções do servidor de e-mail é um problema, porque, nesse caso, o spam é devolvido para a caixa de correio de uma pessoa inocente, em vez de voltar para o remetente de spam.
Pode haver casos em que a distribuição do endereço de e-mail em primeiro lugar seja tão limitada, que você saiba que não pode haver nenhum envio legítimo de e-mail para o endereço. Nesses casos, faz pouca diferença se você rejeitar o comando RCPT TO ou se aceitar o e-mail e silenciosamente descartá-lo. Mas não consigo pensar em uma situação em que, silenciosamente, descartar o e-mail seja melhor do que rejeitá-lo durante a transação SMTP.