QMail - um monte de aviso de falha na fila no relé aberto apenas para localhost

2

Eu configurei um servidor qmail para rejeitar mensagens se o destinatário não estiver listado em rcpthosts e estou usando tcp-env com xinetd para permitir que procs locais enviem e-mails para qualquer pessoa adicionando a seguinte linha a /etc/hosts.allow :

tcp-env: 127.0.0.1 : setenv RELAYCLIENT

Durante os testes tudo parece estar funcionando corretamente:

$ telnet mydomain.com 25
Trying xxx.xxx.xxx.xxx...
Connected to mydomain.com.
Escape character is '^]'.
220 mydomain.com ESMTP
HELO
250 mydomain.com
MAIL FROM: [email protected]
250 ok
RCPT TO: [email protected]
553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)

Na vida real, há muitas mensagens como essa na fila:

2744522 (1, remote)
  Envelope Sender:
  Envelope Recipient: [email protected] (To Be Delivered)
  Date: 22 Apr 2014 07:38:14 -0000
  From: [email protected]
  To: [email protected]
  Subject: failure notice
  Size: 18.45KB (18889 Bytes)

O QMail deve enviar um aviso de falha para domínios listados em rcpthosts e deve rejeitar e-mails para domínios não listados nele sem enviar aviso de falha.

Alguém pode me explicar o que estou fazendo de errado?

Obrigado!

    
por Erich 22.04.2014 / 14:44

1 resposta

1

Uma das desvantagens do qmail é que, por padrão, ele não verifica a localpart do endereço do destinatário antes de aceitar a mensagem. Tudo o que ele faz é verificar se o domínio do destinatário está em sua lista de domínios de destinatários permitidos. (Esta foi uma escolha de design não razoável no início de 1990. É menos hoje em dia.) Isso significa que, por exemplo, Os spammers que fazem um spray de dicionário podem encher o seu servidor lançando um zilhão de mensagens para destinatários inexistentes. Quando o qmail tenta entregar as mensagens, ele descobre que o local não existe e irá gerar uma mensagem de rejeição. E como os spammers forjarão o remetente do envelope, seu servidor não poderá entregar essas mensagens e preencherá a fila.

A melhor solução é não aceitar esses emails em primeiro lugar. Se o seu servidor puder rejeitar e-mails imediatamente em RCPT TO:[email protected] , então será o trabalho do servidor de envio de e-mails para emitir a devolução e você não será inundado com rejeições.

Outra solução seria reduzir a quantidade de tempo que o qmail continuará tentando entregar mensagens devolvidas, para que elas sejam excluídas antes e, portanto, também não preencham a fila.

E, claro, você pode filtrar o spam recebido e descartá-lo, em vez de permitir que ele gere rejeições.

Rejeitando partes locais desconhecidas

A única maneira de conseguir isso é corrigir o qmail, para que qmail-smtpd verifique as partes locais. Você não pode fazer isso apenas com opções de configuração, você precisa realmente corrigir e recompilar e instalar o patch qmail-smtpd .

Existem alguns patches diferentes que podem alcançar isso. Eu não posso recomendar qualquer um deles sobre o outro - de volta quando eu estava gerenciando servidores qmail, tivemos outro sistema atuando como um proxy que fez essa filtragem, então eu nunca precisei usar isso. Mas você pode encontrar vários patches em netdevice.com/wmail/rcptck e code.dogmap.org/qmail/ .

Reduzindo o tempo qmail tenta entregar bounces

Se isso puder ser feito apenas para rejeições, não sei como. Mas você pode fazer isso para todos os e-mails, alterando o valor de queuelifetime . man qmail-control deve dizer como fazer isso.

Filtragem de spam

Há muito a dizer sobre a filtragem de spam para caber em uma única resposta aqui. Eu começaria considerando listas de blackhole no estilo RBL e rejeitar conexões de endereços IP listados nelas. É claro que você precisa escolher cuidadosamente suas listas de buracos negros e corre o risco de bloquear o correio "real". Há algumas informações sobre a filtragem de spam especificamente para o qmail no howto anti-spam qmail de Chris Hardie , e há informações sobre várias listas de blackhole em spamhaus.org .

Espero que isso seja suficiente para começar. Eu usei o qmail por algumas décadas, incluindo a execução do sistema de e-mail para um ISP com vários milhões de usuários - mas eu também tenho que acrescentar que se eu tivesse que configurar esse sistema agora, o qmail não seria mais minha primeira escolha . Era um servidor de e-mail muito bom quando foi criado, e fazia muitas coisas muito bem, mas hoje em dia eu provavelmente usaria o postfix. O tempo e os spammers mudaram e o qmail ainda não.

    
por 22.04.2014 / 15:57

Tags