Devo deixar o email saltar ou enviá-lo para um buraco negro?

Eu tenho muitas contas não usadas (antigas, mortas) na minha máquina. Muitos deles recebem literalmente milhares de e-mails por dia, todos spam.

Se a conta foi usada por uma pessoa, deixei o e-mail saltar para que qualquer pessoa que tentasse entrar em contato com ela soubesse que algo estava errado. No entanto, não tenho certeza do que fazer com as centenas de contas usadas para outros fins, como contas descartáveis ​​que costumava usar em sites que solicitavam meu endereço de e-mail ou endereço que eu costumava listar em páginas da web .

Opção 1:
Encaminhe todos os emails para essas contas para /dev/null. O remetente não recebe uma devolução.

Opção 2:
deixe o email retornar.

A vantagem de enviar o e-mail /dev/nullé que um remetente de spam não pode me usar para gerar mensagens de devolução (spam de retroespalhamento) . ou seja: forje a linha "de" para ser alguém de quem não gosta e use-me para enviar toneladas de mensagens de devolução a essa pessoa.

O benefício de devolvê-los é que é menos manutenção para mim. Só posso excluir o item do meu arquivo de alias e o e-mail retornará. Além disso, continuo descobrindo novas armadilhas de spam e adicionando-as à minha lista de "buracos negros de spam", que é uma perda de tempo.

Quais são os prós e os contras de cada abordagem?

Desde que você devolva o e-mail recusando-se a recebê-lo, o spammer não poderá usá-lo para incomodar alguém inocente com muitos retornos.

Você pode retornar um erro no RCPT TOcomando, o que geralmente acontece no caso de um endereço inexistente, ou pode retornar com êxito o RCPT TOcomando, mas retornar um erro no final de DATA.

Nos dois casos, o resultado final será o mesmo. Seu servidor de correio não se responsabilizou pelo correio, e o servidor de envio agora é responsável por devolvê-lo. No caso de spam, isso significa que o remetente terá que gerar devoluções. (E se é isso que eles querem 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 ao aceitar o correio. Ou seja, se o seu servidor de email responder com êxito durante toda a transação, inclusive no final de DATA, então será responsabilidade do servidor de email entregá-lo. Isso é um problema, porque você não tem uma saída adequada.

• Ignorar silenciosamente o e-mail é um problema, porque se algum e-mail legítimo foi enviado, o remetente nunca pode saber que não foi entregue.
• Enviar saltos do servidor de email é um problema, pois nesse caso o spam salta 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 email em primeiro lugar foi tão limitada, que você sabe que não pode haver nenhum email legítimo enviado para o endereço. Nesses casos, faz pouca diferença se você rejeitar o RCPT TOcomando ou se você aceitar o e-mail e descartá-lo silenciosamente. Mas não consigo chegar a uma situação em que soltar o correio silenciosamente é melhor do que rejeitá-lo durante a transação SMTP.

Vou tornar essa resposta bastante genérica, pois os detalhes da terminologia e da configuração variam de acordo com o seu servidor de email específico / software de filtro de spam.

Na verdade, existem três abordagens para um destinatário inválido:

1. Depois que o destinatário for considerado inválido, envie uma mensagem Não entregue de volta ao remetente.

2. Feche a conexão SMTP enquanto a mensagem ainda estiver "em andamento". O servidor SMTP do remetente será responsável pela geração da mensagem Não entregue.

3. Aceite a mensagem e exclua-a silenciosamente. O remetente não tem idéia se a mensagem foi ou não recebida.

Há poucas razões para usar a abordagem nº 1. No caso de um ataque de retrodispersão, seu servidor será parecido com o spammer (mesmo sendo uma vítima inocente) e você será quem entra na lista negra. Ele também carrega mais carga no servidor e carrega largura de banda, porque precisa enviar a mensagem de devolução.

A abordagem nº 2 é praticamente universalmente melhor do que a abordagem nº 1. Reduz a possibilidade de seu servidor ser colocado na lista negra ou no DoSed. Isso não elimina a possibilidade de retrodifusão contra um endereço de terceiros inocente, mas pelo menos não é o servidor que envia as mensagens de devolução.

A abordagem nº 3 elimina a possibilidade de retroespalhamento. Também ajuda a se proteger contra um ataque de colheita de diretório . No entanto, isso também significa que, se um remetente externo digitar incorretamente seu endereço, ele nunca saberá. Também pode ser um problema se alguém deixar sua empresa e um cliente tentar entrar em contato com o ex-funcionário.

Eu herdei um sistema de email que usava a Abordagem nº 3 devido a preocupações com o DHA. Causou mais problemas do que valia a pena. Agora usamos a abordagem nº 2. (Observe que existem outras maneiras de reduzir o DHA.)

Se o seu servidor de email estiver configurado corretamente, você deve rejeitar o email para usuários desconhecidos durante a transação SMTP.

Rejeitar email durante a transação SMTP

Seu servidor deve estar configurado para rejeitar email para usuários desconhecidos durante a fase de transação SMTP. Fazer isso retorna um código de erro 550 SMTP para o servidor de envio. Como isso acontece durante a transação SMTP, seu servidor nunca envia um Relatório de Não Entrega (também conhecido como devolução).

Configurado corretamente, isso evita a retroespalhamento, pois a rejeição é enviada diretamente ao servidor de envio e outros cabeçalhos de email são ignorados.

Benefícios

Os benefícios dessa abordagem são que você rejeitará o email muito em breve no processo de transação do SMTP. Isso pode significar:

• Menor utilização de recursos em seu servidor, especialmente se todos os emails forem enviados para processamento após a aceitação (filtragem antivírus / av).
• Os remetentes costumam remover esses endereços de email de suas listas para evitar serem incluídos na lista negra.

Considere que, se você nula o email, o servidor remetente acha que a mensagem foi entregue com sucesso. Não há motivo para eles pararem de enviar esses endereços extintos. Como resultado, à medida que esses endereços antigos se acumulam, você precisa de mais e mais recursos do servidor para processar o email.

Para implementar isso, basta excluir os usuários do sistema de email. Se você precisar de backups do email atual, tudo bem, você só quer que seu servidor envie a 550 user unknownresposta.