[FUG-BR] AJUDA (sendmail ou não-sendmail, eis a questao!)
João Carlos Mendes Luís
jonny em jonny.eng.br
Seg Mar 14 19:52:37 BRT 2005
João Rocha Braga Filho wrote:
> <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: freebsd em fug.com.br
Sair da Lista: http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
Mais detalhes sobre a lista de discussão freebsd