[FUG-BR] Amavisd + Spambayes
Joao Rocha Braga Filho
goffredo em gmail.com
Quarta Junho 7 10:02:48 BRT 2006
On 6/7/06, Otávio Fernandes <otavio_fernandes at yahoo.com.br> wrote:
> Olá João,
>
> Já montei algumas soluções assim. Gosto muito do sendmail,
> principalmente pela performance e estabilidade, costumo utilizar o
> modelo descrito na documentação do amavisd-new chamado dual-sendmail
> (README_FILES/README.sendmail-dual -- em anexo), no qual uma instância
> do sendmail recebe os e-mails e posta para o amavisd, e este, por sua
> vez, entrega os e-mails para o segundo sendmail, o qual, entrega para
> os usuários ou encaminha para outros MTA's.
Estou lendo, e notei algo estranho.
"
- Full amavisd-new functionality is available, including adding spam and
virus information header fields, adding address extensions and removing
certain recipients from delivery while delivering the same message to
the rest (*_lovers). Also a message can be split if different recipients
need different header edits. All this is not available when using
amavis-milter helper program.
"
O milter permite que sejam feitas várias destas coisas, se não todas. Se
o milter dele não faz, é por que não quiseram fazer.
"
- Content scanning need not be performed at the time of mail reception.
This allows better control on CPU-intensive content filtering: mail
checking can be streamlined and performed at optimum throughput setting
(number of content checker processes) so as not to overwhelm host resources,
instead of leaving it at the mercy of the current number of incoming
SMTP sessions where available crude controls are mostly based on system
load. Typically the number of incoming SMTP sessions (tiny processes)
is desired to be many times above the number of content filtering
processes (heavy resource consumers).
"
Isto é uma faca de dois gumes. Pode funcionar bem para servidores de
e-mail que às vezes recebe um surto de a-mails, mas está idle boa parte
do tempo. Mas para servidores muito ocupados, pode ser mais interessante
filtrar logo, antes que se acumule, e também pouparia espaço em filas, IO,
processamento total, etc.
"
- No helper programs needed, MTA communicates with amavisd-new directly
via SMTP, saves on creating one directory and one file for each message,
and deleting it (at the cost of one additional transfer);
"
Isto deve ser comparando com o milter dele.
"
- Receiving sendmail daemon (MTA-RX) need not run as root (using option
RunAsUser) since it does not need to run any local delivery agents (LDA)
or to access user .forward files. This avoids external SMTP clients
talking directly to a process running as root.
"
Isto pode ser interessanto se surgir um problema de segurança.
A idéia é interesante, mas não sei se o desempenho é alto. Não parece
ser baixo, mas parece não ser, em média melhor que o milter. Pode lidar
melhor com surtos de e-mail, mas pode causar um atraso na entrega e
um aumento da carga total sobre a máquina. A idéia de separar discos
parece interessante, mas isto já pode, pelo menos em parte, ser feito sem
fazer toda esta comfiguração.
O Milter também poderia lidar com surtos, gerando uma resposta de falha
temporária, e assim a mensagem seria reenviada mais tarde.
Atenciosamente,
João Rocha.
>
> boa sorte,
>
> --
> |
> | Otávio Fernandes <otaviof at gmail.com>
> | Debian Sarge 3.1 - Linux User: 283.396
> | http://otaviof.googlepages.com
> |
>
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
>
>
>
--
"Sempre se apanha mais com as menores besteiras. Experiência própria."
goffredo at goffredo.eti.br
goffredo at gmail.com
http://www.goffredo.eti.br
Mais detalhes sobre a lista de discussão freebsd