<humor> Briga religiasa � vista.. :^)
Sempre... E n�o tem nada de humor nisso.
</humor>
<Material pol�mico>
Eu trablho em um lugar onde usava o qmail e troquei pelo sendmail. Estou acostumdo ao sendmail, e muitas outras coisas.
Ent�o fique com o sendmail. O melhor sistema � sempre aquele que voc� sabe usar. Mas se est� disposto a aprender coisas novas, seja bem vindo.
Pelo que eu entendi do qmail, ele � um conjunto grande de pequenos programas que s�o chamados para processar o e-mail, e o que voc�
Perfeito. E � assim que tudo vai ser feito de agora em diante, incluindo o sendmail nas pr�ximas vers�es.
est� sofrendo, de excesso de processos era plenamente esperado por mim, especialmente quando se coloca muitos m�dulos, como voc� fez. S�o mais programas para serem executados a cada e-mail que chega.
Voce est� assumindo que os programas tem todos o mesmo tamanho. Mas no caso do postfix/qmail/exim/etc os v�rios processos s�o MUITO menores e mais simples que o gigante monol�tico do sendmail. Cada processo tem apenas os privil�gios necess�rios (somente um ou dois s�o setuid root, por exemplo), cada processo pode ter chroot numa regi�o diferente do sistema, e principalmente, n�o preciso carregar em mem�ria o m�dulo s desnecess�rios. Por exemplo, se o email � puramente local, por que carregar o m�dulo SMTP internet? Se o email � SMTP, por que carregar as instru��es de email BITNET? Se estou apenas tentando enviar um email que j� est� na minha fila SMTP de sa�da, por que ter o m�dulo entrega para usuarios ou de verifica��o de v�rus rodando?
Com processos individuais o sistema s� executa o que for necess�rio, quando for necess�rio, com os direitos m�nimos necess�rios.
Acredite. Nos tempos do sendmail 8.9, migrei de sendmail para postfix e a diferen�a de velocidade e consumo de mem�ria foi absurda em favor do postfix. As listas de freebsd.org rodam com postfix, n�o com sendmail. Se rodassem com sendmail uma mensagem sua demoraria dias para chegar na lista, dado o tr�fego do servidor.
Ah, note que o sendmail tamb�m trabalha com o conceito de m�dulos. A ultima vers�o que eu vi j� usava duas instancias em mem�ria, pelo menos. A primeira inst�ncia recebia os processos de usu�rio, sem setuid root, e enviava para localhost:25, esse sim rodando como root. Mas cada processo � monol�tico e completo, ou seja, voc� t� carregando DUAS vezes o mesmo programa para fazer coisas diferentes.
Eu prefiro o sendmail, com a sua interface milter, pois com ela os programas que fazem a an�lise do e-mail (anti-v�rus, anti-spam etc) n�o geram novos processos. Eles s�o processos que j� est�o em mem�ria, poupando o overhead de inicializa��o e finaliza��o dos programas. No m�ximo se tem v�rias tasks de um programa, e n�o muitos processos, especialmente come�ando e terminando.
A interface milter � um ponto a favor do sendmail, e coisa nova depois que eu o abandonei.
O postfix tem um conceito de policy check que � semelhante. Ele passa todos os cabe�alhos e envelopes para um outro processo, conectado por socket, que usa essa informa��o para decidir se entrega ou n�o a mensagem. Eu implemento greylisting assim, por exemplo. Infelizmente a interface de policy n�o previu o envio do conte�do, e por isso n�o pode ser usada para anti-v�rus e assemelhados. Nesse caso, o postfix (e todos os outros modulares) inserem um m�dulo no pipeline de processamento da mensagem. � simples e r�pido, entretanto, quando isso acontece a mensagem j� foi recebida pelo m�dulo smtpd, e n�o d� mais para rejeitar. Pelo menos o policy � durante o smtpd, o que j� � uma vantagem em rela��o ao qmail, por exemplo, que faz a seguran�a e a verifica��o de login local em um m�dulo separado, j� tarde demais para rejeitar durante a recep��o.
_______________________________________________________________ Para enviar um novo email para a lista: [email protected] Sair da Lista: http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
