Lentidao no servidor de mail (Qmail)

[helio_traxx]

alguem tem ideia do que pode ser!! o meu servidor de email (Qmail) ta muito lento tanto pra enviar quanto pra receber independente do tamanho da msg. (uso fedora 4)

[rato16br]

Dê uma olhadano seu servidor se ele esta demorando para resolver os nomes, tive um problema parecido que era isso, então tive de da uma olhada em meu firewall

[Avenger]

Dá uma olhada no 'uptime' do seu computador, se está baixinho, esse lance de DNS também pode atrapalhar, e também faz um 'ps auxww' prá você ver se tem algum processo (subprocesso do qmail ou nao) comendo muito do processador, outra coisa interessante a olhar é o 'free' se tá usando a swap -- qdo o pc começa a usar swap, as coisas ficam mto mais lentas...

Por ultimo, dá uma olhada nos logs do qmail. Não sei onde você loga o qmail-send seu, você pode ver da seguinte forma, se você usa o daemontools prá manter os processos do qmail rodando:

ps auxww | grep multilog

Vai dar um cado de resultado, e vê se algum deles parece com o do qmail-send (com 'var/qmail/log/send', talvez);
Não funcionando, procura o /var/qmail/rc, edita ele e vê se ele roda o qmail-start redirecionando o output prá algum log, ou se dá alguma pista para 'onde o log dele está indo'.

O que você procura, é um log do tipo:
status: local 0/10 remote 5/120
ou
@4000000043330f3f3079919c status: local 0/10 remote 4/120
de acordo com o log estar sendo gerado pelo multilog ou não.

Bem, se você achar a pastinha do multilog, dá um 'tail' no arquivo 'current' e verifica esse texto do log: se o local 0/10 estiver algo como 10/10, é porque a fila tá bem cheia. Igualmente, o 'remote' deve estar baixo. Se esse número está próximo ou alcança o segundo número (à direita da barra (/)), significa que a fila está muito cheia, e com isso -vai- demorar a sairem os e-mails.

Achando esse log fica mais fácil você acompanhar até seu andamento na resolução do problema. Caso você indague sobre o '/120' no meu resultado ser diferente do seu, é porque eu fiz uma modificação no /var/qmail/control/concurrencyremote (só deixar o arquivo com o número 120). Acho que não precisei fazer patch adicional para ele ler esse arquivo, mas não lembro bem.

Bem, levantando mais uma hipótese pro seu problema, se um dos números do log estiver cheio, você pode estar sendo um terrível e perigoso 'open relay'. Daí os spammers acham seu servidor (sim, eles acham um open relay em questão de horas em entopem ele de spam!). Nesse caso, -não execute um teste online do ordb.org-, porque você pode ser listado. Se você rodar algum teste de open relay é preferivel você mandar email prá um amigo conectar no seu smtp de outro provedor sem ter antes checado e-mail pelo pop3, enviando um e-mail para um -terceiro- domínio (endereço de e-mail, nem pro seu domínio de email, nem pro domínio dele). Outra coisa que você nota com o open relay vai ser alto uptime e alto tráfego de dados na rede (podendo até parar seu link se não for muito bom).

Prá consertar esse problema de open relay, você pode fazer como é recomendado no howto de instalação do qmail, o /etc/tcprules permitindo relayclient só pros IPs da sua faixa, ou ainda melhor, fechando relaydomain prá todo mundo, e fazer o smtp-after-pop3 do vpopmail. O Vpopmail tem um recurso que assim que um cliente checa sua caixa de e-mail, o servidor libera o SMTP pro IP dele por 30 minutos, dessa forma qquer cliente seu vai poder usar seu SMTP sem ser filtrado, e você não atuará como um open relay. Só que seus clientes têm que checar e-mail antes de enviar. Na pior das hipóteses, se o cliente usa outlook, redige os e-mails e conecta na net para mandá-los, ele vai receber um erro de 'relay blahblah' na primeira vez que clicar em enviar/receber, e da segunda vez os mails vao sair direitinho. Nada muito aborrecedor. E note que você pode usar o smtp-after-pop (ou pop-before-smtp?) juntamente com o /etc/tcprules prá liberar alguma faixa de IP fixa que você tenha.

Espero que ajude!!

[helio_traxx]

Ajudou um bucado mesmo!!! era o spamassasin que nao tava levantando!!!